직업병

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 사무엘

2010/10/17 18:08 2010/10/17 18:08
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/393

※ 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 사무엘

2010/08/20 09:03 2010/08/20 09:03
, , , , , ,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/352

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 사무엘

2010/08/13 09:18 2010/08/13 09:18
,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/347

프로그램의 권한

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 사무엘

2010/06/22 08:55 2010/06/22 08:55
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/300

내가 옛날에 만든 프로그램들

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 사무엘

2010/02/26 09:05 2010/02/26 09:05
, , , ,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/198

« Previous : 1 : ... 19 : 20 : 21 : 22 : 23 : Next »

블로그 이미지

그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2024/04   »
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        

Site Stats

Total hits:
2679865
Today:
1949
Yesterday:
2484