아... 무척 지치는군요.

오전에는 공통세션으로 2개의 세션이 진행됐고 오후에는 A,B 둘로 나뉘어서 4개의 세션, 저녁 6시30분부터는 Delphi Hour in Tokyo가 진행됐습니다. 전세계 인터넷 생중계 ^^
총 11개 세션이 진행된거군요. 저는 총 6개 세션이 들어갔습니다.

결론부터 얘기하면 한두가지 건진것도 있고, 희망적인 얘기도 들었고, 우려스러운 얘기도 들었고, 실망스러운 세션도 있었습니다.

아마도 닉호지스가 진행한 공통세션 및 ASP.NET 2.0을 이용한 웹 어플리케이션 개발은 한국에서 열린 세미나와 거의 일치하리라 봅니다.

오늘 세미나는 대체적으로 커뮤니티 대표로 나온 사람들이 진행한 세션들이 알맹이가 없었습니다.
C++빌더 세션으로는 wxWidgets기반 개발에 대한거였는데 솔직히 왜 코드기어 행사에서 그걸 다루는지 이해가 안 되더군요. 단지 상용으로 판매되는 C++빌더 플러그인인 TwinForms 솔루션을 이용해서 빌더에서 wxWidgets 프로그램을 만들 수 있다는걸 보여주고 싶었던 것 같은데 뭔가 주객이 전도된 듯한 느낌이 드는 데다가 프리젠테이션 자료도 별 알맹이가 없고, 필요하면 직접 찾아보면 되겠다 싶어서 코드기어의 Ruby개발툴인 3rd Rail 세션으로 이동했습니다만... 3rd Rails는 구경도 못하고 Java랑 Ruby얘기만 실컷 들었네요. -_-...
연사가 From Java to Ruby라는 책을 일본어로 번역한 친구였습니다. 아마도 제가 참여하지 않은 첫번째 공통세션에서 대충 데모가 있었던 것 같은데... 결국 전 구경도 못했네요.

Delphi for PHP도 마찬가지였습니다. 시종일관 LAMP(Linux + Apache + MySQL + PHP) 얘기만 하다가 Delphi for PHP를 쓰면 좋겠더라... 얘기 한 번 하고 나머지는 MySQL 칭찬... 물론 같은 시간에 Interbase세션이 진행되고 있었습니다만... 그 친구는 대체 왜 나왔는지 모르겠더군요. 역시나 Delphi for PHP는 구경도 못했습니다.
단지 흥미로운 몇가지 통계치는 있었습니다. WebServer분포 - Apache: 73.62%, IIS: 19.40%

일본인이 나와서 하는 세션중 하나 괜찮았던건 RTL 컴파일하기...
즉, Rad Studio에 있는 RTL 소스를 이용해서 RTL을 새로 컴파일 하는 방법에 대한거였습니다. Delphi의 경우 Release Build와 Debug Build의 두가지 버전의 RTL 및 VCL이 기본 포함돼 있기 때문에 자기가 직접 RTL 및 VCL소스를 수정해서 사용하는 경우가 아니면 다시 컴파일 할 일이 별로 없지만 빌더의 경우는 Release빌드만 포함돼 있기 때문에 DEBUG옵션을 줘서 재컴파일 한 뒤 디버깅에 활용할 수 있는 꽤 괜찮은 내용이었습니다.
의외로 방법은 간단하더군요.
빌더는 source\cpprtl로 이동해서 path에 tools 폴더 추가하고 (path %path%;%cd%\tools) build.bat를 실행하는걸로 끝입니다. 디버깅 할땐 set DEBUG=1 하고 나서 build하면 됩니다. 컴파일 시간은 꽤 오래 걸리더군요. RTL만 10분 이상 걸립니다.
델파이는 source\win32\rtl 경로에서 mkdir lib 해서 lib폴더 수동으로 만들어준 후 make. 디버깅옵션으로 할땐 set debug=1 하고 난 뒤 make -B
컴파일 속도 죽이더군요. RTL전체 컴파일 하는데 체감상 10초도 안걸린거같습니다.
의외로 재밌는 내용이 많아서 꽤 위로가 됐습니다.

오전에 공통세션 끝나고 나서 닉호지스한테 가서 '아까 발표중에 티뷰론의 유니코드 지원을 위한 스트링 클래스를 만들고 있다고 했는데 그게 WideString이 아니라 새로 개발되는거냐' 물었더니... 그렇답니다. 역시 Reference 카운터가 없어서 발생하는 WideString의 메모리 복사 문제는 코드기어측도 제대로 인식하고 있더군요. 이 시점에서는 무척 기분이 좋아졌습니다만...
오후 6시30분부터 진행된 Delphi Hour에서 일본친구가 비슷한 질문을 했고, 현재 Unicode쪽 개발에 참여중인 일본인 개발자가 직접 나와서 그 부분에 대한 답변을 했는데... 현재 여러가지를 시도하고 있다고 하더군요. 옵션에 따라 String이 AnsiString 또는 새로 개발되는 UnicodeString으로 전환이 되는걸 시도하는데 뭐 여러가지 문제가 있답니다. 그래서 생각중인게 AnsiString을 수정해서 CharSet을 추가로 저장하도록 하는걸 연구중이랍니다... 오마이갓....
아... 무지 걱정됩니다. 시도하고 있다는 두가지 방법 모두 너무 위험해 보입니다.

Unicode기반으로 프로그램을 많이 작성해 보신 분들은 아시겠지만... Unicode기반이라고 해서 AnsiString이 필요없는게 아닙니다. 프로그램 내부에서는 대부분 UCS2로 데이터가 유통되지만 외부 입출력, 혹은 네트워크를 경우하는 데이터는 UTF-8, ANSI 등 다양한 방식을 쓰기 마련인데... 이런 경우는 당연히 AnsiString이 다루기 쉽죠.
제가 선호하는 Unicode구현방식은... 새로운 UnicodeString 클래스는 BSTR을 고려하지 않는 AnsiString과 비슷한 구조의 Reference count를 지원하는 UCS2 기반. 기존 WideString버전, AnsiString버전이 따로 존재하는 함수는 모두 UnicodeString버전으로 통합, VCL Control은 전부 UnicodeString기반으로 대체, 그러나 AnsiString은 그대로 사용 가능한 형태... 입니다만...
물론 영어권 사용자의 반발이 예상됩니다. 하지만 메모리를 두배 차지하는 대신 성능면에서는 월등해집니다. AnsiString처럼 Leading / Trailed byte계산이 필요 없기 때문에 그만큼 구조가 단순해지죠.

아무래도 내일부터라도 Unicode지원방식에 대해서 제 의견을 구체적으로 정리해서 적어봐야겠습니다. 영어로 번역해서 코드기어로 보내볼랍니다. 답답하네요. 제발이지... AnsiString 개조해서 처리하는 방법만큼은 안했으면 합니다. AnsiString 걸레됩니다. 성능은 성능대로 떨어지고 쓰기는 불편해지고... 코드기어에서 이번만큼은 좀 과감한 결정을 내렸으면 좋겠는데...

기분 꿀꿀합니다.