허동수의 표정은 차가웠다. 유식이 제안한 방법대로 코드를 수정했더니, 실패한 테스트의 수는 눈에 띄게 줄었다. 하지만 남은 버그들은 요령부득이었다. 점심을 먹을 상황이 아니었다. 밥이 넘어갈 것 같지도 않았다. 허동수는 커피를 찾았다. 너무 많이 마시면 쉽게 잠들 수 없으리라는 건 알고 있었지만, 지금 상황에서는 잠을 줄이는 게 오히려 득이 될런지도 모르는 일이었다.
결국 안팀장은 다른 팀원들과 식당으로 내려갔다. OLYMPUS 과제원 모두는, 굳은 얼굴로 자리에서 일어나질 않았다.
"모두들 입맛이 없으신 것 같네. 그럼 잠깐 회의나 할까요?"
시애의 말에 모두 느릿느릿, 자리에서 일어났다. 신발 바닥에 껌이라도 붙은 사람들 같았다.
회의의 주제는 버그였다. 오직 버그만을 위해 회의를 하는 것은 드문 일이었다. 과제 종료를 한달 앞두고 시스템 안정화에 매진해야 할 시간에, 이런 문제로 모이게 되는 것도 드문 일이었다. 그리고, 팀장을 빼놓고 이런 회의를 여는 것도, 참으로 드문 일이었다.
안이태는 팀원들이 어떤 기분일지 잘 알고 있었다. 스무명 규모의 팀이었지만, 실질적으로는 두 개의 팀이 운영되고 있는 거나 진배없었다. OLYMPUS 과제원들이 자신을 껄끄럽게 생각할 줄은 알고 있었지만, 그것이 팀원 사이의 단합을 해칠 거라고는 예상하지 못했었다. 결국 모두는 하나의 조직원으로 섞이지 못했고, 그것은 온전히 자신의 책임이었다.
하지만 가끔 박시애가 자신을 유령 취급하는 걸 보면, 분통이 터졌다. 나는 내 일이나 잘 하고, 너는 보고 받은 거나 잘 처리하라는 식이었다. 짧은 결혼 생활의 앙금이라고만 치부하기에는 지나친 처사였다. 물론, 스스로 남자 답지 못했었다는 것은 잘 알고 있었다. 무슨 스토커마냥 뒤를 좇았고, 같은 회사에 입사한 시애를 수시로 감시했었다.
'되돌릴 수는 없는 것인가'
그녀와 처음 사랑에 빠질 때 만 해도, 이렇게 뒤가 좋지 않으리라는 건 꿈도 꾸지 못했었다. 항상 재결합을 생각했지만, 시애는 받아주지 않았다. 그녀에게 손찌검을 했던 것이 내내 문제가 되었다. 거기다 지금은, 남기수라는 듣보잡까지 끼어든 상태였다. 어이가 없었다.
하지만 지금 급한 것은 그게 아니었다. 과제 평가가 한달 뒤였다. 비록 다른 장소에 있었지만, 그 순간 안팀장과 시애는 같은 생각을 하고 있었다.
"버그가 얼마나 줄었죠?"
시애가 물었다.
"한 십분지 일 정도 줄었습니더."
동수가 짧게 대답했다.
"그러니까 유식씨가 제안했던 내용이 효과가 있긴 했군요."
"네. 그러니까 이제 공통 라이브러리 부분에는 남은 버그가 없는 셈입니다."
유식은 자신있게 말했다. 하지만 공통 라이브러리가 5,000줄 남짓인데 반해, UI를 제외한 나머지 코드는 거의 60,000줄 규모였다.
"그럼 이제 어떻게 하는 게 좋을까요."
"백업을 기대하는 건 물건너 간 것 같고요."
대수가 씁쓸히 내뱉었다.
"아무래도 전면적인 디버깅을 시작해야 할 것 같습니다."
"그러니까, 실패한 테스트를 중심으로 원인 규명을 해야 한다는 이야기죠?"
"그렇습니다."
"테스트가 전부 몇 개 정도 되죠?"
"5,000개 정도 되는데, 아무래도 디버깅을 진행하면서 두 배로 늘려야 할 것 같네예."
잔뜩 긴장한 사람들을 보고 있자니, 선화의 마음도 얼어붙는 것 같았다. 하지만 유식은, 도무지 지나치다 싶을 정도로 태평스러워 보여 이해할 수 없었다.
'걱정도 안되나봐'
원래 낙천적인 성격이긴 했지만, 그래도 이런 상황에서는 표정이라도 무거워야 하는 것 아닌가, 싶었다. 하지만 한편으로, 그녀는 이런 생각을 하고 있었다. '도울 일이 없어서' 남 탓이나 하고 있는건 아닌가 하는, 그런 걱정. 프로젝트 도중에 어려운 일이 몇 번 있었는데, 그 때 마다 선화는 할 수 있는 일이 없었다. 프로그래밍을 해 보긴 했지만 취미 수준이었고, 어디까지나 자신의 업은 디자인이었다.
'이번에도 그냥 응원이나 해야 하는 걸까'
도넛이 배달되었고, 모두들 커피를 들고 도넛을 깨작거렸다. 입 안에 퍼지는 단맛은 금방 피로를 가시게 해 주었지만, 남의 일처럼 느껴지는 회의 탓에 졸음까지는 달아나게 할 수 없었다.
"그런데 말이에요."
그런데, 정말로 그런데, 선화의 머리를 스치고 지나가는 한 가지 의문이 있었다. 12. 대관절 그 12의 의미는 무엇인가.
"주석에 12, 라고 달려 있었잖아요."
"그런데예?"
"누가 왜 12라고 적은 걸까요?"
기수도 그것이 궁금했다. 주석을 애써 달아놓을 정신머리가 있었던 사람이, 고작 12라고 밖에 적지 않았다는 것은, 거기 무슨 의미가 숨어있다는 증거가 아니었을까.
"혹시, 12라는 숫자와 관련해서 뭔가 생각나시는 분 있나요?"
시애가 묻자 모두들 고개를 갸웃거렸다.
"글쎄요. 보고서 쪽수일 수도 있겠고."
기수가 대답했다. 그러자 유식도 나섰다.
"아니면 12일에 수정했다는 뜻일 수도 있고."
"오늘은 21일이니까 그건 아닐거에요. 만일 그랬다면 훨씬 전에 문제가 생기지 않았겠어요?"
헤라가 내린 광기로 자신의 아이들을 죽인 헤라클레스는 죄값을 치르기 위해 그의 적인 에우리스테우스 밑에서 10개의 노역을 하게 되었다. 만약 그가 성공한다면 자신의 죄를 씻고 불멸자가 될 자격이 주어졌다. 다른 설에는 10개의 노역을 모두 끝냈지만 에우리스테우스는 아이게우스의 외양간을 보상을 받고 청소한 것, 레르나의 히드라를 퇴치할 때 사촌 이올라오스의 도움을 받은 것을 들어서 2개의 노역(헤스페리데스의 황금 사과 따오기, 케르베로스 잡아오기)을 더 시킨다. 이로써 헤라클레스가 했던 노역의 개수는 12개로 늘어났다.
-- 위키피디아
"재수없는 이야기구마."
동수가 투덜댔다.
"왜 재수가 없어요?"
시애가 묻자 허동수는 미간을 잔뜩 찌푸렸다.
"열한번은 더 이런 삽질을 해야 문제가 해결될거라는 소리처럼 들린다 아입니꺼."
"한번은 했으니까?"
"그렇지 않겠습니꺼?"
"재미있네요."
시애가 미소를 지으며 말했다.
"그렇게 따지면 우리가 오늘 고친 버그는 '열 두 번째 버그' 인 셈이네."
"그런 셈이지예."
모두들 웃었다. 정말로 버그가 열두개 뿐이라면, 희망은 있었다. 하루 온종일 수십개의 버그를 잡아 없앤 적도 있었으니, 열두개 정도는 조금만 공들이면 해결할 수 있는 규모의 문제였다.
하지만 정말 그럴까. 정말로 열두개의 버그를 찾으면, 우리가 처한 이 문제는 온데간데 없이 사라지고 마는 것일까. 모두의 마음에 무거운 질문들이 피어나 떠돌았다. 그리고 그 질문들은, 소프트웨어 개발자로서 겪어온 아픔과 고난, 그리고 그 숱한 불면의 밤들을 자양분으로 삼아, 점점 더 크게 자라났다.
호출을 받고 달려온 유식의 첫 물음이었다. 유식은 사태를 그다지 심각하게 생각하지 않고 있었다. 버그 없는 시스템이란 상상할 수 없었고, 모든 버그는 해결 가능한 것이었다. 유식이 보기에, 버그는 '재미있는 것' 이지 '심각한 것'이 아니었다. 하지만 허동수의 표정은 심각했다.
"보이소. 내가 담당한 부분이 아니라서 뭐라고 말을 못하겠네예."
공통 라이브러리에 해당하는 코드 담당자는 유식과 대수였다. 유식은 고개를 끄덕였다.
"제가 맡은 부분이니 제가 봐야겠죠. 그런데 문제가...?"
허동수는 모니터를 가리켰다. 허동수가 가리킨 그곳에는, 소스코드가 변경되었음을 알리는 diff 문자열이 찍혀 있었다. diff는 거짓말을 하지 않았다. 이미 십수년간, 수많은 개발자들이 어루만지고 개선한 프로그램이었다. 그리고 diff는, 유식이 담당한 코드를 누군가 수정했음을 알리고 있었다.
http://dstein.egloos.com/1702045
"어떻게 바뀐 것 같습니꺼?"
어느새 선화와 대수도 유식 뒤에 와 있었다.
"함수 인자 형이 바뀌었고, 코멘트가 한줄 추가되었군요."
"그건 저도 압니더. 내가 알고 싶은거는, 이렇게 바꾸고 나면 시스템에 어떤 영향이 있느냐는 겁니더."
"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) 시스템을 점검한 후 다시 회귀 테스트를 시작했다.
- 위이잉
그 순간 하드디스크가 굉음을 내며 돌아가기 시작했다, 고 느낀 것은 아마 허동수의 착각이었을 것이다. 그는 긴장하고 있었다. 또 실패하면 어떻게 하나. 그 때는 정말로 뒤질 백업도 없는데. 그 때는 정말 팀장에게도 할 말이 없는데.
안팀장의 질책에 허동수는 마른 침을 삼켰다. 귀신이 곡할 노릇이었다. 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
프로그래머 3부를 시작합니다. 언제나처럼, '언제 끝나게 될 지 모르겠습니다'라는 이야기를 드려야 할 것 같습니다만, 이제 어떻게 마무리를 지어야 할지는 알게 된 것 같습니다. :-)
2011년 1월 21일 9:30
"커피나 한 잔 할까예?"
유식의 어깨를 짚는 동수의 턱에 말라붙은 피딱지가 보였다. 면도를 하다 베인 모양이었다. 지나칠 정도로 파르라니 깎여 깔끔해 보이는 하관과는 달리, 그의 눈가에는 피곤이 덕지덕지 달라붙어 있었다. 프로그래머에게 아침 시간 커피는 잠깐의 여유가 아니라 각성제였다. 좀처럼 쫓을 수 없을 것 같은 어지간한 졸음도 걸쭉한 다방커피 한잔이면 쉬이 물러가곤 했다.
"제대로 못 주무셨나 봐요?"
프로젝트 말미에는 누구나 잠을 설친다. 야근하느라 잠을 못자는 경우도 있고, 결과물이 걱정되어 잠을 못 이루게 되는 경우도 있다. 하지만 유식은 어지간하면 눕는 대로 곯아떨어지는 편이었다. 운동 덕분이었다. 선화와 함께 수영장을 다니게 된 뒤로, 유식은 수영을 거르는 법이 없었다.
http://dosiya.tistory.com/354
"누구랑 같습니꺼."
프로젝트가 끝나갈 때쯤 되면 사람들은 의도적으로 말을 아꼈다. 말을 많이 하게 되면 싸울 일도 덩달아 많아지게 되기 때문이었다. 모두가 날카로와져 있기 때문에, 쓸데없는 말은 금물이었다. 농담에도 자존심을 다치고, 그러다 보면 고성이 오가기 일쑤였다. 하지만 허동수는 예외였다. 허동수는 언제나 말을 많이 했다. 그런 그를 고까와 하는 사람도 있을 법 했지만, 대개는 좋게 보았다. 푼수짓에 능했기 때문이었다. 똑똑한 사람과는 싸울 일이, 허술한 사람과는 웃을 일이 많은 법이다. 그는 회사에서 대체로 허술했다. 그리고 누구에게든 스스럼없이 말을 걸었다. 사람들은 그런 그를 거의 항상 고마와했다.
하지만 커피를 앞에 두고 유식과 마주 앉은 허동수는 어쩐지 말이 없었다.
"무슨 일 있습니까?"
유식이 묻자 그가 손사래를 쳤다.
"아입니더. 그냥 좀 피곤하네예."
"테스트 결과 보고서 작성하느라 밤을 새셨나봐요?"
"표납니꺼?"
표가 나는 정도가 아니었다. 동수는 커피 한 모금을 홀짝이고는 창 밖을 바라보았다.
"차가 없으니까 너무 늦어버리면 퇴근이 안대는기라."
허동수는 시쳇말로 구두쇠였다. 휠체어를 탄 채로는 택시 잡기가 어려우니까 콜택시를 부르게 되는데, 그러면 천원이 더 붙는다는 거였다. 간혹 안받으려는 기사도 있는데 미안해서라도 준다는 거였다. 그런데 주고 나면 또 그 천원이 아깝다는 거였다. 그래서 늦으면 아예 휠체어 위에서 자고 간다는 거였다.
"회사에 침대도 있는데 왜 꼭 거기서 주무세요?"
자려고 침대에 가 보면 꼭 일층에는 누가 자고 있더라는 거였다. 2층에는 올라갈 수가 없으니까, 그래서 그냥 앉은 채로 눈을 붙인다는 거였다. 피곤할만도 하겠다,고 유식은 생각했다. 건강한 몸으로 IT 하는 것도 힘든 일인데, 불편한 몸으로 IT 한답시고 야근하면 그건 또 얼마나 힘들까, 하고 생각했다.
"그래도 몇번 자 보면 적응 된다 아입니꺼. 근데, 저번에 마무리한다던 그거는 다 댔습니꺼?"
지난 한주간 허동수가 유식에게 하달했던 지령은 이런 것이었다. 주석이 없는 코드에는 전부 주석을 달라. 최소한 클래스 앞부분이나 함수 앞쪽에는 달아 두라는 것이었다. 그렇지 않으면 대체 뭐가 뭔지 알 수가 없기 때문이었다.
"남기수씨도 주석문에 신경쓰는 성격은 아인거 같은데, 그래도 중요한 부분에는 제법 잘 달아 놨더라꼬예. 이 함수는 무슨 함수를 호출하는 함수고, 어떤 함수가 호출하는 함수고, 뭐 그런 것 까지 시시콜콜 잘 적어 놨더라 아입니꺼. 물론 100으로 보자면 한 20프로나 달았나? 그래서 탈이지만서도...."
"테스트 대신 주석에 신경쓰시는 걸 보니, 이제 우리 프로젝트도 곧 끝나려나봐요."
"한달 남았다 아입니꺼. 별 탈 없이 끝나는 거 같으니 다행이지예. 이제 한달 뒤에 우리 갑선생께서 검수조서에 도장만 꽝, 찍어주면 끝입니더 끝."
"갑선생이라뇨?"
"갑 있다 아입니꺼 갑. 갑을병정 할때 갑. 우리 계약서의 주인, 갑."
아, 그 갑. 유식은 빈 종이컵을 꽉, 움켜쥐었다. 지난달 점검회의때 지적받았던 실수는, 지금 생각해도 낯이 뜨거웠다. 시험을 목적으로 함수의 인자를 임의로 고정시켜두었었는데, 시험을 끝마치고 원래대로 돌려둔다는 것을 깜빡했던 것이었다. 결국 시연장에서 버그가 발견되었고, 유식은 팀장으로부터 호된 질타를 들어야 했다.
회귀 테스트(regression test)를 거치지 않은 코드를 저장소에 반영했던 것은 분명 욕을 먹어 마땅한 일이었다. 두고 두고 새겨두고 반성해야 할 일이었다. 하지만 그에게도 아주 항변할 거리가 없는 것은 아니었다. 시연을 할 코드는 시연 하루나 이틀 전에 주 개발 트리(tree)에서 분리하는 것이 관행이었는데, 평소에는 그런 문제에 철저하던 허동수가 하필 그때는 소스를 분리시켜놓지 않은 것이었다. 당연히 분리된 소스코드로 시연을 진행할거라 생각했던 유식은, 결국 보기 좋게 물을 먹었다.
하지만 그렇다고 허동수를 탓할 수는 없는 노릇이었다. 아니, 설사 탓하는 것이 마땅하다 하더라도 그래서는 안되는 일이었다. 이미 떠나버린 버스가 되어버린 실수 하나 보다는, 같이 밤을 새워 가며 일하는 팀원이 더 소중하게 마련이었으니까. 그리고 어차피, 허동수도 인간이었다. 인간은 원래 실수를 저지르게 되어 있는 것이고, 그래서 인간이라 불리는 것이었다.
"이제 한달 뒤면 그 갑하고도 굿바이네예."
허는 씨익, 웃어보였다. 정말로, 정말로 굿바이. 속시원한 웃음이었다.
"그런데... 왜 이렇게 시끄럽죠?"
유식은 고개를 돌렸다. 소리의 발원지는 개발실이었다. 누군가 평소보다 큰 소리로 떠들고 있었는데, 화가 난 목소리는 아니었다. 당황한 목소리였다. 그리고 그 목소리의 주인공은, 남기수였다.
"우리 도움이 필요한갑네."
허동수는 졸려 죽겠는데 재미있겠네, 하는 표정으로 휠체어를 돌렸다. 으지직, 하는 소리와 함께 이번에는 유식이 비명을 질렀다. 허동수의 휠체어가 그의 발등 위를 보기좋게 찍고 지나가 버린 것이었다.
2011년 1월 21일 10:00
"무슨 일인가요?"
"소스코드가 지워졌대요."
사색이 된 남기수 옆에 박시애가 서 있었다. 차마 입을 떼지 못하는 그를 대신해 대답을 한 것도 그녀였다.
"어쩌다 그랬습니꺼?"
"그게 폴더 이름을 바꾸려다 단축키를 실수로 눌러서 그만..."
허동수가 알만하다, 는 표정으로 남기수의 어깨를 툭, 짚었다.
"진정하이소. 자주 있는 일입니더."
별거 아니라는 표정이었다. 그는 남기수의 터미널로 걸어가 명령어 히스토리를 훑어보더니, 물었다.
"소스코드를 저장소에 커밋(commit)하긴 하신거지예?"
"네. 마지막으로 한 게 어제 아침이었어요."
"그럼 거기서 다시 받으면 되겠구마."
기수의 얼굴에 화색이 돌았다. 왜 그걸 생각 못했지? 하는 표정이었다. 박팀장도 안도하는 표정이었다. 기수는 동수를 밀어내고 급히 svn update를 입력했다.
> Skipped '.'
"폴더가 통째로 날아가서 svn 연결 정보가 사라진 모양이네예. 리파지토리 URL을 주고 소스를 다시 체크아웃(checkout) 해야 되겠습니더."
"그래야겠네요. 수고해요 기수씨."
박팀장은 기수의 어깨를 살짝 짚어주고는 가 버렸다. 무슨 일인가 기웃거리던 오대수도, 그리고 뭔가 해서 뛰어 왔던 유식과 동수도 자리로 돌아갔다.
하지만 혼자 남은 남기수는 편치 않았다. 스스로 꽤 능숙한 개발자라고 생각하고 있었는데 그런 어이없는 실수를 저지른 것도, 그리고 복원 방법을 생각해 내지 못한 것도 마음에 들지 않았다.
'부끄럽다.'
하지만 부끄러워 하는 것도 사치였다. 일단 소스코드를 복원하고, 미처 마무리짓지 못한 문서 작성도 마쳐야했다. 명령어를 입력하자, 순식간에 소스코드 트리가 재구성되었다. 남기수는 잽싸게 컴파일을 마치고, 테스트를 돌렸다. 이미 어제 테스트를 마친 코드였지만, 웬지 다시 점검해두지 않으면 무슨 일이 생길 것만 같았다. 어쩐지, 일진 사나운 하루가 될 것 같은 예감이 들었다.
> 13 Tests Failed: See log files for detailed report
'뭐지?'
그가 난데 없는 오류 메시지에 당황하자마자, 오대수의 자리에서도 비명이 들렸다.
"어라?"
그러자 유식이 자리에서 일어나 대수에게 물었다.
"대수씨도 테스트 실패했다고 나오죠?"
"네. 어제까지는 테스트에 문제가 없었는데 왜 이러지?"
2011년 1월 21일 10:30
'음료가 매우 뜨거우니 주의하세요.'
평소에는 한 번도 눈여겨 보지 않는 문구였다. 고온의 음료에 데일 수 있으니 알아서 조심하라는 경고 문구가 적힌 골판지가 아침에 받아온 종이커피잔을 감싸고 있었다.
'커피를 엎질러 손을 데더라도, 위험하다는 것을 알렸으니 자기네들 책임은 없다는 거로군.'
그런 것이 한 사람을 대하는 대기업의 자세였다. '공지'로 위험을 '회피'하려는 고전적인 전략. 시애는 웬지 세상살이가 지겹다, 는 생각을 하고 있었다.
상념에 잠겨 커피향을 음미하고 있을 즈음, 갑자기 팀원들이 분주하게 움직이기 시작했다. 무슨 일인지 알아봐야 할 것 같은데도, 눈은 계속 커피잔에 머물러 있었고, 생각은 아침에 들렀던 커피 전문점 주변을 떠돌고 있었다.
'팀장이 알아서 하겠지.'
하지만 프로젝트 관리는 팀장이 그녀에게 맡긴 임무였다. 덕분에 시애는 참으로 오래간만에, 코딩 한 줄 하지 않고서 몇 달을 보낼 수 있었다. 하지만 강제로 책임자 자리에서 격리된 후, 코딩마저 하지 않으니 그야말로 세상살이가 지겹고 건조했다. 결국 그녀는 다시 코딩의 세계로 돌아갔다. 하지만, 열심일 수는 없었다. 시쳇말로, 마음이 떠 버린 것이었다.
소란의 발원지는 남기수였다. 소스코드를 날려 먹은 것이 사건의 시작이었다. 그러나 다른 팀원들이 몰려와 한마디씩 거든 덕분에, 그녀는 곧 자리로 돌아올 수 있었다.
남기수가 그렇게 당황하는 것은 처음 보았다. 백짓장처럼 하얗게 질린 표정은 엄마에게 거짓말을 들킨 어린아이 같았다. 평소같았으면 그의 그런 표정이 귀여워 보여 가슴이라도 뛰었겠지만, 사실 그럴 기분은 아니었다. 자기 일에 매진하는 기수의 태도에는 높이 볼 구석이 많았지만, 가끔은 자부심과 신비주의가 지나쳐 팀웍을 해쳤다.
한두번 주의를 주자 좋아지는 듯 했지만, 쉽게 달라지리라는 기대는 버렸다. 숱하게 보아 와 알고 있는 사실 한가지는, 사람의 태도가 본질적으로 바뀌는 데는 몇 년의 시간도 모자라다는 것이었다. 프로그래밍 실력이 좋긴 하지만, 남기수도 그저 한 사람의 사내일 뿐이었다. 사내들이 하는 짓은 대체로 비슷했다.
문득, 막 피어오르지도 못하고 끝나버린 짤막한 결혼 생활이 떠올랐다. 혼인신고조차 할 시간 없이 막을 내린, 철없는 결혼이었다. 1년도 안되는 시간 동안 그녀가 배운 교훈은, 사람을 함부로 믿어서는 안된다는 것이었다. 그리고, 믿을 수 없는 사람과는 멀리 떨어져 지내는 것이 좋다는 것이었다. 하지만 그녀는 그 교훈을 제대로 실천에 옮기지는 못하고 있었다. 안이태와 한 회사에서 근무하겠다는 결정을 내린 것이 바로 그것이었다. 최악의 결정이었다. 안이태는, 아직도 집착과 복수심에 사로잡힌 졸렬한 수컷이었다.
하지만 과거사를 되짚는 것도 여유 있을때나 하는 일이었다. 갑자기 오대수의 자리에서도 비명이 들렸다. 시계는 열시 삼십분을 가리키고 있었다.
'아무래도 길고 피곤한 하루가 될 지 모르겠군.'
시애는 자리에서 일어나 오대수의 자리로 걸음을 옮겼다. 언제 소리를 질렀느냐는 듯, 그는 잔뜩 웅숭그리고 앉아 모니터를 응시하고 있었다.
"무슨 일이에요?"
"테스트가 깨졌다고 나옵니다."
"언제 마지막으로 회귀 테스트를 마쳤는지는 점검해 봤어요?"
시애가 묻자 대수는 모니터를 돌려 차트를 보여주었다.
"어제 저녁까지는 실패한 테스트가 없었습니다. Hudson이 한시간 마다 다시 전체 패키지를 빌드하고 테스트를 하는데, 새벽 다섯시까지는 문제가 없었어요."
"그 뒤로는요?"
"이상한게 그 뒤로는 테스트가 실행된 기록이 없습니다."
"그래요? svn에 마지막으로 소스코드가 반영된 기록은요?"
"잠깐만요."
그가 키보드를 두들겼다. 화면에 어지럽게 아스키 텍스트들이 뿌려졌다.
"오호."
뭔가 발견했다는 듯, 대수가 나지막히 감탄사를 내뱉었다. 화면을 보는 박시애의 눈도 반짝였다. 대수가 말했다.
"아침 여섯시에 누군가 소스코드 전부를 다 commit 했군요."
"그렇다면..."
"모든 파일들이 전부 덮어쓰기 되었다는 이야기죠."
"commit 메시지는 뭐라고 남았나요?"
보통 소스코드를 수정하고 저장소에 반영(commit)할 때에는, 무슨 연유로 어디를 고쳤는지를 commit 메시지 형태로 남기도록 되어 있었다. 누가 뭘 어떻게 고쳤는지 확인할 목적이었다.
"아무래도, commit -m "" 이라도 한 모양인데요."
그러니까, 아무런 메시지도 남기지 않았다는 뜻이었다. 난감한 노릇이었다. 소스코드가 전부 다 덮어쓰기 되었다면, 마지막으로 수정된 파일이 무엇인지도 알 수 없었다. 한가지 해결책은, 아침 여섯시 이전으로 소스코드를 복원하는 것이었다.
"복원은 할 수 있겠어요?"
시애가 묻자 대수는 머리를 긁적였다.
"그게 말이죠. commit 하기 전에 친절하게도 예전 소스코드를 싹 밀어버린 다음에 commit 했네요. "
프로그래머 2부가 좀 많이 (?) 수정되었습니다. 예전에 한참 '프로그래머'를 연재했을때, 많은 분들이 관심을 보여주셨던 것에 비하면, 진도는 지지부진합니다. 현재 3부를 대폭 수정해서 쓰고 있는데, 그 전에 수정된 2부를 보여드립니다.
- - -
2부.
"모두 반갑습니다."
박팀장이 입을 열었습니다. 회의실이 어떻게 설계되었는지는 몰라도, 그녀의 목소리는 마치 노래방 마이크를 통해 나오는 소리처럼 울렸습니다. 그녀의 입가에는 미소가 어려 있었습니다.
"이제 모두 모였으니, 간단히 자기소개부터 하죠. 아마 오늘 첨 뵙는 분도 있을 것 같은데... 우선 제가 먼저 간단히 말씀드리면, 저는 팀장인 박시애구요. 제 오른쪽에 앉으신 분부터 시계 반대 방향으로 남기수, 김유식, 허동수, 이선화, 그리고 오대수씨입니다. 저까지 포함 전부 여섯 분이군요. 우리 팀 이름은... 그게 좀 애매한데요. 네트워크 관리 기술 개발팀이에요. 이름만 들어서는 대체 뭘 하자는 건지 알기가 좀 어렵죠? 사실 저도 아직 감을 잡지 못하고 있습니다. 그건 차차 나아질 테니 양해해 주시구요."
그녀는 잠시 말을 멈추고 모두를 웃으며 차례차례 바라보았습니다. 그리고는 다시 말을 이었습니다.
"자. 그러면 한 분씩 개인 소개를 해 볼까요? 우선 제 왼쪽에 앉은 오대수씨부터."
그리고 그녀는 내 얼굴을 빤히 쳐다보았습니다. 제 얼굴은 순간 붉어졌습니다.
"아... 반갑습니다. 오대수입니다. 이 회사에 입사한 지는 일년 남짓 된 것 같습니다. 입사 후에는 김유식 주임과 같이 일을 했구요. 직급은 대리입니다. 주로 해 온 일은... 아마 여러분들도 비슷하실 것 같습니다만, 프로그래밍입니다. 뭐 남들보다 잘 하는 건 아니구요. 그냥 먹고 사는 데 지장 없을 정도로 합니다."
그러자 모두들 미소를 지어 보였습니다. 나도 다를 것 없다는 뜻의, 겸손한 웃음이었습니다.
"좋아하는 것은 책읽기, 남 이야기 들어주기 등등입니다. 사실 그동안 먹고 사느라 바빠서 특별히 특기 같은 걸 만들 새가 없었습니다. 앞으로도 다를 것 같지는 않지만요."
"어떤 책을 좋아하세요?"
박팀장이 물었습니다.
"아... 뭐 그냥 잡다하게 읽습니다. 일 때문에 보는 책을 뺀다면, 그리스 로마 신화 류의 서적을 좋아하는 편이구요."
"결혼은 하셨어요?"
남기수가 물었습니다. 너무 상투적인 질문이다 싶었는지, 그는 다소 겸연쩍게 웃고 있었습니다.
"아뇨. 아직 못했습니다. 역시 먹고 사느라 바빠서..."
내가 헛웃음을 웃자 모두들 따라 웃었습니다. 역시, '나도 마찬가지 신세요' 하는 듯한 표정들이었습니다.
"프로그래밍 언어는 보통 뭘 쓰십니까?"
허동수가 물었습니다. 프로그래머들끼리 모여 앉으면 한 번 씩은 할 법한 질문이었습니다. 애써 경상도 사투리를 자제하려는 듯 말하고 있었습니다만, 허동수의 말투에는 특유의 억양이 짙게 배어 있었습니다.
"뭐... C++하고 Java를 좀 쓸줄 압니다. JavaScript도 조금 할 줄 알고... 다른 언어는 잘 모르구요."
모두들 고개를 끄덕였습니다.
그리고 한참 동안, 모두들 자기소개를 했습니다. 이선화가 낭랑한 목소리로 자기소개를 할 때는 모든 총각 사원들의 눈이 빛났습니다. 김유식 주임만 빼구요. 허동수는 아주 진지한 태도로 길게 자기소개를 했고, 김유식은 아주 짧게 소개를 마쳤습니다. 남기수는 말하는 내내 뭔가 좀 불편한 표정이어서 모두를 의아하게 했습니다. 나중에 알고 보니 원래 공식적인 자리에서 말 할 때는 좀 불편해 하는 성격이더군요.
모두의 소개가 끝나자, 박팀장은 다시 간단하게 자기소개를 했습니다. 그리고는 말했습니다.
"다시 한 번, 반갑습니다."
모두가 반갑습니다, 하고 한 목소리로 대답했습니다. 박 팀장은 웃으면서 말을 이었습니다.
"보시다시피, 우리 팀은 아주 작은 팀입니다. 우리 회사에서도 이례적으로 작은 팀이죠. 위에서는 프로젝트를 진행하면서 필요한 사람을 그때그때 충원하던지, 아니면 다시 용역을 주던지 하라고 이야기하고 있어요. 뭐, 저도 필요하다면 그렇게 할 생각입니다. 하지만 정말 그럴 필요가 있을지를 우선 알아보아야 할 거고, 앞으로 한 달 정도는 그 작업을 할 생각이에요."
그리고 박팀장은 모두에게 몇 장짜리 유인물을 나누어 주었습니다.
"자. 모두들 한 부씩 받으시고요. 우리가 앞으로 진행할 프로젝트가 어떤 프로젝트인지, 그리고 우리가 무슨 일을 해야 하는지를 간단하게 적어보았습니다. 제가 간단하게 설명을 해 드릴게요. 그런데 그 전에……."
박팀장의 눈길이 김유식에게 가서 멎었습니다.
"김주임님. 이전 팀에 계실 때 총무 하셨었죠?"
"네. 맞습니다."
"혹시 이번에도 해 주실 수 있나요?"
그러자 그가 웃으며 대답했습니다.
"네, 얼마든지요."
박팀장의 얼굴에 다시 웃음이 번졌습니다.
"가장 심각한 문제가 해결되었군요."
그 말에 모두들 웃었습니다. 약간은 딱딱했던 분위기가 풀어지는 느낌이었습니다.
"위에서 허락해 줄지는 모르겠지만, 한 달에 하루 정도는 일을 쉬고 밖에서 재충전의 시간을 갖도록 하겠습니다. 같이 영화를 봐도 되고 밥을 먹어도 되고 아니면 세미나를 해도 되고... 그러려면 회비가 필요한 데 한 달에 만 원 정도 총무님이 각출해서 관리해 주세요. 모자라는 돈은 제가 처리하도록 하겠습니다."
다들 조금은 뜻밖이라는 듯이 서로를 쳐다보았습니다만, 싫어하는 눈치는 아니었습니다.
"자. 그러면 제 프리젠테이션을 시작하죠. 대수씨. 프로젝터 바로 앞이신데, 좀 켜 주시겠어요?"
그리고 그녀의 발표가 시작되었습니다. 우리가 해야 하는 일은 회사의 주력 사업 영역에서는 한 발 물러서 있었습니다. 네트워크 장비 관리 시스템을 만드는 일이 우리가 해야 하는 일이었죠. 웹 브라우저를 통해 구현되는 클라이언트와, 웹 서버 위에서 돌아가는 서버 시스템을 만들어야 했습니다. 그리고 그 서버는 사용자가 등록한 네트워크 장비에 사용자가 원하는 설정을 내릴 수 있어야 했습니다. 모두들 그런 종류의 프로그램에는 경험이 없었습니다. 관리해야 하는 네트워크 장비라는 것도, 생소하기 짝이 없는 물건들이었습니다. 스위치나 허브 같은 거야 일상적으로 쓰이는 물건들이니 낯설 건 없다고 할 수 있겠지만, 라우터(router) 같은 장비에 이르면 남기수를 제외한 모두가 문외한이었습니다.
"라우터라는 게 뭡니꺼?"
허동수가 불쑥 질문을 던졌습니다.
"라우터는, 인터넷을 서로 연결 시켜주는 장비에요. 가령 허동수씨가 브라우저를 열어 웹 서버에 접속을 하면, HTTP 패킷이 웹 서버로 날아갈 텐데요. 그 패킷을 웹 서버라는 목적지 까지 계속 중계해 주는 것이 라우터가 하는 일입니다. 라우터는 패킷을 만날 때 마다 그 패킷에 적혀 있는 목적지 IP 주소를 보고, 다음에 어느 라우터로 보내야 하는지, 라우터가 아니라면 다음에 어떤 호스트로 보내야 하는지를 결정하죠. 그 덕에 우리가 인터넷을 통해 웹 서버에 접속할 수 있게 되는 겁니다."
"웹 서버가 보내는 웹 페이지도 그런 식으로 저에게 되돌아오는 거란 말씀이지요?"
"그렇습니다."
모두들 고개를 끄덕였습니다. 그러자 박팀장이 말을 이었습니다.
"아마 생소한 용어들이 많아서 걱정이 많이 되실 텐데, 미리부터 겁먹지 않으셔도 괜찮아요. 프로젝트를 준비하는 데 한 달 정도의 시간은 있으니까, 그 동안 공부하고 대비하면 될 겁니다."
하지만 모두들, 벌써부터 잔뜩 겁먹은 눈치였습니다. 저도 마찬가지였고요.
"이 프로젝트의 공식 명칭은, OLYMPUS입니다. Object layer for management of packet-support systems의 약자죠. 이 프로젝트를 주신 분들이 지은 명칭이라 저도 그 뜻이 정확하게 무언지는 모르는 상태입니다만, 곧 알게 될 겁니다. 능력이 워낙 출중하신 분들이라, 여러분들이 저보다 먼저 알게 되실 수도 있고요."
이번에는 고개를 끄덕이는 사람이 아무도 없었습니다. 회의실에는 침묵이 감돌았습니다.
"자. 그럼 회의는 이것으로 마치겠습니다. 오늘 저녁에 회식 있는 건 아시죠? 시간은 저녁 여섯 시 반, 장소는 회사 바로 앞 길건너 서울 회관입니다. 모두, 수고하셨습니다."
그날 저녁의 회식 자리는 조용했습니다. 술이 좀 들어가자 허동수를 중심으로 약간씩 목소리가 높아지기는 했습니다만, 전체적으로 조용한 자리였습니다. 대화는 거의 질문 형식이었습니다. 모두들 박팀장에게 프로젝트의 성격에 대해서 두세 가지 정도의 질문들을 했고, 박팀장은 아는 대로 성의껏 대답을 해 주었습니다. 하지만 간혹 대답이 막힐 때에는 남기수가 재빨리 끼어들어 구체적인 사항을 설명해 주었습니다. 네트워크 관련 기술에 대한 경험이 있는 사람인지라, 기술적인 사항에 확실히 밝았습니다.
"남기수씨."
"네, 팀장님."
"고마워요."
질문도 잦아들고, 두어 명씩 짝을 지어 개인적인 대화들을 나누는 분위기가 되자, 박팀장이 조용히 술잔을 기울이던 남기수에게 고개를 숙여 감사의 뜻을 표했습니다. 그는 황급히 손을 저었습니다.
"아뇨, 그런 말씀 안하셔도……."
"이번 프로젝트는 남기수씨께서 많이 도와주셔야 할 것 같아요. 저를 포함해서 많은 사람들이 이쪽에는 경험이 없어요. 이 프로젝트가 어떻게 우리 회사까지 넘어오게 되었는지 저도 자세히는 모르지만, 지금 회사 상황이 조금은 어렵고, 이 프로젝트가 어떻게 끝나느냐에 따라 우리 회사의 사업 분야도 조금은 달라질 것 같다는 이야기를 들었어요."
"네에..."
박팀장의 말에 그는 고개를 끄덕거렸습니다. '결국 또 똑같은 일을 하게 되는 건가?" 하는 듯한, 심드렁한 표정이었습니다.
"상황만 보더라도, 남기수씨를 뽑은 건 정말 시의 적절한 일이라고 해야겠죠?"
그 말을 하며 박팀장은 그에게 소주잔을 내밀었습니다. 그녀의 얼굴에는 숨길 수 없는 기쁨이 잔뜩 묻어 있었습니다. 그의 얼굴은 이미 술기운으로 불콰했습니다만, 그녀의 미소를 보는 그의 귀밑어름은 더욱 새빨갛게 물들어 가고 있었습니다.
"열심히 하겠습니다."
남기수는 그녀가 주는 잔을 받아 단숨에 들이켰습니다. 박팀장도 남기수의 잔을 받았습니다.
"그런데 대수씨는 원래 그렇게 말이 없으신 편인가요?"
그 때 갑자기 이선화가 잔뜩 꼬부라진 혀로 나에게 물었습니다. 느닷없는 질문이라 한참을 생각해야 했습니다. 내가 원래 말이 없는 인간이던가?
"네, 그런 것 같습니다. 제가 좀 재미없는 사람이라서요."
겸연쩍게 웃으면서 머리를 긁적이자, 바로 옆에 앉아 있던 허동수가 내 어깨를 툭 쳤습니다.
"에이, 원래부터 재미없는 사람이 어디 있습니꺼. 그런 건 다 택도 없는 소리고예. 자. 한잔 받으이소. 술을 안드시니까 그렇다 아입니꺼. 원래 술을 마시면 안되던 영어도 된다꼬 했습니더. 자. 한잔 하입시더예. 쭉 들이키이소. 쭉."
허동수는 완전히 술에 취해 있었습니다. 그러면서도 다른 사람들의 빈 잔 만큼은 꼬박꼬박 챙기고 있었습니다. 그 덕에, 그의 주변에 앉은 모든 사람들은 거의 떡이 되어 있었습니다. 저는 생각했습니다.
'나도 곧 저렇게 되겠군.'
그리고 그 예상은 전혀 빗나가지 않았습니다. 한 삼십분이나 더 흘렀을까? 저는 테이블에 머리를 처박고 눈만 끔뻑거리고 있었습니다. 허동수는 내 등을 두드리며 '괜찮으십니꺼?' 하고 몇 번 묻다가 다시 남은 사람들에게 잔을 돌렸고, 박팀장과 남기수는 계속 프로젝트에 관한 이야기를 하고 있었으며, 이선화와 김유식은 허동수의 잔을 받으면서 계속 뭔가로 토닥거리고 있었습니다. 나는 생각했습니다. 내가 몇 살이더라? 여기가 어디더라? 나는 무슨 일을 하는 사람이더라? 그런 뜬금없는 생각들이 머릿속을 맴돌다 픽, 하고 꺼져버릴 때 쯤 나는 정신을 잃었습니다.
눈을 뜨자, 익숙한 숙취의 고통이 사방에서 밀려왔습니다. 어지러웠고, 메스꺼웠고, 두통으로 머리가 저렸습니다. 내가 눈을 뜬 곳은 회사의 휴게실에 마련된 이층 침대였습니다.
커피를 뽑아 들고, 자리에 앉았습니다. 아침 일곱 시 반이었습니다. 컴퓨터를 켜고, 로그인을 하고, 메일을 간단히 확인한 다음 기분 좋게 식어있는 커피를 들이켰습니다. 머리가 조금 맑아지는 기분이었습니다. 하지만 온 몸에 배인 회식의 냄새는 지울 수가 없었습니다. 나는 서랍을 열어 미리 챙겨둔 팬티와 티셔츠, 바지를 꺼내 들고 회사 내 샤워실로 향했습니다.
샤워실이라고는 했습니다만, 사실은 세면대 중 한 곳에 샤워호스를 달아둔 것에 불과했습니다. 그래도 뜨거운 물이 나온다는 사실에 감사할 일이었습니다. 나는 머리를 감고, 몸을 씻고, 옷을 갈아입었습니다. 그리고는 다시 사무실로 돌아와 사무실 한편에 비치된 거울 앞에서 머리를 말리고 빗었습니다.
자리에 앉자, 술 냄새는 사라지고 커피향이 코 속 깊이 밀려왔습니다. 기분 같아선, 어떤 코드든 내 맘대로 주무를 수 있을 것 같았습니다. 하지만 두통이 문제였습니다. 다시 서랍을 뒤졌습니다. 타이레놀이 있었습니다. 한 알을 꺼내 커피를 물 삼아 삼키고, 눈을 감고 의자에 기댔습니다. 잠깐 쉬면 두통은 사라질 것이었습니다.
그런데 그렇게 눈을 감고 있자니, 이런 저런 생각들이 정해진 순서도 없이 밀려들기 시작했습니다. 나에게는 지난 일을 좀처럼 잊지 못하는 나쁜 버릇이 있습니다.
대학시절, 나는 그다지 넉넉하지 않은 형편의 고학생이었습니다. 김유식과 마찬가지로, 이런 저런 아르바이트를 하지 않으면 학생이라는 신분을 유지하기 힘들었던, 그런 가난하고 평범한 학생이었습니다. 그러다 보니 유혹이 많았습니다. 흔히 피라미드라고 불리는 다단계 사업도 그 중 하나였습니다.
흔히 다단계 사업을 경제적 종교라고 합니다. 종교와 다단계에는 굉장한 유사점이 있습니다. 독실한 종교 신자는 그 교리가 자신의 인생을 훨씬 나은 방향으로 돌려놓았다고 믿습니다. 다단계 참여자는 그 시스템 덕에 자신의 인생이 경제적으로 개선되었다고 믿습니다. 그리고 그 믿음의 힘은 굉장히 강력합니다.
자신의 인생이 너무나 달라졌고 좋아졌다고 믿기에, 기쁩니다. 만나면 누구에게나 그 이야기를 하지 않고는 못 배깁니다. 다른 사람들도 자기처럼 인생이 달라지는 경험을 하기를 원하기 때문입니다. 그래서 만나는 누구에게나 그 이야기를 합니다. 하지만 사람들의 반응은 차갑습니다. 본질적으로 그런 이야기들은 '가치관'에 대한 이야기이기 때문입니다. 사람들은 자신의 가치관이 이유 없이 침해받는 것을 싫어합니다.
모든 지식에는 비슷한 속성이 있습니다. 특히 실행지침(practice)에 가까운 지식은 더더욱 그렇습니다. 가령 누군가, 코드를 작성하기 전에 테스트를 먼저 작성하면 생산성이 훨씬 높아진다는 이야기를 했다고 합시다. 그리고 그 이야기를 굉장히 열성적으로 했다고 해 봅시다. 열성적으로 하면 할수록 그 경험을 성공적으로 나눌 확률은 떨어집니다. '종교 이야기'나 '다단계 이야기'와 같은 이유에서입니다.
유사 이래로, 어떤 믿음을 성공적으로 전파하는 가장 좋은 방법은 실제로 자신의 인생이 어떻게 변하였는지를 묵묵히 보여주는 것이었습니다. 마더 테레사가 그랬고, 간디가 그랬으며, 마틴 루터 킹이 그랬습니다. 하지만 그런 이치를 단돈 만원에 목마른 고학생이 알 리는 없는 노릇. 나는 다단계 때문에 많은 친구를 잃었습니다. 그 중 몇몇은 아직도 내 이야기가 나오면 고개를 절래 흔들 정도니까요.
그런 생각들이, 숙취로 지끈거리는 내 머릿속을 맴돌았습니다. 지금은 멀어진 친구들 얼굴이며, 자취방 한 구석에서 먼지를 뽀얗게 뒤집어 쓴 흉물이 되어 버린 전자요들……. 그런 것들이 악몽이 되어 나를 괴롭혔습니다.
"대수씨."
선잠에 가위눌려버린 나를 구원한 것은 박팀장이었습니다.
"대수씨. 괜찮아요?"
그 목소리에, 나는 힘겹게 눈을 뜰 수 있었습니다.
"아... 네. 괜찮습니다."
"어디 아픈 거 아니에요? 앓는 사람처럼 신음하던데... 식은땀까지 흘리고."
"아닙니다. 괜찮습니다."
애써 웃는 나에게 그녀는 특유의 미소를 지어 보이며 말했습니다.
"어제 술 너무 많이 마셨구나?"
"아 네 좀..."
멋적게 뒤통수를 긁자 그녀가 드링크 한 병을 꺼내어 건넸습니다.
"마셔요. 마시면 속이 좀 편해진대요."
그리고 그녀는 일일이 모두의 자리를 돌며 내게 건낸 것과 같은 드링크를 꺼내어 올려놓았습니다. 아침에 출근하면서 약국에 들른 모양이었습니다.
드링크를 목으로 넘기자 특유의 알싸한 향이 코를 찔렀습니다. 속이 개운해지는 느낌이었습니다. 오전에 회의가 잡혀 있었으니, 어떻게든 빨리 정신을 차려야 했습니다. 한 잔의 커피를 뽑아 들고 회의 시간에 쓸 자료를 점검하기 시작했습니다. 지끈거리던 머리도 서서히 풀려가고 있었고, 글자 한 자 한 자가 천천히 머릿속으로 밀려드는 것을 느낄 수 있었습니다.
OLYMPUS 프로젝트는 만만한 프로젝트는 아니었습니다. 처음 해 보는 프로젝트라 그랬고, 많은 수의 장비를 관리해야 하는 프로젝트라 더더욱 그랬습니다. 우리 팀만으로 감당할 수 있을 것 같아 보이진 않았습니다. 필요하다면 재하청을 주어야 할 일이 생길 것 같아 보였습니다.
프로젝트에 소요되는 기간도 짧았습니다. 길게 잡아 육 개월에서 팔 개월. 마지막 한 달은 '죽음의 행군'을 해야 할 지도 모르는 일이었습니다. 마감시간이 다가올수록 늘어가는 버그. 여기저기서 툭 툭 튀어나오는 문제점들. 이슈 추적 시스템에 산더미처럼 쌓여가는 문제점들... 그 모든 것이 불안했습니다. 그리고 그런 불안을 느끼는 것은 나만이 아니었습니다. 회의는 조용히 진행되었고, 모두들 어떻게 해야 할 지 감을 잡지 못하는 듯 보였습니다.
하지만 그 불안을 조용히 처리해 가는 두 사람이 있었습니다. 박팀장과 남기수, 그 두 사람은 마치 1:1로 팽팽하게 진행되는 투수전 끝에 마무리로 등장한 구세주 같아 보였습니다. 남기수가 말했습니다.
"이미 이 바닥에는 네트워크 관리 시스템(NMS: Network Management System) 개발로 잔뼈가 굵은 사람들이 많습니다. 저도 그런 분들을 좀 만나봤구요. 제가 개발했던 프로토콜은 그런 관리 시스템의 일부였습니다. 이런 관리 시스템이 하는 일은 대개 일정합니다. 중앙에는 네트워크를 관리하는 데 사용될 정책(Policy)이라는 것이 있습니다. 이 정책을 모든 장비에 일관되게 반영해야, 네트워크가 일사불란하게 움직이기 시작하죠. 문제는 네트워크 장비들은 이 정책을 이해 못한다는 점입니다. 정책은 주로 사람이 이해 가능한 언어에 가깝게 만들어지는데, 정작 장비는 그런 언어를 이해하지 못하죠. 장비가 이해하는 언어는 SNMP, TL1, 그도 아니면 CLI를 통해 전송되는 텍스트 스트림으로 이루어집니다. 간단히 말해서, 정책을 장비가 이해하는 언어로 변환해 전송하는 절차가 반드시 개입되어야 한다는 뜻이죠."
그러자 김유식이 물었습니다.
"그렇다면 우리가 만들어야 하는 시스템은 전형적인 3-tier 시스템에 가까와지지 않을까요?"
"적어도 정책, 그리고 그 정책을 변환할 변환 에이전트, 그리고 장비라는 세 부분을 그 세 계층에 대응시키겠다고 한다면 그렇게 말할 수도 있겠습니다. 하지만, 통상 이야기하는 3-tier 시스템과는 그 각각의 계층이 하는 일이 좀 다르지 않을까 싶네요."
모두들 고개를 끄덕거렸습니다. 그러자 박팀장이 나섰습니다.
"그런데 말이죠, 그런 실질적인 이야기를 하기 전에, 우리 프로젝트 명칭이 갖는 의미를 한 번 곱씹어 볼 필요가 있을 것 같아요. OLYMPUS는 Object layer for management of packet-support systems의 약자에요. 저는 이 단어들 중에서 Object Layer라는 그 두 단어가 굉장히 중요하다고 생각해요. 그런데 저로서는 그게 무슨 뜻인지 잘 모르겠어요. 여러분들 중에 감이 오는 분 계신가요?"
그러자 허동수가 입을 열었습니다.
"제 생각에는예..."
그리고 그는 잠깐 말을 멈추었습니다. 무언가 생각하는 표정이었습니다. 다시 입을 열자, 그의 입에서는 단어들이 속사포탄처럼 튀어나오기 시작했습니다.
"보통 Hybernate 같은 시스템을 보믄, 데이터베이스라는 굉장히 평면적인 구조를 객체로 대응시키는 기능을 제공하거든예. 그런걸 ORM이라고들 하지 않습니꺼. 실질적으로 보믄, 2차원 테이블 위에다 객체라는 뷰를 제공하는 것이거든예. 그걸 굳이 부른다면 레이어, 그러니까 계층이라고 부를 수 있지 않겠습니꺼? 같은 이치로, 네트워크 장비를 데이터베이스 테이블같이 본다면, 그 위에다가 객체라는 계층을 살짜기 얹을 수도 있지 않겠나, 이런 생각이 들거든예. 장비를 꼭 객체마냥 취급할 수 있는 레이어를 만들 수도 있지 않겠나, 이 말입니더. 잘은 모르겠지만예, 쪼끔 더 생각해보믄, 그 단어에 맞는 시스템을 만들 수도 있을 것 같고예."
그의 말이 정확히 무슨 말인지 알기는 힘들었지만, 그 골자만큼은 모두들 이해하는 눈치였습니다. 장비 위에 객체 계층을 얹는다. 그럼 프로그래밍은 그 객체 계층 위에서 진행될 것이고... 나름대로 매력적인 아이디어였습니다.
"그런데, 문제가 있습니다."
김유식이 손을 들더니 말했습니다.
"데이터베이스는 업체들 마다 조금씩 다른 문법을 제공하는 경우도 있지만, 본질적으로는 굉장히 유사하거든요. SQL을 통해 사용한다는 점도 그렇고, JDBC나 ODBC같은 표준적인 접근 방법을 제공한다는 점에 있어서도 그렇습니다. 과연 네트워크 장비도 그럴까요? 이 문제 때문에 며칠간 웹을 좀 뒤져 봤는데요. 네트워크 장비를 관리하는 데 사용되는 프로토콜은 SNMP, CLI, TL1 등 비교적 일정한 편입니다만, 그 장비로 가져오거나 설정해야 하는 정보에 이르면, 업체마다 천차 만별입니다. CLI를 통해 장비를 제어해야 하는 경우에는 각 회사들 마다 장비 설정 문법이 다 다르고 설정 결과로 출력되는 결과도 다 다른 형식이라는 것이 문제가 되구요. SNMP인 경우에도 사정은 크게 다르지 않습니다. SNMP는 가장 널리 사용되는 프로토콜인데도, 정작 장비마다 다른 정보 모델을 채용하고 있다는 것이 문제가 되죠."
그러자 모두들 다시 조용해졌습니다. 왜였을까요? 아마 이 일의 규모가 대체 얼마나 되는 것인지, 좀처럼 감을 잡을 수 없다는 것이 가장 큰 문제가 아니었을지. 그 때, 박팀장이 책상 앞으로 바짝 다가 앉으며 말했습니다.
"그럼, 우리에게 이 프로젝트를 던져준 당사자들을 만나봅시다."
"당사자요?" 남기수가 무심한 눈빛으로 물었습니다.
"네. 당사자. 요즘 유행대로 하자면 사용자라고 해야 하나요? 이 프로젝트를 우리에게 준 사람들, 그리고 이 프로젝트의 결과물을 사용할 사람들, 그리고 이 프로젝트를 우리 팀에 던진 결정권자들, 모두를 한 번 만나봅시다. 그러면 뭔가 영감이 떠오르겠죠. 뭔가 막힐 때 구글 신전에서 신탁을 구하는 것처럼요."
적절한 비유는 아니었습니다만, 모두들 웃으며 기꺼이 동의했습니다. 우리는 모두 장님이고 프로젝트는 코끼리 같았는데, 코끼리를 만져볼 방법이 없으니 코끼리가 어떻게 생겨먹었는지 이야기라도 들어야 했습니다.
회의를 마치고 박팀장은 여기저기 전화를 걸어 약속을 잡았습니다. 우선 프로젝트를 따 온 윗선 이야기를 들어보기로 했고, 프로젝트를 준 업체 실무자를 초청해 이틀간 집중적으로 회의를 진행하기로 했습니다. 최종적으로 만들어질 제품을 사용할 사람들을 만나는 것은, 업체 실무자와의 미팅 이후로 미루었습니다. 어차피 그 실무자를 통해야 했으니까요. 우선은 프로젝트의 성격을 정확히 파악하는 것이 중요했습니다.
코드는 한 줄도 짜지 않았는데, 모두들 코끼리를 등에 업고 걸어가는 사람 마냥 표정이 밝지 않았습니다. 벌써 마음 한편에 아직 만나보지도 못한 버그가 날아다니는 환영을 보고 있는 듯한 기분이었습니다.
그 다음주, 우리는 우리가 만들어야 할 코끼리의 모습을 알려줄 사람들과의 첫 모임을 가졌습니다. 프로젝트를 수주한 기술영업팀의 부장님과 과장님 두 분이었습니다. 팀장님 이하 모든 팀원도 모여 한 테이블에 마주 앉았습니다.
부장님이 먼저 말문을 열었습니다.
"그런데, 이렇게 모든 개발자분들이 참석할 필요가 있나요? 박팀장님하고 저하고 둘만 이야기해도 충분할 것 같은데..."
박팀장이 대답했습니다.
"개발자들 모두 이 프로젝트의 성격이나 해야 할 일에 대해 궁금해 하고 있거든요. 부장님과 과장님 두분께서 이 프로젝트 수주 과정을 주도하셨으니, 우리 궁금증을 충분히 풀어주실 수 있을 것 같아서 뵙자고 했습니다."
그러자 부장이 뇌까렸습니다.
"프로젝트 성격이라……."
그리고 잠시 회의실에는 정적이 흘렀습니다. 그동안 박팀장은 노트북을 열고 회의실 스크린에 파워포인트 발표 자료를 띄웠습니다. 우리 모두 본 적이 있는 자료였습니다.
"이 자료는 저희가 프로젝트를 담당하기로 결정되었을 때 전달받은 것인데요."
그때 부장이 손을 들어 말을 막았습니다.
"네. 저희가 드렸으니 저희도 내용은 알고 있습니다. 이 프로젝트가 여러분에게 아주 생소한 프로젝트가 되리라는 것도 예상했습니다. 하지만 이 프로젝트를 맡을 수밖에 없었던 여러 가지 사정이 있었습니다. 그런데, 그 사정은 여러분께 이 자리에서 일일이 말씀드릴 만한 성질의 것이 아닙니다. 그러니, 그런 부분에 대한 질문은 하지 않아주셨으면 좋겠습니다."
부장은 회의가 쓸데없이 길어지면 곤란하다는 듯, 딱 잘라 선을 그었습니다. 수긍이 가는 부분이었습니다. "왜"를 묻기 시작하면 이런 이야기 저런 이야기 한도 끝도 없이 나오는 일이 많았으니까요. 우리는 "무엇"을 만들어야 하는지를 물어야 했습니다. 박팀장은 웃으며 말을 계속했습니다.
"알겠습니다. 그런 부분에 대한 질문은 삼가하도록 할께요. 그럼 제가 가장 궁금했던 부분부터 여쭙겠습니다. 아시다시피 이 프로젝트의 영문 약자가 OLYMPUS인데요. 그 첫 두 글자가 Object-Layer입니다. 우리가 만들어야 하는 시스템이 네트워크 관리 시스템이라는 이야기를 들었는데, Object-Layer라는 말을 들으면 마치 우리가 만들어야 하는 무엇이 어떤 시스템의 한 계층에 불과하다는 느낌이 듭니다. 아마 우리 팀원들도 같은 느낌을 받고 있을 것 같은데요. 어떻습니까? 부장님."
부장의 턱에는 미처 깎을 시간이 없었던 듯, 수염이 까칠하게 자라 있었습니다. 부장은 그 까칠함을 음미라도 하듯 어루만지며 천천히 입을 열었습니다.
"팀장님 말씀이 아마 맞을 겁니다."
"'아마'라는 말씀은..."
"이 프로젝트의 명칭만 두고 보면, 분명히 우리가 만들어야 하는 시스템은 어떤 독립적인 시스템이라기보다는 시스템 플랫폼에 가깝습니다. 아니, 시스템을 만들 때 사용되는 환경에 가까울는지도 모르죠."
그러자 김유식이 나서 물었습니다.
"그럼 그 부분만 개발하면 된다는 말씀이신가요?"
그러자 과장이 나서 대답했습니다.
"그런데 문제는 시연입니다."
"시연이라뇨?"
"우리가 만든 환경이 관리 시스템 개발에 제대로 사용될 수 있다는 사실을 입증해 보여야 한다는 뜻이죠."
"그렇다면……."
"네. 환경도 만들고 그 위에서 운용되는 간단한 관리 시스템 정도를 만들어야 할 수도 있다는 이야기입니다."
박팀장이 머리를 긁었습니다. 뭔가 심히 난감해졌다는 표정이었습니다.
"그럼 다른 질문을 더 드려보죠. 대체 그 객체 계층이라는 것은 어떤 것이어야 하나요?"
"거기까지는 제가 말씀드릴 수 없습니다. 당연한 일이겠지만, 프로젝트를 주신 분들과 미팅을 하셔서 알아내야겠죠. 사실 너무 늦은 감이 있는데, 프로젝트를 주신 분들께서 킥오프(kick-off) 미팅을 하자는 연락을 주셨습니다. 미팅 일정은 내일 모레, 그러니까 수요일입니다. 오후 네 시부터 일곱 시까지 회의를 진행하고, 그런 다음에 회식을 하려고 합니다. 물론 저희도 참석하구요."
회식 생각을 하자 기분이 좋아졌다는 듯, 부장은 너털웃음을 웃었습니다. 그날의 회의는 그것으로 끝이었습니다. 사소한 질문 서너 가지가 더 오갔습니다만, 더 알아낼 수 있는 것도 없었고, 우리가 이미 알고 있는 것 보다 더 많은 대답을 들을 수도 없었습니다. 우리는 업무의 범위를 알아내었고, 해야 할 일이 단지 그 범위 안에만 머무르지 않는 다는 것을 깨달은 것만으로 만족해야 했습니다.
"수요일에 술을 좀 많이 먹어야 할지도 모르겠군요."
개발실로 향하는 복도를 걸으며 혼잣말인지 질문인지 모를 말을 내뱉자, 옆을 걷던 이선화가 물었습니다.
"왜요?"
"갑과 술자리를 할 때는, 보통 술자리가 길어지게 마련이죠. 앞으로의 일처리를 매끄럽게 한다는 핑계로 그분들께 좀 과한 대접을 해드려야 할 수도 있으니까……."
그러자 그녀는 무슨 뜻인지 알겠다는 표정으로 고개를 끄덕이고는 입을 다물었습니다.
다음 주, 우리는 프로젝트를 넘긴 당사자들과 예정대로 모임을 가졌습니다. 기술영업부의 부장과 과장, 그리고 우리 팀 전원이 참석한 자리였습니다. 프로젝트를 준 회사는 알고 보니 한 거대 기업의 SI 관련 자회사였습니다. 스스로를 프로젝트의 책임자라고 소개한 사람은 그 회사의 선임 연구원으로, 이름은 여운태였습니다.
"안녕하세요? 만나서 반갑습니다."
그의 머리는 거의 민머리에 가까울 정도로 짧았고, 짙은 갈색 뿔테 안경을 끼고 있었습니다. 짙은 색 눈썹 아래로 빛나는 그의 눈을 보고 있자니, 어쩐지 만만한 상대는 아니겠다는 느낌이 들었습니다. 하지만 그의 차림으로 보면, 도무지 회의를 하러 먼 길을 짚어 찾아온 사람 같지는 않았습니다. 흔한 서류 가방 하나 들고 있지 않았거든요. 회의실에 들어서서 인사말을 건네자마자 그가 맨 먼저 한 일은 모두에게 명함을 돌리고, 부장과 과장, 그리고 팀장과 인사를 나눈 것이었습니다.
"음... 화이트보드는 있는데 마커가 없네요?"
그리고는 냅다 화이트보드 앞으로 가서 서더니 마커를 찾았습니다. 김유식 주임이 바로 밖으로 튀어나가 마커를 가져왔고, 그는 유식에게 꾸벅 고개를 숙여 보이더니 바로 마커의 뚜껑을 열어 보드에 이렇게 휘갈겼습니다.
'OLYMPUS'
그리고는 모두에게 고개를 숙여 보이며 큰 소리로 이야기를 시작했습니다.
"다시 인사드리겠습니다. 여운태입니다. 흔한 성이 아니라서 아마 이름 기억하시기는 쉬우실 겁니다. 저는 S회사에서 네트워크 제어 솔루션 관련 개발 일을 맡고 있고요. 어쩌다 보니 이 프로젝트의 책임자 역할을 맡게 되었습니다. 물론 서류상 실제 책임자는 다른 분입니다만, 그 분은 워낙 맡고 계시는 과제가 많으셔서 이 프로젝트에 까지 신경을 쓰실 여력이 거의 없습니다. 해서, 아마 여러분은 앞으로도 저나, 저희 팀의 다른 실무자 분들과만 얼굴을 알고 지내시면 될 것 같습니다. 방금 모든 분들과 인사를 나누기는 했습니다만, 귀찮지 않으시다면 박팀장님께서 팀원 한분 한분씩 무슨 일을 하시는지 소개를 좀 해주시면 안 될까요?"
"귀찮긴요. 그럼 제 왼쪽부터 시작할게요. 이 분은 허동수씨구요, 하시는 일은……."
그렇게 시작된 소개는 대략 십분 가량 이어졌습니다. 그 동안 여 선임은 만면에 미소를 띠고 귀를 기울이고 있었습니다. 소개가 끝나자 그는 함께 온 자신의 동료 팀원들을 소개했습니다. 모두 네트워크 관리 시스템 개발 분야에서 잔뼈가 굵은 사람들이었습니다.
"그럼 바로 OLYMPUS 프로젝트에 대해 이야기를 하도록 하죠. 이 프로젝트는..."
그런데 갑자기 허동수가 끼어들었습니다.
"저 근데 죄송하지만 한 가지 여쭤봐도 되겠습니꺼?"
"음... 네. 말씀하세요."
"실례되는 질문일지는 모르겠는데예. 머리는 왜 그렇게 짧게 깎으신 겁니꺼?"
그러자 여 선임과 그의 동료들이 껄껄 웃었습니다.
"머리에 껌이 붙어서요."
여 선임의 대답을 들은 우리 팀원들도 웃을 수밖에 없었습니다. 덕분에 모두들 긴장을 푸는 것 같았습니다. 하지만 저는 긴장을 풀 수 없었습니다. 껌이 붙었다고 머리를 바짝 깎고 회사에 출근할 정도면, 뭔가 제멋대로인 사람일 거라는 생각이 들었거든요.
"자. 그러면 이제 OLYMPUS 프로젝트에 대해서 이야기를 드리도록 하겠습니다."
여 선임은 화이트보드에 그림을 그리기 시작했습니다.
"별다른 발표 자료 없이 이렇게 성의 없이 회의를 시작하게 된 점은 이해해주시기 바랍니다. 쓸데없이 긴 발표 자료를 만드느라 시간을 허비하는 걸 싫어하는 편이라서요. OLYMPUS 프로젝트의 결과물은 당연히 OLYMPUS라는 이름의 시스템, 또는 네트워크 관리 시스템 개발 플랫폼 형태를 갖게 됩니다. 이 시스템은 네트워크상에 어느 위치에 들어가게 되는가 하면……."
그가 그려 보여준 도해는 간단했습니다.
"OLYMPUS 시스템, 그러니까 OLYMPUS 플랫폼에 의해 만들어지는 시스템은 기본적으로 네트워크 장치(Network Device)들을 관리하는 시스템입니다. 이런 장치들로는 라우터(router), 스위치(switch) 등등이 있을 수 있습니다. 이 시스템은 장치 쪽으로 향하는 South-bound 인터페이스와, 상위 시스템으로 향하는 North-bound 인터페이스를 갖습니다. 그런데 OLYMPUS라는 약어의 OL, 그러니까 Object Layer는 North-bound 인터페이스를 어떻게 구현해야 하느냐 하는 문제와 관련이 있습니다."
그러자 박팀장이 물었습니다.
"어떤 문제죠?"
"통상적으로 네트워크 관리 시스템에서 North-bound 인터페이스라고 하면, 그 상위 시스템과의 연동을 위한 프로토콜 인터페이스를 말하는데요. DIAMETER 프로토콜이나 SNMP, RADIUS 같은 것들이 아마 그 후보가 될 수 있을 겁니다. 임의의 프로토콜을 사용할 수도 있구요. 그런데 OLYMPUS는 독립 시스템이라기보다는 시스템을 개발하기 위한 플랫폼적인 성격이 강하기 때문에, 여기서의 North-bound 인터페이스는 그런 프로토콜을 의미하지는 않습니다. 오히려, OLYMPUS 위에서 객체지향적으로 프로그래밍을 할 수 있도록 돕는, Object-Oriented API라고 보는 쪽이 적절할 것 같습니다."
그러자 김유식이 손을 들었습니다.
"네, 말씀하세요."
"그럼, 마치 RDBMS(관계형 데이터베이스)에 대한 객체지향적 API를 제공하는 iBatis와 같은 API 레이어를 맨 윗부분에 얹어두어야 한다는 이야기로 받아들여도 되겠습니까?"
"네. 그렇습니다."
여 선임의 대답에 모두들 안도하는 표정이었습니다. 어차피 요즘 대부분의 개발이 객체지향적으로 진행되고 있는데, 객체지향적으로 구현되는 시스템에 객체지향 API를 얹는다는 것은, 그다지 어려운 일로 보이지 않았거든요. 하지만 여 선임이 그 다음으로 풀어놓은 이야기는 조금 달랐습니다.
"그 부분은 뭐 상대적으로 간단해 보일 수도 있겠습니다만, South-bound 인터페이스에 이르면 이야기는 조금 달라집니다. 세상에는 굉장히 많은 네트워크 장비들이 있고, 그 각각은 관리 방법이 서로 다릅니다. SNMP만 있으면 관리 가능한 장비도 있고, CLI까지 동원해야 관리가 가능한 장비도 있습니다. 이런 장비간 격차를 어떻게 해소할 것이냐, 하는 것이 관건입니다."
그러자 남기수가 나섰습니다.
"그 문제는 저희도 이미 예상하고 있습니다. 그래서 그 문제를 어떻게 풀어야 할 지, 지금 연구중이구요."
박팀장은 다소 뜻밖이라는 표정이 되었습니다. 예상이야 했다 치지만, 솔루션을 고안해 내는 업무는 아직 누구에게도 할당된 적이 없었거든요. 물론 남기수가 적임자이리라는 데는 별다른 이견이 없을 것 같았지만 말입니다. 여 선임은 웃으면서 말을 이었습니다.
"연구 중이시라니 다행입니다. 남기수씨라고 하셨죠?"
"네. 맞습니다."
"예전에 몇 가지 통신 관련 프로토콜을 개발하신 적 있는 걸로 알고 있는데, 그 분 맞으시죠?"
남기수의 얼굴이 순간 붉어졌습니다. 자신의 이름을 기억해 주는 사람이 있을 줄은 몰랐다는 표정이었습니다.
"네, 맞습니다."
"예전에 일하시던 곳 사장님하고 같이 일을 했던 적이 있는데, 가끔 님 칭찬을 하시더군요."
"부끄럽습니다."
그러자 여 선임은 손을 내저으며 웃었습니다.
"에이... 부끄러우시긴요. 아무튼, 오늘 팀원 여러분들을 직접 뵙고 보니, 많이 안심이 됩니다. 이쪽에 별다른 경험이 없으시대서 걱정을 좀 했거든요. 그런데 이제는 한숨 돌려도 될 것 같군요."
모두의 표정이 밝아졌습니다. 어떤 의미의 칭찬이건 간에, 칭찬이라는 것은 기분 좋은 것이니까요. 하지만 저는 불안함을 떨쳐 버릴 수 없었습니다. 우리는 서로 모르는 사람들이었습니다. 서로가 어떤 능력을 가지고 있는지, 그리고 그 능력이 한데 모이면 어떤 결과가 빚어질지, 저로서는 도무지 예측할 수 없었습니다. 제가 불안했던 것은 그런 탓이었습니다. 우리는 불확실성으로 가득한 프로젝트에 내던져진, 불확실하기 짝이 없는 개인들이었습니다.
그 뒤로도 회의는 두어 시간 남짓 계속되었습니다. 지루할 정도로 많은 질문과 대답들이 이어졌고, 회의가 끝날 때쯤에는 모두들 지쳐 있었습니다. 허동수는 간혹 꾸벅 꾸벅 졸기도 했습니다. 이선화는 노트에 이상한 기호며 그림들을 잔뜩 휘갈겨 대고 있었고요.
그날 저녁, 예정된 회식이 열렸습니다. 여 선임은 목소리가 꽤 큰 사람이었습니다. 그는 스스럼없이 우리 팀원들과 어울렸고, 격식에 구애받지 않고 잔을 돌리고 담배를 피웠습니다. 술이 몇 순배 돌자, 그는 잔을 내려놓고 나에게 말을 건넸습니다.
"사실 저는 예전에는 용역 관리를 해 본 적이 없습니다."
"그럼 주로 어떤 일을 하셨나요?"
내 질문에 그는 잠깐 멍하니 허공을 쳐다보다가 대답했습니다.
"주로 개발을 했습니다."
"연구소 특성상 직접 개발을 하실 일은 없을 것 같은데..."
"어쩌다 보니 그렇게 되었습니다. 정상적인 상황이라면 논문을 훑어보고, 솔루션들을 비교해 보고, 대안을 찾는 일이 주된 업무가 되어야 했습니다만, 인력이 부족했죠. 그런 상황에서는 누군가 나서 남들이 하기 싫어하는 일을 떠맡아야 하죠. 아시겠습니다만, 저희 회사에는 개발에 전문적인 경험을 갖춘 사람이 드뭅니다. 그러니, 남들보다 조금만 더 경험이 있으면 전문가로 행세할 수 있죠."
"네에..."
내가 고개를 끄덕거리자 그는 쓸데없는 이야기를 하고 말았다는 표정으로 잔을 내밀었습니다.
"어쨌든, 앞으로 잘 부탁드립니다. 이번에 잘 해주셔야, 저도 회사에 낯이 서니까요."
"별말씀을……. 저희 팀장님을 비롯해서 다른 분들이 능력이 출중하시니까, 어떻게든 되지 않을까 싶습니다."
"팀장님께서 평판이 좋으시더군요. 저도 몇몇 분을 통해 전해 들었습니다. 해서 크게 걱정은 하지 않습니다. 다만 앞으로 제가 이런 저런 요구사항들을 들고 자주 귀찮게 해 드릴지 모르는데, 용역을 하시다 보면 자주 생기는 일이니 저를 너무 미워하지 않으셨으면 좋겠어요."
그가 껄껄 웃자 옆에 앉아 있던 박팀장이 웃으며 끼어들었습니다.
"너무 자주 바꾸시지만 않으면 괜찮아요."
요구사항이 바뀌는 것은 당연하다는 표정이었습니다. 그렇습니다. 요구사항이 너무 자주 바뀌면 갑과 을의 관계는 이내 서먹해지고 말죠. 개발자는 짜증을 내고, 용역 담당자는 '어쩔 수 없다'는 말을 반복하게 되고, 개발 팀장은 지쳐버리고 말죠. 이 바닥에 있는 모든 사람들은 요구사항으로부터 프로그램을 만들어 낼 수밖에 없다는 것을 잘 알면서도 요구사항에 질려 있었습니다. 프로젝트 마감시한이 닥쳐와도 일이 전혀 줄어들지 않는 것은, 바로 그것 때문이었으니까요.
술기운 탓이었는지, 요구사항에서 시작된 저의 상념은 어느새 올림푸스라는 이름의 신전에 닿아 있었습니다. 세상 모든 것들의 창조주이면서도 자신의 피조물이 빚어내는 갈등에서 전혀 자유롭지 못했던 그들의 모습은, 모든 것을 만들어 내야 하면서도 그 과정을 온전히 즐길 수는 없는 개발자들의 신세와 닮아 있었습니다. 그러니, OLYMPUS라는 프로젝트 이름이 의미심장하게 느껴진 것은 당연하다고 해야 할까요.
앉은 바닥이 너무 뜨거웠던 탓인지, 낯은 금세 벌겋게 달아올랐습니다. 찬바람이라도 쐬면 나아질까 싶어 유식과 담배를 피우러 음식점 밖으로 나섰지만, 한번 달아오른 얼굴은 쉬이 가라앉지 않았고 머릿속은 그리스 신화의 주인공들이 벌이는 분탕질로 어지러웠습니다. 문득 헤라클레스 생각이 났습니다. 에우리스테우스가 던진 열두 가지 업을 무슨 어린애 장난 마냥 간단하게 해치우고서도 비극적인 죽음을 맞아, 영웅이 아닌 신으로서 인생을 마감한 헤라클레스 말입니다.
솔직히 말해, 그의 그런 능력이 부러웠습니다. 뒷일이야 어찌 풀리건 간에, 당장 닥친 일을 키보드질 몇 번 만으로 해치울 수 있는 헤라클레스적인 능력이 나의 손끝에 강림하면 얼마나 좋을까? 이런 객쩍은 생각을 하고 있었던 것이죠. 알코올뿐 아니라 몽상에도 취해 있던 나를 깨운 것은 유식이었습니다.
"담배 피우다가 자는 사람은 첨보겠네. 정말 자요?"
"아니. 서서 자는 사람 봤어요?"
"글쎄. 지금 보고 있는 것 같은데."
"허 참 사람 싱겁기는..."
"그나저나. 박팀장님 안보이시네. 술 취해서 화장실이라도 가신 건가?"
창으로 안을 들여다보니 정말 박팀장이 없었습니다. 여 선임은 이 사람 저 사람 술을 부어주느라 정신이 없었고, 허동수는 평소와는 달리 일찍 취했는지 테이블에 코를 박고 엎어져 있었습니다. 이선화는 턱을 괴고 뭔가 생각에 빠져있는 표정이었고요. 남기수만 홀로 멀쩡했습니다.
"글쎄... 어딜 가셨나. 먼저 들어가요. 나는 한대 더 피우고 들어갈께."
"그래요 그럼. 그나저나 여 선임이라는 분. 대단하네. 혼자서 소주 세 병은 넘어 마신 것 같은데 취한 것 같지 않으니... 그럼 정신 좀 차리고 들어와요."
나는 잠깐 주변을 걷기로 마음을 먹었습니다. 걷다 보면 정신이 좀 맑아지지 않을까 싶어서였죠. 그런데 모퉁이를 막 돌아서니, 어디선가 익숙한 목소리가 들려 왔습니다.
"당신 정말 이럴 거야?"
박팀장이었습니다. 평소 때의 온화한 어조와는 달리, 그녀의 목소리에는 잔뜩 날이 서 있었습니다.
"내가 뭘 어쨌는데?"
뒤이어 들려온 것은 안이태 팀장의 목소리였습니다. 안 팀장이 대체 여기는 왜?
"왜 내 뒤를 이렇게 졸졸 따라 다니면서 귀찮게 하냐고!"
"몰라서 물어?"
"그래 모르겠다. 대체 왜 그러는데?"
반사적으로, 나는 몸을 웅크려 어둠 속으로 피했습니다. 두 사람 사이에 오고가는 대화는 내가 회사에서 알고 있던 박팀장과 안팀장의 대화가 아니었습니다. 숨죽여 들어야만 하는 사생활의 냄새가 짙게 배어 있는, 그런 말다툼이었습니다. 타인의 인생에 쓸데없는 관심을 갖고 사는 사람은 아니었습니다만, 나는 어느새 '이건 전부 술 탓이야'라는 말을 뇌까리며 귀를 쫑긋 세우고 그들의 이야기를 엿듣고 있었습니다.
"당신, 아직도 내가 당신 여자인 줄 착각하는 거 아냐?"
저는 소스라치게 놀랐습니다. 자기 여자인 줄 아느냐니? 그들이 나누는 내용은 내가 들어 알고 있는 사실과 달랐습니다. 그렇다면... 저는 짧은 시간에 어느새 결론을 내리고 있었습니다. 안팀장이 박팀장을 못살게 군 것, 프로젝트가 제대로 굴러가지 못하게 괴롭힌 것, 그리고 주차장에서 뺨을 맞은 것 등등은 단순한 시기심의 결과가 아니었습니다.
"물론 내 여자는 아니지."
"그런데 왜 이렇게 쫓아다니면서 괴롭히는 건데?"
갑자기 안팀장의 목소리가 뚝 끊겼습니다. 주변에서 흘러나오는 취객들의 목소리를 빼면, 사방은 그야말로 괴괴한 적막에 휩싸여 있었습니다. 순간, 그 자리에 더 있어서는 안되겠다는 생각이 들었습니다. 저는 발걸음을 돌려 다시 식당으로 향했습니다. 술이 확 깨는 것 같았습니다.
"어딜 갔다 와요?"
식당 밖에는, 남기수가 서 있었습니다. 그도 정신을 가다듬으려는 듯, 커피를 마시며 담배를 피우고 있었습니다.
"기수씨도 담배 피워요?"
내가 묻자 그는 멋적게 웃었습니다.
"끊었었는데 가끔 이렇게 술 마시면 피우죠. 그런데 어디 다녀 오세요?"
"아 그게..."
그 때 누군가 걸어오는 기척이 느껴졌습니다. 박팀장이었습니다. 남기수가 반색을 하며 말을 건넸습니다.
"팀장님. 어디 다녀오세요?"
"아……. 배가 좀 아파서요."
"여자 화장실은 저쪽이던데..."
그의 말에 박팀장의 얼굴에 당황한 기색이 어렸습니다. 하지만 이내 밝게 웃으며 말하더군요.
"술들은 많이 마셨어요? 기수씨도 많이 취한 것 같네?"
"아뇨... 뭐 그냥 조금... 여선임님이 술이 굉장히 세시네요. 같이 오신 분들은 별로 드시지 않는 것 같은데. 조금 있으면 2차 가자고 하실 것 같아요."
"2차라..."
순간 박팀장의 얼굴에 씁쓰레한 미소가 번졌습니다. 술자리가 길어지는 건 영 마뜩찮다는 표정이었습니다.
"자. 들어가죠. 손님을 모셔놓고 이렇게 너무 오래 밖에 있는 건 예의가 아니잖아요?"
박팀장의 말에 우리는 다시 식당으로 들어갔습니다. 아니나 다를까, 여 선임이 웃으며 말을 건넸습니다.
"다들 오셨네요? 지금 2차를 어디 갈까 이야기하던 중이었어요."
"어딜 가고 싶으신데요?"
박팀장이 묻자 여 선임이 대답했습니다.
"뭐... 가까운 노래방이나 갈까요?"
그러자 테이블에 코를 박고 있던 허동수가 고개를 살며시 들더니 물었습니다.
"어디 좋은 데 말씀이십니꺼?"
그러자 여 선임은 허동수를 물끄러미 쳐다보더니, 웃으면서 말했습니다.
"이 분 좀 취하셨네. 노래방 가서 술 좀 깨고 들어가자는 말이었어요. 괜찮으시죠?"
그러자 조용히 이야기를 나누며 술잔을 돌리던 그의 동료들이 말했습니다.
"여선임 노래방 까지 갈려구? 우리는 먼저 일어나야 할 것 같은데... 애기들이 기다려서 말이야."
그러자 여 선임이 웃으며 말했습니다.
"그럼 나머지는 제가 책임질께요. 두 분은 먼저 들어가시구요."
그리고 우리는 모두 자리에서 일어났습니다. 회식비는 여 선임이 어느새 치른 상태였습니다. 영업부장이 당황해 왜 그러셨냐고 여 선임을 가볍게 나무랐지만, 그는 당연한 것 아니냐고 말하고는 자켓을 걸치고 식당을 나섰습니다. 부장이나, 팀장이나 모두 조금 의외라는 표정들이었습니다.
하지만 허동수는 2차에 참석하지 못했습니다. 노래방들이 전부 지하에 있었던 데다, 그의 휠체어가 내려가기에는 너무 가팔랐던 탓이죠. 그는 이 말을 남기고는 쓸쓸히 사라졌습니다.
"그럴 줄 알았다니깐..."
그러자 여 선임이 말했습니다.
"아이구... 2차 장소를 잘 못 골랐군요."
"아뇨. 어차피 허동수씨 많이 취하셨는걸요."
내가 그렇게 말하자 여 선임은 그래도 미안한데... 하며 뒤통수를 긁적거렸습니다. 어쩐지, 그와 함께 하는 프로젝트는 이전과는 조금 다를 것 같다는 생각이 들었습니다.
그날의 노래방은 그야말로 광란의 도가니였습니다. 모두 마이크를 놓지 않으려 했고, 노래만 흘러나오면 몸을 흔들어 댔으니까요. 선화가 노래를 하면 유식이 랩을 했고, 남기수가 흐드러진 발라드로 분위기를 깰라 치면 여선임이 나서서 뽕짝으로 수습했습니다. 영업부장과 과장도 나온 배를 흔들어 가며 보조를 맞추었고요. 노래를 못하는 저는 그냥 탬버린이나 칠 밖에 다른 도리가 없었지만, 그래도 즐거운 자리였습니다.
하지만 그래도 단 한 사람, 모두가 노래방을 나설 때 까지 단 한 곡의 노래도 부르지 않은 사람이 있었습니다. 박팀장이었죠. 그녀는 두시 간 동안 내내 웃으며 박수로 장단을 맞추었지만, 한 번도 자리에서 일어나지 않았습니다. 선화가 그녀를 일으켜 세우려고 나섰지만, 그녀는 일어서지 않았습니다. 그저 컨디션이 조금 좋지 않다며 미소를 지을 뿐이었죠. 남기수는 그런 그녀를 가끔 걱정스러운 눈빛으로 바라보았습니다.
아무려나, 회식은 그렇게 마무리되었습니다. 노래방을 나선 모두는 조용히 집으로 향했습니다. 새벽 한시쯤인가, 술에 혀가 꼬부라진 허동수가 전화를 해서 '아직도 술 마시고 있는거냐'고 물은 것을 빼고는, 괜찮은 마무리였습니다. 물론 다음날 회의실에 모여앉은 사람들 가운데 한 두 명 정도는 그때까지도 불콰한 표정이긴 했지만요.
그리고 그때부터 쭈욱, 우리는 프로젝트의 방향을 잡고 개발 일정을 정하고 구체적인 개발 방법을 만들어 가는 일에 몰두했습니다. 한 번도 해 본 적이 없는 프로젝트라는 점이 걸리긴 했습니다만, 그렇다고 해서 손 놓고 누군가 완벽한 요구사항 목록을 던져주기를 기다릴 수는 없었습니다. 우리가 만들 시스템의 사용자가 누구며 그들이 무엇을 원할 것인지를 추정해야 했습니다. 그리고 그 결과를 놓고 갑과 토론을 해야만 했습니다.
"OLYMPUS의 사용자는 과연 어떤 사람들일까요?"
팀장이 질문을 던지자 제 머리 속에는 오만가지 생각들이 스쳐갔습니다.
"신전의 사용자는 신들이 아닐까요?"
뜬금없는 제 대답에 박팀장은 웃음을 터뜨렸습니다.
"그렇긴 해요. 가끔 사용자는 우리가 만들 시스템에 신적인 권능을 요구하기도 하죠. 그런 의미에서 보면 사용자는 모두 신들과 같다고 비유해도 무리는 아닐 것 같네요."
그 말에 남기수는 사뭇 진지한 표정으로 이렇게 대꾸했습니다.
"물론 그렇습니다만... 우선은 그들이 '어떤 신'들인지 범위는 좁혀 두어야겠죠."
램은 '솔라리스'라는 소설에서 세상에 대한 호기심으로 가득한, 마치 어린아이와 같은 신에 대해 언급한 적이 있습니다. 자신이 가지고 노는 존재들이 무엇인지 알기 위해 이런 저런 시도들을 하지만, 정작 그 결과로 장난감들이 어떻게 망가질 지에 대해서는 알지 못하고 관심도 없는 그런 신 말이에요. 우리가 모셔야 하는 신들이 그러하다면 과연 우리는 어떻게 대처해야 하는 걸까요?
"우선 우리 시스템이 플랫폼적인 성격을 가지고 있으니까, 개발자를 주요 타깃으로 보아야 할 것 같은데요. 플랫폼을 이용해서 네트워크 관리 시스템을 개발할 사람들 말입니다."
유식이 말했습니다. 그러자 팀장이 화이트보드에 그림을 그리기 시작했습니다.
"그러니까 여기 플랫폼이 있고... 그 위에 이렇게 개발자가 있다 이 말이군요."
팀장은 UML의 액터(actor) 기호를 그려 넣고는, 그 아래에 '개발자'라고 큼지막하게 적었습니다. 그 아래에는 우리가 만들 플랫폼의 경계가 사각형으로 그려져 있었습니다. 그 안을 채우는 것은, 우리가 할 일이었습니다. 그러자 남기수가 나섰습니다.
"그럼 롤 플레이(role-play)를 한번 해 보는 것은 어떨까요?"
"롤 플레이요?"
"가상의 개발자를 한 명 두고, 그 사람이 우리 시스템을 실제로 어떤 식으로 사용할 것이며 어떤 기능을 요구할 지 역할극을 한 번 해 보자는 것이죠."
그러자 허동수가 말했습니다.
"재미있겠네예."
그러자 남기수가 웃으며 대답했습니다.
"재미있을지는 저도 장담할 수 없습니다만... 적어도 그런 페르소나(Persona)를 만들어 놓고 이야기를 하다 보면, 우리가 상대할 사용자를 좀 더 잘 이해할 수 있을 것 같긴 합니다. 그런 의미에서, 그 사용자에게 이름을 붙여 보는 것은 어떨까요?"
"이름이요?"
박팀장이 물었습니다. 그러자 유식이 말했습니다.
"좋은 생각이네요. 계속 사용자 사용자 사용자 이렇게 부르는 것 보다는, 이름이 있으면 이야기하기 좀 더 편하겠죠. 어떤 이름이 좋을까요?"
모두들 이런 저런 이름들을 내 놓았습니다. 저도 하나를 제안했습니다.
"제우스가 어떨까요?"
"제우스요?"
"네. 그리스 로마 신화에 등장하는 신들의 수장이기도 하고, 가장 제멋대로인 신이기도 하죠. '사용자는 제멋대로다'라는 개발자 사이의 통념에 비추어 본다면 가장 잘 어울릴 이름일 것 같기도 합니다만...'
그 말에 모두들 너털웃음을 터뜨렸습니다.
"제우스라. 거창하긴 하지만 발음하기도 편하고, 괜찮은 이름이군요. 다른 분들 생각은 어떠세요?"
"좋습니다."
결국, 우리의 사용자는 제우스라는 이름을 갖게 되었습니다. 팀장은 화이트보드에 적인 '개발자'라는 단어를 지우고, 그 자리에 '제우스'를 큼지막하게 써 넣었습니다.
"자. 그럼 지금부터 제우스씨가 우리에게 무슨 이야기를 하는 지 들어보도록 하죠."
제우스씨는 그날 많은 말을 했습니다. 아니, 남기수씨가 말을 많이 했다고 해야 맞겠군요. 그날 제우스가 되어 사용자 행세를 한 사람은 남기수였습니다. 아무래도 네트워크 관리에 대해 아는 것이 많으니, 우리도 그가 제우스가 되는 편이 낫겠다고 생각했죠.
"저, 그러니까 제우스는 네트워크 관리 소프트웨어를 만드는 프로그래머입니다."
그가 심각한 표정으로 운을 떼자 여기저기서 쿡쿡대는 소리가 들렸습니다. 회의실 앞을 마치 키노트 스피치를 진행하는 스티브 잡스처럼 왔다 갔다 하는 그를 보고 있자니, 정말 웃지 않을 수가 없더군요.
"저는 가능하면 적은 노력으로 네트워크 관리 소프트웨어를 개발하고 싶어요. 모든 API가 Thread-safe했으면 좋겠고, 이미 짜 놓은 소스코드를 고치는 일 없이도 새로운 장비를 관리할 수 있도록 customization이 가능했으면 좋겠어요. 내가 알아야 하는 API가 많은 것은 원치 않구요. DBMS에 데이터를 저장하기 위한 API, 장비를 조작하기 위한 API, 모니터링 하기 위한 API, 뭐 그 정도만 있으면 충분했으면 좋겠어요."
그러자 허동수가 나직이 읊조렸습니다.
"아 바라는 게 너무 많아..."
다시 모두들 쿡쿡댔습니다. 하지만 그러거나 말거나, 우리의 제우스는 이야기를 계속했습니다.
"그리고 시스템이나 소프트웨어 일부가 죽어도, 남은 부분은 계속 동작할 수 있었으면 좋겠어요. 아예 다른 시스템으로 failover가 되면 더 좋고요. 그리고 가능하다면, Eclipse같은 IDE와 통합된 개발 환경이 지원되었으면 좋겠어요."
그러자 화이트보드 옆에 서 있던 박팀장이 테이블에 살짝 기대듯 걸터앉으며 물었습니다.
"제우스씨. 그 중에서 가장 중요하게 생각하는 것은 무엇인가요? 아니, 가장 먼저 개발되었으면 좋겠다고 생각하는 것은 무엇인가요?"
그러자 제우스는 잠깐 생각하더니 말했습니다.
"개발하는 데 사용할 Thread-safe한 API 들입니다."
"일단은 라이브러리 형태로만 제공되더라도 개발할 수 있다는 사실만 입증되면 괜찮다는 건가요?"
박팀장이 되묻자 제우스는 다시 생각하더니 대답했습니다.
"네, 그렇습니다."
그러자 박팀장이 웃으면서 모두를 향해 물었습니다.
"일단 제 질문은 여기까지. 우선 우리의 사용자가 무엇을 가장 중요하게 생각하는 지는 파악한 것 같군요. 물론 최종적으로 갑의 인증을 받은 사실은 아니지만 말이죠. 다른 분들은 질문 없으세요?"
그러자 회의 시작때 부터 졸고만 있던 이선화가 갑자기 손을 들더니 말했습니다.
"질문있습니다."
"네, 말씀하세요."
제우스가 웃으며 대답했습니다. 이선화는 뭔가 알쏭달쏭하다는 표정으로 물었습니다.
"제우스님은 나이가 몇살이세요?"
그러자 모두들 헉, 하는 표정으로 웃어댔습니다. 그러나 웃지 않는 사람이 한 명 있었으니, 바로 허동수였습니다.
"아, 잠깐만예. 웃을 일은 아니고 굉장히 좋은 질문 같은데요. 우리의 사용자가 어떤 인간인지를 아는 것은 굉장히 중요합니더. 그런게 파악되지 않고서는, 사실 이런 역할극이 별로 필요 없지 않겠습니꺼? 테스트를 할 때도 테스트를 하는 사람이 어떤 패턴으로 행동하는 지를 파악하는 것이 꽤 중요하거든예. 사용자의 요구를 상상하는 것이 의미있다는 것에는 동의하는데, 그 사람이 어떤 사람인지 구체적으로 그려놓지 않으면 그냥 요구사항을 나열하는 거하고 별반 차이가 없지 않느냐 하는 소리지예."
박팀장이 고개를 끄덕이며 말했습니다.
"허동수씨의 말에도 일리가 있네요. 하지만 그렇다고 제우스가 어떤 사람인지 너무 심층적으로 파들어가다가는 소설을 쓰게 될 것 같은데, 적당히 가정을 하면 어떨까요? 30대 초중반의 남성. 아침 열시부터 저녁 아홉시까지 일하다 파김치가 되어 퇴근하는 전형적인 벤처 프로그래머. 예상하지 않았던 일이 갑자기 닥치는 것을 싫어하는, 평범한 네트워크 프로그래머. 뭐 이정도로요. 네트워크 관리 프로토콜에 대한 이해는 어느 정도 되어 있다고 가정해야 겠군요."
그러자 남기수가 물었습니다.
"그런데 제가 네트워크 관리 프로토콜을 잘 모르면 어쩝니까?"
"네?"
"저, 그러니까 제우스가, 여러분들 만큼이나 네트워크 관리 프로토콜에 대해 잘 모른다면 어떻게 해야 하느냐 하는거죠. 그에 따라 API의 모양도 달라질 수 있습니다."
그러자 박팀장이 고개를 숙이고 턱에 손을 댄 채로 중얼거렸습니다.
"그러니까 제우스가 갖고 있는 도메인 지식이 어느 정도인지 우리로서는 알 수 없다는 건가..."
"그럴 수도 있겠네요."
유식이 고개를 끄덕거렸습니다. 옆자리에 앉아있던 선화도 동의한다는 듯 고개를 끄덕여 보였구요. 그러자 박팀장이 말했습니다.
"그럼 남기수씨 대신, 다른 분이 제우스 역할을 맡아서 역할극을 계속해 보도록 할까요?"
그러자 허동수가 물었습니다.
"왜 바꿀라고 그라시는데예?"
"아무래도, 제우스가 네트워크를 잘 모른다는 경우까지 따져보려면 남기수 씨 말고 다른 분들도 참여해보는 것이 옳지 않겠어요? 겸사겸사 브레인스토밍까지 할 수 있을지도 모르구요."
팀장의 말에 모두들 고개를 끄덕거렸습니다. 다음에 제우스를 맡은 사람은 저였습니다. 이름을 지었으니, 실제로 제우스가 되어 보는 것도 나쁠 것 같지 않았습니다. 저는 앞으로 나가, 제가 OLYMPUS에 기대하는 바를 이야기하기 시작했습니다. 저는 네트워크에 대해서 잘 모르는, UI 개발 경험이 전부인 프로그래머가 되어 입을 열었습니다.
"저는 가능한 한 모든 개발 API가 하는 일이 분명했으면 좋겠고, API 별로 기능 분담도 확실하게 되었으면 좋겠습니다. 클래스로 객체를 만들어 메시지를 보낸다는 식의 패턴 보다는, 웹 서비스 형태의 API가 되었으면 좋겠다는 거죠. 필요하면 API를 호출하고, 그러면 그것으로 끝나면 좋지 않을까요? 아무튼 그런 기분으로 코딩할 수 있었으면 좋겠습니다. 그래야 제시간에 퇴근해서 헬스장에도 들를 수 있을 것 같고요."
마지막 말에 모두들 키들거렸습니다. 그렇게, 모두들 역할극에 참여해서 자신이 기대하는 바를 말했습니다. 좀 변화를 주고 싶어서, 나중에는 한 명씩 돌아가면서 OLYMPUS 역할도 해 보았습니다. 그러자 좀 더 즐거워졌습니다. 가장 웃겼던 것은 허동수가 OLYMPUS 역할을 맡았을 때였습니다. '그런건 못해.' '이봐, 좀 더 생각한 다음에 이야기할 수는 없나?'는 식의 엉뚱한 대답을 해 댔기 때문입니다.
그렇게 모두들 즐겁게 회의를 진행했습니다. 자신이 개발자라는 사실을 잠시나마 잊는 듯한 모습들이었습니다. 아니, 좀 더 정확하게 말하자면 '개발자는 당연히 이래야한다'는 고정관념을 잠시나마 잊을 수 있어서 즐거워했다고 해야 하겠지요.
"자. 오늘 회의는 이것으로 마칩시다. 선화씨. 오늘 다과도 준비해주고 이것저것 챙겨줘서 고마웠어요. 모두 선화씨에게 수고했다고 한 마디씩 해 주세요."
팀장이 말했습니다.
"암브로시아를 먹고 넥타르를 마시는 기분이었어요."
유식이 말했습니다. 그러자 선화씨의 얼굴이 빨개졌습니다. 모두들 기분좋은 미소를 지어 보였습니다. 회의실을 나서는 저의 발걸음도 그다지 무겁지 않았습니다. 어쩐지, 모든 것이 다 잘 풀려 나갈 것 같은 기분이었습니다.
그 때, 제 어깨를 두드리는 손길이 있었습니다. 고개를 돌려보니 선화였습니다.
"오대리님."
"네. 말씀하세요."
"그런데 암브로시아가 뭐에요?"
암브로시아는 올림푸스 신전에 거하는 신들이 먹는 음식이었습니다. 신들이 불로장생하는 것도 암브로시아와 넥타르를 먹고 마신 덕분이라고 전해지죠. 제 설명을 듣는 선화의 눈빛은 사뭇 진지했습니다. 그러더니 말하더군요.
“유식씨가 가끔 뭐라고 말을 하면, 잘 못 알아듣겠어요. 창피해서 말은 못하겠는데, 제가 너무 무식한 사람처럼 느껴져요.”
“이렇게 생각해 보면 어떨까요? 선화씨가 무식한 게 아니라 유식이 너무 아는 게 많은 거라고.”
“그런 걸까요?”
선화의 얼굴에 화색이 돌았습니다. 저는 물었습니다.
“그런데, 저한테 묻는 건 창피하지 않아요?”
그 말에 선화의 얼굴은 순식간에 붉어졌습니다. 그리고는 한달음에 복도 끝으로 내달려 버리더군요. 그 순간 저는 알았습니다. 유식이 선화에게 어떤 의미인지를요. 하지만 시간은 저에게 그 의미를 숙고할 여유를 허락하지 않았습니다. 개발실로 돌아와 보니, 이사님이 회의를 소집해 두고 계셨습니다. 퇴근 시간이 십분 남짓 가까워 오고 있었습니다만, 도리 없었습니다. 우리는 다시 회의실에 모였습니다. 회의실에는 이사님과 부장님이 계셨고, 안팀장이 배석해 있었습니다.
‘안팀장이 여긴 왜 온 거지?’
모두가 자리에 앉자, 이사님이 무표정한 얼굴로 입을 열었습니다.
“갑자기 모이라고 해서 미안합니다. 퇴근시간이라는 건 잘 아는데, 아무래도 퇴근 전에 이야기를 해 두어야 내일부터 모든 일이 차질없이 진행될 것 같다는 생각이 들어서 말입니다.”
“괜찮습니다. 말씀하세요, 이사님.”
박팀장이 전혀 불쾌하지 않다는 표정으로 말하자, 이사님의 안색도 풀렸습니다. 하지만, 그 뒤에 그의 입에서 나온 말은 대신 우리 모두의 얼굴을 무표정하게 만들었습니다. 아니, 정확하게 말하자면 얼어붙게 만들었다고 해야겠군요.
“조직 개편과 인사이동이 있습니다. 오늘부터 OLYMPUS 프로젝트 팀의 팀장은 안팀장님이 맡습니다. 안팀장은 기존에 맡고 계시던 팀의 팀장도 겸직하게 될 겁니다.”
“그럼 저는…….”
박팀장이 굳은 얼굴로 묻자 그는 잠시 그녀의 얼굴을 미안하다는 표정으로 응시하더니, 입을 열었습니다.
“책임 연구원으로서 과제 책임자 역할을 계속 수행하게 될 겁니다. 하지만 업무 지휘 체계가 달라진 만큼, 앞으로 모든 보고와 결재는 안팀장을 거쳐야 합니다.”
“왜 갑자기 조직 개편 결정이 내려진 겁니꺼?”
허동수가 어이없다는 듯 물었습니다. 물론, 모두들 어이없어 하기는 마찬가지였죠.
“아마 대충은 짐작하시겠지만, 이 프로젝트는 정부에서 추진하는 과제와 관련이 있습니다. 프로젝트 결과에 따라서 앞으로 비슷한 과제를 계속 수주하게 될 가능성이 큰데, 가능하면 큰 프로젝트 수행 경험이 많고 정부 요구사항을 꼼꼼하게 챙길 수 있는 사람이 팀을 운영하는 것이 좋겠다는 판단을 내린 것이죠.”
안팀장은 고개를 숙인 채 ‘그래도 이건 아니지’라고 말하고 싶은 사람처럼 고개를 젓고 있었습니다. 하지만 그의 입가에 스쳐가는 미소는, 분명 이죽거림이었습니다. 이사님이 말을 마치자, 그는 기다렸다는 듯 고개를 들고는 말했습니다.
“미안합니다. 저도 박팀장님의 능력이라면 이정도 프로젝트는 충분히 감당하실 수 있을 거라고 누차 말씀 드렸습니다만, 회사 입장에서는 리스크가 크다고 판단했던 것 같습니다. 아무쪼록, 잘 부탁드립니다. 여러분들과 함께 이 프로젝트를 성공적으로 마칠 수 있도록, 최선을 다하겠습니다.”
그리고는 자리에서 일어나, 모두를 향해 고개를 숙여 인사를 했습니다. 엉겁결에, 모두들 따라 고개를 숙였습니다. 그리고 고개를 드는 순간, 모든 것이 느닷없이 현실이 되어 버렸습니다. 우리 앞에는 새로운 팀장이 있었고, 당혹감에 어쩔 줄 몰라 하는 예전 팀장이 있었고, 그리고 그 모든 결정을 당연하고 합리적인 것으로 생각하는 관리자들이 있었습니다.
모두들 무슨 생각을 하고 있었을까요? 짐을 챙겨 회사를 나서는 사람들의 표정은 눈에 띄게 무거워 보였습니다. 오직 남기수만이 예의 그 심드렁한 표정으로 자리에 앉아 코드를 만지작거릴 뿐이었죠. 기우이길 바랄 뿐이었습니다만, 저는 어쩐지 초나라와 한나라가 중국의 패권을 놓고 전쟁을 거듭하던 그 시절이 떠올랐습니다.
초패왕 항우가 한신을 중용하라는 대사부 범증의 간언을 뿌리치고 도읍 천도를 만류하는 신하들에게 참형을 서슴지 않자, 한신은 초나라의 운명이 그다지 길지 않을 것임을 예감하고는 한나라의 유방에게 몸을 의탁합니다. 그리고 초나라는 한신의 직감대로, 내홍과 독단에 갈팡질팡하다가 결국 항우의 자결로 역사에서 그 이름을 지우게 됩니다. 초나라를 결딴낸 데에는 한신의 지략이 한 몫을 단단히 했습니다만, 결국 모든 것을 파국으로 초래한 것은 자신의 힘을 과신한 항우의 독선이었습니다.
고작 소프트웨어 프로젝트 팀일 뿐인 우리 몇 사람의 앞날을 초와 한의 운명에 빗대어 본다는 것은 누가 보더라도 코웃음 칠 일이었습니다만, 한 번 가지를 치기 시작한 상념은 멈출 줄을 몰랐습니다.
"무슨 생각을 그렇게 하세요?”
저를 생각의 늪에서 건져 올린 것은 남기수였습니다. 제 어깨를 짚더니, 이렇게 말하더군요.
“너무 신경 쓰지 마세요. 이미 내려진 결정이잖습니까. 우리가 할 수 있는 일도 없고요. 기왕 이렇게 된 거, 프로젝트나 잘 마무리 할 밖에요.”
그의 말이 옳았습니다.
“그래요. 우리는 개발자일 뿐이니까.”
키보드에는 버튼이 많습니다. 누를 때 마다 자의식 가득한 소리를 내는 키보드는, 마치 당연하다는 듯 내 책상의 한 자리를 차지하고 있습니다. 가끔은 그 버튼들이 내는 소리들이, 비웃음처럼 들리기도 합니다. 키보드라면 응당 이래야 해, 라는 사람들의 믿음을 조롱하듯 말입니다. 오랜 세월동안 사용자 인터페이스는 혁신의 혁신을 거듭해 왔지만, 아직 누구도 마우스나 키보드 없이 컴퓨터로 무언가 심각한 일을 할 수 있을 거라곤 믿지 않습니다. 마우스의 버튼이 하나에서 세 개로, 그리고 마침내 사라지기까지 정말 오랜 세월이 걸렸습니다. 하지만 키보드의 버튼은, 좀처럼 사라질 것 같지 않습니다.
세상에는 사라져야만 의미 있는 것들이 있습니다. 하지만 그 의미라는 것도 애초에 그것이 존재하였기 때문에 있는 것이고 보면, 무언가를 창조하고 허무는 행위는 필연적으로 단계적이고 계량적일 수밖에는 없습니다. 하지만 마음이란 것은 물과 같아 때로 급하게 흘러가게 마련이고, 바뀌지 않는 무언가에 맞닥뜨리면 당황합니다. 나는 당황하고 있었고, 사라져야만 의미를 가질 무언가에 대해서 생각하고 있었습니다. 혹 그것이 나 자신의 허물이 아닌지 되짚으면서 말입니다.
남기수와 나는 개발실에 앉아 일은 제쳐두고 확률의 문제를 따져보기 시작했습니다. 농담으로 시작된 그 대화는 한 시간 동안 이어져 나름대로는 진지한 결론으로 마무리되었습니다. 개그맨으로 성공할 확률이나, 야구선수로 성공할 확률이나, 세일즈맨으로 성공할 확률이나, 프로그래머로 성공할 확률이나 따지고 보면 비슷하지 않겠느냐는 것이 그 결론이었습니다. 성공에 이르는 문은 좁고 문제없는 조직은 없으니 인생을 물타기한답시고 여기 저기 기웃거려 봐야 결국 똑같은 확률과 싸워야 되지 않겠느냐는 것이었죠.
하지만 대화 끝에 찾아온 침묵은, 조용히 웅변하고 있었습니다. 그런 생각마저도 결국은 이분법의 다른 모습이라는 것을요. 그렇다면 말입니다, 인생이 성공과 평범함의 두 가지 스펙트럼 사이에 오는 무엇이라면, 내가 해야 할 일은 과연 무엇이었을까요? 개발실로 돌아가면서 나는 다짐했습니다. 인생이 이분법의 변주로 만들어지는 음악이 아니라면, 그 음악 뒤에 깔리게 마련인 지루한 화음들을 견뎌 내는 것도 나의 의무이리라. 그리고 오직 견디고 버티는 것으로 그치지 않고, 나는 매일 매일 그 음악을 새롭게 가다듬으리라.
하지만 그런 장한 다짐을 비웃기라도 하듯, 내가 만든 코드는 조잡하기 짝이 없었습니다. 마치 이렇게 말하는 듯 했습니다.
사람이 없다 없다 하지만 아직까지는 일자리를 구하는 사람들이 일자리보다 더 많습니다. 그래서 면접은 중요합니다. 면접은 경력의 시발점이 되는 순간이니까요.
한가지 신기한 것은, 개발자들은 일반인들과는 좀 다른 방식으로 면접을 보고 있고, 아무도 그것을 이상하게 생각하지 않는다는 점입니다. 개발자들에게는 TOEIC 점수 같은 것이 중요하지 않으며, 영어 대신 '프로그래밍 언어'라는, 프로그래머들 사이에 통용되는 특별한 종류의 language만이 중요합니다.
이런 특별한 상황 덕분에, 어느 서점을 가도 '개발자가 면접에서 성공하는 법' 같은 책은 찾아볼 수가 없었습니다. 아직까지도 개발자는 '취업 희망자' 가운데 소수이니까요.
그런데 이런 책이 나왔습니다. 벌써 5판째이고, 꽤 인기 있는 책이 되었다는 소문입니다. 이 책의 목차를 훑어보시면 아시겠지만, 구글/마이크로소프트/애플 등등의 저명한 회사들에서는 어떻게 면접을 보는지, 어떤 식으로 옷을 입어야 하는지, 어떤 문제들이 출제될 가능성이 있는지 등등의 정보들이 좀 시시콜콜하다 싶을 정도로 담겨져 있습니다.
아래는 이 책의 목차입니다.
목차만 봐도 어떤 내용이 담겨있는지 감이 오실듯 싶군요. 더 자세한 설명은 드리지 않겠습니다. 이 책의 번역서가 인사이트 출판사에서 출간될 예정이라고 하니 관심있는 분들은 기대해 보셔도 좋을 듯 싶군요. :-)
무창포 비체팰리스에 가족여행을 다녀왔습니다. 작년에 감기 등등 여러가지 사정으로 다녀오지 못했고, 이번에도 가기 전까지 취소할까 말까 굉장히 고민을 많이 했습니다만, 가지말까? 하고 물었더니 애들이 너무 실망해서 결국 다녀오게 되었습니다.
무창포는 대천해수욕장에서 가깝고, 대전에서 차량으로 한시간 30분 정도면 도착할 수 있습니다. 비체팰리스는 무창포 바닷가 바로 앞에 위치한 콘도미니엄으로, 소형 워터파크, 사우나, 스파, 노래방 등등의 부대시설을 갖추고 있습니다.
비체팰리스 숙박 가족에게는 할인율이 적용되기 때문에, 대인 2 소인 2를 기준으로 65,000 정도면 스파를 이용할 수 있습니다. 스파 시설은 규모 면에서는 하, 수온 면에서는 상, 시설 관리 면에서는 중 정도의 점수를 줄 수 있겠습니다. 대전 인근의 다른 스파 처럼 뻑적지근한 물놀이를 즐길 수 있는 물놀이 위주 테마파크 (가령 테딘같은) 를 상상하시면 곤란합니다.
콘도에서 개콘 보는 중
비체 팰리스 방은 넓고 쾌적한 편이며, 잘 관리되고 있습니다. 한화 콘도미니엄보다는 낫고, 대명과는 비슷한 수준 정도로 생각하시면 되겠습니다.
그럼 다른건 다 생략하고 사진이나 보시겠습니다. 콘도미니엄 내부 사진은 1장 빼곤 없습니다. 물놀이 하러 갔다 와서 저녁 여덟시 반부터 곯아 떨어져 잠든 바람에... 다음날 바닷가에서 찍은 사진이 거의 답니다.
비체팰리스에서 바닷가로 통하는 입구에 있는 눈사람(?) 앞에서
무창포에 몇번 갔는데 대체 이 섬 이름이 뭔지는 모르겠음
갯벌탐험 1
갯벌탐험 2
갯벌탐험 3
갯벌탐험 4
갯벌탐험 5
갯벌탐험 6 - 조약돌 수집중
얼음 미끄럼 타기
놀이사진은 여기까지구요. 대충 한시간 정도 갯벌에 있다 보니까 배가고프다고 아우성이라서 아무데나 눈에 젤 먼저 보이는 횟집으로 들어갔는데, 4인 기준 모듬회 한접시 가격이 ㅎㄷㄷ - 머 좀 저렴한 일식집 왔다 생각하고 그냥 주문.
그런데 의외로 회 말고 다른 것 (스끼다시라고도.. ㅋㅋ) 도 잘 나와서 기분이 많이 나쁘지는 않았습니다. 모듬회 기준으로 4인 12만원이었구요. 예상 외의 출혈이라 2월 달 까지는 된장찌개만 끓어먹고 살기로 아이들과 다짐했습니다.
프로그래밍이라는 행위는 여러가지로 글쓰기와 유사합니다. 아무것도 없는 것에서 무언가를 만들어 내기 위해 글자를 쉼없이 타이핑 해 넣어야 한다는 행위적인 유사성 뿐 아니라, 그 결과가 팔려야 하고, 잘 팔리기 위해서는 많은 사람들의 리뷰와 교정을 거쳐야 하고, 최종적으로는 디자인을 덧입히는 패키징 과정을 거쳐야 한다는 점에서도 비슷합니다.
영작문 기술에 대해 심각하게 고민해 본 사람이라면 한 번쯤은 읽어보았을 책 가운데, The Elements of Style이라는 책이 있습니다. 이 책은 흔한 문법 오류를 바로 잡는 법부터 시작해서, 좋은 글을 쓰기 위해 지켜야 하는 규칙들도 이야기합니다.
이 책의 2장, Elementary Principles of Writing의 첫 절, "Choose a Suitable design and hold to it"을 인용해보겠습니다. (번역은 완전하지 못하며, 군데군데 오류가 있을 수 있습니다.)
A basic structural design underlies every kind of writing. Writers will in part follow this design, in part deviate from it, according to their skills, their needs, and the unexpected events that accompany the act of composition.
모든 종류의 글쓰기는 기본적인 구조 설계를 전제한다. 작가는 부분적으로는 이 설계를 따르기도 하고, 부분적으로는 자신의 기술과 필요, 그리고 작문 도중에 발생하는 예상치 못한 사건들 때문에 그 구조로부터 이탈하기도 한다.
Writing, to be effective, must follow closely the thoughts of the writer, but not necessarily in the order in which those thoughts occur. This calls for a scheme for a procedure.
효과적으로 글을 쓰려면 작가의 생각에 가깝게 따라가는 것이 좋겠지만, 그렇다고 생각이 떠오르는 순서를 그대로 따라야 한다는 것은 아니다. 그래서 절차적인 방법이 필요하다.
In some cases, the best design is no design, as with a love letter, which is simply an outpouring, or with a casual essay, which is ramble. But in most cases, planning must be a deliberate prelude to writing. The first principle of composition, therefore, is to foresee or determine the shape of what is to come and pursue that shape.
무설계가 최선의 설계인 경우도 있다. 연애편지처럼 흐르는대로 쏟아내거나, 격식을 차릴 필요 없는 에세이 같은 경우가 그에 해당한다. 하지만 대부분의 경우, 글쓰기 전에는 의식적으로 계획을 먼저 세워야 한다. 그러므로 글쓰기의 첫 번째 원칙은 최종 결과물의 형태를 예측하고 결정한 다음, 그 형태를 추구하는 것이다.
A sonnet is built on a fourteen-line frame, each line containing five feet. Hence, sonneteers know exactly where they are headed, although they may not know how to get there. Most forms of composition are less clearly defined, more flexible, but all have skeletons to which the writer will bring the flesh and the blood. The more clearly the writer perceives the shape, the better are the changes of success.
어떤 구조를 따르고, 최종 결과물의 형태를 예측한 다음 그 형태를 빚어낼 수 있도록 노력해야 한다는 것은, 프로그램의 구조 설계와 그에 필요한 요구사항들을 연상시킵니다.
자신의 기술과 필요에 따라 처음에 정했던 구조를 이탈하기도 한다는 대목은, 코드를 리팩터링하다보면 초기 구조에서 점차로 이탈하여 새로운 구조가 만들어지기도 하는 것과 비슷합니다.
보통 글쓰기를 예술적 창조의 영역에 놓습니다. 그렇다면 프로그래밍은 같은 영역에 둘 수 있을까요?
프로그래밍 결과로 만들어지는 코드는 그 자체로 음미할 대상이 아니라는 점에서, 작문과 같은 영역에 놓을 수는 없겠습니다. 우리는 소스 코드를 음미하는 것이 아니라, 결국 최종적으로 만들어진 바이너리를 평가하게 되죠.
하지만 우리가 글쓰기를 하면서 자기 성찰에 따르는 즐거움을 누리듯, 프로그래밍을 하면서도 같은 기쁨을 느끼곤 한다는 점을 염두에 둔다면, 적어도 프로그래밍을 사적인 예술의 영역에 놓을 수도 있겠습니다. 예술은 기본적으로 즐거움에 관한 것이니까요.
그러니, 데드라인이 가까와 올 때 까지는 우리 모두, 스스로를 예술가라고 생각하도록 합시다. :-)
이전 글에도 썼던 적이 있습니다. "micro-invention이 macro-invention으로 이어진다." 이 말은 작은 개선들이 어떻게 큰 개선으로 이어지고, 그것이 어떻게 혁신으로 이어지는 지를 이야기합니다. ([Thoughts] - 스티브 잡스를 따라하면 난감해지는 이유) 우리에게 창조성의 자산이 중요한 이유는, 그것이 micro-invention으로 이어지는 씨앗이 되기 때문입니다.
우리 주변을 살펴보면, 작은 개선들을 꾸준히 실천하여 삶의 개선, 그리고 우리 주변의 환경을 개선하는 사람들이 있습니다. 그런 개선이 지속적으로 이어져 뭔가로 끊임없이 이어질 수 있도록 하는 사람들을 우리는 달인이라고 부릅니다.
IT 업계에 부족한 풍토 중 하나는, 이런 달인을 발견하고 대접하는 태도입니다. 달인이 이룬 성취를 온전히 대접하고, 거기로부터 뭔가를 배우려는 교훈이 자산으로 만들어지지 않으면, 우리는 결코 뭔가를 배울 수 없다고 저는 생각합니다. 십년 이상을 한 가지 기술에 매진한 사람을 느닷없이 관리자로 '전진배치' 시키거나 하는 풍토는, 달인을 대접하는 일에 이 사회가 얼마나 서투른가를 단적으로 보여줍니다.
그래서 저는 우리 주변의 달인을 찾고, 그런 달인을 소개하는 일에 블로그의 한 지면을 할애할까 합니다. 오늘은 그 첫번째 시간입니다. 오늘 소개해 드릴 분은, 인터넷 자전거 동호회에서 "새다리"라는 필명으로 알려진 분입니다.
새다리님은 굳이 '달인'으로 소개되는 것을 사양하셨지만, 이 분이 아마추어로서 자전거, 수영, 그림, 오디오등을 대하는 자세에는 범상치 않은 구석이 있습니다. 뭔가 부족한 것을 발견하고 그것을 끊임없이 개선하는 태도에는, 분명 달인의 그것으로 바라볼 수 있는 무언가가 있습니다. 제가 이 분의 생활 태도에서 뭔가를 배울 수 있었듯이, 여러분도 그러하기를 기대합니다.
그래서 오늘, 새다리님과의 서면 인터뷰 결과를 싣습니다. 중간 중간에, 여러분의 이해를 돕기 위해 새다리님 블로그에서 가져온 자료를 같이 싣겠습니다. 여러분들도, 실생활에서 micro-invention을 실행할 수 있는 방법을, 이 분을 통해서 배울 수 있기를 바랍니다.
- - - [인터뷰 전문]
Q: 인터넷에서는 새다리라는 필명을 사용하고 계시고, 자출사 관련 동호회들에서는 이미 그 필명으로 꽤 유명하신데요. 특히 저렴한 생활형 로드바이크를 타시는 분들에게 새다리님 블로그는 한 번은 거쳐가야 하는 성지처럼 되어 있지요. 새다리라는 필명을 선택하신 동기가 있으신가요?
원래 제가 오래도록 (하이텔 시절부터) 사용하던 닉이 있으나 몇분야에서 나름 알려져서 사생활에 방해 (잦은 질문, 어떤 책임감 등)를 받는 경우가 있었습니다.
그래서 좀 벗어나고 싶었는데, 자전거라는 취미로 카페 활동을 하면서 새다리라는 새로운 닉을 사용하기 시작했습니다.
제 다리가 정말로 새다리처럼 가냘프기도 하고, 자전거를 잘 타는 것과는 역설적인 모습이기에 재미도 있어서 붙이게 되었습니다.
Q: 새다리님께서 블로그에 올리신 글들을 보면, 지속적으로 뭔가를 고민하고 개선하는 동력이 엿보입니다. 이런 능력은 스티브 잡스처럼 어떤 분야에서 성공한 사람들에게서 자주 발견되는 것이기도 한데요. 이런 동력이 자신에게 있다는 것을 느낀 것이 언제부터였나요? 그리고 그런 동력이 선천적으로 자신에게 있던 것이었다 느끼시는지, 아니면 후천적으로 개발된 것이라 느끼시는지? 후천적으로 개발된 것이라 본다면, 어떤 계기로 그런 자질을 본격적으로 개발하기 시작하셨나요?
성장 환경이 영향을 주었을수도 있지만 어느 정도는 타고난 캐릭터라고 생각이 듭니다.
그러한 성향이 있음을 스스로 느낀 것은 30대에 헤드폰앰프 자작에 빠졌을 때 부터지만 돌이켜보면 학창시절부터 기질은 가지고 있었던 것 같습니다.
새다리님께서 자작한 오디오 헤드폰 앰프들.
고1때 팝송에 빠져서 중하위권의 성적을 받아 부모님께 라디오 등의 기기를 빼앗기고 연금생활(?)을 할 때도 책상 위 조명 스탠드의 갓 안에다가 소형 스피커를 설치하고 발로 밟을 수 있는 스위치를 바닥에 놓고서는 공부하는 척하면서 음악을 듣기도 했습니다.
또한 대학원 시절 컴퓨터가 취미가 되었을 때도 남들과는 다른 방식으로 짧고 빠르게 계산되도록 계속 프로그램을 개선하면서 이러한 방면에도 소질이 있음을 발견했습니다.
지금도 단순한 공구나 뻔하게 쓰이는 칫솔 또는 면도기 마저도 끊임없이 진화하는 것이 무척 경이롭다고 느낍니다.
복잡한 기구를 고안하는 것 보다는 오히려 일상에서 그냥 지나치는 것에서 변화를 끌어내는 것에 더 매력을 느끼고 있습니다.
7단 후리휠을 분해한 후 싱글기어로
한편 나름 다큐멘터리 매니아라고 자부하는데, 처음에는 생명이나 지구, 우주와 같은 자연을 다룬 것이 재미있었지만 요즈음은 인간 활동이나 창의성을 다룬 다큐멘터리가 더욱 흥미롭습니다.
Q: 자전거, 오디오 등 취미로 하시는 활동들이 (취미의 수준은 이미 한참 뛰어 넘으신 것으로 보입니다만) 꽤 많으셨는데요. 자전거를 시작하신 동기는 블로그에 올려져 있으니 저도 알고 있습니다만, 오디오를 취미로 삼으신 계기는 무엇인가요? 특히, 오디오 앰프 등의 자작을 시작하신 동기는 어떤 것이었나요? 그리고 자작을 시작하시면서 가장 주안점을 두신 부분이 있다면? (소형화나 가격이 주안점 중 하나가 아니었을까라고 저는 생각하고 있습니다만 ^^)
지금까지 여러 취미생활을 했지만 일반적인 수준을 넘어서 몰두했던 취미로는 음악감상, 헤드폰앰프 자작, 자전거 등인 것 같습니다.
헤드폰앰프 자작은, 워낙 음악 듣는 것을 좋아했었는데 대학원 다닐때 연구실에서 헤드폰으로 듣는 중, 전용 앰프를 사용하면 더욱 좋다는 얘기에, 당시 국내에선 헤드폰 전용 앰프를 구하기 어려웠기 때문에 극히 초보적인 것부터 만들기 시작하다가 완전히 매료되었습니다.
특히 저는 기계공학을 전공한 사람이라 전기전자는 옴의 법칙 정도밖에 알지 못하던 상태였는데, 새로운 부분을 배운다는 즐거움과 함께, 세상에 단 하나뿐인 작품(자작 앰프에선 그렇게 부릅니다.^^)을 만든다는 것이 너무나 특별했습니다.
또한 전문 지식이 깊지 않아도 기본 개념을 확실히 잡고 직관을 가지고 있다면 오히려 특정 분야에선 선구자가 될수도 있는 것 같습니다.
하지만 무엇보다도 워낙 만드는 것을 좋아했고, 선천적으로 가지고 있던 손재주를 마음껏 발휘할 수 있어서 빠져들게 되었습니다.
게다가 보기좋게 정리하고 꼼꼼히 기록하는 성격 때문에 같은 취미를 가진 사람들을 끌어 모으는데 큰 역할을 했습니다.
결국 140여개가 넘는 헤드폰 앰프들을 자작했고, 몇몇 앰프나 전자회로에 대한 새로운 아이디어도 내어 이 분야에서는 많이 알려져 있기에 자부심도 느낍니다.
새다리님의 BUF634 buffered amp
현재는 바쁜 월급장이 생활에 결혼 이후에 아이들 때문에 개인 방도 없는 상태이기 때문에 자작과 같은 취미를 못하고 있지만 나중에 개인 작업실을 하나 갖는 것이 꿈입니다.
한편, 스스로 깨우치거나 창의성을 발휘하는 것에서의 즐거움이 크다보니 널리 알려진 정보나 흔한 방법보다는 새로운 것을 찾는 편입니다.
또한, 하나를 성취하기 위해 오랜기간 모든 공을 쌓기 보다는 바로 결과물을 얻을 수 있는 다수의 시도를 더욱 좋아하는 편이라 저렴하고 작은 것을 다루는 것이 더 편했습니다.
그러다 보니 제가 시도한 많은 작업들을 다른 사람들도 쉽게 경험할 수 있기에 좋았습니다.
Q: 새다리님께서 취미로 하고 계신 활동들의 경우, 한계가 느껴지면 어떤 식으로 극복하시나요? 수영에 관해서라면 강습을 받아서 한계를 극복하셨던 것으로 보입니다만. 그림이나 오디오, 자전거 분야에 대해서는 어떠셨나요?
취미라는 것이 목표를 정해서 하는 경우도 있고, 하다보니 현재보다 좀더 상위의 목표가 생겨서 단계적으로 하는 경우도 있고, 그냥 취미 자체를 즐기는 경우도 있는 것 같습니다.
수영의 경우가 목표 (철인3종)를 정해서 하는 것이고, 마라톤은 원래 목표가 아니었는데 10 km를 어떤 기회에 뛰고 보니, 하프도 뛸수 있게 되고, 결국 풀코스까지 자연스럽게 가게 되었습니다.
결국 지속적으로 즐기다보면 대단한 목표를 정하지 않아도 어느 순간 그곳에 있는 것 같습니다.
쉼없이 2.5km 완주한 뒤의 새다리님 포스팅
자전거(업힐이나 라이딩 등)도 마찬가지로, 엄청난 것 보다는 지금 수준보다 한단계 높은 수준을 시도하는 것 자체가 극복이 될 수 있다고 봅니다.
즉, 목표를 정하고 미리 준비하는 방법도 있지만 일단 시도해 보는 것이 목표 달성에 가장 효과적이었습니다.
Q: 새다리님 블로그에서 대학 다니실 때 작성하셨던 학습 노트를 봤습니다. 그런 노트를 작성하게 된 계기가 있으셨나요? 대학 이전에도 그렇게 모든걸 깔끔하게 잘 정리하는 성격이셨는지? 노트를 잘 정리하게 되면서, 새다리님의 대학 생활을 비롯한 인생의 다른 부분이 긍정적인 영향을 받았나요? 받으셨다면, 어떤 것들이 긍정적이었나요?
새다리님의 학습 노트 (부분)
제가 타고난 재능이 있다면 미술입니다만, 아쉽게도 형편상 부모님이 그런 재능을 키워주시지 못했고 예전엔 미술로는 먹고살기 고달펐기 때문에 따로 배운 적 없이 공책에 캐리커처나 끄적거리는 정도였습니다.
그러다가 내게는 매우 어려운 도전이었던, 대학원 공부를 준비하다가 학습내용의 정리가 필요했고, 보기 좋으면 나중에 머리에도 잘 들어올 것이라 생각되어 한 것이 오히려 미술에 대한 자아실현 수준으로 하게 되었습니다.
물론 내가 잘 정리해 놓으면 후배들도 많이 볼 것이라는 생각도 작용했습니다.
결과적으로 이 정리노트는 매우 유명해져서 학과에서 전설이 되었고, 제본이 잦다보니 나중엔 아예 학교앞 복사가게에 맡겨서 몇년간 상시 구입이 가능할 정도가 되었습니다.
타대학까지 유명해져서 와서 사가기도 했지요.
20년이 넘었지만 아직도 그때의 제 서브노트를 회사에 두고 있다는 얘기도 종종 듣습니다.
이런 정리 습관은 장기간 목표의 공부엔 도움이 됩니다.
그래서 나중에 기술사 자격 시험공부를 할 때도 제대로 정리를 하여 자격 취득후엔 제가 정리한 내용으로 기술사 수험서를 내기 까지 했습니다.
결국 제 인생의 경력에 중요한 획을 긋는 결과도 얻은 셈입니다.
하지만 정리 습관이 제 생활 전부에 해당되는 것이 아니고 상당히 편향되어 있습니다.
지금도 저희 직장에서 가장 지저분하고 복잡한 책상이 제 자리입니다.
Q: 새다리님 블로그에서 자전거 관련 수치들을 정리해두신 엑셀 파일을 봤는데요. 뭔가 바뀔 때 마다 손쉽게 그 영향을 가늠해 볼 수 있도록 하는 구성이 인상적이었습니다. 원래 그런 식으로 정량화하고 측정하는 것을 좋아하는 편이셨는지? 아니라면, 어떤 동기로 그런 작업을 시작하게 된 것인지요? 일상 생활에도 그런 깨달음의 결과물들을 적용해보고 개선해 나가는 걸 즐기는 편이신지요?
새다리님의 속도 분석 액셀 프로그램
컴퓨터도 제가 거쳐온 중요 취미이자, 거기에 빠져서 박사과정에 올라가지 못했을 정도였기 때문에 (박사학위는 중년이 되어서 받았습니다.) 정확성과 반복성이 필요한 경우 프로그래밍이 몸에 배어 있습니다.
다만, DOS시절에 프로그래밍에 심취해 있다가 윈도우 환경으로 바뀌면서 새로 배우느니 엑셀로 대부분의 작업이 그냥 가능함을 알고는 직접 코딩은 접게 되었습니다.
(컴퓨터 역사상 가장 위대한 소프트웨어로 MS-Excel을 꼽고 싶습니다.)
하여간 타고난 Engineer 체질로 인해서 정량화 분석 및 비교하는 것이 습관이 되어 있습니다.
게다가 그것 자체가 창의성을 발휘할 수 있는 창작물이 되니까 더욱 매력이 있습니다.
Q: 새다리님께서 직업으로 하시는 일을 간단히 소개해주실 수 있으시겠는지요?
제 세부전공은 기계공학과의 열전달 분야인데, 현재 기업체 연구소에 다니면서 냉동공조쪽 분야의 제품을 개발하고 있습니다.
첫 직장을 다니다가 그만두고 다시 공부를 했으며 박사학위 취득후 대전에서 연구원 생활을 좀 하다가 지금의 회사에 다니고 있는데 내성적이고 보수적인 성격이지만 본의 아니게 여러 기업체나 연구소를 경험하였습니다.
Q: 저 같은 경우에는 취미로 자전거를 만지작거리기도 하고, 글을 쓰기도 합니다. 사진을 찍기도 하고요. 그 덕에 제 인생의 많은 부분이 달라졌다고 생각합니다. 새다리님의 경우, ‘아, 내가 취미로 했던 일들 덕에 내 인생이 이렇게 달라졌구나!’라는 것을 깨달은 결정적인 순간이 있으셨나요? 있으셨다면, 언제 어떻게 깨닫게 되셨나요?
저 역시 취미생활에 많은 시간을 투자했기 때문에 제 인생에도 크게 좌우 했다고 봅니다.
특히 매사에 자신감이 생기고 예전에는 상상하기 힘들정도로 활동적으로 성격이 바뀌었습니다.
물론 취미생활을 하지 않았다고 해서 그 시간을 허송세월 했을리도 없기 때문에 좋다 나쁘다 단언하긴 어렵습니다.
하지만 취미생활은 직업에서 필요한 것과는 다른 경험과 지식이기 때문에 뜻하지 않게 시너지를 가지고 오는 경우가 있음을 체험했습니다.
대학원 과정에서 결정적인 문제를 해결한 적이 있는데, 당시에 무척 도전적인 실험장치를 제작해야 하는데 앰프 자작에서 이용되는 아이디어와 스킬을 적용해서 성공을 했고 아주 좋은 성과를 내었습니다.
Q: 직업으로 하시는 일에도, 취미로 하시는 일과 같은 태도를 유지하시는 편인가요? 그렇다면, 취미로 하는 일들이 일에도 긍정적인 영향을 미치고 있다 느끼시나요? 그렇다면, 어떤 영향인가요?
이 질문의 답변은 어려워서 생략하고 싶습니다.
아. 현재 회사에서는 고전하고 있습니다. ㅠ.ㅠ
Q: 직업으로 하시는 일의 경우, 한계가 느껴지면 어떤 식으로 극복하시나요?
과거의 비슷했던 어려움들을 생각해 봅니다.
대부분 너무 걱정할 필요없이 잘 해결되어 지나 갔었기 때문에 긍정적으로 생각합니다.
특히 너무 한가지를 오래 고민하는 것보다, 분위기를 전환하면서 자주 생각해 보는 것이 문제 해결 아이디어가 잘 나오는 것 같습니다.
Q: 인생의 좌우명으로 삼고 계신 것이 있다면 간단히 소개 부탁드립니다.
감동을 주는 사람이 되자.
이것이 제 오래된 좌우명입니다.
하지만 살면서 보니까 결국 내가 스스로에게 감동하면 다른 사람에게도 감동이 되는 것 같습니다.
Q: 취미로나 혹은 직업적으로, 어떤 분야에서 일가를 이루기 위해서는 함께 생활하는 가족들의 이해와 도움이 절실할 때가 많은데요. 새다리님께서는 어떻게 이해와 협조를 구하셨나요? 새다리님께서 뭔가를 성취하시는 데 가족들의 도움이 크게 작용했다면, 어떤 것이었는지 여쭤 봐도 될까요? 그리고 가족들의 이해나 협조를 크게 구하지 않고서도 원하는 바를 달성하는데 어려움을 겪지 않으셨다면, 그 구체적인 방법을 여쭤봐도 될런지요.
제 취미가 전부 많은 시간을 혼자서 하는 것이기 때문에 가족의 이해가 많이 필요합니다.
그래서 신혼이나 아이가 어렸을 때는 취미생활을 하지 못했고, 아내가 아이 교육에 매달리고, 아이도 커가면서 수험생활이나 자신의 시간이 필요하기 때문에 제게 많은 요구를 하지 않습니다.
그렇다고 너무 나 자신만의 생활을 할 수는 없으니 자전거도 라이딩을 당일 코스에만 국한하고 횟수도 계획한 정도만 하고 있습니다.
대신 출퇴근이나 거의 모든 이동시에 자전거를 이용하는 등 생활화하여 가족들에게 지장이 없도록 자연스럽게 즐깁니다.
지금은 그런 취미가 나의 건강과 생활의 활력에 도움이 되는 것임을 알고 있기 때문에 가족들이 많이 이해해 줍니다.
한편, 분명 사는 동안 몇개의 다른 취미를 또 가지게 될텐데 다음 취미는 요리처럼 다른 사람에게도 즐거움을 줄 수 있는 취미가 되면 좋겠습니다.
물론 제 마음대로 될지는 모르지만요.
- - -
이상 인터뷰 전문이었습니다. 인터뷰를 진행하면서, 일과 취미를 대하는 따뜻한 마음, 타인에 대한 배려, 겸손, 그리고 무언가에 매진하는 의지, 타인과의 소통을 중요시하는 품성을 느낄 수 있었습니다.
저 개인적으로는 달인 또는 전문가가 되는 네 가지 요소를 의지, 동기, 소통, 시간으로 꼽고 있습니다. 새다리님은 그 중 가장 어려운 소통의 문제를 실천적으로 해결해오고 있으실 뿐 아니라, 동기를 발견해 내는 눈에 더해 그 동기를 실천으로 옮길 의지도 분명한, 보기드문 분이었습니다. 본인은 아니라고 손사래를 치시지만, 아마 인터뷰를 읽고 그 분의 블로그를 방문한 많은 분들이 저와 같은 생각을 하시리라 믿습니다.
올바른 리더란 어떤 리더일까요? 아마 이런 류의 질문을 하면 답이 수천가지는 족히 나올 것 같군요. 사람마다 관점이 다 다를 수 있으니까요.
그러니 오늘은 예를 한번 들어보도록 하겠습니다. 올바른 리더, 존경받는 리더란 어떠해야 하는가에 대한 나름대로 괜찮은 사례죠. 실제 사례가 아니고 드라마에 나온 사례라는게 좀 아쉽긴 하군요.
워킹데드 시즌 2 에피소드 7번 보셨나요? 이것으로 워킹데드 시즌2의 절반이 끝나고, 나머지 절반은 두달을 기다려야 볼 수 있게 되었습니다.
이번 시즌의 에피소드의 주된 소재는 '소피아를 찾아서' 였습니다만 진짜 주제는 '릭과 셰인'의 리더쉽 싸움이었어요. 핵심은 농장 한 켠에 버티고 서 있는 헛간이었습니다. '좀비는 병자일 뿐'이라는 관점을 견지하고 있던 농장주가 좀비들을 보이는 대로 생포해서 헛간에 가둬놓은 것이 문제의 시발이었죠.
소피아와 대면한 릭
셰인은 그 좀비들을 들을 전부 총으로 끝내고 안전을 확보하자고 주장했고 (자신들을 임시로 거둬주고 있던 농장주의 의견과는 180도 다른 의견), 릭은 계속 농장주를 설득해 일단은 농장에 남은 다음 좀비 문제를 해결하자고 제의했습니다. 아내가 임신을 하는 바람에, 농장을 나가면 대책이 없어진다는 것이 릭의 문제였죠. 셰인의 말대로 하면 다시 떠돌이 생활을 하게 되거나, 아니면 최악의 경우 농장주를 죽이고 농장을 빼앗아야만 하는 일이 생길 수도 있었습니다.
그래서 릭은 예전같았으면 절대로 하지 않았을 '좀비를 생포해서 헛간에 밀어넣기' 같은 더러운 작업도 마다하지 않습니다. 릭의 생각에 분명 좀비들은 '시체'에 다름 아니었지만, 가족들을 살리기 위해 농장에 남을 수만 있다면, 농장주의 요구도 들어줄 수 있다는 전향적인 자세를 보인 것이죠. 농장주를 설득해 좀비들을 죽이는 것은 그 다음에 해도 된다고 생각했던 것입니다.
좀비 '생포'라니 대체...
하지만 셰인은 그렇지 않았습니다. 좀비들을 무조건 싹 쓸어버려야 한다고 주장했죠. 그리고 '모든 사람의 안전을 생각하고, 그 안전을 확보하기 위해 무슨 일이든 다 할 수 있는 것은 나같은 사람'이라고 끊임없이 주장했습니다. 겉보기에 릭이 취한 방법은 나약하고 지루해 보였으니, 죽음 앞에서 다급해진 사람들 가운데 셰인의 추종자가 생긴 것도 어찌 보면 당연한 일이라고 해야겠습니다만.
시즌 2에서 마초 사이코로 거듭난 셰인
결국 농장주와 릭의 바램과는 아무 상관 없이, 좀비들을 가두어두었던 농장의 문이 열렸습니다. 셰인이 농장의 문을 열어버린 것이죠. 결국 '좀비'라는 리스크가 대책없이 개방되었고, '어쨌든 좀비는 죽어야 한다'는 입장을 초지일관 고수하고 있던 셰인 일행은 좀비들을 향해 무차별 난사를 시작합니다. 그 덕에, 농장주의 아내와 자식들의 '좀비'도 쓰러지죠.
그런데 정작 심각한 문제는 그 다음 순간에 일어났습니다. 그들이 그토록 찾아해메던 '소피아'의 좀비가 헛간 안에서 걸어나온 것입니다.
이 순간, 총을 들고 있던 모두가 딜레마에 빠졌습니다. 자신들 (특히 셰인)의 주장에 따르면 소피아는 시체에 불과하니, 당장에 쏴 죽여야 마땅했어요. 하지만 그렇지 못했습니다. 모두들 소피아의 머리에 차마 총알을 날리지 못했죠.
그 순간을 정리한 것은 릭이었습니다. 총을 빼들고 걸어나와, 소피아의 머리를 날려버린 것이죠.
결국 문제를 해결한 것은 릭
아마 본인도 그토록 찾아 헤매던 소피아 앞에서, 설사 소피아가 좀비로 돌아왔다고 하더라도, 조금은 주저했을 겁니다. 소피아의 엄마도 보고 있는데, 과연 소피아의 머리를 날려버려야 하는 걸까.
하지만 때로 리더는 싫은 선택을 해야 합니다. '좀비는 시체일 뿐' 이라는 명제를 농장주에게 설득해야 하는 릭이 그랬죠. 잠시 전향적인 선택을 하긴 했지만, 릭은 깨달았을 겁니다. 소피아의 머리를 날려버리지 않으면, '좀비는 시체다'라는 모두의 견해는 설 곳을 잃게 된다는 것을.
릭은 '최후의 순간까지 설득을 멈추지 않아야 한다'는 태도와, '필요하다면 신념 앞에 주저함이 없어야 한다'는 태도를 일관되게 보여줌으로써, 농장주에게는 '나는 믿을만한 사람이다'라는 메시지와 '좀비는 시체일 뿐이다'라는 명제를 전달하는데 성공했고, 동료들에게는 '언제나 결정적인 순간에 결단을 내리는 것은 나'라는 사실을 보여주었어요. 거기다, 릭은 '상대의 가치를 존중하는 것의 미덕'을 온몸으로 보여주었습니다. 상대의 가치를 존중하지 않으면, 결국 폭력적인 결정을 내릴 수 밖에 없게 된다는 것을 알고 있었던 것이죠.
많은 사람들이 새로운 IT 캐치프레이즈를 만들 때, '스티브 잡스'라는 이름을 갖다 붙이곤 합니다. '제 2의 스티브 잡스 양성' 뭐 이런 식으로 말이죠. 그런데 대관절 어떻게 하면 '제 2의' 스티브 잡스를 만들 수 있는 걸까요?
그러려면 먼저 스티브 잡스가 어떤 인물인지를 알아야 되겠군요. 뉴요커 2011년 11월 14일 인터넷판에 말콤 글래드웰이 이런 기사를 썼습니다. "The Tweaker". 결론부터 말씀드리면, 스티브 잡스는 창조자혁신가라기 보다는 개량가 내지는 개선가라는 이야기죠. 그것에 관련된 이야기는 예전에 애플 이야기를 하면서 잠깐 드렸던 바 있습니다. [Thoughts] - 창조성의 비밀: 미국과 한국은 무엇이 다른가
글래드웰은 "The Tweaker"를 쓰면서 스티브 잡스 전기의 저자 월터 아이작슨의 이야기를 상당 부분 인용했습니다. 그 중의 몇 가지 흥미로운 대목을 살펴보면...
가장 성가신 문제는 어떤 세탁기를 사느냐 하는 것이었다. 잡스는 유럽 제품들은 세제와 물을 적게 쓰므로 옷감에 더 좋긴 하지만 세탁하는 시간이 미국 세탁기보다 두 배는 더 걸린다는 사실을 발견했다. 그럼 도대체 어떤 제품을 사야 하나? 잡스는 이렇게 술회했다. "우리 가족은 세탁기 선정과 관련된 트레이드-오프 문제를 해결하기 위해 많은 이야기들을 나누었습니다."
기본적으로 이런 것이 잡스의 태도였습니다.
잡스가 색상표를 끊임없이 바꿔대는 통에 공장에 설치된 로봇과 기계들에도 끊임없이 색을 다시 칠해야만 했다.
세탁기 하나에도 그렇게 집착하는 사람이 공장 내부에도 신경을 안 썼을리 없지요. 기본적으로 잡스는 모든 것이 '마음에 들 때까지' 다시 하고 다시 해야 직성이 풀리는 종류의 사람이었습니다. 심지어 그는, 췌장암으로 유명을 달리하기 직전 병원에 입원해 있는 동안에도, 마스크의 디자인이 마음에 들지 않는다는 이유로, 서로 다른 모양의 마스크 샘플을 요구하기도 했었습니다. 말도 제대로 할 수 없는 상태였는데도 말이죠.
글래드웰은 그의 그런 성격이, '산업혁명이 하필 영국에서 발원한' 이유와도 궤를 같이 한다고 보고 있습니다. 당시 영국에서는 기술이 굉장히 빠른 속도로, 개량적으로 발전했습니다. 당시 Samuel Crompton이라는 사람이 Spinning Mule이라는 이름의 직조기를 하나 만듭니다.
Spinning Mule
이 기계는 처음 고안되어 세상에 공개된 이후로, 대략 여섯 명 정도의 서로 다른 사람에 의해 개량되었습니다. Henry Stones는 기계에 강철 롤러를 추가했고, James Hargreaves는 회전 휠이 좀 더 부드럽게 가속하고 감속할 수 있는 방법을 고안했으며, William Kelly는 수력으로 기계를 구동하는 방법을 고안했고, John Kennedy는 휠이 정밀하게 양을 잴 수 있는 방법을 추가했으며, Richard Roberts는 최초의 Spinning Mule의 구조를 처음부터 다시 생각하여 좀 더 정확하고 좀더 고속의 '자동' Spinning Mule을 재창조해 냈습니다. The Tweaker의 내용을 인용하자면, "micro-invention이 macro-invention으로 이어진" 것이죠.
글래드웰은 스티브 잡스의 재능은 바로 이 '산업혁명기'의 영국 발명가들이 보여준 '끊임없는 개량과 개선의 능력'에 좀 더 가깝다고 언급합니다. 엄밀하게 이야기해서, 잡스는 '창조자''혁신가'는 아니라고 본 것이죠.
Job's sensibility was editorial, not inventive -- 말콤 글래드웰
2011년 12월 1일 수정: 덧글에 달린 의견을 반영해, 원글을 대폭 수정했습니다. 의견 주신 많은 분들 감사드립니다. 하지만 의견에 '인신공격성 발언'을 너무 많이 섞으신 분들은, 의견만 취하고 덧글 삭제, IP 차단했습니다. 의견을 취한 이유는 '의견 자체는 훌륭'했기 때문이고, 덧글 삭제하고 IP를 차단한 이유는 제가 '이런 분들하고 다시 엮이게 되면 스트레스를 받을 것 같아서'입니다. ㅋㅋ 의견을 주실 때는 의견만 주세요. '소통'을 이야기하면서 '소통을 방해하는 요소들'을 뒤섞으면, 우리는 결국 '소통과는 무관한 단어들'을 꼬투리 잡느라 시간낭비를 하게 됩니다. 저는 시간낭비하는 걸 굉장히 싫어합니다. 그건 여러분들도 마찬가지일거라 생각합니다. 문제점을 리스트로 만드는 걸 연습하시고, 가급적 비폭력적(NVC)으로 대화하세요. 소통에 드는 시간이 훨씬 짧아질 겁니다.
그렇게 따지고 본다면, 잡스가 이루어낸 혁신이라는 것은 대부분 '최초의 씨앗'에 크게 의존적이라고 결론 내려도 될 것 같습니다. 예전 글에도 적었습니다만, 잡스가 이루어낸 '혁신'은 과거의 유산을 아주 잘 다듬고 세련되게 만들어 낸 결과였습니다. 그 결과로 산업혁명에 비근할 만한(과장이 좀 심한것 같기도 합니다만) 변화를 만들어 내었죠.
그렇다면, 우리에게 중요한 것은 '최초의 씨앗', 그러니까 가끔 제가 '창조성의 자산'이나 근원이라고 부르는 무엇을 갖는 것이겠군요. '제 2의 스티브 잡스'를 빚어내려 고군분투 하는 것이 아니라, '제 2의 제록스 연구소' 같은 것을 가지는 것이 중요하겠다는 이야기입니다. 그래도 꼭 '제 2의 스티브 잡스'를 빚어내야 직성이 풀리시겠다면, 이것을 기억하도록 합시다. 그에게도 고쳐야 할 점이 있었다는 것을요.
애플이라는 기업 내에서 잡스는 어떤 사람이었을까요? 간단히 요약하면, 그는 "나는 무엇이 옳은지 '보면' 안다. 그러니 내가 OK할 때 까지 고쳐서 가지고 와라" 라고 말하는 관리자였습니다. 그를 독선적이라고 지적하는 많은 사람들이 그의 이런 점을 지적했죠. '보면 안다'는 이야기는 사실 중요한 의사결정이 그의 '취향'에 따라 내려진다는 이야기이기도 하거든요.
아이튠즈나 아이폰의 성공이 스티브 잡스 같은 다소 독단적인 'Tweaker'의 재평가를 가능하게 하긴 했습니다만, 여러분이 이런 류의 상사와 같이 일하게 된다면 기분이 어떠시겠어요?
"그래서 원하시는 게 뭔데요?"라고 빈센트가 물었다. "원하는게 뭔지 말 하지도 못하고 있잖습니까." 그러자 잡스가 말했다. "그래요 모릅니다. 하지만 뭔가 새로운 걸 나한테 보여줘야 해요. 지금까지 당신이 나한테 보여준건 그 근처에도 못갔다고요." 빈센트가 다시 반박하자 갑자기 잡스는 이성을 잃었다. "갑자기 나한테 소리를 지르기 시작하더군요." 빈센트가 술회했다. 빈센트 또한 적대적이 되었을 것이다. 두 사람은 점점 더 험한 소리를 주고받게 되었다. 빈센트는 이렇게 소리질렀다. "당신이 뭘 원하는지 말해 줘야 한다고요!" 그러자 잡스는 맞서 소리질렀다. "당신이 나한테 뭔가를 보여줘야 한다고. 그게 뭔지는 내가 보면 알아!"
이런 관리자가 존경할만한 유형의 관리자인가요? 일반적인 상황에서라면, 리스크가 너무 높죠. 그래서 잡스가 특별할지도 모르겠습니다. 리스크 따위는 전부 달나라 너머에 던져버렸으니까요.
콜롬부스가 아메리칸 대륙을 발견하였지만 그가 발견한 후로는 뭇사람들이 그를 깍아내렸죠.
개나 소나 배만 타고 주욱 가면 발견할 수 있었던 거라고.
하도 그런 헛소리에 시달리자, 콜롬부스는 사람들을 모아놓고 말했습니다.
달걀을 세워보라고... 아무도 못세웠습니다. 그러자 그는 달걀을 부숴서 탁자위에 세웠죠.
그와 비슷한 예는 역사에 많이 있습니다.
아인슈타인 시대에 태어났으면 자기가 상대성이론을 발견했을거라고 말하는 한국의 학부생조차 보았습니다.
누군가가 하고 나면 쉬워보이지만 그 경계에 처음 도달한 사람과 뒤따로 오는 사람과의 차이는 하늘과 땅처럼 큽니다.
자신이 단 한번이라도 세상의 선구적인 위치에 있었던 사람이라면, 타인의 남들보다 앞선 시야와 도전을 함부로 폄하하지 못할 겁니다.
유독 한국에서만 그를 비하하는 언론 기자들이 많은 것은 삼성의 머니플레이 덕택이기도 하지만, 그만큼 세상을 리더해나가본 자들이 없었다는 의미일거란 씁쓸한 생각도 듭니다.
하지만 이렇게도 한 번 생각해보시면 좋겠습니다. 스티브 잡스라는 '개량의 천재'가 있었기 때문에 지금의 애플이 있다는 것을 생각하기 전에, 과연 우리에게 '개량할 만한' 자산, 그러니까 제가 예전 글에서 '창조성의 자산'이라고 부를 만한 것이 축적되어 있느냐 하는 점을 따져봐야 한다는 것입니다.
우리에게도 '개량의 천재'들은 분명 많을 것입니다만 애플과 같은 결과물이 나오지 않은 것은, 그런 '창조성의 자산'이 제대로 축적되지 않은 탓이라고 저는 생각하고 있습니다.
그러니 오히려 우리가 배워야 하는 것은, 창조성의 자산을 축적하는 방법이라고 생각하는 것이죠.
제가 스티브잡스를 높이 평가하는 이유는 시대의 흐름을 읽을줄 안다는 것이죠. 2000년대 초반 냅스터가 유행하자 앞으로는 디지털음원 시장이 대세가 될거란걸 깨닫고 발빠르게 아이튠즈 열고 아이팟으로 대박을 쳤습니다. 오늘날 애플이 미국 음반시장을 좌지우지하는 위치를 차지하게 된것은 잡스 덕분이죠. 이런 일화가 한두개만 되도 영웅인데 잡스는 셀 수 없이 많습니다. 얼마전에는 시리를 만든 업체에 직접 전화해 인수를 추진했다던지. 현재 시리는 아이폰의 핵심 기능이 되었습니다. 그가 폭군이면서도 직원들의 존경을 받을 수 있었던건 그가 하자는대로 하면 대부분 성공했기 때문입니다
직관력의 질과 표현법의 질 사이에 구분이 있어야겠죠. 직관력과 직관력을 표현하는 방법은 꼭 같다고만은 할 수 없습니다. 개인용 컴퓨터, 아이팟, 아이폰 등은 완전히 새로운 시장을 만든 것이고 그것은 단기간의 유행이라고 말하기에는 약간 어폐가 있지 않나 합니다. 스티브 잡스가 추앙받는 이유는 이와 같은 뛰어난 직관력과 그것을 세상에 드러낼 수 있는 그의 능력 때문이지, 도덕적으로 완벽했기 때문은 아닙니다. 하지만 그랬다고 해서 그와 같이 일한 사람들이 꼭 불행하기만 했을까요? 착하지만 그래서 일반적인 생각밖에 하지 못하는 상사와, 괴팍하지만 직원들로 하여금 정말 새로운 세상을 열기 위해 일하게 할 수 있는 직관을 가진 상사. 둘 중에 누가 나은지 싸우는 건 무의미하다고 생각합니다.
글쓴이 께서 스티브 잡스를 개량의 천재라고 평한 것은 어쩌면
최초로 어떤 기능을 가진 기계를 발명하는 것만이 혁신이라고 생각 했기 때문이 아닐까합니다.
혁신은 사람마다 정의가 다르겠지만, 제가 생각하는 혁신은 기존의 틀에서 벗어나 새로운 것을 만들어내는 것입니다.
이 정의에는 어떤 특정한 기능을 가진 물건을 발명하는 것만이 포함되어있지는 않습니다.
새로운 사업모델(스마트폰 세상이 열린건 기계보다 앱스토어의 역할이 더 큰 것 같습니다, 아이튠즈 등) 많은 이해관계를 뚫고 거래를 성사시켜서 세상에 제품을 내놓는 과정 자체가 혁신이였다고 생각합니다.
그리고 잡스는 이를 통해 세상을 바꾸었지요. 저는 처음 발명한 사람보다 그것으 이용해서 세상을 바꾼 사람을 더 높이 사고 싶습니다. 그런 사람이 진정한 혁신가가 아닐까요?
제가 공학도 여서 이렇게 생각하는 걸지도 모릅니다.
또한 글쓴이의 글을 읽으면 잡스가
발명 한 것이 없고 단지 개량만 한 것이라고 사람들이 오해할 가능성이 있는데요, 이는 아시다시피 사실이 아닙니다. 잡스는 300개가 넘는 발명 특허에 이름을 올린 사람입니다.
잡스는 미국에서 성공할수 있는 인간형이죠. 한국에서 태어났으면 학벌과 인맥의 고리를 어떻게 못하고 아르바이트를 하거나 아님 잘되도 중소기업을 운영하다 대기업에 치여서 빚더미에 올랐을겁니다. 적어도 한국형 중소기업의 한계로 세계적인 기업이 될수는 없었겠죠. 말씀하시는것처럼 직관력과 똥고집 부분이 탁월한 인물이었지만 한국에서 이런 인간형은 주변과 융화하지 못한다고 배척당하죠. 직관력 부분도 안정적인 수익모델만을 추구하는 대기업이라 스마트폰같은 아이디어가 나와도 확 밀지 못했을겁니다. 모르긴 몰라도 삼성같은곳에 인재들이 많으니까 스마트폰 같은 의견은 잡스이전에도 나왔을거 같은 생각이 들어요. 이건 미국이니까 가능했고, 잡스니까 가능했던 거죠.
예전에, 골리앗들의 리그에서 다윗이 생존하려면 어떤 전략을 취해야 하는지에 대한 글을 올린 적이 있습니다. 결론은 간단했습니다. 절대로 골리앗들의 규칙을 따르면 안된다는 것. [Thoughts] - 규칙을 어기는 자가 성공한다
최근에 머니볼(moneyball)이라는 영화가 상영되었는데요. (영화를 보진 못했습니다) 인터넷에 돌아다니는 리뷰들을 보면 이 영화는 마치 말콤 글래드웰이 'underdog들의 성공 철학'에 대해 풀어놓은 이야기들을 그대로 영화로 만들어 놓은 것 같아 보이더군요.
영화의 플롯은 단순합니다.
오클랜드 애슬레틱스라는 야구팀이 있습니다. 뭔가 잘 풀리지 않는 팀인데다, 결정적으로 돈이 없습니다. 돈이 없으니 양키스처럼 돈을 많이 주고 '좋은' 선수들을 뽑을 여력이 없습니다.
이런 상황에서는 적절히 돈을 주고 좋은 선수들을 뽑아와 좋은 경기를 펼쳐 승률을 올린다는, 양키스와 동일한 전략을 취해서는 승산이 없습니다. 일단 돈이 없으니까요.
그래서 단장 빌리 빈은 다른 전략을 취하기로 합니다. 일단 철저히 선수들의 성적을 통계적으로 분석한 다음에, 출루율이 높은 선수들만 고릅니다. 그런 다음, 그 선수들을 집중적으로 내보냅니다. 포볼로 진루하던, 데드볼로 진루하던 상관하지 않습니다. 무조건 루상에 나갈 확률이 높은 선수들을 집중적으로 선발하여 내보냅니다. 전체적인 상품성을 따지지 않으니, 출루율이 높은 선수들 가운데 몸값이 낮은 선수를 데려올 수 있습니다. 나이가 많건 적건, 부상에서 회복중이건 아니건 따지지 않습니다.
결과는 어떻게 되었을까요?
오클랜드 애슬레틱스는 그해 20연승이라는 야구 역사상 전무후무한 대기록을 세웁니다. 물론 월드시리즈에도 진출했습니다만, 아쉽게도 포스트시즌에서는 실패하고 맙니다. 대신 이러한 구단 운영 철학은 보스턴 레드삭스에 전수되어, 보스턴 레드삭스가 '베이브루스의 저주'를 끊고 우승하는 데 결정적인 역할을 하게 됩니다.
물론, 이런 전략은 '전통적인' 야구를 사랑하는 사람들 관점에서 보면 탐탁치 않은 전략입니다. 일단 선수들을 수시로 갈아치우는 것이 정당화되고, 연봉이 상승한 선수는 재빨리 다른 구단에 넘긴 다음에 차익으로는 저평가된 다른 선수들을 데려와 자리를 메웁니다. 그다지 인간적인 것 같아 보이지는 않습니다.
하지만 이런 방법론적 '비인간성'이 과연 비인간적인 것인지에 대해서는 달리 생각할 수도 있습니다. 저평가된 다른 선수들 입장에서는 오클랜드 애슬레틱스는 '두 번째 기회', 그러니까 Second Chance를 주는 구단이거든요. 외부 평가가 어떠냐와는 상관 없이, 선수들 입장에서는 그것이 가장 중요한 일일 수도 있는 것이죠.
어쨌든, 골리앗(양키스와 같은)과 싸우는 판에서 승수를 챙기려면 이렇게 다소 '변칙적'인 전략이 먹힐 수 있습니다. 같은 규칙으로는 이길 수 없으니까요. 그리고 이런 전략은 확률적인 접근법이라는 측면에서 과학적이기도 합니다. 출루율이라는 측면을 놓고 보면, (경기는 좀 재미없어질지도 모르지만) 꼭 '잘 쳐서' 진루하는 것만이 정답일까요? 볼넷을 골라내는 좋은 선구안은 정말로 가치가 없는 것일까요?
이 이야기의 교훈은, 성공 전략을 수립하는 데 있어서 '획일화된 기준'의 위험성이라고 볼 수 있을 것 같습니다. 거대한 시장에서 성공을 거두려면, 획일화를 피하세요. 인간적으로 문제가 있는 사람들이 모여 있더라도, 각자가 자기가 강점을 갖는 부문에서 정상적인 성과를 낼 수 있다면, 그런 팀 조차도 성공할 수 있을지 모릅니다.
물론 이건 야구 선수들 이야기니까, 소프트웨어 프로젝트에서는 이야기가 좀 다를지도 모르죠. 야구경기장에서는 각각의 플레이어가 '공'만 가지고 서로 소통하지만, 소프트웨어 프로젝트는 그것보다는 훨씬 더 복잡합니다.
그러니, 소프트웨어 프로젝트에 '머니볼' 적 전략을 도입하려면, 우리는 '조율'의 문제를 좀 더 심각하게 생각해 봐야 할 거에요. 전체적으로 봐서 '소프트웨어 개발'을 수행하기에 못미치는 프로그래머들이 있다고 하죠. 그런데 누구는 코딩은 기가 막히게 잘 하고, 누군가는 테스트를 기가 막히게 잘 하며, 누군가는 야부리를 기가 막히게 잘 친다고 가정해봅시다.
이런 팀은 어느 정도의 성공확률을 가지고 있을까요?
어쩌면, 그런 팀이야 말로 리더의 역량이 가장 빛날 수 있는 팀일지 모릅니다.
오클랜드 애슬레틱스에서, 빌리 빈이 그랬던 것 처럼요.
스마트폰을 쓰다 보면, 이게 워낙에 터치 기반이라 시각장애인을 위한 인터페이스로도 기능할 수 있는 방법이 충분히 있을 거라고 생각하게 됩니다.
하지만 실제로는 조금 절망적이죠. 시각 장애인에게 터치스크린은 또다른 평면일 뿐이거든요. 가끔 특정한 버튼을 누른다거나 특정한 기능을 실행하면 소위 햅틱 반응이라고 불리는 진동 반응을 느낄 수 있긴 한데요. 시각 장애인들에게 충분히 활용될 수 있을 정도는 아니에요.
사실 시각 장애인들에게 터치스크린이 유의미한 입력장치가 되려면, 터치 스크린을 통해 질감을 느낄 수 있어야 해요. 가능할까요? 글쎄요. 지금까지 기술로는 아닌 것 같습니다만. 아래의 동영상과 같은 스마트폰이 실현되면 어떨까요?
나노테크놀로지와 터치 기반 입력 UI를 결합해서 만든, HumanForm이라는 이름의 입력장치/스마트폰입니다. 물론 아직 시장에 나온 제품은 아니고, 그냥 이렇게 만들면 쌈빡하겠다... 는 정도의 리서치 프로토타입이죠.
동영상 중간에서 발견하실 수 있으시겠습니다만, HumanForm은 자유자재로 휘어집니다. 거기다 결정적으로 놀라운 것은... 터치를 통해 '사물'의 질감을 느낄 수 있도록 만듭니다! (동영상에서는 '이미지'의 질감을 느끼도록 하는 기술을 시연하고 있죠.)
이런 기술이 현실화가 되면, 시각장애인들은 별다른 장치 없어도 '올록볼록'한 버튼을 (무슨 버튼인지가 양각되어 있는) 누를 수 있을 거에요. 누르자마자 그 버튼은 온데간데 없이 사라질 것이고, 버튼이 있던 자리는 방금 실행한 기능이 메우게 되겠죠. 이 모든 것들을 '촉각'으로 느낄 수 있게 된다는 겁니다.
이런 기술들을 제안하고 만드는 것은 노키아의 연구센터, http://research.nokia.com/ NRC (Nokia Research Center) 입니다. 최근에 노키아가 상황이 어렵습니다만, 그래도 계속 이런 혁신적인 아이디어들을 내 놓는 다는 것, 놀랍지 않나요? 혁신과 창조성의 '관성'이 지금까지 계속되고 있음을 느끼게 되죠.
이런 것이 한 기업의 저력이 아닐는지. (부자는 망해도 삼대는 가는 법...)
어쨌든 이런 형태의 스마트폰은, 장갑을 끼고 이용해야 하는 시각장애용 전화기나 말하는 스마트폰 같은 아이디어보다는 참신합니다. 일단, '터치'라는 기존의 UI 이용 방법을 변경하거나 왜곡하지 않는 것이 가능하죠. 그리고 시각장애인들이 이미 친숙한 방식으로 정보를 전달할 수 있구요.
트위터와 같은 새로운 형태의 미디어는 정보를 소비하는 사람들에게 새로운 질문을 던집니다. "과연 내가 tweet 혹은 retweet하는 이 정보는 얼마나 진실한가?"
정보를 유통하는 사람들은 보통 정보의 진실성에 대한 책임을 져야 하는데, SNS에서 그 책임은 아주 가볍습니다. 굳이 표현하자면, Featherweight responsibility 정도?
보통 우리가 매스미디어를 욕할 때, 그 근거로 삼는 것들은 대개 일정합니다. 매스미디어가 정보를 유통시킬 때, 그 정보의 소스에 대해서 철저한 확인 작업을 거치지 않는다는 것이죠.
트위터와 같은 SNS에서는 그런 일이 더 심하게 발생할 수 있습니다. 누군가, 출처가 불명확한 정보를 트위터에 올립니다. 그럴싸다하다고 생각한 다른 사용자가 해당 정보를 retweet합니다. 관련된 사람의 영향력이 크면 클수록, 정보 확산 속도는 빨라집니다.
문제는 정보를 중계하는 사용자들이 정보 출처에 대한 분석 작업 없이 자신이 retweet하는 정보를 '그냥 믿어버리는' 경우가 있다는 점입니다. 이런 경향이 심해지면, 확인되지 않은 정보들이 또 다른 정보의 출처나 참고자료(reference)가 되는 일이 발생합니다.
위키피디어 같은 crowdsourcing 모델은 정보에 대한 검증 책임을 집단적으로 지도록 해서 그런 문제를 피했습니다만, 아쉽게도 트위터와 같은 SNS에서 '검증'과 같은 문제는 부차적으로 치부되기 쉽습니다. 잘못된 정보가 쓰나미처럼 타임라인을 쓸고 지나간 뒤에 뒷북처럼 검증이 이루어지는 것이죠. 결국, 우리는 우리가 부정하는 매스미디어가 저지르는 문제를 반복하게 됩니다.
SNS를 통해 뉴스를 crowdsourcing 하는 경우, 우리는 그런 문제를 항상 염두에 두어야 합니다.
위의 링크는 news를 '성공적으로' crowdsourcing한 사례들을 나열하고 있습니다. 시스템적인 관점에서만요. 하지만 '시스템'은 우리가 잘못된 정보를 보는 일을 막기에는 역부족입니다. 바라기로는 SNS를 통해서 '검증 결과'가 전파되는 속도가 '잘못된 정보가 유통되는 속도'에 비견하기를 바라지만, 정말로 그럴 수 있을까요?
위의 TED 동영상이 웹사이트에 공개되고, 많은 사람들이 덧글을 달았습니다. 뉴스를 crowdsourcing 한다는 것에 대해서 많은 사람들이 긍정적인 반응을 남겼습니다. (저는 부정적인 쪽에 서 있는 셈이군요.)
위의 이미지는 그 덧글들의 일부입니다. 어떤 사람들이 어떤 의견들을 개진하였는지는, 직접 확인해 보시기 바랍니다. IT 기술이 정보를 유통하는 방법을 혁신하고는 있습니다만, 어떤 정보를 어떤 형태로 책임있게 전달할 지에 대해서는, 아직 생각해 봐야 할 것들이 많이 남아 있습니다.
IETF (Internet Engineering Task Force)는 인터넷과 관련된 표준화를 담당하는 표준화 기구입니다. ITU-T에 계시는 분들은 IETF에서 제정된 RFC가 진정한 의미에서의 표준은 아니라고 낮추어 보기도 합니다만, 제 소건으로는 ITU-T와 IETF는 표준화 하는 영역에 조금 차이가 있을 뿐, 결국 거기서 거기입니다. 하다 보면 결국 두 기구가 특정한 기술을 표준화 하는 데 있어서 협력을 하기도 하고요.
그런데 오늘 하려고 하는 이야기는 사실 그건 아닙니다. 오늘 하려고 하는 이야기는 Open Source의 개발 모델과 IETF의 표준화 모델 사이의 유사성입니다.
IETF
IETF는 표면적으로는 열려 있는 표준화 기구이고 아무나 참석하여 표준화에 기여할 수 있도록 되어 있습니다만, 좀 더 깊이 들어가보면 사실 꼭 그렇지는 않습니다. Cisco, Juniper, Huawei 등 네트워크 분야의 주도권을 쥐고자 하는 많은 업체들이 싸우는 전쟁터이기도 합니다. 각 업체 입장에서 보면, 표준이 제정될 때 어떻게든 자사 기술이 표준으로 채택되도록 만들 필요가 있습니다.
보통 표준화가 진행되기 전에 각 업체는 자사 기술에 대한 많은 특허를 내놓습니다. 그러나 자사 기술이 공통 표준에 많이 반영되면 될수록 표준 = 자사 기술의 등식이 성립하게 되고, 이렇게 되면 유리합니다. 자사 특허를 침해하지 않고 표준안 대로 기술을 구현할 수 있는 가능성이 적어지게 되니까요.
그렇게 되면 궁극적으로는 자사의 기술을 택한 장비가 시장에 퍼지게 되던지, 아니면 특허에 대한 기술료라도 받아 챙길수 있는 구조가 됩니다. 간단히 말하자면 그렇습니다. 이것이 IETF를 통한 표준화에 네트워크 장비 생산업체들이 그렇게 열심인 이유입니다.
Open Source
오픈소스 또한 모든 개발자에게 열려 있는 구조입니다. 아무나 참여해서 필요한 기능을 추가하고, 확장해 나갈 수가 있습니다. 그런데 최근의 오픈소스 개발 모델을 보면, 어느 정도는 IETF와 비슷해지고 있습니다.
결국 Message 시스템의 구현에 필요한 Consistency 측면과, 다량 메시지에 대한 Indexing 요구사항을 처리할 수 있는 데이터베이스 기술로 최종 채택된 것은 HBase 였습니다. [각주:1] 그리고 HBase를 페이스북의 Message 데이터베이스로 이용하기 위해, HBase에 페이스북은 꽤 많은 기여를 했습니다. 그 덕에, 전 세계의 좀 더 많은 개발자들은 좀 더 향상된 기능의 HBase를 사용할 수 있게 되었죠. (여전히 HBase는 오픈소스입니다)
그렇다면, 오픈소스 세계에서 최종적으로 살아남게 되는 기술은 어떤 기술일까요? 최종적으로는, 페이스북과 같은 대형 업체에서 사용되는 오픈소스가 살아남을 가능성이 높습니다. 개발자들은 본능적으로 그런 기술에 이끌리게 되어 있죠.
결국, 페이스북이나 구글과 같은 대형 업체들이 잠식하고 있는 것은 플랫폼 시장 만은 아닌 셈입니다. 이미 그런 대형 IT 업체들은 Open Source 프로젝트 또한 좌지우지 할 정도의 영향력을 행사하게 되었고, 그 과정을 통해서 성장한 Open Source 기술들은 대형 플랫폼 업체들이 자사 기술의 영향력을 확대시키는 수단으로서도 기능하게 되었습니다.
오픈 소스 시스템을 상업적으로 이용하려면 우리는 그에 대한 대가를 지불해야 합니다. 오픈 소스는 오픈되어 있기는 하지만, 공짜는 아니기 때문이죠. 오픈 소스 시스템을 확장했다면 (확장을 어떻게 했느냐에 따라서는) 확장하는 데 사용된 소스를 공개해야 합니다. MySQL처럼 '상업적으로 사용하려면 돈을 내라'고 하는 곳도 있습니다. 거기다 오픈 소스 구현에 사용된 기술 중 상당수는 이미 특허가 제출된 것들입니다.
'공개'의 함정
그러니 우리는 뭔가가 '공개'되었다고 하면 거기에 대해서 다시 한 번 생각해 봐야 해요. 오픈소스 프로젝트가 처음 태동되었을 때만 해도 '공개'의 의도는 순수했습니다. 그런데 지금도 정말 그럴까요? 누가, 무엇을, 왜 공개했는지 좀 더 심도있게 고민해야 할 시점이 된 것 같네요.
MySQL은 RDBMS라서 데이터가 많아지면 인덱싱하는 데 드는 시간이 성능 요구사항을 만족할 수 없을 정도로 커졌고, Cassandra의 Eventual-consistency 모델은 '결국에는 consistency가 맞는다'는 낙관적인 형태의 모델이어서, 언제나 consistency가 보장되어야 하는 messaging 시스템 구현에는 쓰이기 곤란했습니다. HBase는 간단한 형태의 consistency 모델을 제공하고 있었고, 성능도 괜찮았습니다. [본문으로]
댓글을 달아 주세요
우연히 블로그를 들어오게 되었고 재미있게 글 읽고 있습니다.
2012/02/10 13:49 [ ADDR : EDIT/ DEL : REPLY ]저는 지금 대학교 4학년이며 MIS전공으로 IT쪽으로 진로를 잡고 있는데 정말 재미 있게 보고 있습니다.
앞으로도 재미있는 글 부탁 드립니다.
아이구 감사합니다. 열심히 쓰겠습니다.
2012/02/10 17:00 [ ADDR : EDIT/ DEL ]프로그래머가 새로 연재되어 읽을 때마다
2012/02/10 17:44 [ ADDR : EDIT/ DEL : REPLY ]The Bug in the Seven Modules
A Parody
by Andy Oram
Copyright © 1997
가 자꾸 연상됩니다.
못읽어봤는데, 한번 찾아봐야겠네요. 감사합니다.
2012/02/10 17:53 [ ADDR : EDIT/ DEL ]리얼한면이 있는 것 같아요. 직접 겪으신것도 한두가지는 포함되어있겠죠?
2012/02/11 00:32 [ ADDR : EDIT/ DEL : REPLY ]아무래도 그렇죠 ^^
2012/02/11 12:54 [ ADDR : EDIT/ DEL ]