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

1.

<날개셋> 한글 입력기는 동일한 입력기 커널을 공유하는 세 개의 프런트 엔드가 있다.
그 중에서 가장 존재감 있는 터줏대감은 전용 에디터인 편집기이고, 실질적으로 가장 널리 이용되는 프로그램은 윈도우용 IME인 외부 모듈이다. 한편, 편집기처럼 실행되어 마치 IME처럼 동작하는 포인팅 장치 입력 유틸리티인 입력 패드도 지난 5.3 버전에서부터 추가되어 제 3의 프런트 엔드 구실을 하고 있다.

그 중 가장 먼저 만들어진 ‘편집기’는... 프로그램을 만든 본인부터가 에디터로서 아주 유용히 사용한다.
차라리 외부 모듈은 디버깅 할 때 외에는 사용하지 않는다. 운영체제의 기본 IME로 지정되어 있으면 파일을 고칠 수가 없어서 디버깅을 못 하기도 하기 때문이다.

<날개셋> 편집기는 어떤 점에서는 아주 답답하다. 가변폭 글꼴이 지원 안 되고 글씨 크기 조절도 안 되고, ClearType 렌더링이라든가 OpenType 스펙 등 오늘날의 모든 최신 타이포그래피 기술로부터 완벽하게 소외된 외딴 섬이기 때문이다.

그러나 한편으로 <날개셋> 편집기는 아주 작고 가벼우면서도 윈도우 95 이래 어떤 OS에서나 동일하게 유니코드 5.2 옛한글을 마음대로 조합할 수 있고 한글을 내 마음대로 다룰 수 있는 우리집 안방 같은 공간이다. 내가 만든 프로그램이어서 자화자찬 차원이 아니라 정말로 그렇다.
입력 기능뿐만 아니라 다양한 텍스트 필터도 있고, 한글을 자모 단위로 찾고 입력기에다 넘겨주는 글쇠를 붙여넣는 것 같은 아기자기한 기능도 있다. 도스 시절 추억의 도깨비 한글 비트맵 글꼴을 볼 수 있는 건 덤이다.

예전에는 옛한글은 오로지 내장 글꼴로밖에 표현할 수 없었는데 5.3에서부터 임의의 조합 테이블과 추가 자모를 내장 가능한 자체 비트맵 글꼴 포맷을 제정함으로써 <날개셋> 한글 입력기의 커널은 나름대로 글꼴도 독립을 이뤘다. 아래아한글 1.x와 비슷한 글월 입력 환경을 윈도우 환경에서 재현해 낸 것이다.

완전한 텍스트 에디터 엔진을 처음부터 새로 만들었기 때문에, 앞으로 한글 표현 방식이 어떻게 바뀌든 이 구조에 맞춰 엔진을 마음대로 내가 고칠 수 있다.
리눅스나 맥 OS에서는 이런 게 언제쯤 상륙 가능할까? ㄲㄲ

2.

지금까지 <날개셋> 한글 입력기를 만드는 과정에서 그 당시엔 내가 방법을 전혀 몰라서 어려움을 겪던 고비가 몇 차례 있었다.
- 인스톨 패키지 만들기(2002~2003년): MSI 기반으로 완전히 해결
- 외부 모듈(2004~2005년): 3.x 초창기 버전 때 무수한 시행 착오를 겪으면서 결국 안정화 단계. 하지만 “아직까지도” 일부 극소수 몰상식-_-한 응용 프로그램에서 사소한 오동작 버그 신고가 올라오고 있음
- 64비트(2007년): 결국은 본인이 64비트 기계를 직접 장만하면서 지원에 성공.

3.

한 컴퓨터를 놔두고 세벌식 사용자인 본인과 두벌식 사용자인 지인이 같이 앉아 문서를 읽으면서 검토와 교정을 하고 있었다. 이때 복벌식 입력 방식을 아주 유용하게 사용했다. 글자판 전환을 할 필요 없이 서로 자기에게 익숙한 글자판으로 자기가 수정하고 싶은 곳에서 바로 글자를 입력하면 되니 이렇게 편할 수가 없었다. ^^

이거 하니까 세벌식 관련 다른 팁이 또 생각난다. 세벌식 숫자 배열이 익숙한 분이라면, numlock이 켜져 있을 때 오른손 숫자 자리가 non-shift 자리로 내려오게 하면 엑셀 같은 데서 숫자 입력을 아주 편리하게 할 수 있다. <날개셋> 한글 입력기로는 가능하다.

4.

버전 5.53 내지 5.65쯤부터 추가되었지 싶은데, <날개셋> 편집기로 프로그램이 아닌 문서 창(MDI)의 시스템 메뉴를 보면 해당 문서 파일의 ‘속성’ 창을 바로 꺼내거나, 탐색기를 꺼내거나 전체 경로를 복사하는 명령이 있다. ‘파일 경로 복사’를 고르면 되는데, 지금까지는 진짜 말 그대로 파일의 경로가 텍스트 형태로 복사되어 메모장에서만 그걸 붙여넣을 수 있었다.

그런데 탐색기에서 Ctrl+V를 누르면 해당 파일 자체가 실제로 복사도 되게끔 프로그램을 고쳐 봤다. 메모장과 탐색기는 클립보드를 사용하는 방식이 완전히 다르기 때문에 이 기능은 서로 충돌을 일으키지 않으며, 이렇게 하니까 아주 편하다. 5.8 버전에 이 기능이 반영되지 못해서 아쉽다.

5.8을 릴리즈한 후 현재까지 도움말의 오타 내지 로그인 화면· 아웃룩· vim 등에서의 사소하지만 쉽지 않은 외부 모듈 관련 버그가 몇 개 보고되어 있다. 하지만 다들 프로그램의 성능이나 안정성(죽는다거나-_-)과 관련된 건 아니다. MS IME의 소스를 직접 보지 않는 이상 이런 것까지 다 완벽하게 처리하는 버그 없는 IME란 제작 불가능하다. -_-

5.

다음은 <날개셋> 타자연습 이야기. 지금부터는 그림도 좀 곁들이겠다.

요즘도 실력 유지를 위해 타자 연습을 안 하는 건 아닌데,
주옥같은 연습글을 만들었다. 다음 버전에 추가할지 진지하게 고민 중이다. ^^;;

공 병우 세벌식은 10년을 넘게 써도 한글의 위상을 끌어올린 정말 위대한 발명품임이 느껴진다. 그 반면 저 불편한 현행 두벌식 글자판은 어떻게 쓰는지 그걸로 빨리 치는 사람들이 대단하기 그지없다. 세벌식의 단점--기껏해야 글쇠 수 좀 많고 4단 쓰는 것--에 비해 두벌식의 단점은 훨씬 더 치명적이다.

2008년부터 2010년까지 존재하는 본인의 게임 점수판은 전부 ‘승리’(12단계 깨고 엔딩)이다. 본인이 사무엘이라는 이름을 쓰기 시작한 건 2008년 말부터임.
<날개셋> 타자 게임은 과거의 한메 타자 베네치아보다 훨~씬 더 어렵지만 요즘은 한글 타자가 워낙 일상화했기 때문에 본인 말고도 엔딩 보는 사람이 꽤 있을 것이다.

6.

끝으로, 10년 전에 만들었던 WordTech 엔진(컴퓨터 자동 대국 기능)을 요즘 완전히 새로 다시 짜고 있다. 스크린샷은 기존 WordTech와, 새 엔진(GUI를 갖다붙이지 않은 콘솔 프로그램)끼리 서로 검증 대국을 시키는 모습이다.

본인은 <날개셋> 한글 입력기를 만들기 전엔 국내에서 거의 최초로 크로스워드 게임 엔진을 만든 바 있으나... 그 당시의 작품은 지금의 관점에서 보면 기술적으로 개허접.. ㄲㄲㄲㄲ

요즘은 워낙 컴퓨터가 똑똑해진 덕분에, 굳이 이것보다 더 빠르고 메모리를 덜 쓰는 크로스워드 게임 엔진을 만든다는 게 큰 의미는 없지만... 이번에 새로 짠 코드는 메모리 사용량, 계산량, lexicon의 자료구조와 알고리즘, 코드의 깔끔함과 재사용성 등 모든 면에서 10년 전의 구닥다리 코드와는 비교가 되지 않는다. 참으로 아름답다. ^^;;

사실, 이렇게 만들면 된다는 이론적 기반은 이미 수 년 전에 완성되었지만 <날개셋> 개발 때문에 뒷전으로 밀려서 지금까지 작업을 못 하고 있었을 뿐이다.
WordTech도 버전업 좀 하고 싶은데.. ㅠㅠ 컴퓨터과학과 대학원 수업에서 무슨 과목으로든 프로젝트로 좀 할 기회라도 있었으면 좋겠다. 이 엔진 얹으면 버전 4.0으로 가는 건데.;;

콘솔은 만국의 공통 인터페이스이다 보니(표준 입출력 스트림^^), 엔진을 비주얼 C++뿐만이 아니라 오랜만에 DJGPP로도 컴파일해서 도스에서 돌려 봤다. 똑같이 32비트이기 때문에 별 어려움 없이 돌아간다. 지금도 DJGPP가 버전업이 되고 있는지는 모르겠지만 내가 보유하고 있는 건 무려 1997년에 설치한 버전. 혹시 bool 키워드가 지원되지 않나 확인해 봤는데 다행히 지원한다.

10년 전에는 DJGPP의 그 느린 빌드 속도가 무척 거슬렸으나 지금은 그마저도 전광석화. 별도의 도스박스 같은 에뮬뿐만이 아니라 그냥 윈도우 운영체제의 NTVDM에서도 잘 돌아간다.
단, printf의 포맷 지정자로 %c만 인식하고 %C는 인식하지 않는다. 대문자를 찍는다는 생각에 %X와 %x(16진수 숫자)를 구분하듯 습관적으로 %C를 지정해 줬는데 인식이 안 되더라. 뭐, 어차피 찍을 때 chCode+'A' 식으로 대문자를 지정하기 때문에 %c와 %C는 전혀 구분할 필요가 없고 %c만 지원해도 충분하긴 하다.

이상으로 본인의 programming life 잡설 끗.

Posted by 사무엘

메리 크리스마스 인사부터 하고... ㅋ
본인 블로그의 정기 구독자-_-라면 이미 귀가 따갑게 들으셨겠지만, 본인은 10년 전, 제 17회 한국 정보 올림피아드(KOI) 공모 부문의 고등부 대상 수상자이다. 그리고 얼마 전엔 모듈 음악에 대해 글을 쓰면서, 바로 전 해인 16회 대회의 고등부 금상 수상자에 대해서 언급했었다. 그때는 대상 수상자가 없었다.
이제 이 글에서는 전 회에 이어, 본인이 참가한 해의 바로 이듬해인 18회 대회의 고등부 대상 수상자에 대해서 얘기하도록 하겠다.

그 주인공은 바로 김 성진 씨.
학창 시절부터 일찌감치 경시가 아닌 공모 테크를 타고 뭔가 창의적인 아이템으로 소프트웨어 개발에 매진했다는 점에서는 본인의 진로와 비슷하다. 그리고 지금까지 한 우물만 죽어라고 파고 있다는 점에서도 본인과 공통점이 있다. (무슨 분야인지는 곧 소개하겠다.) 그런 외골수는 나밖에 없는 줄 알았는데 여기 또 있다. ^^

이 친구는 KOI뿐만이 아니라 창의성 대회나 다른 소프트웨어 공모전 등에서 자기의 동일 아이템으로 상을 휩쓸었고, 본인보다 매스컴도 훨씬 더 많이 탔으며 IT 분야 사회 활동을 더 활발히 해 왔다. 사교/사회성, 정치성 자체가 본인과는 비교할 수 없이 더 뛰어난 사람이다.

이 친구의 보유 기술 및 아이템이 뭐냐 하면,
인터넷 보안, 음란 사이트 차단, 자녀 컴퓨터 사용 제어(parental control), 인터넷/게임 중독 예방 쪽이다. 관심 분야부터가 지극히 사회적인 쪽이지 않은가?
그걸 수 년째 연구한 솔루션을 만들어서 그는 18회 KOI에서 당당히 대상을 차지하고, 일반고 출신으로서 지정 대회 우수 입상자로 카이스트에 진학했다. 본인은 그와 2001년에 처음으로 메신저에서 만났고, 이내 학교에서 볼 수 있었다. 굉장히 예의바르고 인상이 좋은 사람이었다는 기억은 아직까지 생생하다.

그 후 2004년 가을에는 전산학과에서 제 1회 KAIST Computing Festival이라는 행사를 열었는데, 그때 대회 참가자로서 또 서로 만날 일이 있었다.
그는 확실히 이론보다는 실무형 인재였고, 내 예상과는 달리 전산학과가 아닌 산업디자인과에 진학해 있었다. 전산/산디 복수 내지 부전공인지는 확실히 잘 모르겠다. 저런 친구야말로 카이스트 전산과의 학부 과목인 ‘컴윤리’는 꼭 들어야 했을 텐데 말이다. (그러고 보니 김 진형 교수님도 불과 몇 년 뒤면 정년이다. 세월 한번 무섭다.)

그는 산디과 소속답게 자기 작품을 소개하는 발표용 프레젠테이션은 정말 기가 막히게 잘 만들었던 걸로 본인의 기억에 남아 있다. HCI(사람-기계 커뮤니케이션) 쪽에도 관심이 많은 듯. 스티브 잡스 근성이라도 있는 걸까? ㄲㄲㄲ

뭐, 사족을 덧붙이자면 그 교내 공모전에서도 본인이 출품한 <날개셋> 한글 입력기 3.02가 1등을 했다.
카이스트 전산학과는 가히 전국에서 날고 기는 수학 덕후· 컴퓨터 괴물들이 우글거리는 곳이고, 난 그 집단 안에서는 별 보잘것없는 중하위권 학부생에 불과했다. 그럼에도 불구하고 거기서까지 내 작품이 최고로 인정받을 수 있었던 것은 1, 2년 연구한 작품이 아니니 짬과 연륜면에서 타 작품들과 비교가 안 되고, 또 한글을 이런 식으로 입력할 수 있다는 게 세벌식 사고방식으로는 당연한 것이지만 두벌식밖에 안 써 본 사람이라면 카이스트 교수에게라도 충분히 창의적이고 참신하게 작용했기 때문인 것 같다.

본인이 국어학하고 양다리를 걸쳤다면, 김 성진 씨는 디자인과 양다리를 걸쳤다. 그는 카이스트에서 산디과 석사까지 마친 후, 아예 (주)휴모션이라고 벤처기업 창업을 했다. 그게 2008년의 일이고, 현재까지 어엿한 사장님이 돼 있다. ^^;; 창업 과정에서 카이스트로부터 지원을 당연히 아주 많이 받았다. 보아하니 회사는 대전의 유성 고속버스 터미널에서 꽤 가까운 곳에 있는 듯.
사장이 디자인 전공이다 보니, 핵심 기술인 ‘컴퓨팅 안전’ 분야 솔루션뿐만이 아니라 웹사이트 내지 심지어 회사 CI의 디자인 용역까지 담당하는 모양이다. 대단한 후배이다. 본인과 나이 차차도 별로 안 난다.

정올 공모 출품작 아이템을 이렇게 사업 아이템으로까지 스스로 발전시켜 잘 나가고 있는 입상자가 주변에 있으니 부럽기도 하고 훈훈하다. 정올 공모에서 이렇게 입상하고 덤으로 카이스트 같은 좋은 면학 환경까지 거쳐 간 인재들이 특별히 전산학하고 다른 분야와의 학제간 연구를 통해 우리나라에 뭔가 좋은 일을 많이 했으면 좋겠다. 본인 역시 그 꿈을 이루려는 의욕이 있어서 뒤늦게나마 협동과정 대학원에 갔다. 나는 그렇게 학구파는 아니지만 저 친구 같은 사교력이나 사업 수완은 더 없기 때문에-_-;; 일단 공부부터 좀 하려고..;;
성진 후배가 이 글을 볼 일이 있을지 모르겠지만, 그의 성공과 사업의 번창을 기원한다.

Posted by 사무엘

우리는 C/C++ 언어에 대해 배울 때, 이 언어는 근본적으로 컴파일과 링크를 거쳐 결과물이 만들어지며, 이 과정에서 소스 코드가 obj 파일로 바뀐다는 말을 듣는다. 그런데 이런 중간 파일들의 내부 구조는 어떨지, 최종 결과물인 실행 파일의 형태와 중간 파일 사이의 관계는 어떨지 등에 대해서 궁금하게 생각해 본 적은 없는가?

물론 obj 파일에는 컴파일된 기계어 코드가 잔뜩 들어있을 것이고 lib는 그냥 이미 컴파일된 obj 파일의 컬렉션에 불과하다. 하지만 그걸 감싸는 컨테이너 포맷 자체는 필요할 것이다.
C++의 경우, 함수의 이름을 prototype대로 decorate하는 방식이 표준으로 제정된 적이 없어서 그 방식이 컴파일러마다 제각각인 것으로 악명 높다. 그렇다면 이런 obj, lib 파일 포맷도 언어마다, 혹은 컴파일러마다 제각각인 것일까?

결론부터 말하자면, 정답은 ‘No’이다. obj, lib 같은 파일 포맷은 실행 파일의 포맷과 더불어 굉장히 시스템스러운 포맷이고, 일반적인 응용 프로그램의 개발자가 거의 관심을 가질 필요가 없는 분야임이 틀림없다. 컴파일러를 만든다거나, 골수 해커 같은 부류가 아니라면 말이다.

이런 건 그렇게까지 다양한 파일 포맷이 존재하지 않으며, 다양하게 만들 필요도 없다.
인텔 x86 기계에서는 전통적으로 인텔 사가 고안한 OMF(object module format이라는 아주 평이한 단어의 이니셜) 방식의 obj/lib 포맷이 독자적으로 쓰였다. 굉장히 역사가 긴 포맷이며, 볼랜드, 왓콤, MS 등의 컴파일러에서 다 호환됐기 때문에 서로 다른 컴파일러나 언어로 만든 obj 파일끼리도 이론적으로는 상호 링크가 가능했다. 물론, 언어별로, 특히 C++의 경우 아까 언급했듯이 decoration 방식이 다르면 명칭이 일치하지 않아 혼용이 곤란하겠지만, 이건 파일 포맷 자체의 문제는 아니었다.

그런데, 32비트 시대가 도래하면서 사정이 약간 달라졌다.
machine word의 크기가 커지고 CPU의 레지스터 구조도 달라지고.. 그에 따라 obj/lib 파일의 포맷도 일부 필드의 크기가 확장되는 등 변화를 겪게 되었으며, 인텔 사에서는 OMF 포맷을 32비트로 확장한 업그레이드 버전을 내놓았다. 마치 지금 윈도우의 PE 실행 파일도 64비트에서는 기본적인 뼈대는 그대로 유지하되, 규격이 확장된 것과 같은 이치이다.

컴파일러들은 대체로 그 규격을 따르기 시작했으나, 이때 MS에서는 꽤 과감한 결정을 내렸다.
기왕 32비트로 갈아타는 김에, 자기네가 만드는(OS/2의 밑천으로? ㄲㄲ) 순수 32비트 운영체제인 윈도우 NT에서는 공식 사용하는 실행 파일과 obj/lib 파일의 포맷을 싹 바꾼 것이다.
어디 그뿐일까? 메모리가 귀하던 1990년대에 그때 이미 유니코드를 고려하여 딱 16비트 wide string을 내부 자료 구조로 채택했다. 본인이 보기에 윈도우 NT는 출발이 굉장히 대인배스러웠다.

새로운 포맷은 단순히 구조체 필드만 32비트에 맞게 키운 게 아니라, 더 보편적인 이식성과 확장성을 고려해서 설계되었다. 코드, 데이터 등 용도별로 다양한 chunk를 둘 수 있고, CPU 정보도 넣어서 굳이 x86뿐만이 아니라 어느 플랫폼 코드의 컨테이너로도 활용할 수 있게 했다. 또한 어차피 똑같은 기계어 코드가 들어있는 파일인데 obj/lib/exe 사이의 구조적 이질감을 낮춰서 일단 컴파일된 코드의 링크 작업을 더욱 수월하게 할 수 있게 했다.

그래서 MS는 32비트 컴파일러에서는 AT&T가 개발한 COFF(Common Object File Format) 방식을 약간 변형한 obj/lib를 사용하기 시작했고, 32비트 실행 파일은 잘 알다시피 COFF의 연장선에 가까운 PE(Portable Executable) 방식을 채택했다. 이 컨벤션이 오늘날의 64비트에까지 고스란히 전해 내려오는 중이다.

그렇게 MS는 과거 유물을 미련 없이 내버렸지만, 볼랜드 컴파일러는 32비트 윈도우용도 여전히 OMF 방식을 사용했고, 왓콤처럼 당시 16비트/32비트 도스/윈도우를 모두 지원하던 컴파일러는 OMF와 COFF 방식을 혼용까지 해서 당시 개발자들에게 상당한 혼란을 끼쳤다고 한다. 윈도우 운영체제가 16비트에서 32비트로 넘어가면서 이런 것까지도 정말 넘사벽에 가깝게 세상이 바뀐 것이다. 참고로 DJGPP는 도스용 컴파일러이지만 32비트 기반이고 COFF 방식 파일을 사용한다.

1985년에 나온 윈도우 1.0 이래로 16비트 윈도우가 사용하던 NE 포맷은 chunk 같은 게 없었다. 정보 자체를 식별하는 방법이 없이 요 정보 다음엔 무슨 정보, 다음에는 무슨 정보.. 딱 용도가 고정되어 있었고, 뭔가 확장을 할 수가 없었다. 상당히 원시적인 포맷이었다는 뜻. 개인적으로 그 시절에는 컴파일과 링크가 어떻게 이뤄졌고 DLL import/export가 어떤 방식으로 되었는지 무척 궁금하다.

또 생각나는 게 있는데, 과거에 똑같은 베이직 컴파일러이지만 MS가 개발한 퀵베이직은 굉장히 C언어에 가깝고, 파워베이직은 파스칼에 가까운 빌드 모델을 사용했다. 전자의 경우 헤더 파일을 인클루드하고 소스 파일을 obj로 컴파일하고, 각종 라이브러리와 링크하고... C와 똑같지 않은지? obj/lib 파일 포맷은 당연히 인텔 OMF 방식이었다.

그 반면, 파워베이직은 파스칼처럼 unit이라는 패키지를 만들고, 그걸 간단하게 use하는 것만으로 여타 모듈의 루틴을 사용할 수 있었다. 자바, C#, D 같은 요즘 언어들이야 비효율적인 인클루드(text parsing이 필요!) 방식이 아닌 패키지 import를 선호하는 추세이지만, 그 당시 파워베이직을 개발한 Bob Zale은 분명 파스칼 언어에서 이 아이디어를 따 왔을 것 같다. 물론 그렇다고 해서 파워베이직도 기존 obj 파일과 링크하는 방식이 없는 건 아니었다.
Bob Zale과, 터보 파스칼을 개발한 필리페 칸과는 어떤 사이일지 궁금하다.

C/C++에 전처리기가 있다면, 베이직이나 파스칼 같은 언어는 주석 안에다가 메타커맨드를 넣는 방식을 써 온 것도 흥미로운 점.
아울러, tpu, pbu 같은 저런 unit 파일은 분명 컴파일된 기계어 코드가 들어있는 라이브러리에 가깝지만, 당연히 컴파일러 vendor마다 파일 포맷이 제각각이다. 마치 퀵베이직의 QLB(퀵라이브러리) 파일이 아주 독자적이고 특이한 실행 파일인 것처럼 말이다.

Posted by 사무엘

1.
레크리에이션 시간에 하는 OX 퀴즈 말이다. 이거 완전 퀵 정렬스럽다는 느낌이 들지 않는지?
퀴즈는 PIVOT값이다. 정말 알쏭달쏭해서 사람들이 O와 X로 반반씩 갈려야 좋은 문제이고,
너무 쉽거나 해서 사람들이 한데 쏠리면 그건 난감하다. 퀵 정렬도 완전 똑같다. ㅋㅋ

2.
수업 시간에 각 학생들에게 설문지를 돌리거나 과제물을 나눠 준다. 내게도 서류 뭉치가 왔는데, 이게 어디서 왔는지 모르겠고 내가 살펴본 뒤에 다음으로 이걸 어느 방향에다가 넘겨줘야 할지 잘 모를 때가 있다.
이건 C++로 치면 iterator이다. 서류 뭉치는 모든 학생들을 한 번씩 순회하는데, ++itor; 명령이 수행되려면 지금의 순회 위치로부터 다음 순회 위치를 알 수 있어야 한다. 트리 구조를 순회한다면, 각 노드마다 부모 노드 포인터도 갖추고 있어야 한다는 뜻.

3.
요즘 존재하는 수많은 웹사이트들 중, html 수작업으로 만들어진 것들은 로컬 환경으로 치면 기계어로 짠 네이티브 프로그램이고, 블로그 엔진 기반은 닷넷처럼 일종의 상부 계층 위에서 돌아가는 프로그램에다 비유할 수 있을 것 같다.
개인 사용자가 나모 같은 에디터로 홈페이지를 만들 일이 없어졌다는 건, 윈도우 환경에서 어셈블러 수작업으로 프로그램을 만들 일이 없어진 것과 비슷한 맥락이 아닌가 싶다.
하지만 Win32 API 같은 네이티브 계층 자체가 완전히 없어지는 날은 과연 올까?

4.
외솔관에 있는 대학원생 독서실에 있다가 위당관으로 수업을 들으러 간다. 두 건물의 뒤쪽엔 높은 언덕이 있기 때문에 3층과 4층이 뒷문으로 연결되어 있으며, 이 경로를 이용하면 건물 사이를 왕래할 때 번거롭게 1층까지 내려갔다가 다시 올라갈 필요가 없다.
바깥에 비해 상대적으로 어두운 건물 복도를 걸으면서 지하철 터널을 떠올리는 것은 어렵지 않다. 그러다가 잠시 밖으로 나가면, 지하철이 강을 건너거나 서울 지하철 8호선의 복정-산성 구간 같은 곳을 지나느라 잠시 지상으로 나온 것 같은 느낌이 든다.

5.
교회에서 성가대 연습을 한다. 노래를 부르는데 반주자가 악보를 넘기느라 잠시 피아노 반주가 중단되었다. 그래도 노래는 박자나 음정의 어긋남이 없이 계속 잘 이어진다.
이것은 절연 구간을 지나느라 전동차에 전원 공급이 잠시 중단되더라도 차가 관성으로 계속 달리는 것과 같은 맥락으로 풀이할 수 있다. 아울러, 바닷물과 민물을 넘나드는 연어는 교류-직류 겸용 전동차의 예표이다.
일상생활 속에서 철도 패턴을 찾기는 어려운 일이 아니다.

6.
대학 학부까지만 학업을 마치고 취업을 한 건, 지금 생각해 보니 학업이라는 지하철이 서울 시계까지만 건설된 뒤 노선이 끊어졌던 듯한 느낌이다. 학부를 졸업한 지 5년이 지나서야 대학원에 들어가니, 그 선로를 이어서 장거리 광역전철을 건설하는 것 같다.

7.
<날개셋> 한글 입력기 5.65를 공개한 후, 소스를 대대적으로 뒤집어엎었다.
null-terminate 스트링의 write 버퍼를 받는 모든 함수에는 버퍼의 크기에 대한 정보를 추가하고, sprintf 같은 함수 호출도 버퍼 오버런을 일으키지 않게 다 손질했다.
파일을 읽고 쓰는 과정에서 에러 처리를 더욱 강화하고, 범용적인 dll 모듈은 thread-safe하도록 고쳤다.
좀 비효율적이고 불합리하게 만들어져 있던 라이브러리 API를 뜯어고쳤다.

그래서 다음 버전으로 잠정 계획 중인 <날개셋> 한글 입력기 5.8은 5.5 시절부터 비교적 잘 유지되어 왔던 API 하위 호환성이 모두 깨질 예정이다.
타자연습도 덩달아 버전업된다. 입력기에 적용된 프로그래밍 테크닉이 그대로 적용되고, 그리고 연습글을 좀 정리할 생각이다.

6만 줄에 달하는 <날개셋> 한글 입력기 소스 코드를 들여다보노라면 정말 나만의 세계, 나만의 건축물, 나만의 철도 노선에 들어온 느낌이다. 의존도라고는 Win32 API와 몇몇 Ansi C 함수밖에 없으며, 나머지 코드들은 100% 자체 제작이다. 다른 프레임워크나 오픈소스 작품 같은 거 쓴 것이 전혀 없다.

누구에게 돈이나 시간 면에서 단 한 치도 얽매인 게 없이, 전적으로 개인 취미 생활로 개발하는 것이다 보니,
단순히 기능만 되게 하는 게 아니라 소스 코드의 질에도 굉장히 신경을 쓴다.
비록 한 줄에 100칼럼을 꽉꽉 채우느라 겉보기로는 코드가 좀 지저분해 보여도, 구조는 의외로 깔끔한 편. ㅋㅋㅋㅋ

코드에 무슨 공통된 패턴이 반복되는 게 발견되면 함수로 따로 떼낸다거나, 모듈 간의 공통된 기능을 한 기반 클래스로 빼낸다거나.. 이런 식으로 "리팩터링"을 수시로 진행한다는 뜻이다.
이런 거 공사 하나 잘 해서 추상적인 클래스가 하나 탄생하고 상속 계층이 한 단계 올라간다거나 하면,
어려운 버그를 잡은 것만큼이나 기쁘다.

Posted by 사무엘

※ Fabrice Bellard (프랑스) 1972년생
http://bellard.org/
홈페이지를 보면, 주인장은 수학과 전산학, 전자 공학의 완전 덕후임을 알 수 있다.
파이 계산, 컴파일러, 게다가 IOCCC(국제 난잡한 C 코드 경연대회) 입상 경력.
관심 분야가 이쪽과 상당히 비슷한, 본인의 모 지인이 떠오른다. (누굴까? ㅋㅋㅋ)
이 사람은 1990년대 도스용 실행 파일 압축 프로그램인 lzexe의 개발자이기도 하다.
겨우 고등학생 나이 때 8086 어셈블러로 직접 짰다고 한다. 흠좀무...;;;;;;
그 당시, V3로 바이러스 검사를 해 보면, 압축된 실행 파일은 검사가 되지 않고 압축부터 풀어야 한다는 경고문이 떴다. lzexe와 더불어 pklite도 실행 파일 압축 프로그램이었다.

※ David Fotland (미국) 1957년생
http://www.smart-games.com/
The Many Faces of Go라는 바둑 게임의 개발자이며, 회사까지 차려서 20년 전이나 지금이나 바둑 AI를 열심히 밀고 있는 게임 인공지능 전문가이다. (도스, 윈도우, 모바일 기기) 그 프로그램을 혼자서 다 만들었다니.. 대단하다.
생각보다 나이가 지긋한 분이다. 캘리포니아 주 산호세에 거주 중.

※ Jean-loup Gailly (프랑스)
http://gailly.net/
gzip의 개발자이며, 데이터 압축 분야의 세계적인 권위자로 유명하다. 아래아한글도 2.1 시절부터 이 사람이 개발한 알고리즘을 라이선스하여 hwp 파일 내부 압축을 구현하고 있다. 현재는 스위스 취리히에서 살고 있으며, 구글에 입사했다. 나이가 좀 있어 보이는 분인데 정확한 생년은 모르겠다.
이 사람도 바둑 매니아이다. 개인 홈페이지를 보면 바로 위의 the Many Faces of Go 프로그램에 대해서도 응당 논평을 해 놓았다. AI가 세계 최강급은 아니지만 초보자를 위한 인터페이스가 무척 잘 돼 있다나?

※ Ken Silverman (미국) 1975년생
http://advsys.net/ken/
듀크 뉴켐 3D의 기술 기반인 빌드(Build라는 단어 자체가 고유명사) 엔진을 개발한 게임 프로그래머.
뼛속까지 프로그래머 근성이 철철 흐르는 한편으로 과학, 스포츠, 음악 등등 온갖 분야에 해박한 엄친아라는 게 느껴진다. 빌드 엔진 역시 학창 시절의 작품이다.
지금까지도 딱히 정식으로 소속된 직장이 없이, 프리랜서 프로그래머로만 일하는 모양이다.

※ Shawn Hargreaves (영· 미 이중 국적) 1975년생
http://www.talula.demon.co.uk/
Ken과 동갑이고 비슷한 업종에 종사 중인 게임 개발자이다.
도스 시절, 32비트 C/C++ 컴파일러로 왓콤과 맞장을 떴던 GNU 계열의 DJGPP를 기억하시는가? DJGPP용으로 소스까지 공개이던 걸출한 게임 그래픽 라이브러리 알레그로를 만든 사람이 이 사람이다.
음악에 특별히 조예가 아주 깊은 매니아이다. 지금은 쟝 아저씨의 구글 입사와 비슷한 시기에 마이크로소프트에 입사해서 XNA 기반 게임 개발에 푹~ 잠겨 있는 듯.

말이 나왔으니 또 덧붙이자면.
본인은 중· 고등학교 시절에 스크래블 게임을 컴퓨터용으로 개발했다.
국내에 그런 프로그램이 개발된 사례가 없었기 때문에 응당 외국의 동급 프로그램들을 여럿 구해다가 벤치마킹을 했는데.. 알고 보니 그런 게임의 개발자 중에도 졸라 프로그래밍 고수가 많았다.

※ Jim Homan (1950년대생)
미국 출신. CrossWise라는 걸출한 게임을 혼자 만든 사람으로, 컴퓨터 AI가 굉장히 뛰어나고 프로그램 UI도 매우 프로페셔널하게 잘 만들어졌다. 윈도우 3.1용으로는 보기 드물게 비주얼 C++ 1.x + MFC로 개발되었다.
이 사람은 옛날에는 자기 회사를 차려 사업을 했기 때문에 회사 홈페이지 아래에 얹힌 개인 홈페이지에 개인 프로필도 나와 있었다. MIT에서 컴퓨터 과학을 전공하고 성적도 엄청 좋았고, 접해 본 플랫폼과 관심 분야 등등도 화려하기 그지없었는데, 지금은 이 사람에 대해서 알 수 있는 곳이 없다.

※ Graham Wheeler (1960년대생으로 추정)
http://www.linkedin.com/in/grahamwheeler
WordsWorth라는 게임을 만들었다. 개발자는 완전 수학 덕후로, 학부에서 수학 전공하고 대학원에서 컴퓨터 과학으로 박사와 박사 후 연구원까지 마친 브레인이다. 국적이.. 남아프리카 공화국으로, 케이프타운 대학을 나왔다.
지금은 마이크로소프트에 입사. 프로필과 블로그를 보면 역시 뼛속까지 엔지니어를 넘어 골수 컴퓨터 과학자이다.

한 줄 요약: 세상은 넓고 덕후들, 고수들은 무진장 많다.

Posted by 사무엘

C 언어 표준 라이브러리에는 잘 알다시피 배열 데이터에 대해서 간단한 검색과 정렬 알고리즘을 구현해 놓은 함수가 존재한다.
정렬을 수행하는 qsort()가 대표적인 예이고, 이미 정렬된 배열에 대해서 이분 검색을 수행하는 bsearch()도 유용하다.

이들 검색과 정렬 함수는 비슷한 형태의 인자를 받아서 동작한다. 배열을 가리키는 포인터, 각 원소의 개수와 크기, 그리고 찾고자 하는 원소의 값, 그리고 비교 함수의 포인터이다. 비교 함수는 두 원소의 비교를 수행하여 대소 관계를 리턴값의 부호 또는 0 여부로 알려 주어야 한다. 이렇게 함으로써 int든 float든 그 어느 자료형이라도 범용적으로 검색하거나 정렬을 수행할 수 있다.

그런데 C 언어는 이분 검색뿐만 아니라 선형 검색을 하는 함수도 제공한다. 찾는 원소와 같은 값이 나올 때까지 배열을 처음부터 끝까지 단순히 뒤지기만 하는 알고리즘 말이다. 동작 방식은 단순하기 그지없지만, 이분 검색과 더불어 그냥 일관성을 위해서 선형 검색도 함수로 표준화한 듯하다. 선형 검색이 받아들이는 비교 함수는 두 값의 대소 비교를 할 필요가 없이 두 값이 단순히 같으면 0, 그렇지 않으면 nonzero만 되돌려도 된다.

그런데 본인은 C 언어가 제공하는 선형 검색 함수의 형태를 보고는 놀라지 않을 수 없었다.

1. 이분 검색이 bsearch이니 선형 검색은 응당 lsearch일 거라고 본인은 생각했다. 그런데 선형 검색 함수는 _lsearch와 _lfind로 나뉘어 있고, 어찌 된 이유인지 함수 이름 앞에 밑줄이 추가돼 있다. 이분 검색과 정렬 함수는 stdlib.h에도 선언이 되어 있는 반면, 선형 검색 함수는 거기에 없으며 반드시 생소한 search.h를 인클루드 해 줘야 한다. 왜 이런 차이가 존재하는지부터 의문이다.

2. _lsearch는 원소를 찾아서 이게 배열에 존재하지 않으면, 그 원소를 배열의 끝에다가 추가를 한다. 따라서 이 함수는 매개변수만 올바르다면, 원하는 원소가 배열에 없다고 하더라도 NULL을 리턴하지 않는다. 그 반면 _lfind는 read-only 함수로, 원하는 원소가 없으면 NULL을 되돌린다. 그러므로 정확하게 bsearch 함수의 동작 방식만 선형 검색의 형태로 원한다면 _lsearch가 아닌 _lfind를 써야 한다.

3. bsearch와는 달리, 선형 검색 함수는 배열 원소의 개수를 넘겨주는 인자가 포인터형이다. 그것도 size_t도 아닌 unsigned int의 포인터이기 때문에 64비트 환경에서도 여전히 32비트 값 전달만 가능하다는 한계마저 그대로 지닌다. ㅜ.ㅜ 왜냐하면 _lsearch의 경우, 원하는 원소가 배열에 존재하지 않아서 그 원소가 배열 뒤에 추가되었을 경우, 배열 원소 개수를 1 증가시켜 주기 위해서이다.

그러나 배열 원소 추가를 하지 않는 _lfind라면 배열 원소 개수 인자가 포인터여야 할 필요가 전혀 없고 bsearch처럼 size_t 값을 그대로 받기만 하면 된다. 왜 _lfind까지 _lsearch처럼 그렇게 포인터를 받게 해 놓았는지 모르겠다.

Posted by 사무엘

1.
병특 회사에서 근무하던 시절의 일이다.
그때 본인은 본업을 넘어-_-, ActiveX 컨트롤을 만들어 관리하던 적이 있었다.
(사용자들이 아무리 ActiveX 욕하고 우리나라가 무슨 MS 공화국이네 뭐네 하면서 까도, 일선 개발자들은 위에서 까라면 깔 수밖에 없다. 더구나 본인은 국방부 시계가 돌아가던 중! ^^;;; )
ActiveX는 내부에 플래시 UI를 하나 만들어서 플래시는 웹 상에서 사용자와 소통을 하고, ActiveX는 플래시와 소통을 하면서 플래시만으로 하기 힘든 네이티브 코드를 수행했다. 내가 왕년에 저런 일까지 했다니..

그런데 문제가 있었다. 정확하게는 기억이 안 나지만, ActiveX든 플래시든.. 뭔가 로컬에 있는 파일을 참조하는 건 아무 문제가 없었는데 웹에 있는 놈을 가져오는 건 아무 이유 없이 도무지 되지 않고 작동을 거부하는 것이었다.
먼 옛날 일이 됐으니 망정이지, 이것 때문에 당시 회사에 환멸을 느낄 정도로 좌절하고 삽질했었다. -_-;;

문제의 원인은 보안이었다. 그 당시 갓 출시된 플래시 7이던가 8이던가.. 하필 그때부터 보안 정책이 딱 바뀌어 플래시의 액션스크립트는 아무 웹에서나 정보를 덥석 가져오지 못하게 되었다.
그 반면, 내 로컬 컴퓨터의 ....\flash player\#security\flashplayertrust 이런 디렉터리에다가 configuration file을 만들어서 접근을 허용하는 웹 주소를 먼저 적어 줘야 하고, 플래시는 허용된 웹으로만 접근할 수 있다.
자세한 정보: http://kb2.adobe.com/cps/116/1165eb90.html

어쨌든 이것 때문에.. 가장 권한이 많고 강력한 ActiveX가 DllRegisterServer를 통해 등록될 때 저 flashplayertrust에다가 우리 플래시에 대한 정보를 덩달아 등록해 주고, 등록 해제될 때 그 정보를 삭제하도록 함으로써 문제는 일단락되었던 걸로 기억한다. ActiveX는 네이티브 코드인 관계로 파일, 레지스트리, 웹 등에 다 접근이 되고, 심지어 Win32 API를 직접 호출해서 뭐든 다 할 수 있으니.. 사기 유닛이다.

물론 오늘날은 다른 웹 표준과 RIA 기술도 풍부한데 저런 무식한 방법을 쓰는 건 곤란하다.
참고로 플래시에 전설의 flv 동영상이 추가된 게 그 무렵부터일 것이다. 유튜브가 그때 막 태동했으니 말이다. 플래시가 벡터 드로잉 애니메이션뿐만 아니라 일반 비디오 플레이어 분야도 섭렵하기 시작했으며, 덕분에 이제 인터넷으로 동영상 볼 때 ActiveX 설치를 요구하는 사이트는 개념 없다는 소리를 듣기 시작하게 됐다.

2.
안드로이드 어플 만들면서도 비슷한 경험을 했다. 아놔 다른 프로그램에서는 잘 되는 환경설정 변경이 왜 도대체 안 되고, 기껏 되더라도 왜 내가 바꾼 환경설정이 다른 곳에 도무지 적용이 안 되는지.. 함수 호출 결과는 성공인데.. 그 뒤 결과는 그냥 씹히고 있던 것이다.
하루를 삽질하고 났더니 원인은 역시 매니페스트 파일에다가 android.permission.WRITE_SETTINGS , android.permission.CHANGE_CONFIGURATION 요 따위 퍼미션 요청을 안 해 놨기 때문이었다.

3.
그동안 유닉스 계열 OS에 비해 권한이나 보안 같은 관념이 너무 약하던 윈도우도, 비스타부터는 그쪽으로 좀더 엄격해졌다.
잘 알다시피 사용자 계정 컨트롤(UAC)라는 게 추가됐으며, 프로그램을 관리자 권한으로 실행할 때와 그렇지 않을 때에 허용되는 권한의 차이가 매우 커졌다. 가령, 관리자 권한이 아니면 '내 문서' 말고 다른 디렉터리에다가는 파일을 제대로 만들지도 못한다.

그리고 이 프로그램이 요구하는 권한을 명시하는 게 가능해졌다.
아무 권한에서나 실행 가능한지, 무조건 관리자 모드에서 실행돼야 하는지 하는 걸 말이다.
지정은 EXE 내부의 매니페스트 XML에다가 하면 된다. 그 개념은 이미 윈도우 XP에서 시스템 DLL의 로딩 방식을 제어하기 위해 도입된 바 있으므로 새삼스러울 게 없다.
비주얼 C++ 2008부터는 링커 옵션에 이걸 바로 지정해 주는 게 추가됐다. 그 이전 버전에서는 사용자가 직접 xml 파일을 손으로 써서 링크해 주면 된다.

스크린 키보드처럼 장애인 Accessbility용 프로그램은 의외로 높은 보안 수준이 필요하다.
내가 받은 입력에 대한 결과를 시스템 모든 프로그램에다가 끼쳐야(키보드 입력 흉내) 하기 때문에
이런 프로그램은 별도의 인증을 거쳐야 운영체제가 그 정도의 권한을 허락하게 되어 있다.
그런 인증을 거치지 않은 "<날개셋> 입력 패드"는, 사용자가 직접 관리자 권한으로 실행해 주지 않으면,
자기보다 권한 등급이 높은 프로그램에다가는 글자 입력을 전달해 줄 수 없다.

글을 맺는 소감:
삽질해야 하는 게 싫다. -_-;;
지금 유닉스 명령어 익히느라 땀 뻘뻘 흘리는 걸 보면, 옛날에 지금보다 영어도 훨씬 더 못 하던 시절에 도스 명령은 어째 알아서 외웠는지 궁금하다.
지금 이놈의 안드로이드 때문에 삽질하는 걸 보면, 옛날에 윈도우 API는 어째 공부했는지 내가 생각해도 나 자신을 이해할 수 없다.
그때는 삽질을 삽질이라고 여기지 않고 전적으로 재미로 했기 때문에 프로그래밍에 재미를 붙일 수 있었던 것 같다.

Posted by 사무엘

1. PentaCombat (마지막 빌드 2000): 2000년대 이후로 개발이 중단됐다. (그 당시 이 프로젝트 이후 곧장 <날개셋> 한글 입력기 개발로..) 나름 3*3과 4*4 판단 알고리즘을 굉장히 정교하게 구현해 냈고 오목은 AI 연구용으로도 굉장히 재미있는 주제라고 생각했는데, 더 개발을 못 하게 된 게 무척 아쉽다. 지금 공개되어 있는 컴파일 EXE, DLL은 무려 비주얼 C++ 4.2로 빌드되었으며, 날짜도 1999년~2000년대이다. ㅎㄷㄷ

2. WordTech (마지막 빌드 2007): 이것도 굉장한 애착을 갖고 있는 프로그램이다. 국내에서 스크래블/업워드 크로스워드 게임을 자체 개발한 사례는 이 프로그램이 유일하기 때문이다. 그것도 컴퓨터 AI에다 네트워크 기능까지 말이다.
지금은 10년 전보다 더 효율적인 단어 목록 자료구조와 더 빠르고 똑똑한 AI 알고리즘을 만들 수도 있다. 그리고 네트워크 쪽도 구닥다리 DirectPlay 대신 저수준 네트웍 API로 새로 짤 필요도 있다. 하지만 본인은 이제 이걸 도저히 손댈 수 없는 처지가 됐다.

3. <날개셋> 타자연습 (마지막 빌드 2009): 더 무슨 말이 필요하리요? 게임은 좀 3D로 고쳐야 하고 각종 바이러스들의 비주얼 효과도 더욱 현란하게 고쳐야 한다. 윈도우 비스타부터는 운영체제의 기본 내장 게임조차 Direct3D를 쓰는 세상이 되지 않았던가.
그리고 네트워크 기능을 적극 도입하여 온라인 타자방, 실시간 연습글 업데이트 같은 기능도 넣어야 한다.
하지만 타자연습도 작년 말 3.21을 끝으로, 더는 내가 더 손을 볼 수 없는 사실상 개발 중단 상태가 되지 않을까 싶다. (지원 중단이라는 뜻은 아님. 여건상 새로운 기능을 추가하지는 못하지만, 버그 패치나 보안 업데이트 정도만. ㅎ)

4. <날개셋> 한글 입력기: 그나마 지금까지 독자적인 아이템으로, 10년간 가장 열정적으로 기능 연구와 개선을 해 온 프로그램. 엔진 쪽도 사실 최하 6.0까지는 더 만들고 싶지만 현실은 5.7, 혹은 5.53에서 끝날지도 모르겠다. 엔진 차원에서 더 고차원적인 개념을 생각하자면 끝도 없지만, 일반 사용자의 관점에서는 지금 엔진만으로도 기능은 이미 너무 많아서 미처 다 활용도 못 할 수준이리라.
지금의 5.5x대 엔진을 바탕으로 아무래도 여타 운영체제 포팅을 할 가능성부터 먼저 찾는 걸로 계획을 수정해야 할 것 같다. 그것부터 된 후에 여건이 남으면 엔진 작업도 더 할 것이다.

본인에게는 <날개셋> 한글 입력기만큼이나, 한글과 관련된 또 완전히 다른 솔루션을 연구하고 싶은 게 있다. 시기가 시기이니만큼 이 카드도 슬슬 꺼내 봐야 할 것 같다. 그러니 언제까지나 기존 아이템의 유지 보수에만 매달려 있을 수가 없다. 지저분한 윈도우 IME 쪽 버그 살펴보는 것도 한계가 있다.

이런 식으로 사람은 점점 발전하는 것 같다.
역시 어렸을 때, 실패에 대한 위험 부담 내지 사회적 책임이 적을 때 하고 싶은 일을 실컷 해 놔야 한다. 게임으로 허비하기엔 인생은 너무나 아깝다.

고등학교 3학년 때 과감하게 <날개셋> 한글 입력기 1.0을 만들었기 때문에 10년 뒤에 이것이 5.5까지 버전이 오를 수 있었다.
그리고 그 전에 허접하게나마 저 두 보드 게임을 만들었기 때문에 그 기술과 경험을 근거로 이듬해에 <날개셋> 한글 입력기 1.0이 만들어질 수 있었다.

저 프로젝트들 생각만 하면 그나마 프로그래머다운 기질이 팍팍 살아나는 걸 느낀다. 하지만 나는 순수 공돌이나 전산학도는 아니기에, 내 경쟁력을 위해서는 아무 프로그램이나 짜서는 안 되고, 컴퓨터를 수단으로 삼아 다른 특정 분야에서 활로를 찾아야겠다.

Posted by 사무엘