Extremely Agile

2011년 1월 21일 12:00

"점심이나 먹으러 가죠."

허동수의 표정은 차가웠다. 유식이 제안한 방법대로 코드를 수정했더니, 실패한 테스트의 수는 눈에 띄게 줄었다. 하지만 남은 버그들은 요령부득이었다. 점심을 먹을 상황이 아니었다. 밥이 넘어갈 것 같지도 않았다. 허동수는 커피를 찾았다. 너무 많이 마시면 쉽게 잠들 수 없으리라는 건 알고 있었지만, 지금 상황에서는 잠을 줄이는 게 오히려 득이 될런지도 모르는 일이었다. 

결국 안팀장은 다른 팀원들과 식당으로 내려갔다. OLYMPUS 과제원 모두는, 굳은 얼굴로 자리에서 일어나질 않았다.

"모두들 입맛이 없으신 것 같네. 그럼 잠깐 회의나 할까요?"

시애의 말에 모두 느릿느릿, 자리에서 일어났다. 신발 바닥에 껌이라도 붙은 사람들 같았다.

http://www.gulnara.net/main.php?pcd=120.129.&_cat=s431.&_vpg=view&_vuid=78

2011년 1월 21일 11:30

"뭐가 좀 나왔나요?"

호출을 받고 달려온 유식의 첫 물음이었다. 유식은 사태를 그다지 심각하게 생각하지 않고 있었다. 버그 없는 시스템이란 상상할 수 없었고, 모든 버그는 해결 가능한 것이었다. 유식이 보기에, 버그는 '재미있는 것' 이지 '심각한 것'이 아니었다. 하지만 허동수의 표정은 심각했다.

"보이소. 내가 담당한 부분이 아니라서 뭐라고 말을 못하겠네예."

공통 라이브러리에 해당하는 코드 담당자는 유식과 대수였다. 유식은 고개를 끄덕였다.

"제가 맡은 부분이니 제가 봐야겠죠. 그런데 문제가...?"

허동수는 모니터를 가리켰다. 허동수가 가리킨 그곳에는, 소스코드가 변경되었음을 알리는 diff 문자열이 찍혀 있었다. diff는 거짓말을 하지 않았다. 이미 십수년간, 수많은 개발자들이 어루만지고 개선한 프로그램이었다. 그리고 diff는, 유식이 담당한 코드를 누군가 수정했음을 알리고 있었다.

"어떻게 바뀐 것 같습니꺼?"

어느새 선화와 대수도 유식 뒤에 와 있었다.

"함수 인자 형이 바뀌었고, 코멘트가 한줄 추가되었군요."

"그건 저도 압니더. 내가 알고 싶은거는, 이렇게 바꾸고 나면 시스템에 어떤 영향이 있느냐는 겁니더."

"PolicyAgent는 Agent의 하위 클래스이니까..."

유식은 생각했다. PolicyAgent는 Agent의 하위 클래스이다. 상위 클래스에는, 하위 클래스 구현을 편리하게 해 주는 코드가 들어가 있게 마련이다. 또한, 하위 클래스에서 바꿀 필요가 없는 공통의 프로그램 로직이 들어가 있게 마련이다. 하위 클래스에서 상위 클래스의 동작 방식을 변경하고자 할 때에는, 변경할 메소드만 골라 내어 오버라이딩(overriding)한다. 오버라이딩 된 '같은 이름의' 메소드는, 상위 클래스에 존재하는 '같은 이름의' 메소드를 대체한다.

유식은 생각했다.

'pass_policy라는 메소드가 상위 클래스에 있었나?'

상위 클래스에 없었다면 문제될 것이 없지만, 상위 클래스에 있는 메소드였다면 문제가 심각해지기 때문이었다. 가령 pass_policy라는 메소드가 하위 클래스에만 있는 메소드였다면, 그 인자의 형(type)에서 const가 탈락되더라도 크게 문제될 것은 없었다. 하지만 상위 클래스에도 있는 메소드라면, 상위 클래스의 pass_policy와 하위 클래스 pass_policy는 순간 다른 메소드가 되어 버린다. 그러니 하위 클래스 메소드의 인자형을 바꿔버리는 순간, 하위 클래스 pass_policy 대신 상위 클래스 pass_policy가 호출되도록 프로그램은 바뀌어 버릴 것이다.

"잠깐 키보드 좀 쓸께요."

유식은 동수로부터 키보드를 넘겨받고 소스코드를 확인했다.

"어떻습니꺼?"

몇 글자 쳐 넣지도 않았는데 허동수가 결과를 물었다.

"잠시만요. 급하시긴..."

"급한 일이니까 그렇지예. 유식씨는 별로 안 심각한갑네."

"서두른다고 빨리 해결 될 일이면 저도 서두르죠."

서두른다고 타이핑 속도가 늘어나는 것도 아니고, 서두른다고 생각의 속도가 달라지는 것도 아니지 않나. 유식의 생각은 그랬다. 오히려 중요한 것은 숨고르기였다. 문제가 드러났을 때 서두르면, 코드는 망가지게 되어 있었다. 천천히 생각하고 또 생각해야, 문제를 교정한답시고 더 많은 버그를 만들어 내는 어리석음을 피할 수 있었다. 지금 말썽을 부리고 있는 저 부분이, 필요 없어 보인다는 판단에 아무 생각없이 const를 걷어내서 생긴 버그가 아니라고 누가 장담할 수 있겠는가.

"문제가 뭔지 알았습니다."

"뭔가요?"

대수가 물었다.

"그 원인은 즉슨..."

유식이 설명하자 모두 고개를 끄덕였다. 그런데, 뭔가 찜찜한 것이 있었다. 대수가 물었다.

"그런데, 저 코멘트는 뭘까요?"

"12, 라고 적힌 저 주석(comment)?"

"네. // 대신 /// 를 붙여 놓은 것도 웬지 독특해보이는데 말이죠. 대체 무슨 뜻의 주석일까요?"

"글쎄요..."

그것까지는 유식도 추측할 수 없었다. 주석에 적힌 내용을 분석해서 프로그램에서 사용한 클래스에 대한 문서를 만들어주는 시스템 가운데에는, '///'와 같은 특별한 주석 형식을 사용하는 것도 있긴 했다. 하지만 12와 주석 형식과는 특별한 관련성이 없어 보였다. 아니, 어떤 연관성을 찾아내기에 12라는 숫자가 갖는 상징성은 너무 왜소해보였다.

"어쨌든, 저 부분을 원래대로 되돌려 놓고 테스트를 한 번 해 보죠."

허동수는 대수를 데리고 자기 자리로 돌아갔다. 대수는 유식의 말대로 소스코드를 고쳤고, 허동수는 백업 시스템과 빌드(build) 시스템을 점검한 후 다시 회귀 테스트를 시작했다.

- 위이잉

그 순간 하드디스크가 굉음을 내며 돌아가기 시작했다, 고 느낀 것은 아마 허동수의 착각이었을 것이다. 그는 긴장하고 있었다. 또 실패하면 어떻게 하나. 그 때는 정말로 뒤질 백업도 없는데. 그 때는 정말 팀장에게도 할 말이 없는데.

2011년 1월 21일 11:00

"백업이 없단 말인가요?"

안팀장의 질책에 허동수는 마른 침을 삼켰다. 귀신이 곡할 노릇이었다. Hudson은 매 시간마다 테스트가 끝난 소스코드를 백업하도록 설정되어 있었다. 백업을 관리하는 것은 자신의 책임이었다. 매일 퇴근 전에 백업을 점검하는 것은 물론이고, 혹시 모를 정전에 대비하여 무정전 장치에까지 연결을 해 둔 상태였다.

"네. 그게 어찌된 일인지 저도 잘 모르겠습니더. 어제 밤까지는 분명히 수백개의 백업이 있는 상태였고만..."

안팀장은 '잘난척 하더니 너희도 별 수 없구나' 하는 표정이었다.

"오늘 중으로 대책 세우시고, 백업을 복원할 수 없으면 멀쩡히 잘 돌던 시스템이 왜 돌아가지 않는지부터 규명하세요."

'얼씨구, 그런 말은 내도 하겠구마'

허동수가 보기에, 팀장이라는 사람들은 실질적으로 하는 일이 없는 존재들이었다. 물론 박시애 팀장 같은 예외도 있었다. 허나 그의 생각에, 대부분의 팀장들은 '하나 마나 한 소리로 팀원들 사기나 떨어뜨리는' 암적 존재들이었다. 허동수가 그런 생각을 굳히게 된 데에는, 안팀장도 한 몫을 했다. 왜 그가 이 회사에서 그토록 인정을 받는 사람이 되었는지, 아무리 생각해도 알 수 없는 노릇이었다.

어쨌든, 발등의 불이었다. 허동수는 자리로 돌아와 앉아 해결책을 떠올려 보았다. 백업 서버의 하드를 떼다가 복원을 부탁하는 것도 한 방법이었지만, 지금은 '하드는 살아 있는데 파일만 날아간' 이상한 경우였다. 물론 복원 업체에 맡기면 어떻게든 방법을 찾아서 해 주겠지만, 시간과 비용이 문제였다. 마무리 작업에 남김없이 시간을 갖다 부어도 모자랄 판국에, 업체에 하드를 맡기고 하염없이 기다린다? 안될 말이었다.

'자, 그라믄 우짜면 좋노?'

"저, 허동수씨."

그의 멍한 고민을 방해한 것은 유식과 선화였다.

"도움이 좀 될까 싶어서 왔는데... 선화씨가 자기 자리로 좀 와 주셨으면 한다네요."

"무슨 일입니꺼?"

동수가 묻자 선화가 머뭇머뭇, 하다 나서서 말했다.

"저, 제가 디자인 작업 때문에 아이맥을 쓰고 있는데..."

"있는데?"

"거기 타임캡슐(맥에서 사용되는 전용 백업 하드디스크)이 붙어있거든요. 그래서..."

그 말을 듣자마자, 허동수는 반사적으로 휠체어를 돌려 선화의 자리로 달음질했다. 어찌나 급하게 튀어나갔는지, 바퀴로 유식의 발등을 찍은 것도 모를 지경이었다.

선화의 자리에 도착하자 마자, 허동수는 마우스를 움직여 타임머신(타임캡슐과 연동하는, 맥 전용 백업 소프트웨어)을 실행하려 했다. 그러나, 그의 급한 마음을 화면 보호기와 로그인 창이 가로막았다.

"진정하세요."

선화가 웃으며 패스워드를 입력해 주었다. 화면에는 이미 타임머신이 구동되어 있었다. 그녀가 탐색기 창을 보여주며 말을 이었다.

"제가 디자인 작업 때문에 소스코드를 가끔 통째로 다운받아서 필요한 그림 파일을 바꿔 넣은 다음에 commit 해드리곤 했거든요."

"얼마나 자주 했습니꺼?"

"글쎄요. 한달에 한번 정도?"

"마지막으로 작업했던게 언젠데예?"

"오늘 아침에 소스코드를 다시 다운받았어요."

"쓰..."

선화의 백업 디스크에 남아 있을만한 가장 최신의 백업 파일도 한달 전 것이라는 소리였다. 허동수는 낙담했다.

"별 도움이 안될까요?"

하지만 단언할 수는 없는 노릇이었다. 단 하나의 단서라도 소중한 시점이었다.

"글쎄예. 일단은 살펴 봐야 알겠네예. 잠시 봐도 되겠습니꺼?"

"네에. 저는 휴게실에 가있을께요."

선화와 유식은 주섬주섬 노트북을 챙기더니, '우리가 없는게 더 편하죠?' 한마디를 남기고는 사라져버렸다.

'편하긴 개뿔이 편하겠구마'

그러나 사방이 조용해지자, 허동수의 잔머리는 곧 빠르게 회전하기 시작했다. 그는 역시, 혼자 내버려 두어야 일을 하는 부류의 사내였다.

우선, 최근에 거의 작업할 일이 없었던 공통 라이브러리 부분을 보기 시작했다. 이 부분의 개발은 거의 두어달 전에 끝난 상태라, 선화의 백업 디스크에 깔려 있는 소스 코드가 마지막 버전이라고 확신할 수 있었다. 실제로, Hudson에는 이 부분과 관련하여 기록된 변경 이슈가 없었다. (Hudson은 소프트웨어 프로젝트를 진행할 때 사용하는 Continuous Integration Software로서, 개발자들은 코드를 수정하거나 변경해야 할 때 마다 이 시스템에 '어디를 왜 어떻게 수정하려 하는지'를 '이슈'라는 이름으로 등록하도록 되어 있다)

'그럼 일단 공통 라이브러리 부분부터 살펴볼까.'

허동수는 그녀의 백업 디스크에서 추출한 소스코드들을 USB에 카피한 다음에, 자리로 돌아왔다. 공통 라이브러리에 속한 모든 소스 코드 파일을, 오류를 일으킨 지금 버전의 소스 코드와 1:1로 대조해 볼 심산이었다. 바뀐 부분이 없다면, 적어도 공통 라이브러리 모듈은 사고의 원인이 아니라고 결론 내릴 수 있을 것이었다.

'diff를 이용하자.'

허동수는 잽싸게, 서로 다른 두 디렉터리 내의 모든 같은 이름 파일을 비교한 다음 그 결과를 요약해 보여주는 셸 스크립트를 작성했다.

'천재 아이가.'

십여분 만에 작성된 스크립트가 우아하게 돌아가는 것을 보면서, 허동수는 스스로 만족스러워 하고 있었다.

'가만. 근데 이게 뭐꼬?'

스크립트가 비교 작업을 마치는 데는 몇 초가 채 걸리지 않았다. 그리고 화면에는, 이런 문구가 찍혔다.

$> tempdiff.sh

repository-agent.h has been changed.
< void pass_policy(const char* policy);
> void pass_policy(char* policy);

repository-agent.cc has been changed.
< void RepositoryAgent::pass_policy(const char* policy) {
> void RepositoryAgent::pass_policy(char* policy) {
>        /// 12

그는 핸드폰을 꺼내 유식에게 전화를 걸었다.

- 여보세요?

"유식씨. 냅니더. 여기 와서 이것좀 바 줘야 되겠네예."

프로그래머 2부가 좀 많이 (?) 수정되었습니다. 예전에 한참 '프로그래머'를 연재했을때, 많은 분들이 관심을 보여주셨던 것에 비하면, 진도는 지지부진합니다. 현재 3부를 대폭 수정해서 쓰고 있는데, 그 전에 수정된 2부를 보여드립니다. 

- - - 

모든 사람들은 기억에 의존해 살아갑니다. 모든 창조는 기억에 의존하니, 기억하지 않고는 만들 수도 없고, 개선할 수도 없습니다. 프로그래머는 프로그래밍 언어에 대한 기억, 프로젝트에 대한 기억, 아키텍처에 대한 기억, 디버깅에 대한 기억 등등 여러가지 기억들에 의지해 생활합니다.

- - -

일주일 전, 프로그래머 L을 만났습니다. 늦게 시작한 공부를 마칠때가 되어 그런지, 논문 준비에 초췌해진 모습이었습니다. 회사 일 하랴 논문 쓰랴, 까칠해진 그의 얼굴이 여전히 안스러워 보였습니다. 책상에 조용히 기대앉아 있는 그의 어깨에 손을 얹고 물었습니다.

- 괜찮아? 힘들어 보이는데...

그런데 저를 돌아보는 그의 눈빛은 어쩐지 서늘하고 허전해 보였습니다. 그는 내 손을 붙잡고 입술을 달싹였습니다. 쉽게 열리지 않는 그의 입술은, 무언가를 간절히 찾고 있는 듯 했습니다.

- 도와주세요.

뜬금없이 도와달라니. 업무를 도와달라는 뜻이 아님은, 그의 절박한 표정을 보고 미루어 짐작할 수 있었습니다. 믹스 커피를 앞에 두고, 우리는 휴게실에 마주앉았습니다. 도와달라는 말을 할 때 처럼, 그는 다시 힘겹게 운을 뗐습니다.

어제 세시쯤이었어요. 핸드폰 수리 때문에 대리점을 찾았죠. 그리고 핸드폰을 받아왔어요. 다시 깨끗해진 액정을 보면서, 즐거웠던 기억이 나요. 기분이 좋아서 매점에 들러 아이스 아메리카노를 주문했죠. 뚜껑을 닫고 빨대를 꽂으려 했는데, 마침 뚜껑이 없었어요. 괜찮겠지, 싶어서 그냥 커피를 들고 나왔죠. 빨대 없다고 커피를 마실 수 없는 건 아니잖아요. 천천히 걸었죠. 그런데 비가 왔어요. 후두둑, 갑자기 거세게 쏟아졌죠. 뛰어야 했어요. 비 냄새가 뒤섞인 커피를 마셔야 할지도 모른다고 생각하니, 어쩐지 마음이 급해졌어요. 그래서 뛰었어요. 그런데 그때, 전화벨이 울렸어요.

- 그래서?

전화를 받으려다 미끄러졌고, 넘어졌어요.

- 다친데는 없고?

눈을 떠 보니, 곁에 사람들이 서 있었어요. 저를 흔들고 있었죠. 바닥에 머리를 부딛혔나봐요. 잠깐 정신을 잃었던 거죠. 그런데, 일어나 보니 이상하게 개운한 거에요. 여태껏 그런 적이 있었나, 싶을 정도로 머리가 맑았죠. 괜찮은지 묻는 사람들에게 '멀쩡합니다' 라고 씩씩하게 말한 다음 자리로 돌아왔어요. 십분쯤 지났나, 두통이 생기더군요. 조금 쉬면 괜찮겠지 싶어 눈을 감고 하던 대로 명상을 하기 시작했어요. 그러다 까무룩 잠이 들어버렸죠.

- 그리고?

눈을 떴어요. 얼마나 잔 건지. 알 수 없었죠. 시계를 보니 네시였지만, 언제 잠이 들었던 건지는 기억나질 않았어요. 그런데 뭔가 달라졌다는 느낌이 들었어요. 무슨 느낌이었냐고요?

- 그래, 뭐가 달라졌다고 느꼈는데?

기억이 나질 않았어요.

- 기억이?

네. 기억이. 기억이 나질 않았죠. 내가 그날 무슨 일을 하고 있었는지, 무슨 일을 하게 되어 있었는지 기억이 나질 않았어요. 돌아보니, 주변의 풍경도 생경했죠. 누가 저를 찾는 목소리가 들렸어요. 이상하게 낯설어보이는 자리에서 일어나 누가 부르는 지를 찾으니, 팀장님이었어요. 그런데, 제가 아는 팀장님의 얼굴과 달랐죠. 그분이 말씀하시더군요. 'L 선임. 잠시 자리로 와서 이것좀 봐 주겠어?' 자리로 갔습니다. 어쩔 수 없었어요. 이해할 수 없는 상황이 벌어지고 있었지만, 어떻게든 아무 일 없는 척 해야 한다는 생각이 들었어요. 그래서 그 분 자리로 가서, 그분이 보라는 문서를 봤습니다. 쓴 사람 이름이 저로 되어 있더군요.

- 그 문서의 내용은 기억이 났어?

아뇨. 기억이 나질 않았습니다. 팀장님이 이것 저것 물으시는데, 바로 답변을 할 수가 없었어요. 그래서 좀 더 생각해보고 말씀드리겠다고 한 다음에, 자리로 돌아왔습니다.

- 괜찮아?

네. 괜찮습니다. 저는 멀쩡해요. 아니, 온전히 멀쩡하다고 할 수는 없겠죠. 지난 2년간의 기억 일부가 사라졌으니까요.

- 2년간? 그건 어떻게 안거지?

자리로 돌아와서 제일 먼저 한 것은 메일함을 뒤지는 것이었어요. 아시잖아요. 네트워크의 도움을 조금만 빌리면 자신이 어떤 사람인지 파악하는 것도 그다지 어렵지 않아졌죠. 이제 인터넷은 인간의 기억까지 분산시켜 저장해버리고 있으니까요. 메일함을 뒤지면, 내가 어디까지를 기억하지 못하는 건지 알 수 있으리라 생각했어요. 그래서 메일함을 가장 최근 날짜부터 옛날까지 순서대로 뒤졌죠.

- 그랬더니?

2년 전 메일에 담긴 내용은 기억이 나더군요.

- 그럼 지난 2년간 무슨 일을 했는지, 완전히 잊어버렸다는 거야?

아뇨. 그렇지는 않아요. 메일을 거꾸로 천천히 읽어 나가다 보니, 머리 속에 뭔가 그림이 떠오르기 시작하더군요. 내가 사람들과 무슨 이야기를 했고, 무슨 언쟁을 했으며, 뭘 중요하게 생각했었는지가 조금씩 생각났어요. 결국, 업무에 관한 내용은 50% 정도는 되살릴 수 있었고, 팀장님의 질문에도 답을 할 수 있었죠. 팀장님이 언제 바뀌었는지도 다시 생각났구요.

- 그럼 일시적인 기억 상실인건가?

잘 모르겠습니다. 일상적인 일들은 비교적 쉽게 다시 기억해 낼 수 있었어요. 집도 제대로 찾아갈 수 있었고, 아이들이 어떻게 컸는지도 기억할 수 있었습니다. 핸드폰에 저장된 사진, 그리고 블로그에 적어놓은 글들, 이런 것들이 도움이 됐죠. 제가 지난 2년간 관심가졌던 일들, 하고자 했던 일들, 그런 것들이 메일과 블로그, 핸드폰에 저장되어 있었어요. 그런 것들은, 주변 사람을 걱정시키지 않고도 쉽게 기억해 낼 수 있었고, 설사 기억나지 않는다고 하더라도 다시 기억해 버릴 수 있었죠.

그런데 핸드폰에 저장된 주소록에 이르니 좀 난감해지더군요.

- 무슨 문제가 있었는데?

가족을 빼곤, 주소록에 저장된 이름들이 나와 무슨 관계에 있는 것인지 도무지 기억해 낼 수가 없었어요.

- 기다리면 되지 않나?

네. 기다리면 되겠죠. 기다리면 분명 연락이 올 겁니다. 연락하게 되어 있는 사람이라면 연락을 해 오겠죠. 그런데 제가 그 사람들에게 대체 어떻게 반응해야 하나요? 죄송한데요 제가 기억을 잃었습니다. 그래서 당신이 어떤 사람인지 기억나질 않으니 조금만 힌트를 주시겠어요, 이렇게 물어야 하나요?

- 그렇긴 하군. 말하기도 그렇고, 듣는 사람도 당황스럽긴 마찬가지겠네.

갑자기 병자가 된 기분이에요. 최근까지 작업하던 논문의 내용도 기억이 잘 나질 않아서, 다시 읽어야 했어요. 그리고는 제 컴퓨터와 노트북을 이잡듯 뒤져 소스 코드를 찾았죠. 다행히 데스크탑에 SVN이 설치되어 있었고, 거기에 모든 소스코드의 최신 버전이 있어서 내가 무슨 프로그램을 만들고 있는지 알아내는 건 쉬웠어요. 그 프로그램 가운데 내가 쓰고 있던 논문에 관계된 것을 추리고 걸러내는 일이 힘들었고, 실험 데이터를 어디다 저장해 뒀는지 찾아내는 것이 어렵긴 했지만 말이에요.

- 그런데... 뭘 도와달라는 거지?

제가 지난 2년간, 어떻게 살았는지 말씀해 주세요.

그래서 저는 L에게, 그가 어떻게 살았는지 이야기해 주었습니다. 그의 생활은 단순했습니다. 일찍 출근하고, 일찍 퇴근했으며, 주말에는 아이들과 시간을 보냈다는 것. 작년에는 머리에 껌이 붙어 머리를 박박 밀어버렸었고 그 일로 모두들 재미있어 했다는 것, 프로그래밍이 아닌 일은 도통 하지 않으려 했다는 것, 정신과 치료를 받으러 다녔다는 것, 그리고 최근에는 교회에 나가기 시작했고 새벽기도를 하러 나가는 날에는 기도가 끝나자 마자 부리나케 회사 체육관으로 달려와 몸을 만들었다는 것. 덕분에 식스팩이 생겼다고 팀원들에게 자랑하기도 했다는 것. 회사 사람들에게는 약간 까칠한 인물로 알려져 있었는데 요즘은 사람이 좀 유해졌다는 소리를 듣기도 했으며, 담배를 끊겠다는 결심은 도통 지키질 못했다는 것 등등의 자질구레한 이야기들을 해 주었습니다. 최근에는 책을 쓰고 있었고, 출판사로부터 출판 제의를 받은 덕분에 내년쯤에는 책을 출간할 예정이었다는 말도 해 주었습니다. 이야기를 들으며 그는 웃기도 했고, 한숨을 쉬기도 했으며, 도통 모르겠다는 듯 고개를 저어 보이기도 했습니다.

그래서 거울로 보는 제가 낯설어 보였던 거군요.

- 그렇지, 살이 많이 빠졌으니까.

정신과에는 왜 다녔던 걸까요?

- 모르지. 업무 때문에 스트레스를 많이 받아서 잠을 못 이룬다고 한번 나에게 말을 했던 적이 었었어. 집안 문제 때문에 골치아프다는 이야기도 했었고. 이런 말 하긴 좀 뭣하지만, L씨는 고민이 많은 사람이었어.

책을 쓰고 있다는 것은 알았습니다. 윈도우즈 최근 문서 목록에 제가 쓰고 있던 한글 파일이 링크되어 있더군요. 프로그래머들에 관한 책이었어요. 재미는 없었지만, 어쨌든 출판 제의는 받았던 거로군요.

그는 한참을 말 없이 앉아 있었습니다. 나는 함께 그의 자리로 돌아가, 회사 서버에 쌓여 있는 주간 업무보고 목록을 보여주었습니다. 거기엔 지난 2년간 그가 팀에서 어떤 고민을 했는지, 매주 어떤 업무를 했는지 고스란히 기록되어 있었습니다.

- 이걸 보면 기억을 되살리는 데 도움이 좀 될거야.

우리는 함께 많은 것을 살폈습니다. 가장 큰 도움이 되었던 것은 그가 써 놓은 논문이었습니다. 거기에는 그가 지난 2년간 했던 일의 정수가 담겨져 있었습니다. 저널에 투고를 앞두고 있던 그 논문이, 박사 졸업 이외의 다른 곳에도 쓰임새가 생길 줄은, 그도 미처 예상치 못했을 것입니다. 아니, 예상했더라도 기억에서는 사라져버렸을 터이지요.

가장 문제가 되었던 것은 그가 만든 소스코드였습니다. 걱정하기 보다는 만들고 본다는 그의 모토에 걸맞게, 그의 소스 코드는 간결하고 짜임새가 있었지만 주석문이 부실하다는 문제가 있었습니다. 우리는 함께 자리에 앉아 그 모든 함수들을 하나 하나 밑바닥부터 테스트하고, 테스트 결과를 바탕으로 주석문을 만들었습니다. 그가 시스템을 설계할 당시 만들어 두었던 시퀀스 다이어그램과 인수테스트 문서는 시스템의 전체 얼개를 파악하는 데 많은 도움을 주었습니다. 최종 시스템 테스트가 끝나고 그가 쌓아올린 모든 코드에 대한 기억을 복원하는 데 까지 꼬박 일주일이 걸렸습니다. 그것도 그나마 그가 단위 테스트에는 열심히 주석을 달아 둔 덕분에 일주일이었지, 그렇지 않았다면 한달이 걸렸을 지도 모르는 일이었습니다.

그는 교회에 대한 기억도 다시 되살리고 싶어 했습니다. 그래서 우리는 그의 gmail 계정을 뒤져, 그가 facebook에 계정이 있었다는 것을 알아냈습니다. 그의 facebook 계정에는 그가 읽었던 성경귀절, 그리고 그가 했던 고민들이 몇 줄 안되는 문장이지만 고스란히 남아 있었습니다. 그가 facebook을 했던 시점이 2년이 채 안되어, 그 이전의 일들은 짐작할 수 없긴 했지만 말입니다.

- 꽤 큰 일을 치룬 것 같군.

그러자 그가 말했습니다.

그러네요. 꽤 큰 일을 해냈습니다. 선배님 아니었으면 불가능 했을 거에요. 고맙습니다.

- 고맙긴 무슨...

이 일을 하면서, 또 한가지 기억난 게 있습니다.

- 뭔데?

제가 뭔가 잊고 싶어 했다는 걸 기억해 냈어요. 뭘 잊고 싶어 했는지는 기억나지 않아요. 떠올리고 싶은 생각도 없고요. 떠올리고 싶은 일이었다면, 잊고 싶어 했을 리도 없겠죠. 제 기억 상실이 제 정신적 문제에 대한 방어기제 때문에 생긴 것인지, 아니면 신체적 충격 때문인지 알 수는 없지만, 그건 중요하지 않아요. 중요한 건 제가 기억을 잃었다는 사실이고, 이제 그 기억 중 일부는 영원히 되살릴 수 없는 어딘가로 떠나버렸다는 사실이겠죠.

우리가 그의 기억에 대해 이야기한 것은 그것이 마지막입니다. MRI며 CT며 열심히 받아본 결과 그의 머리에는 아무런 이상이 없었고, 손상된 것은 그의 기억 뿐이었습니다. 그가 마지막으로 했던 말이 떠오릅니다.

행복하다는 생각이 들어요. 이제 저에게 남은 것은 행복했던 기억들 뿐이니까요. 이것도 하나님의 은총이라면 은총이겠지요. 고맙습니다 선배. 신세 두고두고 갚겠습니다.

사람이 죽으면 망각의 강을 건넌다고 합니다. 죽어 망각의 강을 건넌다는 것에는 여러가지 의미가 있겠지만, 아마 이승에서 받은 고통의 기억으로부터 벗어난다는 의미도 있을 거에요. 돌아서는 그의 뒷모습을 보고 있자니, 저승 문턱에도 가보지 못한 그가 망각의 강에 발을 담글 수 있었던 것도 나름 행운이 아니었을까, 하는 생각이 들었습니다.

하지만 저보고 같은 경험을 하라면? 글쎄요. 제가 짠 소스코드를 남의 것처럼 느껴야 한다는 것 만큼 끔찍한 일도 아마 없으리라는 생각이 들어요.

FIN.

Amnesia (from Greek Ἀμνησία) is a condition in which memory is disturbed or lost. Memory in this context refers either to stored memories or to the process of committing something to memory. The causes of amnesia have traditionally been divided into the "organic" or the "functional". Organic causes include damage to the brain, through physical injury, neurological disease or the use of certain (generally sedative) drugs. Functional causes are psychological factors, such as mental disorder, post-traumatic stress or, in psychoanalytic terms, defense mechanisms. Amnesia may also appear as spontaneous episodes, in the case of transient global amnesia - Wikipedia

인사이트에서 "프로그래머의 길, 멘토에게 묻다"라는 제목의 신간이 나왔습니다.

프로그래밍을 처음 할 때에는 잘 몰랐습니다만, 어느 분야에서 전문가가 되려고 맘을 먹은 사람이라면 가장 중요하게 따져봐야 할 덕목중에 하나로 '소통'이라는 것이 있더군요. 간단하게 이야기하면, 우물안 개구리처럼 자기 코드만 들여다 봐서는 절대로 전문가가 될수 없다, 뭐 그정도로 요약할 수 있겠습니다.

그래서 많은 프로그래머들이 직간접적으로 어떤 커뮤니티에 소속되어, 많은 다른 프로그래머들의 이야기를 듣습니다. 시스템 설치시 발생하는 오류에 대한 대처법에서부터 버그 교정법, 그리고 더 나은 프로그램을 만드는 데 필요한 많은 지식들이 이런 커뮤니티를 통해 오고가죠.

저희 회사에서도 그랬습니다만, '사수'라는 제도가 있었습니다. 이 제도를 요즘 유행하는 다른 말로 이름지어 부른다면 '코치'나 '멘토'쯤 되겠죠. 옆에 좋은 멘토가 있으면 (그 멘토의 말을 귀담아 들을 자세가 되어 있다는 가정 하에서) 실력이 느는 속도가 적어도 배는 빨라집니다.

언어를 혼자서 배울 수는 있겠지만, 전문가들과 교류하지 않으면 그 언어의 진수를 깨우치는 데 오랜 시간이 걸리게 됩니다. - 68페이지

이런 이야기를 해 줄 사람이 주변에 많으면 좋은데, 안타깝게도 프로그래머들은 독립적인 성향이 강해서 그런 이야기를 외면하거나, 외면하지 않더라도 주의깊게 귀를 기울이는 일은 드물죠. 듣더라도 실천에 옮기는 경우는 더더욱 드물고요.

이 책에는 프로그래밍 언어에 관한 교훈 뿐 아니라, 다른 교훈도 풍성합니다. 여태껏 단 한번도 멘토를 가져본 적이 없거나, 멘토의 말에 귀를 기울여 본 적이 없는 사람이라면 읽어볼 만한 이야기들이 많다는 뜻이죠. 제가 말로 주구장창 이야기해봐야 감은 잘 안오실 터이고, 몇 가지 인상적인 대목을 추려보겠습니다.

겸손은 성공적인 견습과정의 토대 중 하나다. 야망과 결합될 때, 겸손은 당신을 집중하게 해주며 올바른 방향으로 전진할 수 있게 해 준다. 겸손함이 없다면 견습과정이 끝났다는 판단을 성급하게 내릴 여지가 있으며, 소중한 교훈을 일부 놓칠 수 있다. - 178페이지

소프트웨어를 만들면서 우리는 업무 중에 연습을 하는데, 그것이 업무 중에 실수를 하게 되는 원인이다. 우리는 직업적인 일과 연습을 구분할 방법을 모색해야 한다. 우리에게는 연습 시간이 필요하다. - 190페이지

실패는 불가피한 것이다. 그것은 늦든 이르든 간에 모든 이에게 일어난다. 사실 무언가를 한 번도 실패해 본 적이 없는 사람이라면, 그는 자기 능력의 한계치까지 밀어붙이기를 피해 왔거나 자기 실수를 대수롭지 않게 여기도록 배운 사람이다. - 225페이지

동시성의 다양한 형태(및 그 한계)에 대해서 아는 것이, 'subclass Thread나 implement Runnable'보다 더 유용한 지식이다. - 244페이지

정말 어려운 일은 도구상자의 많은 부분을 버려야 할 때 생긴다. 가끔 당신의 도구들은 구식이 되어 버리기도 하고, 더 좋은 대체품이 나타나기도 할 것이다. 드물게는 당신이 '최첨단'에 대해 정통한 결과, 전에 알던 도구를 소용없게 만들어버리는 무언가를 발명하게 될 수도 있을 것이다. - 253페이지

같은 식으로, 이 책에 실린 패턴과 아이디어 중 많은 부분은 갈등과 저항을 불러올 것이다. 이것은 어느 정도는 현재 상황으로 이득을 보는 사람들, 상황이 개선됐을 때 뭔가 잃을 것을 두려워하는 사람들이 늘 있기 때문이다. - 262페이지

내가 컴퓨터를 처음 접한건 국민(초등)학생일 때 였다. 만화책처럼 묶인 베이직 프로그래밍 입문서를 우연히 구해 읽었는데, 그 뒤로 8비트 컴퓨터를 사 달라고 아버지께 조르고 졸랐다. 결국 내가 처음으로 쓰게 된 컴퓨터는 IQ-1000이라고 불리던 MSX 호환 컴퓨터. 메인보드와 키보드가 일체형이었고, 오래 쓰면 뜨끈뜨끈해져 사람을 불안하게 만들던 컴퓨터였다. 

[이전 글에서 계속...]

우리는 동시성이라는 화두를 두고 한참을 이야기했습니다. 물론 대부분은 동시성을 올바르게 처리하지 못해 겪었던 문제들이었습니다. 별다른 진전을 보지 못하자, 유식이 제안했습니다.

“어쩌면 우리가 동시성이라는 단어를 너무 거창하게 받아들이고 있는 것은 아닌지 모르겠어요. 좀 다른 각도에서 생각해 보면 어떨까요?”

“다른 각도라면...?”

“하나의 메시지가 어디로 와서 어디로 가는지에 한 번 초점을 맞춰서 생각해 보죠.”

“메시지라면 하나의 관리 명령 말인가요?”

“네. 장비에 전송해야 할 하나의 관리 명령. 하지만 그것 말고도 많습니다. 장비가 관리 소프트웨어에 비동기적으로 전송하는 메시지, 그리고 장비가 명령 실행 결과로 전송하는 응답 메시지 등등. 사실 우리가 생각하는 동시성이라는 것은 ‘동시 다발적으로 관리 소프트웨어에 쏟아지는 메시지’를 의미하는 것이 아니었나요?”

“그렇긴 하죠.”

유식은 뭔가 깨달았다는 표정으로 그림을 그리기 시작했습니다.

“자. 여기 메시지가 있습니다. 우선은 관리 명령이라고 해 보죠.”

그가 그린 것은 하나의 원이었습니다.

“이 메시지를 만들어 내는 것은 아마도 GUI일 것입니다. 이 메시지가 최초로 가 닿게 되는 곳은 어느 부분일까요?”

“GUI와의 연결을 관리하는 연결 관리자가 되겠죠. 3-tier 식으로 이야기하면 First Tier?"

"아마 그럴 겁니다. 그럼 그 다음 단계로 통과하게 되는 것은 어디죠?“

“뭘 자꾸 나한테 물어 잘 알면서. 아마도 Business Logic이 실행되는 Middle Tier가 되겠죠. MVC 식으로 이야기하면 Controller쯤 되겠군요.”

“그렇습니다. 그럼 이 메시지는 처리 결과로 전송 레이어를 거쳐 장비로 전송될 겁니다. DBMS에 뭔가를 기록할 일이 있다면 기록하면 될 거구요.”

“그렇다고 보면 되겠죠.”

“그렇다면 이 메시지가 통과하는 지점들을 따라 가다 보면 자연스럽게 동시성 문제가 불거지는 부분을 발견할 수 있게 되지 않을까요?”

“부수적으로는 시스템 구조까지도 어느 정도는 밝혀낼 수 있겠네.”

“그렇죠.”

“이런 걸 MDD(Message-Driven Development)라고 불러도 되려나?”

내 말에 그가 껄껄 웃었습니다.

“뭔가 이름을 붙여야 직성이 풀리신다면 그래도 좋겠죠.”

“결국 메시지를 통해 시스템 컴포넌트를 식별한다는 거니까, 그런 용어를 써도 되지 않을까 싶긴 한데... 아무튼 그건 그냥 농담이었고. 그럼 작업을 해 볼까요?”

그가 그리기 시작한 그림은 점점 복잡해졌습니다. 우리는 그 복잡한 그림을 단순화된 표기법으로 바꾸는 방법은 없을지 궁리하기 시작했습니다. 병행성이 문제가 되기 시작하는 부분을 표시할 수 있으면서도, 시스템 전체의 구조를 표시하는 다이어그램과 조화롭게 어울릴 수 있는 그런 표기법을요. 그 작업은 거의 사흘 동안 이어졌습니다.

사흘 동안, 우리는 오직 그 문제만을 생각했습니다. 사실 경험이 많은 개발자라면 별다른 고민 없이도 해결할 수 있는 문제였을지도 모르겠습니다. 하지만 그 당시 우리에게는 그 문제가 세상 어떤 문제보다도 어렵고 중요했습니다.

“이러다 UML처럼 이런 저런 기호들로 복잡해지는 건 아닌가 모르겠어요.”

그가 말했습니다. 나도 공감했습니다. 범용적으로 쓰일 새로운 언어 체계를 만드는 것은 우리의 애초 목적과는 거리가 멀었으니까요. 그도, 그리고 나도, 자리에 앉아 뭔가를 긁적거리는 시간이 늘었습니다. 머리를 긁적거리는 시간도 덩달아 늘었죠. 그리고 사흘 뒤에, 우리는 다시 마주 앉아 그다지 많은 말을 하지 않고도 하나의 그림을 그릴 수 있었습니다.

 “이 정도가 우리 한계겠죠?”

유식이 말했습니다. 나도 고개를 끄덕거렸습니다. 우리의 평범함이 그렇게 한심하게 느껴진 적은 없었습니다.

“적어도 한 가지는 확실해 졌네요. 우리는 새로운 체계를 만들어 낼 능력은 없는 사람들이라는 거.”

내가 말하자 그는 고개를 저었습니다.

“뭐 설마 그것 뿐이려구요. 아마 같은 생각이시겠지만, 이 그림을 통해 얻은 소득도 많잖습니까? 가령 이 플로우를 역으로 타도록 메시지 방향을 바꾸어야 할 때에는 무조건 새로운 쓰레드를 만들어야 하고, 사용자가 정의한 Business Logic으로 메시지를 튕겨 줘야 할 때도 새로운 쓰레드를 만들어야 한다는 뭐 그런 사소한 사실도 이 그림에 드러나잖아요. 그리고 그런 깨달음을 적을 수 있는 간단한 표기법을 얻었다는 것, 그 정도만 해도 꽤 많이 한 거 아닐까요?”

그의 말을 듣자 위안이 되었습니다. 적어도 우리가 쓸 데 없는 일을 하면서 사흘을 보낸 것은 아니었으니까요.

우리는 그림을 화이트보드에 옮기고 한참을 바라보았습니다. 그리고는 사진을 찍었습니다. 선들이 약간은 어지럽게 그어져 있었고, 식별된 시스템 컴포넌트의 모습이 두서없긴 했습니다만 적어도 우리는 올림푸스라는 신전을 지을 주춧돌은 놓은 셈이었습니다. 모두가 기껍게 보아주기를 기다리며, 우리는 사진 파일을 컴퓨터에 옮기고 메일에 첨부하여 ‘보내기’ 버튼을 눌렀습니다. 그리고는 서로를 바라보며, 멋쩍게 웃었습니다.

“갑시다. 술이나 한잔 하죠.”

3.2 레르나의 히드라

그 뒤로 참 많은 메일이 오고갔습니다. 평생 보낼 메일을 한 주간 몰아 보낸 것처럼 느껴질 지경이었으니까요. 덕분에 OLYMPUS의 구조는 빠르게 자리를 잡았습니다.

마련된 설계안을 회람하고 변경하고 구현 계획을 수립했습니다. 프로젝트 일정이 빠듯했기 때문에 가능한 한 빨리 구현에 착수해야 했습니다. 허동수는 일일 빌드 서버를 만들고 테스트 계획을 만드느라 분주했고, 박팀장은 갑과의 잦은 회의와 의견 조율로 자리를 비우기 일쑤였습니다. 저와 유식은 실제 코드의 뼈대를 만들어 나가기 시작했고, 남기수는 장비와 통신하는 프로토콜을 독자적으로 구현해 나가기 시작했습니다. 이선화는 평소대로 하던 일을 했구요.

그런데 저와 유식은 남기수의 독자 행동이 사실은 좀 불만이었습니다. 그가 코딩을 잘 하고 프로토콜 구현 경험이 풍부하다는 것은 알고 있었지만, 협의를 할 때에도 자기 일 생각에 빠져 말문을 잘 열지 않는 모습이 마뜩찮았던 것이죠. 그의 그런 태도 덕에, 우리는 그가 만들어 낼 라이브러리와 그 API를 사용하는 코드를 대체 어떻게 작성해야 할지 갈피를 잡지 못하고 있었습니다.

그러던 어느 날이었습니다. 유식과 그 문제로 갑론을박하고 있는 와중에 안이태 팀장이 찾아왔습니다.

“박팀장 어디 가셨나?”

“외근 나가셨는데요. 협의하실 게 있으셔서요.”

그렇게 대답하자 그는 잠시 망설이다 물었습니다.

“혼자 가셨나?”

“아뇨. 남기수씨랑 같이 나갔습니다.”

“... 그래?”

순간 그의 표정이 어두워졌습니다. 잠시 나를 물끄러미 바라보던 그는, 물었습니다.

“바쁜가보네?”

“네. 문제가 좀 있어서요.”

“어떤 문제지?”

그러자 유식이 ‘대체 당신이 그걸 왜 궁금해 하는 건데’ 하는 표정으로 그를 바라보더니, 대답했습니다.

“뭐... 사소한 문젭니다. 곧 해결 되겠죠.”

그러자 안팀장은 고개를 끄덕이며 가 버렸습니다. 그러자 유식이 나에게 묻더군요.

“안팀장님 박팀장님한테 너무 관심이 많으신 것 같지 않아요?”

그날 회식 자리에서 무슨 일이 있었는지 알고 있던 저로서는, 뜨끔한 질문이었습니다.

“글쎄요. 뭐 같은 회사에 있고 직위도 같으니까, 관심 갖는 게 당연하지 않을까요?”

모르는 척 눙치긴 했는데, 그래도 찜찜하긴 하더군요. 마침 그때 외근 나갔던 남기수씨와 팀장님이 돌아오는 소리가 들렸습니다.

“잘 다녀오셨어요?”

역시 맨 먼저 인사하는 것은 선화였습니다. 그러자 남기수가 대답했습니다.

“네. 별 탈 없이 잘 끝났어요. 별일 없었죠?”

“아까 안팀장님이 박팀장님 찾으시던데요?”

선화의 말에 박팀장의 표정이 눈에 띄게 어두워졌습니다. 그러더니 지갑을 챙겨 밖으로 나가시더군요.

“저 커피 한 잔만 사가지고 올게요. 한 시간 뒤에 미팅 있습니다, 잊지 마세요.”

밖으로 향하는 표정은 다시 밝아져 있었습니다만, 어쩐지 느낌이 좋지 않았습니다. 따라 나서 볼까 생각했지만, 어쩐지 그래서는 안 될 것 같았습니다. 하지만 사람이 하는 짓이 어디 머리로만 올바르게 다스려 지던가요. 저는 조심스럽게 박팀장의 뒤를 밟았습니다. 예감대로, 박팀장이 향하는 곳은 커피샾이 아니었습니다. 어딘가에 전화를 하던 그녀는, 전화기를 주머니에 넣고 잠시 한숨을 쉬더니 옥상쪽 계단으로 향하더군요. 저는 일부러 한 층 정도 간격을 두고 그녀의 구두소리에 귀를 기울였습니다.

일이 분이나 지났을까, 터벅거리는 슬리퍼 소리가 들리더니 멈췄습니다. 먼저 말을 꺼낸 것은 박팀장이었습니다.

 "당신, 내가 하는 일에 그만 신경 써줬으면 좋겠는데.”

뒤이어 들리는 목소리는, 역시 안팀장의 목소리였습니다.

“그런데 그게 내 마음대로 잘 되지 않아서 말이지.”

평소의 당당하던 목소리가 아니었습니다. 어쩐지 한 풀 죽어 있는 어조였죠.

“우리가 한때 부부의 연을 맺고 살았던 건 사실이지만, 서로 실수였다는 것 인정 했고, 같이 살기에는 너무 다른 사람들이라는 것도 인정 했잖아. 내가 당신 회사에 입사한 건 당신과 같이 일하고 싶어서가 아니었다는 것도 알고 있지 않아? 우리 헤어질 때 앞으로 어떻게 살 것인지에 대해서는 완전히 무관심해 지기로 했던 것 같은데.”

“그 때는 내가 쿨하게 굴었던 것 같은데, 지금은 당신이 쿨하게 구는 군.”

그녀와 그 사이에 무슨 일이 있었는지 확실히 알 수는 없었지만, 적어도 그녀와 그가 부부였다는 것. 그리고 지금은 헤어진 사이라는 것쯤은 분명해 지더군요. 충격이었습니다. 안팀장이 버젓이 버티고 있는 회사에 떳떳이 시험을 보고 들어와 팀장 자리까지 꿰차게 된 그녀의 의중이 무엇인지가 의아하긴 했지만 말입니다.

그 뒤로 그와 그녀는 한 십오 분 간, 그렇게 낮고 쿨한 말투로 이야기를 나눴습니다. 안팀장은 다시 시작하고 싶어 하는 눈치였습니다만, 그녀는 아니었습니다.

“우리는 이미 끝난 사이야. 다시 시작해도 다시 끝나게 될 거고.”

“... 남기수와는 어떤 사이지? 둘이 자주 붙어 다니던 데.”

머뭇거리다 건넨 그의 질문에 박팀장은 코웃음을 치며 대답했습니다.

“팀장과 팀원 사이야. 그 이상도 이하도 아니고. 나는 당신과 그 어린 나이에 헤어진 이후로 단 한 번도 누군가를 만나야겠다는 생각을 해 본 적이 없어요. 남자를 믿지 못하게 된 것은 물론이고.”

그리고 박팀장은 몸을 돌려 계단을 내려오기 시작했습니다. 저는 황급히 반대 방향으로 뛰었습니다. 발소리를 들키면 곤란하다는 생각에 발뒤꿈치를 최대한 들고서 말이죠. 복도에 아무도 없었기 망정이지, 누가 보았다면 저 인간이 왜 저렇게 엉거주춤한 자세로 뛰고 있나, 아마 꽤 궁금해 했을 겁니다.

자리로 돌아온 저는 최대한 숨을 고르며 붉어진 낯을 식히려 애썼습니다. 그러자 유식이 물었습니다.

“뭔 일 있어요? 왜 그렇게 숨을 헐떡대.”

“아... 별일 아닙니다.”

“별일 아니면 여기 이 별 일 좀 같이 보시죠.”

“뭔데요?”

그의 자리로 가자 그가 띄워놓은 몇 개의 터미널이 보였습니다. 유식은 vi 마니아라, Java 프로그래밍을 할 때를 빼고는 좀처럼 IDE 같은 통합 개발 환경을 사용하지 않았습니다.

“지난주에 2,000줄 정도 코딩을 했는데요. 오늘 테스트를 하려고 돌려 보니까 괴상한 오류들이 떠서요.”

“가만있자... pure virtual method called라는 오류가 뜨는군요? 이건 저도 예전에 한번 겪은 오류 같은 데요.”

“그래요?”

“네. 간단히 설명하자면 상위 클래스 객체가 미처 초기화되기 전에 하위 클래스 객체의 가상 함수(virtual method)가 호출되면 생기는 오류죠. 그건 아마 구글 신전에 가서 신탁을 받으셨으면 충분히 해결하실 수 있으셨을 텐데.”

그러자 그가 머리를 긁적거리며 말했습니다.

“그런데 오류가 그것뿐만이 아니라 서요.”

그랬습니다. 한 가지 오류를 수정하고도 화면에는 열 몇 가지 정도의 난해한 버그들이 보고되고 있었습니다. 컴파일 시간에 잡을 수 있는 오류였으면 덜 심각했을 터인데, 하필이면 프로그램 실행 도중에 나타나는 논리 오류였던 것이 문제였죠.

“그럴싸한데?”

갑자기 허동수의 걸걸한 목소리가 들려, 우리 모두는 화들짝 놀랬습니다.

“아니 언제 왔어요?”

유식이 묻자 그가 씨익 웃으며 말했습니다.

“재미있는 이야기들을 하시기에 궁금해서... 뭐가 문젠지 같이 좀 봐도 대겠습니꺼?”

그는 심심하던 차에 잘됐다, 하는 표정이었습니다. 그리고는 키보드를 빼앗더니, 익숙한 손놀림으로 vi를 구동시켜 코드들을 훑어보았습니다. 유식은 부끄러운 듯 얼굴을 붉히고 있었구요.

“테스트 코드가 없네예.”

“네, 아직 못 만들었습니다.”

뒤통수에 습진이라도 걸린 사람 마냥, 유식은 연신 머릴 긁적거렸습니다.

“자아. 그러면 기계적으로 클래스 하나 마다 하나씩 테스트 코드를 만들어 보입시더. 문제가 뭔지 잘 모를 때는 그게 제일이라예.”

“시간 너무 많이 걸리지 않을까요?”

내가 묻자 그가 대체 무슨 말이냐는 표정으로 나를 빤히 쳐다 보더니, 말을 이었습니다.

“이런 식으로 디버깅 하면 더 시간 많이 걸리는 거, 안 겪어 보셨습니꺼? 하긴 머, 테스트 코드를 작성 안해본 사람은 잘 모르제...”

그는 더 말 섞기 싫다는 표정으로 휠체어를 움직여 나와 유식 사이를 빠져 나가면서 한 마디 툭 던졌습니다.

“당장 CPPUNIT부터 설치하이소. 그리고 테스트 코드 다 작성한 다음에, 검사 맡으이소. 적어도 클래스 별로 하나의 테스트 프로그램은 있어야 합니더. 제가 시키는 대로 안 하면 팀장님한테 꼰지를 테니까 하시는 게 좋을 겁니더.”

그래서 유식은 시스템에 CPPUNIT을 설치했고, 소위 단위 테스트(unit test)라 불리는 코드들을 하나씩 하나씩 추가하기 시작했습니다. 2,000라인으로 불어나 있는 클래스들에 테스트 코드를 짜 넣는 것은 그다지 만만한 일은 아니었습니다. 하지만 유식은 별다른 불평 없이 그 일을 해 냈습니다. 그리고 매일 매일, 자신이 작성한 테스트 코드를 허동수에게 보여 주면서 의견을 구했습니다.

“잘 되어 가요?”

사흘 째 되는 날, 내가 유식에게 물었습니다.

“보시겠어요?”

유식이 겸연쩍은 표정으로 액셀 그래프를 보여주었습니다.

“무슨 차트인가요?”

“버그가 어떻게 줄어들었는지 보여주는 그래프예요.”

그의 쑥스러운 표정에서 짐작했던 대로, 버그는 많이 줄어들어 있었습니다. 아니, 거의 없어졌다고 봐도 과언이 아니었죠.

“테스트 케이스가 늘수록, 버그가 줄어들더군요. 결국 문제의 원인은 테스트 없이 코드부터 작성했던 탓이었던 거죠.”

단순한 결론이었습니다. 저는 문득, 레르나의 히드라 이야기를 떠올렸습니다. 헤라클레스는 에우리스테우스의 명을 받고 히드라를 죽이러 갔다가 난감함에 빠집니다. 히드라의 목은 50개였는데, 그 목을 다 베어야 히드라를 죽일 수 있었죠. 그런데 목을 하나 벨 때 마다, 그 자리에서 새로운 목이 두 개씩 돋아나는 겁니다. 결국 히드라의 목은 100개까지 늘어나게 되고 말죠. 전해지기로는 이올라오스의 도움으로 진짜 목을 찾아 벨 수 있었던 덕에 결국 히드라를 죽일 수 있었다고도 합니다만, 테세우스가 헤라클레스를 도와 목이 떨어져 나간 자리를 불로 지진 덕에 결국 100개의 머리를 다 자를 수 있었다는 말도 있습니다.

저는 테스트 케이스가 어쩐지 테세우스가 들고 있었을 횃불 같다는 생각을 했습니다. 초반에 해결하지 못한 버그는, 나중에 더 많은 버그로 불어나 돌아오는 경우가 많았으니까요.

“그런데 한편으로는 걱정이 좀 됩니다.”

유식이 말했습니다.

“뭐가요?”

“이 테스트 케이스들을 어떻게 유지하죠?”

“유지하다뇨? 내버려 둔다고 코드가 썩는 것도 아니잖아요.”

“지금 제가 작성한 코드가 확정된 코드가 아니잖습니까. 나중에 언제든 바뀔 수 있는데 그러면 테스트 코드도 그에 맞게 바꿔야 하는데, 지금 테스트 코드 양이 거의 실제 코드의 절반 수준이거든요.”

생각해 보지 못한 이슈였습니다. 그 때 허동수가 휠체어를 밀고 자리로 다가왔습니다.

“테스트 과정에서 구조가 좀 개선되지는 않았습니꺼?”

“음... 그랬죠. 구조적인 문제 때문에 생긴 버그도 있었으니까요.”

“그렇다면 코드를 나중에 수정할 확률도 떨어졌다고 봐야 하지 않겠습니꺼?”

“그러려나요?”

모두 잠깐 동안 입을 다물었습니다. 그의 말에 일리가 있었습니다. 테스트 코드를 작성하는 동안 유식의 코드는 분명 개선되었을 것이고, 테스트 코드에는 유식이 작성한 클래스들의 사용법이 녹아 들어가 있을 터이니, 나중에 코드 전반을 리팩터링하게 될 가능성은 떨어졌다고 보는 것이 타당했습니다.

“그래도 걱정되시긴 하지예?”

그가 물었습니다. 유식은 고개를 끄덕였습니다.

“그건 그때 가서 생각하입시더. 맘에는 안 드시겠지만...”

유식은 잠시 모두를 물끄러미 쳐다보더니, 말했습니다.

“불안은 영혼을 잠식하는 법이니까요.”

허동수는 잠시 벙 찐 표정으로 그를 바라보다가 소리를 꽥 질렀습니다.

“그건 또 대체 무슨 소린교?”

3.3 케리네이아의 암사슴

흐르는 강물이 바위를 만나면 잠시 쉬었다 돌아가듯 키보드를 만지는 우리의 손길도 잦은 회의에 멈출 때가 많았습니다만, 나름대로는 별 탈 없이 흘러갔습니다. 모든 프로그래머들이 바라는 하루가 있다면 이렇겠지요. 어떤 전화도 오지 않고, 어떤 메일도 오지 않으며, 어떤 손님도 오지 않는 평온한 하루. 마주해야 할 것은 오직 키보드와 마우스 그리고 모니터뿐이고, 마음에는 평화와 코드 말고는 다른 것이 없으며 마치 신의 은혜가 강림이라도 한 것인 양 컴파일러와 런타임 시스템은 문법 오류 말고는 다른 아무 것도 말하지 않는, 그런 날 말입니다.

하지만 제우스가 헤라와의 약속을 밥 먹듯이 어기는 것과 마찬가지로 여 선임은 때로 전화를 걸어 잊었던 무엇이 갑자기 생각나기라도 한 듯 아무렇지도 않게 새로운 요구사항을 이야기했고, 우리는 그 요구사항에 부응하기 위해 코드를 변경하고 또 변경해야 했습니다. 그리고 늦도록 가실 줄 모르는 9월의 더위 덕에, 우리의 야근과 냉커피는 풀가동중인 에어컨이 내뱉는 소음에도 아랑곳없이, 너무나 뜨뜻미지근했습니다.

그러던 어느 날이었습니다. 갑자기 남기수가 자리에서 일어나 소리를 질렀습니다.

“으아악!”

제일 먼저 그의 자리로 달려간 것은 유식이었습니다. 뒤이어 박팀장, 이선화, 그리고 허동수가 그의 자리로 달려갔습니다. 저녁 식사 후 밀려오는 졸음에 꾸벅 꾸벅 졸고 있던 제가 제일 마지막이었죠.

“무슨 일이죠?”

박팀장이 물었습니다.

“저, 저기...”

남기수는 모니터를 가리켰습니다. 그 순간, 모두들 웃음을 터뜨리지 않을 수 없었습니다. 그가 가리킨 곳에는, 큼지막한 나방 한 마리가 붙어 있었습니다.

”뭐꼬. 벌레 한 마리 때문에 이 난리를 피웠단 말인교?“

우리 모두에게는 벌레 한 마리일 뿐이었습니다만, 그에게는 아니었던 모양입니다. 큰 키에 어울리지 않게, 그는 사색이 되어 있었습니다.

“하긴, 벌레를 두려워하는 건 모든 프로그래머의 본성이지예.”

동수의 말에 선화가 깔깔대며 웃었습니다.

“그럼 동수씨도 무서워하는 벌레가 있으세요?”

“저는 다리 많은 건 다 싫어합니더. 지네, 돈벌레, 기타등등, 기타등등...”

그 말에 선화가 고개를 갸웃거렸습니다.

“돈벌레가 뭐에요?”

“머라카드라? 표준말로는 그리마라 하는 거 같더만... 하도 돈벌레라 캐싸서 글마 본 날에는 복권 한 장씩 삽니더. 하지만, 좋아는 안합니더.”

“그렇구나...”

그리고 선화의 뇌까림이 끝나기 무섭게, 나방은 휘릭, 하고 어디론가 날아가 버렸습니다. 그러자 허동수가 또 나직이 읊었습니다.

“자고로, 달을 가리키면 달을 봐야지 손가락은 뭐할라꼬 보노, 라고 했니더.”

그러자 남기수가 대체 뭔 소리냐는 표정으로 물었습니다.

“달을 보다뇨?”

“저기 터미널을 보이소. 프로세스가 죽었다, 하고 떡 하니 찍혀 있다 아인교?”

아닌 게 아니라 그랬습니다. 나방이 날아간 그 자리에 남은 것은, 실행 도중에 죽어버린 프로세스였습니다. 그 화면을 보더니 남기수가 머리를 긁적거렸습니다.

“그러게요. 장비와 통신하는 부분은 거의 완성했고 테스트도 다 되었는데, OLYMPUS쪽과 통신하는 테스트를 하고 있는 데 자꾸 죽습니다. 원인이 뭔지는 찾고 있는 데 아직 잘 모르겠어요.”

그 말을 듣자 박팀장이 난감한 표정으로 턱을 긁었습니다.

“이러면 곤란한데... 여 선임이 아까 전화를 했는데, 일주일 뒤에 지금까지 완성된 시스템을 좀 구경할 수 있느냐고 전화를 해 왔어요. 허동수씨. GUI쪽은 어떻게 되어 가고 있나요?”

“일단 용역을 맡은 친구들이 GUI 코드를 들고 왔는데예. 유식씨가 아래쪽에 가짜 코드를 붙여서 일단 시험은 가능하게 해놨거든예. 그러니까 남기수씨가 돌아가는 코드를 주기만 하면 거기에 붙여서 어떻게든 돌려는 볼 수 있는 상태고, 시험 결과도 나쁘지 않아서 몇 가지 손만 좀 더 보믄 됩니더. 버그 리스트는 엑셀로 만들어서 어제 팀장님께 보고 드린 대로고예.”

허동수의 일처리는 매끄럽고 빈틈이 없어 보였습니다. 역시 테스터답다고 해야 할까요. 문득 남기수의 얼굴에 당혹스러움이 비쳤습니다. 저로서는, 그의 심정을 알 것 같았습니다. 자신의 코드에서 생긴 문제를 남에게 보이기 싫다는 프로그래머 특유의 자존심이 그에게는 유독 강했으니까요. 우리 모두 그가 어떻게 일하는지 알지 못했고, 우리는 그가 보여주는 완성된 코드나 문서를 보고 그가 얼마나 빨리 일하는지, 그리고 얼마나 빈틈없이 일하는지 추측만 할 수 있을 뿐이었습니다. 그런데 불쑥 나타난 나방 한 마리 때문에, 그의 자존심이 무너져 내린 것이죠. 거기다 허동수와 은연중에 비교당하기 까지 했고요. 아, 우연의 힘이란!

“일주일 안에 OLYMPUS에 붙여서 돌릴 수 있겠어요?”

박팀장의 질문에 남기수는 표정을 가다듬었습니다. 한껏 싸늘해져 있었죠.

“그렇게 하겠습니다.”

그 순간 저는 직감했습니다. 그가 잠을 줄여서라도 어떻게든 문제를 해결하리라는 사실을요. 그리고 지금까지 해 왔던 그대로라면, 우리는 그가 어떻게 문제를 해결했는지 아마 영원히 알 수 없을 것이었습니다.

“남기수씨. 저 좀 잠깐 볼까요?”

박팀장이 남기수의 의자를 책상으로 밀어 넣고는 그의 팔을 잡아끌었습니다. 남기수는 ‘어어’ 하더니 저 버그는 어떻게 하고... 하는 표정으로 끌려갔죠.

저는 개발실 한쪽 벽으로 갔습니다. 거기에는 매주 누가 무슨 일을 했는지가 적혀 있었습니다. 그 아래에는 각자의 이름표가 붙어 있는 매직 팬이 서로 다른 색으로 놓여 있었고, 모두들 자기 일을 해치울 때 마다 해야 할 일 목록에 X표를 했습니다. 해야 할 일을 적는 것은 팀장과 팀원들이 상의해서 결정했습니다. 그러다 보니 그 목록은 꼭 가로로 누운 막대그래프 진도표처럼 변해 갔습니다.

그 진도표의 꼴찌를 달리는 사람은 남기수였습니다. 그의 칸에 할 일을 적는 것도 그였고 X 표를 하는 것도 그였는데, 그는 도통 팀장과 상의도 하지 않았고 할 일을 쪼개어 적지도 않았거든요. 그러니 진도를 확인할 방법이 없었습니다. 가끔 팀장이 내가 선 바로 그 자리에서 생각에 잠겨 있는 것을 보곤 했는데, 그녀도 아마 같은 것을 느꼈을 겁니다.

나는 커피를 타 들고 휴게실로 걸음을 옮겼습니다. 회의실에 앉아 이야기를 나누고 있는 박팀장과 남기수가 보였습니다. 박팀장의 손이 테이블 위에 깍지를 끼고 있는 남기수의 손목 위에 놓여 있었습니다. 순간 그런 생각이 들었습니다. 저것은 친밀감의 표시일까요, 아니면 단순히 당신의 심정에 공감한다는 뜻을 전하기 위한 여성 특유의 소통 방법일까요? 안팀장에게 던진 말을 되씹어보면 아마 후자일 겁니다. 하지만 저는 왜인지 그것이 남기수에 대한 박팀장의 호감의 표현이었으면 좋겠다는 생각이 들었습니다.

왜냐고요? 글쎄요. 왜 그런 생각을 했는지는 잘 모르겠습니다. 어쩌면 그녀의 포용력과 남기수의 외로운 성격이 잘 어울릴 거라고 느꼈는지도 모르죠. 아무려나, 박팀장이 누구에게나 호감을 주는 미인이긴 했지만, 어차피 제 일은 아니었습니다. 무심함이 저와 잘 어울리는 건 아니었지만, 그게 저에게도 좋았습니다.

저는 휴게실로 가야한다는 사실도 잊고 계속 복도를 걸었습니다. 복도 끝에는 창이 나 있었습니다. 창밖으로 물결처럼 넘실대는 차량의 흐름을 십분 쯤 바라본 뒤, 저는 다시 자리로 돌아와 모니터를 쳐다보았습니다. 새로운 메일이 한 통 와 있더군요.

- 대수씨. 회의실에서 기다리고 있을 테니 이 메일 보시는 대로 와 주세요.

박팀장의 메일이었습니다. 저는 바로 회의실로 향했습니다. 남기수는 이미 자리를 떴고, 박팀장이 제 몫의 커피까지 타 놓고 저를 기다리고 있었습니다.

“아... 커피 벌써 마셨는데.”

“괜찮아요. 제가 두 잔 다 마시죠. 커피 중독이거든요. 아무리 마셔도 끄떡없이 잠이 들 정도로.”

“그런데 무슨 일이신지?”

박팀장은 머그컵에 제 몫의 커피까지 붓더니 이야기를 시작했습니다.

“남기수씨가 여러 모로 팀원들과 잘 어울리지 못하고 있다는 사실은 대수씨도 알고 계시죠?”

“네. 알고 있습니다.”

“그래서 말인데, 대수씨가 기수씨와 공동으로 코딩 작업을 해 주셨으면 해요.”

“네?”

세상에 불가능한 일은 없겠습니다만, 불가능에 가까운 일은 꽤 많습니다. 코끼리를 냉장고에 집어넣는 것이나 일주일 동안 잠을 자지 않는 것, 그리고 소금을 설탕으로 바꾸는 것 등등이 그 좋은 예죠. 남기수와 공동으로 코딩을 하는 것도, 저에게는 어쩐지 바로 그 ‘불가능에 가까운 일’처럼 보였습니다. 같이 점심을 먹으러 가지 않으면 자리에 있는지 없는지 조차 알기 힘든 사내와 공동 작업이라니요?

“이 작업이 대수씨가 맡고 있는 일을 지연시킬 수 있을 것 같아, 두 주 이상의 여유를 더 드리던지, 아니면 유식씨에게 그 중 일부를 인계하려고 해요.”

“네에.”

박팀장의 뜻은 이미 확고해 보였습니다.

“그렇다면, 두주 정도만 시간을 더 주시죠. 유식씨도 이미 하고 있는 일이 많아서, 제 일 까지 넘기긴 그렇고요. 가능한 한 제가 두 업무를 다 보도록 하겠습니다.”

짧은 회의를 끝내고 남기수의 자리로 가 보니, 그는 굳은 얼굴로 턱을 괴고 앉아 키보드의 커서 키를 또각또각 매만지고 있었습니다.

“아, 오셨어요?”

저를 맞는 표정도 그다지 달갑게 보이진 않았습니다. 제가 먼저 운을 뗐습니다.

“박팀장님께 이야기는 들으셨죠? 저도 갑자기 떨어진 업무라 좀 당황스럽긴 합니다만, 기왕에 같이 작업하기로 했으니 잘 해 봅시다. 그런데 어떻게 공동작업을 하면 좋을까요?”

“그래서 제가 키보드를 하나 더 준비해서 연결해 두었습니다.”

그가 모니터 옆에 세워 둔 무선 키보드를 책상 위로 옮기더니, 저에게 같이 앉을 수 있도록 의자를 권했습니다. 바로 코드부터 들여다보자는 뜻인 듯 했습니다. 그래서 우리는 모니터 하나를 사이에 두고 별다른 말도 없이 코드를 살폈습니다. 프로젝트 빌드에 쓰이는 Makefile을 보았고, 코드 리스트를 보았고, 그가 작성해 둔 디버그 매크로를 보았고, 그가 만들어 둔 개발 문서를 함께 보았습니다. 설명이 필요할 때는 그에게 청했고, 별다른 설명이 필요 없을 때에는 제가 마우스를 움직여 필요한 파일을 열었습니다. 입을 열지 않는 그의 표정은 어쩐지 피곤해 보였습니다. 이렇게 해서 과연 문제가 해결될 수 있을까, 의아해 하는 듯도 싶었습니다.

그렇게 코드를 살피고 분석하기를 사흘이 지나자 그가 만들어 놓은 30개 정도의 헤더 파일과 소스 파일을 모두 일별할 수 있었습니다.

“그럼 이제 버그를 보여드릴까요?”

그가 말했습니다. 고개를 끄덕이자 그가 터미널 몇 개를 동시에 열어 프로세스를 실행시켰습니다. 화면에는 온갖 디버깅 정보들이 출력되기 시작했고, 그는 다시 하나의 터미널을 열어 그 프로세스들에 메시지를 쏘았습니다. 그러자 1분쯤 뒤에, 프로세스 중 하나가 뻗었습니다. SIGSEGV 시그널을 받았다는 메시지와 함께요.

“메모리 문제일 가능성이 제일 크군요.”

“그렇습니다. 그래서...”

그는 자신이 만든 Ruby 스크립트를 하나 보여 주었습니다. 그리고 설명을 시작했습니다.

“한 번 해제된 메모리를 두 번 해제하고 있지는 않은 것인지, 혹시 해제되지 않은 메모리가 남아 있지는 않은 것인지 살펴보려고 모든 new, delete 연산을 매크로로 감쌌습니다. new와 delete가 실행될 때 마다, 할당받은 메모리의 주소와 반환되는 메모리의 주소를 출력하죠. 그리고 Ruby 스크립트를 돌려서 한번 반환된 메모리가 또 다시 반환되는 일은 없는지 검사했습니다. 스크립트 자체는 버그가 없다는 것을 확인한 상태입니다.”

그는 실행 결과로 남은 로그에 그 스크립트를 돌려서 나에게 보여주었습니다. 할당되었다가 프로세스가 죽는 바람에 미처 반환되지 못한 메모리의 주소만이 출력될 뿐이었습니다. 프로세스가 죽기 전까지 실행된 시간을 감안하면, 동적으로 할당되는 메모리의 요구량은 극도로 낮아서, 과연 메모리 문제가 생길 수나 있는 것인지 의심될 정도였죠.

“프로세스들의 실행 속도가 너무 빨라서, 디버깅하기도 어려우셨겠어요.”

내가 묻자 그는 고개를 끄덕였습니다.

“거기다 프로세스들 마다 쓰레드를 몇 개 씩 띄우니까 더더욱 어려웠죠.”

“디버거를 한 번 붙여보는 것은 어떨까요?”

내가 제안하자 그는 그것도 해 봤다면서 직접 어떻게 했는지 보여주었습니다. 그는 프로세스 각각에 gdb를 붙인 다음에, malloc_error_break에 breakpoint를 건 다음 실행했습니다. 그리고 똑같이 실행하자 SIGSEGV 시그널이 뜨는 순간에 프로세스가 멈추면서 디버거도 실행을 중단했습니다.

“함수 호출 경로를 한 번 보죠.”

죽은 지점은 delete가 실행되는 지점이었습니다. 그러니까, 메모리가 반환되다가 죽었다는 이야기였습니다. 문제는, 디버거가 그 원인에 대해서 아무런 힌트도 주지 않고 있다는 점이었습니다. 우리는 SIGSEGV가 발생한 문제의 파일을 열었습니다.

“메모리 할당하는 곳은 바로 위에 있고, 두 줄 아래에서 그 메모리를 다 쓴 다음에 반환했는데 프로세스가 죽는다... 이거 이상하군요.”

그도 당최 이유를 알 수 없다면서 고개를 내저었습니다.

“좀 쉬었다 할까요?”

내가 묻자 그도 흔쾌히 자리에서 일어났습니다. 우리는 휴게실로 가서 자리에 앉았습니다. 원래는 흡연실을 겸하고 있었는데, 건물 전체가 금연 구역으로 지정되면서 이제 담배를 피우려는 사람은 모두 옥상으로 가야 했습니다.

“여기는 그래도 시원해서 좋네요.”

그가 커피를 한 모금 삼키며 말했습니다.

“저랑 붙어 있으려니까 더우시죠?”

그러자 그가 키들거렸습니다.

“혼자 있을 때 보다는 덥긴 하죠. 그런데, 저랑 일하기 불편하지 않으세요?”

그도 자신의 문제가 뭔지 잘 알고 있는 듯 했습니다. 그래서 이렇게 말해주었습니다.

“유식씨가 썰렁한 농담할 때가 사실 더 힘듭니다.”

그 말에 그는 너털웃음을 터뜨렸습니다.

“죄송합니다. 저도 제 문제가 뭔지 잘 아는데, 쉽게 고쳐지질 않네요. 제가 좀 이기적인 성격인가 봅니다.”

“프로그래머들은 대부분 혼자 일 하는 걸 좋아하죠. 그냥 경험 부족이라고 생각하세요. 스스로를 이기적으로 생각하는 건 어쩐지 좀 아니다 싶습니다.”

그러자 그는 갑자기 예전 여자 친구 이야기를 꺼냈습니다. 그를 처음으로 이기적인 사람으로 불렀던 여자. 그는 한참동안이나 그 때 이야기를 풀어놓았습니다. 그가 그렇게 말을 많이 하는 것은, 술 취했을 때 빼고는 처음인 것 같았습니다.

“그래서 가끔, 제 자신이 정말로 이기적인가 생각해보게 돼요.”

그의 말에, 어쩐지 아무런 대답도 할 수 없었습니다. 나는 이기적일까요 이타적일까요? 그런 질문에 자신 있게 답을 할 수 있는 사람은 몇이나 될까요? 어쩌면 우리가 겪는 이기와 이타의 문제는 단순히 기술적인 문제는 아닐까요? 많은 사람들이 다른 사람들과의 관계에 있어서 문제를 겪곤 합니다. 그리고 그런 문제는 좀처럼 가볍게 풀리지 않습니다. 어쩌면 고르디우스의 매듭보다 더 풀기 어려운 매듭일 지도 모르죠.

“어쩌면, 단순히 연습이 부족해서 일수도 있다는 생각, 안 해 보셨나요?”

내가 묻자 그는 무슨 소린가, 하는 표정으로 나를 바라보았습니다.

“스스로 이기적이라고 생각하는 사람보다, 남을 이기적이라 비난하는 사람들이 더 많습니다. 그리고 그렇게 행동하는 사람조차도, 이기적이라고 비난받으면 화를 내죠. 모든 사람들이 ‘이기적’이라는 단어를 부정적으로 느낀다는 뜻입니다. 그런데 말이죠, 이렇게 생각해 봅시다. 바이러스 백신도 만들어 내는 세상인데, 왜 모든 사람들이 싫어하는 ‘이기심’은 세상에서 사라지지 않는 걸까요?”

“왜 그런 건데요?”

“바이러스를 치유하는 방법은 발견되었지만, 이기심을 치유하는 방법은 발견되지 않았거나, 쓰이지 않고 있기 때문이죠.”

“그래서 기술적인 문제라고 말씀하신 건가요?”

“네. 이기적으로 굴지 않을 방법만 체득하면, 적어도 이기적이라 비난 받는 일은 피할 수 있다는 것이죠. 그러다 보면 정말로 마음속의 이기심까지 버리게 될 수도 있겠고요.”

이 사람이 대체 무슨 소리를 하는 거지? 남기수의 표정은 어느 새 그렇게 변해 있었습니다. 저는 속내를 숨길 줄 모르는 그가 어쩐지 마음에 들었습니다. 단순히 팀원으로서가 아니라, 코드를 나눌 수 있는 동료로서요.

우리는 그 자리에 한참 동안 앉아서 이런 저런 이야기를 나누었습니다. 화제는 어느새 이기심의 문제에서 우리가 매만지던 코드 쪽으로 돌아가 있었습니다. 저는 물었습니다.

“그런데, 그 버그가 최초로 발견된 건 언제부터인가요?”

“확실히 기억나진 않습니다만, 코드가 Windows에서도 돌아갈 수 있도록 변경하는 작업이 끝난 뒤부터였던 것 같습니다.”

“메모리 디버깅을 위한 매크로를 삽입한 것이 그 버그 때문이었나요?”

제 질문에 그는 잠깐 생각하더니, 고개를 저었습니다.

“아뇨. 처음에는 코드를 Windows에 어떻게 포팅할 까 고민하다가 Cygwin 플랫폼 위에서 컴파일하고 돌려봤었거든요. 그런데 이상한 예외가 자꾸 뜨더군요. 메모리 문제가 아닐까 고민하다가 메모리 디버깅 매크로를 만들어 넣은 겁니다. 그런데도 그 예외는 사라지지 않았어요. Cygwin 내부에서 발생하는 예외였는데, 도무지 해결할 방법이 없어서 결국 Win32 API를 직접 호출하는 쪽으로 방향을 틀었죠. 그 작업은 일주일 만에 끝났고, Windows 포팅도 성공적으로 끝났죠. SIGSEGV 시그널이 터지기 시작한 건 그 뒤입니다.”

우리는 자리로 돌아갔습니다. 저는 물었습니다.

“그러면 아까 그 코드를 매크로 삽입 이전 코드로 돌려 놔 봅시다.”

우리는 SIGSEGV 시그널이 발생한 부분의 코드만 이전 상태로 돌렸습니다. 그런 다음에 컴파일을 하고, 다시 프로세스를 띄우고 테스트를 시작했습니다.

“이번엔 죽질 않는데요?”

그랬습니다. 삼십분이 넘게 테스트를 했는데, 일이 분이면 발생하던 시그널이 더 이상 뜨질 않았습니다.

“정말 그런데요. 그럼 UNDO해서 매크로가 들어있던 코드로 다시 복구해 보겠습니다.”

남기수의 손가락이 키보드를 몇 번 오락가락하자, 코드는 다시 원래 상태로 돌아갔습니다. 다시 테스트를 시작했고, 이번에는 SIGSEGV 예외가 떴습니다.

“뭐가 문제였는지 찾은 것 같군요.”

내가 말하자 그도 고개를 끄덕였다.

“매크로에 버그가 있었다면 매크로를 사용한 모든 부분에서 같은 예외가 떴을 테니, 매크로 자체에는 버그가 없다고 믿어도 되겠죠?”

그는 대답없이 코드를 뚫어지게 쳐다보았습니다. 나도 함께 바라보았습니다. 저기 어딘가에 그가 저지른, 아니 우리가 미처 알아채지 못한 버그가 숨어 있을 터였습니다.

아주 어렸을 때, 소풍을 가면 꼭 보물찾기를 했습니다. 선생님은 보물이 숨겨진 곳의 단서를 주었고, 우리는 선생님이 신호를 보내자마자 보물을 찾기 시작했는데, 나는 단 한 번도 보물을 찾은 적이 없었습니다. 상품은 언제나 다른 친구들의 몫이었죠. 그 시절을 반추해 보면, 지금 내가 코드 사이에 숨겨져 있는 비합리의 흔적을 따라 버그를 찾는 직업을 가지게 된 것은 신기한 일이었습니다. 나에게는 그런 재능이 없다고 봐야 옳았으니까요. 그 시절, 친구들은 나에게 이야기했습니다.

“이거 같이 먹을래? 너는 하나도 못 찾았잖아.”

딱하다는 듯이 나를 보는 친구들의 말에 나는 언제나 고개를 저었습니다. 내 안의 자존심은 친구들의 호의를 사심 없이 받아들이는 것을 결코 허락하지 않았습니다. 친구들이 손을 내밀면, 나는 언제나 씩씩거리다 울음을 터뜨렸습니다.

“내가 찾을 거란 말이야!”

그 시절의 나를 떠올리자, 입가에 절로 미소가 피어올랐습니다. 남기수에게도 그런 어린 시절이 있었을까요? 그는 보물을 찾아 친구와 나눌 줄 아는 아이였을까요, 아니면 나처럼 자존심에 몸을 떨다 눈물을 흘리고는 선생님의 품에 안기고 마는 아이였을까요?

“씨팔...”

그가 나직이 중얼거렸습니다. 나도 거의 동시에 문제를 알아차렸습니다.

“아래쪽에서는 DEL_ARR 매크로를 썼는데, 위에서는 NEW 매크로를 썼군요.”

“그러네요. 그러니까 그 말은...”

“new[]를 했을 때만 delete[]를 해야 하는데, new를 하고는 delete[]를 해 버렸다는 뜻이죠. 우리가 코드를 원래 상태로 돌려 놨을 때에는 그 짝을 잘 맞췄는데, 매크로 코드를 넣을 때는 짝을 잘 맞추지 못했다는 뜻이죠.”

“왜 그런 일이 벌어졌을까요?”

“NEW(TYPE, ...)와 NEW_ARR(TYPE, SIZE) 매크로를 인자가 딱 두 개인 상황에 적용했을 때는, 컴파일러가 어떤 오류도 내질 않거든요.”

결국, 타이핑 실수였습니다. 컴파일러의 한계를 올바르게 알지 못하고 매크로를 작성한 것도 실수의 원인이었죠. 그가 나를 보며 멋쩍게 웃었습니다. 나도 같이 웃었습니다. 우리는 한참을 넋 놓고 그렇게 앉아있었습니다.

네메아의 사자를 퇴치하고 레르나의 히드라를 죽인 헤라클레스에게 주어진 세 번째 과제는 케리네이아의 암사슴을 생포하는 것이었습니다. 헤라클레스는 1년 동안이나 그 사슴을 쫓았지만 잡지 못했습니다. 결국 지친 사슴이 잠시 쉬는 틈을 타, 사슴의 다리뼈와 근육 사이에 독이 묻지 않은 화살을 쏘아 사슴을 생포하죠.

그 사슴은 아르테미스 여신의 것이었습니다. 헤라클레스는 솔직하게 아르테미스 여신에게 사정을 설명하고 용서를 구합니다. 에우리스테우스 왕에게 사슴을 보여주고 나면, 원래 있던 곳에 풀어놓을 것이라는 말과 함께요. 아르테미스는 헤라클레스를 용서하고 그가 노역을 마칠 수 있도록 배려합니다.

세상에 무서울 것이 없는 헤라클레스조차도 신 앞에서는 겸손했습니다. 어쩌면, 우리가 마주하는 모든 버그는 자존심을 온전히 내버릴 수 있어야 해결될 수 있는 것인지도 모르겠다는 생각이 들었습니다. 프로그래머에게 자신이 만든 코드는 자식과도 같습니다. 작가에게 자신이 쓴 글은 자식이나 마찬가지입니다. 하지만 자기 품 안에서 오냐오냐 키운 자식은 올바르게 성장하지 않습니다. 남에게 끊임없이 부탁하고 조언을 구해야 그나마 바르게 크는 것이 자식이라는 존재죠.

그날, 저와 남기수는 코드를 나누는 방법, 자존심을 버리고 남의 말에 귀를 여는 법을 배웠습니다. 따지고 보면 세상의 문제를 푸는 방법이 전부 한 길로 통해 있을 터인데, 우리는 참으로 힘겹게 그 방법을 배운 셈입니다.

저는 박팀장을 만나 문제가 풀렸음을 보고했고, 그녀는 일이 빨리 풀려 다행이라고 미소 짓는 것으로 수고했다는 인사를 대신했습니다. 저는 다시 제 일로 돌아왔습니다. 나흘 정도 일정이 늦춰지긴 했지만, 만회할 수 없는 수준은 아니었습니다. 설사 감당 못할 문제가 생기더라도, 제 곁에는 손만 내밀면 나를 도와줄 동료들이 있었으니까요.

[다음 글에서 계속...]

어떻게 어떻게 벌써 30회에 도달했군요. 그 동안 관심보여주신 여러분들 감사합니다. 올해 상반기 안에는 이 글이 어떻게든 끝날 것 같군요. ^^

[이전 글에서 계속...]

3.1. 네메아의 사자

"그래... 어쨌든 건강 잘 챙겨요. 몸에 안좋은 건 죄 끊는게 좋을거에요. 담배든 커피든... 녹차 같은 대체제도 활용해 보시구."

"그래야겠죠."

"그건 그렇고... 우리한테 떨어진 똥덩어리 이야기나 해 볼까요?"

그러자 유식이 웃으며 물었습니다.

"아까 팀장님이 일거리 주실 때 무슨 생각하셨어요?"

"글쎄...? 유식씨도 아시다시피 내가 생각이 많은 사람이 아니라서..."

헛 웃음을 웃어 보이자 그도 따라 웃었습니다.

"고객이 아무리 변심하더라도 절대로 바뀔 수 없는 요구사항들로는 어떤 것이 있다고 생각하세요?"

하지만 거푸 질문을 던지는 그의 표정은 사뭇 진지했습니다. 나는 대답했습니다.

"글쎄요. Scalability, Robustness, Availability 같은 것들이 그런 것 아닐까요? 그런 것들은 거의 대부분의 시스템에 요구되는 필수적 덕목이니까요."

그러자 유식이 고개를 끄덕였습니다.

"저도 그렇게 생각합니다. 그런 것들을 어떻게 보면 우리가 개발할 시스템이 갖추어야 할 플랫폼으로서의 속성이라고 부를 수도 있을 것 같은데요."

"플랫폼적 속성이라... 뭐 어차피 우리가 만들 시스템이 개발 플랫폼으로서의 역할을 하게 되니까, 그렇게 봐도 되겠군요."

그는 내 자리에 놓여 있던 자그마한 화이트보드에 마커로 그림을 그려 보였습니다.

"그러니까 이 자리에 우리 시스템이 있고, 이 자리에 우리 시스템 위에 놓일 비즈니스 로직들이 오고, 우리 시스템 아래쪽에 우리 시스템이 관리할 장비들이 놓이게 된다고 봤을 때, 결국 우리 시스템은 비즈니스 로직들이 요구하는 그런 불변조건들을 충족시켜야 된다는 건데요."

"그래서요?"

"그런 조건들을 만족시키는 작업이 우리가 가장 우선적으로 해야 할 일 아니냐 하는 것이죠."

그런데 나로선 그의 그런 말에 100% 동의할 수가 없었습니다.

"그런데 유식씨. 비즈니스 로직이 어떻게 작성될 지 잘 모르는 상태에서 확장성이나 가용성을 우리가 임의대로 설계해서 구현할 수 있을까요?"

"오대리님은 어렵다고 생각하세요?"

"비즈니스 로직이 어떻게 작성될 지를 모르잖아요. 그 말은, 우리가 방금 이야기했던 불변조건들이 그 로직에 어떤 형태로 제공될 지를 예측할 수 없다는 말도 되는 건데."

그러나 제 말에 100% 동의하지 않는 건 유식씨도 마찬가지였습니다.

"꼭 비즈니스 로직이 어떻게 작성될 지를 알아야 할까요?"

"그건 무슨 말?"

"이상적인 소프트웨어 플랫폼이라면, 개발자가 그런 불변조건들이 어떻게 만족되는지 모르도록 해야 할 것 같은데요. OLYMPUS 시스템을 놓고 보면, 비즈니스 로직이 놓여 실행될 수 있어야 하고, 장비와 통신이 가능해야 하고, 비즈니스 로직 간에도 통신이 가능해야 하고. 아주 단순하게 생각하자면 정도의 기능만 있으면 우선은 되는 것이거든요. 복잡한 부분은 오히려 그 위에 놓일 비즈니스 로직일 것 같구요. 오라클 같은 DBMS 쓸 때, 확장성이나 가용성 같은 조건이 어떻게 만족되는 지 생각해가면서 SQL 질의문 만드는 건 아니잖아요?"

"그러니까 유식씨 말은 기본적으로 OLYMPUS는 비즈니스 로직 및 관리 대상 장비 사이의 원활하고도 신뢰성있는 통신을 가능하게 하는 소프트웨어 플랫폼일 뿐이다?"

"네. 덤으로 DBMS 소프트웨어와의 통합도 간단히 지원하구요."

동의하지 않을 수 없었습니다. 그래서 우리는 함께 OLYMPUS가 반드시 갖추고 있어야 하는 '불변의 속성' 리스트를 만들기 시작했습니다. 그날 저녁때 쯤, 대략적인 윤곽이 드러났습니다. 대부분은 역할극 시간에 이미 살펴보았던 것들이더군요.

"이 중 가장 중요한 것은 무엇일까요?"

내 질문에 그가 고개를 갸웃거렸습니다.

"글쎄요..."

"우선 순위를 매기기 어렵다면 설계시 가장 기본적으로 고려되어야 하는 것 부터 따져 볼까요?"

"그러시죠. 오대리님 생각에는 뭐가 가장 기본인가요?"

기본이라... 그가 묻자 갑자기 옛날 생각들이 떠오르더군요. 프로젝트가 끝날 때 즈음 기다렸다는 듯이 밀어닥치던 버그들. 그리고 그 버그들을 교정하느라 하얗게 새버렸던 새벽들. 그 날들을 생각하니, 저는 한 가지 대답밖에는 할 수가 없더군요.

"동시성요."

"동시성이요?"

"네. 병행성(concurrency)이라고 해야 하나?"

"왜 그렇게 생각하시죠?"

"동시성을 고려하지 않고 설계되거나 개발된 소프트웨어는 비결정적(undeterministic) 버그를 만들어 내곤 하죠. 찾기도 어렵고, 찾아내더라도 언제 어느 순간에 시스템을 망가뜨리는 지 추적하기가 아주 곤란한 버그들."

그 말에 그가 반색하며 대답하더군요. 예전에 자기도 그런 문제 때문에 고생했던 적이 있었다는 거였습니다. 하긴 누군들 그런 경험이 없을까요.

"그런데 오대리님. 버그를 피하는 것이 소프트웨어 설계의 주된 목적이 되어서는 안될 것 같은데요."

"버그를 피하자는 것이 아니라, 설계 당시부터 그 점을 고려하지 않으면 견고한 시스템이 나올 수 없지 않겠느냐는 거죠. 소프트웨어의 모든 모듈을 무상태(stateless) 모듈로 만들 거라면 또 모를까..."

"하긴 그도 그렇군요. 그런데 동시성은 소프트웨어를 설계하는 출발점으로 잡기에는 지나치게 추상적이지 않나요? 어디 하나 구체적인 구석이 없으니...."

"확장성이나 가용성 같은 덕목들도 추상적이기는 마찬가지죠. 그런 면에서는 오히려 좀 더 구체적이라고 보는데..."

하지만 그렇게 이야기하는 나로서도 어떻게 첫 발걸음을 떼어 놓아야 할 지는 막막했습니다.

[다음 글에 계속...]

[이전 글에서 계속...]

유식이 내 어깨를 툭 치며, 말했습니다.

"오대리님 블로그에 재미있는 거 적어놨던데, 그러니까 요지가 프로그래머는 예언자쯤 된다 머 그런건가요?"

네이트온 대화명 옆에 블로그 주소를 적어놨더니 들러본 모양이었습니다.

"뭐... 굳이 예언자라고 부를 것 까지는 없는데 프로그래머 없이는 컴퓨터 사용에 필요한 소프트웨어를 구할 수 없을테니까 일반 사용자 입장에서는 그렇게 받아들일 수도 있지 않겠나 싶어서 말이죠."

그러자 유식이 고개를 끄덕거리며 말했습니다.

"그런데 예언자는 보통 소수잖아요? 프로그래머는 그렇게 받아들이기엔 너무 많아 놔서..."

키들거리는 그의 얼굴을 보고 있자니 정말 그렇다는 생각이 들더군요. 프로그래머는 이제 너무 많아서 선지자연 하기에는 희소성이 너무 떨어지는 존재가 되어 버렸습니다.

"그런데 언제부터 프로그래머가 이렇게 많아졌죠? 우리 자랄 때만 해도 프로그래머가 뭐 하는 인간들인지 아는 사람이 드물었는데, 요즘은 초등학생한테 물어도 '아, 게임 만드는 사람들요?' 라고 대충은 대답할 정도니, 진짜 많아지긴 했어요 그죠?"

"많긴 많죠..."

그러자 박팀장이 지나가면서 한 마디 했습니다.

"뭐가 많아요? 어딜 가나 사람 없다고 투덜거리고들 있는데."

그러자 유식이 중얼거렸습니다.

"그러니까 '그정도'로 많은 건 아니라는 거구나..."

"네?"

"아, 아닙니다. 그런데 팀장님. 오늘 업체 분들하고 회의 한다고 하지 않으셨나요? 저번에 도출한 요구사항에 대해서 논의하신다고..."

"네. 맞아요. 그런데 전부 오실 필요는 없고. 저하고 남기수씨 두 사람만 들어가도 될 것 같아요. 다른 분들은 신경쓰지 말고 하던 일 하세요."

유식은 자리로 돌아갔고, 곧 개발실에 정적이 찾아왔습니다. 모두들 파티션에 파묻혀 쥐죽은 듯 지냈죠. 그 고요함이 깨진 것은 오후 세시쯤이었습니다. 박팀장이 종종걸음으로 개발실에 들어오더니, 모두를 호출하더군요.

"지금 즉시 회의실로 모이세요."

웃는 낯인걸 보니 나쁜 소식은 아닌 듯 싶었습니다. 선화가 물었습니다.

"무슨 일이세요?"

"아... 여선임이 우리가 제출했던 요구사항을 보고 수정안을 냈어요. 그런데 별 차이가 없어서, 그냥 개발 진행해도 무리는 없을 것 같거든요. 우선 수정안 검토를 하고, 개발 일정을 잡아야 할 것 같아서 모두 오시라고 했습니다."

정말 그랬습니다. 프로젝터가 보여주는 요구사항 목록은 우리가 제출했던 것 과 신기할 정도로 닮아 있더군요. 모두들 안도의 한숨을 내쉬었습니다. 그런데 남기수만은 마땅치 않아 하는 표정이었습니다.

"뭐 걸리는 거라도 있으신가요 기수씨?"

팀장이 묻자 남기수는 이런 말을 해도 되나, 하는 표정으로 어렵게 입을 열었습니다.

"사실 회의실에서는 모든게 너무 자연스럽게 풀려서 그냥 네네 알겠습니다 하고 말았는데요. 아무래도 여선임 쪽에서도 정확한 고객 요구사항을 모르는 것 같습니다."

"왜 그렇게 생각하시죠?"

"글쎄요. 우리가 생각한 시스템 사용 시나리오는 사실 평범합니다. 개발자로 일해 본 사람이면 누구나 생각해 낼 수 있는, 딱 그정도의 수준이죠. 그런데 실제로 일을 해 보면 그런 평범한 시나리오가 그대로 먹혀 들어가는 일은 잘 없거든요. 뭔가 예외상황이 생겨도 생기게 마련이니까요. 만일 여선임이 생각한 고객 요구사항이 정말로 이 시스템의 실제 사용자, 그러니까 개발자들로부터 나왔다면, 이렇게 단순할 리는 없지 않을까, 하는 생각이 들었습니다. 그러니까 여 선임도 결국 고객 요구사항을 '추정'했고, 그 추정의 결과물을 가지고 우리가 낸 안을 확정한 것이 아니냐 하는 의구심이 들었다는 것이죠."

"추정 결과로 추정 결과를 컨펌했다, 뭐 이런 뜻입니꺼?"

허동수가 묻자 남기수가 고개를 끄덕였습니다.

"네, 뭐 그런 의심이 듭니다."

그러자 팀장이 물었습니다.

"그럴 경우 나중에 우리는 어떤 손해를 보게 될까요?"

모두들 가만히 있었습니다. '뻔한걸 왜 묻고 그러세요'하는 표정들이었습니다.

"시스템을 납품할 때 쯤 요구사항이 바뀌게 되겠죠."

내 말에 모두들 고개를 끄덕였습니다. 그러자 다시 박팀장이 물었습니다.

"그럼 어떻게 하면 좋을 것 같으세요?"

모두들 조용히 입을 닫고 있었습니다. 사실 저는 박팀장의 입에서 뭔가 고수다운 의견이 나오지 않을까 기대했습니다만, 박팀장은 그저 질문하고 답을 기다릴 뿐이었어요. 하지만 아무도 대답을 하지 않자, 결국 박팀장이 입을 열었습니다.

"그럼 일단 이 요구사항 대로 가기로 합시다. 여 선임과 협의해서 이 요구사항이 정말로 고객의 요구사항인지 확인하는 작업은 저와 남기수씨가 하기로 하겠습니다. 오대리와 김유식 주임은 이 요구사항들을 분석해서, 아무리 고객이 변덕스러워도 반드시 만족시켜야 하는 것들이 무엇인지 추려 주세요. 그런 다음에 구현 일정을 다시 논의하기로 합시다."

유식은 '아 드디어 똥무더기가 떨어지는구나' 하는 표정으로 자리에서 일어났습니다. 그 뒤를 선화가 종종걸음으로 따라갔습니다. 문득 '쟤네들 사귀는 거 아냐?'하는 생각이 들었습니다.

"오대리님도 저랑 비슷한 생각 하십니꺼?"

"네?"

허동수가 뜬금없이 물었습니다. 그는 나를 쳐다보며 빙글빙글 웃고 있었습니다.

"저 친구들 사귀는 거 아닐까예?"

"글쎄요..."

"잘 어울리기는 하구마는..."

"잘 어울리긴 하는데, 그런데요?"

내가 되묻자 허동수가 씨익 웃으며 대답했습니다.

"뭐, 그렇다꼬예."

허동수는 휠체어를 밀어 자기 자리로 돌아갔습니다. 전혀 수줍음을 타지 않는 성격인데, 그날따라 허동수의 미소에는 알 수 없는 부끄러움이 배어 있었습니다. 나는 생각했습니다.

'건강 생각해서 술만 좀 줄이면 참 좋을텐데...'

노트를 챙겨 자리로 돌아오자, 유식이 내 의자에 앉아 나를 기다리고 있었습니다.

"주인도 없는 자리에서 뭐하심?"

"뭐하긴요. 오대리님 기다리지. 하달된 지령을 받들어야 할 것 아닙니까?"

"그렇긴 해... 잠깐 이야기좀 할까요?"

"한참 이야기하셔도 됩니다."

우리는 커피를 한 잔씩 타 가지고 소회의실로 갔습니다. 큼지막한 원형 테이블과 다섯개의 의자가 회의실에 놓인 집기의 전부였습니다. 그가 자리에 앉더니 대뜸 말했습니다.

"커피를 좀 줄어야 할텐데... 밤에 잠이 잘 오지 않아요."

"그래요? 언제부터?"

"글쎄요... 한 보름쯤 되었나. 예전엔 베게에 머리를 누이자 마자 잠들었는데 요즘은 그게 잘 안되네요."

"다른 걱정 있는 건 아니고?"

"그런건 아니구요."

[다음 글에 계속...]

[이전 글에서 계속...]

그러자 허동수가 물었습니다.

"왜 바꿀라고 그라시는데예?"

"아무래도, 제우스가 네트워크를 잘 모른다는 경우까지 따져보려면 남기수 씨 말고 다른 분들도 참여해보는 것이 옳지 않겠어요? 겸사겸사 브레인스토밍까지 할 수 있을지도 모르구요."

팀장의 말에 모두들 고개를 끄덕거렸습니다. 다음에 제우스를 맡은 사람은 저였습니다. 이름을 지었으니, 실제로 제우스가 되어 보는 것도 나쁠 것 같지 않았습니다. 저는 앞으로 나가, 제가 OLYMPUS에 기대하는 바를 이야기하기 시작했습니다. 저는 네트워크에 대해서 잘 모르는, UI 개발 경험이 전부인 프로그래머가 되어 입을 열었습니다.

"저는 가능한한 모든 개발 API가 하는 일이 분명했으면 좋겠고, API 별로 기능 분담도 확실하게 되었으면 좋겠습니다. 클래스로 객체를 만들어 메시지를 보낸다는 식의 패턴 보다는, 웹 서비스 형태의 API가 되었으면 좋겠다는 거죠. 필요하면 API를 호출하고, 그러면 그것으로 끝나면 좋지 않을까요? 아무튼 그런 기분으로 코딩할 수 있었으면 좋겠습니다. 그래야 제시간에 퇴근해서 헬스장에도 들를 수 있을 것 같구요."

마지막 말에 모두들 키들거렸습니다. 그렇게, 모두들 역할극에 참여해서 자신이 기대하는 바를 말했습니다. 좀 변화를 주고 싶어서, 나중에는 한 명씩 돌아가면서 OLYMPUS 역할도 해 보았습니다. 그러자 좀 더 즐거워졌습니다. 가장 웃겼던 것은 허동수가 OLYMPUS 역할을 맡았을 때였습니다. '그런건 못해.' '이봐, 좀 더 생각한 다음에 이야기할 수는 없나?'는 식의 엉뚱한 대답을 해 댔기 때문입니다.

그렇게 모두들 즐겁게 회의를 진행했습니다. 자신이 개발자라는 사실을 잠시나마 잊는 듯 한 모습들이었습니다. 아니, 좀 더 정확하게 말하자면 '개발자는 당연히 이래야 한다'는 고정관념을 잠시나마 잊을 수 있어서 즐거워했다고 해야 하겠지요.

"자. 오늘 회의는 이것으로 마칩시다. 선화씨. 오늘 다과도 준비해주고 이것 저것 챙겨줘서 고마웠어요. 모두 선화씨에게 수고했다고 한 마디씩 해 주세요."

팀장이 말했습니다.

"암브로시아를 먹고 넥타르를 마시는 기분이었어요."

유식이 말했습니다. 그러자 선화씨의 얼굴이 빨개졌습니다. 모두들 기분좋은 미소를 지어 보였습니다. 회의실을 나서는 저의 발걸음도 그다지 무겁지 않았습니다. 어쩐지, 모든 것이 다 잘 풀려 나갈 것 같은 기분이었습니다.

그 때, 제 어깨를 두드리는 손길이 있었습니다. 고개를 돌려보니 선화였습니다.

"오대리님."

"네. 말씀하세요."

"그런데 암브로시아가 뭐에요?"

[이전 글에서 계속...]

제우스씨는 그날 많은 말을 했습니다. 아니, 남기수씨가 말을 많이 했다고 해야 맞겠군요. 그날 제우스가 되어 사용자 행세를 한 사람은 남기수였습니다. 아무래도 네트워크 관리에 대해 아는 것이 많으니, 우리도 그가 제우스가 되는 편이 낫겠다고 생각했죠.

"저, 그러니까 제우스는 네트워크 관리 소프트웨어를 만드는 프로그래머입니다."

그가 심각한 표정으로 운을 떼자 여기 저기서 쿡쿡대는 소리가 들렸습니다. 회의실 앞을 마치 키노트 스피치를 진행하는 스티브 잡스처럼 왔다 갔다 하는 그를 보고 있자니, 정말 웃지 않을 수가 없더군요.

"저는 가능하면 적은 노력으로 네트워크 관리 소프트웨어를 개발하고 싶어요. 모든 API가 Thread-safe했으면 좋겠고, 이미 짜 놓은 소스코드를 고치는 일 없이도 새로운 장비를 관리할 수 있도록 customization이 가능했으면 좋겠어요. 내가 알아야 하는 API가 많은 것은 원치 않구요. DBMS에 데이터를 저장하기 위한 API, 장비를 조작하기 위한 API, 모니터링 하기 위한 API, 뭐 그 정도만 있으면 충분했으면 좋겠어요."

그러자 허동수가 나직히 읊조렸습니다.

"아 바라는 게 너무 많아..."

다시 모두들 쿡쿡댔습니다. 하지만 그러거나 말거나, 우리의 제우스는 이야기를 계속했습니다.

"그리고 시스템이나 소프트웨어 일부가 죽어도, 남은 부분은 계속 동작할 수 있었으면 좋겠어요. 아예 다른 시스템으로 failover가 되면 더 좋구요. 그리고 가능하다면, Eclipse같은 IDE와 통합된 개발 환경이 지원되었으면 좋겠어요."

그러자 화이트보드 옆에 서 있던 박팀장이 테이블에 살짝 기대듯 걸터앉으며 물었습니다.

"제우스씨. 그 중에서 가장 중요하게 생각하는 것은 무엇인가요? 아니, 가장 먼저 개발되었으면 좋겠다고 생각하는 것은 무엇인가요?"

그러자 제우스는 잠깐 생각하더니 말했습니다.

"개발하는 데 사용할 Thread-safe한 API 들입니다."

"일단은 라이브러리 형태로만 제공되더라도 개발할 수 있다는 사실만 입증되면 괜찮다는 건가요?"

박팀장이 되묻자 제우스는 다시 생각하더니 대답했습니다.

"네, 그렇습니다."

그러자 박팀장이 웃으면서 모두를 향해 물었습니다.

"일단 제 질문은 여기까지. 우선 우리의 사용자가 무엇을 가장 중요하게 생각하는 지는 파악한 것 같군요. 물론 최종적으로 갑의 인증을 받은 사실은 아니지만 말이죠. 다른 분들은 질문 없으세요?"

그러자 회의 시작때 부터 졸고만 있던 이선화가 갑자기 손을 들더니 말했습니다.

"질문있습니다."

"네, 말씀하세요."

제우스가 웃으며 대답했습니다. 이선화는 뭔가 알쏭달쏭하다는 표정으로 물었습니다.

"제우스님은 나이가 몇살이세요?"

그러자 모두들 헉, 하는 표정으로 웃어댔습니다. 그러나 웃지 않는 사람이 한 명 있었으니, 바로 허동수였습니다.

"아, 잠깐만예. 웃을 일은 아니고 굉장히 좋은 질문 같은데요. 우리의 사용자가 어떤 인간인지를 아는 것은 굉장히 중요합니더. 그런게 파악되지 않고서는, 사실 이런 역할극이 별로 필요 없지 않겠습니꺼? 테스트를 할 때도 테스트를 하는 사람이 어떤 패턴으로 행동하는 지를 파악하는 것이 꽤 중요하거든예. 사용자의 요구를 상상하는 것이 의미있다는 것에는 동의하는데, 그 사람이 어떤 사람인지 구체적으로 그려놓지 않으면 그냥 요구사항을 나열하는 거하고 별반 차이가 없지 않느냐 하는 소리지예."

박팀장이 고개를 끄덕이며 말했습니다.

"허동수씨의 말에도 일리가 있네요. 하지만 그렇다고 제우스가 어떤 사람인지 너무 심층적으로 파들어가다가는 소설을 쓰게 될 것 같은데, 적당히 가정을 하면 어떨까요? 30대 초중반의 남성. 아침 열시부터 저녁 아홉시까지 일하다 파김치가 되어 퇴근하는 전형적인 벤처 프로그래머. 예상하지 않았던 일이 갑자기 닥치는 것을 싫어하는, 평범한 네트워크 프로그래머. 뭐 이정도로요. 네트워크 관리 프로토콜에 대한 이해는 어느 정도 되어 있다고 가정해야 겠군요."

그러자 남기수가 물었습니다.

"그런데 제가 네트워크 관리 프로토콜을 잘 모르면 어쩝니까?"

"네?"

"저, 그러니까 제우스가, 여러분들 만큼이나 네트워크 관리 프로토콜에 대해 잘 모른다면 어떻게 해야 하느냐 하는거죠. 그에 따라 API의 모양도 달라질 수 있습니다."

그러자 박팀장이 고개를 숙이고 턱에 손을 댄 채로 중얼거렸습니다.

"그러니까 제우스가 갖고 있는 도메인 지식이 어느 정도인지 우리로서는 알 수 없다는 건가..."

"그럴 수도 있겠네요."

유식이 고개를 끄덕거렸습니다. 옆자리에 앉아있던 선화도 동의한다는 듯 고개를 끄덕여 보였구요. 그러자 박팀장이 말했습니다.

"그럼 남기수씨 대신, 다른 분이 제우스 역할을 맡아서 역할극을 계속해 보도록 할까요?"

[다음 글에 계속...]

[이전 글에서 계속...]

아무려나, 회식은 그렇게 마무리되었습니다. 노래방을 나선 모두는 조용히 집으로 향했습니다. 새벽 한시쯤인가, 술에 혀가 꼬부라진 허동수가 전화를 해서 '아직도 술 마시고 있는거냐'고 물은 것을 빼고는, 괜찮은 마무리였습니다. 물론 다음날 회의실에 모여앉은 사람들 가운데 한 두 명 정도는 그때까지도 불콰한 표정이긴 했지만요.

그리고 그때부터 쭈욱, 우리는 프로젝트의 방향을 잡고 개발 일정을 정하고 구체적인 개발 방법을 만들어 가는 일에 몰두했습니다. 한 번도 해 본 적이 없는 프로젝트라는 점이 걸리긴 했습니다만, 그렇다고 해서 손 놓고 누군가 완벽한 요구사항 목록을 던져주기를 기다릴 수는 없었습니다. 우리가 만들 시스템의 사용자가 누구며 그들이 무엇을 원할 것인지를 추정해야 했습니다. 그리고 그 결과를 놓고 갑과 토론을 해야만 했습니다.

"OLYMPUS의 사용자는 과연 어떤 사람들일까요?"

팀장이 질문을 던지자 제 머리 속에는 오만가지 생각들이 스쳐갔습니다.

"신전의 사용자는 신들이 아닐까요?"

뜬금없는 제 대답에 박팀장은 웃음을 터뜨렸습니다.

"그렇긴 해요. 가끔 사용자는 우리가 만들 시스템에 신적인 권능을 요구하기도 하죠. 그런 의미에서 보면 사용자는 모두 신들과 같다고 비유해도 무리는 아닐 것 같네요."

그 말에 남기수는 사뭇 진지한 표정으로 이렇게 대꾸했습니다.

"물론 그렇습니다만... 우선은 그들이 '어떤 신'들인지 범위는 좁혀 두어야 겠죠."

램은 '솔라리스'라는 소설에서 세상에 대한 호기심으로 가득찬, 마치 어린아이와 같은 신에 대해 언급한 적이 있습니다. 자신이 가지고 노는 존재들이 무엇인지 알기 위해 이런 저런 시도들을 하지만, 정작 그 결과로 장난감들이 어떻게 망가질 지에 대해서는 알지 못하고 관심도 없는 그런 신 말이에요. 우리가 모셔야 하는 신들이 그러하다면 과연 우리는 어떻게 대처해야 하는 걸까요?

"우선 우리 시스템이 플랫폼적인 성격을 가지고 있으니까, 개발자를 주요 타겟으로 보아야 할 것 같은데요. 플랫폼을 이용해서 네트워크 관리 시스템을 개발할 사람들 말입니다."

유식이 말했습니다. 그러자 팀장이 화이트보드에 그림을 그리기 시작했습니다.

"그러니까 여기 플랫폼이 있고... 그 위에 이렇게 개발자가 있다 이 말이군요."

팀장은 UML의 액터(actor) 기호를 그려넣고는, 그 아래에 '개발자'라고 큼지막하게 적었습니다. 그 아래에는 우리가 만들 플랫폼의 경계가 사각형으로 그려져 있었습니다. 그 안을 채우는 것은, 우리가 할 일이었습니다. 그러자 남기수가 나섰습니다.

"그럼 롤 플레이(role-play)를 한번 해 보는 것은 어떨까요?"

"롤 플레이요?"

"가상의 개발자를 한 명 두고, 그 사람이 우리 시스템을 실제로 어떤 식으로 사용할 것이며 어떤 기능을 요구할 지 역할극을 한 번 해 보자는 것이죠."

그러자 허동수가 말했습니다.

"재미있겠네예."

그러자 남기수가 웃으며 대답했습니다.

"재미있을지는 저도 장담할 수 없습니다만... 적어도 그런 페르소나(Persona)를 만들어 놓고 이야기를 하다 보면, 우리가 상대할 사용자를 좀 더 잘 이해할 수 있을 것 같긴 합니다. 그런 의미에서, 그 사용자에게 이름을 붙여 보는 것은 어떨까요?"

"이름이요?"

박팀장이 물었습니다. 그러자 유식이 말했습니다.

"좋은 생각이네요. 계속 사용자 사용자 사용자 이렇게 부르는 것 보다는, 이름이 있으면 이야기하기 좀 더 편하겠죠. 어떤 이름이 좋을까요?"

모두들 이런 저런 이름들을 내 놓았습니다. 저도 하나를 제안했습니다.

"제우스가 어떨까요?"

"제우스요?"

"네. 그리스 로마 신화에 등장하는 신들의 수장이기도 하고, 가장 제멋대로인 신이기도 하죠. '사용자는 제멋대로다'라는 개발자 사이의 통념에 비추어 본다면 가장 잘 어울릴 이름일 것 같기도 합니다만...'

그 말에 모두들 너털웃음을 터뜨렸습니다.

"제우스라. 거창하긴 하지만 발음하기도 편하고, 괜찮은 이름이군요. 다른 분들 생각은 어떠세요?"

"좋습니다."

결국, 우리의 사용자는 제우스라는 이름을 갖게 되었습니다. 팀장은 화이트보드에 적인 '개발자'라는 단어를 지우고, 그 자리에 '제우스'를 큼지막하게 써 넣었습니다.

"자. 그럼 지금부터 제우스씨가 우리에게 무슨 이야기를 하는 지 들어보도록 하죠."

[다음 글에 계속...]

[이전 글에서 계속...]

저는 소스라치게 놀랐습니다. 자기 여자인 줄 아느냐니? 그들이 나누는 내용은 내가 들어 알고 있는 사실과 달랐습니다. 그렇다면... 저는 짧은 시간에 어느새 결론을 내리고 있었습니다. 안팀장이 박팀장을 못살게 군 것, 프로젝트가 제대로 굴러가지 못하게 괴롭힌 것, 그리고 주차장에서 뺨을 맞은 것 등등은 단순한 시기심의 결과가 아니었습니다.

"물론 내 여자는 아니지."

"그런데 왜 이렇게 쫓아 다니면서 괴롭히는 건데?"

갑자기 안팀장의 목소리가 뚝 끊겼습니다. 주변에서 흘러나오는 취객들의 목소리를 빼면, 사방은 그야말로 괴괴한 적막에 휩싸여 있었습니다. 순간, 그 자리에 더 있어서는 안되겠다는 생각이 들었습니다. 저는 발걸음을 돌려 다시 식당으로 향했습니다. 술이 확 깨는 것 같았습니다.

"어딜 갔다 와요?"

식당 밖에는, 남기수가 서 있었습니다. 그도 정신을 가다듬으려는 듯, 커피를 마시며 담배를 피우고 있었습니다.

"기수씨도 담배 피워요?"

내가 묻자 그는 멋적게 웃었습니다.

"끊었었는데 가끔 이렇게 술 마시면 피우죠. 그런데 어디 다녀 오세요?"

"아 그게..."

그 때 누군가 걸어오는 기척이 느껴졌습니다. 박팀장이었습니다. 남기수가 반색을 하며 말을 건넸습니다.

"팀장님. 어디 다녀 오세요?"

"아... 배가 좀 아파서요."

"여자 화장실은 저쪽이던데..."

그의 말에 박팀장의 얼굴에 당황한 기색이 어렸습니다. 하지만 이내 밝게 웃으며 말하더군요.

"술들은 많이 마셨어요? 기수씨도 많이 취한 것 같네?"

"아뇨... 뭐 그냥 조금... 여선임님이 술이 굉장히 쎄시네요. 같이 오신 분들은 별로 드시지 않는 것 같은데. 조금 있으면 2차 가자고 하실 것 같아요."

"2차라..."

순간 박팀장의 얼굴에 씁쓰레한 미소가 번졌습니다. 술자리가 길어지는 건 영 마뜩찮다는 표정이었습니다.

"자. 들어가죠. 손님을 모셔놓고 이렇게 너무 오래 밖에 있는 건 예의가 아니잖아요?"

박팀장의 말에 우리는 다시 식당으로 들어갔습니다. 아니나 다를까, 여 선임이 웃으며 말을 건넸습니다.

"다들 오셨네요? 지금 2차를 어디 갈까 이야기하던 중이었어요."

"어딜 가고 싶으신데요?"

박팀장이 묻자 여 선임이 대답했습니다.

"뭐... 가까운 노래방이나 갈까요?"

그러자 테이블에 코를 박고 있던 허동수가 고개를 살며시 들더니 물었습니다.

"어디 좋은 데 말씀이십니꺼?"

그러자 여 선임은 허동수를 물끄러미 쳐다 보더니, 웃으면서 말했습니다.

"이 분 좀 취하셨네. 노래방 가서 술 좀 깨고 들어가자는 말이었어요. 괜찮으시죠?"

그러자 조용히 이야기를 나누며 술잔을 돌리던 그의 동료들이 말했습니다.

"여선임 노래방 까지 갈려구? 우리는 먼저 일어나야 할 것 같은데... 애기들이 기다려서 말이야."

그러자 여 선임이 웃으며 말했습니다.

"그럼 나머지는 제가 책임질께요. 두 분은 먼저 들어가시구요."

그리고 우리는 모두 자리에서 일어났습니다. 회식비는 여 선임이 어느새 치른 상태였습니다. 영업부장이 당황해 왜 그러셨냐고 여 선임을 가볍게 나무랐지만, 그는 당연한 것 아니냐고 말하고는 자켓을 걸치고 식당을 나섰습니다. 부장이나, 팀장이나 모두 조금 의외라는 표정들이었습니다.

하지만 허동수는 2차에 참석하지 못했습니다. 노래방들이 전부 지하에 있었던 데다, 그의 휠체어가 내려가기에는 너무 가팔랐던 탓이죠. 그는 이 말을 남기고는 쓸쓸히 사라졌습니다.

"그럴 줄 알았다니깐..."

그러자 여 선임이 말했습니다.

"아이구... 2차 장소를 잘 못 골랐군요."

"아뇨. 어차피 허동수씨 많이 취하셨는 걸요."

내가 그렇게 말하자 여 선임은 그래도 미안한데... 하며 뒤통수를 긁적거렸습니다. 어쩐지, 그와 함께 하는 프로젝트는 이전과는 조금 다를 것 같다는 생각이 들었습니다.

그날의 노래방은 그야말로 광란의 도가니였습니다. 모두 마이크를 놓지 않으려 했고, 노래만 흘러 나오면 몸을 흔들어 댔으니까요. 선화가 노래를 하면 유식이 랩을 했고, 남기수가 흐드러진 발라드로 분위기를 깰라 치면 여선임이 나서서 뽕짝으로 수습했습니다. 영업부장과 과장도 나온 배를 흔들어 가며 보조를 맞추었구요. 노래를 못하는 저는 그냥 탬버린이나 칠 밖에 다른 도리가 없었지만, 그래도 즐거운 자리였습니다.

하지만 그래도 단 한 사람, 모두가 노래방을 나설 때 까지 단 한 곡의 노래도 부르지 않은 사람이 있었습니다. 박팀장이었죠. 그녀는 두시간 동안 내내 웃으며 박수로 장단을 맞추었지만, 한 번도 자리에서 일어나지 않았습니다. 선화가 그녀를 일으켜 세우려고 나섰지만, 그녀는 일어서지 않았습니다. 그저 컨디션이 조금 좋지 않다며 미소를 지을 뿐이었죠. 남기수는 그런 그녀를 가끔 걱정스러운 눈빛으로 바라보았습니다.

[다음 글에 계속...]

[이전 글에서 계속...]

그날 저녁, 예정된 회식이 열렸습니다. 여 선임은 목소리가 꽤 큰 사람이었습니다. 그는 스스럼 없이 우리 팀원들과 어울렸고, 격식에 구애받지 않고 잔을 돌리고 담배를 피웠습니다. 술이 몇 순배 돌자, 그는 잔을 내려놓고 나에게 말을 건냈습니다.

"사실 저는 예전에는 용역 관리를 해 본 적이 없습니다."

"그럼 주로 어떤 일을 하셨나요?"

내 질문에 그는 잠깐 멍하니 허공을 쳐다보다가 대답했습니다.

"주로 개발을 했습니다."

"연구소 특성상 직접 개발을 하실 일은 없을 것 같은데..."

"어쩌다 보니 그렇게 되었습니다. 정상적인 상황이라면 논문을 훑어보고, 솔루션들을 비교해 보고, 대안을 찾는 일이 주된 업무가 되어야 했습니다만, 인력이 부족했죠. 그런 상황에서는 누군가 나서 남들이 하기 싫어하는 일을 떠 맡아야 하죠. 아시겠습니다만, 저희 회사에는 개발에 전문적인 경험을 갖춘 사람이 드뭅니다. 그러니, 남들보다 조금만 더 경험이 있으면 전문가로 행세할 수 있죠."

"네에..."

내가 고개를 끄덕거리자 그는 쓸데없는 이야기를 하고 말았다는 표정으로 잔을 내밀었습니다.

"어쨌든, 앞으로 잘 부탁드립니다. 이번에 잘 해주셔야, 저도 회사에 낯이 서니까요."

"별말씀을... 저희 팀장님을 비롯해서 다른 분들이 능력이 출중하시니까, 어떻게든 되지 않을까 싶습니다."

"팀장님께서 평판이 좋으시더군요. 저도 몇몇 분을 통해 전해 들었습니다. 해서 크게 걱정은 하지 않습니다. 다만 앞으로 제가 이런 저런 요구사항들을 들고 자주 귀찮게 해 드릴지 모르는데, 용역을 하시다 보면 자주 생기는 일이니 저를 너무 미워하지 않으셨으면 좋겠어요."

그가 껄껄 웃자 옆에 앉아 있던 박팀장이 웃으며 끼어들었습니다.

"너무 자주 바꾸시지만 않으면 괜찮아요."

요구사항이 바뀌는 것은 당연하다는 표정이었습니다. 그렇습니다. 요구사항이 너무 자주 바뀌면 갑과 을의 관계는 이내 서먹해지고 말죠. 개발자는 짜증을 내고, 용역 담당자는 '어쩔 수 없다'는 말을 반복하게 되고, 개발 팀장은 지쳐버리구요. 이 바닥에 있는 모든 사람들은 요구사항으로부터 프로그램을 만들어 낼 수 밖에 없다는 것을 잘 알면서도 요구사항에 질려 있었습니다. 프로젝트 마감시한이 가까와 오는데도 일이 전혀 줄어들지 않는 것은, 바로 그것 때문이었으니까요.

술기운 탓이었는지, 요구사항에서 시작된 저의 상념은 어느새 올림푸스라는 이름을 가진 신들의 신전에 가 닿아 있었습니다. 세상 모든 것들의 창조주이면서도 그 모든 것으로부터 비롯된 갈등에서 전혀 자유롭지 못했던 그리스 시대의 신들의 모습은, 모든 것을 만들어 내야 하면서도 그 과정을 온전히 즐길 수 만은 없는 개발자들의 신세와 닮아 있었습니다. 그러니, OLYMPUS라는 프로젝트 이름이 어쩐지 의미심장하게 느껴진 것은 당연하다고 해야 할까요.

앉은 바닥이 너무 뜨거웠던 탓인지, 낯이 금새 벌겋게 달아 올랐습니다. 찬 바람이라도 쐬면 나아질까 싶어 김유식과 담배를 피우러 음식점 밖으로 나섰지만, 한번 달아오른 얼굴은 쉬이 가라앉지 않았고 머리 속은 그리스 신화의 주인공들이 벌이는 분탕질로 어지러웠습니다. 문득 헤라클레스 생각이 났습니다. 에우리스테우스가 던진 열두가지 업을 무슨 어린애 장난 마냥 간단하게 해치우고서도 비극적인 죽음을 맞아, 영웅이 아닌 신으로서 인생을 마감한 헤라클레스 말입니다.

솔직히 말해, 그의 그런 능력이 부러웠습니다. 뒷일이야 어찌 풀리건 간에, 당장 닥친 일을 키보드질 몇 번 만으로 해치울 수 있는 헤라클레스적인 능력이 나의 손끝에 강림하면 얼마나 좋을까? 이런 객적은 생각을 하고 있었던 것이죠. 알콜 뿐 아니라 몽상에도 취해 있던 나를 깨운 것은 김유식이었습니다.

"담배 피우다가 자는 사람은 첨 보겠네. 정말 자요?"

"아니. 서서 자는 사람 봤어요?"

"글쎄. 지금 보고 있는 것 같은데."

"허 참 사람 싱겁기는..."

"그나 저나. 박팀장님 안보이시네. 술취해서 화장실이라도 가신 건가?"

창으로 안을 들여다 보니 정말 박팀장이 없었습니다. 여 선임은 이 사람 저 사람 술을 부어주느라 정신이 없었고, 허동수는 평소와는 달리 일찍 취했는지 테이블에 코를 박고 엎어져 있었습니다. 이선화는 턱을 괴고 뭔가 생각에 빠져있는 표정이었고요. 남기수만 홀로 멀쩡했습니다.

"글쎄... 어딜 가셨나. 먼저 들어가요. 나는 한대 더 피우고 들어갈께."

"그래요 그럼. 그나저나 여 선임이라는 분. 대단하네. 혼자서 소주 세 병은 넘어 마신 것 같은데 취한 것 같지 않으니... 그럼 정신 좀 차리고 들어와요."

나는 잠깐 주변을 걷기로 마음을 먹었습니다. 걷다 보면 정신이 좀 맑아지지 않을까 싶어서였죠. 그런데 모퉁이를 막 돌아서니, 어디선가 익숙한 목소리가 들려 왔습니다.

"당신 정말 이럴 거야?"

박팀장이었습니다. 평소 때의 온화한 어조와는 달리, 그녀의 목소리에는 잔뜩 날이 서 있었습니다.

"내가 뭘 어쩄는데?"

뒤이어 들려온 것은 안이태 팀장의 목소리였습니다. 안 팀장이 대체 여기는 왜?

"왜 내 뒤를 이렇게 졸졸 따라 다니면서 귀찮게 하냐구!"

"몰라서 물어?"

"그래 모르겠다. 대체 왜 그러는데?"

반사적으로, 나는 몸을 웅크려 어둠 속으로 피했습니다. 두 사람 사이에 오고가는 대화는 내가 회사에서 알고 있던 박팀장과 안팀장의 대화가 아니었습니다. 숨죽여 들어야만 하는 사생활의 냄새가 짙게 배어 있는, 그런 말다툼이었습니다. 타인의 인생에 쓸데없는 관심을 갖고 사는 사람은 아니었습니다만, 나는 어느새 '이건 전부 술 탓이야'라는 말을 뇌까리며 귀를 쫑긋 세우고 그들의 이야기를 엿듣고 있었습니다.

"당신, 아직도 내가 당신 여자인 줄 착각하는 거 아냐?"

[다음 글에서 계속...]