책을 쓰는 동안 가장 힘든 것이 무엇이었냐고 누가 물어온다면 수많은 일들이 머리에 떠오르겠지만, 그 중에서 가장 대표적인 두 가지만를 꼽자면 내가 쓰려고 하는 내용이 공격 받는 것을 발견하는 것과 끊임없이 발생하는 호기심을 억눌러야 하는 것 두가지를 들고 싶다.

책이 나오고 책의 내용이 공격 받는 것은 차라리 나을 것 같다. 이미 출간되서 독자 손에 들어갔으니 뭐 어쩌겠는가. 자기들끼리 지지든 볶든 상관할 바도 아니고, 상관해봤자 온라인으로 출판된 글과 달리 인쇄된 책의 내용을 고칠 수도 없으니 차라리 마음이 편할지도 모르겠다는 생각을 했다. 물론 속은 많이 상하겠지만.

사실 책의 내용에 대한 공격은 원고가 내 손을 떠나기 전에 이미 시작된다. 책을 쓰는 내내 저자 머리 속에서 치열한 전쟁이 벌어지기 때문이다. 내가 쓴 글을 다시 읽을 때마다 과연 이 얘기가 정말 맞는 것일까 혹은 잘못 설명한 것은 아닐까 하는 의심이 끊임없이 들었다. 책을 쓰기 전에는 분명한 확신을 가지고 어디서든 당당하게 얘기했던 내용조차도 책의 원고에 넣고 나면 갑자기 수상하게 보였다. 그래서 관련된 책을 찾아보고 인터넷을 뒤지면서 내가 설명하는 내용이 타당한지 검토하고 또 검토했다. 물론 논쟁거리에 속하는 그런 주제는 어쩔 수 없다. 그건 내가 어느 한편을 지지하든지 아니면 적절한 선에서 양다리를 걸치든지 하는 수밖에. 대신 독자들이 최종 판단을 내릴 수 있도록 충분한 근거들을 나열해주는데 신경을 썼다. 때로는 한 문단의 내용을 뒷받침 해주는 근거를 뽑아내기 위해 책 한권을 통채로 읽은 적도 있다.

내 스스로 확신이 없는 않는 내용은 책에 넣지 말자는 생각이었다. 물론 내 확신이 틀린 수도 있지만 그거야 어쩔 수 없고.  그동안 다른 책을 읽으면서 잘못된 주장이나 왜곡된 사실이 얼마나 많이 책에 들어가는지 놀랄 때가 많았다. 저자가 지지하는 기술을 위해서 경쟁관계에 있는 기술을 폄하하는 모습을 보면 짜증도 났다. 특히 스프링은 그런 공격을 가장 많이 받은 기술이다. 희한하게도 스프링은 사람들의 심기를 건드리는 뭔가가 있는 듯 하다. 자신이 지지하는 개발철학이나 기술을 절대적으로 신봉하는 사람은 그래서 스프링이 불편하다. 물론 나중에 스프링이 대세다 싶으면 자신이 비난했던 일은 쏙 감추고 스프링 전문가  행세를 하고 다니기도 하지만.

저자의 성의가 부족해서 잘못된 사실이나 설명을 책에 남기는 것은 어떻게든 피하고 싶었다. 그래서 스프링 기술에 대한 설명은 문서만 참고해서 작성하지 않고 일일이 학습테스트를 만들어서 내 눈으로 동작하는 것을 직접 확인하려고 노력했다. 2부 예제인 Part2 프로젝트의 학습 테스트 코드는 그렇게 만들었던 테스트의 일부를 독자들도 참고해보라고 넣은 것이다.

문제는 1부였다. 코드야 거의 TDD에 준하는 테스트를 계속 작성해가면서 만들었으니 기능적으로는 문제가 없을 것이다. 하지만 스프링의 프로그래밍 모델과 개발철학을 이해하는데 도움이 될 것이라고 생각해서 동원했던 다양한 이론과 원칙, 패턴들에 대해서는  간단히 검증할 수 있는 것이 아니라서 고민을 많이 했다. 처음엔 애자일 개발 이론을 동원해서 스프링의 특징을 설명하려고도 노력했는데, 애자일은 너무 방대하고 내가 도저히 감당할 수 있는 주제가 아니라고 판단되서 그 내용은 모두 제거했다. 대신 가장 단순하고 명확한 한 가지 이론을 꺼내서 그것에 대한 이론적인 설명대신 그 이론이 코드에 적용되서 코드가 발전하는 모습을 보여주려고 노력했다. 이론이 눈에 보이는 코드에 적용되서 더 나은 코드가 되는 모습을 보여주고 싶었다. 반대로 그런 코드의 개선 이유를 설명할 수 있는 용어와 이론을 알려주고 싶었다. 그리고 그렇게 개선된 코드가 바로 스프링의 핵심 기술이고 스프링이 개발자들에게 권장하는 코드라는 것을 보여주기 바랬다. 그래서 선정한 가장 간단하고 명료한 개발 이론이 바로 관심사의 분리(SoC)였다. SoC도 깊이 들어가면 복잡하고 방대한 주제긴 하지만, 그냥 그 용어의 표면적인 의미만 가지고도 충분히 내가 원하는 설명을 이끌어낼 수 있을 것이라고 기대했다. OO원칙이니 패턴이니 하는 얘기를 너무 자주 들먹이면서 설명을 하면, 그런 이론을 좋아하는 사람들은 만족할지 모르겠지만 그렇지 않은 개발자들은 오히려 피로를 느낄 수 있기 때문이었다. 그래서 가장 단순한 "관심이 다른 코드는 분리하는 것이 좋다"는 명제 하나를 가지고 코드를 살펴보는 것으로 스프링의 모든 개발철학과 핵심기술을 설명하려고 시도했다.

스프링의 DI는 기본적으로 SoC를 바탕으로 한다. DI는 의존관계에 대한 것인데, 의존관계가 성립하려면 적어도 두 개의 구분된 존재(오브젝트)가 필요하다. 그래야 한 쪽이 다른 한 쪽을 의존할 수 있고, 그래야 DI도 성립하니까. 그래서 DI의 기본 전제는 분리다. 사람들이 스프링을 왜 제대로 사용하지 못할까를 고민하면서 내가 내린 결론은 겨우 3계층으로 구분하고 나면 더 이상 분리를 할 줄 모르기 때문에, DI할 필요를 찾지 못하기 때문이라는 것이다. 성격이 다른 코드를 하나의 클래스와 메소드에 마구 우겨 넣어놓았으니 무슨 DI가 가능하겠나. 가장 원시적인 DI가 적용된 템플릿/콜백도 의미있는 분리가 기본 전제다. 그렇게 따져보면 스프링의 모든 기술은 다 적절한 관심사(책임, 변경조건, 성격.. 뭐라고 해도 좋다)에 따라 코드를 분리하는 데서 시작된다. SoC라는 용어가 소프트웨어 개발의 가장 근간이 되는 기본적인 원칙으로 자리를 잡게 된 것도 비슷한 맥락이라고 봤다.

내 책을 본 사람들은 알겠지만 1장의 앞부분에서부터 이 SoC가 등장한다. 사실 SoC라는 용어가 중요한 것은 아니니 그 뒤로는 그냥 "관심(책임, 변하는 성격)이 다른 것이 같이 있네? 분리해 보고 어떻게 되나 살펴보자"라는 식의 설명으로 바꾸긴 했지만, 이 원칙을 1부 내내, 7장까지 끊임없이 반복해서 적용한다. 그러면 스프링 다운 코드가 되고 스프링 자신이 된다. 짜잔. 이제 1부의 내용이다. 거창한 객체지향이니 원칙, 패턴 같은 것도 따져보면 여기서 부터 출발하는 것이라고 생각했고, 그런 패턴의 기계적인 적용에 앞서서 먼저 적절하게 분리되야 할 코드를 살피는 것(물론 응집도를 높이기 위해서 분리한 것을 다시 유연한 방식으로 결합하는 주제도 나오지만)에만 충실해도 도움이 될 것이라고 생각했다.

그리고 1부의 마지막인 8장에서는 스프링이 이 적절한 분리(SoC)를 통해서 엔터프라이즈 개발의 복잡함을 효과적으로 다룰 수 있게 해준다는 결론을 내렸다.

그런데 어느날 우연히 "SoC가 가져오는 복잡성을 극복하는 방법"이라는 글을 봤다. 글의 취지나 내용은 대충 이해하지만 이 제목과 SoC, 복잡함이라는 단어를 사용하는 방식에는 동의할 수 없었다. 그런 자극적인 문구를 보니 갑자기 내가 썼던 글들이 온통 부정당하는 느낌이 들었다. 지금까지 SoC가 어떻게 복잡함을 극복하는지에 대한 이야기를 풀어나가고 있었는데 SoC가 복잡성을 가져온다니! 그 글에선 SoC라는 단어를 극히 협소하고 제한된 의미로 사용하고 있다고 생각됐다. 게다가 복잡함에 대한 설명도 받아들이기 힘들었다. 글의 취지는 이해하지만 그래도 마음이 불편하고 신경 쓰였다.

그래서 블로그에 가볍게 반박하는 글을 썼다. 글 전체에 대한 반박이라기 보다는 복잡함과 SoC라는 단어 사용에 대한 반론이었다. 글을 썼던 S님도 내 블로그를 찾아와 "의견 고맙다"는 답글도 달아줬다.

나오지도 않은 책의 내용을 반박당하는 듯해서 찝찝했던 기분은 다시 좋아졌고 다시 내 주장을 계속 펼쳐나가면 되겠다고 생각했다. 그런데 그 때 사고가 터졌다. 블로그계의 악동 영회였다. SoC에 관한 글에서 복잡함이라는 주제에 대한 내용은 내가 충분히 반박할 수 있다고 생각했지만, 글의 결론으로 나오는 UML모델링 툴의 사용이 해결책이다라는 내용은 내가 그 툴을 거의 써본 적이 없고 모델링 툴을 통한 접근방법에 대해서는 별 관심도 없었기에 내가 다룰 내용이 아니라고 생각했다. 대신 평소에 모델링툴 만능주의자들을 끊임없이 비난해왔던 CBD 모델링 컨설턴트 출신의 영회가 생각났다. 게다가 언급된 툴은 마침 영회가 잘 안다고 하던, 그래서 블로그에 소개도 자주 하던 것이었다. 그래서 마침 메신저에 들어온 영회에게 그 글을 보여주면서 의견을 물었다. 영회도 그 내용이 불만이었다. 그래서 자기도 글을 하나 쓰겠다고 했다.

그런데 웬걸 다음날 아침에 난리가 났다. 영회가 또 사고를 쳤다는 얘기가 들려왔다. 영회 블로그를 급히 가보니 S님의 글을 링크해놓고 "아직 경험이 없고 어려서 뭘 모른다"거나 "닷넷 개발자들은 수준이 낮다"는 식의 자극적인 얘기가 적혀있었다. 모델링 툴에 대한 그 글의 해법에 대해서 의견을 써보라고 했더니 그런 얘기는 없고 인신공격으로 보일 수 있는 글을 적어놨다.

그때문에 한동안 시끄러웠다. 사실 영회 글의 파급력이 엄청났기 때문에 내 글은 묻혔다. 게다가 S님은 내가 영회랑 짜고 자기를 공격했다는 식으로 나를 비난하기 시작했다. 억울했다. 해명을 하려고 메신저로 연결해서 이야기를 나눴지만, 영회의 공격에 감정이 많이 상한터라 반응이 안좋았다. 공격의 화살은 오히려 내게로 돌아왔다. 내가 영회한테 시켜서 그런 글을 쓰게했다는 식의 얘기가 떠돌았다. 영회가 그렇게 오해하기 딱 좋은 댓글("형이 시켰자나")을 써놨기 때문이다. 영회한테 글을 알려주고 글을 써보라고 했지만 그게 자신의 평소 주장을 이용해서 글의 내용을 반박을 하라는 거였지, 닷넷 개발자를 깔아뭉개거나 엄마젖 더 먹고와라는 식의 글을 쓰라는 것은 아니었는데 내가 그런 악의적인 글을 쓰도록 뒤에서 조종한 사람 취급하는게 억울했다.

영회도 막상 일이 커지니 당황해서 글을 수정하고 지우고 자극적인 문구에 대해 사과하는 등 수습하느라 바빴다.

피곤한 경험이었다. 물론 나중에 S님을 잘 달래서 오해는 풀어줬고 좋은 사이가 될 수 있었지만 서로에게 조금씩 상처를 남긴 유쾌하지 않은 기억이다. S님 기분을 풀어주기 위해서 N모씨가 쓴 영회에 대한 인신공격/비방 글을 모두 찾아서 보여주기도 했다. 그리고 인터넷에 글을 남기고 활동하는 것은 언제든 이런 공격을 받을 수 있다는 것, 그리고 그런 위험을 감수할 수 밖에 없다는 것에 대해서 설명했다. 나도 "xxx에 경험도 없는 놈이~"라는 식의 인신공격을 받아본 적이 있기 때문에 그 심정을 대충 이해한다. 인신공격을 이용해서 자기 주장을 내세우는 것은 치사하지만 상당히 효과적이다. 그래서 더 나쁘다. 상대방의 발언 내용에 대해서 논리를 가지고 반박하는게 아니라, "너는 경력이 얼마 안되자나. 그러니까 네 주장은 틀렸다"는 식으로 몰고가는 것이다.

책의 내용이 공격받는 듯한 느낌이 들어서 시작하긴 했지만 순수하게 글의 내용만 가지고 토론했다면 감정 상하지 않고 적절하게 마무리할 수 있는 일이었는데 하는 아쉬움이 남는다. 스프링 포럼에서 기술적인 토론이 벌어지면 상당히 강한 공격과 반박이 오고 간다. 하지만 그 토론의 내용는 모두 객관적이고 기술적인 것이고, 개인적인 공격이나 그런 공격을 이용한 치사한 주장 같은 것은 찾아보기 힘들다. 그래서 격렬한 토론이 오고 간 뒤에도 기분 좋게 끝낼 수 있고, 또 그러는 사이에 많은 것을 배울 수도 있다. 하지만 한번 인격을 공격하기 시작하고 그것을 자기 주장의 근거로 삼으려는 시도를 하고 나면 지저분해질 수 밖에 없다. 사실 그런 유혹은 항상 있고, 사적인 대화나 술자리에서는 그런 얘기가 쉽게 오고가기도 한다. 하지만 공개된 블로그 등에서 그런 얘기를 하는 것은 차원이 다르다. 누군가는 크게 기분을 상하고 의욕을 잃을 수도 있다. 영회만 그런 실수를 하는 것은 아니다. 세계적으로 유명한 개발자나 IT계 종사자들 사이에서도 그런 일이 종종 발생한다. 얼마전에는 유명 블로거인 조엘이 밥 마틴과 켄트 벡을 영회와 비슷한 방식으로 비꼬았던 일이 있었다. 나중에 공개적으로 자신의 그런 발언에 대해 사과를 하기는 했지만, 그러는 사이에 밥 마틴은 물론이고 평소엔 잘 흥분하지 않는 켄트 벡까지도 감정이 실린 글을 썼고 댓글을 통해서 심한 이야기들이 오고가는 것을 봐야 했다. 개빈 킹은 예전에 화가나면 문장이 F로 시작하는 글을 남기기도 했다. 그래서는 건전한 기술 토론이 이어질 수가 없다.

아무튼, 그런 일로 또 몇 날을 진도도 제대로 못나가고 신경만 잔뜩 쓰면서 보내야 했다. 좋지 않은 경험을 하고 나니, 그 뒤로 책의 내용과 관련된 글이나 스프링을 공격하는 글을 봐도 그냥 무시하고 넘어가거나 아니면 혼자서 투덜대고 말아야 했다.

어쨌든, 책을 쓰는 동안 저자의 머리 속에서는 보이지 않는 치열한 전쟁이 일어나는 것 같다.

 

두 번째는 책의 주제에만 장시간 집중해야 하니 다른 기술에 호기심이 일어나도 자제해야 했던 것이다. 나는 오랫동안 프로그래밍을 취미로 해왔다. 새로운 것을 좋아하고 무엇인가 창조적인 일을 하는 것에 관심이 많은 나에게 끊임없이 새로운 기술이 쏟아져 나오고 원하는 대로 만들고 실행하고 남들이 사용하는 것을 지켜볼 수 있는 프로그래밍은 최고의 취미였다. 우연한 기회에 아르바이트로 일을 시작했다가 현장에서 일을 해야지만 만질 수 있는 대형 시스템의 매력에 빠져서 아예 직업으로 선택하게 되었지만. 일을 하는 중에 어떤 일을 할지 선택할 수 있는 기회가 주어지면 나는 항상 내가 해보지 않은 새로운 기술과 언어, 환경, 도메인에 우선순위를 두었다. 끊임없이 내 호기심을 자극해줄 수 있는 일을 찾았다. 그래서 프로젝트를 마칠 때면 고객사로부터 특채로 뽑아줄테니 직원으로 들어와서 일을 하라는 제안을 받았지만, 한 회사에서 한 가지 시스템을 몇 년씩 만져야 하는 일은 정말 지루해 보여서 도저히 받아들일 수 없었다.

그런 내가 스프링, 그것도 스프링의 기초와 핵심 기술 몇 가지에 매달려서 연구하고, 그것을 이리 저리 풀어서 설명하는 책을 쓰는 일에만 2년 가까이 집중해야 했던 것은 정말이지 고문이었다. 물론 책을 쓰면서 시간을 따로 떼서 다른 기술을 공부할 수도 있었지만, 계속 해서 밀리는 일정과 그에 따른 부담이 커지면서 책의 내용 외에 관심을 두는 것은 왠지 외도하는 느낌이 드는 데다 출판사에 미안한 마음 때문에라도 자제할 수 밖에 없었다. 블로그 글도 책에 넣으려고 공부핬는 스프링 3.0에 대한 이야기나 써야 했고. 다른 기술이나 책 내용 이외의 스프링 고급 기술에 대해선 깊이 파고 들어갈 마음의 여유를 가질 수 없다.

그런데 1,2장이 끝나고 슬슬 책을 쓰는 데 가속도가 붙기 시작하게 되니 마음에 빈틈이 생겼을까 자꾸 다른 재밌어 보이는 다른 기술에 눈이 가기 시작했다. 그래도 본격적으로 손을 대지는 못하고 있었는데, 어느날 한 출판사에서 연락이 왔다. "XXX 기술에 관한 책이 있는데 한번 번역하지 않으시겠어요?"라는 내용이었다. 내가 블로그에 그 기술에 대한 글을 몇 번 적은 적이 있는데 그것을 보고 내가 관심이 있어하지 않을까 해서 연락을 한 듯 했다. 갑자기 유혹이 몰려오기 시작했다.

일단 스프링 3.0에 맞춰서 책을 내기로 허락을 받았으니 마음에 여유가 조금 있었다. 게다가 3장 이후로는 엄청난 속도로 책이 써지는 것을 보면서 이 대로라면 3.0이 출시될 때 맞춰서 여유있게 책을 마무리 할 수 있을 것 같았다. 게다가 하루 종일, 일주일 내내 스프링 생각만 하면서 지내는게 너무나 지겨웠다. 뭔가 기분을 전환하고 다른 주제로 관심을 돌리는 시간이 필요할 듯 싶었다. 그래서 일단 긍정적인 답변을 했다.

그리고 나서 걱정이 됐다. 계약한지 2년이 넘도록 책도 마무리 못하고 있는 불량 저자 주제에 다른 책을 번역하는 것은 무책임한 짓이 아닌가 하는 생각이 들었다. 하지만 한편으로는 책을 쓰는 동안에는 다른 일을 안하겠다고 한 것도 아니고, 게다가 이미 스프링 3.0 출시에 맞춰서 책을 내기로 했으니 그 약속만 지킨다면 다른 일을 하든 책을 번역하든 괜찮지 않을까 하는 생각도 들었다. 한편으로는 포기할까 생각했지만, 그래도 자꾸 그 기술이 눈에 들어왔다. 사실 번역은 내 관심사가 아니다.  하지만 책을 번역하면 내가 관심이 있는 기술을 꼼꼼히 공부할 기회가 주어질 것 같아서 맘이 자꾸 끌렸다.

그래도 일단 김 부사장님께 말씀을 드리고 허락을 받는 것이 예의라고 생각을 했다. 그래서 연락을 해서 어렵사리 말을 꺼냈다. "번역 제의가 들어왔는데요. 제가 관심이 많은 주제라… 혹시 해도 될지.." 말이 미처 끝나기도 전에 대답이 돌아왔다. "절대 안돼요". 한마디라도 더 했다간 지난 2년간 제대로 책도 안쓰고 질질 끌던 것까지 함께해서 콤보로 혼날 것 같았다. "네".

책을 빨리 안 쓴 내가 잘못이지. 결국 그 출판사에는 개인 사정으로 번역은 못하겠다고 얘기했다. 그리고 더 열심히 더 빨리 스프링 책을 마무리 해야 겠다고 결심했다. 그 뒤로 무서운 속도로 책을 써나가기 시작했다. 그리고 1부의 내용이 제법 마무리 되가던 가을에 한국을 방문하게 됐다. 2부는 별로 걱정이 안됐다. 2부는 레퍼런스 식으로 각 기술의 사용방법과 기술선택에 관한 내용을 적으면 되기 때문에 별로 고민할게 없었다. 그동안 준비해놨던 방대한 양의 학습테스트 코드와 스프링의 깔끔한 API 문서, 레퍼런스 문서 등을 참고하면 1부보다 3배는 빠르게 쓸 자신이 있었다. 그러니 1부의 내용이 어느 정도 정리가 되가자 슬슬 눈을 딴데 돌리기 시작했다.

장인어른 팔순 때문에 평화와 아내와 함께 한국을 방문하기로 하고 준비하고 있던 어느날 또 다른 출판사에서 연락이 왔다. 역시 번역제안이었다. 기존에 내가 하고 싶었던 기술과 갈은 것이지만 다른 책이었다. 처음 제안받은 책은 바이블 성격의 두툼한 책이지만 두 번째 제안받은 책은 양도 작고 내용도 가벼운 입문자용 책이었다. 문장도 쉽고 코드도 많았다. 스프링을 잠시라도 벗어나야 숨이 트일 것 같은 기분으로 살고 있었기 때문이었을까. 덜컥 하겠다고 말해버렸다. 당시 스프링 3.0은 연말이나 되야 나올 스케줄로 진행되고 있었고 책은 그 때까지 충분히 마무리할 수 있을 것 같았다. 800페이지 짜리 책을 쓰기로 했는데 이미 500페이지가 넘었고, 2부는 더 쉽게 쓸 수 있을 것이라고 생각했으니까. 어쨌든 책을 먼저 마무리 하고 번역은 슬슬 진행하다가 스프링 책 원고를 넘기고 나서 집중적으로 하면 2010년 봄 쯤에 마무리 할 수 있을 것 같았다. 하루에 5페이지 정도만 한다면 2시간 정도 시간을 내면 될 듯 했고. 그 정도라면 평소에 책을 쓰다가 머리를 식히려고 보내는 시간 정도만 할애해도 충분할 듯 싶었다.

문제는 무서운 김 부사장님께 말씀드리는 것인데. 분명 몇달전에 안된다고 하셨는데 또 하겠다고 나오면 완전 반항으로 비칠듯 싶었다. 그래서 이를 어째야 하나 계속 걱정을 하면서 지내다가 한국을 방문하게 되었다.

가족과 함께 시간을 보내고 나서 돌아가기전에 김희정 부사장님을 만나기로 약속을 잡았다. 참석 가능한 KSUG 멤버들 몇 명도 자리를 함께 하기로 했다. 장소는 교보빌딩 1층의 모 식당에서 저녁 7시.

그런데 우연이겠지만 그날 같은 장소에서 몇 시간 전에 번역을 하기로 한 책을 낼 출판사 이사님과도 만나기로 했다. 그 장소가 출판인들에게 인기있는 장소였을까. 아무튼 그날 만남은 번역 계약서를 작성하는 자리였다. 일단 저술하는 책이 있으니 당분간은 그 책에 전념을 해야겠지만, 서서히 진행하다가 스프링 책이 완료되면 빠르게 마무리 하겠다고 말씀드렸다. 그 때까지 김 부사장님과 에이콘 직원분들 외에 내가 만났던 출판사 관계자는 I 출판사 사장님이 전부였다. 그런데 출판사 분들은 다들 왜 그리 친절하고 이해심 많고 저자나 역자를 끔찍히 배려해주는 데다 상냥하기도 한지. 그날 만난 이사님도 정말 천사같았다. 그러니 내가 거절을 못했을지도.

번역 계약을 마친후 서점에서 조금 시간을 보내다 저녁때 김희정 부사장님과 영회, 세원님 그리고 성철이 형을 만났다. 하필이면 앉은 자리도 오후에 번역 계약을 하러 다른 출판사 분을 만났을 때 앉았던 같은 자리였다. 김 부사장님을 만나면 번역 하기로 했다는 얘기를 꺼내야겠다고 마음을 먹긴 했는데 막상만나고 나니 말이 목에 걸려서 도저히 나오지가 않았다. 그날 내가 가장 많이 한 말은 그냥 "네".

게다가 그 날은 김희정 부사장님이 내 책에 대해서 이런 저런 주문을 많이 하셨다. 책의 분량은 800페이지 정도로 하기로 이미 여러번 합의를 보았지만 1부 내용이 조금 길어지는 것을 느끼면서 그보다 조금 더 늘어날 것 같은 느낌이 들었다. 김 부사장님은 만날 때마다 책 분량에 대해서 다시 확인하신다. 맨날 까먹으시는 것인지 아니면 저자가 욕심을 내서 분량을 늘릴까바 걱정되서 그러시는 것인지는 모르겠지만. 아무튼 그날 내가 "800정도 쓰려고 하는데요.. 근데.."라고 말이 꺼냈더니, "설마 800페이지 이상 쓰실려는 것은 아니죠?"라는 날카로운 목소리의 답변이 돌아왔다. 평소의 친절하고 상냥한 목소리와 톤이 일단 다른 데다 눈꼬리가 살짝 올라갔음을 눈치채고 나능 황급히 "물론 800이에요"라고 대답할 수 밖에. 뭔가 눈치를 채셨는지 "책을 쓸 때 뭘 넣을지가 중요한게 아니라 뭘 뺄지가 중요해요"라는 설명이 다시 이어졌다. 괜한 욕심부리지 말고 얼릉 마무리 하라는 얘기로 들렸다. 까짓거 일단 써보다가 800 페이지가 넘으면 일부 내용을 빼서 PDF로 만들어 따로 공개하면 되겠지라고 생각하면서 일단 그렇게 마무리.

평소와 다르게 그날은 실제적인 저술 방법에 대한 주의사항이 이어졌다. 대부분 내가 안지키고 있던 것들이었다. –_-;;;

"혹시 각주 넣으셨어요?". 물론 넣었다. 간단한 용어 설명이나 참고 정보는 각주로 뽑았다. 왠지 있어보이니까. 하지만 넣었다고 하면 혼날 것 같았다. 뻥을 쳤다. "아..니요…". 별 다른 설명이 뒤따르지 않았던 것으로 봐서는 그래야만 했던 것 같다. 이왕이면 저술을 시작할 때 그런 주의사항이나 가이드라인을 미리 주셨으면 좋았을텐데라는 아쉬움이 있었지만, 뭐 어쩌겠는가. 다시 호주에 돌아오자마다 각주는 모두 본문에 삽입하거나 박스에 넣어서 정리했고 새롭게 받은 가이드라인에 따라서 기존에 쓴 내용을 정리하느라 다시 며칠을 보내야 했다.

아무튼 처음으로 저술 방식과 형식 등에 대해서 한참 교육을 받고 나니 긴장이 더 됐는지, 결국 그날은 번역에 대한 얘기를 꺼낼 용기를 내지 못했다. 뻔뻔한 영회 같으면 그냥 얘기하고 말았을텐데.

 

내일 다시 적겠지만 그때 예상은 다 틀렸다. 스프링은 그해 12월에 나왔지만 내 원고는 올해 3월에야 겨우 마무리 했고, 생각보다 긴 교정시간을 거쳐서 5월에서야 겨우 초고를 넘길 수 있었다. 번역은 상당히 재밌는 경험이었고 책을 쓰는 것에 비하면 스트레스도 훨씬 적었다. 기대했던 대로 스프링과 완전히 다른 성격의 기술을 살펴보는 것은 머리를 식히는 데 최고였다. 물론 스프링 책에 우선순위를 두기로 한 결정은 그대로 지키려고 했고. 그래서 스프링 책의 마무리가 늘어지면서 번역작업도 같이 지연되었다. 결국 번역을 마무리 하고 초고를 보낸 것은 지난 7월이었다.

물론 김희정 부사장님께는 뒤늦게 다 실토했다. 한번 혼나고. 흑.

 

그 뒤의 이야기는 내일 계속.

두세 편이면 충분했을 것이라고 생각했는데 벌써 여덟 번째 이야기.

사실 그동안 내 이야기에 나온 사람들은 모두 내가 좋아하는 사람들이다. 책을 쓰는 동안에 나에게 나쁜 짓을 하거나 안좋은 영향을 준 사람들도 있지만 당연히 그런 사람들에 관한 얘기는 적고 싶지 않다. 그래서 여기에 언급된 사람들은 모두 내가 아끼는 사람들이고 여러모로 고맙게 생각하는 사람들 뿐이다. 어떤 상황에서도 프로의 모습을 잃지 않으시며 역자와 저자에 대해 미스테리한 마력을 가진 김희정 부사장님과 멋쟁이 김창제 수석님을 제외하면 나를 포함한 나머지 사람들은 모두 나사가 한두 개쯤 풀려있긴 하지만, 그래도 다들 마음이 따듯하고 알고보면 착한 사람들이다.

그동안 영회는 줄곳 나를 괴롭히는 악당으로 등장했지만, 그건 저술기간 동안 얼마나 힘들었는지를 설명하기 위해서 그런 사건(물론 100% 실제 있었던 일들이다)만 골라 넣었기 때문이지 사실 영회가 항상 나를 괴롭히기를 즐기는 나쁜 사람이기 때문은 절대 아니다. 이참에 실추된 영회의 이미지를 회복시켜주기 위해서 잘 알려지지 않은 영회의 선행을 하나 공개하겠다.

내가 다녀왔던 연변과기대 내의 IT교육원에는 종종 한국의 IT전문가들이 학생들을 위한 특강차 방문하곤 했다. 나도 프로젝트 교육 이전에 한번 특강을 위해서 방문한 적도 있고. 그래서 그 후로 여러 사람들에게 특강을 위해서, 또 새로운 자극과 휴식을 위해서 한번 쯤 연변을 방문하기를 권유해왔다. 보통 일주일 정도 방문을 하면 IT교육원 학생들을 위한 특강 시간을 한번 가지고 기회가 되면 학부 학생들이나 선생님, 교수님들을 위한 세미나를 열기도 한다. 대신 IT교육원은 영리를 목적으로 운영되는 기관이 아니기 때문에 모든 방문자들은 항공권을 포함해서 모든 경비를 스스로 지불해야 한다. 특강을 마치고 학생들과 식사를 할 때도 식사 비용을 방문자가 내는 것이 관례이다. 대신 IT교육원 선생님들이 시간을 내서 도문이나 용정 같은 곳에 데려가 관광시켜 주기도 하고, 현지의 독특한 음식을 맛볼 기회도 제공해준다. 무엇보다도 순수한 마음을 가진 학생들에게 특강을 통해서 무엇을 준비하고 어떻게 살아야할지 이야기 해줄 수 있는 기회를 가진다는 것이 가장 보람있는 일이다.

하지만 이런 얘기를 해줘도 대부분은 시간과 비용에 부담을 느껴서 선듯 가겠다고 나서지 못했다. 일년에 겨우 일주일 정도 휴가를 가지는 것도 쉽지 않은 빡빡한 환경에서 그 시간을 모두 들여서 특강을 위해 외국을 다녀오는 것은 쉬운 일이 아니다. 그런데, 그 얘기를 영회한테 했을 때 영회는 주저 없이 가보겠다고 했다. 마침 영회가 참여했던 큰 프로젝트가 하나 끝나고 프로젝트 포상 휴가가 기다리고 있을 때였다. 영회는 그 시간을 사용해서 연변을 방문하기로 했다. 기꺼이 자신의 시간을 기꺼이 들여서 처음 만나는 학생과 강사들에게 좋은 지식과 경험을 나누고 보람있는 시간을 보내고 돌아왔다. 그때 이야기는 영회 블로그(http://younghoe.info/937)에서 읽을 수 있다.

그런데 정작 내가 감동한 것은 그 후의 일이다. 영회가 특강을 했던 교육원 4기 학생들이 교육을 마치고 수료할 때가 되었다. 보통 졸업식 직전에 1박2일로 MT를 간다. MT 프로그램 중에 항상 빠지지 않는 것은 한국에 있는 IT전문가들의 만들어서 보내준 영상 축하 메시지를 보는 시간이었다. IT교육원을 설립하고 운영하는 데 가장 중요한 역할을 한, MSSQL의 대가인 원혁이 형이 주로 축하 메시지를 보내주는 단골이다. 그런데 4기 졸업 때는 영회도 자진해서 축하 메시지 영상을 만들어서 보냈다는 얘기가 들려왔다. 담당자를 이리 저리 꼬셔서 어렵사리 얻어낸 그 동영상은 지금 다시 봐도 참 감동적이다. 평소에 보이는 잘난척 하는 듯한 말투와 까칠한 눈빛은 보이지 않고 순박하고 착한 형이 동생들에게 해주는 듯한 따듯한 메시지가 담여있다. 특히 꾸미지 않은 쌩얼과 평소에는 잘 쓰지 않는 두툼한 안경을 쓴 모습이 일품이다. 이 영상만 봐도 영회가 얼마나 따듯한 마음씨를 가졌는지 알 수 있을 것이다.

하지만 겸손한 영회는 자신의 선행이 알려지는 것을 극도로 꺼려해서 그 동안 이 영상을 공개적으로 공유할 수 없었다. 하지만 아쉬움은 이제 그만. 가끔 영회가 술 마시고 들어와서 생각없이 블로그 글을 남겼다가 욕을 먹었던 일이나, N모씨에 의해서 한국의 3대 돌팔이라고 비난당해왔던 일 등을 생각하면 이쯤에서 잘못 알려진 이미지를 회복하는 것이 좋겠다고 생각된다. 그래서 쑥스러워 하는 영회의 만류에도 불구하고 그 영상을 내 블로그에 처음으로 공개한다. 이런 영상은 포털 메인에 올라가야 마땅한 건데… 다들 각자 블로그에 퍼가도 좋겠다.

 

영회의 명예회복을 시켜줬으니 다시 내 책 얘기로 돌아가자.

김희정 부사장님을 만나서 3.0으로 책을 내도 좋다는 허락을 받은 뒤 스프링원 아메리카 2008의 참석을 위해서 영회, 케누형, 기선이 등과 함께 미국으로 향했다. 나는 스프링소스의 컨퍼런스에 네번째로 참석하는 것이었다. 첫 번째 참석과 비교해 보면 한국, 중국, 일본 등지에서 온 아시아 개발자들의 참여가 늘었다는 것이 가장 인상적이었다. 2006년에는 아시아에서 참석한 사람은 나와 일본 NTT시스템즈에서 온 이시모로가 전부였는데 불과 2년 만에 D사와 S사에서 온 여러 명의 개발자들, 그리고 개인비용을 들여서 온 영회나 광남이 형 등을 포함해서 10명이 넘는 한국인들이 참여한 것을 보니 그동안 한국에서 스프링의 인기와 위상이 얼마나 높여졌는지 실감할 수 있었다.

컨퍼런스를 마치고 알라바마의 고객사에 일주일 방문해서 시스템을 점검해주고 다시 호주로 돌아왔다. 그리고 컨퍼런스에 맞춰서 공개된 스프링 3.0의 첫 번째 릴리스인 3.0 M1을 이용해서 1장의 내용을 열심히 마무리해나갔다. 기존에 JavaConfig이라는 이름으로 2년여간 질질 끌어오던 프로젝트가 스프링 3.0에서 코어 프레임워크로 통합되었다. 자바 코드를 이용한 설정 메타정보를 작성하는 기법은 내가 1장에서 추구해온 자바 코드에 의한 평범한 DI를 스프링을 이용한 프레임워크 기반의 DI로 옮기는 데 아주 좋은 연결고리가 되어주었다. 1장의 포인트는 바로 그것을 이해하는 데 있다.

1장을 끝내고 나니 자신감이 붙었다. 일단 코드를 손에 쥐니 그것을 이리 저리 만져가면서 그 과정을 옆자리에 있는 후배에게 설명하듯이 얘기를 풀어나갈 수 있었다. 보통 기술을 설명할 때 나는 먼저 간단한 그림을 종이에 그려가면서 코드의 구조와 동작하는 순서를 설명하는 습관이 있는데, 그런 내용이 필요하다 싶을 때마다 꼬박꼬박 다이어그램을 그렸다. 처음엔 UML 툴 같은 모델링 툴을 사용할까 했는데, 나중에 이미지로 옮겨와 붙이는 것도 귀찮고, 내가 자유롭게 그림을 그리고 싶을 때 불편할 듯 싶어서 손이 많이 가고 시간은 더 들지만 워드의 그림툴을 사용해서 모든 다이어그램을 만들었다.

1장은 그 뒤로 가장 많이 다시 손을 봤지만 지금까지도 제일 아쉬움이 남는 장이다. 가장 중요하지만, 가장 쉽게 써야 했고, 가장 많은 용어가 갑자기 튀어나와서 이를 수습해야 했고, 가장 많은 코드의 변화가 있는 장이다. 사실 1장은 스프링을 통해서 만들어지는 코드가 어떤 것이라는 기본을 소개하는 장이고, 2장부터 7장까지는 1장에서 소개한 내용을 다시 다양한 엔터프라이즈 기술 영역에서 응용하는 방법을 보여주는 것이다. 사실 그게 스프링의 전부이고, 그것만 잘 알면 스프링의 기술을 빠르고 쉽게 이해할 수 있다. 그래서 가장 많은 정성을 쏟기도 했고, 가장 많이 뜯어고쳐야 했다.

2장은 1장에서 main() 메소드로 만들었던 원시적인 테스트를 JUnit을 이용해서 전환하면서 자동화된 테스트의 필요성을 설명하고 테스트 코드를 작성하는데 필요한 기초적인 지식을 다루었다. 2장은 1장에 비해선 부담없이 쓸 수 있었다. 2장까지 모두 마무리하고 나니 2009년도 절반 가까이 흘렀다.

먹고 살아야 하니 그 사이 크고 작은 일도 맡아서 해야 했다. 그래서 예상했던 것보다 시간이 많이 소요됐다. 그래도 급하게 다음 장으로 넘어가지 않고 책을 쓰는 기본 틀을 다지는 데 많은 시간을 들이는 것이 낫다고 생각했다. 이야기를 풀어나가고 그에 맞게 코드와 다이어그램 등을 넣는 방법에 익숙해지고 나니 그다음 부터는 속도가  빨라졌다. 3장은 1장의 2/3쯤 되는 적지 않은 분량인데도 단 8일만에 완료했다. 정말 흐름을 타고 술술 써내려져가는 느낌을 받았다. 상대적으로 양이 적은 4장은 단 4일만에 끝냈다. 마틴 파울러와 로드 존슨이 트위터에서 책을 쓰다가 어느 순간 흐름을 타는 것을 느낄 때가 있다고 얘기한 적이 있는데 그때가 바로 그런 느낌이었다. 5장도 적지 않은 분량임에도 11일만에 끝냈다. 6장은 1부에서 가장 양이 많은 장이고 가장 난이도가 높다. 지금까지 누구도 하지 않았던 새로운 방법으로 난해한 AOP를 설명하려고 노력했다. 그러다 보니 등장한 코드(리스트) 갯수만 100개이고 다이어그램도 25개나 됐다. 보통 코드를 만들고 다듬는 시간이 절반, 그리고 그 코드를 다시 처음부터 풀어가면서 글로 남기는 시간이 절반 정도 들었다. 6장에 사용할 코드를 만들고 다듬은 후에 그 내용을 써내려갈 때는 정말 쏟아져 나오는 생각과 말을 정신없이 타이핑한다는 느낌이 들 정도였다. 그렇게 150페이지 분량의 내용을 준비하고 작성 완료하는데 한달이 채 걸리지 않았다.

그러는 사이 사촌동생의 소개로 작지만 매우 급한 개발 프로젝트 하나를 맡게 됐다. 그 프로젝트를 진행하는 한달 가까이는 책에 손을 대지 못했다. 그런데 프로젝트를 하느라 종일 코딩과 테스트에 매달려야 했지만 그 사이 내 머리 속에선 그 다음에 풀어갈 내용들이 계속 흘러다녔다. 완전히 흐름을 탄 느낌이었다.

그 사이 평화는 처음으로 어린이집에 다니게 되었고, 아내는 호주를 떠나면서 중단했던 대학원을 마저 다니기로 했다. 아내가 학교를 가는 날은 평화를 돌보고 어린이집에 데려다 주고 오고, 돌보는 일이 모두 내 책임이었다. 어린이집을 가지 않는 날은 온 종일 집에 있는 평화를 상대해야 했다. 가장 힘든 일은 밥을 먹이는 것과 낮잠을 재우는 것. 평화는 먹는데 취미가 없다. 게다가 입맛이 까다로워서 주는 대로 먹지 않는다. 보통 2-3가지 음식을 준비해서 시도해야 겨우 한가지 먹을까 말까.  음식을 들이밀어도 아예 입도 대지 않으려는 때가 더 많았다. 평화를 키우면서 들어가는 수고의 70%쯤은 밥을 먹이는데 들어갔다. 까다로운 입맛에 맞춰서 음식을 준비해야 하고, 한번 시도해서 안되면 다시 다른 음식을 준비해야 했다. 아무거나 주면 잘 먹고 자기가 먼저 밥 달라고 한다는 애들 얘기를 들으면 그렇게 부러울 수가 없었다. 물론 평화가 더 어렸을 때는 주는 대로 잘 받아먹었고, 우리도 음식을 골고루 먹이려고 제법 많은 노력을 들였다. 인스턴스나 미리 준비된 음식은 거의 먹이지 않고 다양한 재료를 골고루 먹게 하려고 노력했다. 하지만 입맛 까다로운 나를 닮은 평화는 자기가 음식을 거부할 수 있음을 알게되면서부터는 쉽게 입을 열지 않았다. 게다가 자기 그릇에 놓인 음식이 맘에 안드는데 자꾸 먹으라고 채근하면 짜증이나서 음식이나 그릇을 던져버리는 일도 있었다. 그때마다 혼을 내고 타일러봐도 별 소용이 없었다. 그렇게 하루 하루가 전쟁이었다. 잠을 재우는 것도 쉽지 않았다. 낮잠을 제대로 못자면 저녁 때 힘들어하고 짜증을 많이 내기 때문에 낮잠을 꼭 재워야 하는데, 이게 타이밍을 놓치면 쉽지 않다. 정 안되면 차를 태우고 한 바퀴 돌면서 재우기도 했는데 어떨 때는 한시간 넘게 운전을 해도 잠이 들지 안을 때도 있었다.

아내가 학교 가는 날은 그렇게 평화랑 종일 씨름하다가 조금씩 틈이 날 때 잽싸게 책을 쓰거나 일을 해야 했다. 어떨 땐 짜증을 참지 못하고 한바탕 혼을 낸 뒤에 펑펑 우는 평화를 붙잡고 달래며 시간을 보내야 했다. 태어나서 처음으로 엄마랑 떨어져 지내는 시간이 쉽지 않았을 텐데, 게다가 어린이집이라고 일주일에 이틀씩 보내는 곳은 집에서 듣던 것과 전혀 다른 언어로 이야기 하는 선생님과 친구들 뿐. 이런 저런 스트레스가 대단했을 텐데 그것을 다 받아주지 못하고 종종 화를 냈던 것이 지금도 미안하다.

책을 쓰면서 가장 힘들었던 순간은 평화가 방문을 열고 와서 자기와 놀아달라고 내 손을 잡아 끄는데 그것을 거절해야 했을 때다. 어떨 땐 방문을 잠궈보기도 했는데, 그러면 방문 앞에서 문을 두드리면서 ‘아빠’라고 수십번씩 목놓아 부르기도 한다. 아빠가 필요한데 자기랑 놀아주지 않고 손을 밀어내며 키보드만 두드리는 아빠가 얼마나 원망스러웠을까.

아무튼 그렇게 쉽지 않은 환경에서 꾸역꾸역 원고를 채워나가던 중에 한국을 다시 방문할 기회가 생겼다. 이번엔 일이나 컨퍼런스 때문이 아니라 장인어른 팔순 잔치 때문이었다. 사실 잔치는 장인께서 원치 않아서 따로 하지는 않았지만, 팔순인 만큼 온 가족이 다 모이기를 강력히 희망하셔서 미국에 사는 큰 처형과 호주에 있는 우리 가족을 포함해서 온 가족이 모이는 시간을 가졌다.

 

오늘은 오랜만에 비가 와서 그런지 날씨도 꿀꿀하고 기분도 왠지 울적해서 글도 잘 안써진다. 오늘 얘기는 여기서 대충 줄이고 내일 다시 더 써야겠다. 그래도 이제 끝이 보인다.

영회가 생각없이 던진 돌에 정통으로 맞아 쓰러지고 나서 시간이 조금 흐르니 오히려 마음이 편해졌다. 어짜피 내가 아무리 용을 쓰고 책을 잘 써봤자 영회같은 인간들이 분명히 나타나서 이런 저런 시비를 걸 것이 분명했다. 어짜피 어떻게 해도 욕먹을 거라면 그냥 내가 쓰고 싶은 대로, 내가 하고 싶은 얘기를 하면 되겠다고 생각하니 그때까지 가졌던 긴장감이 다 풀렸다. 잔뜩 주고 있던 힘이 빠지고 나니 오히려 그 다음은 쉬웠다.

날려버린 1장을 처음 쓸 때 사실 힘들었다. 그 1장에는 코드 한줄 나오지 않는다. 대신 3만피트 상공으로 올라가서 스프링 세계를 내려다보며 스프링이 이렇게 생겼네라고 구름 위에서 얘기하듯이 설명하는 내용이다. 그래서 신경쓸 것은 단어, 표현 등이었다. 함축적인 단어를 어떻게든 잘 골라서 이런 저런 스프링의 특징을 깔끔하게 묘사해야 할텐데라는 고민으로 대부분의 시간을 보냈다.

나는 그런 식의 얘기가 편하지 않다. 내가 가장 편한 시간은 코드를 앞에 놓고 코드에 대해서 이야기 할 때다. 열 줄 정도의 코드만 있어도 재미나게 한 시간쯤은 수다를 떨 수 있다. 지난 27년간 거의 매일 만들고 다듬고 뜯어보고 감상해왔던 것이 코드다. 그래서 누군가에게 기술을 설명해줄 때도 코드를 놓고 이야기해야 편하다. 특히 어설픈 코드를 만들어 놓고 그것을 다듬고 발전시켜서 아름다운 코드로 만들어내는 과정을 즐기는 것이 좋다.

그래서 다시 1장을 쓰면서 가장 먼저 코드 하나를 들이 밀었다. 초난감 DAO. 왜 하필 DAO로 시작했을까? 사실 1장은 스프링의 DI를 설명하려고 쓴 것이다. 보통 스프링 서적이나 교육시간에는 다형성이 적용가능한 도메인 모델을 가져다가(예를 들면 찬욱이가 잘 쓰는 피자 주문 어쩌고 같은) XML로 설정을 바꿔가며 DI하는 모습을 보여주는 것이 일반적이다. 하지만 나는 그런 현장감이 없는 코드가 싫었다. 개발자라면, 심지어 이제 막 자바 교육과정을 마친 초보 개발자라도 쉽게 이해할 수 있는 익숙한 코드를 가지고 설명하고 싶었다. 그래서 선택한 것이 가장 간단하고 단순한 DAO 코드이다. DAO 코드만 가지고도 DI를 설명하기에 충분하다.

 

나는 이미 이전에 간단한 DAO 코드를 가지고 스프링의 DI를 설명해본 경험이 있다. 2007년 (북반구) 여름에 연변자치주 내의 연길시에 있는 연변과학기술대학(YUST)에 방문한 적이 있다. 그냥 방문이 아니고, YUST의 IT교육센터에 초빙강사쯤으로 간 것이다. 거기서 2주정도 체류하면서 조선족 대학졸업자를 대상으로 진행하던 4개월간의 합숙 교육과정의 마지막 단계인 프로젝트 실습시간을 맡아서 자바의 기초를 이제 막 배운 학생들과 함께 교육과정을 마무리 하는 프로젝트 교육을 진행했다. 당시 교육과장에 참여했던 20여명의 학생 중에서 소수만이 북경에 있는 SI업체에 취업이 확정된 상태이고 다른 학생들은 아직 일자리를 찾지 못하고 있어서 기운을 잃고 있던 상황이었다.

YUST의 IT교육센터는 YUST가 그렇듯이 조선족 젊은이들에게 양질의 교육 프로그램을 제공해서 중국 사회, 나가서는 세계적으로 실력있는 전문가를 만들어내려는 목적으로 2007년 초에 설립되었다. 매일 새벽 운동으로 시작해서 밤 12시까지 교육과 실습 시간을 가지고 학교내의 기숙사에 머물면서 강도 높은 교육을 진행한다. 이 교육센터를 설립하고 강사로 일하는 분들은 모두 자원봉사자들이다. 다들 한국에서 이름을 날리던 IT전문가, 유명 강사들인데 자신의 삶에서 몇 년의 시간을 떼어서 자원의 제약이 많은 지역에 살고 있는 사람들에게 지식을 나누고 꿈을 심어주기 위해서 아무런 댓가도 없이 이국땅에 모인 존경스러운 분들이다.

아무튼 거기서 보낸 2주간의 시간은 참 행복했다. 학생 대부분은 IT전공자가 아니다. 심지어 영어를 전혀 못하는 사람도 있었다. 연변자치주 내의 조선족 학교에 다녔던 학생들은 중고등학교 시절에 영어가 필수 과목이 아니었다고 한다. 보통 일본어를 더 많이 공부했고, 대학에 진학해서야 교양과목 수준으로 영어를 배운 사람들이 많다. 그래서 일부는 대졸자임에도 알파벳에도 익숙하지 못한 사람들이 있었다. 그래서 알파벳과 영어단어를 읽는 것부터 가르쳐야 했다.

이 교육센터의 특징은 24시간 선생님과 학생들이 함께 하는 것이다. 물론 가족이 있는 선생님은 학교 주변의 숙소에 머물긴 하지만, 정규 교육시간이 끝나고 집에 가서 저녁 식사를 하고 야간 실습시간이 되면 다시 학교로 올라와 12시, 심지어는 새벽까지 그날 공부한 내용을 학생들이 실습해보면서 막히는 것이 있으면 옆에 붙어서 가르쳐 주고, 개인적인 상담도 해주기도 했다. 일부 학생들는 ABC부터 공부해가면서 그렇게 열심히 자바를 배웠다. 그 와중에 SCJP시험도 공부해서 대부분 SCJP도 딴 상태였다(학생들을 받아주기로 한 업체의 요구사항의 하나였다고 한다). 하지만 막상 내가 프로젝트 수업을 어떻게 진행할까 고민하면서 그동안 공부한 내용을 살펴봤을 때는 참 막막했다. 자바 언어와 JDBC, DB(SQL), HTML/자바스크립트, 서블릿, JSP 모델1 정도를 배운 것이 전부였다. 사실 맨땅에서 그만큼이라도 공부한 것은 대단했다. 나름 공부한 내용은 끊임없이 실습하고, 반복해서 학습했기 때문에 익숙했다.

4개 조를 나눠서 주어진 요구사항을 충족하는 웹 애플리케이션을 만들도록 했다. 스프링 따위는 사용할 엄두도 낼 수 없었고, 내가 하루 밤 사이에 급조해서 만든 초간단 MVC 프레임워크를 사용해서 모델2로 만들도록 했다. 매일 새벽 1시에 건물을 관리하는 분이 나가라고 찾아올 때까지 함께 코드를 만들어가면서 그렇게 열흘 정도를 보내고, 기대 이상의 멋진 결과물을 만들어서 YUST 전산과 교수님들을 모아 놓고 발표회를 가질 수 있었다. 내가 일했던 회사의 개발자들에 비하면 다들 형편없는 수준의 초보자였지만, 하나도 놓치지 않고 배우고자 하는 열정과 끈기가 대단했고, 교육해주는 강사에 대한 고마운 마음과 존경심이 대단했다. 참 행복한 시간이었다. 처음엔 취업이 되지 않아서 실망하고 열정도 잃었던 학생들이 코드를 만들어나가면서 동작하는 애플리케이션을 보고 환호하고 서서히 자신감을 찾아나가고 미래에 개발자로서 살아갈 꿈을 꾸는 모습을 보는 것이 즐거웠다.

다행히 대부분의 학생들은 북경과 상해의 여러 업체에 취업이 되었고, 일부 학생들은 한국 SI업체의 북경지사에 취직해서 프로젝트 하러 한국에 다녀가기도 했다.

그런데, 기껏해야 내가 만든 간단한 MVC 프레임워크(URL 컨트롤러 매핑은 프로퍼티 파일을 사용하게 했다)와 원시적인 JDBC API로 만들어진 DAO를 이용하는 코드를 만들어본 경험이 전부인 초보자들인데, 일부 SI업체들은 전혀 교육도 시켜주지 않은 채로 스프링을 써야하는 프로젝트에 마구 투입했다. 내 생각에는 아마 프로젝트에 비용을 맞추기 위해서 신입들을 머리수 채우는 용도로 넣은 것이 아닌가 싶다. 아무튼 그렇게 여러 사람들이 스프링 개발을 해야 하는데 막막해 하고 있다는 얘기를 전해 들으니 가슴이 아팠다. 그렇다고 내가 뭔가 뾰족하게 도와줄 방법도 없었다. 그저 책과 자료를 알려주고 차근차근 공부하라고 할 수 밖에. 하지만 내가 아는 스프링 책들과 인터넷의 자료들은 그저 자바기초와 JDBC, JSP 정도를 아는 경험없는 초보 개발자들이 쉽게 독학으로 스프링을 익힐 수 있는 것들이 아니었다.

그러던 즈음에 IT교육센터에 보조강사로 남은 졸업생의 한 명인 향화가 스프링을 알려달라고 연락이 왔다. 향화는 YUST를 졸업하고 유학을 준비하던 즈음에 강사로 간 분의 꼬임에 넘어가 IT교육센터에 입학했다. 내가 가르쳐본 경험으로는 가장 우수한 학생이었다. 한족이지만 한국어를 제법 잘해서 교육을 함께 받았던 소강이와 함께 가장 학습능력이 뛰어나고 프로그래밍 실력이 좋은 학생이었다. 그래서 마음만 먹으면 얼마든지 원하는 회사에 갈 수 있었지만, 자기는 연길에 남아서 후배들을 가르치는 일을 하고 싶다고 취업을 포기하고 보조강사로 IT교육센터에 남은 기특한 아이였다. 막상 보조강사는 하고 있지만 교육센터의 프로그램은 IT 기초소양교육과 자바 프로그래밍 기초였기 때문에 스프링과 같은 고급 기술을 배울 기회가 없었다. 그런데 막상 현장에 나가서 일을 하는 졸업생들은 스프링은 어디가나 다 쓰기 때문에 꼭 배워야 한다는 얘기를 전해오고 있었으니, 자신도 스프링을 좀 준비해둘 필요가 있다고 생각한 것이다.

내가 놀랐던 사실 하나는 2007년 여름에 중국 아마존 사이트에 등록 되어있는 스프링 2.0 서적이 무려 20권이나 있다는 사실이었다. 한국에는 2.0책이라곤 SiA 2판이 겨우 나왔을 때였는데 말이다. 그만큼 중국에서는 스프링을 많이 사용한다. 뭐, 일본도 그렇고 전세계가 다 그렇지만. 아무튼 한국과 비교했을 때 당시 중국의 스프링 도입률이 훨씬 높았다.

아무튼, 당시 나는 서울에서 일을 하고 있었고 향화는 중국 연길에 있었다. 교육을 해준다고 해도 기껏해야 스카이프와 메신저가 전부였다. 그나마 코드는 SVN을 이용해서 서로 공유해서 볼 수 있었지만. 향화는 공대출신이기는 하지만 IT전공자가 아니었으니, 자바 지식이라곤 교육센터에서 4개월 배운 것이 전부였다. 따라서 자바 언어 기초, JDBC/DAO, 서블릿/JSP 정도는 확실하게 알고 다룰 수 있는 실력이지만 그 외의 프레임워크니 기술은 전혀 사용해본 경험이 없었다.

그래서 향화에게 어떻게 스프링을 가르쳐 줄까 고민하다가 생각한 것이 그나마 향화가 가장 익숙하고 많이 만들어본 DAO였다. 초보 개발자들이 교육센터 등에서 만드는 DAO 수준은 뭐 뻔하다. try/catch/finally라도 적용했으면 다행이고, 그렇지 않은 경우도 많았다. JDBC API를 사용해서 돌아만 가는 CRUD만 만들 수 있어도 잘하는 것이었으니까. 물론 향화는 내가 교육하면서 try/catch/finally나 안전한 DAO를 만드는 방법에 대해서 확실하게 교육했으니 잘 알고 있었지만.

그래서 향화가 그나마 잘 아는 DAO 코드를 하나 만들어줬다. 그리고 그 코드의 문제점이 무엇인지 찾아보고 그 코드를 매일 매일 조금씩 개선하면서 OO적인 코드로 다듬는 것을 알려줬다. 그렇게 짬짬이 원격 교육을 하면서 서서히 DAO코드를 다듬어서 DataSource에 대한 DI도 적용하고 템플릿/콜백도 만들어가는 식으로 설명을 해줬다. 그냥 XML 설정파일 만들고 DAO와 DataSoruce 빈을 등록하고, CRUD는 JdbcTemplate가져다 쓰고, web.xml에 컨텍스트로더리스너 등록해서 돌리라고 가르쳤으면 일주일이면 충분했을 것을 몇 달에 걸쳐서 설명을 해줬다. 하지만 그렇게 스프링을 이해하고 배우는 것이 나중에 내가 더 이상 스프링을 가르쳐 주지 못하고 혼자서 공부할 때 분명 도움이 될 것이라는 확신이 있었다. 결국 나중에 나는 너무 바빠서 교육은 기선이에게도 부탁했다. 교육센터의 보조강사는 기숙사에서 함께 생활하면서 24시간 학생과 함께 지내야 한다. 특히 실습과 시험준비 등으로 새벽까지 남아서 공부하는 학생이 있으면 끝까지 옆에 붙어서 도와줘야 한다. 그래서 나중에는 너무 바빠서 더 이상 충분히 공부할 시간이 없어서 스프링 공부는 흐지부지 끝나고 말았다.

 

다시 1장을 쓰기로 마음먹고 무엇인가 코드를 일단 던져 놓고 시작을 해야겠다라고 생각했을 때 향화에게 스프링을 가르쳐 주던 생각이 났다. 그때 사용했던 DAO코드를 개선해 나가면서 스프링을 적용하는 과정을 이용하면 되겠다는 생각이 들었다. 김희정 부사장님이 만날 때마다 하셨던 얘기는 "책을 쉽게 써야 한다"였다. 보통 처음 책을 쓰는 사람은, 욕심에 책을 어렵게 쓰는 경향이 있다. 자기 주변에 잘 하는 사람들이 많이 있을테니 그 사람들이 봐도 있어보일만한 책을 쓰려는 욕심이 들기 쉽다. 또, 독자들이 자기 주변의 사람들 처럼 이미 선지식이 충분히 있을 것이라고 착각하기도 쉽다. 당연히 JUnit도 척척 쓸 줄 알고, 자바 언어와 디자인패턴도 완벽히 꿰고 있을 것이라고 착각하기 쉽다. 하지만 대부분의 독자는 그렇지 않다. 나도 현장을 다니면서, 나름 유명한 기업의 개발팀 사람들이 JUnit을 들어본 적도 없다는 사실에 놀라기도 했다. 가장 기본이라고 생각하는 자바 콜렉션 프레임워크의 semantics에 대해서도 제대로 이해를 못하는 사람도 많았다. 당장 현장에서 돌아가는 애플리케이션을 만들고 관리하는 것이 주업무였고, 컨설턴트나 아키텍트가 만들어준 템플릿을 이용해서 기계적인 반복 코딩을 했기 때문일 수도 있고.. 뭐 이유는 많겠지만.

물론 주변에서 "한국에도 이제 중고급자(만)을 위한 책이 나와야 하자나요. 마음 것 고급내용으로 어렵게 쓰세요"라고 꼬시는 사람들이 있었다. 하지만 그럴 때마다 어려운 책을 붙잡고 씨름하다 막막해 하는 향화나 교육센터 졸업생들을 생각해봤다. 그래서 그들도 볼수 있도록 책을 쓰자고 결심했다. 또는 그런 비슷한 수준의 초보 개발자들, 또는 자바 입문자들도 공부할 수 있도록 써야 겠다고 생각했다. 물론 자신을 고수라고 생각하는 일부 개발자들은 "책이 너무 쉽다. 블로그 글을 보고 그 수준으로 기대하고 샀는데 사기 당했다"라고 원망할 수도 있을 것이다. 물론 치밀한 나는 그런 사람들을 위해서 중간 중간에 난이도가 높은 내용을 틈틈히 박아두기는 했지만.

아무튼, 그렇게 해서 1장을 썼다. 막상 코드를 꺼내놓고 얘기를 풀어 나가니 줄줄 잘 써졌다. 코드만 만지면 이게 무슨 짓을 하는 것인지 정리가 안될테니 중간 중간에 이런 저런 이론을 가지고 배경을 설명하려고 노력했다. 물론 그런 이론 얘기가 나오면 경기를 일으키는 개발자들도 있기 때문에 이런 얘기는 몰라도 그만이라고 둘러대고 넘어가야 했지만. 사실 스프링의 DI를 XML 설정파일이라고 착각하는 개발자들이 많다. 소위 대안 언어씩이나 한다는 사람들이 스프링도 별거 없다고 까면서 흔히 꺼내는 것이 바로 XML 설정파일 같은 거 써야 하는 자바 언어의 후진성에 관한 얘기다. 물론 다 DI의 D자도 제대로 모르기 때문에 나오는 헛소리다. 스프링이 말하는 DI는 평범한 프로그래밍 원리일 뿐이고 자바 언어만으로 충분하다. DI로 검색하면 DI에 대한 정의 – 애플리케이션 코드와 어셈블러(의존관계 설정의 책임을 맡은 놈)를 분리해서 개발하는 방법 – 가 널려있는데, 그걸 자꾸 언어의 한계 때문에 XML 설정파일을 사용하는 프레임워크가 필요한 기술이라고 왜곡 시키는 사람들을 나는 도무지 이해할 수 없다.

그래서 XML 한 줄 없이, 스프링 코드 전혀 없이 DI를 적용하는 모습을 보여주고 싶었다. 그래서 100페이지쯤 되는 1장의 절반이 될 때까지 DI를 줄곳 설명하고 코드를 보여주지만 스프링은 전혀 등장하지 않는다. DI에 스프링이 필요한게 아니니깐 등장할 필요도 없다. 그리고 나서 DI컨테이너(또는 프레임워크)로서 스프링을 활용하면 그 때까지 평범한 자바로 했던 DI작업이 좀 더 편해진다는(물론 규모가 있는 DI적용의 경우에) 설명을 곁들여서 DI와 DI프레임워크의 차이점을 보여주려고 했다.

제법 빠른 속도로 그렇게 1장을 써나가던 12월 초에 드디어 스프링원 아메리카 참석차 한국을 거처 미국으로 떠나게 되었다.  친절한 민호가 나와 기선이 모두 스프링 컨퍼런스에 다녀올 수 있도록 후원해주겠다고 했다. 가는 길에 한국에 일주일 먼저 들리기로 했다. 물론 이 선택은 나중에 후회를 했는데, 갈 때는 한국에 스톱오버를 해서 쉬었다 가서 괜찮았지만 올때는 바로 갈아타고 호주로 오느라 거의 24시간 가량 쉬지 않고 비행기를 타야했고, 엉덩이는 거의 의자 모양(비상구 좌석)에 맞게 네모로 변했고, 완전 녹초가 되버리고 말았다. 왜 어떤 사람들이 비행기에서 협소공포증을 느끼고 뛰어내리고 싶어하는지 살짝 이해가 가기도.

 

아무튼 한국을 간다는 소문이 나자 김희정 부사장님이 만나자고 연락이 왔다. 두둥.

호주로 갑자기 떠났던 불량 저자가 온다고 하니 이 참에 확실히 교육시켜야 겠다고 벼르고 계실거라는 생각이 들었다. 덜덜덜. 그래도 어쩌겠는가. 시내에서 영회와 때마침 한국에 온 성훈이 부부와 함께 김희정 부사장님을 만났다. 성훈이는 MIT에 있던 2007년부터 같은 팀에서 함께 일을 한 적이 있어서 친하긴 했지만 한번도 얼굴을 본적은 없었다. 다른 사람들과 함께 만나서 다행이었다. 설마 3자 앞에서 너무 면박주지는 않을테니까.

차마 진도가 어느정도 나갔다는 얘기는 못했다. 대신 용기를 내서 스프링 3.0이 내년(2009년) 봄에 나온다는데 이왕이면 3.0에 맞춰서 책을 내는게 어떻겠는가 하고 얘기를 꺼냈다. 이미 2.5 책들은 여러 권이 나와서 팔린 상태였고 3.0이 나오는 마당에 2.5 책을 내버리면 뒷북치는 꼴이 되버리는 것이 아니겠냐는 논리였다. 물론 나는 어떻게든 가능한 시간을 벌려는 속셈이었다. 마치 책을 마무리 해가지만 3.0을 기다렸다가 3.0 맞춰서 수정해서 빠르게 3.0 책으로 내는 것이 마케팅 측면에서도 더 낫지 않겠느냐는…  개발자 출신 저자의 얕은 속셈을 다 꿰뚫어 보고 있지만 그럼에도 항상 상냥한 김희정 부사장님은 예상과 달리 "2.0 책 낸다고 계약했는데 3.0까지 가면 어떡해욧"이라고 하지 않으시고 "그럼 3.0에 맞춰서 내는게 좋겠어요. 사장님께도 그렇게 말씀드릴께요"라고 답하셨다. 그런 표현은 없었지만 기획한 책이 빨리 안나온다고 사장님께 혼난다는 눈치였다. 호랭이 희용이가 김 부사장님께 시달린다고 얘기할때와 비슷한 상황이었다. 한편으로는 "도대체 어디까지 질질 끌려나 한번 두고 보자. 3.0이든 4.0이든 어디 한번 해봐라"는 자포자기한 마음에서 나온 얘기가 아니었을까 생각이 들기도 했다.

어쨌든 시간을 좀 벌었으니까 일단 한숨 돌렸다.  점심으로 먹던 중국 요리가 목에 반쯤 걸려있었는데 갑자기 쑥 내려가는 느낌이었다.

스프링 3.0이 2009년 4월에 나온다는 것이 스프링소스의 공식 발표였다. 그런데, 솔직히 말하자면 스프링소스는 약속한 날자에 한번도 스프링 새버전을 릴리스를 한 적이 없다는 사실을 나는 너무 잘 알고 있었다. 그러니 4월에 나온다고 하면 빨라야 8-9월에나 나올 것이 분명했다. 하지만 그런 얘기는 차마 할 수가 없었다. 그때문에 더 죄송했지만 내 코가 석자라.

아무튼 3.0에 맞춰서 내는 것을 허락받고 나니 마음이 한결 가벼워졌다. 물론 김희정 부사장님은 "굳이 정식버전이 다 나오지 않아도 책을 내도 괜찮아요. 일단 RC버전이라도 최대한 내용을 맞춰서 일단 책을 내고, 2쇄 할 때 최종 버전이 나오면 좀 더 보충하는 식으로 해도 돼요"라고 설명해주시면서 릴리스 일정 핑계대서 질질끌지 말고 가능한 빨리 내야 한다는 눈치를 주시긴 했다.

 

하지만 스프링 개발팀은 내 예상을 훨씬 넘어서 처음 약속보다 8개월이 지난 12월에야 3.0을 내 놓았다. 내 책은 그 뒤로 다시 8개월이 지나서 나오게 되었고.

본격적으로 책의 내용을 써내려간 이야기. 그리고 다음 해 9월 한국 방문과 그 때 벌어진 KSUG 회장 전격 교체작전 등등에 대해서는 내일 다시.

토비의 ‘이제는 말할 수 있다’ 여섯 번째 이야기.

본격적으로 책을 쓰기로 결심하고 나서 가장 먼저 시작한 일은 스프링 공부였다. 스프링에 대해서는 누구보다 더 많이 연구했고 알고 있다고 자신하지만, 그래도 내가 자주 사용하지 않는 옵션들과 접근방법들에 대해서 꼼꼼하게 점검해볼 필요가 있다는 생각이 들었다. 스프링 2.5.6의 레퍼런스 매뉴얼을 처음부터 꼼꼼하게 읽어나가면서 그 내용 하나 하나를 학습 테스트로 만들기 시작했다. 코드를 만들어 확인해보지 않은 지식은 내 지식이라고 할 수 없다는 평소의 지론대로 내가 써보지 않은 옵션과 조합, 설정 방식 등을 모두 한 번씩 적용해가며 테스트 코드를 만들어 나가기 시작했다. 학습테스트를 이용한 학습방법은 내 블로그에도 한 번 썼듯이(http://toby.epril.com/?p=419) 매우 유용하고 확실한 기술 습득 방법이다. 애자일 자바는 자바 언어 수준에서 초보적인 학습테스트를 활용한 것이다. 그렇게 레퍼런스의 내용을 빠짐없이 테스트로 만들어나가면서 스프링의 다양한 기술조합을 공부하다보니 시간이 적지 않게 흘렀다. 내가 익숙지 않은 몇 가지 기술과 테스트 작성하기가 힘들어보이는 웹 기술을 빼고 나머지 모든 스프링 기술에 대해서 학습 테스트 작성을 끝내고 나니 9월 말이었다. 3개월의 시간을 그렇게 쏟아붓고 나니 머리 속에 스프링의 전 기능에 대한 지도가 그려진 것 같은 느낌이 들었다. 그렇게 만들어진 학습 테스트 코드는 나중에 책을 쓸 때 매우 유용하게 활용했다. 책의 2부는 바로 그렇게 학습 테스트를 만들어가면서 공부하는 식의 내용이다. 물론 책의 예제로 들어가는 테스트는 3.0에 맞춰서 모두 새롭게 쓰긴 했지만, 어쨌든 처음 만들어둔 테스트가 아주 중요한 역할을 한 것은 분명하다.

그리고 10월이 되서 처음으로 책 원고를 쓰기 시작했다. 처음 저술요청을 받았을 때 페이지 분량을 확인해보는 용도로 쓰라고 김 부사장님이 주신 원고 템플릿 파일이 있다. 그 워드 파일의 포맷에 맞춰서 글을 쓰면 대략 몇 페이지쯤 된다는 것을 파악할 수 있게 만들어진 것이다. 그런데 아무리 찾아도 그 파일이 보이지 않았다. 다시 달라고 할까 싶었지만 그랬다가는 아직 시작도 안한 것을 들키고 말테니 안되겠다 싶었다. 그래서 나보다 먼저 에이콘 출판사를 통해서 책을 출간했던 현철주님 한테 원고 샘플을 요청을 했다. 현철주님은 스트럿츠2 책을 쓰신 멋진 분이다. 그 책을 쓸 때 사용한 워드 파일이 있을테니 그 파일을 가지고 글을 쓰면 출판사에서 원하는 페이지 분량에 맞출 수 있을 것이라고 생각했다. 그렇게 받은 스트럿츠2 원고 파일을 기준으로 스타일을 만들어서 내 책의 템플릿 파일을 작성했다. 그리고 꼼꼼히 확인하려고 인쇄된 책을 가져다가 가로 세로 글자 수와 줄 수를 세어서 실제 책의 페이지 분량과 일치하는지도 확인했다.

그런데, 그렇게 준비된 템플릿을 이용해서 원고를 작성했음에도 막상 최종 편집을 하고 보니 워드 파일보다 페이지 수가 훨씬 늘어났다. 부록을 빼고 내가 출판사에 넘겨드린 워드 파일의 페이지 수는 1030페이지쯤 됐다. 그런데 꼭꼭 눌러서 편집을 했음에도 최종 편집 결과는 1400페이지 가까운 것이었다. 어떻게 30% 가량 차이가 났는지는 지금도 의문이다. 그 사이 출판사의 책 크기와 폰트, 간격, 여백 등의 기준이 바뀐 것인지, 아니면 내가 뭔가 착각을 해서 템플릿 파일의 페이지 크기 조절을 잘못한 것인지 모르겠지만. 아무튼, 나는 1400페이지짜리 두꺼운 책을 쓰려고 한게 절대 절대 아니다! 이 얘기는 나중에 다시.

 

원고 템플릿을 만들고 나서 처음 한 일은 제목과 부제를 쓰는 것이었다. 물론 책 판매에 중요한 영향을 미치는 책 제목과 부제는 나중에 출판사의 결정에 따라서 바뀌게 된다는 사실을 잘 알고 있지만, 일단 내가 쓰고 싶은 것으로 적었다. 제목은 ‘애자일 스프링’. 부제는 ‘스프링과 함께 더 나은 개발자가 되는 법’. 내가 이 책에서 하고 싶은 얘기가 무엇인지 다시 생각해봤다. 단지 스프링을 어떻게든 빨리 사용하도록 안내하는 책인가? 아니면 스프링 기술을 깊이 파는 마니아를 위한 책인가? 아니면 뭘까? 2004년부터 시작된 나의 스프링 경험을 돌아보면 가장 내 기억에 남는 것은 스프링을 공부하고 적용하면서 프로그래밍에 대한 나의 생각과 시각, 습관이 바뀐 것을 느낄 수 있었다. 처음엔 그저 XML에 빈 설정하고 컨테이너 만들어서 DI방식으로 오브젝트가 생성되게 해서 쓰는 것이 전부라고 생각했던 스프링이 사실은 그보다 더 중요한 원리를 충실히 따르면서 자연스럽게 만들어진 것을 깨달았다. 그리고 스프링에 적용된 그 원리와 프로그래밍 습관이 내가 작성하는 코드에도 서서히 녹아어가기 시작했음을 알고 짜릿했던 순간들. 그동안 공부했던 다양한 프로그래밍 원칙과 패턴이 자연스럽게 엔터프라이즈 환경에 실체화된 것이 스프링이라는 사실을 하나씩 구체적으로 발견했던 기억들. 아무튼 그 속에서 내가 스프링을 사용하기 전보다 좀 더 나은 개발자가 되었음을 얘기하고 싶었다.

물론 내가 생각했던 제목은 나중에 김희정 편집장님이 단칼에 "애자일? 절대 안돼요!”라고 잘라버리셔서 전히 빛을 볼 수 없긴 했지만. 사실 그 뒤에 생각했던 몇 가지 제목이 더 있는데 차마 말을 꺼낼 수도 없었다. 뭐, "스프링 공중부양"이라든가 "엣지있게 스프링" 따위. 최종 제목과 부제는 모두 김희정 부사장님의 정하셨다. 나는 단지 "어때요" 하셔서 자동으로 "네"라고 했을 뿐. 책 제목에 내 이름(토비)이 들어가는 것이 처음에는 좀 그랬는데, 워낙 스프링 책이 많다보니 책 이름이 아무래도 혼동되기 쉬울 것 같고, 뭔가 확연하게 구분되려면 좀 독특한 이름을 쓰는 것도 나쁘지 않겠다고 생각됐다.

 

빈 원고에 제목 두 줄을 쓰고 나니 정말 책을 쓴다는 느낌이 들었다.

그리고 서문을 쓰기로 결정했다. 사실 김희정 부사장님은 "서문은 일단 쓰지 마세요"라고 했다. 물론 왜 쓰지 말아야 하는지 설명은 없이. 대충 짐작이 가는 바가 있었지만, 그래도 나는 나중에 버리는 한이 있더라도 서문을 쓰고 싶었다. 영회가 그렇듯이 나도 한 때는 책의 서문과 목차, 추천글 등을 제끼고 바로 1장으로 들어가는 버릇이 있었다. 1장이 만약 역사니 의미니 하는 내용이 나오는 것 같으면 1장도 제끼고 본격적인 내용이 시작되는 2장으로 넘어가기도 했다. 그런데 언젠가 책의 서문에 저자가 남긴 내용이 얼마나 중요한지 알게된 후로는 책의 서문을 꼼꼼하게 읽는다. 그러면 그 책을 어떻게 읽어야 할지 그림이 그려진다. 물론 성의 없이 쓴 듯한 서문은 좀 그렇지만.

보통 서문을 읽어보면 서문을 먼저 쓰고 본문을 썼는지 아니면 그 반대인지 알 수 있다. 보통 책을 다 쓰고 나서 쓴 서문이 많은 것 같다. 그래도 나는 일단 서문을 쓰고 싶었다. 내가 이 책을 왜 쓰는지, 어떤 얘기를 하고 싶은지 내 자신한테 얘기하고 싶어기 때문이다.

코드를 작성하면서 스프링 기능을 정리할 때는 PC에서 작업을 하는 것이 수월했지만 막상 책의 원고를 쓰기 시작하려니 좀 더 집중할 수 있는 환경이었으면 좋겠다 싶었다. 그래서 10월 초부터 브리즈번 강가에 있는 퀸즈랜드 주립 도서관에 다니기 시작했다. 이 도서관에는 서고, 열람실과 별도로 아무나 자유롭게 들어와서 PC도 사용할 수 있고 다양한 모양의 의자와 소파 등에 앉거나 누워서 공부도 하고 책도 볼 수 있는 공간이 있다. 특히 무선 인터넷과 전원이 공짜로 제공되기 때문에 유학생들이 즐겨 찾는 장소이기도 하다. 노트북을 들고 기차를 타고 시내로 나가서 강가를 따라 걸어서 도서관으로 갔다. 그렇게 3일 동안 도서관에 다니면서 5페이지짜리 서문을 완성했다. 그게 따듯한 봄이었던 2008년 10월이었다.

물론 서문을 쓰지 말라고 했음에도 써버린 나는 결국 김희정 부사장님의 주문에 따라 서문을 대신할 ‘들어가며’라는 스프링 소개 글을 다시 써야 했다. 그래도 서문에 썼던 얘기의 상당부분은 그대로 ‘들어가며’ 안에 남겨둘 수 있어서 다행이긴 하다. "쓰지 말라는 서문을 왜 썼어욧!"이라고 혼나지 않은 것만 해도 다행이었다.

내 원고는 PC와 서버에 git 리포지토리를 만들어서 관리했다. 완성된 서문을 git 리포지토리에 처음 커밋한 것이 10월 13일이다. 그리고 그 뒤로 약 500번 정도 커밋을 더 하고나서 책이 완성됐다.

 

서문을 마치고 1장을 시작했다. 나도 다른 책의 따분한 1장이 싫었다. 특히 기술의 역사가 나오면 가장 짜증났다. 내가 알고 싶은 것은 지금 내가 사용할 버전의 기술이지, 장황한 기술 역사와 그 역사를 꿰고 있다는 저자의 자랑이 아니었다. 물론 그렇다고 특정 기술설명이나 코드로 바로 들어가는 것은 적절해보이지 않았다. 스프링을 예제와 사용법 위주로 공부하면 전체를 꿰뚫는 프로그래밍 모델과 철학을 놓치기 쉽다. 프레임워크를 사용하는데 개발철학 따위야 꼭 필요한 것은 아니지만 스프링은 예외다. 스프링은 기본을 알면 이해하고 응용하기가 아주 쉬운데 그렇지 않고 개별 기술을 따로 따로 공부하면 그 방대한 양에 금세 지쳐버린다. 게다가 스프링 만큼 오해가 많은 것도 없다. 그래서 일단 1장에서 스프링이란 도대체 뭐고, 뭐에 쓰는 것이고, 스프링이 어떤 유익을 주는지에 대해서 적기로 했다. 대신 스프링의 역사 따위는 한 문장 쯤으로 끝내버리고.

거의 한 달만에 1장을 완성했다. 물론 책 쓴다고 손가락 빨고만 있을 수는 없으니 부담 없이 장기간 진행할 수 있는 가벼운 프로젝트를 준비하기도 해야 했다. 11월 중순에 2장을 시작했다. 1장의 제목은 ‘스프링이란 무엇인가’ 였고, 2장의 제목은 ‘애자일 개발과 스프링’으로 정했다. 다른 책의 제목을 흉내낸 것이긴 하지만 일단 애자일 스프링이라고 정한만큼 애자일 개발 방법과 스프링의 상관관계를 POJO와 테스트편의성을 중심으로 설명해봤다. 사실 2장의 목적은 테스트의 중요성을 강조하기 위한 것이었다. 애자일은 그냥 테스트에 대한 이야기를 풀어내기 위한 도입기재로 사용한 것이고.

2장을 쓰는 중에 영회가 자꾸 책 진도를 물어왔다. 그래서 1장을 마쳤으니 한번 읽어보라고 1장 원고를 넘겨줬다. 2장은 완성되면 줘야지 하고 아직 넘기지 않았다. 진득하게 기술을 공부하고 연구하는 것보다는 사람들과 어울려서 수다떠는 것을 더 좋아하는 영회인지라 원고가 넘어가고도 한참이 지나서야 겨우 읽은 듯 했다. 다 읽었다고 하길래 어땠냐고 물어봤다.

그 질문을 한 것이 일생일대의 실수였다.

돌아온 영회의 피드백은 충격적이었다. 사실 기대한 것은 스프링에 대해서 이렇게 설명하는 것보다는 이렇게 하는 것이 좀 더 이해하기 쉽지 않겠냐라든가 스프링의 정의에 이런 요소를 넣었으면 좋겠다와 같은 실제 1장의 의도에 맞는 분석이나 제안이었다. 하지만 영회는 원래 그런 것에 별 관심이 없다. 평소에 문과 출신이고 IT계에서 흔치 않게 인문학적 소양이 높다는 점을 자랑했듯이 돌아온 피드백도 스프링의 기술과 본문의 내용과는 상관없는 단순 인상비평이었다.

"지루해. 문장이 번역투 같애"

영회의 평소 언행을 생각해보면 그다지 좋은 얘기가 나올 것을 기대할 수는 없었지만, 그래도 좀 심하다 싶은 얘기들이 돌아왔다. 자기야 그냥 느낌을 얘기하는 것이겠지만, 평소에 "자기는 글을 잘 쓰지만 나는 못쓴다"고 주장했던 것을 생각해보면 내용과 그 의미 보다는 책으로 쓰여진 글의 짜임새나 문장력을 평가한듯 싶었다. 문장이야, 나중에 나도 읽어보면서, 좀 늘어지고 어색하다고 느낀 부분이 제법 있기는 했지만, 그래도 로드 존슨 책처럼 간결하게 핵심을 짚은 내용을 최대한 함축적으로 나열하려고 한달간 매일 열시간 이상 끙끙대면서 쓰고 고치고 했던 내용을 칭찬 한마디 없이 그런 식으로 싸잡아서 비판 하는 것을 들으니 눈물이 핑돌았다.

 

위기가 왔다.

속도 상하고 화도 많이 났다. 책을 쓴다고 5개월 가까이 투자해 왔는데 건질게 없는가 해서 좌절감이 몰려왔다. 나는 책을 쓸 자질이 없다는 생각이 들었다. 그리고 결국 때려치기로 마음을 먹었다. 나야 몇 달의 시간을 투자한 것을 버리면 그만이었다. 그런데 출판사와 김희정 부사장님이 문제였다. 원고를 장기간 끄는 저자 때문에 당시 잘 나가는 스프링 관련 책도 못내고, 그렇다고 닥달도 못하고 속앓이만 하고 있을 김 부사장님한테 미안했다. 그래도 어쩌겠는가. 이왕 해외로 나온거 그냥 도피해야겠다고 생각했다. 다시 한국에 돌아가서 일 할 것도 아니니 아쉬울 것도 없었다. 이참에 인연을 끊어보자고 생각했다. 블로그는 폐쇄하고, 메신저는 다 끊고, 한국에서 걸려온 전화는 무시하면 그만이겠구나 싶었다.

이런 저런 생각을 하면서 며칠을 허탈하게 보냈다.

그래도 포기하지 말자는 생각을 했다. 영회가 평소에 하도 씹어대서 내가 글을 잘 못쓴다는 것은 진작에 알고 있었지만, 사실 책에 들이는 정성에 비하면 거의 장난삼아 쓰는, 구성과 내용은 물론이고 오자가 넘처나는 내 블로그 글도 누군가 꾸준히 와서 보고 도움을 받는다고 얘기하던 것을 생각해봤다. 그냥 블로그 쓰는 만큼, 그 수준으로 쓰자. 설마 누군가에게는 도움이 되겠지라,  내 경험을 나누면서 쓰는 블로그 글처럼 내 책도 그런 수준이면 되지 않겠는가 하는 생각을 했다. 영회 같은 까칠대마왕이 아니라면 뭐 문체를 따지고 그럴까 하는 생각도 했다.

그렇게 다시 며칠을 마음을 비웠다. 그리고 그 때까지 쓴 1,2장 원고를 모두 버렸다.

다시 처음부터 시작.

 

책의 구상부터 다시 새롭게 하기로 마음 먹었다. 그때가 2008년 11월이었다. 그리고 12월에는 미국에서 열리는 스프링원(TSE가 S1 America로 이름을 바꿨다)에 참석하기 위해서 미국에 가면서 한국에도 들리기로 했다. 도피하듯 나온 터라 제대로 인사도 못했던 김희정 부사장님을 한 번 볼 수 밖에 없는 상황이었다. 계약한지 2년 가까이 되가는 마당에, 그나마 썼던 원고는 영회의 이단 옆차기로 모두 날려버린 상태. 그리고 완전히 백지에서 다시 쓰기로 마음먹은 상황에서 김희정 부사장님을 만나게 된 이야기. 그리고 영회에 대해서 복수의 칼을 갈기 시작하고 일년 간의 치밀한 계획 끝에 복수에 성공한 이야기 등등은 내일 계속.

책이 출간되기 전에 얼릉 지난 이야기를 끄적여놓고 출간과 동시에 잠적하려고 했던 계획이 실패했다. 뭐, 내가 계획했던 일이 다 그렇지.

일년여의 고민끝에 스프링 책을 어떻게 쓸지 큰 그림을 그린 채로 2007년을 마감했다. 책 제목은 일단 애자일 스프링이라고 하기로 했고, 단일 예제 중심의 설명보다는 애자일 자바 스타일로 학습 테스트를 이용한 코드를 중심으로 각 기술의 다양한 옵션을 보여주는 것으로 그림을 그렸다. 테스트 코드는 독립적으로 동작하고 그 결과를 확인할 수 있으면서도 매우 간결하게 작성할 수 있다는 장점이 있으니, 최소한의 코드로 스프링 기술의 다양한 조합을 제한된 지면 내에서 적절히 보여줄 수 있을 것이라고 생각됐다.

2007년 12월에는 2006년에 이어서 두 번째로 미국에서 열린 The Spring Experience 컨퍼런스에 참석하게 되었다. 첫 컨퍼런스 참석 때처럼 설레이는 것은 없었지만 2.5가 나온지 얼마되지 않은 시점에 열린 컨퍼런스라 재밌는 새로운 이야기를 들을 것이 많았다. 또, 한가지 반가웠던 것은 한국에서 온 다른 참석자를 몇 명 만나게 된 것이다. 컨퍼런스 첫날 저녁 식사를 하면서 같은 테이블에 앉은 사람들에게 내 소개를 할 기회가 있었다. 언제나 그렇듯이 일단 한국에서 왔다고 하면 다들 신기한 눈으로 바라본다. 처음 나를 보고는 중국이나 일본에서 왔거나 아니면 미국이나 캐나다에 사는 이민자 정도로 생각했을 것이기 때문이다. 그런데 옆 자리에 있던 스프링소스 직원 한명이 갑자기 반가운 얼굴을 하고는 SDS에서 왔냐고 물었다. 아니라고 대답하고, 어떻게 SDS를 아느냐고 물었더니 최근에 스프링소스의 컨설팅을 받은 업체라서 잘 알고 있다고 했다. 그래서 혹시나 하는 마음에 세션에 참석할 때마다 한국에서 온 참석자가 있는지 살펴보았다.

아마 둘째 날이었을 것이다. 스프링소스 주관 컨퍼런스가 대체로 휼륭한 강사와 세션으로 구성되 있기는 하지만, 강사 개인에 따라서 지루하고 졸린 발표를 하는 사람이 있다. 여독이 풀리지도 않은 채로 첫 날부터 강행군을 했더니 둘째날 오후에는 피로가 심하게 몰려왔다. 게다가 하필이면 선택한 세션의 강사는 거의 자장가 같은 목소리로 중얼중얼 지루한 발표를 하는 사람이었다. 이미지 관리를 위해서 사람들이 없는 뒷쪽 구석에 자리를 잡고 졸다 듣다를 반복하고 있었다. 그런데 갑자기 앞에 앉은 검은 머리의 남자 한명이 눈에 띄었다. 발표를 들으면서 노트북으로 뭔가 열심히 하는 모습이 보였는데, 자세히 보니 노트북 화면이 낯이 익다. 흐리멍텅한 녹색 바탕의 네~이버였다. 끝나고 슬그머니 다가가서 인사를 했다. SDS의 김창제 (당시)팀장이라고 소개를 해줬다. 나중에 알고 보니 스프링 기반의 한국형 오픈소스 SI 프레임워크인 애니프레임의 기획과 개발을 책임지는 팀장이었다. 김창제 (지금은) 수석님은 이후에도 몇 번 만날 기회를 가졌고, 고맙게도 내 책의 추천사도 써주셨다. 한국의 SI업체에는 숨은 고수들이 많이 있다고 했는데, 바로 김창제 수석님이 그런 분이었다. 이미 그 당시 애니프레임 개발팀은 테스트 커버리지 90%를 달성하지 못하면 인사고과에 반영할 정도로 강력한 클린코드 정책을 유지하고 있었다. X인터넷이나 특정 벤더 종속적인 프레임워크가 점령하고 있는 척박한 SI환경에서 오픈소스 기술을 중심으로, 그것도 스프링을 기반으로 프레임워크를 만들어서 보급하고 있는 모습에 놀랐다.

 

아무튼, 그렇게 해서 2008년을 맞았다. 우선 호주로 돌아가는 일을 준비하는 작업을 시작했다. 2005년에 달랑 가방 두 개들고 한국에 들어왔는데 서울-대전-다시 서울 생활을 하다보니 짐이 많이 늘었다. 처분할 짐을 제외하고 호주로 보낼 살림살이를 먼저 국제이사업체를 통해서 보냈다. 배편으로 가는 짐은 빠르면 보름에도 가지만 늦어지면 3개월도 걸린다. 짐이 들어오면 컨테이너를 채우다가 컨테이너가 꽉 차야 해당 컨테이너를 배에 선적하고, 배도 일정 분량 이상 짐이 실려야 출발하기 때문이다. 많지는 않지만 이삿짐을 보내고 나니 마음도 이미 호주로 떠난 듯 설레였다.

한국에서 관여했던 회사 일도 정리하기 시작했다. 미국에 있는 고객사의 프로젝트가 하나 준비되고 있었는데, 나는 호주로 가서 가족과 함께 지내기로 결심한 만큼 미국에 보낼 다른 사람을 물색하고 있었다. 그 전에 미국 일 얘기가 나왔을 때는 영회가 자기를 보내달라고 했다. 하지만 그 뒤로는 그런 얘기가 다시 없었다.

그러던 중에 기선이가 미국으로 가고 싶다는 뜻을 밝혔다. 좀 애매한 상황이긴 했지만 기선이를 그 자리에 넣어두고 나는 일에서 손을 뗄 준비를 했다. 물론 기술적인 지원이나 기타 관리는 내가 맡아서 원격에서 참여할 계획이었다. 어쨌든 현장에서 고객들을 상대하고 일을해야 할 사람 중에서 나랑 손발이 잘 맞을만한 사람이 한명 필요했고, 그 역할을 기선이가 잘 해줄 것으로 기대했다. KSUG에서 활동하는 동안에 종종 만나기는 했지만 기선이와는 그리 친하게 지내지는 않았다. 나는 주로 집이 가까운 찬욱이랑 친하게 지냈고, 기선이에게는 영회가 잠수탔을 때 관련자들의 연락처를 물어보느라 몇번 연락했을 뿐이다. 좀 까칠해보이긴 하지만 성실하게 자기 몫은 잘 해내는 모습이 마음에 들었다.

가족이나 친척, 기타 일과 관련된 사람들과는 별 부담없이 인사도 하고 정리를 할 수 있었는데, 가장 끝까지 좀처럼 얘기를 꺼내지 힘들었던 사람이 바로 김희정 부사장님이다. 큰소리 치고 계약한지 일년이 다 되가는데 진도가 나간 것도 없고, 그러는 와중에 호주로 떠난다고 하면 얼마나 황당해 하실까 걱정이었다. 얘기를 꺼내기 힘들어서 한동안 질질 끌다가 결국 말씀을 드렸다. "어머나". 나는 호주이민자고 한국에 계속 체류할 것이 아님을 한번도 감춘적이 없었지만, 그래도 어느날 갑자기 떠난다는 말을 들으셨으니 얼마나 놀랐을지 모르겠다. 그것도 스프링 최신 버전이 나오고 관련 책들도 쏟아져 나와서 인기를 끌고 있는 마당에 스프링 책을 쓰겠다는 저자가 원고도 안넘기도 멀리 가버린다니! 가까이 있다면, 정 안되겠으면 납치(에이콘 출판사에 대해서 사람들에게 물어보면 다들 저자나 역자를 납치하는 것으로 유명하다는 얘기를 해주는데 그게 무슨 얘긴지 지금까지도 잘 모르겠다)를 해서 사무실에 감금하고 창틀로 먹이를 던져주며 원고를 쓰게라도 할텐데, 호주는 비행시간만 10시간 떨어진 곳이라 관리하기가 쉽지 않다. "한번 봐요"가 안통하는 곳. 그때 김 부사장님이 어떤 얘기를 하셨는지는 잘 기억이 나지 않는다. 단지 "호주로 쫒아가서라도 원고를 받아내고 말겠다"는 굳은 의지를 느꼈던 것을 기억할 뿐.

 

2008년 3월에 떠나기 직전까지 일이 몰렸다. 프레임워크 제작, 교육, 기타 컨설팅 등등. 일부 일은 호주에 도착하고 나서도 계속 진행해야 했다. 게다가 거의 일년 가까이 기획해온 큰 프로젝트 하나가 기다리고 있었다. 호주에 와서는 임시로 친척집에 머물면서 집을 구하고 다시 정착하기 위해서 계속 뛰어다녀야 했다. 다행히 살 집은 빨리 구할 수가 있었다. 원래는 친구 집에 6개월 정도 머물면서 랜드+하우스 패키지를 사서 집을 직접 디자인해서 지을 생각이었다. 그런데 우연히 고모님이 소개해준 집을 보고 맘에 들어서 덜컥 계약을 해버렸다. 교통이 매우 좋은 곳에 있으면서도, 조용한 동네고, 땅크기도 830m2정도로 넉넉해서 나중에 집을 다시 지어도 좋겠다 싶었다. 아직 돌도 안된 평화도 있는데 집 보러 다니느라 매일 돌아다니고 고민하고 시간을 끌지 않는 것이 좋겠다는 생각 때문이었을 수도 있다. 게다가 집 가격도 저렴했고. 책과 옷, 그릇, 식탁과 침대 하나를 빼면 거의 모든 가구와 가전제품을 모두 새로 구입하느라 매일 쇼핑센터와 이베이를 전전. 낮에는 낯선 곳에 정착하기 위해서 열심히 뛰고 밤에는 개발과 프로젝트 기획 등으로 정신없는 시간을 보냈다.

그렇게 지낸 시간이 다시 몇 달. 한국에서는 떠날 준비하느라 바빠서, 호주에 와서는 정착하느라고 바빠서. 이런 저런 핑계로 책을 쓰는 일은 다시 저 멀리로 보내놓고 6월을 맞았다. 그러는 중에도 때때로 책을 써야 하는데라는 부담이 거대하게 몰려올 때가 있었다. 혹시나 김희정 부사장님이 메시지를 보내지 않을까 해서 MSN 메신저를 켜지도 못했다. 3-4개월에 한번씩 김 부사장님 대신 황지영 대리님으로부터 "저술 진행 문의" 메일이 왔다. "원고 진행은 잘 되고 계세요? 초벌 원고가 나올 때 갈은데요. 진행이 어떻게 되는지 알려주세요"라는 똑같은 레파토리의 메일이 날라왔다. 나는 한번도 제대로 답장을 할 수가 없었다. "진행이 전~혀 안되고 있어요"라고 말할 수는 없었으니까. 그리고 내가 아무리 "잘 되고 있습니다. 조금만 더 기다려주세요"라고 뻥을 쳐봤자, 눈치 빠른 김 부사장님은 아직 시작도 안했구나라고 금새 알아차릴 것이 분명했다.

그런데, 나중에 알게된 사실이지만 김 부사장님은 영회를 스파이로 사용하고 있었다. 영회한테야 방심한 채로 책이 진도가 나가는지 어떤지를 다 얘기하고 있었다. 그것을 눈치챈 김 부사장님은 영회에게 정기적으로 보고를 받으면서 책을 얼마나 썼는지, 지금 쓰고 있는지, 질질 끌고 있는지 등등을 파악하고 있었다. 나한테 별 관심이 없는 영회가 수시로 "형. 책 얼마나 썼어?"라고 물어볼 때 눈치챘어야 했는데…

 

그러는 중에 6월이 됐다. 그리고 충격적인 얘기를 들었다. 지난 일년간 준비해온 중요한 프로젝트가 갑자기 무산됐다는 소식이었다. 이미 담당자를 통해서 기획서가 작성되서 회장의 결재까지 다 끝났고 예산도 이미 잡혀 있어서 진행만 하면 되는 상황이었는데 무슨 일인가 해서 알아봤다. 알고보니 국제적인 경제위기로 수익이 줄어든 다국적 기업 S가 코묻은 돈까지 다 싹쓸이하자는 전략을 세워서 우리 고객사에까지 접근을 한 것이었다. 그리고 고가의 제품을 덤핑 수준의 가격으로 제시하면서 담당 임원을 공략했다. 국제적인 브랜드에 넘어간 해당 임원이 갑자기 기존 기획을 취소 시키고 해당 제품을 들이기로 결정했다. 요즘 J모 언어를 말아먹는다고 말이 많은 O모사에게 프로젝트를 막판에 뺐긴 카이스트에서의 일이 다시 재현된 것이다. 카이스트 일이야 진행할만큼 하고나서 넘어간 것이라 그래도 덜 억울했는데, 이건 비용도 적지 않게 들여서 기획을 다 해놨는데 초장에 일을 뺐겼으니 더욱 황당했다.

이미 다 따논 일이라고 안심하고 있었는데 일이 날라가면서 갑자기 공중에 붕 뜬 꼴이 됐다. 호주를 떠나기 전에 진행하던 로컬 비즈니스는 잠정적으로 중단시켜논 상황이었고, 일단 기존 프로젝트를 진행하면서 호주 비즈니스는 차근 차근 셋업해 나갈 계획이었는데, 갑자기 할 일이 날라가버렸으니!

남자는 직업을 잃을 때 가장 큰 충격에 빠진다고 한다. 거의 배우자가 바람핀다는 것을 알게됐을 때의 충격이라고 한다. 나는 뭐 직업을 포기해야 하는 것은 아니었지만, 다 따논 일을 이렇게 막판에 날리면 충격이 크다. IMF로 핵심 공급업체 두 군데가 부도가 나서 일년 넘게 준비한 인터넷 서비스를 그대로 접어야 했을 때, 9/11 사건의 여파로 다 된 프로젝트를 날려버리고 준비중이던 50여명의 프로젝트 팀원에게 돌아가서 각자 살길을 찾으라고 말해야 했을 때나, 큰 일을 함께 추진하던 파트너 업체가 사실은 부도 직전이라는 것을 알게 됐을 때, 조직개편으로 프로젝트 진행 부서가 통채로 공중 분해됐을 때, 프로젝트를 진행하던 연구소의 출입문 비밀번호가 바뀌고 연구소가 폐쇄됐다는 것을 알았을 때 등등. 그런 경험이 적지 않았지만 아무튼 매번 충격이다.

6월. 호주의 살을 에이는 듯한 추운 겨울이 다가오고 있을 무렵이었다. 며칠을 멍하니 앉아서 이제 무엇을 해야하나 하고 고민을 했다. 그리고 결심했다. 책을 쓰자. 일은 나중에 하고 일단 책을 먼저 빨리 마무리 해야겠다는 생각이 들었다. 그때가 절호의 기회라고 생각이 들었다. 진행 중인 프로젝트는 모두 마무리 되었고, 앞으로 하려고 했던 프로젝트는 날라갔다. 호주에서 함께 일했던 비즈니스 파트너들에게서 연락이 와서 새로운 일을 벌이자는 요청이 있기는 했지만 일단 모두 거절했다.

그리고 나도 로드 존슨이 J2EE D&D를 처음 쓸 때처럼 한 일년쯤 책 저술에만 매달려야 겠다는 생각을 했다.

그렇게 해서 드디어 토비의 스프링 3을 처음 쓰기 시작했다. 그게 몹시 춥던 2008년 6월이었다.

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha