김 용묵의 절대공간 - 블로그

Posted by 사무엘

 http://www.dilascia.com/ruint.htm

본인이 이 사람 이름을 본 것은 비주얼 C++ 6.0을 쓰던 시절부터이다.
MSDN을 보면 각종 함수 레퍼런스, 툴 설명서뿐만이 아니라 고맙게도 일부 책이나 간행물 내용까지 수록돼 있었는데, 어느 프로그래밍 잡지의 C++ Q&A란을 애독하기 시작했다. 그리고 그 코너를 집필하는 사람이 바로 저 전설의 프로그래머 Paul DiLascia였다.

특히 비주얼 C++ 6.0 MSDN에는 bmp 파일 뷰어를 밑바닥부터 만드는 과정을 설명해 놓은 게 있었는데
친절한 설명도 설명이거니와 이 아저씨는 글빨 입담이 정말 구수하다는 것을, 생소한 영어를 읽으면서도 느끼지 않을 수가 없었다.

윈도우+MFC 프로그래밍의 달인인 건 의심의 여지가 없고, 나중에 알고 보니 이 사람은 원래 수학 전공에다 컴퓨터 예술 쪽에도 심취해 있는 다재다능 엄친아였다. 이름이 좀 유럽풍인 것 같아 보이나, 실제로는 뉴욕에서 태어나서 자란 골수 미국인이라고 한다. 조상이 이민자?

링크를 건 곳은 저 사람의 2003년 시절 인터뷰이다.
고수 프로그래머로서의 조언도 여럿 담겨 있는데, 그 내용이 무척 공감이 간다.

- 최신 기술 동향은 놓치지 않되, 남들이 좋다고 하는 데에 소신 없이 절대 우루루 휩쓸려 따라가지 말라. 가령 클라이언트처럼 C/C++가 독보적인 분야가 있고, .NET 같은 곳이 더 유리한 분야가 따로 있을 뿐이다. 자신의 문제 해결에 가장 적합한 툴이나 기술을 잘 고르는 요령이 무엇보다도 중요하다. 그런 것들은 도구일 뿐이며 절대적인 우열이 존재하는 게 아니다.
- Win32 API가 존재하는 한.. 윈도우즈 운영체제가 밑바닥부터 새로 뒤바뀌지 않는 한, 너무나 클래식(?)한 C/C++이나 MFC 같은 것은.. 결코 그렇게 호락호락 없어지지 않는다. 더 업데이트가 안 되고 있다는 말은 그만큼 API가 성숙하고 안정화됐다는 뜻으로 오히려 다행스러운 현상인 것이다.
- 늘 목표를 명확히 하고 내가 무슨 문제를 해결해야 하고 그 목표 달성을 위해 무슨 도구를 쓰는 게 가장 최적일까를 고민하라. 디자인 과정을 소홀히 하지 말라.

민장(minjang.egloos.com) 님 블로그에서도 비슷한 요지의 말을 봤던 것 같다.

그리고.....

  "워드, 엑셀 같은 유명 소프트웨어에 들어있는 GUI 베껴서 따라 만드느라 시간 낭비 절대 하지 말라!" (그 시간에 실제 기능 구현에 필요한 자료구조/알고리즘 연구나 더 해라)

란 주문도 들어있다. ^^;;
아마 C++ Q&A 운영하면서 "나도 저기에 들어있는 그 기능, 그 UI 만들고 싶다. 어떡하면 좋은가?" 류의 뱁새가 황새 따라가려는 급의 문의를 엄청 많이 받았지 싶다.

* * * * *
  Too many programmers spend all their energy implementing some cutesy UI feature like docking windows or pink scrollbars because they saw it somewhere else. Microsoft has 5000 programmers to create animated paper-clips. You don't. Don't fall into the code envy trap!

  Don't get side-tracked implementing the latest GUI feature you saw in Word or Excel.
(그런 공룡 대기업들이나 부리는 '가진 자의 여유'를 당신이 따라할 여건은 안 된다는 걸 알아야 한다)
* * * * *

저건 우리나라의 유명한 비주얼 C++ 서적의 저자인 이 상엽 씨도 똑같은 말을 했다.

* * * * *
  그래도 예술적 가치가 있는 프로그램 제작에 열을 올린다면 좋은 이야기다. 그것도 아닌 것을 예술인냥 착각하고 움직이지는 절대 말라는 것이다. 예술적 가치가 없는 부분이 어떤것인가를 물어 볼것이다. 거 있지 않은가? MS 사에서 도움말 강아지 이리저리 왔다 갔다 한다고 자신의 프로그램에 강아지 만들어 넣는거...Visual C++의 워크 스페이스 창이 도킹 되었다가 떨어졌다 하는데 나두 이거 만들구 싶다 라는거...
예를 간단하게 들어서 MP3 에 있는 압축기술이나 음성인식 또는 지문인식 등의 기능이 예술이라고 볼수 있고 그냥 강아지 이리저리뛰어 다니는 것은 처음 만들어 내지 않는다면 것은 잡다구리 테크닉이다.
* * * * *

그래서 <날개셋> 한글 입력기의 편집기 프로그램은... 9년이 넘게 개발되고 버전이 5.5가 넘어선 지금까지도 완전 윈도우 95의 기본 컨트롤과 UI 요소만 사용하여 만들어져 있다. ^^;;; 편집기의 경우 과거 3.41 버전에서 MFC를 떼어내는 과정에서, 이제 도구모음줄이 도킹을 할 수 없게 바뀌었다. 그게 원래 MFC가 구현해 주던 일이었기 때문이다.

사실, 편집기를 실행해 보면 도구모음줄 아이콘들이 좀 중앙에 안 있고 메뉴, 즉 위쪽에 너무 바싹 붙었다는 인상을 받는데 이것도 딱히 바꿀 방법이 없다.
아이콘 사이에 임의의 크기로 여백을 내는 것도 MFC가 윈도우 프로시저를 다 서브클래싱해서 굉장히 지저분한 작업을 한 끝에 구현한 것이다. 이런 점에서 MFC는 단순히 윈도우 API wrapper 역할만 하는 것은 아님을 알 수 있다. 하지만 그런 거 따라하는 일에 너무 심취하지 말라는 얘기이다.

아쉽게도 이 사람은 작년(2008) 9월, 40대 후반의 나이로 세상을 떠났다. 사인은 밝혀져 있지 않다. 비주얼 C++ 2008의 내장 MSDN에는 2006년자로 작성된 그의 글을 볼 수 있는데, 이제 더는 그런 글을 접할 수 없으니 안타깝다.

Posted by 사무엘

※ QuickBasic

아래의 PB와 더불어 제 인생에서 거의 최초로 접한 “EXE 생성기”가 아니었나 싶습니다. 중학교 시절 저의 주된 장난감이었습니다. 특히 가장 대중적인 베이직 컴파일러였던지라 한글 입출력/그래픽/사운드/마우스/메모리 등 갖가지 분야의 공개/상용 라이브러리로 기능을 확장해서 프로그램을 만들던 기억이 납니다.

MS는 오로지 고객 편의 위주로 기존 관행을 확 깨는 새로운 제품 만드는 데는 정말 비상한 재주가 있다는 걸 인정해야겠습니다. 그래서 윈도우 9x 같은 타협안으로 소비자 시장을 우려먹기도 했고, 베이직 개발 환경만 해도 저런 대화형 구조에다가 라이브러리까지 특수한 EXE로 링크해서 ‘퀵라이브러리’(QLB)라는 개념을 발명하여, IDE에서 빌드도 없이 바로 프로그램을 실행시킨 것도 정말 대단하다고밖에 말할 수 없군요.

QB는 최종 버전이 4.5였고 그로부터 몇 년 뒤에 소위 MS Basic이라 불린 Basic PDS (전문 개발 시스템)가 7.0/7.1 (VS .NET 같군)라는 QB 후속 버전이 나오긴 했습니다. 하지만 차이를 전혀 모르겠어요. 오히려 기능 확장의 생명인 라이브러리가 호환이 안 되고 불편해서 널리 사용되지는 않았습니다. PDS 이후 MS는 비주얼 베이직으로 넘어갑니다. 마치 MS C 7 이후로 비주얼 C++이 나온 것처럼.

※ PowerBasic

볼랜드에서 Turbo Basic을 잠시 만들던 전 직원이 볼랜드를 나와서 따로 창조한 브랜드이죠. 베이직만으로 QB보다 월등히 빠르고 거의 C/C++ 수준의 효율적인 네이티브 코드를 만들어 준 덕분에 QB와는 별개 영역에서 사용자를 구축하고 있습니다. 저는 3.1을 써 봤습니다.

단점으로는 QB에 비해 역시 라이브러리 캐부족, 일부 QB와 호환되지 않는 문법, QB보다는 다루기 불편한 IDE. 그리고 PB도 아예 Win32 콘솔 프로그램은 만들어도 32비트 도스 익스텐터와의 연계는 없었던 걸로 압니다.
또한 QBasic도 지원하는 스크린 mode 13H (VGA 320x200 256색) 모드를 지원 안 하는 것도 너무너무 아쉬운 점.

세상에 베이직처럼 Dialect가 많은 언어도 별로 없는 것 같습니다. 요즘 베이직은 그냥 스크립트 언어처럼 쓰거나 아니면 .NET 구도에 맞춰서 문법 다 뜯어고쳐서 쓰는데, PB는 베이직으로 하드코어 네이티브 코드를 지향했다고 볼 수 있습니다. 참고로 베이직을 거의 어셈블리 수준으로 짬뽕시킨 언어 내지 툴로 ASIC이라는 녀석도 있었습니다.

※ Visual Basic

GUI 바로 만들고 거기에다 코드를 즉시 갖다붙이는 형태가 무척 재미있어서 잠시 갖고 놀아 봤습니다. 하지만 런타임 DLL이 필요한 EXE밖에 못 만든다는 걸 알고서 이내 좌절함. 그나마 5.0 이전 버전은 EXE 자체도 자바 내지 닷넷 같은 슈도코드 기반이지 네이티브 코드는 지원도 안 하고 있었고요.

아울러, 닷넷부터는 IDE가 언어 불문하고 한데 통합되었기 때문에 VB 특유의 그 개성 넘치는 IDE를 볼 수 없게 된 것이 좀 아쉽습니다.

※ Borland Pascal

언어 특성상 C/C++과는 비교가 안 될 정도로 빌드 속도가 월등히 빠르고 라이브러리 오버헤드도 훨씬 작아서(Hello, world! 프로그램의 exe 크기) 굉장히 좋은 인상을 받았습니다. 16비트 도스용 네이티브 컴파일러로는 그야말로 최고봉이 아닌가 싶습니다. 파스칼 언어도 제가 베이직에서 C/C++로 전환할 때의 과도기 컨셉 역할을 잘 해 주었습니다. 이걸로 뭔가 걸출한 프로젝트를 진행해 봤으면 하는 아쉬움도 있습니다.

파스칼은 교육용으로 무척 훌륭한 언어이고 간단한 문법 덕분에 빌드하기는 간편하나, C/C++보다 함축성이 굉장히 떨어져서 코딩하기는 번거롭습니다. 가령 정수 나누기 정수도 결과가 무조건 실수가 되고 일일이 형변환을 해야 하는 건 기계 입장에서는 직관적이지 못하죠. 또한 단축연산이란 것도 없고.

※ Turbo C/C++

고등학교 때 정보 올림피아드 준비하던 시절에 잠시 다뤘을 뿐, 제품 자체의 왕년의 영향력에 비해서 얘를 써 본 경험은 거의 없습니다. 본격적인 응용 프로그램 개발을 위해 필요한 프로젝트 세팅, 메모리 모델 설정 같은 것도 전혀 해 본 적 없습니다. 저는 16비트 C/C++과는 도스/윈도우 공히 인연이 없는 셈입니다.

※ Delphi

놀랍게도 제가 얘를 다뤄 본 건 95년에 나온 초창기, 그것도 16비트 버전인 1.0뿐입니다. 오브젝트 파스칼 언어로 비주얼 베이직 같은 프로그래밍을 할 수 있구나 하는 인상만 받고 더 진척된 건 없습니다.

델파이는 런타임 DLL이 필요한 EXE를 만드는 옵션 자체가 없고 기본적으로 EXE 크기가 2~300KB대 이상은 먹고 들어가는 걸로 알고 있습니다.

※ C++ Bulder

비베, 델파이 수준의 RAD 환경을 C++로도 만들어 버렸으니 대단하다는 인상을 받았음. 물론 다른 건 다 델파이를 따라해도 빌드 속도를 따라할 수는 없지요.
버전 3을 써 봤습니다. 골치아프게 Win32 GDI API 쓸 필요 없이 캔바스 객체에 접근하여 프로퍼티를 바꾸는 것만으로 선과 면 색을 바꾸는 것도 흥미로웠습니다.

하지만 RAD 용도로는 어차피 델파이가 한 역할 담당하고 있었고, C++ 빌더는 상대적으로 존재감이 덜했던 것 같습니다.
MFC도 지원은 하지만, 빌드 속도 내지 빌드된 코드의 성능이 MFC의 본고장인 VC로 빌드한 것보다 무척 뒤쳐졌던 걸로 기억합니다. 빌드 속도는 흠, pre-compiled header 설정을 안 해서 그런 걸까?

델파이와는 달리 C++ 빌더의 EXE는 기본적으로 VCL.DLL이던가 컴포넌트 DLL이 필요한 형태입니다. 스테틱 링크가 가능한지는 기억이 안 납니다.

※ Watcom C/C++

MS와 볼랜드 컴파일러의 공통점은 32비트 도스 익스텐더 기반 코드 생성을 지원하지 않았다는 것입니다. 자기네 컴파일러들이나 겨우 몇 MB 정도 추가 메모리 확보를 위해, 286용 16비트 도스 익스텐더 정도를 사용한 게 고작입니다.

그러던 차에, 상용 게임들 덕분에 유명하던 DOS4GW 기반 코드 생성을 지원하던 왓콤 컴파일러는 정말 신선한 충격이었습니다. sizeof(int)도 말로만 듣던 4바이트로 나왔죠.
최적화 성능도 매우 뛰어났던 걸로 기억합니다. 익스텐더는 다르지만 도스용 아래아한글 386 에디션도 왓콤 기반이었던 것으로 유명합니다.

하지만 라이브러리가 부족하고 IDE도 없는 이 컴파일러로 본인이 당장 할 수 있는 일이 별로 없었던 게 아쉽습니다.

※ DJGPP

자유 소프트웨어 진영의 위력을 보여준 불세출의 32비트 도스 컴파일러입니다. 소스까지 공짜, DOS4GW보다 stub 크기가 훨씬 작고 더구나 DPMI가 기제공되는 환경에서는(윈도우 도스박스 같은) 필요하지도 않은 CWSDPMI.
거기에다 rhide 같은 IDE와 알레그로 같은 무지막지한 게임 라이브러리.

빌드 속도가 좀 느리고 exe 크기가 살짝 좀 큰 게 압박인데, 그 정도는 좀 대형 프로그램 작성하다 보면 아무것도 아닙니다. 도스가 살아 있다면 계속해서 쓰고 싶습니다. 물론 윈도우용 GCC도 있다고는 들었지만.

※ Visual C++

여러 개발툴들을 거쳐 이제 최종적으로 정착한 도구는, 그 이름도 유명한 비주얼 C++입니다. 더 설명이 필요없으리라 믿습니다. 닷넷이고 뭐고 많이 나와도 역시 한글 IME를 직접 개발하다 보니 제게는 네이티브 말고 다른 계층은 필요하지가 않네요.

Posted by 사무엘