대니 쏘프는 볼랜드의 치프 사이언티스트이며, 이전에는 델파이를 처음 개발한 팀의 일원이었다. 빌더 매거진에서는 .NET으로의 이전, 카일릭스, 그리고 델파이의 미래에 대해 대니와 인터뷰를 가졌다.

브렌든 체이스, 2005년 6월 20일

Builder AU: 현재 당신이 볼랜드에서 맡고 있는 업무는 무엇인가?
대니 쏘프: 작년에 치프 사이언티스트로 승진했다. 나의 주 업무는 업계와 기술이 변해갈 지평을 예측하고 그쪽으로 가기 위한 우리의 내부 일정을 설정하는 것이다. 개인적으로 내 주 관심은 아직 델파이 언어와 컴파일러에 있다. 나는 아직 컴파일러 자체를 재설계할 방법을 살펴보고 있는데, 컴파일러에서 멀티 쓰레드의 이점을 활용할 방법이 있을지도 모르겠다. 이것은 과거에 시도해보지 않았던 것이다.

이미 C#이 이미 나와있는데 왜 델파이.NET인가?
.NET 플랫폼의 멋진 점들중 하나는 개발자가 익숙한 언어를 선택할 수 있는 유연성과 자유다. C#은 기본적으로 C에 기반한 언어이고, 자바는 C 기반의 언어이면서 개발자를 특별한 정신세계로 끌어간다. C 스타일 모델에 동조하지 않는 수없이 많은 사람들이 있다. 또 파스칼과 델파이를 경험한 많은 사람들이 있으며, 이런 사람들의 경우 다른 언어를 새로 배우는 것보다는 델파이.NET을 이용하는 편이 낫다.

비주얼 베이직에 관련된 재미있는 사실 하나는, VB.NET과 VB6 사이의 관계에 대한 것이다. 이 언어는 .NET을 위해 완전히 처음부터 새로 설계되었기 때문에 호환성 면에서 잃은 것이 많다. 이런 문제의 일부는 우연적이고 또다른 일부는 마이크로소프트가 의도적으로 그렇게 한 것이며, 비주얼 베이직 커뮤니티는 이런 문제에 대해 정말로 화를 내고 있다. 델파이 커뮤니티에서 우리가 가지고 있는 많은 강점은 우리가 사람들을 전진하게 하고 새로운 분야로 나아가게 하는 데에 아주 성공적이었다는 것이다.

전통적인 델파이 개발자들이 .NET으로 넘어가는 과정에서는 그런 문제(VB의 호환성 문제)를 보지 못했나?
"지금까지 사용했던 것처럼 포인터를 사용할 수 없어요" 등의 전형적인 불만을 말하는 것 같다. 하지만 대체로 델파이에 있어 Win32에서 .NET으로의 전환은 VB6에서 VB.NET으로의 마이그레이션에 비하면 훨씬 수월하다. 예를 들어, VB6 에서 사용하던 컨트롤들을 NET 플랫폼으로 마이그레이션하는 것은 불가능하지만 일반적인 애플리케이션이라면 몇시간 내에 .NET으로 마이그레이션할 수 있다.

카일릭스 관련으로는 어떤지, 그리고 리눅스 플랫폼을 위한 개발자 툴을 만드는 쪽으로 진행되고 있는 일로는?
카일릭스는 너무 일찍 나옴으로써 희생된 경우였다. 내게 가장 놀라웠던 점들 중 하나는, 리눅스 시장에서 말 많고 적극적인 일부는 다른 툴들을 원하지 않았다는 것이다. 그들은 이런 식의 말들을 했었다. '왜 델파이 같은 것을 여기 갖다놨나? 우리는 원하지 않는데. 내 뒤뜰에서 그런 것은 좀 치워달라구. Emacs와 C++이야말로 모든 사람들이 필요로 하는 거라구.' 이런 말들이 우리를 낙담하게 했다. 우리는 리눅스 개발자 커뮤니티에 서비스를 제공하면서도 큰 손실을 보지 않는 방법들을 찾고 있다. 이미 우리는 3년전 마지막 발표 이후 카일릭스를 현재의 표준으로 끌어올리기 위해 몇몇 기술 문서들의 초안을 가지고 있다. 리눅스는 그 이후로 많이 변했고 카일릭스에도 상당한 양의 작업이 필요하다. 우리는 이 작업을 사내에서 직접 할 수도 있고 혹은 계약에 의해 외부에서 진행할 수도 있다. 이떤 경우든 커뮤니티의 반응에 따를 것이다.

오픈소스 커뮤니티에 코드를 제공하는 것도 고려중인가?
이미 런타임은 오픈소스로 넘겨져 있다. 다만 컴파일러를 오픈소스로 제공하는 일은 없을 것이다. 시간이 지나다보면 언젠가는 IDE를 오픈소스로 공개하는 것도 가능할 것이다. 나는 IDE 팀을 대변할 수는 없다. 하지만 아직 컴파일러 내에 활발하게 사용되고 있는 지적 재산들이 많이 있다.

카일릭스를 오픈소스화하는 데 있어 다른 중요한 점은, 이클립스(Eclipse)와 직접적으로 비교될 것이라는 점이다. 볼랜드에 카일릭스의 무료 혹은 오픈소스 에디션을 지원할 커뮤니티를 구축할 수단이 있는가? 아마 대단히 어려울 것이다. 아마 또다른 접근 방법은 이클립스 위에 구축하는 것을 고려하는 것일 것이다. 이렇게 하면 이전과 동일한 커뮤니티를 대상으로 할 수 있고, 많은 이클립스 멤버들이 하고 있는 것처럼 사용가능한 툴들에 상용의 제품을 구축할 수 있다. 이것은 가능성이다.

당신은 모노 프로젝트와 밀접하게 작업중이라고 보는가?
물론이다. 나는 이따금씩 미구엘 데 이카자에게 메일을 보내고 있다. 그는 현재 노벨에 있지만 카일릭스에 흥미를 가지고 있다. 모노는 확실히 강력한 개발툴 커뮤니티를 찾고 있기 때문에 그들은 볼랜드가 참여하는 문제에 대해 큰 관심을 가지고 있다. 물론 마이크로소프트의 그림자가 항상 따라다니기 때문에, 우리는 누구를 어떻게 불쾌하게 하지 않을지 주의해야 한다. 볼랜드에도 그 문제에 대해 매우 신중한 사람들도 있지만, 적어도 나는 그들중 하나는 아니다. 우리 델파이 .NET 테스트 팀에는 .NET 코드가 모노에서도 동작하도록 하기 위해 모노 베타 테스터도 포함되어 있다. 정치적으로 민감한 부분은 모노 개발을 얼마나 촉진하게 될지, 그리고 마이크로소프트가 어느 정도 선에서 개입하게 될지이다.

델파이는 올해로 10주년을 맞이했다. 향후 5년에서 10년 사이에 델파이는 어떨 것으로 보는가?
앞으로 5년에서 10년 동안 우리는 C++과 조금 정도가 덜한 C#처럼 표준화된 언어들은 쉽게 접근하기 힘든 특정한 복잡한 프로그래밍 작업을 근본적으로 단순화해주는 개발 언어 및 툴셋에 주목할 필요가 있다.

한 예로, 나는 멀티코어 프로세서가 애플리케이션 개발에 미칠 영향에 대해 많은 생각을 하고 있다. 프로세서에 있어 기가헤르츠 경쟁은 끝났다고 할 수 있고, 멀티코어 프로세서에서는 복수의 실행 코어 경쟁으로 가게 될 것이다. 이런 멀티코어에서 모든 계산 능력을 활용할 수 있는 애플리케이션은 멀티쓰레드 기반일 수밖에 없다. 현재의 멀티쓰레딩에 있어 문제점은, 모든 것이 수작업이고 프로그래머가 모든 것을 해야 한다는 것이다. 이제 개발툴의 경쟁에서 핵심은 자동화되고 세부적인 부분에 대해서만 신경을 쓸 수 있는 단순화된 모델을 제공하는 것이다. 나는 델파이 언어의 변화로 그런 방향으로 갈 수 있는 기회를 가지고 있다고 생각한다. 만약 기존의 언어 일부를 재정의하거나 혹은 새로운 기능을 추가할 수 있다면 "이 루틴은 다른 모든 루틴들과는 독립적으로 실행될 수 있다"고 말할 수 있게 되고, 그러면 개발자들은 콜백이나 많은 다른 문제들에 대해 걱정하지 않아도 되게 된다.

우리는 또한 좋은 프로그래밍 관행을 장려하기 위해 타입 기하학 작업을 진행중이고 또 개발자들의 코드를 분석하여 개발자들에게 성능 측면에서 보상하고 있다. 이것은 연구활동의 모든 영역이다.

나는 델파이가 이런 좁고 수직적이며 특정 분야에만 적합한 프로그래밍 언어로 발전해가는 것을 보고 싶지는 않다. 델파이는 범용 언어이며 그런 장점을 지켜나갈 것이다. 또한 우리는 .NET에서 독자적인 영역을 가지고 있을 뿐 아니라 다른 플랫폼들에서도 마찬가지이다. C#은 .NET 이외의 어디에서도 사용될 수 없으며 그럴 수 있는 언어는 극소수이다. 약속하건대 우리는 델파이의 [다양성]을 계속 지켜나갈 것이다.

최근 2년 동안 마이크로소프트와 썬같은 기업들은 자사의 제품 및 서비스의 로드맵에 대해 더욱 투명하게 하려고 노력해왔다. 볼랜드는 앞으로의 제품 발표 및 계획에 대해 좀 더 공개적이 될 수 있는가?
우리는 회사 체제에 따라 기본적으로 비공개로 임해왔다. 과거의 볼랜드는 모든 것에 대해 언급을 꺼렸으며 제품을 발표할 때마다 고객들은 놀라게 했었다. 업계는 그 이후로 계속 발전해왔고 고객들은 더 많은 정보와 더 세세한 공지를 바라고 있다. 대기업들은 이미 수백만 달러를 투자한 제품의 새 버전으로 인해 놀라기를 바라지 않는다. 하지만, 우리가 공개를 할지 혹은 공개를 하지 않을지는 균형의 문제다. 델파이의 로드맵은 공개하는 쪽으로 결정되었고 다른 부문들에서 고민중인 문제에 영향을 미칠 것 같다.

델파이가 공개 베타로 나올 계획은 없는가? 이 방법이 더 나은 개발툴을 만드는 데 도움이 될 거라고 생각하는가?
나는 우리가 퍼블릭 베타를 채택할 것으로 생각한다. 아직은 거기까지 나아가지 못했지만 그런 일을 추진하기 위한 내부적인 세력이 점점 가속화되고 있다. 그건 단지 정책의 문제이다. 나는 베타 테스팅이 버그를 효과적으로 찾아준다고 생각하진 않으며, 퍼블릭 베타는 샷건이다. 개발자들이 버그를 찾는 방법은 체계적인 유닛 테스팅, 라인별 조직적 테스팅이다. 퍼블릭 베타가 도움을 주는 곳은 판촉 활동이다. 숨겨진 제품을 갑자기 공개할 경우 퍼블릭 베타는 일찍부터 사람들의 마음을 효과적으로 사로잡을 수 있다. 피드백과 유용한 기능들을 수집하는 측면에서는, 비공개 테스팅도 이미 많은 정보를 제공하고 있다. 퍼블릭 베타를 실시함으로써 얻는 주된 이득은 판촉이다.

e메일 작성이나 볼랜드에서 델파이 컴파일러 관련 작업을 하지 않을 때 당신은 뭘 하는가?
나는 열렬한 스노우보더이다. 이미 두번이나 목이 부러질 뻔 했으며 아직 어께에 상처가 남아있다. 한 친구와 함께 우리 보드를 직접 만들고 있는 중이다. 몇가지 가벼운 해결할 기술적 문제가 있긴 하지만 시작할 준비가 되어 있다.

원문 : http://www.builderau.com.au/architect/sdi/0,39024602,39194366-1,00.htm
번역 : 박지훈.임프