개발자로서

The Orion Project
개발자로서 - 시작하는 글

오로지 열정과 집념의 몸부림만 있었을 뿐.

저가형 미니 키보드 사용기

입력 장치는 휴먼 인터페이스라 해서, 인체 공학적 설계 등을 갖춘 고가 장비들이 출시되고 있지만, 개인적으로 키보드및 마우스는 소모품에 해당한다. 워낙 마구 대충 열악하게 사용하기 때문에, 고가의 HHK 프로 같은 키보드로 작업한다면, 내 성격상 키보드에 신경이 쓰여 작업을 제대로 못할 것이라 생각된다. HHK 는 언젠가는 사고싶은 물건이지만, 이상과 현실을 일치시키기란 쉬운 일이 아닌 것 같다.

한편, 오른쪽에 숫자 키패드가 달린 일반적인 키보드들은 오른쪽에 마우스를 두는 사용자들에게 불편함을 준다. 물론 다른 이유도 있겠지만, 이런 불편함 때문에 왼손 마우스를 쓰는 분들도 있는 것 같다.

이런면에서 선택하게된 저가형 키보드 두 종류, 세진 트랙볼 USB 미니키보드 및 붐테크 USB 콤보 미니 키보드 (BKM-100S)에 대한 비교 사용기를 적어보려한다. 저가형 미니 키보드에 관심있는 분들께 조금이나마 도움이 됐으면 좋겠다.

새진 트랙볼 USB 미니 키보드( 정보 보기 )

가격: 27000원 내외

키배열 :

(1) ` 키 (또는 쉬프트시 ~ 키 ) 가 좌측 하단에 있다. VIM 에서 이전 커서 위치 이동 (``)을 사용하는 경우, 처음 적응시 헷갈린다.
(2) 개발자 주요키 중 작은 키가 있다. 잘 못 누르게 되는 경우가 좀 있다. ( 탭키, \ 키, ESC 키 )
(3) Fn - CTRL 키 순으로 배열돼 있다. 내 경우는 이런 배열일 때 엄지로 CTRL 을 누르게 되는 경우가 생기는 것 같다. 그래서 CTRL 이 맨 바깥쪽에 있는 경우와는 키 누르는 패턴이 약간 달라졌다.
(4) INS, DEL 이 우측 상단에 있다. 일반 키보드와 비슷한 느낌을 준다.

(5)Numlock 은 Fn 키에 의해 작동된다.

키감 :

처음 구입했을 때는 뻑뻑한 고무판을 누르는 느낌이 난다. 쓸수록 괜찮아지긴 해도 키감은 뻑뻑한 편이다. 어쨌든 내게는 사용하는데 큰 지장은 없는 편이었으나, 다른 분들의 사용 소감을 보면 역시 키감은 문제가 있는 것 같다.

트랙볼:

이 키보드를 선택하게 한 중요한 이유 중 하나였고, 처음 물건을 받았을 때는 쓸만하다고 생각했지만, 시간이 흐를수록 헐거워져서, 트랙볼 바퀴가 위치하는 반대 방향으로 이동시 헛도는 경우가 생긴다. 예를 들어, 수평 이동 감지용 바퀴가 오른쪽에 부착돼 있다면, 왼쪽으로 트랙볼 이동시 헛돈다. 명함 두께의 종이를 작게 오려서 끼워넣으면 나아지지만, 갈수록 트랙볼 성능은 안좋아진다. 트랙볼이 유용할 때는 갑자기 마우스가 고장나서 버튼이 더 이상 작동을 안할때, 그리고 누워서 영화를 감상하는 등에 필요한 컴퓨터 조작 정도를 할 때라고 생각한다. 작업용으로 쓰기엔 조잡하다.

기타:

(1) 국산이다. 그래서 겉모습은 BKM 보다 좀 견고하다. 물론 가격이 더 높은 이유도 있다.

(2) 각도 조절 받침 있다. 키스킨 포함돼 있다.

(3) 동시 키입력 문제 때문에 ( 잘은 모르지만 USB 키보드가 대개 이렇지 않나 싶다. ) 게임시 우측 쉬프트 키를 할당할 수 없어서, 디센트 게임할 때 오른손이 사용하는 키배치를 다르게 해야 한다.

BOOMTECH BKM-100B ( 정보 보기 )

가격 : 7000 원

키배열 :

(1) 세진과 달리 ` (쉬프트시 ~ )키가 일반키보드 위치와 같다. 그 덕분에 세진에 익숙해졌다가 다시 이것에 익숙해지느라 또 헷갈리는 중이다.

(2) 대체로 키 크기가 만족스럽다. 그 때문에 세진보다 약 2.5 cm 정도 가로로 더 길다. 스페이스키는 약간 짧다. 그 덕에 특이하게도 미니 키보드에 오른쪽 ALT 키가 있다. 오른쪽 ALT 를 없애고, 스페이스를 길게 했으면 좋았을 것 같다. 오른손 엄지로 스페이스를 누를때 처음에 약간 적응이 어려웠다.

(3)CTRL - Fn 으로 배열돼 있다. 그 덕에 세진 쓰느라 CTRL 누를때 엄지를 쓰던 버릇이 남아서 헷갈리고 있다.

(4) INS,DEL 이 우측 하단에 있다. 이것 또한 헷갈리고 있다.

(5) Numlock 키가 별도로 있다.

키감 :

세진이 뻑뻑하다면, 이건 아주 헐겁다. 누르는 느낌이 좀 아쉬운 정도다. 고무로 된 전자 계산기 키보드까지는 아니지만, 어쨌든 그런 부류의 부드러운 고무판을 누르는 느낌이다.

기타:

(1) 중국 OEM 이다. 키 높이가 조금씩 서로 차이가 있다.

(2) 각도 조절용 받침이 없다. ( 처음에 좀 놀랐다. -_- ) 수건을 접어 받쳐서 쓰고 있다. 키 스킨 역시 없다. PS/2 변환잭이 들어있고 PS/2 포트로도 사용할 수 있다. (사용은 안해봤음)

(3) 동시 키입력 문제는 역시 있지만, 언급했듯이 INS-DEL 이 우측 하단에 있는 덕에 디센트 오른손 키설정을 거의 그대로 적용할 수 있다.

어쨌든, 두 키보드 모두 그냥 쓸만하다. 하지만, 가격 대비 성능을 얘기하자면 BKM-100B 쪽에 점수를 주고 싶다. 그리고, 일반 키보드와 키배열이 좀 더 비슷한 것 역시 BKM 쪽이다. 막쓰기를 즐기시는 분들께 추천하고 싶다.

1 과 2는 연속된 정수이면서, 각자 독립된 한개의 비트를 차지하고 있으며, 두 값의 비트합 및 산술합은 다시 연속된 정수인 3이 된다.

오라이언 프로젝트를 같이 개발할 개발자가 있었으면 좋겠다.

오전 12:54 2007.05.21

2000년 넘어서면서 프로그램 개발에 있어 가장 의미있던 일은 VIM 을 익히기 시작한 것이다.

오후 10:57 2007.04.04

어떤 문제에 부딪혀 결정을 내려야 할 때 하나의 문제를 가지고 일주일이 넘게 고민하는 때가 있다.

그런 고민 끝에 처음 생각과는 다른 새롭고 더 좋은 해결방안을 찾으면 고민한 시간은 아깝지 않다. 미래에 분명히 그것은 개발 시간을 줄여줄테니까.

만일 처음 생각 그대로 결정을 하게됐다면, 조금은 아쉽다. 고민은 문제점으로부터 출발했을 것이므로, 이 경우라면 그 문제점에 대한 해결방안을 고안해낸 것으로 봐야한다. 그렇지 않았다면 이 결정을 내릴 수 없다.

최악은 결론내리지 못한 경우다. 물론 어떤 식으로든 마무리지을 수는 있겠지만, 이건 내 작업을 더 진행할 수 없게 만들어버리는 요인이다.

이번 결정은 2주일 가까이 걸린 것 같다. 아무튼 결론은 얻어서 다행이다. 하지만, 너무 늦다. 두뇌 회전이 좋지 않아지고 있는 게 분명하다.

한때 거대 소프트웨어 기업에 대한 막연한 반발감, 자유소프트웨어, 특히 리눅스에 대한 막연한 추종심을 가졌던 적도 있었다. 하지만, 그런 생각은 이제 내겐 유행처럼 지나가버린지 오래다. 리눅스든 윈도우즈든 심지어 소형 기기에서 작동하는 심비안이나 위피든,

모두 그저 하나의 플렛폼에 불과할 뿐 그 이상도 이하도 아니다.

오전 04:45 2007.03.26

SHIFT-SPACE 한영 전환 유감

SHIFT-SPACE 한영 전환이 처음 시작된 것이 아래아 한글부터인 것으로 안다. 나는 이 두 키를 조합하는 것을 진절머리나게 싫어하는데, 여전히 사용되고 있고, 선호하는 분들도 있는 것 같다.

나는 프로그램 소스를 작성할 때, 대문자 입력을 위해 SHIFT 키를 유지한다. 그러므로 다음과 같은 문장을 입력한다면,

#define A B

나는 A 를 입력하기 위해 SHIFT 를 누르기 시작하고, 공란 뒤 다시 대문자를 입력할 것이므로, SHIFT 를 유지한 채 SPACE 를 누른다. 그다음 B 를 누르면 결과는,

#define Aㅠ

이건 개발 작업에서 재앙이다. 한컴은 도대체 무슨 생각으로 이런 황당한 조합키를 만들어내서 아직까지도 그 망령에 시달리게 하는가.

오후 10:01 2007.03.17

나는 성격 더러운 개발자로 기억될진 모르겠지만, 일 못하는 개발자로 기억되진 않을 것이다.

S6311 NBINSIDE 리뷰

나의 새로운 창. 후지쯔 S6311. 창만 좋다고 잘 싸우겠냐만은,
이 정도는 돼야 전쟁터를 누비지...
1994년 ~ 1999년까지 486 DX2 66
2000년 ~ 2006년까지 P3 600
이런 추세라면 아마 마흔까지는 이걸로 유지하지 싶다.
마흔이라면 나는 개발자로서 은퇴를 원한다.

세진 미니 트랙볼 키보드

나의 새로운 장신구, 세진 미니 트랙볼 키보드.
키감은 좀 뻑뻑하다. 딱딱한 고무판을 누르는 느낌이다.
좀 치다보면 나아졌으면하는 바램이다...
트랙볼은 마음에든다. 책상위가 넓어질 것 같다.

PM 10:28 2006.11.21

나는 기계 공학 전공자다. 하지만, 대학에 입학해서 대학원까지 약 8년동안, 소프트웨어 개발자로서 기본 능력을 나름대로 키웠다.

세 회사를 거친 7년여의 기간 동안, 크게 보았을 때 서로 다른 두 분야에서 실무적 경험을 얻으며, 실제 개발 환경에 적용될 수 있는 소프트웨어 아키텍쳐를 갖추기 위해 노력했다. 첫회사에서 고안해낸 범용 소프트웨어 아키텍쳐는 세번째 회사에서 더욱 심화되었고, 다음과 같은 아키텍쳐를 결론 지었다.

이식성 높은 스크립트/레코드/컴포넌트 기반 비동기적 서버 클라이언트 아키텍쳐

Highly Portable Script/Record/Component Based Asynchronous Server Client Architecture

나는 이 아키텍쳐를 완성하고, 그 결과를 다시 회사로 환원하고 싶었다. 하지만 애석하게도 그럴 수 있는 기회는 찾기 어려웠다.

결국 이 아키텍쳐가 갖는 개념들은 내 궁극의 프로젝트 오라이언의 아키텍쳐로 자리 잡을 것이기 때문에 오라이언 소프트웨어 아키텍쳐 ( The Orion Software Architecture )라 불리운다. 나는 이 비동기적 실행 시스템을 가지고 앞으로 10여년 남짓 남았을 거라 생각되는 내 개발자로서 경력을 마감하고 싶다.

나는 누가 뭐라든 어떻게 생각하든, 일관된 방향성을 가지고 이제까지 달려왔다. 조금 숨을 고를 뿐 다시 달리기 시작하면 이제 끝날 때까지 멈추지 않는다.

AM 01:35 2006.09.30

어떤 분과 이런 저런 이야기를 나눈 후 두가지가 기억에 남았다.

"OOO씨는 기술적인 두려움이 없나봅니다."
"저요? 두려움 많습니다. 안두려우면 사람이 아니죠."

"OOO씨는 자기가 개발 실력이 어느 정도라 생각하세요?"
"글쎄요... 자기 스스로 국내에서 다섯 손가락에 꼽힌다고 말하는 개발자도 봤습니다만... 저는... 음... 못하지는 않는다고 생각합니다.

미래에 내 눈에 드는 개발자를 만났을 때, 그리고 내가 개발자를 은퇴할 때, 다시 한번 물어볼만한 질문이다.

AM 05:43 2006.07.24

소스를 이해하고 이해시키는 일에 대해

다른 사람이 작성한 소스를 보는 일은 그 소스가 잘 되어있든 그렇지 않든 항상 어렵다. 그러므로 개발자로서 남의 소스를 보며 느끼는 어려움을 그에 대한 맹목적 거부감으로 표출해서는 안된다.

어려움을 거부감으로 표현하기보다는 우선 개발자의 의도를 살피려는 노력이 필요하다. 오프라인으로 대면할 수 있는 개발자라면 상황은 한결 쉬울 것이다. 이러한 노력 없이 거부감 표출로 바로 진입하는 개발자들의 심중을 나는 어렵지 않게 판단할 수 있고, 내가 그 사람을 설득할 수 없다고 판단되면, 나 또한 그 반응에 대한 거부감을 표출할 수 밖에 없다. 특히 내가 좋아하지 않는 사람이라면 바로 그렇게 할 것이다.

소스 가독성이라는 건 부수적인 문제라고 생각한다. 나는 설명할 수 있는 소스를 작성해야 한다고 본다. 개발 의도, 아키텍쳐, 코딩 스타일, 구현 방법에 대해 모두 투명하게 설명할 수 있는 소스는 충분한 가독성을 갖게 되어있다. 다른 사람이 이해하기 쉬운 코드를 작성하기 위해 소스 가독성을 강조하는 글들을 종종 보지만 그것은 본질이 아니다. 다른 사람이 이해하려면 내가 이해시킬 수 있도록 설명할 수 있어야 한다. 그래서 소스를 살펴서 해당 개발자 자신도 적절히 설명할 수 없는 코드라고 판단되고, 어떠한 상황적 특수성도 없었다면 그것은 비난 받아야 한다.

다른 사람이 작성한 소스를 보는 것은 꾸준히 단련해야 하지만, 다양한 오픈 소스 프로젝트들을 다운로드 받아서 그 소스들을 살펴보면 항상 어렵다. 그 어려움을 쉽게 거부하지 않는 개발자가 좋다.

AM 03:49 2006.04.15

나는 좋은 개발이 좋은 제품을 만들고, 좋은 제품이 상업적 성공을 거둔다고 생각하며, 이 생각을 바꿀 생각은 없다. 앞서 가 있는 경쟁자를 따라잡기 위해 무조건 서둘러 뛰기 시작하는 사람은 어리석은 자 또는 오만한 자 둘 중 하나다.

그러므로, 나의 모든 생각은 회사의 모든 생각과 다르다. 이것은 내가 여기 더 이상 머무를 어떠한 근거도 존재하지 않는다는 것을 의미한다. 여기까지라고 생각된다. 모든 잔재를 일소하는 일만 남지 않았을까? 초심으로, 그리고 열정과 집념으로 다시 몸부림쳐야 할 것 같다.

PM 11:47 2006.03.06

"애초 이 개발에 착수할 때 가장 중요한 목표는 일정을 지키는 것도, 좋은 평가를 받는 것도 아니라, 다음 개발자들이 아키텍쳐를 이해한다면 그들을 괴롭히지 않는 프로그램을 작성하는 것이었습니다. 그 목표를 달성하지 못하면 절대로 완성시키지 않겠다고 생각했었구요. 그래서 지금도 변함 없이 그 생각 그대로이기 때문에 적절한 타이밍에 일에서 손을 떼게 할 필요도 있겠습니다. 이미 그 타이밍이 지난지도 모르구요.

주제넘은 생각일 수도 있었지만 이 개발은 단지 XXXXX-X 개발을 위해서 시작한 게 아니라, 앞으로 우리 회사에 있을 모든 신제품 소프트웨어에 쓰일 수 있도록 목표를 해서 시작했습니다. 좀 더 빨리 길을 찾았으면 좋았는데, 시행 착오가 생각보다 많았구요. 이건 제가 그 동안 배운 것들 입니다. 그래서 저도 결과가 어찌되든 후회가 없습니다."

이 시절의 결과에 대해 적어도 후회는 없다.

2006.03.02

스크립트, 레코드, 컴포넌트에 기반한 비동기적 실행 아키텍쳐라고나 할까...? 아무튼 빨리 끝났으면 좋겠다. 이게 끝나야 뭐든 할 수 있을 것 같아.

( 2006.02.09 )

구현이 중요한가, 구상이 중요한가. 간단히도 둘다 중요하다. 많은 개발자들은 구현까지는 어떻게든 하지만, 구상하는데 시간을 투자하지 않는다. 아니, 어떤 면에서는 구상할 줄 모른다. 그런 개발자들이 경력이 쌓이고 팀을 이끌고 새로운 제품을 만들어야 한다면 그들이 할 수 있는 일은, 빨리 제품을 만들라는 요구 뿐일 것이다. 관리자는 개발자가 충분히 상상력을 발휘할 수 있도록 여유를 주어야 하고, 개발자는 어떻게 구현할 것인지 구상하는 ( 아키텍쳐를 만드는 ) 연습이 필요하다. 나는 이제까지 내 임의로 시간을 확보하긴 했어도 그것을 보장해주는 사람은 보지 못했다. 그런 상황이라면 항상 쫓기는 마음으로 개발해야 한다. 경험적으로 구상에 필요한 시간은 구현 시간의 두세배쯤 된다. 사실 구상이 끝나면 구현이 어려운 경우는 많지 않다.

피플웨어에서 밝히는 생산성 조사중 흥미로운 일은, 다되면 알려줘식 개발 방침인 경우 생산성이 가장 높았다는 것이다.

( 2006.01.22 )

팀장님께서 면접에서 물어본 간단한 실기 문제들을 많은 사람들이 풀지 못한다는 사실에 놀랐다. 어떤 문제였는가하면,

- delimiter에 의해 구분되는 n 번째 문자열을 구하시오.
- 비트 연산
- 구조체를 파일에 그대로 저장한 뒤 이기종 시스템에서 그 파일을 읽을 때 발생할 수 있는 문제

3번은 내가 낸 단답식 문제 중 하나다. 전공자들이 이것을 못푼다는 것은 충격이다. 내가 낸 주관식 문제는 트리 노드 연결과 traverse 구현, Joel씨가 추천한 문제 두가지 였다. 저 정도도 못풀면 내가 낸 문제는 엄두도 못낸다.

개발자는 기본적으로 자신이 작성하는 코드의 완전함과 우아함을 추구해야 하지만, 항상 그런 것은 아니다. 특히 회사 업무처럼 원치 않아도 해야하는 일들이 많은 경우 걸레같은 소스 코드라도 없애버리지 못한채 계속 끌고 가야 하는 일이 있기 마련이다. 이런 코드와 마주쳤을 때 나는 이 코드의 유용성에 대한 평가가 선행되어야 한다고 본다. 그래서,

1. 아예 들어내고 새로 작성할 것인지
2. 리팩토링 할 것인지
3. 이미 버린놈 취급해 줄 것인지

결정해야 한다고 본다. 그리고 3번을 꺼려할 필요는 없다. 3번은 1번을 기약하며 시간을 버는 것이다. 리팩토링이 항상 좋은 일이라 생각하는 것은 어리석다. 게다가 리팩토링이 대단한 개념인냥 간주하는 것도 어리석다. 객체지향, 디자인 패턴, 리팩토링, STL 등 에 대한 맹신족들은 정작 개발에 있어 철학적인 면들을 간과하기 쉽다. 프로그램 언어로 개발을 하고 있다면, 여전히 그것은 언어라는 것을 잊어서는 안된다.

( 2006.01.02 )

아무리 회사 업무라해도 이번 일은 일정보다 결과물의 우아함을 목표로 할 것이다. 엉터리 코드를 만들어 놓은 개발자들의 뒷치닥거리라는 건 결코 흥미로운 일이 될 수 없으며, 원하지도 않게 내가 다른 사람을 경멸하게 만들기에, 나는 이제 절대로 다음 개발자들이 그런 지루하고 의미없는 일에 얽매이지 않도록 하겠다. 지금 개발이 지연되는 것이 크게 문제될만한 상황은 아닐 뿐더러, 혹여 개발 지연으로 인해 내가 피해를 받게 되더라도, 어떠한 것이든 개의치 않는다. 최악의 결과는 퇴사일 것인데, 이미 그에 대한 결론은 내 머리 속에서 끝났다.

아무튼 이번 업무는 내가 했던 회사 일 중에서는 가장 어렵고, 가장 흥미로운 일인 것 같다. 무엇에 죽도록 몰두하고, 새로운 것을 배우고 좌절하고 헤쳐나가는 일은 개인적인 개발을 하던 것 외에는 경험하지 못했었다.

첫 회사에서 구상하고 추진했던, 그러나 개인적인 문제로 아쉽게 접어야 했던 프로그램 아키텍쳐를 이 회사에서, 그것도 팀을 한번 바꾸고서야 드디어 재개할 수 있게 됐다. 이 일은 그저 회사 업무가 아니라 짧지 않은 세월에 얽힌 나의 빚이다. 그것이 어떻게 평가되든, 또한 내가 최선을 다하는 도중 다시 일을 접어야 한다해도 결코 타협하지 않겠다.

나를 믿고 묵묵히 지켜봐주는 이에게, 나는 적어도 그만큼 댓가를 안겨줄 능력은 있다고 생각한다.

( 2005.11.16 )

컴퓨터가 이해할 수 있는 코드는 어느 바보나 다 짤 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다.

라는 말이 리팩토링에 나온다. 저자가 무슨 말을 하고 싶은 지는 안다. 하지만, 적지 않은 사람들은 이 말을 오해하여, 자기가 이해할 수 없는 코드를 만든 사람을 나쁜 프로그래머라고 생각한다.

다음을 기억하라.

아무리 좋은 프로그래머가 작성한 코드라도 안 좋은 프로그래머는 이해할 수 없다.

다음도 기억하라.
안 좋은 프로그래머는 자기가 만든 코드를 이해하지 못하는 사람을 안 좋은 프로그래머라고 단정한다.

좋은 프로그래머인지 아닌지는 작성된 프로그램이 현재 어떻게 작동하는지 그리고 많은 시간이 지나면서 그 프로그램이 잘 유지 보수 되는지로 평가된다고 생각한다.

( 2005. 10. 22 )

나는 이번 업무를 향해 마치 돌격하는 것 같다. 첫 회사에서 진 빚을 갚고자하는 생각이 있다. 어차피 그 빚을 받아야 할 분들은 내 주변에 없지만, 적어도 나는 나 스스로에게 떳떳해지길 바라는 것이겠지.

내 생활은 극도로 흐트러지고 있다. 결국 내게 불이익이 오겠지만, 그런 것은 상관없다. 내가 그런 사소한 결과에 연연하려고 회사라는 울타리에 나를 가두어 놓고 있는 것은 아니기 때문이다. 하지만, 이런 상황은 파국으로 치닫던 첫 회사에서의 내 모습과 비슷하기 때문에, 끊임 없이 의심스럽고 두렵다. 간혹 20대때 겪은 5년여간의 슬럼프가 재현되는 것 같은 극도의 불안감이 엄습하기도 한다.

첫 회사에서 못다한 것들을 이 회사에서 시도하고 있다. 그것도 단 2개월만에. 솔직히 이것은 무모한 짓이며, 이 회사와 나만 놓고 이득을 논하자면 지극히 소모적이다. 하지만, 나와 미래를 놓고 보자면 결과는 다르다. 그리고 혹시라도 그 미래에 지금 이 회사가 함께 한다면 그 결과를 공유할 수 있을 것이다. 하지만, 그것까지 바라진 않는다. 나의 능력을 인정하는 사람들은 많았지만, 어느 누구도 그것을 펼쳐보일 수 있는 길을 열어주는 사람은 없었다. 이 회사도 마찬가지다.

아무튼 지금 나는 뭔가 잘 못되어 있긴 한데, 멈출 수는 없다. 돌격은 시작됐으므로. 약간은 흥미롭다. 항상 모든 일은 지켜보는 입장에서는 일말이라도 흥미롭기 마련이다.

No pain, no gain.
폐인이 되지 않고서 무언가 얻으려 하지 마라.
내 프로그램 개발 능력은 폐인 시절 가장 빛을 발했다.

처음

많은 사람들이 그랬으리라 생각되는데, 나 또한 어릴적 신문 등에 광고로 나온 8비트 컴퓨터와 게임팩들에 대한 동경을 가졌다. 가끔 컴퓨터가 있던 친구집에서 게임 하던 것 말고는 컴퓨터를 만질 수 있는 기회가 없었다. 내가 처음으로 컴퓨터를 그런대로 만질 수 있었던 것은 아마도 중2 때 선생님께서 여름 방학 중 보내주신 컴퓨터 교육 때였다. 뭐 그래봐야 하루에 한 두시간, 일주일동안 뿐이었지만. 그 때 강사들은 대학생들이었고, 베이식을 배웠는데, 내 이해 판단력이 모자랐던 것이 컸겠으나, 아무튼 그 분들도 잘 알지 못하면서 가르치지 않았나 생각된다. 나는 그 때 하던 게 무엇이었는지 도통알지 못했기 때문이다. 일주일 후 시험에서 아마 30점인가 맞았던 것 같다. 뭘하는 지 모르는데, 무슨 답을 쓰겠나.

그거 하난 기억난다. 아마도 이런 프로그램이었는데,

N% = 1
INC% = 1
DO
	FOR I% = 1 TO N%
		PRINT "*";
	NEXT
	IF N% = 1 THEN
		INC% = 1
	ELSEIF N% = 79 THEN
		INC% = -1
	END IF
	PRINT
	N% = N% + INC%
LOOP UNTIL INKEY$ = CHR$(13)

나는 한 줄 한 줄 프린트 문을 계속 써서 저런 효과를 내려했었다. 강사가 와서 얘기 하길, "이럴 땐 반복문을 써야지." ... 반복문 ? 반복문이 뭔데. 이런 정도였으니, 나는 영재는 아니었던가보다.

본격적으로 컴퓨터를 만질 수 있었던 건 92년 대학에 진학한 뒤였다. 학기 시작 전 사촌 누나에게 간단한 도스 명령과 워드 문서 작성법을 배웠다. 아마도 주부 컴퓨터반이었던 것 같다. 아무튼 그 때 배운게 학기 초에 조금 도움은 됐다. 그걸 배웠었다해도 난 여전히 프로그램 개발자와는 거리가 멀었고, 독수리 타법이었다. 하지만, 그 후로도 나는 자판 연습은 해본 일이 없다. 그런 건 영 흥미가 붙질 않았다. 그냥 수 년 동안 컴퓨터 자판을 치다보니, 한마리 독수리가 두마리가 되고, 나중엔 독수리 군단이 되기 시작했다.

기계 공학이 전공이었기 때문에, 학기 시작 전에 만난 선배들은 포트란이 필요하다고 얘기해줬었다. 그래서 포트란 책을 하나 샀다. 대충 이해는 됐지만, 책만 보면서 배울 수는 없는 일이었다. 첫학기가 시작되고, 선배들이 하는 얘기가 C 언어를 배워두는 게 좋다해서, 책을 한 권 샀다. 그 책은 나중에 잃어버려서, 그 책 이후로 다시는 C 문법 책을 사지 않게 된 계기가 되었다.

컴퓨터 프로그래밍에 관심은 아주 많았는데, 본격적으로 시작할 수 있는 계기가 없었다. 그렇다고 전공도 아니고, 전공에서 필요한 프로그래밍은 당시의 실력만으로 충분했으며, 주변 동기들보다는 월등했다. 하지만, 그건 우물안 개구리에 불과할 수밖에 없었다. 다행히도 선배들 중 프로그래밍에 관심있던 분들이 꽤 있어서, 간간히 새로운 배움을 갖는 계기가 있긴 했다. 그 중 가장 좋은 계기는 도스 인터럽트와 어셈블리어에 관한 책을 알게된 것이었다. 책 제목은 기억나지 않지만, 이 책으로 인해 하드웨어 프로그래밍을 이해할 수 있게 됐고, 나아가 그래픽 하드웨어 프로그래밍에 도전하게 했다. 그 때가 아마 대학 2학년 여름쯤이었나 싶다.

그 이후로 학과 공부와는 별개로 틈틈히 전산실에 남아 프로그래밍을 익혔다. 하지만, 내 개인 컴퓨터가 없었고, 실력도 부쩍 부쩍 늘어갔다고는 볼 수 없었다. 그나마 내 컴퓨터를 갖게 된 건 대학 3학년 초였다. 486 DX2 66 CPU, 800 MB HDD, 16 MB RAM 정도였는데, 그것이 지금까지 내가 개발이 무엇인지 조금이나마 깨달을 수 있도록 가장 많은 도움을 준 소중한 컴퓨터였다. 이 컴퓨터는 2000년 초까지 개발에 사용하다가 현재는 리눅스 라우터로 쓰고 있다.

내 컴퓨터가 생긴 이후로 조금 더 프로그램 개발에 몰두할 수 있었다. 3학년 부터는 프로그램 개발 관련 과목 프로젝트도 꽤 있었고, 4학년이 되면 졸업 논문도 작성해야 했다. 내가 프로그램 개발에 전력을 다하게 된 계기는 이 시점에서 마련됐는데, 선배들과 졸업 논문 등에 대해 얘기 하면서 고체 모델링 ( Solid Modeling )에 대해 알게 된 것이었다. 애초부터 나는 3차원 모델을 컴퓨터 프로그램으로 표현하는 것에 관심이 많았다. 그래서 이 계기는 아마도 운명적이었다. 3학년 여름 방학에 컴퓨터 그래픽스 책 부록에 나온 반 모서리 자료 구조를 기반으로 초기 구현을 시작했다. 3학년 겨울 학과 프로젝트로 오일러 연산과 간단한 그래픽 렌더링이 가능한 고체 모델러 엔진을 제출했다.

3학년 겨울 방학이 왔다. 친구집에 놀러갔다가 C 언어 책을 하나 발견하고는 빌려왔다. 일주일 뒤 돌려주기로 했기때문에, 나는 일주일동안 필사적으로 읽었다. 그것을 계기로 C 언어 문법의 많은 부분을 머리 속에서 정리할 수 있었다. 아무튼 이 책 또한 빌려 읽은 것이고 난 여전히 C 문법 책이 없다. 처음 산 책을 잃어버린 충격이 컸었나... :-) 그때 즈음 고체 모델링 관련 논문을 지도하던 교수님 수하로 들어갔다. 하지만, 얼마 후 의견이 맞지 않아 거기서 나오게 되었고, 경쟁심을 가지고 개발에 전념하게 만들었던 그 한마디를 선배에게 들었다.

"네가 이걸 할 수 있을 것 같냐...?"

정도였나. 돌이켜보면 이게 계기였다. 내가 개발자로 밥벌어먹고 살 수 있는 것도 이게 계기였다고 생각된다. 아무튼 다른 교수님 밑에서 로봇 동역학 및 퍼지와 관련된 논문을 제출하고 졸업했다. 군문제도 있었고 학점이 꽤 좋았기 때문에 진학을 마음먹고 공부를 시작했다. 하지만, 졸업 후 공부는 커녕 방안에 틀어박혀 개발에 몰두했다. 그 때처럼 미친듯이 개발해본 적은 없었다. 모든 버그는 이유를 설명할 수 있도록 단련했다. 반복되는 개발과 디버깅 속에 서서히 개발이 무엇인지 몸으로 깨닫기 시작했다. 내 프로그램 개발 체계의 대부분은 그 당시에 이루어졌다. 그리고 4개월 후 반모서리 기반 고체 모델링 라이브러리 초기작이 완성됐다. 그것은 고체 모델링의 꽃 불린 연산 기능을 포함하고 있었다.

군 문제에 몰리게 됐기 때문에 대학원에 진학했다. 그해 여름 방학때 나는 잡지사에 연락해서 기자를 불렀다. 그리고 고체 모델링 관련 기사를 보내주었다. 그 때 들은 풍문으로는 그 일이 있은 후, 내게 그 말을 했던 선배가 연구실에 와서는 내 프로그램을 실행시켜보았다고 한다. 나는 나만이 안고 온 짧지 않은 시간 동안의 승부를 그것으로 종결지었다. 그 선배는 나중에 두 번째 회사에서 다시 만났다. 다른 부서였는데다가 악감정은 전혀 없었다. 오히려 내게는 고마운 분이다. 고체 모델러는 첫회사 입사때 많은 도움을 줬다.

그 이후로 내 개발은 IMA 프로젝트와 Orion 프로젝트에 집중되었다. ( Orion 프로젝트 개발 진행 과정 ) 아마도 내가 암흑같은 20대 후반을 보내지만 않았더라도 Orion 프로젝트는 이미 완성 단계에 있을 지도 모르겠다. 여전히 포기하지 않았으므로, 조금 늦었을 뿐 달라진 건 없다. 내가 3류 개발자로서 돈을 받아가며 일할 수 있기까지를 되돌아보면, 나는 좋은 조건도, 좋은 능력도 없었던 것 같다. 오로지 열정과 집념의 몸부림만 있었을 뿐.

( 2005. 10 )

처음

이전 | 대문