Imp: Delphi/C++Builder Evangelist

Delphi/C++Builder 2010의 설치 프로그램을 실행하면, 설치 프로그램의 초기 화면도 뜨기 전에 위의 첫번째 이미지와 같이 "'' is not a valid integer value"" 라는 에러가 나는 경우가 간혹 있습니다. 그런 후 '확인'을 누르면 위의 두번째 이미지처럼 Access Violation 에러가 다시 발생합니다.

이런 경우가 자주 발생하는 것도 아니고, 아주아주 드물게 한건씩 발생하는데요. 최근에 다시 이런 경우가 있어서 추적하다가 원인과 해결책을 알아냈습니다.

이것은, 설치하려는 PC 설치했던 프로그램들 중 하나가, CD의 AutoRun 기능을 동작하지 않도록 하기 위해 일부 개발자들이 레지스트리의 해당 항목을 아예 막아버리는 편법을 사용했기 때문입니다. 따라서 이런 문제가 발생할 때는, 레지스트리에서 해당 AutoRun을 막은 곳을 찾아 지워버리면 제대로 설치가 되게 됩니다.

먼저, 레지스트리 에디터(regedit.exe)를 실행시키고, 아래의 키를 찾아갑니다.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion \IniFileMapping\Autorun.inf
위의 키가 존재하고, 그리고 그 (기본값)이 @SYS:DoesNotExist 이런 식으로 지정되어 있다면 이 케이스에 해당합니다.
 
이 Autorun.inf 키 자체를 삭제해버리시고, 윈도우를 재부팅하신 후, 다시 설치를 시도해보시면 잘 되실 겁니다. (원래 이 Autorun.inf 키가 존재하지 않는 것이 디폴트입니다)

델파이나 C++빌더를 실행했을 때, IDE가 실행되지 않고 대신 기본 웹브라우저에서 "How to Buy" 페이지만 덜렁 뜨는 경우가 있습니다.

이 증상의 원인은 세가지가 있는데요.

1. FSecure 안티바이러스 프로그램의 오작동인 경우 (가장 흔함)
2. 디지털 인증서가 잘못된 경우
3. 트라이얼의 날짜 제한이 만료된 경우

이런 증상을 만나게 되면, 아래 링크한 페이지를 참고하시면 됩니다.
http://support.embarcadero.com/article/40400
(조금 전에 엠바카데로 본사 Support 사이트에 번역해서 글입니다)

최근에 문의받은 내용인데... 스캐너에서 스캔받은 이미지를 델파이 프로그램에서 직접 받으려면 어떻게 할까요, 하는 내용이었습니다. 검색해보니 스캐너 연동을 위한 금방 쓸만한 무료 서드파티 컴포넌트가 있었는데요. Delphi Twain이라는 컴포넌트입니다. (여기서 TWAIN이란 스캐너를 연동하기 위한 표준 인터페이스 및 그 드라이버를 말합니다)

실제로 테스트해보니, 간단한 하나의 컴포넌트만으로 현재 PC에 연결된 스캐너를 동작시키고 그 이미지를 TPicture 객체로 받아와 폼 위의 TImage 컴포넌트에 표시할 수 있었습니다. 고급 설정 기능들도 있는데, 그것까지는 다 테스트해보지 못했구요.

다만, 이 컴포넌트가 2004년에 마지막으로 업데이트된 관계로, 델파이 2010이나 2009등에서는 제대로 컴파일이 되지 않습니다. 그래서, 델파이 2010에서도 컴파일 및 설치가 되도록 코드를 조금 수정했습니다. 아울러 원래 소스는 C++빌더에서 지원하지 않는 델파이 문법을 일부 사용하여 C++빌더에서 컴파일이 안되었는데, 그 부분도 수정했으므로 C++빌더에서도 설치가 가능합니다.

아래 첨부 파일을 다운로드하시면 됩니다.

지난 11월에, 델파이 및 C++빌더의 2010, 2009 버전의 VCL for the Web에서 한글이 깨지는 문제의 긴급 해결책에 대해 안내해드렸었는데요.
http://blog.devgear.co.kr/imp/entry/VCL-for-the-Web에서-한글-깨짐-문제

바로 며칠 전에 VCL for the Web의 벤더인 Atozed에서 이 문제를 해결한 IntraWeb 10.0.21 버전을 내놓았습니다. 아래의 링크에서 다운로드를 받으실 수 있구요.
http://www.atozed.com/Intraweb/Download/Download.EN.aspx

설치 프로그램을 다운받아 설치하려고 하면 라이선스 키를 입력하라고 나오는데요. 아래의 링크를 참고해서, 메일로 요청해야 합니다. (키를 안넣고도 설치를 할 수 있지만, 그러면 평가판 모드로 설치가 됩니다)
http://www.atozed.com/Intraweb/Download/FreeKeyRequest.EN.aspx

요청하는 데에 특별한 조건이 있는 것은 아니고, 사용중인 델파이/C++빌더의 버전, 회사 이름, 개발자 이름 정도만 써서 키를 요청하면 됩니다. 예를 들면 저는 아래와 같이 무성의하게 메일을 보냈습니다.

제목: IntraWeb 10.0.21 Free Key Request
내용:
Hello,

Would you please send me IntraWeb 10.0.21 key?

Version : RAD Studio 2010 Architect
Developer Name: 개발자이름
Company Name: 회사이름

한가지 주의할 점은, 이렇게 요청해서 받은 키는 모든 델파이/C++빌더 버전에 대한 키가 아니라 요청한 한가지 버전만 적용되는 키라는것입니다. 설치 프로그램에서는 델파이/C++빌더의 모든 버전이 선택되어 있는데, 요청했던 버전 하나만 선택해야 키를 입력했을 때 다음으로 넘어갈 수 있습니다.

그냥 이 업데이트를 설치한 상태로는 그대로 한글이 깨지구요. 지난번에 알려드렸던 대로 UTF8ContentParser 유닛을 uses 해줘야합니다. 다만 이번에는 UTF8ContentParser.pas 유닛이 기본으로 포함되어 있어서 별도로 다운받아 복사해줘야 하는 불편은 덜었네요.

이 업데이트를 설치하고 나면 파일 업로드에 필요한 TIWDBFile 컴포넌트를 사용할 수 없습니다. 아마도 벤더인 Atozed에서 아직 파악을 못하고 있는 듯 한데, 레포트하도록 하겠습니다.

일반적으로, DLL에 포함된 루틴을 호출하는 방법은 정적 로딩(Static Loading)과 동적 로딩(Dynamic Loading)이 있습니다.

정적 로딩이란 DLL 내의 루틴을 호출하기 위해 해당 루틴의 임포트 선언을 하고 사용하는 방법이죠.

procedure ProcInDll; external 'DLL입니다용.dll';

이렇게 임포트 선언을 하게 되면, 해당 DLL은 현재 프로그램이 실행되는 즉시 프로세스로 로딩됩니다. 이 방법의 좋은 점은, 코드가 아주 간단하고, 이렇게 dll의 루틴들을 모두 모아 라이브러리 목적의 유닛으로 만들어두면, 해당 유닛을 uses하기만 하면 마치 메인 프로그램 소스 내의 함수인 것처럼 편하게 호출할 수 있다는 거죠. 실제로 VCL의 Windows.pas나 ShellAPI.pas처럼 Win32를 그대로 번역한 유닛들이 이런 파일이어서, 우리는 델파이에서 Win32 API를 껌씹듯이 쉽게 호출해댈 수 있습니다.

하지만 이 정적 로딩 방법에는 중요한 단점이 하나 있는데... 프로그램이 시작될 때 해당 DLL을 로드하기 때문에, 만약 해당 DLL이 없거나 DLL 안에 해당 루틴이 없을 경우 프로그램이 아예 시작되지를 못한다는 것입니다. (이런 경우를 많이 접해보셨을 겁니다) 또, 프로그램이 시작될 때 DLL을 몽땅 다 로드해버리기 때문에 당장 쓰지도 않을(경우에 따라서는 아예 호출하지도 않을 수도 있는) 루틴들을 위해 무시할 수는 없을 정도의 메모리가 소요된다는 거죠.

DLL의 동적 로딩이란, 프로그램이 시작되는 동안이 아닌, 프로그램의 코드 내에서 LoadLibrary/FreeLibrary와 GetProcAddress 등의 함수를 이용해서 코드로 일일이 DLL을 로드하고, 그 DLL에서 해당 함수의 주소를 찾고, 그 주소를 함수 포인터로 해서 해당 함수를 호출하는 절차입니다.

TProcInDll = procedure;

var
  Handle: THandle;
  AProcInDll: TProcInDll;
begin
  Handle := LoadLibrary('DLL입니다용.dll');
  if Handle<>0 then
  begin
    @AProcInDll := GetProcAddress(Handle, 'ProcInDll');
    if @AProcInDll<>nil then
      AProcInDll;
  end;
  FreeLibrary(Handle);
end;

정적 로딩 방법에 비해 동적 로딩 방법의 단점은, 위 코드에서 바로 눈에 보이시죠. 코드가 복잡하고 까다롭다는 겁니다. 대신, 해당 DLL이 없거나 DLL 안의 루틴이 없더라도 당장 프로그램이 아예 뜨지도 않는 경우는 발생하지 않는다는 거죠. 물론 기대했던 DLL이 없다면 난감하겠지만, 위의 코드에서처럼 에러 체크를 통해 적어도 뭔가 대책을 세울 수 있는 가능성이 생깁니다. 또, 필요한 경우에만 DLL을 로드하기 때문에 메모리도 적게 먹습니다.

정적 로딩과 동적 로딩 사이에 장단점이 너무나 명확하죠. 그러면... 동적 로딩과 정적 로딩 사이에서 장점만 취할 수 있는 방법은 없을까요? 정적 로딩에서처럼 간단하게 임포트 선언만 하면서도, 프로그램 실행시에 무조건 바로 DLL을 로드하지는 않고 실제로 필요할 때 DLL을 불러들이면 되겠죠.

별로 알려지지 않았지만, 델파이 2010에서 바로 이 기능이 추가되었습니다. 지연 로딩(Delayed Loading)이라는 것으로, delayed라는 지시어가 추가되어 가능해졌습니다. 위의 정적 로딩에서 임포트 선언의 뒤에 delayed만 추가하면 된다는 거죠.

procedure ProcInDll; external 'DLL입니다용.dll' delayed;

정적 로딩 방식과 똑같은 임포트 선언에 delayed 지시어가 추가되었을 뿐입니다. 이렇게 delayed를 추가해주면, 프로그램 시작시에 바로 로딩되지 않고 실제로 해당 프로시저/함수가 호출될 때 비로소 DLL을 로드하고 루틴을 임포트합니다. 그래서 지연 로딩, delayed인 거죠.

당장 델파이 2010의 Windows.pas나 ShellAPI.pas 등등에는 2009 버전까지는 보이지 않았던 수없이 많은 함수들이 이 delayed 지시어와 함께 임포트 선언으로 추가되어 있는데요. 이 함수들은 윈도우 7, 윈도우 비스타, 윈도우 XP 등 특정 버전 이상에서 추가된 함수들로서, 그보다 낮은 윈도우 버전에서는 존재하지 않았던 함수들입니다. 그래서 API 지원이 훨씬 풍부해졌죠.

그러면, 해당 DLL이나 함수가 존재하지 않을 경우, 어떻게 대응을 해야 할까요? 해당 DLL이나 함수가 존재하지 않아 불러들일 수 없는 경우 EExternalException 예외가 발생합니다. 따라서, 동적 로딩에서 리턴 값을 체크해서 함수의 존재 여부에 따라 처리하는 것과 마찬가지로 try except 블럭으로 EExternalException 예외를 처리하면 깔끔하게 되겠죠.

그렇다고 동적 로딩을 사용하는 모든 경우를 지연 로딩으로 커버할 수는 물론 없습니다. 지연 로딩에서 프로그램 시작 이후 DLL 함수가 호출될 때까지는 DLL이 메모리에 로드되지 않지만, 일단 호출된 후에는 해당 DLL이 언로드되지 않고 계속 메모리에 머무르게 됩니다. 극단적으로 효율적인 메모리 운영이 필요하다면 언제든 DLL을 언로드할 수 있는 동적 로딩을 따라갈 수는 없죠.

또, 동적 로딩의 경우에는 DLL 이름과 함수 이름을 문자열로 취급하므로 메인 프로그램이 사전에 알지 못하는 DLL이나 함수도 호출이 가능하지만 정적 로딩과 지연 로딩에서는 컴파일 시점에 고정되는 이름만 지원할 수 있으므로, 업무 개발 프로젝트에서처럼 사전에 프로그램에서 알 수 없는 많은 DLL들을 쓰는 경우를 지원할 수 없게 됩니다.

성능 면에서는 어떨까요. delayed를 불필요하게 너무 남발하면 정적 로딩에 비해 프로그램의 성능을 떨어뜨릴 수도 있습니다. 반면 한번 호출되어 로딩된 DLL은 메모리에 계속 상주하게 되므로 이런 면에서는 매번 LoadLibrary, GetProcAddress를 호출해야 하는 동적 로딩보다는 속도가 빠르게 되죠. 결국 개발자가 정적 로딩, 지연 로딩, 동적 로딩을 적절히 잘 배합해서 사용하는 것이 좋습니다. 실제 VCL 코드에서도 이 세가지가 잘 배합되어 사용되고 있죠.

지연 로딩에 대한 좀 더 자세한 내용은, 엠바카데로의 앨런 바우어의 블로그에서 보실 수 있습니다.
http://blogs.embarcadero.com/abauer/2009/08/25/38894
http://blogs.embarcadero.com/abauer/2009/08/29/38896
http://blogs.embarcadero.com/chrishesik/2009/11/02/35056

아래 JEDI 블로그에서는 조금 더 테크니컬한 내용들을 보실 수 있습니다.
http://blog.delphi-jedi.net/2009/08/29/version-checking-for-delphi/

올해 말, 그러니까 2주 정도 지나고 나면 델파이 2005를 비롯한 그 이하 버전들은 델파이/C++빌더 2010으로 업그레이드 할인을 받을 수 없게 됩니다. 구버전이 있어도 신규사용자용(New User) 제품을 구입해야 하죠. 이미 여러 차례 뉴스레터가 나갔기 때문에 대부분 아실 겁니다. 10월 말에 여기 블로그에도 썼었구요.
http://blog.devgear.co.kr/imp/entry/DelphiCBuilder-2005-이하-업그레이드-할인은-연말까지만

엔터프라이즈 에디션을 기준으로 할 때, 업그레이드 할인 가격은 신규사용자용 제품 가격의 70% 정도입니다. 그러니까, 구버전을 가지고 있으면서 내년에 델파이/C++빌더 2010을 구입할 계획이라면 빨리 서둘러야 합니다.

그런데, 2010 버전이 아니라 만약 내년에 출시될 차기 버전을 기다리는 경우라면? 참고로 말씀드리면, 올해의 경우 델파이/C++빌더 2010은 8월 말에 발표되었는데요. 차기 버전에서는 MacOSX, 리눅스, 아이폰 버전까지 같이 개발중이기 때문에 올해 발표 시기보다는 조금 정도는 늦어질 가능성이 높습니다. 그래서 빠르면 2010년 가을, 늦으면 2010년 말 정도에 발표된다고 보고 있습니다. (더 늦어져서 해를 넘길 가능성은 거의 없습니다)

참고로, MacOSX, 리눅스, 아이폰 버전의 경우, 본사의 전략에 따라, 현재의 윈도우 버전 델파이/C++빌더와 통합 패키징되어 판매될 수도 있고 아니면 별도 제품으로 분리될 수도 있습니다. 이건 완전히 전략 상의 문제인데... 제 개인적으로는 별도 제품으로 분리될 가능성이 좀 더 높지 않을까 생각됩니다.

어쨌든... 내년에 발표될 2011 버전에서 개선될 기능들도 많을 것이기 때문에, 내년으로 제품 구입을 미루는 것은 뭐 있을 수 있는 일입니다. 그런데, 구버전 업그레이드 할인이 올해 말로 종료되기 때문에, 구입 전략을 바꿀 필요가 있습니다.

개발툴 구입과 함께 구입할 수 있는 옵션으로, SA, 혹은 메인터넌스가 있습니다. 이 메인터넌스를 구입했을 때의 혜택은 두가지인데요. 첫째는 기술 지원을 제공한다는 것이구요. (원래 미국과 유럽 등 해외에서는 개발툴 구입에 대해 기술지원이 제공되지 않지만 저희 데브기어에서는 개발툴 구입만 해도 기술지원을 제공하기 때문에 이 첫번째는 큰 의미가 없습니다) 두번째는 지정한 기간 동안(통상 1년) 출시되는 신규 버전을 무료로 업그레이드를 제공한다는 것입니다. 다시 말해, 지금 메인터넌스를 함께 구입하면 내년 2011 버전도 무료로 받을 수 있습니다.

이 메인터넌스 옵션은 1년 기준으로 할 때 가격이 신규사용자용 제품 가격의 30% 정도입니다. 30%라는 가격 설정은 본사에서 한 것인데, 아주 전략적이죠. 업그레이드의 할인 가격이 70% 가격이니까, 개발업체가 매 2년마다 한번씩 업그레이드를 하려고 한다면, 30%+30%니까 60%가 되죠. 그러니까 업그레이드 단품을 구입하는 것보다 10% 싸면서도 중간의 한 버전도 빼지 않고 다 사요할 수 있게 되는 겁니다. 다시 말해, 2년마다 업그레이드하려고 한다면 메인터넌스 옵션이 가격면에서도 혜택 면에서도 더 유리합니다.

그런데, 올해 말까지로 구버전의 업그레이드가 종료되기 때문에, 여기서 재미있는 부작용이 생겼습니다. 구버전으로부터의 업그레이드 할인을 적용받을 때 가격이 신규사용자용 제품의 70%인데, 메인터넌스 옵션의 가격이 30%이므로, 합치면 신규사용자용 가격과 같아지는 겁니다. 만약 업그레이드를 내년의 2011 버전 출시 이후로 미룬다면 그냥 그때 신규사용자용만 사용하게 되는 거고, 반면 지금 업그레이드하면 같은 가격으로 메인터넌스까지 포함해서 당장 2010 버전을 사용하고 또 2011 버전도 사용할 수 있게 됩니다.

그러니, 지금 2010 버전으로 업그레이드를 망설이다가 내년 2011 버전으로 미루려고 한다면, 그럴 필요가 전혀 없습니다. 지금 구입하면 같은 금액으로 두배의 혜택을 받을 수 있으니까요.

지난 밤 사이에 Delphi/C++Builder 2010의 업데이트 4와 업데이트 5, 그리고 부스트 업데이트가 공개되었습니다. Delphi/C++Builder 2010 프로그램 그룹의 Check for Update를 클릭하여 업데이트를 바로 진행할 수 있구요.


혹은, 아래 링크를 통해 업데이트 파일을 다운받아 직접 설치할 수도 있습니다. (116MB)
업데이트4/5, 부스트 업데이트 다운로드 : http://cc.embarcadero.com/item/27492


업데이트 적용 이후에 빌드 넘버는, 보시다시피 14.0.3615.26342 입니다. 업데이트 이전의 빌드 넘버는 14.0.3513.24210 이었구요. 뭐 굳이 빌드 넘버를 찾아보지 않아도, 그 아래에 설치된 업데이트 리스트가 나오니까 알아보기 쉽죠.

난데없이 갑자기 왜 업데이트 4, 5인지 난감하실텐데, 몇주 전에 업데이트 2, 3가 잠깐 공개되었다가, 등록 문제 때문에 삭제되었기 때문입니다. 이번 업데이트 4, 5는 물론 이전의 업데이트 2, 3의 내용을 모두 포함하고 있습니다.

참고로, 업데이트 1은 지난 9월에 공개되었는데, 라이선스 등록 관련의 심각하지 않은 업데이트였기 때문에 자동 업데이트로 제공되지 않았었습니다. 아래는 당시에 썼던 블로그 글 링크...
http://blog.devgear.co.kr/imp/entry/DelphiCBuilder-2010-업데이트-1-발표

이번에도, 업데이트 4는 일반 업데이트이며 업데이트 5는 데이터베이스 업데이트로 구성되었습니다. 따라서 개별적으로 따로 설치할 수는 있지만, 업데이트 5의 내용이 업데이트 4에 의존하므로 반드시 업데이트 4는 설치해야 합니다. 또한 부스트 업데이트의 경우, 업데이트 4에 의존하므로(C++ 컴파일러가 업데이트되었습니다) 반드시 업데이트 4를 설치한 후에 설치해야 합니다.

아래는 이번 업데이트들에서 픽스된 버그 리스트입니다.
Delphi 버그 픽스 : http://dn.embarcadero.com/article/40204
C++Builder 버그 픽스 : http://edn.embarcadero.com/article/40205/

이번 업데이트들에 대한 자세한 내용은 아래 readme에서 보실 수 있습니다.
http://dn.embarcadero.com/article/40174

아래 글에서는 업데이트 4의 내용에 대해 좀 더 간략하고 친절하게(?) 설명해주고 있습니다.
http://blogs.embarcadero.com/chrishesik/2009/12/14/35072

Delphi/C++Builder의 2009 버전과 2010 버전에서는, VCL for the Web (IntraWeb)에서 한글을 사용하면 한글이 깨져 나오는 버그가 있습니다. 이 버그에 대해 여러 번 문의를 받았는데, 조금 전에 문제 해결 방법을 알아냈습니다.

위 파일을 다운받아 컴파일할 VCL for the Web 프로젝트에 추가해주기만 하면 됩니다. 그러면 언제 그랬느냐는 듯이 한글이 깨끗하게 입력, 출력 됩니다. uses 할 필요도 없고, 단지 프로젝트 추가로 끝입니다.

(추가: 이 파일은 2010 버전에는 기본적으로 포함되어 있으므로, 별도로 다운로드하거나 할 필요 없이, 그냥 소스 내에서 uses에서 추가해주시면 됩니다)

Delphi/C++Builder 2009 버전에서는 IntraWeb의 업데이트된 버전으로 업데이트를 해야 합니다. (2010 버전은 업데이트된 IntraWeb이 포함되어 있어 업데이트할 필요가 없습니다) 위 유닛이 제대로 동작하려면 10.0.15 버전 이상이 필요하며, 오늘 현재 IntraWeb의 최신 버전은 10.0.17 버전입니다. 업데이트된 IntraWeb은 아래 사이트에서 다운로드할 수 있습니다.

http://www.atozed.com/IntraWeb/Download/Files/index.EN.aspx

그리고 아래의 링크에서 Delphi/C++Builder 번들된 IntraWeb을 위한 업데이트 키를 받아야 합니다.
프로페셔널 에디션 - http://purchase.atozed.com/rinok/Edition.aspx?ID=10090
엔터/아키 에디션 - http://purchase.atozed.com/rinok/Edition.aspx?ID=10091

사족...
위의 UTF8ContentParser.pas 유닛은 VCL for the Web의 제작사인 Atozed에서 만든 것이 아니라 엠바카데로에서 만든 것이라고 하는데요. 한두달 전 쯤인 것 같습니다. 그런데 이게 IntraWeb에도 포함되지 않고 엠바카데로에서도 공식적으로 제공되지 않는 이유에 대해서는 잘 모르겠습니다. 본사에 문의를 해보겠습니다만, 일단 (문제가 되기 전까지는) 자유롭게 사용하시기 바랍니다.

많은 분들이 열화처럼 요청하신.. 세미나 자료들입니다.
내용 발표 자체에 쓰인 ppt 문서들과, 보여드린 데모 프로젝트들을 압축해서 올립니다.

여기서 빠진 것이 있는데.. 제가 마지막 세션으로 발표했던 "DataSnap 기반 프레임워크 실례"의 소스가 빠져 있습니다. 그 이유는.. 일단 아직 미완성 버전인데 한두달 정도 안으로 완성시킬 예정이고(담달부터 이걸로 업체에 개발 컨설팅을 들어가기 때문에 무조건 완성시켜야 한답니다), 또 제가 UI 라이브러리로 사용한 Toolbar2000의 라이선스 문제도 있습니다. (Toolbar2000은 완전히 상용도, 그렇다고 프리도 아닌 애매한 라이선스입니다)

그래서, 한두 달 정도만 기다려주시면 좀 제대로 된, 그리고 Delphi와 C++Builder를 사용하는 누구나 무료로 받아서 업무개발에서의 효율을 높일 수 있도록 하는 공개 업무개발 프레임워크로 내놓을 예정이랍니다. 그러니 이 소스를 기다리셨던 분들은 양해 부탁드리겠습니다. 꾸벅~

후아~ 정말 숨가쁜 일정이었습니다. 세미나 두개를 연달아 하니, 숨돌릴 틈이 없더군요. 21일 아침 일찍 대전으로 내려갔다가, 대전에서 하룻밤을 자고 새벽같이 부산으로 출발했습니다. 각각 간단히라도 뒷풀이 한잔씩 하다보니, 어제 밤에 부산에서 버스로 출발한 시간이 밤 11시가 넘어서였고.. 집에 도착하니 새벽 다섯시가 다되어가더군요.

뭐, 며칠 동안 밀린 일들 때문에 집에 도착하자 마자 밀린 일을 시작하기 시작했는데, 그러다보니 버스에서 두어시간 잔거 외에는 전혀 쉬지 못하고 사무실까지 나와서 일하고 있답니다.

뭐 그래도, 몸은 완전히 녹초입니다만, 마음은 보람과 열정으로 가득차 있는 느낌... 그만큼 대전과 부산의 개발자분들이 열정적으로 들어주셨거든요. 물론 아무 말 없이 듣고만 있는 청중들에게 무슨 열정적으로 듣고 말고가 있어? 라고 생각할 수도 있겠지만, 사실 앞에서 몇시간 동안 연달아 소리 높여 설명하는 강사의 입장에서는, 한분 한분의 표정, 자세, 이런 모든 것들에서 큰 차이가 느껴지는데요.

이번 두차례 세미나에서는 개발자분들의 표정이 생생하게 살아있는 것이 피부로 와닿아서, 몸은 많이 피곤한데도 개발자 한분한분의 얼굴에서 바로 느낌이 와닿아서, 심장이 마구 뛰고 머리도 쌩쌩하게 돌아가더군요. 서서 설명하는 동안 내내 저도 참 즐겁게 설명을 했는데, 중간에 쉬는 시간이 되니 온몸이 쑤시더라구요. 그래도 다시 다음 세션에서 설명하면 언제 그랬냐는 듯이 또 즐겁게 설명을 드릴 수 있는 힘이 불끈 불끈 솟아나더군요. ㅎㅎㅎㅎ

사실.. 두번 모두 예정된 시간을 한참 오버하면서 진행했는데도, 시간 관계로 설명드리지 못하고 보여드리지 못한 것들이 아직도 너무 많아서 아쉬움도 크네요. 올 봄에 부산, 대전 세미나를 할 때도 그랬는데... 음.. 내년에는 꼭!!!