요약: 이 글에서는 Delphi 컴파일러의 현재 상태와 미래를 조망해봅니다.

서론

이 아티클은 모든 여러분 Delphi 사용자들에게 우리가 Delphi 컴파일러에 대해 어떤 작업을 하고 있고 어떤 고려를 하고 있는지에 대해 알려드리기 위한 것입니다. 우리 전세계의 엠바카데로 직원들은 모두 여러분이 얼마나 델파이 컴파일러를 사랑하는지 너무나 잘 알고 있으며, R&D 연구팀에서 개발중인 멋진 언어 및 컴파일러 기술들이 있기 때문에 여러분이 좋아하는 컴파일러의 미래에 대한 최신의 소식들을 알려드리려고 합니다.

약간의 히스토리

하지만 먼저, 델파이 컴파일러에 대한 히스토리 이야기를 잠깐 하겠습니다. 이 내용 대부분은 여러분에게 새로운 이야기는 아니겠지만, 기억을 되살려보는 것이 중요합니다. 먼저, 델파이 컴파일러는 아주 오랜 세월을 겪어왔습니다. 델파이 컴파일러는 빠르면서도 최신의 툴임이 여러번 증명되었으며, 여러분에게 제네릭, 익명 메소드, 인라이닝 등등 수많은 멋진 최신 기능들을 제공해왔습니다. 하지만, 그 엄청난 유산 때문에, 델파이 컴파일러 안에는 오래 전의 터보 파스칼 시절부터 내려온 코드들까지도 그대로 남아있으며, 그 세월은 은하계만큼 먼 오랜 시간입니다. 델파이 컴파일러에는 아마도 여러분들 중 다수가 존재하는지도 알지 못하고 있을 많은 언어 기능들도 있습니다. 예를 들면, 여러분들 중 (*...*)으로 주석문을 만들 수 있다는 것을 아는 분들이 얼마나 될까요? 또 다음과 같은 코드가 여전히 컴파일된다는 것을 아는 분들은 얼마나 될까요?

var
  WeirdLookingArray: array(.1..10.) of string;

자, 솔직해져봅시다. 이런 기능들을 아는 분들은 그렇게 많지는 않을 것입니다.

하여튼, 델파이 컴파일러는 이런 구문들과 다른 많은 언어 기능들을 하위 호환성 때문에 유지하고 있습니다. 하위 호환성은 여러분에게 정말, 정말로 중요하며 우리에게도 마찬가지로 정말, 정말로 중요합니다. 한번 더 강조하겠습니다. 하위 호환성은 여러분에게 정말, 정말 중요하며 우리에게도 정말, 정말 중요합니다. (이탤릭체로 써서 더 강조가 되었으면 좋겠습니다. 네, 이제 계속 얘기를 진행하겠습니다.) 하지만, 이런 기능들 중 많은 것들이 여러분들에게 이젠 많이 사용되지 않고 있습니다. 더욱이, 우리는 델파이 컴파일러의 매 버전마다 여전히 이런 기능들을 유지보수하고, 테스트하고, 인증합니다. 이것은 대단히 큰 작업입니다. 하지만 여러분 모두 컴파일러 내의 모든 기능을 사용하지는 않을 것이기 때문에("괄호와 마침표" 같은 것을 알고 있었다고 하지 마세요), 여러분 대부분이 신경쓰지 않는 기능들은 실제로는 동작되지 않습니다. 별로 사용되지 않는 언어 기능들을 계속 지원함로써 새로운 기능에 작업할 수 있는 시간을 소모하게 됩니다.

위의 예는 그저 예일 뿐입니다. 하지만 이런 많은 코드 문법들은 우리가 델파이 언어를 변경하고 현대화하려는 작업을 실질적으로 가로막을 수 있는 기능들입니다. 더 이야기하기 전에 한가지 분명히 하겠습니다. 저는 기능의 제거에 대해 이야기하고 있는 것이 아닙니다. 저는 단순히 델파이 언어가 현재 가지고 있는 이슈에 대해 말하고 있는 것입니다. 우리는 어떤 언어 기능들도 제거하거나 여러분의 코드가 오동작하도록 만들 어떤 계획도 가지지 않고 있습니다. 다시 말하지만, 우리는 그럴 계획이 없습니다. 하지만 우리가 뭔가 재미있는 새로운 계획을 가지고 있는 것은 사실입니다.

그래서....

그래서, 우리는 이 문제에 대해 오랫동안 심각하게 고민해왔습니다. 특히, 어떻게 하면 현대적이고 강력한 컴파일러들이 지원하는 모든 것들을 계속 지원해나갈 수 있도록 우리 컴파일러를 발전시킬 수 있을까요? 어떻게 하면 여러분의 기존의 코드를 유지하도록 하는 동시에 멋진 새로운 기능들을 추가하여 델파이 컴파일러가 발전해나가도록 할 수 있을까요?

이 질문에 대한 대답은 짧지도 간단하지도 않습니다. 또 이 질문은 우리가 가볍게 받아들일 수 있는 문제도 아닙니다. 우리는 전체 컴파일러의 앞단을 재작성하여 우리가 원하며 여러분 모두가 가진 많은 코드를 포기하는 새로운 델파이 언어를 만들어낼 수도 있습니다. 하지만 그것은 정말로 나쁜 일입니다. 정말로 나쁩니다. 우리는 결단코 그런 일을 원하지 않습니다. 다시 강조하겠습니다. 우리는 여러분이 가진 기존의 코드들이 동작하지 않게 만들 어떤 계획도, 어떤 의도도, 어떤 이유도 없습니다.

우리가 원하는 것은, 델파이가 네이티브 코드 개발의 최첨단을 계속 달리도록 앞으로 계속 나아가도록 하는 것입니다. 하지만 가끔은 앞으로 나아가는 것이 과거에 연결된 것들 때문에 어려울 때도 있습니다. 델파이는 매우 타입에 안전한(type-safe) 언어이지만, 완벽하게 타입 안전한 것은 아닙니다. 지금도 GetMem을 호출하거나, 범위가 지정되지 않은 배열(array[0..0] of integer)을 생성하거나, 참조를 이용하여 저수준 메모리로 모든 종류의 이상한 일들을 할 수 있습니다. 그런 작업을 할 수 있다는 것은 강력한 기능이지만, 여러분이 하고 있는 작업에 대해 훨씬 덜 설명적이 된다는 것을 의미하기도 하며, 따라서 컴파일러는 여러분이 하던 그대로 하도록 둘 것입니다. 많은 경우에 이것이 여러분이 원한 바로 그것일 수도 있지만, 문제를 일으키는 주된 예일 수도 있으며 여러분이 "제 발등을 찍을" 수도 있습니다. 델파이는 여러분이 안전벨트 없이 달릴 수 있게 해주지만, 그럴 수 있다는 사실은 델파이의 입장에서는 그럴 수 없다는 것을 의미합니다. 여러분의 멋진 차를 그대로 몰 수 있으면서도 3점 고정 안전벨트와 완벽한 에어백을 가질 수 있다면 멋지지 않겠습니까. 그럼 컴파일러 관련으로 해야 할 일들이 뭐가 있을까요?

컴파일러의 프론트 엔드 부분

일반적으로 컴파일러는 보통 "프론트 엔드(Front End)"라고 불리는 부분을 가지고 있습니다. 프론트 엔드는 코드를 전달받아 해석하고 프로그램의 의미적 의도를 나타내는 트리 구조를 생성합니다. 이것은 언어의 구문을 이해하는 부분으로서 궁극적으로 그 언어가 어떤 언어인지를 정의하는 부분이기도 합니다. 델파이에서는, 프론트 엔드는 유닛, for 루프, begin...end 쌍, 변수 선언, 제네릭 클래스같은 모든 델파이 문법 요소들을 읽어들이는 방법을 알고 있습니다. DCU 파일을 생성하는 것도 프론트 엔드입니다. 위에서 말한 모든 오래된 구문들을 처리하는 것도 역시 프론트 엔드입니다. 따라서, 결국 문제는 이것입니다: 어떻게 여러분의 중요한 코드들을 그대로 동작하게 하면서도 최신의 언어 기능들을 추가할 수 있도록 델파이 프론트 엔드를 수정하느냐 하는 것입니다.

만약, 우리가 새로운 컴파일러 프론트 엔드를 만들어서 여러분이 새로운 구문과 이전 방식의 구문 사이에서 선택할 수 있게 하면 어떨까요? (다시 한번 분명하게 짚고 넘어가겠습니다: 우리는 언어 기능의 제거에 대해 말하고 있는 것이 아닙니다. 여러분이 격분해서 "그래서 어떤 코드 구문을 없애려고 하는 겁니까?"라고 묻는다면, 저는 바로 "없습니다. 여러분의 모든 코드는 그대로 동작할 것입니다."라고 대답할 것입니다. 이 점에 대해 우리는 분명합니다. 그렇죠?) 아니면, 기존의 코드와 "새" 코드를 보여주는 새로운 방법을 고안하여 함께 동작하도록 하면 어떨까요? 새 코드는 새로운 모듈에 넣고 옛 코드는 이전처럼 그냥 둘 수 있다면 말입니다. 새로운 방식에 기존의 모든 코드를 그대로 끼워넣을 수 있을 것이지만, "새롭고 개선된" 기능을 이용하려고 한다면 새로운 타입의 코드 모듈에 해야 할 것입니다. 그리고, 컴파일러 버전에 특정되지 않는 DCU 포맷(혹은 현재의 DCU와 비슷한 무언가)을 만들어낸다면 어떨까요? 이런 모든 것들이 어떻게 느껴집니까?

제겐 아주 멋지게 느껴지지만, 이런 일은 당연히 가벼운 일이 아니며 심각한 정도의 시간과 노력을 필요로 할 것입니다. 하지만 이런 일은 그럴 만한 가치가 있지 않겠습니까?

하지만 이런 프론트 엔드의 문제는 단지 절반일 뿐입니다. 컴파일러의 백 엔드 부분도 남아있으니까요.

컴파일러의 백 엔드 부분

여러분이 컴파일러 분야의 전문가가 아니라면, 컴파일러의 "백 엔드(back end)"는 프론트 엔드가 생성한 것들을 읽어들여 기계어 코드를 만들어 사용 가능한 바이너리나 런타임에서 사용이 가능한 어떤 것을 생성하는 부분입니다. 델파이 및 C++ 컴파일러의 백 엔드는 현재 윈도우용 32비트 바이너리를 생성합니다. 하지만 물론 백 엔드가 32비트나 윈도우에 한정되는 것은 아닙니다.

우리가 백 엔드에서 처리해주기를 바라는 새로운 기능들 중 하나는 64비트 바이너리입니다. 그리고 64비트 바이너리의 생성은 새 백 엔드를 필요로 할 것입니다. 기존의 32비트 백 엔드에 추가 작업을 해서 64비트 백 엔드를 만들어 여러분 개발자들에게 드릴 수도 있습니다. 하지만 그건 제대로 된 방법이 아니며, 특히 우리의 C++ 및 델파이 컴파일러는 현재 서로 다른 백 엔드를 가지고 있기 때문에 더욱 그렇습니다. 한번에 할 수 있는 일이라면 두 번 할 이유가 없을 것입니다. 그리고 64비트 프로젝트는 당연히 컴파일러 하나만의 문제는 아닙니다. 디버거, 에디터, 파일 시스템, 리팩토링, 모델링, 문서 등 모든 것을 제대로 작업해서 아무런 제한 없이 완전하게 준비하려 하고 있습니다. 이런 작업은 어느 정도 시간이 소요될 것입니다..

그런 방법이 아닌, 일을 제대로 하는 방식은 새로운 백 엔드를 만드는 것입니다. 그리고 새로운 백 엔드를 만들기로 결정했다면 제대로 된 방식은 델파이와 C++빌더 양쪽 모두에서 사용 가능한 단일 백 엔드를 만드는 것일 겁니다. 그리고 그렇게 한다면, 타겟으로 하는 아키텍처를 고려하여 좀 더 유연할 수 있도록 하는 방법으로 하려 할 것입니다. 재미있는 생각이죠, 그렇지 않습니까?

따라서 델파이와 C++빌더 양쪽 모두에 대해 동작하는 완전히 새로운, 통합된 백 엔드를 만드는 것이 말이 되게 됩니다. 하지만 그런 작업에는 시간이 필요합니다. 솔직히 말하면 우리가 좋아하는 것보다는 더 많은 시간이 필요하겠지만, 이런 일들은 서둘러서는 안됩니다. 결과적으로, 이런 작업을 제대로 하고, 제대로 동작하도록 하고, 델파이와 C++빌더 모두에게 적절한 컴파일러 아키텍처를 만들어내는 것은 만만치 않은 노력이 필요합니다. 제대로 하는 것은 우리에게 중요한 일이며, 여러분 개발자들에게도 마찬가지로 중요할 거라고 생각합니다.

재미있게도, 이 새 백 엔드를 만들어내고 64비트 제품을 개발하는 데 필요한 시간으로 인해 우리가 새로운 델파이 프론트 엔드를 할 기회가 생깁니다. 그래서, 우리는 필요한 모든 백엔드 작업을 할 시간을 할애하고, 동시에 재미있는 프론트 엔드 쪽 일도 하기로 결정을 했습니다. 우리는 편법으로 가지 않을 것이며 그런 편법은 울타리 밖으로 던져버리겠습니다. 우리는 정말로 멋진 새로운 컴파일러를 만들기를 원합니다. 여러분도 그러리라 생각합니다.

델파이 컴파일러는 변화의 시점에 서 있습니다. 그리고 이 변화의 시점은 우리에게(그리고 궁극적으로는 여러분에게) 중요한 의미를 가진 전환점을 만들 기회를 가져다줄 것으로 보입니다.

정리하자면

그럼, 여기서 요점은 무엇일까요? 요점을 정리하자면(드디어!) - 새로운 백엔드와 64비트 컴파일러에 대한 상당한 주요 컴파일러 작업이 진행되고 있는 지금이 새로운 컴파일러 아키텍처로 전환을 시작할 좋은 시기라고 생각됩니다. 우리는 델파이의 64비트 버전이 2010년 중반에 준비가 될 것으로 예상하고 있습니다. 컴파일러는 완전한 64비트 제품에 있어 첫번째 단계이므로, 우리는 2009년 중반에 64비트 컴파일러의 프리뷰 버전을 발표하여 여러분들 중에서 너무나도 64비트 델파이를 보고 싶어하는 분들이 더 일찍 시작할 수 있도록 할 계획입니다.

우리는 이것이 변화라는 것을 알지만, 이런 작업이 바람직한 방법을 선택해서 델파이를 최첨단 언어 기술의 자리에 유지시켜줄 대단히 멋진 변화를 만들어내는 시간을 들일 만한 가치가 있다고 우리는 믿습니다(또한 여러분도 동감하기를 바라고 있습니다) 일단 우리가 새 컴파일러를 개발할 시간을 가지게 되면, 그 시간 동안 수많은 멋지고 새로운 기능들을 추가할 수 있게 될 것입니다. 그리고 여러분 개발자들은 멋지고 새로운 것들을 좋아합니다. 그렇지 않습니까?

결론

델파이는 앞으로 나아가야 합니다. C++빌더는 앞으로 나아가야 합니다. 우리의 컴파일러는 앞으로 나아가야 합니다. 앞으로 나아가기 위해서는, 컴파일러에는 최근의 개발자들이 요구하는 새로운 기능들이 추가되어야 합니다. 두 언어 모두 여러분이 현재 그리고 미래에 기대하는 해결책들을 제공해야 합니다. 이런 새로운 기능들을 만들어내기 위해서는, 옛 속담에서처럼 오믈렛을 만들기 위해서는 달걀을 깨어야 합니다.

하지만 여러분 개발자들은 작업을 계속해야 할 수십조 이상의 코드 라인들을 가지고 있습니다. 우리도 잘 알고 있습니다. 그래서, 우리는 "새 델파이"와 새로운 컴파일러 아키텍처를 만들어내려는 작업을 진행하고 있으며 여러분의 기존의 코드가 계속 동작하도록, 델파이와 C++빌더로 64비트 바이너리를 만들어낼 수 있도록, 그리고 아마도 몇가지 다른 종류의 바이너리도 만들어 낼 수 있도록 할 것입니다. 그리고 이런 모든 작업들은 제대로 하여 제대로 동작하도록 할 것입니다.

이해가 되시는지요. 이것이 정확히 우리가 하려고 계획한 것입니다.


원문: http://dn.codegear.com/article/39290