얼마전의 C++빌더 로드맵에 이어, 엠바카데로 일본 지사에서 며칠 전 개최된 '디벨로퍼 캠프' 행사에서, 델파이/C++빌더 XE3 버전에 대한 좀 더 구체적인 정보들이 흘러나왔습니다.

이 행사에서 나온 정보들 중, 가장 핵심적이고 놀라운 것은, 델파이와 C++빌더의 컴파일러가 LLVM 기반으로 바뀐다는 것입니다. 이건 델파이와 C++빌더, 아니 터보 파스칼과 터보 C 이래 가장 큰 사건입니다. 왜 그런지 알아보시죠.

아래는, 일본 개발자 한분이 블로그에 올린 글을 구글 번역기로 돌린 후 문맥을 손본 내용입니다.

Owl's perspective: 第22回エンバカデロ･デベロッパーキャンプ(東京)まとめ
http://owlsperspective.blogspot.kr/2012/06/embarcadero-devcamp-22-tokyo-summary.html

---

2012 년 6 월 7 일
제 22 회 엠바카데로 디벨로퍼 캠프 (도쿄) 정리

제 22 회 엠바카데로 디벨로퍼 캠프 (도쿄)의 개인적인 요약입니다. 또한 아래의 내용은 보증하는 내용이 아니므로 주의하시기 바랍니다 .
[G1] 키노트 세션 "엠바카데로 2012년 제품 전략"

2011년 실적은 호조로 매출 10 % 성장하여 약 75 억 엔. 보유 자금이 넉넉하다.

2012년 이후를 위한 3 가지를 생각하고 있다.
기존 제품 : RAD Studio XE3, ER / Studio ㅖPortal
인수 : 자금적인 여유가 있고, 경기 침체로 인해 상대적으로 저렴하게 인수를 할 수 있기 때문에 연내에 1~3 개 정도의 인수를 목표로 하고 있다.
AppWave

2012년 제품 계획
차세대 컴파일러 아키텍처
LLVM을 기반으로, 델파이 F/E 또는 C++ F/E (= Clang + PME) → LLVM IR → LLVM Intel / ARM / Other CPU Code Gen 하는 구성에서 컴파일러를 다시 구축. (컴파일러의 프론트 엔드, 백 엔드에 대해서는 wikipedia 컴파일러의 설계 섹션 참조)
XE3
Delphi / C++ : iOS에 네이티브 대응
C++Builder : x64 지원
FireMonkey : Hyper-Real 3D UI, 홀로 그래픽 3D UI
HTML5 : 비주얼 HTML5/CSS3 클라이언트 개발 - Delphi / C++Builder / RadPHP

C++Builder 2012 로드맵
64bit 툴 체인 : IIS 쉘 확장, SQL Server 인터페이스, 64bit 디바이스 드라이버
C++11 : Boost 및 ACE 에 대응
ARM : iOS / Andriod 지원 ARMv7 바이너리 출력 FireMonkey 장치 (GPS, 가속도계 등의 센서)에 대한 기본 지원
일정 :
현재 베타 1, 곧 베타 2가 시작
2012 년 하반기 (Q3) : C++11, x64 Hyper-Real Holographic (HRH)
2013 년 초 : ARM iOS / Android

ER / Studio
데이터 거버넌스, 모델 간 추적
메타데이터 소셜라이즈
Social Portal
최대 경쟁 업체인 CA(ERWin)이 올해부터 일본어 지원을 종료하기 때문에 기회로 생각하고 있다. (주: 사실 여부는 확인되지 않음)

AppWave : 올해도 적극적으로 버전 업을 진행

[T2]​​ Delphi / C++Builder 기술 세션 "RAD Studio 차기 버전 미리보기 - 64 bit화를 추진 C++Builder"
C++Builder
C99 , C++11 표준 준수도 향상
LLVM 기반 (베타 1에서는 아직 x64 전용)
ARM에서는 GDB 디버깅하게 된다
STL (Dinkumware) Boost (BoostPro), ACE (ADAPTIVE Communication Environment), CORBA (TAO)를 지원할 예정
Windows x64, iOS (뮬레이터 장치), Android

Delphi XE3
FireMonkey 강화
작업 목록
제스처
앵커
레이아웃 매니저
Audio / Video : DirectShow / QuickTime
물리 엔진
Indy for iOS
dbExpress for iOS
FPC 베이스에서 LLVM 베이스로 마이그레이션

C++11 : C++에서 추가된 유용한 기능 소개 - auto의 형식 유추 와 lambda 등

[T3] Delphi / C++Builder 기술 세션 "FireMonkey 클래스"
FireMonkey 프로그래밍의 데모 관련 정보:
Team Japan≫개발자 캠프 FireMonkey3D 애플리케이션 프로젝트 for Windows / MacOSX
Embarcadero Discussion Forums : OSX 애플리케이션 종료 처리 코드

[T4] Delphi / C++Builder 기술 세션 "애플리케이션 비대화, 팀 구성원 증가 등의 프로젝트 확대, RAD 환경에서 어떻게 대응할 것인가?"
정리도 두서도 없는 패널 토론. 좀 더 교육이 필요하지... 문서·지역 관리자 아라이 씨의 엠바카데로 테크놀로지 내부 개발 과정의 해설도 있어, 이쪽은 여러가지 재미있는 이야기였습니다.

여기서 이야기가 나왔던 FireMonkey   (일본어 문서 wiki)에 대해서는, Delphi에서 빌드하는 방법을 모처 씨가 쓴 블로그 글들이 있습니다.
모처 - Delphi에서 Jenkins을 사용하려면 (1)
모처 - Delphi에서 Jenkins을 사용하려면 (2)
모처 - Delphi에서 Jenkins를 사용하려면 (3)
모처 - Delphi에서 Jenkins을 사용하려면 (4)

[G5] Q & A 세션 "아무거나 질문! 엠바카데로에게 물어보자"
엠바카데로 테크놀로지 전세계 매출에서 일본의 매출 비율은 8 % 정도.
Clang / LLVM은 아마도 오픈소스 프로젝트부터 포크하여 독자적인 버전이 될 것. (그런 뉘앙스로 발언)
PC에서 IDE의 점유율은 Microsoft가 80%, Embarcadero가 10%, 그 이외가 10% 정도라고 파악하고 있다.
(이하 생략)

---

여기서 F/E라고 쓰인 것은 컴파일러의 프론트 엔드(Front End)를 말합니다.

위에서 LLVM이란, 여러 언어 컴파일러의 집합체이자 버추얼머신, 그리고 JIT 컴파일러로 이루어진, '컴파일러 인프라스트럭처' 입니다. 여기에 포함된 프로그래밍 언어들은 LLVM을 위한 중간 언어(LLVM IR)로 컴파일되고, 이것을 각 OS 플랫폼별로 다시 컴파일하여 네이티브 코드가 나옵니다.



즉, 위 본문에서 말하는 컴파일러 프론트 엔드란 1차적인 언어 컴파일러로서 LLVM IR 코드를 만들어내는 역할을 하고, 이것을 OS별 네이티브 바이너리로 컴파일해내는 것이 백 엔드입니다. 또 위에서 거론되는 Clang은 LLVM의 C/C++/Objective C 프론트엔드입니다.

LLVM 홈페이지에 따르면 현재 LLVM에는 파스칼이 포함되어 있지 않으므로, 엠바카데로는 LLVM에 독자적으로 델파이 컴파일러를 구현하고, 그렇게 완성된 엠바카데로 버전의 LLVM에서 C++빌더와 델파이 양쪽의 프론트 엔드를 통해 IR 코드를 생성하고 다시 OS별 네이티브 코드를 컴파일해내는 방식으로 가려는 것으로 보입니다. 이렇게 되면 C++빌더와 델파이의 경계가 전보다도 더욱 모호해지겠습니다.

(LLVM은 현재 자바와 포트란도 지원하므로, IDE나 라이브러리와의 연동만 해결한다면 Delphi for Java나 FortranBuilder 같은 것도 가능하겠군요. -.-;;)

또한, Clang을 통한다고 한 것을 보면, 기존의 오랫동안 유지되어온 터보 C, 볼랜드 C++ 계보의 컴파일러 자산을 포기하고 Clang으로 대체하려고 하는 것으로 보이네요. 약속했던 C++11, C99 지원도 기존의 볼랜드 C++ 컴파일러가 아닌 Clang이 지원하는 기능에 의존하는 듯 합니다. 마찬가지로, iOS나 안드로이드 지원도 엠바카데로의 자체 구현이 아니라 이런 LLVM의 기능에 기대어서 구현될 것으로 보이구요.

이런 변화는... 한마디로 말하자면, 개발툴의 심장을 갈아치우는 대작업입니다. 델파이와 C++빌더의 컴파일러는, 1980년대초 이후로 30년 가까이 업그레이드되면서 개발자들과 함께 해온, 역사 그 자체이면서 아이덴티티이기도 했는데요. 이런 엠바카데로의 대변신이, 어떤 결과를 가져올지... 개인적으로는 믿어보려고 노력을 해도, 기대보다는 불안감이 더 크게 다가오는 것이 솔직한 심정입니다.

또... LLVM이 최종 바이너리를 OS별 네이티브로 내놓는 것은 틀림없는 사실이지만, 전통적으로 우리가 알고 있는 네이티브 컴파일러와는 거리가 상당한 것도 부인할 수 없는 사실입니다. LLVM이 최적화가 대단해서 LLVM에서 만들어낸 바이너리 코드가 오히려 전통적인 네이티브 바이너리보다 더 빠를 수도 있다는 얘기들도 있지만, OS에 중립적인 중간 코드를 거쳐온 네이티브 코드가, 정말로 해당 OS와 해당 CPU 아키텍처를 제대로 활용하는 네이티브로서 최적으로 동작할지에 대해서는, 아무리 생각해도 의문스럽습니다. 자바나 자바스크립트 등 언어의 입장에서는 LLVM 코드의 성능이 놀라울 정도로 빠를 수 있겠지만, 이전부터 최고의 네이티브 성능을 자랑해온 델파이나 C++빌더에서도 과연 그럴까요.

물론, 엠바카데로가 LLVM을 지금의 디폴트 오픈소스 버전보다 얼마나 더 발전시키느냐도 중요한 변수입니다. 수십년간 발전시켜온 귀중한 자산을 뒤로 하고 오픈소스로 심장을 갈아치우겠다는 결심을 했으니, 엠바카데로의 개발팀들도 각오가 비장하리라 생각됩니다. 아무쪼록, 멋진 제품으로 만들어내서 이런 우려들을 불식시켜주길.