임백준의 블로그

클릭은 딸깍이다

2006-04-14T20:41:40Z

오랫동안 글을 올리지 못했습니다. 그 동안 독감과 배탈로 고생을 하기도 했고, 아이들이 봄방학을 해서 여행을 다녀오기도 했습니다. 웹 2.0 혹은 시맨틱웹이라는 주제를 놓고 새 책을 쓰는 일을 시작해서 여유가 없기도 했습니다. 루슨트에서 일하던 시절에 웹어플리케이션을 개발했기 때문에 웹 2.0이 친근하고 의미있게 다가오기는 하지만 현재 개발하고 있는 프로그램은 웹어플리케이션이 아니기 때문에 개인적으로 새롭게 공부하고 연구해야 하는 일이 많아서 어려운 점도 많습니다.

얼마 전에는 10여년을 사용해오던 인터넷 익스플로러 브라우저를 버리고 파이어폭스 브라우저를 설치하고 여러가지 플러그인을 끼워 넣어보기도 했습니다. 새로운 도구나 기술을 받아들이는 속도가 다른 사람에 비해서 늦은 편이기 때문에 남들이 다 파이어폭스를 사용하는 동안 혼자 익스플로러를 사용하다가 이제서야 '전향'을 하게 되었습니다. 요 며칠 김중태씨의 <시맨틱웹>이라는 책을 흥미롭게 읽었는데, 책의 내용도 내용이지만 우선 영어로 되어 있는 용어를 우리말로 사용하는 그의 노력이 매우 인상적이었습니다. 몇 가지 예를 들자면,

파이어폭스 --> 불여우
프레임워크 --> 얼개
클릭 --> 딸깍

파이어폭스를 불여우로, 클릭을 딸깍으로 표현하는 그의 재치넘치는 한글사랑에 크게 감명을 받았습니다. 특히 '딸깍'이라는 우리말 표현을 보고 한참을 상쾌하게 웃었습니다. 나로서는 도저히 떠올리지 못할 표현이다, 고 생각하며 그 동안 이곳 저곳에 글을 쓰면서 우리말 표현에 대한 고민을 너무 게을리 한 것은 아닐까 반성을 해보기도 했습니다.

핑계

2006-02-23T12:09:39Z

작년 12월부터 진행중이던 새 릴리즈 작업에 점점 살이 붙고 새로운 기능이 추가되더니, 아예 출시일이 훌쩍 뒤로 연기될 정도로 덩치가 커지고 말았습니다. 프로젝트 일정을 관리하랴, 코딩을 하랴, 다른 사람들 일정을 챙기랴, 버그를 잡으랴, 정신이 하나도 없습니다. 이 와중에 맨하탄 한복판에 있는 뉴욕금융연구소에서 한 학기 동안 금융 과목을 수강하기로 했고, 올해 상반기 중에 쓸 책의 자료수집과 연구도 새롭게 시작했습니다. (또한 우리나라 국가대표 축구 시합을 챙겨서 보랴, 박지성이 출전한 맨체스터 유나이티드의 시합을 보랴, 재미있다는 한국 영화도 보랴, 사실은 이 쪽이 더 바쁩니다.)

이렇게 비명을 지르는 것에는 이유가 있습니다. <소프트웨어 산책>을 쓰고서 독자 여러분들과 가깝게 대화를 나누고자 시작했던 블로그에 생각보다 자주 글을 올리지 못하는 것이 부담으로 다가오기에, 핑계를 대려는 것입니다. 아마 이런 추세가 당분간 지속될 것 같은데, 오며 가며 이 곳에 들리는 분들께는 죄송한 마음뿐입니다. 상황이 나아지면 더 자주 글을 올리도록 하겠습니다.

2006년도 벌써 1/6이 지나갔습니다. 참 빠르게 지나가는 시간입니다.

새해 복 많이 받으세요

2006-01-28T21:15:51Z

설날입니다. 미국에 처음 와서는 설날이나 추석이 되면 어쩐지 마음이 설레이곤 했는데, 이제는 그런 감흥이 많이 사라졌습니다. 심지어 설날이 언제인지를 겨우 알게 될 정도가 되었습니다. 그래도 설날은 설날입니다. 미국에서는 이 날이 차이니스 뉴이어(Chinese New Year)라고 알려져서 중국 프로그래머가 많은 곳에서는 제법 축하하는 분위기가 나기도 합니다.

저는 올해 공부를 새롭게, 열심히 해보기로 다짐을 했습니다. 많은 것이 익숙해져서 자칫 매너리즘에 빠지기 쉬운 때이기 때문입니다. 프로젝트를 관리하고, 새로 입사한 프로그래머를 도와주고, 현장에 나타나는 문제를 해결하는 등의 일을 하다가 새로운 기능을 개발하기 위해서 모처럼 조용히 프로그래밍을 하기 위해서 자리에 앉으면, 키보드에 닿는 손끝의 감촉부터 확 달라지는 것이 느껴집니다. 그리하여 올해는 프로그래밍도 많이 하고, 공부도 많이 하는 한해로 만들기로 했습니다. 여러분들도 새해의 복을 많이, 듬뿍, 크게 받으시기 바라고, 공부도 열심히 하시기 바랍니다.

회사 이야기 2

2006-01-16T21:51:31Z

지금까지 주로 앞에서 말씀드린 CDS를 대상으로 했던 트레이딩 시스템을 본격적으로 채권(Bonds) 트레이딩 시스템으로 확장하는 프로젝트가 진행되고 있습니다. 경제적인 배경 지식이 있는 사람은 알겠지만 채권 시장은 전 세계의 회사, 정부, 도시, 기관 등에서 발행하는 모든 종류의 채권을 포함하고, 우리가 흔히 알고 있는 모기지론이나, 크레딧 카드빚에 이르는 온갖 종류의 '빚(debt)'을 포함합니다. 흔히 (서양인들의 관점에서) '발견의 시대'라고 불리우는 15, 16세기의 항해나 탐험이 나라에서 발행한 채권의 힘으로 이루어지고, 세계 1차 대전 당시 영국, 프랑스, 독일 등이 전쟁비용을 조달하기 위해서 막대한 량의 전시 채권을 발행해서 미국의 힘을 키워준 것은 널리 알려진 사실입니다. 역사나 규모라는 면에서 채권 시장은 주식 시장을 압도하며 현대 자본주의 시장 상황의 움직임과 건강을 드러내는 척도로 활용되기도 합니다.

이런 채권에 대해서 신문을 읽으면서 파편적인 지식을 얻을 수밖에 없었던 저로서는 사실 본격적인 채권 트레이딩 시스템을 만들어 나가기가 어려운 것이 사실입니다. 다른 프로그래머들을 돌보면서(mentor) 프로젝트를 수행해야 하는 제 입장에서 시스템이 다루는 내용을 정확히 알지 못할 때 곤란하게 다가오는 점이 한 두 가지가 아닙니다. 그리하여 올 봄에 맨하탄 복판에 있는 뉴욕 금융 연구소(New York Institute of Finance)에서 한 학기 동안 채권 트레이딩(Bond Trading)이라는 과목을 수강하기로 했습니다. 등록금은 물론 회사에서 내주는 것인데, 과목 자체가 프로그래머나 IT 관련 사람이 수강하는 과목이 아니라 주로 막 MBA를 마쳤거나 학교를 졸업하고 월스트리트의 금융가에 트레이더로 진출하는 사람들이 듣는 과목이라 개인적으로 준비를 해야 할 일이 많습니다.

이 모든 것을 하나의 <게임>으로 바라보았을 때, 채권의 흐름과 그 배후에 있는 온갖 수학 공식이 가지고 있는 역동성과 정교함은 높은 지적인 흥미를 줍니다. 그리하여 역동성을 포착해서 하나의 컴퓨터 시스템으로 재창조하는 과정은 그 자체로 하나의 신나는 놀이가 될 정도입니다. 문제는 시스템을 통해서 전 세계를 돌고 도는 천문학적인 숫자들이 담고 있는 수 하나 하나에 지구촌 어디엔가 살고 있는 구체적인 사람들의 피와 땀과 눈물이 스며들어 있다는 엄연한 진실입니다. 월스트리트의 사람들은 직간접적으로 그러한 진실에 눈이 멀도록 끊임없이 훈련을 받습니다. 그 훈련이 제 눈마저 멀게 하지 않도록 정신을 차리고 있어야 하겠다는 생각을 해보았습니다.

프로그래머 "논쟁의 법칙"

2006-01-14T12:18:57Z

(마이크로소프트웨어 2004년 2월호)

썬마이크로시스템즈의 제임스 고슬링은 자바 언어를 개발한 것으로 널리 알려진 프로그래머이다. 장난기 넘치는 웃음을 머금고 있는 그의 모습은 밝아서 얼굴만 봐서는 나이를 가늠하기가 쉽지 않다. 하지만 금발이 찰랑거리던 젊은 시절의 모습과 달리 세월의 무게에 밀려 뒤로 벗겨진 머리는 C++ 언어를 개발한 뱐 스트라우스트럽을 닮았고 턱 밑에 수북한 수염은 C 언어를 개발한 데니스 리치를 닮았다.

캐나다의 캘거리 대학에서 컴퓨터공학을 공부하고 미국의 카네기 멜론 대학에서 컴퓨터공학 박사를 획득한 고슬링은 말하자면 ‘엘리트 코스’를 제대로 밟은 프로그래머였다. 야전(野戰)을 통해서 실력을 쌓은 해커들과 달리 탄탄한 제도권 안에서 내공을 쌓은 그가 훗날(처음에 비해서 의미가 모호해지긴 했지만) 해커라는 이름으로 불릴 수 있게 된 까닭은 대부분 자바 언어 덕분이었다. 개인용 PC 운영체제 시장을 독점한 MS의 전횡에 지친 프로그래머들에게 특정한 운영체제에 구애받지 않는 자바 언어는 ‘해방군’처럼 느껴졌기 때문이다.

소프트웨어 발명가

여담이지만 1991년에 썬 마이크로시스템즈의 프로그래머 13명이 모여서 차세대 셋톱 TV를 위한 기술을 개발하는 ‘그린 프로젝트’가 자바 언어의 탄생 배경이었다는 사실은 유명하다. ‘그린 팀’의 목적은 새로운 언어를 개발하는 것과 거리가 멀었으며 자바는 다만 프로젝트의 진행을 돕기 위해서 고안된 프로그래밍 도구에 불과했다. 그런 자바가 90년대에 C와 C++의 아성에 도전하는 새로운 프로그래밍 언어로서 성공을 거두게 된 데에는 인터넷이라는 환경이 작용한 바가 크지만, 당시 프로그래머들 사이에서 더 명료한 객체지향 언어에 대한 요구가 존재했기 때문이기도 하다.

자바의 성공에 자극받은 MS는 C++의 뒤를 잇는 객체지향 언어인 C#을 발표했지만 이미 자바대 비(非)자바의 양강 구도로 정착된 대세를 바꾸기에는 역부족이었다. 제임스 고슬링은 MS가 C# 언어를 준비하고 있다는 소식을 처음 접했을 때 몹시 긴장할 수밖에 없었다고 고백했다.

하지만 C# 언어가 모습을 드러낸 이후인 2002년 1월에 CNET과의 인터뷰를 할 때에는 C#을 일컬어서 “안정성(reliability), 생산성(productivity) 그리고 보안성(security)을 제거한 자바 언어에 불과하다”고 일축했다. 뿐만 아니라 자바를 폄하하던 MS가 뒤늦게나마 자바와 비슷한 언어를 설계했다는 것은 결국 “자바에 대해서 최대의 찬사를 보낸 것”이라고 말하여 익살을 부리기도 했다.

고슬링은 자바의 초기 문법 구조를 설계하고 컴파일러와 자바 가상기계를 구현한 핵심 프로그래머였기 때문에 흔히 ‘자바의 발명가(Inventor of Java)’라고 불린다. 자바를 발명한 것은 분명히 제임스 고슬링 한 사람이 아니었지만 C의 데니스 리치와 C++의 뱐 스트라우스트럽처럼 고슬링의 이름 앞에는 항상 자바가 따라다니게 되었다. 프로그래밍 언어가 아니더라도 유닉스의 켄 톰슨, 리눅스의 리누스 토발즈, 넷스케이프의 마크 엔드리슨, GNU의 리차드 스톨만처럼 한 시대를 풍미한 소프트웨어의 ‘발명가’로 불리는 것은 프로그래머에게 있어서 무엇과도 바꿀 수 없는 최고의 영광임에 틀림없다(GNU는 물론 한 개의 소프트웨어가 아니다).

프로그래머들의 논쟁

그래서 프로그래머들은 종종 특정한 소프트웨어나 알고리즘의 구현을 둘러싼 ‘크레딧(credit)’을 놓고 격렬한 논쟁을 벌이기도 한다(철학자 헤겔이 말했던 ‘인정 투쟁’을 벌이는 셈이다). 리누스 토발즈의 자서전인 ‘리눅스 그냥 재미로(Just For Fun)’에서 소개된 리누스 본인과 앤드류 타넨바움 사이의 논쟁은 건설적인 논쟁의 예가 된다.

운영체제 학습을 위한 소형 운영체제였던 미닉스의 저자 타넨바움과 새롭게 부상하는 차세대 운영체제인 리눅스를 설계한 토발즈가 ‘마이크로 커널’과 ‘모놀리틱 시스템’의 장단점을 놓고 한판 논쟁을 벌이는 과정은 논쟁의 내용을 떠나서 그 자체로 많은 사람들에게 흥분과 관심의 대상이 되었다(그리고 이 논쟁은 서로에 대한 예의를 잃지 않은 적정한 선에서 정리가 되었다).

그러나 프로그래머 사이의 논쟁은 때때로 감정을 자극하는 파괴적인 다툼으로 발전하여 서로에게 상처만 입히는 싸움으로 끝나는 경우도 많다(크레딧을 둘러싼 이러한 다툼은 유명한 프로그래머 사이에서만 일어나는 일이 아니다. 필자와 같은 평범한 프로그래머, 특히 회사에서 월급을 받으며 생활하는 프로그래머에게 있어서 크레딧을 잘 관리하고 논쟁의 수위와 방향을 조절하는 능력은 프로그램을 잘 짜는 일 못지않게 중요하다).

유닉스 환경에서 vi와 함께 널리 사용되는 문서 편집기인 이맥스(Emacs)를 둘러싸고 제임스 고슬링과 자유 소프트웨어 운동의 대부(代父) 리차드 스톨만 사이에 있었던 크레딧 논쟁은 수위가 잘못 조절되어 파국으로 끝난 잘못된 논쟁의 예에 속한다.

스톨만이 지난 1986년에 스웨덴에 있는 대학에서 강연할 때 이맥스와 관련해서 다음과 같은 일화를 밝힌 적이 있다. 다음은 GNU의 웹 사이트에 있는 원고에서 강연 내용의 일부를 발췌하여 내용을 일부 번역한 것이다.

“두 해 전에 한 친구가 자신은 고슬링 이맥스의 초기 개발에 관여했기 때문에 고슬링이 자기에게 이맥스를 배포할 수 있는 권리를 허락했다고 말했다. 고슬링은 내가 원래 이맥스를 가지고 시작했던 철학을 따르겠다는 입장을 취했기 때문에 많은 사람들의 협력을 구할 수 있었다. 그렇지만 그는 자신의 소프트웨어에 카피라이트를 적용함으로써 모든 사람들의 등에 칼을 꽂았다. 아무도 그것을 재배포할 수 없도록 만든 다음 자신은 그것을 한 소프트웨어 회사에 팔아넘겼다. 내가 고슬링과의 개인적인 교류를 통해서 확인한 것은 바로 이와 같은 사실로부터 알 수 있듯이 그가 비열하고 천박한 종류의 인간이라는 점이었다.”

프로그래머 중에서 리차드 스톨만을 모르는 사람은 거의 없을 것이다. 또한 유닉스 환경에서 프로그래밍을 하는 사람이라면 GNU에서 개발하여 무료로 배포하는 소프트웨어 도구를 한 번쯤 사용하지 않았을 가능성이 거의 없다. 오픈소스 운동보다 먼저 시작된 자유 소프트웨어 운동의 지도자에 해당하는 스톨만은 ‘자유’와 ‘저항’이라는 해커 정신의 핵심을 포기하지 않았기 때문에 프로그래머들보다 오히려 인터넷이나 사이버스페이스 같은 열쇠 말을 연구하는 사회학자나 철학자에게 더 많이 알려져 있을 정도이다.

많은 사람들에게 크레딧을 받고 있는 스톨만은 이렇게 강력한 어조로 또 다른 일군의 프로그래머들에게 ‘리더’로서의 존경을 받는 제임스 고슬링을 비판했다. 이러한 스톨만의 비판에 대해서 고슬링의 입장을 변호하는 사람들은 스톨만이 GUI는 물론 마우스의 사용까지 혐오하는 고지식한 ‘텍스트 모드’ 마니아이며, 고슬링은 따라서 스톨만이 제작했던 조야한 초기 버전을 사용자들에게 더 친숙한 소프트웨어로 개선할 수밖에 없었다고 항변했다.

그리고 그에 덧붙여서 스톨만은 (GNU/Linux의 예에서 볼 수 있듯이) 자기가 조금도 관여하지 않은 소프트웨어를 통해서 크레딧을 얻으려고 애를 쓰며, 다른 사람이 자기보다 성공하거나 주목받는 것을 견디지 못하는 속 좁은 인간이라는 인신공격에 가까운 비판을 퍼부었다.

이런 식의 주장은 이미 기술적인 측면에 초점을 두는 건설적인 논쟁의 궤도를 벗어나서 서로의 철학과 정치적 입장 혹은 인간성에 대한 비판으로 나아가는 위험천만한 다툼에 해당한다. 양쪽의 주장이(구체적으로 입증할 수 없는 근거를 기초로 해서) 팽팽하게 맞서고 있기 때문에 사람들은 누구의 말을 들어야 할지 쉽게 판단하기 어렵다. 따라서 사람들 중에는 이맥스의 ‘발명가’를 스톨만으로 알고 있는 사람도 있고 고슬링으로 알고 있는 사람도 있다.

하지만 이와 같은 경우에는 크레딧을 누가 가져가든 당자를 제외한 3자에게는 아무 의미가 없다(스톨만의 비판은 고슬링이 자유 소프트웨어 정신을 배신했다는 점에 핵심이 놓여 있다. 반면 고슬링 쪽에서는 스톨만이 크레딧에 집착한 나머지 다른 사람의 정당한 공헌을 왜곡한다는 점, 그리고 절실히 요구되는 기술적 개선을 외면한다는 점을 지적하고 있다. 하지만 이런 것은 차원이 다른 문제이다. 이맥스의 주인공이 스톨만이든 고슬링이든 사용자들은 개의치 않는다!).

논쟁의 수위 조절

프로그래밍은 속성상 다른 분야의 일에 비해서 ‘공(功)’과 ‘과(過)’가 비교적 뚜렷하게 구분된다. 예를 들어서 고객이 사용하고 있는 소프트웨어에 중대한 결함이 생겨서 일정한 기간 내에 결함을 반드시 수정해야 하는 경우가 발생했다고 하자. 이 경우 문제가 간단하게 해결될 수 있는 성질의 것이 아니라면 실력이 뛰어난 프로그래머 몇 사람이 달라붙어서 밤을 새우며 디버깅을 해야 할 지도 모른다.

이 때 문제를 해결한 사람은 영웅이 되고 그 문제를 야기한 코드의 주인공은 졸지에 역적이 된다. 약간 과장된 표현이긴 하지만 프로그래밍을 하는 사람이라면 영웅이 되는 우쭐한 기분도, 역적으로 내몰리는 서글픈 기분도 맛본 적이 있을 것이다.

필자가 일하는 프로젝트의 구성원들은 미국에 있는 직원들과 영국에 있는 직원들이 반씩 섞여 있기 때문에 대개 5~6시간의 시차를 두고 일을 한다. 아무래도 얼굴을 맞대고 있는 사람들끼리 나누는 의사소통이 편하기 때문에 소프트웨어를 몇 개의 큼직한 컴포넌트로 나눈 다음, 몇 개는 미국 부서에서 구현하고 나머지 몇 개는 영국 부서에서 구현한다.

이렇다 보니 사용자 필드에서 치명적인 문제가 보고 되었을 때 문제의 원인이 어느 컴포넌트에 존재하는지를 규명하는 일은 항상 (두 지역의 프로그래머 사이에서) 심각한 수준의 논쟁을 수반한다. 이 때 필자가 늘 마음속으로 긴장하면서 노력하는 것은 논쟁의 ‘수위’를 알맞게 조절하여 합리적인 결론을 도출하는 일이다.

필자와 함께 일하는 미국 친구 중 한명은 매우 뛰어난 프로그래밍 실력을 갖추고 있음에도 불구하고 이와 같은 논쟁의 상황이 전개되면 쉽게 이성을 잃고 흥분하여 크레딧을 스스로 까먹는 경우가 많다. 유심히 살펴보면 프로그래밍 실력이 뛰어나고 자아가 강한 사람일수록 자기의 의견에 맞서는 논쟁을 견디지 못하는 경우가 더 흔하다. 이런 사람들은 쉽게 흥분하여 합리적인 근거에 입각한 주장보다 인신공격에 가까운 표현을 구사하여 논쟁의 발전적 가능성을 차단시킨다.

필자는 스톨만을 매우 존경했고 지금도 존경하고 있지만, 그가 자바에 대해서 비교적 냉담한 자세를 취하는 이유의 상당 부분이 고슬링과의 개인적인 악연에 기인한다는 주장을 (어느 곳에선가) 읽고 크게 실망한 적이 있었다. 논쟁을 논쟁 자체로 끝내지 못하고 그 이후의 개인 감정으로 끌고 들어오는 것은 상당히 잘못된 일이기 때문이다.

논쟁도 즐겨라

결론을 내려 보자. 지난 컬럼에서 필자는 ‘기쁨’이 있는 프로그래머와 그렇지 않은 프로그래머 사이에는 큰 차이가 있을 수밖에 없다고 말했다. 예술적 창의력이 있는 사람과 없는 사람의 차이에 대해서도 언급했다(참고로 지난 글의 말미에서 분명히 밝혔음에도 불구하고 필자가 ‘설계에 앞서는 코딩이 예술이다’ 혹은 ‘코딩이 설계에 앞서야 한다’고 주장한다고 잘못 이해한 사람도 있었다. 상대방의 이야기를 이렇게 엉뚱하게 이해하는 것도 잘못된 논쟁 방식의 예가 된다!).

이번에 이야기하고자 하는 내용은 ‘논쟁’을 건설적으로 이끌어 가며 즐길 수 있는 프로그래머와 그렇지 않은 프로그래머 사이에는 시간이 흐르면 큰 차이가 생길 수밖에 없다는 점이다. 자신의 의견에 맞서는 ‘논쟁’을 고맙게 생각하여 힘껏 즐기고 또한 (지위 고하를 막론하고) 자신의 생각과 다른 의견에 대해서 끊임없이 의심하여 논쟁을 제기하기를 두려워하지 말 일이다. 예의를 잃지 않는 논쟁은 프로그래밍 실력을 키우는 가장 큰 지름길이기 때문이다.@

프로그래밍은 예술이다

2006-01-14T12:09:18Z

(마이크로소프트웨어 2004 1월호)

필자는 프로그래밍을 비교적 늦은 나이인 이십대 중반에 시작했다. 따라서 독학을 통해서 익힌 ‘초식’이 많았는데 그래서인지 10년이 지나도록 잘 고쳐지지 않는 습관이 하나 있다. 머리 속에 알고리즘의 윤곽이 떠오르면 일단 키보드를 붙잡고 코드를 두드려야만 직성이 풀리는 것이다. 그렇게 하지 않으면 다음 내용이 잘 떠오르지 않는다. 프로그래밍 방법론이나 소프트웨어 공학의 충고에 의하면 이것은 ‘코딩’이 ‘설계’에 앞서는 대단히 잘못된 방법에 속한다. 교과서에 적힌 기본을 무시하는 철저한 아마추어리즘의 소산인 것이다.

프로그래밍의 맛

여러 명의 개발자가 함께 코딩을 하는 경우에는 물론 얘기가 다르다. 그런 경우에는 레쇼날 로즈(Rational Rose) 같은 소프트웨어나 객체 설계용 언어인 UML을 이용해서 어느 정도 설계를 마친 다음에 코딩을 시작할 수밖에 없다. 하지만 프로그래밍을 혼자서 할 때는 언제나 ‘코딩’이 ‘설계’를 앞선다. “진정한 ‘프로’는 설계를 마친 다음에 비로소 키보드를 잡는 거야”라고 아무리 말해도 소용이 없다. 커피를 마실 때 크림을 넣지 않으면 맛이 느껴지지 않는 것처럼 손끝에 전달되는 키보드의 감촉이 없으면 프로그래밍의 ‘맛’이 느껴지지 않는다.

이런 습관은 회사에서 수행하는 공식적인 프로그래밍에도 종종 연결된다. 외부의 API가 모두 결정된 상태에서 독립적인 컴포넌트의 내부를 구현하는 경우에는 예외 없이 코딩에서 부터 설계가 시작된다. 화면에 뜬 편집기(필자의 경우에는 주로 vi)라는 캔버스 위에 키보드 커서라는 연필을 조금씩 움직여 나가면 머리 속에 감추어져 있던 알고리즘이 서서히 눈앞에 모습을 드러낸다. 때로는 종이 위에 동그라미, 네모, 선 등을 그리면서 설계를 하는 경우도 있지만 그것은 어디까지나 키보드를 통해서 하는 붓질을 돕는 보조적인 조치일 뿐이다.

프로그래밍에 ‘조예’가 있는 개발자라면 이런 습관은 그다지 자랑할 바가 아니라고 생각할 것이다. 당연하다. 필자도 아주 최근까지 그렇게 생각했다. 그렇지만 프로그래머 중에서 이와 같은 습관을 가지고 있는 사람이 적지 않으리라는 점은 분명하다. 손끝에 키보드의 감촉이 전달될 때 비로소 프로그래밍의 맛을 느끼는 사람은 결코 필자에 국한되는 얘기가 아닐 것이다.

하지만 그런 사람들조차 대부분 ‘설계’에 앞서는 ‘코딩’은 자랑할 바가 아니라고 생각한다. 특히 프로그래밍 실력이 뛰어난 고수일수록 설계를 마치기 전에는 키보드를 넘실거리지 않을 것이라고 믿는다. 뒤집어 말하면 설계를 끝내기 전에 키보드를 만지작거리는 사람은 일종의 ‘하수’로 간주되는 셈이다.

프로그래밍 예술론

필자가 이와 같은 ‘설계’와 ‘코딩’의 관계를 포함하여 흔히 알려진 프로그래밍의 방법론이나 소프트웨어 공학의 ‘교리’를 의심하기 시작한 것은 (지난 해에 두 권의 책을 쓰면서) 프로그래밍의 본질이 ‘공학’에 있는가 아니면, ‘예술’에 있는가 하는 문제를 고민하면서부터였다.

프로그래밍이 도대체 예술일 수 있는가에 대한 답을 구하려면 우선 예술이 무엇을 의미하는지 이해해야 하는데 그것은 간단하지 않은 주제이므로 여기서 다루기 어렵다. 하지만 한 가지 분명한 것은 필자의 관점에서 볼 때 프로그래밍은 공학적 요소를 포함하고 있긴 하지만 분명히 예술에 더 가깝다는 점이다.

프로그래밍을 예술로 파악하는 것은 물론 새로운 관점이 아니다. 「프로그래밍의 예술(The Art of Computer Programming」로 유명한 스탠포드 대학의 도날드 카누스 교수는 일찍이 「문학적 프로그래밍(Literate Programming)」이라는 책에서 ‘프로그래밍은 예술’이라고 선언한 바 있다. 그는 이러한 선언을 한 걸음 더 밀고 나아가 프로그램 소스 코드도 다른 예술 작품들과 마찬가지로 미학적 요소와 독창성을 고려해서 ‘값’이 매겨지는 시대가 도래할 것이라고 예언하기까지 했다.

문학적 프로그래밍이란

카누스 교수가 말한 ‘문학적 프로그래밍’이란 사실 단순한 비유에서 그치는 것이 아니라 코드의 예술성을 담보하기 위한 일종의 구체적인 프로그래밍 방법론이었다. 우리나라에서는 「생각하는 프로그래밍」이라는 책으로 번역된 ‘프로그래밍 펄(Programming Pearl)’로 유명한 존 벤틀리는 카누스 교수가 ‘문학적 프로그래밍’을 설명한 글을 읽고 감명을 받은 나머지 자신의 컬럼 몇 개를 카누스 교수의 새로운 방법론을 소개하는데 바치기도 했다.

‘프로그래밍은 예술’이라는 명제는 사실 수학 명제처럼 명쾌하게 증명될 수 있는 것이 아니다. 그러나 프로그래밍을 하는 사람이라면, 그 ‘맛’을 조금이라도 아는 사람이라면, 이 명제를 간단하게 거부하지 못할 것이다. 오픈소스 프로젝트에 참여하여 자신의 여가시간마저 프로그래밍에 바치는 해커든, 아니면 회사에 출퇴근하면서 정해진 틀에 따라 코딩을 하는 ‘월급쟁이’이든 상관이 없다.

프로그래밍이 단순히 기술이나 공학의 수준에 머무르지 않는다는 사실은 누구에게나 분명하다. 프로그래밍이라는 행위 안에는 꼭 집어서 설명할 수 없지만 가슴이 떨리고 흥분이 밀려오는 ‘창조적 긴장’의 순간이 담겨 있기 때문이다.

카누스 교수는 스스로 수학적 논리와 알고리즘에 대해서 실로 심오한 내공을 갖추고 있었다. 그런 맥락에서 그는 프로그래밍이 가지고 있는 ‘과학적 미학’의 측면을 강조했다. 이에 비해서 폴 그래이엄은 프로그래밍에 담겨 있는 ‘창조적 미학’의 측면을 날카롭게 부각시켰다. 그래이엄은 하버드에서 컴퓨터 공학 박사 학위를 받고 인공지능 언어인 LISP에 대한 교과서를 쓸 정도로 내공이 중후한 프로그래머였다. 뿐만 아니라 인터넷 붐이 한창이던 1998년에 ViaWeb이라는 회사를 야후에 팔아서 ‘비즈니스맨’으로서도 이름을 얻었다.

그래이엄은 프로그래밍에 담긴 예술의 측면을 설명하기 위해서 프로그래밍을 그림 그리는 행위에 비유했다. 앞에서 그를 소개하면서 내공이 중후한 ‘프로그래머였다고’ 말한 이유는 그가 지금은 그림(painting)을 공부하여 화가의 길을 걷고 있기 때문이다.

그가 보기에 프로그래밍은 순수한 논리나 학문의 대상이라기보다는 ‘실천적 행위’를 통해서 몸에 익혀 가는 구체적인 ‘행동’에 가까웠다. 그것은 마치 텅빈 백지 위에 붓을 한 번 크게 긋는 행위와 다를 바 없었다. 그래서 그는 컴퓨터 과학이라는 표현이 프로그래밍의 진정한 속성을 정확하게 담지 못한다고 비판했다.

프로그래밍이 ‘컴퓨터 과학’ 혹은 ‘컴퓨터 공학’과 같지 않은 이유는 그림을 그리는 예술적 실천이 물감의 화학적 배합을 연구하는 ‘학문’과 같지 않은 이유와 동일하다. 다시 말해서 그림을 그리는 화가는 물감의 화학적 성분이나 여러 화학 이론에 대해서 굳이 알 필요가 없다.

이와 마찬가지로 프로그래밍이라는 창조적 활동을 하는 사람(즉, 프로그래머)들은 컴퓨터 과학과 공학의 수많은 이론을 굳이 자세하게 알 필요가 없다. 예를 들어서 튜링 기계나 오토마타의 개념 정도는 알 필요가 있을지 몰라도 복잡성 이론(complexity theory)에 등장하는 명제를 모두 읽어야만 좋은 프로그램을 만들 수 있는 것은 아니다.

코딩이 설계에 앞선다?

그래이엄을 알기 전까지 필자는 ‘코딩’이 ‘설계’를 앞서는 습관을 ‘아마추어리즘’의 표현이라고 생각해 왔다. 진정한 프로라면 교과서에서 가르치는 대로 정확하게 설계를 마친 다음 비로소 코딩을 시작해야 하는 것이라고 생각했다. 이런 강박관념은 일종의 열등감마저 수반했는데 그래이엄의 통찰은 필자를 ‘예술’이라는 아름다운 이름과 함께 구원해 주었다.

프로그래밍을 예술로 바라보는 관점에서 생각해 보면 ‘판에 박힌 듯한’ 소프트웨어 개발 방법론은 프로그래머 개개인의 감성을 존중하기보다는 정해진 틀에 맞는 상품을 생산하기 원하는 기업의 욕망을 반영하고 있다. ‘획일적인 틀’은 상품 생산을 위해서 필요할 뿐 진정한 창조와 아무런 상관이 없기 때문이다.

뛰어난 프로그래머였던 그래이엄은 자기 자신도 프로그래밍을 할 때 키보드를 붙잡고 코딩부터 시작한다고 고백했다. 그가 밝힌 방법은 우선 가볍게 키보드를 두드리면서 코드의 전체 윤곽을 잡고, 다시 처음으로 돌아가서 조금씩 각 부분의 디테일을 살려 나가는 방식으로 프로그램을 작성하는 것이었다. 그는 코딩이 설계에 앞서는 이와 같은 방식을 조금도 이상하게 여기지 않았다. 오히려 그는 모든 예술적 창조가 대개 이와 비슷한 과정을 거치면서 이루어지며 그림을 그리는 과정도 이와 다르지 않다고 말했다. 그리고 미술에서는 그것을 ‘스케치’라는 자연스러운 이름으로 부른다고 지적했다.

혹시 필자가 이 글을 통해서 ‘코딩은 설계에 앞서야 한다’는 명제를 주장하고 있다고 잘못 이해하지 않기 바란다. 그것은 손으로 달을 가리켰더니 손가락만 바라보더라는 이야기와 다를 바 없는 오해가 될 것이다. 여러 명이 함께 복잡한 소프트웨어를 만들 때 ‘설계’의 과정이 결정적으로 중요하다는 사실에는 이견이 있을 수 없다. 다만 필자는 소프트웨어의 ‘생산성’을 높이기 위한 방법론이 반드시 프로그래밍의 ‘예술성’을 강화시키는 쪽으로 작용하지 않는다는, 아니 정확하게 말하자면 그 반대의 방향으로 작용한다는 사실을 지적하고 싶었을 뿐이다.

그럼 프로그래밍의 ‘예술성’을 강조하는 프로그래머는 그렇지 않은 프로그래머에 비해서 소프트웨어 ‘생산성’이 떨어지는 것일까? 놀랍게도 전혀 그렇지 않다. 오히려 그 반대의 경우가 더 많다. 창조의 기쁨을 아는 사람과 그렇지 않은 사람이 발휘하는 능력에는 본질적인 차이가 존재하기 때문이다. 필자가 이 글을 통해서 말하고 싶은 것이 바로 그 차이이다. ‘기쁨’이 있는 사람과 없는 사람 사이에 존재하는 차이는 프로그래밍의 예술적 속성을 이해하는데 있어서 핵심적인 열쇠가 된다.

회사 이야기 1

2006-01-10T11:14:26Z

제가 회사에서 개발하고 있는 소프트웨어는 CDS(Credit Default Swap)라고 불리는 금융 상품과 채권(Bond)을 실시간으로 사고파는데 사용되는 트레이딩 시스템입니다. 현대 자본주의 시스템은 많은 부분이 위험(Risk)이라는 개념을 통해서 설명이 됩니다. 예를 들자면 돈에 붙는 '이자' 같은 것도 위험이라는 개념으로 설명을 할 수 있습니다. 돈을 빌려주면서 위험을 부담하는 대신 받는 대가를 이자라고 볼 수 있는 것입니다. 정부나 회사가 발행하는 채권(Bond)도 그것을 구입하는 사람은 일정한 위험을 떠안는 것이기 때문에 돈(프리미움)을 지불받고, 집을 사는 사람에게 모기지론을 대출해주는 은행도 위험을 부담하는 대신 이자를 받습니다. 무디스와 S&P 같은 신용평가기관이 매기는 '신용' 혹은 크레딧이라는 개념도 결국 특정 회사나 국가에 투자를 하거나 돈을 빌려주었을 때 발생하는 위험의 정도를 나타내는 척도라고 볼 수 있습니다.

CDS라는 것은 바로 이러한 '위험'에 대한 보험이라는 개념으로 생각을 하면 쉽습니다. 만약 내가 삼성전자에서 발행한 채권을 10억원어치 구입을 했다고 하면, 그 10억원이라는 투자 자본은 삼성이 시장에서 가지고 있는 위험의 정도, 혹은 신용의 수준에 전적으로 의존하게 됩니다. 이 때 내가 삼성의 채권은 그대로 보유하고 있으면서, 삼성의 신용 수준에 의존하는 경향을 배제하거나 완화하고 싶으면 CDS라는 상품을 구입하여 그에 대한 보험을 들 수 있습니다. 즉, 삼성전자의 채권을 대상으로 하는 CDS 상품을 구입하면 때마다 일정 금액을 보험료로 지불하지만, 만약의 사태에 삼성전자가 부도가 나거나 파산을 하는 경우 채권 금액의 전부를 보상받을 수 있도록 계약을 맺는 것입니다.

여기까지는 이해하기가 별로 어렵지 않은데, 이 CDS라는 녀석들이 보험의 의미를 벗어나서 단순히 돈놓고 돈먹기의 대상으로 전락하게 되고, 그 위에 인덱스다, 트랜치다, 합성 CDO다 하는 기기묘묘한 '금융 공학'이 동원되기 시작하면 머리가 쥐가 나지 않을 수 없게 됩니다. 뿐만아니라 트레이더와 브로커들이 구사하는 트레이딩 기법을 그대로 소프트웨어에 반영하려면 대단히 정교하고 복잡한 알고리즘을 구사해야 하기 때문에 루슨트 시절에 다루던 네트워크 원리와 기법이 오히려 단순하게 느껴질 정도입니다. 놀라운 것은 전혀 들어보지 못하던 CDS라는 상품이 거래되는 시장의 규모가 2004년에 1.6 Trillion 달러였고, 2006년에는 10배가 늘어난 16 trillion 달러가 되리라는 사실입니다. 16 트릴리온 달러면 우리돈으로 16000 곱하기 1조, 즉 1.6경원에 달하는 천문학적인 숫자입니다.

CDS라는 금융 시장의 급팽창과 월스트리트 트레이딩 시장의 전반적인 소프트웨어화라는 경향이 맞물리면서 CDS나 채권을 다루는 트레이딩 시스템에 대한 수요와 사용자 수는 최근 몇 년 사이에 급격하게 늘어나고 있는 실정입니다. 그리하여 여러 경쟁업체들과 소프트웨어의 품질을 놓고 경쟁하는데 따르는 압박감은 부담이 되는 한편으로 좋은 자극이 되기 때문에 나쁘지 않지만, 투기 자본이 지구촌 곳곳을 돌아다니면서 야기하는 비극을 생각하면 프로그래머로서의 양심에도 압박과 긴장이 떠나지 않습니다. 정체가 쉽게 드러나지 않는 헤지펀드가 CDS 시장의 40% 정도를 차지하고 있다는 사실은 이것이 이미 보험이라는 본래의 의미로가 아니라 평균을 상회하는 이윤에 굶주린 투기꾼들의 도박판으로 이용되고 있음을 나타내는 것입니다.

2006년 새해

2006-01-09T08:11:44Z

블로그를 찾아주시는 분들께 새해 인사가 늦었습니다. 모든 분들이 행복하고 건강한 새해를 맞이하셨기 바랍니다. 개인적으로 많은 성취와 기쁨이 있었던 2005년이 시간의 강물 속으로 사라졌습니다. 힘들었던 순간도 있었지만 아픔은 잊고 반성의 내용만 남아서 이제는 모든 것이 새로운 내일을 위한 밑거름으로 기억될 뿐입니다.

년말에 보름 정도 휴가를 썼는데, 프로젝트 일정이 빠듯한데다가 회사에 나오면 '수당'을 준다는 달콤한 당근도 있고 해서 며칠 회사에 나갔습니다. 12월이 되면 월스트리트는 사실상 개점휴업 상태가 됩니다. 그래서 현장에서 특별한 일은 일어나지 않았지만, 새로운 버전을 준비해야 하는 프로그래머들은 오히려 할 일이 많아진 느낌이 들었습니다. 그렇지만 많은 사람들이 휴가를 떠난 상태이고 크리스마스 장식이 화려한 거리는 한산해서, 평소와 같은 기분으로 일을 하기보다는 읽고 싶던 테크놀로지, 혹은 금융과 관련된 글을 조용히 읽는 시간을 가질 수 있었습니다.

일손을 멈추고 짬을 내어 '공부'를 하다보면, 세상에는 내가 알지 못하는 일이 너무나 많다는 느낌, 내가 알고 있는 것은 어떤 작은 부분에서 극히 일부분에 불과하다는 느낌이 듭니다. 프로그래밍 언어 한 가지만 놓고도 숨쉴 틈 없이 쏟아져 나오는 새로운 기능, 플랫폼, 툴, API 등을 따라잡을 수 없는데, 프로그래밍이 아닌 다른 분야의 일이나 세상사는 더 말할 나위가 없습니다.

사람들 중에는 자기가 즐겨찾는 인터넷 사이트가 눈에 씌워주는 렌즈로 사물을 바라보면서 보고 들은 바를 앵무새처럼 읊조릴뿐, 자기 성찰이 없는 사람들이 있습니다. 그런데 그런 사람의 모습을 가만히 들여다보고 있으면 거기에 제 모습이 거울처럼 반사되는 것을 보고 깜짝 놀라게 됩니다. 성찰이 없는 삶을 살기로는 저 역시 다를바가 없기 때문입니다. 일이 바쁘다는 핑계로 정작 소중한 것들을 잊고 살아가는 것은 아닌지, 쏟아지는 정보와 상업적 광고의 홍수 속에서 자기 중심을 잃고 휩쓸려 다니며 살고 있는 것은 아닌지, 차분히 반성해 보는 새해의 시작이 되어야겠다는 생각입니다.

자기 중심을 튼튼히 잡고 근본을 깨달으면 부분을 알아도 전체를 아는 것이고, 그렇지 않으면 많은 것을 아는 것처럼 보여도 그는 지극히 작은 부분에 머무르는 것입니다. 저를 포함해서 많은 분들이 빠르기만 할 뿐 깊이가 없는 세상의 뒤를 쫓느라 힘들게 땀을 흘리는 것이 아니라, 남보다 느리게 보여도 한걸움 한걸음을 묵직하고 의미있게 움직여 나가는, 그런 한해를 만들어 나가기를 기대해봅니다.

바그다드카페

2005-12-19T21:19:18Z

[바그다드카페, 1988, 퍼시 애들론Percy Adlon감독]을 재미있게 보았습니다. 소자본으로 만들어진 영화라서인지 다분히 연극적인 연출이 영화로의 전적인 몰입을 방해하긴 하지만 어쩌면 그것마저 감독의 의도였을지 모른다는 생각이 드는 좋은 영화였습니다. 기이하고 낯선 느낌의 주인공들이 사막에 있는 황량하고 가난한 바그다드 카페에서 만나서 서로를 이해하고, 사랑을 느끼고, 그리하여 황량함과 가난에 희망과 활력을 불어넣는 과정을 보여주는 내용입니다. 회사에 (나이가 제 또래인) 러시아 출신 프로그래머가 적지 않습니다. 얼마 전에 회사의 연말 파티에서 그들과 이야기를 나누었는데, 제가 [굿바이레닌]을 보았는가 하고 물었습니다. 좋은 영화다, 라는 식의 이야기를 꺼내려고 했던 것인데, 그들의 반응은 그 이상이었습니다. 과거의 소비에트 이데올로기를 냉소하고 미국과 자본주의를 선택한 그들은 영화 [굿바이레닌]을 이야기하면서 자기들의 마음 속에도 과거에 대한 짙은 향수가 있음을 숨기지 못했습니다. 그것은 이데올로기가 아니라, 인간이라면 누구에게나 존재하는 무엇, 즉 유년의 추억이라고 부를만한 무엇이었습니다. 바드다드카페가 보여주는 낯섬과 가난에서 따뜻한 이해와 사랑으로의 전환도 관객에게 보편적인 수준에서의 공감과 유년의 추억을 불러일으키는 것으로 느껴졌습니다. 좋은 영화는 그런 힘을 가지고 있습니다.

좀 다른 이야기이지만, 러시아 프로그래머들은 대개 상당히 똑똑하다는 느낌을 줍니다. 인도 친구들 중에는 사람을 질리게 할 정도로 두뇌회전이 빠르고 기억력이 좋은 사람들이 많은데, 러시아 친구들은 대개 수학적 상상력과 집중력이 뛰어납니다. 물론 항상 그런 것은 아닙니다. 다만 제 느낌이 그렇다는 것입니다. 그들은 성실하다는 느낌보다는 자기 할 일을 확실하게 한다는 그런 느낌을 줍니다. 중국 프로그래머로 말하자면, 어쩐지 그들은 인해전술이 그랬던 것처럼 우선 숫자로 압도하는 느낌을 줍니다. 어디를 가도 적지 않은 수가 모여서 그룹을 형성하는 중국 프로그래머들 중에는 똑똑한 친구도 있지만 게을러 보이는 친구도 많이 있습니다. (머리를 자주 감지 않는 것은 말 할 것도 없습니다.) 글쎄, 그들이 보는 한국 프로그래머에 대한 느낌은 어떨지 모르겠습니다.

주인과 노예의 변증법

2005-12-11T20:41:44Z

일주일 동안 영국 런던으로 출장을 다녀왔습니다. 새로 출시된 릴리즈의 현장 지원(production support)을 위한 출장이었습니다. 예전에 루슨트테크놀로지스에서 일할 때 맘스베리(Malmesbery)라는 작은 도시로 출장을 다녀온 일이 몇 번 있었는데, 런던은 이번이 처음이었습니다.

런던에 머무르는 동안 그 곳에 있는 친구의 도움으로 프리미어쉽 축구 경기를 하나 관람하고, 런던브릿지, 템즈강, 소호 등을 구경하는 등 좋은 시간을 가졌습니다. 회사 업무는 새로운 릴리즈가 출시된지 하루만에 QA팀에서 발견하지 못한 미묘한 버그가 현장에서 발생하는 바람에 뉴욕의 개발자들과 연락을 주고받으면서 부랴부랴 패치를 적용시킨 것 이외에는 전체적으로 무난한 편이었습니다.

지금까지 프로그래밍 일을 해오면서 이렇게 현장에 앉아서 지원을 해 본 것은 처음이었는데, 한 가지 생각이 제게 흥미롭게 다가왔습니다. 그것은 바로 구체적인 비즈니스 업무에 있어서 프로그래머가 차지하는 위상에 대한 질문이었습니다. 더 많은 돈을 벌어들이기 위해서 소프트웨어를 사용하는 트레이더, 브로커들에게 그것은 명백히 하나의 <도구>에 지나지 않습니다. 그런데 프로그래머들에게 있어서 소프트웨어는 (적어도 회사와 일이라는 문맥 속에서는) <최종 목적>입니다. 사용자들은 프로그래머에게 여러 가지 사항을 요구하고, 그 요구가 받아들여지지 않으면 화를 내거나 소프트웨어의 사용을 거부함으로써 벌을 내립니다. 이 때 프로그래머는 벌을 받지 않기 위해서 요구를 무조건 받아들이거나 아니면 요구를 최대한 정중하게 거절하기 위한 비책을 짜내야만 합니다. 사용자에게 그것은 '효율성'을 추구하기 위한 게임이지만, 프로그래머에게 있어서 그것은 목숨이 걸린 생존게임입니다.

이를테면 저는 이번에 런던에서 일을 하면서 그러한 생존게임의 절박성을 느꼈습니다. 사용자들은 끊임없이 요구하고, 조그만 틈이 보이면 벌을 내리려고 했습니다. 그들은 끝없는 효율성을 추구했고, 소프트웨어와 프로그래머들에게 한없는 <복종>을 요구했습니다. 그리하여 우리는 네트워크, 성능, 버그, 시스템 로드 등과 관련되어서 조금이라도 이상한 징후가 보이면 문제를 사전에 차단하기 위해서 1등급 경보를 발생시키고 핵심 프로그래머들이 비상체제에 돌입하는 일을 반복했습니다. 주인이 노예에게 자신의 욕망을 말합니다. 노예는 주인의 말에 자신의 생명이 걸려 있음을 알고 그것을 실현하기 위해서 노력합니다. 주인이 또 다른 욕망을 노예에게 전달합니다. 노예는 또 목숨을 걸고 그것을 실현합니다. 이러한 일이 반복되다보면, 이제 주인은 자신의 욕망을 실현하는 일이 전적으로 노예의 손에 달려있음을 깨닫게 됩니다. 노예도 마찬가지입니다. 문제가 되는 것은 이제 자신의 생명을 손에 쥐고 있는 주인이 아니라, 주인의 욕망을 손에 쥐고 있는 자기 자신이라는 점을 깨닫게 되는 것입니다. 그리하여 서로를 바라보는 시선이 달라지게 되는 것입니다.

헤겔이 말한 주인과 노예의 변증법입니다. 주인과 노예 사이에 존재하는 힘의 관계가 역전되는 현상을 변증법적으로 설명한 논리입니다. 제가 일하는 팀에서 개발한 트레이딩 소프트웨어를 많은 사용자들이 사용하는 모습을 확인하면서 저는 이제 그것이 그들에게 있어서 더이상 있어도 그만이고 없어도 그만인 도구가 아니라는 점을 깨달을 수 있었습니다. 그것은 효율성을 추구하는 그들의 <욕망>을 손에 쥔 노예의 깨달음, 프로그래머라는 존재의 위상에 대한 새로운 인식의 과정이었습니다. 소프트웨어의 세계에서 이런 일은 끝없이 일어납니다. 아마 여러분이 프로그래밍하는 소프트웨어에서도 이런 일은 일어나고 있을 겁니다.

힘의 역전. 노예의 깨달음. 그것이 가능하기 위해서는 누가 보거나 말거나 한 바이트, 한 비트의 코드에 온 정성과 심혈을 기울이는 프로그래머의 장인 정신이 전제가 되어야 할 것입니다. 이번의 런던 출장은 제게 그러한 장인 정신의 복구를 다짐하는 새로운 계기가 되어 주었습니다.

사기의 기술 (con art)

2005-11-29T11:59:54Z

아내의 친구가 여행을 떠나면서 집에서 키우는 강아지를 맡긴 적이 있습니다. 서로의 집이 차로 세 시간 정도 떨어져 있기 때문에 친구가 여행을 마치고 돌아오고 나서도 한참을 맡아 키워야 했습니다. 두 달 남짓한 시간이었는데, 이 때 두 딸아이가 강아지에게 흠뻑 정을 느끼고 말았습니다. 강아지를 돌려주고 나서도 두 녀석이 자나깨나 강아지 타령을 하는 바람에 마침내 강아지를 키우자고 결정을 하게 되었습니다.

아내와 두 아이가 인터넷을 열심히 뒤적거리더니 태어난지 3개월된 귀여운 요크셔테리스 한마리를 발견하고 주인에게 연락을 취했습니다.

필라델피아에 사는 주인은 이메일을 보내왔는데, 강아지는 이미 다른 사람이 샀다. 그는 오하이오에 사는 누구누구라는 사람인데, 유니세프에서 일을 하는 사람이다. 그런데 그가 최근에 나이지리아에 일을 하게 되었고, 그 곳에서 강아지를 키울 수 없게 되어 새주인을 찾는다더라. 만약 강아지를 원하면 그에게 직접 연락을 해봐라. 하는 내용이 적혀있었습니다.

아내와 아이들은 나이지리아에 있다는 그 주인에게 이메일을 보냈습니다. 하루쯤 지나서 주인으로부터 답장이 왔는데, 나는 정말 이 강아지를 키우고 싶지만 상황이 이렇게 되어서 안타깝다. 나는 강아지를 팔아서 돈을 받고 싶은 생각은 없으므로 강아지를 비행기로 보내는데 필요한 값만 받겠다. 그리고 아무에게나 주지 않고 강아지를 사랑으로 정성껏 키울 가정에게 줄 것이다. 등등의 사연이 적혀 있었습니다.

그 때부터 2~3일 동안 계속 이메일을 주고받으면서 사연을 나누었습니다. 마침내 아내는 나이지리아로 <현금>과 동일한 머니 트랜스퍼를 통해서 돈을 부쳤고, 강아지를 보냈다는 연락이 오기를 기다렸습니다.

연락은 하루가 지나서 왔습니다. 공항에서 강아지를 보내려고 했는데 뜻하지 않게도 관세를 200불을 내라는 이야기를 들었다, 강아지를 보내기 위해서는 네가 이 돈을 빨리 보내줘야 하겠다는 내용이었습니다. 아내에게 도착한 이 이메일은 우연찮게 제가 직접 확인을 하게 되었는데, 코 끝에 어떤 냄새가 확 풍기는 것이었습니다. 무슨 관세가 200불이나 되니? 저는 우선 그 사람이 유니세프의 직원인지 여부를 확인하고 싶었습니다.

제니퍼 그린(Jennifer Green)이라는 이름을 유니세프와 함께 구글에서 검색하니 여러 결과가 화면에 떠올랐습니다. 그리고... 놀랍게도 그 자가 사기꾼(Scammer)이라는 사실을 확인하게 되었습니다! 맨 처음 웹사이트에 요크셔테리스 강아지를 올린 사람과 나이지리아에 있다는 사람은 동일 인물이었던 것입니다. 다행히도 200불을 보내기 전이었지만 이미 강아지 우편료 350불을 보낸 다음이었기 때문에.. 그의 사기에 순진하게 속아넘어간 우리는 350불을 손해볼 수밖에 없었습니다.

그깟 돈이야 없어도 그만이지만 속아넘어간 자신에게 화를 참지 못하는 아내의 상심과 강아지를 갖지 못하게 된 아이들의 실망을 보면서 가슴이 저렸습니다. 아이들에게 <사기>라는 개념을 어떻게 설명할지에 대해서도 참으로 막막한 심정이 들었습니다. 작고 귀여운 강아지 앞에서 마음이 착해지지 않을 사람이 어디에 있겠습니까? 그렇게 착해진 마음을 이용해서 돈을 뜯어내는 이 자의 사기의 기술(con art)은 참 나쁘다는 생각이 듭니다. 여러분도 이와 비슷한 사기를 당하고 상심한 적이 있는지 궁금합니다. 하지만 그럴 수만 있다면 이런 식의 사기는 당하지 않고 사는 것이 더 좋겠습니다. 돈도 돈이지만, 무엇보다도 이런 식의 경험은 사람에 대한 신뢰에 금이 가게 하기 때문입니다. 그게 참 마음을 아프게 합니다.

프로그래머 최악의 날

2005-11-17T13:20:18Z

올해 마지막 버전의 출시가 내일인 금요일로 다가왔습니다. 출시일에는 대개 새벽 1~2시까지 작업을 하게 되는데, 일일이 확인하면서 수행해야 하는 30여개의 작업 항목 하나하나가 극도의 집중과 주의를 요구하기 때문입니다. 그렇다고 해서 개발팀 전원이 밤늦게 남아있어야 할 필요는 없으므로 출시일에는 소수의 정예부대를 구성하게 됩니다. 개발은 진작에 끝났고, 1~2주 전에 QA 테스트팀의 작업도 모두 끝나서 지금은 모두 출시작업에 박차를 가하고 있는 상황입니다. 금요일 밤에 출시를 하고나면 고객들은 월요일 아침부터 새 버전의 소프트웨어를 사용하게 됩니다. 이때 혹시 발생할지 모르는 문제를 현장에서 지원하기 위해서 몇몇은 이미 런던으로 출장갈 준비를 하고 있기도 합니다.

이와 같은 상황에서 어제 QA팀에서 이상한 문제를 보고했습니다. 시스템의 서버에는 매일 일과가 끝나면 수행되는 프로세스가 하나 있는데, 이 프로세스가 동작하는 순간에 테스터 한명이 사용하던 클라이언트가 동작을 멈춘 것이었습니다. 뭐, 데이터 설정이나 환경이 잘못 구성된 거겠지.. 하고 그냥 넘어갈 수도 있는 문제였지만 특별히 할 일도 없고해서 문제를 자세하게 분석하기 시작했습니다.

분석이 꼬리에 꼬리를 물고 이어진 끝에.. 어딘가 클라이언트 코드에서 GUI 쓰레드가 아닌 일반 쓰레드에서 자바 스윙 컴포넌트를 건드렸기 때문에 문제가 발생한 것이라는데까지 밝혀내었습니다. 그리고 나서 매니저와 동료들을 상대로 이거 쓰레드 문젠데.. 자주 발생하진 않겠지만 필드에서 문제가 발생할 여지가 있다. 출시를 하루 앞둔 지금 이걸 고쳐야 하는 것일까, 어쩌고 하면서 떠들고 다녔습니다.

그리하여 많은 사람들이 이 문제의 심각성을 알게되고, 수정을 해야할지 여부를 고민하기 시작한 즈음에.. 코드를 더 자세하게 분석해 들어가던 저는... 문제를 일으키고 있는 코드가 바로 내가 얼마전에 작성해 넣은 한 줄 짜리 코드였음을 알게되었습니다. 그러니까, 문제를 일으키고 있는 범인은 바로 나 자신이었던 것입니다!! 세상에!!! 아주 간단한 버그를 고치기 위해서 삽입한 한 줄 코드가 GUI 쓰레드가 아닌 별도의 쓰레드에서 실행되었기 때문에 문제가 발생한 것인데.. 사실을 깨달은 저는 하늘이 무너지고 심장이 멎는듯한 충격을 받을 수밖에 없었습니다. 이런 버그를 안고 있는 프로그램을 출시한다는 것은 말도 안돼는 일이고, 그렇다고 해서 출시를 연기할 수도 없는 상황인 것입니다.

QA팀은 그쪽대로 이렇게 심각한 버그를 지금까지 발견하지 못했다고 해서 난리가 나고, 개발팀은 개발팀대로 벌집을 쑤셔놓은 듯한 분위기가 되고.. 그 번잡함의 와중에서 얼굴에 열이 올라 멍해졌던 저는 최선을 다해서 수습책을 마련해 나가기 시작했습니다. 실수는 실수고, 수습은 수습이기 떄문입니다. 다행히 버그는 쉽게 수정되었고, 패치가 금방 준비되었습니다. 하루종일 거의 1초의 휴식도 없이 집중을 했더니 한밤이 된 지금도 잠이 올 것 같지 않은 각성상태가 유지되고 있을 정도입니다.

<최악의 날>이로군. 오늘 길에 몇번을 그렇게 생각했습니다. 속으로 욕도 여러 번 내뱉었습니다. 하지만 위기를 넘기고 시간이 흐른 지금 보기에는 오히려 좋은 교훈을 얻은 하루였다는 생각이 더 많이 듭니다. 어쨌든 버그의 존재를 오늘 알게 되었던 것은 내일 알게 되었던 것보다 나은 일이었던 셈입니다.

프로그래밍이라는 일 앞에서 더욱 겸손하고 진지해져야겠다는 <반성>이 떠오르는 밤입니다.

AspectJ

2005-11-10T20:47:35Z

어제 저녁에는 회사 친구와 AspectJ에 대한 대화를 나누었습니다. 저는 일전에 Spring 프레임워크를 공부하면서 Aspect Oriented Programming의 개념을 접한 적이 있었는데, AspectJ는 개념에서 한걸음 더 나아가서 개념을 현실화하는 <언어>를 제공하고 있었습니다. 프로그래머로 하여금 로우레벨 디테일(low level detail)에서 벗어나서 비즈니스 로직에만 전념하도록 만들겠다는 뜻은 훌륭합니다. 보기에 따라서는 AspectJ가 마치 C++가 C언어를 확장했던 것처럼 자바를 확장한 Java++처럼 보이기도 합니다.

하지만 자기가 할 수 있는 일을 남이 대신해주는 것을 별로 좋아하지 않는 프로그래머들의 속성을 생각해 볼 때, AspectJ가 프로그래머들에게 얼마나 폭넓게 받아들여질지는 미지수입니다. 곧바로 자바 바이트 코드를 만들어내는 컴파일러의 성숙도도 고려의 대상이 되지 않을 수 없습니다. AspectJ를 이용해서 실제 제품을 만들기는 아직 이른감이 있지만, 흥미로운 언어임에는 틀림이 없습니다. 시간이 날 때, 웹사이트를 방문해서 둘러보는 것도 괜찮을 것이라 생각됩니다.

요즘 웹2.0의 부각과 그에 대한 마이크로소프트의 위기감을 주제로 한 신문기사를 자주 접하고 있습니다. 인터넷 주식거품 이후 정체되었던 인터넷 기술에서 새로운 패러다임의 <변화>가 시작되고 있는 느낌입니다.

집에서 일하기

2005-10-31T11:16:54Z

미국의 회사엔 'working from home(집에서 일하기)'라는 제도가 있습니다. 예를 들어서 오후 2시에 병원에 갈 약속이 있다든지, 아니면 집에 배달되는 소파를 기다려야 하는 것처럼 집에 머물러야 하는 이유가 있을 때에는 매니저에게 "나 오늘 집에서 일한다"라고 이메일을 보내고 집에서 일을 하는 것입니다. 몸에 가벼운 감기 기운만 느껴져도 이메일을 보내고 집에서 일을 하는 것은 흔한 일입니다. VPN을 통해 회사 네트워크에 접속해서 일을 하게 되는데, 너무 자주 집에서 일하면 좀 그렇지만 한 달에 한 두 번 정도는 집에서 일하는 사람들이 많습니다.

한국을 떠난지 근 10년이 되어가다보니 한국에서 경험했던 일들이 요즘도 사실인지 알 수 없을 때가 많습니다. 바로 '집에서 일하기'가 그 중 하나입니다. 인터넷 시설이 발달한 한국에서 요즘 집에서 일하기라는 제도가 존재하는지 궁금합니다. 제가 10년 전에 한국에서 회사 생활을 할 때는 '집에서 일하기'란 것을 상상조차 할 수 없었습니다. 당시에는 집에서 회사 네트워크에 접근할 수 있는 기반 시설이 거의 없었던 때이기도 했지만, 설령 그런 기술적인 문제가 없었다고 해도전체적인 분위기가 집에서 일하기를 용인했을 것 같지 않습니다.

팀 회식 때문에 새벽까지 술을 마신 날 아침에 새벽같이 일어나서 숙취와 교통체증에 시달리며 사무실까지 나가는 대신, 아침 7시까지 푹 자고 일어나서 곧바로 방 안에서 일을 시작할 수 있으면 얼마나 좋을까, 그게 더 효율적이지 않을까 하고 생각했던 기억이 납니다. 하지만 당시에 회사가 요구했던 것은 <일>을 얼마나 질높게, 그리고 빠르게 하는가가 아니라, 양복을 차려입고 회사 사무실에 나가서 아침 방송을 보고, 팀 조회에 참석하는 지극히 형식적인 절차들이었습니다. 그런 절차들이 끝나면 라면을 사먹으러 회사 앞의 분식점에 가고, 간혹 화장실에 앉아서 잠을 잔 적도 있습니다.

무엇을 중심에 놓고 사고할 것인가, 라는 질문을 던지는 것입니다. 실력이 뛰어난 프로그래머를 보면 주변 정리가 잘 안되는 친구들이 많습니다. 무슨 말인가 하면 책상 위가 늘 지저분하게 어질러져 있고, 밤에 잠자리에 드는 시간이 일정하지 않고, 따라서 아침에 출근 시간이 일정하지 않은 그런 친구들 말입니다. 그런 친구들에게 형식적인 절차를 강요하는 것은 그들의 창의성과 의욕을 말살시키는 가장 빠른 방법입니다. 대부분의 회사 일이 한 두 명의 천재보다는 열 명의 근면한 둔재를 요구한다지만, 프로그래밍 세계는 다릅니다. 프로그래밍 세계에서는 분명히 한 명의 천재가 나머지 열 명, 스무 명이 해야할 일을 결정합니다. (천재라고 해서 대단한 사람을 말하는 것이 아닙니다. 창의력과 열정으로 가득한 실력 좋은 프로그래머를 의미할 뿐입니다. 저로 말하자면 그런 천재가 아니라 나머지 열 명, 스무 명에 속합니다.)

처음에는 '집에서 일하기'라는 개념이 익숙하지 않아서 눈치도 좀 보이고 했는데, 요즘은 프로그래밍의 효율성을 높이기 위해서 가끔 집에서 일하는 것이 더 편하고, 실제로 능률도 높기 때문에 아무런 부담없이 (필요하면) 집에서 일을 합니다. 이 제도가 어찌나 마음에 드는지 만약 제가 회사를 운영하는 사람이라면, 프로그래머들에게 일주일에 하루는 의무적으로 <집에서 일하는 날>로 정하고 싶을 정도입니다. 그렇게 하는 회사가 왜 없는지 (있는데 제가 모르는 것일 수도 있지만) 알 수 없는 일입니다.

쥐

2005-10-19T13:24:06Z

오는 금요일이 코드 프리즈(code freeze)라서 밀린 버그를 수정하고, QA팀에게 전달할 테스트 버전을 빌드(build)하고, 다른 시스템들과 연결되는 통합테스트를 수행하느라 눈코뜰 새가 없습니다. 팀을 대표해서 버그 관리 시스템에 입력된 버그를 검토하고, 버그를 어떤 버전에서 수정할 것인지 등을 검토하는 미팅에 참가하다보면 막상 나에게 할당된 버그를 수정할 시간이 없어서 밤늦은 시간에 작업을 할 수밖에 없습니다. 저녁을 근처 일식집에서 사시미 정식을 시켜서 먹고 작업을 하다보니 밤 11시가 다 되어서야 집에 갈 수 있었습니다.

맨하탄 시내에서 운행하는 택시는 흔히 옐로우캡이라고 불리는 노란색 택시지만 맨하탄에서 한 시간 정도 떨어진 뉴저지 교외까지 가는 택시는 옐로우캡이 아니라 전화를 걸어서 불러야 하는 검은색 세단입니다. 요금은 대략 $110 정도인데 비용은 물론 회사에서 지불해 줍니다. 이 택시를 불러놓고 회사 앞에서 잠시 차를 기다리고 있었습니다. 바람이 그렇게 차갑지 않고 시원한 느낌이라 마치 풍경화처럼 다가오는 월스트리트의 밤모습을 바라보면서 시원한 가을 저녁을 온몸으로 감상하고 있었습니다.

그 때였습니다. 발 밑으로 뭔가 거무스름한 것이 슥 지나갑니다. 뭔가 하고 바라보니.... 이런! 쥐가 한 마리도 아니고 세 마리가 펄쩍펄쩍 뛰면서 지나가고 있었습니다. <이런 제길!> 하고 외치면서 후다닥 뒤로 물러서고 보니 쥐가 온데간데 없습니다. 마침 길을 지나가던 아줌마가 이상한 사람이야.. 하는 표정으로 바라보며 지나갑니다. 건물 구석에 만취한 모습으로 주저앉아 있던 홈리스 아저씨는 쥐 때문에 뭘 저리 놀라나.. 하는 표정입니다.

차를 타고 집으로 돌아오는 길에, 요즘 서울에는 쥐가 있을까.. 하는 궁금함이 일었습니다. 일주일 동안 내리던 비가 그친 가을밤에는 달과, 별과, 비행기의 불빛이 초롱초롱했습니다.