토비의 스프링이 나오기까지

2010년에 책이 나온 뒤에 블로그에 썼던 토비의 스프링이 나오기까지라는 글을 모두 옮겨봤다. 길다.

토비의 스프링 3이 나오기까지 (1)

 

원고에서 손 뗀지 얼마 안됐는데 벌써 책 내용도 가물가물하다. 그러니 책을 써온 그 동안의 기억도 금세 사라지겠지. 더 잊기 전에 책을 써왔던 이야기를 적어놔야겠다.

 

IT서적은 국민학교 5학년 때부터 교보문고 컴퓨터 서적 코너에 수시로 들락거리면서부터 꾸준히 읽고 공부하기 시작했으니 대충 27년쯤 읽어온 것 같다. 하지만 한번도 내가 직접 책을 써볼까 하는 생각을 해본 적은 없다. 그래서 2006년 어느날 당시 마소 기자였던 희용이(지금은 마소 발행인이자 마소 인터렉티브 사장)가 "형 책 한번 써볼 생각 없어?"라고 지나가는 말로 물어봤을 때도 별 생각 없이 "기회되면 한번 해보지"라고 대답했던 것 같다. 누가 부탁하면 거절을 못하는 못된 습성 때문에 "안 써"라고 말할 수는 없었기 때문이었을 것이다. 그리고 어느날 희용이가 강남에서 출판사 관계자와 함께 만나자고 했을 때도 별다른 생각없이 희용이 얼굴이나 한 번 보려고 나갔다.

 

그날 에이콘 출판사의 김희정 편집장님(지금은 부사장님)을 처음 만나게 되었다. 한국 IT서적은 97년에 삼각형 출판사에 여러번 크게 데인 뒤로 다시는 국내 서적은 보지 않겠다고 결심하고는 10년간 전혀 읽지 않았다. 99년에 해외로 나갔으니 더더욱 한국 책은 볼 기회가 없었다. 그래서 국내 IT서적 출판사가 어떤 곳이 있는지 알지도 못하던 때였다. 당연히 에이콘 출판사는 이름도 들어보지 못한 곳이었다. 어쨌든 희용이가 잘 알고 친하게 지내는 곳이라고 해서 만남을 가졌다.

 

처음 만났던 김희정 편집장님은 말투는 상냥하지만 좀 차갑게 느껴졌다. 인사를 하고 식당으로 가서 식사를 하면서 처음 받은 질문이 아마 "책을 쓰실 수 있겠어요?"였을 것이다. 나는 희용이 소개로 그냥 인사나 하려고 만난 것이라고 생각했는데, 당시 받은 느낌은 내가 책을 내고 싶어서 출판사에 소개시켜달라고 해서 만난 것 같은 상황이었다. 게다가 출판사 편집장님의 눈빛이나 말투는 "정 기자가 소개를 해줘서 한번 만나기는 하지만, 어디서 이름도 못들어본 사람이 책을 내겠다고 하는데 과연 제대로 쓸 수나 있을까? 실력은 있는 것일까?" 하는 의심에 찬 것이었다. 물론 예상치 못한 질문에 당황한 나머지 그런 인상을 받았을 뿐 김희정 편집장님은 그런 뜻은 전혀 아니었겠지만.

 

아무튼 "네까짓게 책을 쓸 수 있어"라는 도전을 받은 듯한 느낌이 드니 오기가 발동했던 것 같다. 그래서 스프링이 얼마나 좋은 기술이고(당시만 해도 스프링 얘기를 꺼내면 다들 우습게 보던 시절이었다. 스트럿츠1 때문에 한국에서 스프링은 뜰 수 없다고 얘기하고 다니는 유명한 자바 개발자도 있었다. 오픈소스 기술은 절대 엔터프라이즈 개발에 쓸 수 없다고 블로그에 와서 훈계하고 가는 사람들도 있었다) 앞으로 전도 유망한지 열심히 얘기했던 것 같다. 아마 그런 열정을 보여서일까 그날 얘기는 긍정적으로 생각해보자는 선에서 마무리된 것 같다.

 

당시에 나는 카이스트의 모 프로젝트에서 스프링을 이용한 애플리케이션 프레임워크 개발을 책임지고 있던 시절이다. 2004년에 시작한 미국 프로젝트를 마치고 호주에 다시 돌아가려고 하던 차에 물개 승권이의 꼬임에 넘어가서 카이스트 프로젝트에 참여하게 되었다. 원래 한달만 참여해서 아키텍처만 잡아주면 된다는 것이 조건이었는데, 물개의 물귀신 신공에 넘어가서 한달이 6개월이 되고 6개월이 다시 일년이 되고, 2년도 되고 그러던 시절이었다. 사실 마소에 글을 쓰고 정기자를 알게된 것도 마소에 글쓰기가 귀찮아진 물개가 나한테 얼렁뚱땅 떠넘겼기 때문이다. 얼마나 원고 쓰기가 싫었던지 막판에는 내 블로그 글을 긁어다가 기사로 그대로 낸 적도 있는데(나한테는 일방적으로 통보만 해주고) 아마 그때 미안했는지 마소에 나를 추천해준 것이 정기자를 알게된 계기가 되었다.

 

그리고 그 해 겨울에 미국에서 열린 두 번째 스프링 컨퍼런스인 The Spring Experience 2006에 처음으로 참석하게 되었다. 담당 PM이 당황해서 프로젝트 중에 어디 가면 안된다고 말렸지만, 안보내주면 때려치겠다는 내 협박에 못이겨서 컨퍼런스 참여로 시간을 비우는 1주치의 급여를 받지 않는다는 조건으로 다녀올 수 있었다. 컨퍼런스 참가비와 여비, 못받은 급여 등을 합해보면 600만원 정도의 개인 비용을 투자한 셈이었다. 하지만 정말 10원도 아깝지 않은 시간이었다. Eric Evans를 만났고, 새로운 기술을 배운 것도 좋았지만 그보다는 전 세계에서 몰려든 스프링 개발자들과 교제하면서 그들의 실력과 열정에 도전 받게 된 것이 더 좋았다.

 

컨퍼런스에 다녀오는 내내 책을 어떻게 쓸까 하는 생각을 많이 해봤다.

 

기존에 봤던 스프링 책들은 모두 장단점이 있었다. 로드 존슨의 J2EE Development without EJB는 절반은 왜 EJB의 대안이 필요한지 설명하는 내용이었고, 나머지 절반도 스프링의 기초 개념만 살짝 다룬 책이라 실무에 적용할 구체적인 지식을 얻기는 힘들었다. 그래서 without EJB는 최초의 스프링 책이라고 볼 수도 있고, 아닐 수도 있다. 제대로된 최초의 스프링 기술 서적은 Spring in Action일 것이다. 하지만 SiA는 내가  궁금한게 많고 관심을 많이 가졌던 SpringMVC를 제대로 다루지 않아서 크게 실망한 책이었다. 600여페이지 밖에 안되는 얇은 책 주제에  Acegi니 Struts 같은 내용이 잔뜩 자리를 차지하고 있는 것을 보고 실망한 나머지 책을 구입한지 3일 만에 구석에 처박아 두고 다시는 보지 않았던 책이다.

 

당시엔 스프링 레퍼런스 문서는 100페이지도 안되는 얇은 분량이었다. 역시 SpringMVC에 관한 내용은 별로였다. 그래서 초기에 스프링에 대한 정보를 얻을 수 있는 거의 유일한 통로는 로드 존슨도 열심히 활동하던 스프링 사용자 포럼과 스프링 소스 코드였다. 어쩌면 스프링 소스를 들여다 볼 생각을 하고 거기서 많은 정보를 얻을 수 있다는 것을 알게된 것은 초기에 빈약한 스프링 관련자료와 서적 덕분이었을 것이다.

 

내가 가장 만족하면서 읽었던 스프링 책은 롭 해롭의 Pro Spring 1판이다. 2판은 저자가 바뀌면서 내용이 부실해져서 많은 원성을 들었지만, 1판은 정말 최고의 책이었다. 컨퍼런스에서 만났던 다른 스프링 개발자들에게 물어보면 다들 Pro Spring을 최고의 서적으로 꼽았다. 내가 Pro Spring에서 가장 좋았던 것은 단순히 스프링의 기술 사용방법 뿐 아니라, 그 원리와 기본이 되는 동작방식을 잘 설명해준 것과 POJO를 이용한 비즈니스 로직 작성의 중요성을 알려준 것이었다.

 

스프링 주요 개발자들이 함께 쓴 Professional Spring Framework도 물론 좋았다. 이 책에 나온 "스프링의 정수(essence)는 POJO에 엔터프라이즈 서비스를 적용시켜주는 것”이라는 설명은 지금도 내가 스프링을 설명할 때 자주 인용하는 것이다. 스프링이 POJO 프로그래밍을 위한 도구임을, 가장 중요한 것은 POJO로 만들어진 환경과 기술에 독립적인 애플리케이션 코드라는 것을 잘 알려주는 책이다. 이 책에서 가장 흥미롭게 본 것은 AOP다. AOP가 프록시 기술을 바탕으로 어떻게 만들어지고 적용되는지 매우 깊이있게 다뤄 준다. AOP가 어디선가 갑자기 떨어진 외계 기술이 아니라 자바의 고급 활용법에 불과하다는 것을 여기서 처음 알게되었다.

 

여러 가지 특징을 가진 스프링 책이 이미 존재하고 있고 또 계속 나오고 있는데, 과연 나는 어떤 책을 쓸 것인지, 어떤 독자를 대상으로 해야 할지 등등 여러가지 생각만 하면서 2007년을 맞았다.

 

토비의 스프링 3이 나오기까지 (2)

 

하늘이가 태어난 뒤로 아침에 평화를 준비시키고 도시락을 싸서 유치원에 데려다주는 것은 내 몫이다. 낮과 밤에 잠을 재우는 것도. 거기에 하늘이 분유 타는 것도 내 담당이다. 지난 밤처럼 2시에 먹고 아침까지 잔 날은 정말 해피하지만, 2-3시간마다 계속 깨는 날은 잠을 제대로 자기도 쉽지 않다. 동생이 생긴 뒤로 스트레스를 받아서 그런지 사소한 일에도 쉽게 울먹이는 평화랑 틈틈이 놀아주는 것도 큰 일이다. 장모님이 오셔서 많은 것을 도와주시기는 하지만 아내가 입덧을 심하게 하던 올 초 만큼 신경쓸게 많고 바쁘기도 하다. 그래도 뭔가가 마무리 된 후의 일인지라 마음은 참 편하다. 책 쓰는 것도 비슷하다. 책을 쓰는 중에 받는 스트레스와 쓰고 난 뒤에 받는 스트레스는 강도가 비슷하더라도 이를 상대하는 마음의 여유가 다르다.

 

다시 희미한 기억을 더듬어서 쉽지 않았던 시간 속으로 돌아가보자. 책을 쓰는 동안의 이야기를 적는 이유는 내 블로그가 원래 그런(내 삶의 기록을 남기는) 용도이기 때문이다. 그리고 이제 이 책에서 관심을 끊기 위해서다. 책을 마무리 할 때까지 가지고 있던 계획은 편집까지 마치면 예제에 대한 빠진 설명을 적고, 책을 쓰게 된 이야기를 적고 그리고 잠적하는 것이었다. 사실 하늘이가 생기기 전에는 호주 일주 여행을 떠나는 게 원래 계획이었다. 하늘이를 가진 것을 알고는 낳기 전에 시드니 여행을 다녀오는 것이었다. 하지만 책보다 하늘이가 먼저 나와버렸다. 아쉽지만 여행은 취소. 3×7일이 지나면 평화 데리고 바닷가에 연이나 날리러 가야겠다.

 

다시 어설픈 기억을 더듬어서 2007년 초로.

 

2006년은 물개 덕분에 여러가지 새로운 경험을 많이 했던 해였다. 사실 물개가 아니었으면 나는 한국에 체류할 일도 없었을테고 책을 쓸 기회도 없었을 것이다. 한국의 자바 커뮤니티와는 전혀 교류가 없던 나를 여기 저기 소개해주고, 추천해주고, 가끔 자기가 귀찮은 것을 떠밀어 맡기기도 하면서 그렇게 2005, 2006이 흘러갔다. JCO에서 발표를 하게 된 것도, 기묘에서 스프링 2.0 세미나를 하게된 것도, 마소에 기고를 하게 된 것(물개는 마소에 나를 두 번이나 추천해줬는데, 한번은 2005년에 기술 컬럼 담당으로, 다음 번은 편집진이 모두 교체된 뒤에 새로 들어온 정희용 (당시)기자에게 소개해준 것이다. 두 번 다 자기가 하다가 귀찮아져서 떠 넘긴 것으로 의심하고 있으나 사실은 순수한 의도로 그랬을 수도 있다)도 다 물개 덕이기도 하고 물개 탓이기도 하다. 잘 되면 물개 덕이고 안되면 물개 탓. 아무튼 물개의 농간에 넘어가서 점차로 한국의 개발자들을 알게 되고 마소의 정희용 기자도 알게 되고 에이콘 출판사의 김희정 편집장님도 알게 되고 하면서 2006년이 지나갔다.

 

그리고 내 인생에서 가장 바쁘고 정신없던 2007년이 시작됐다. 한국에서 장기간 체류하기로 결심하게 된 결정적인 계기는 사실 카이스트 프로젝트가 아니었다. 그건 1달, 6개월, 1년 하는 식으로 계약을 늘려갔기 때문에 나는 언제든지 빠져도 뭐라고 할 수 없는 상황이었다. 반면에 부모님의 권유는 거절하기가 힘들었다. 우리 부부는 결혼한지 7년 가까이 되던 그때까지 아기가 없었다. 나름 유명한 한의원에서 약도 먹어보고 호주에서 클리닉도 가봤지만 아이가 쉽게 생기지 않았다. 뭐, 안 생기면 말지라고 생각하긴 했지만, 그래도 아내가 다른 사람의 아이들을 끔찍히 이뻐하는 모습을 보거나 쇼핑몰의 아동복 코너를 지나가면서 옷이 참 이쁘네 하고 말할 때면 가슴이 아팠다. 2대 독자인 아들이 아이를 가지지 않는 것을 안타까워 하시는 부모님, 특히 엄마의 권유로 불임치료 강국이라는 한국에서 한 번쯤 시도는 해봐야겠다는 생각을 했다. 적어도 일년쯤은 시도를 해보고 그래도 안되면 포기해야지라는 생각을 했고, 그만큼은 한국에서 체류할 생각으로 대전에 내려가서 프로젝트에 참여한 것이다.

 

역시 세계 최고라는 한국의 불임치료 의술은 놀라웠다. 호주에서는 1년쯤 걸려서 천천히 강도를 높여가는 과정을 단 3주만에 패스. 다음 단계로, 다음 단계로. 그러더니 2006년 중반에 병원 다닌지 채 일년이 안되서 첫 임신을 했다. 하지만 안타깝게 첫 임신은 실패로 끝났다. 어느 정도 몸을 추스리면서 서서히 재시도를 하고 있던 2006말 우연히 알게된 한 교수님의 소개로 나와 아내는 국제적인 학교설립 프로젝트에 자원봉사자로 참여하게 되었고, 당시 카이스트 일을 파트타임으로 돌리고 S사 프로젝트를 준비하느라 바쁜 나를 대신해서 아내가 2007년 1월에 평양에 회의참석차 다녀오게 되었다. 지금이야 정치적인 상황이 복잡하지만 당시만 해도 남-북 분위기는 나쁘지 않았고, 북한은 호주의 정식 수교국가여서 비자를 받아서 쉽게 들어갈 수 있었고, 평양 방문(개고기 시식을 포함한)은 호주 교민들이 선호하는 인기 여행상품이기도 했다. 평양 방문 전에 시술을 했던 터라 혹시나 하는 생각에 돌아오자마자 검사를 해봤다. 두 번째 임신이었다. 

 

새해 초부터 정신없이 시작된 2007년은 정말 새로운 일과 도전거리로 가득찬 버겨운 시간이었다. 아내는 입덧이 심해져서 일을 중단하고 서울 친정에 와서 지냈고, 나는 대전과 서울을 오가면서 두 개의 프로젝트를 진행하면서, 틈틈히 유지보수 프로젝트도 두 개를 더 하고 있었고. 영회를 포스트로 넣어두고 나는 밖으로 돌면서 여유있게 진행하려고 했던 S사 프로젝트는 프로젝트 진행 결재까지 나고 계약서도 들어간 즈음에 총수의 후계구도 정비를 위한 대대적인 조직개편에 휩싸여서 잠정 연기, 중단되더니 담당 조직이 공중분해되는 일을 겪어야 했다. 그러는 중에 물개의 농간으로 공동 발표하게 된 영회가 발표준비를 나한테 다 떠넘겨서 혼자서 영회 발표자료까지 다 만들어줘야 했던 JCO 컨퍼런스 발표를 하고, 스프링 컨설팅 업체인 Epril을 급조해서 만들었고, Epril 주최 스프링 세미나를 진행하고, 세미나 직후에 KSUG를 설립하고 KSUG 세미나를 5차례 더 진행했고, 영회가 튀는 바람에 공중에 떠버린 일을 추스리느라 우왕좌왕 했고, 유럽에서 열린 SpringOne유럽에 다녀왔고, 중국 연길에 특강하러 한번, 교육하러 한번, 리서치 하느라 한번, 회의 하느라 한번 해서 4번 방문했고, 북경에 두 번 방문, 샌프란시스코의 QCon참석, 알라바마에 물류 시스템 개발 프로젝트 하느라 한달간 체류, 그리고 SpringOne 미국 컨퍼런스에도 다녀왔고, 그러는 차에 호주 회사의 프로젝트 2개를 원격으로 진행했고, 한국 프로젝트 두 개 더와 한 차례 스프링 교육을 하고, 유료 세미나도 한번 하고,수많은 업체의 컨설팅 요청에 대응해야 했다. 특집 기획과 원고를 요청하는 정희용 기자/편집장의 요청도 다 들어줘야 했고. 그러는 와중에 평화가 태어났고, 병원으로 산후조리원으로 처가집으로 다시 본가로 이전해야 했고, 아내가 입덧으로 일찍 일을 그만 두는 바람에 생긴 공백을 메꾸기 위해서 땜빵 개발 일을 했고, 그러는 중에 카이스트 프로젝트가 오픈 몇달 남기고 O사의 공략에 프로젝트가 공중분해되는 일을 겪고, 물개가 홧김에 연구소 입구를 발로 뻥 걷어차며 나가는 것을 지켜봐야 했다. 헉헉. 그 외에도 많지만 대충 이만 생략.

 

이게 다 2007년 한 해에 일어난 일이다. 평범하게 일하는 중에 애기만 나왔어도 정신없었을 텐데. 다시 생각해봐도 참 정신없던 시간이었다.

 

여기에 하나를 더 얹어야 하는 것이 바로 스프링 책 저술 계약이다. 정확한 날자는 기억이 나지 않는다. 그 뒤로 여러 차례 이사를 하면서 저술(출판인가?) 계약서를 분실해서 계약 내용도 날자도 알 수가 없다. 출판사에서 "사실은 노예계약이었다"라고 해도 할 말이 없다. 아무튼 기억 나는 건 계약을 마치고 돌아오는 길에 김희정 부사장님과 아내의 입덧에 대해 얘기를 나눴던 것으로 봐서, 입덧 기간이었던 2007년 1~3월 사이라고 추정할 수 밖에.

 

어느날 김희정 부사장님께 연락이 왔다. "한번 봐요". 바빴지만 거절을 못하는 탓에 피할 방법은 없었다. 한창 정신 없이 시간을 보내던 그때, 시청 근처에서 김희정 부사장님과 스프링 관련 저서를 준비하고 있는 다른 저자 한분을 만났다. 다른 저자와는 우연히 시간이 맞아서 같이 만나게 된 것인지 아니면, 그 분이 먼저 기획하고 저술하고 있는 책이 스프링을 사용하는 것이라서 내가 쓸 책과 내용이나 대상 독자가 중복되지 않도록 조율해보라는 출판사의 배려였는지는 잘 모르겠지만, 아무튼 모 SI업체에서 스프링을 도입하려고 노력하고 있는 분을 만나게 되서 반가웠다. 식사를 마치고 커피숍으로 가서 조금 더 이야기를 나누던 차에 김 부사장님이 가방에서 얇은 서류 하나를 꺼내셨다. 저술(출판인가?) 계약서였다. "이게요. 특별한 것은 아니고요. 부담 가지실 필요 전~혀 없어요. 내용 신경쓰지 마시고 마음 편하게 그냥 싸인만 하시면 되요." 계약을 위한 만남으로 내가 미리 알고 그 자리에 나갔는지에 대해서는 기억이 잘 나지 않는데. 대뜸 들이미시는 계약서를 보고 흠짓 놀란 기억이 있는 것으로 봐서는 아마 몰랐을 것이라는 생각이 든다.

 

역시 거절을 못하는 탓에 "네!” 하고 바로 싸인.

 

그 전에 한번 만났을 뿐인데, 내가 저술 기획서를 만들어서 제출한 것도 아니었는데 왜 갑자기 계약을 하자고 했을까 하는 의문이 들었지만, 뭐든 계약서에 싸인하고 나면 기분 좋아지는 성격 탓에 굳이 물어볼 생각은 못했다. 첫 만남 뒤로 뒷조사를 했는데 모험해 볼 만하다는 평가가 있었던 것인지 어쨌는지는 지금도 잘 모르겠다.

 

아무튼 그렇게 저술 계약을 하면서 시작된 2007년은 앞에서 얘기한 대로 정신없는 일과 사건, 새로운 경험과 예상치 못한 일정으로 가득 찼다. 스프링 책을 써야지 하는 생각이 간간히 들기는 했지만, 구체적으로 할 일이 무엇인지 꼽을 수 없는 일들이 대부분 그렇듯이 항상 우선 순위가 밀렸고 선듯 손에 잡히지가 않았다.

 

그러는 중에 갑자기 정신이 번쩍 드는 일이 일어났다. 이 얘기는 내일 계속.

 

토비의 스프링 3이 나오기까지 (3)

 

흐릿하고 왜곡된 기억과 진하게 남은 느낌을 바탕으로 쓰는 토스3이 나오기까지 세 번째.

 

사람의 기억은 쉽게 왜곡된다. 굳이 심리학이나 정신병리학 이론 따위를 들먹이지 않아도 자신이나 주위의 경험을 살펴보면 쉽게 알 수 있다.

 

예를 들어, 예전에 어떤 사람이 "토비가 영회 멘토인데, 멘토가 제대로 가르쳐주지 않아서 영회가 저 모양이다"는 식의 글을 비아냥 거리기 위해서 써논 것을 본적이 있다. 당연히 나는 영회의 멘토가 아니다. 내가 영회한테 뭘 가르쳐주거나, 영향을 준 것도 없고, 영회는 내 말 따위는 한 귀로 듣고 다른 한 귀로 흘려버린다. 어쩌다보니 같이 활동을 많이 하게되고 미운정이 많이 들어 친한척 지내는 사이일 뿐.

 

영회와의 인연은 영회가 오래전에 스프링MVC 분석 글을 쓰면서 하도 틀린 얘기를 많이 해서 매번 가서 틀린 내용을 댓글로 지적해주다가, 어느날 우연히 찌질이 EJB빠가 등장해서 영회 글을  까는 것을 보고 영회(사실은 스프링)편을 들어준 덕에 어쩌다 친해진 것이다. 강한척 하지만 사실은 매우 소심한 영회는 내가 순수하게 기술적으로 잘못된 설명을 정정해 주는 글을 남겼던 것인데도, 그 일을 지금까지 마음에 품고 있다가 얼마전에 내 책을 마감하는 시점에 축하 댓글을 술김에 남기면서 "형이 4년전에 내 블로그에 와서 댓글로 깠던 것 이제 다 용서해줄께"라고 적을 만큼 마음이 여리다. 얘기가 샜는데, 더 이상 자기 얘기를 쓰면 "토스3 홍보대사를 그만 두겠다"고 협박한게 있어서 여기까지.

 

아무튼, 하려고 했던 얘기는 왜 그 사람이 나를 영회 멘토라고 오해했을까이다. 그 사람은 멘토인 내가 권유해서 영회가 모임에 나왔다고 소개하는 것을 분명히 들었다고 주장했다. 영회가 모 협의회 모임에 처음 나갔을 때 자기 소개를 하면서, 아는 형이 권유해서 나왔다는 식으로 얘기한 것을 "아는 형 + 모임 참석 권유 = 멘토가 하는 짓"라는 자신이 친숙한 공식을 적용해서 "영회는 토비라는 멘토가 있고, 그의 권유로 모임에 나왔다"라고 인식했을 것이다. 아마 그렇게 자신에게 익숙한 개념으로 입력이 전환되서 기억에 저장되면, 나중에 기억을 더듬어보면 그게 생성하게 사실인 것처럼  인식되기 쉽상이다. 영회가 당시에 미쳤거나 여친에게 혼나고 흥분 상태에 있던 것이 아니라면 "멘토"라는 평소에 절대 사용하지 않는 말 따위는 하지 않았을 것이 분명하다는 것이 내 판단이다.

 

그래서 하고 싶은 얘기는 내 얘기도 그런 식으로 살며시 왜곡되어서 저장된 것을 바탕으로 했을 수도 있다는 disclaimer. 물론 전혀 없는 사실을 상상하거나 꾸며낸 것은 아니니, 구체적인 인용에서 일부 표현이 달라졌으면 몰라도 내 얘기가 거짓은 아닐테다. 그리고 이 블로그는 내 어설픈 기억과 경험, 지식을 꺼내놓는 장소이니 뭐 어떤가. 출간할 책도 아니고.

 

 

 

다시 2007년. 계약을 하긴 했지만 사실 책을 어떻게 쓸지, 내용은 어떤 것을 담을지에 대해서 아무런 결정된 것이 없었다. 솔직히 말해 2007년엔 책을 단 한 줄도 쓴 것이 없다. 구상은 했지만 구체적으로 기록한 것도 없다. 지난 글에서 설명했듯이 정신없는 새로운 일과 도전으로 가득찬 한 해를 보내다보니 여유가 없어서 그랬을 수도 있고, 익숙하지 않은 것을 시작하는데 어려움을 겪는 내 성격 때문이기도 했을 것이다. 거기에 하나를 더 보태자면 그다지 출판사에서 압박 내지는 재촉을 받은게 없다는 사실이다.

 

나도 영회 못지 않게 마음이 여려서 부정적인 피드백이나 노골적인 지적을 받으면 감정이 쉽게 상하고 한동안 힘들어하는 편이다. 그래서 왠만하면 남에게 지적 받는 실수를 하지 않으려고 노력하고 모든 일을 완벽하게 하려고 애쓰는 편이다. 아마도 출판사에서 "책을 언제까지 쓸거냐. 왜 빨리 안쓰냐"라고 재촉했으면 결과는 두 가지 중의 하나로 났을 것이다. 책이 어설프게 나마 빨리(2007년 내에) 나오든가 아니면 아예 책 쓰는 것을 포기했을 것이다. 내 장점은 도저히 안되겠다 싶으면 뭐든 빨리 포기하는 것이다. 또는 욕을 먹거나 지적을 받으면 다른 일을 다 제쳐두고 밤을 새서라도 빨리 일을 마무리하기도 한다. 아무튼 수시로 연락해서 진도를 확인하고, 이런 저런 경고를 받았다면 만사를 제쳐두고라도 책부터 쓰지 않았을까 싶다.

 

하지만 출판사, 내가 가진 유일한 커넥션인 김희정 부사장님은 전혀 그런 것이 없었다. 초반에 출판사 사무실을 방문하고 출판사가 주관하는 번개나 모임 등에 가서 만났던 사람들은 내가 책을 쓰기로 했다는 얘기를 하면 주위를 살피고 조용히 이런 저런 충고를 해주었다. 거의 모든 사람이 공통적으로 한 얘기는 "김희정 부사장님을 조심하라"였다. Y,K,P 님의 설명에 따르면 김희정 부사장님은 번역이나 저술이 늦어져도 절대 재촉하거나 기분 나쁜 소리를 하지 않는다. 그런데 항상 친절한 말투로 편안한 이야기를 하는 데도 불구하고 막상 역자나 저자들은 강한 압박감을 받고 꼼짝 못한다는 것이다. 그래서 친절하게 대해준다고 방심하면 나중에 부담이 100만배로 늘어나서 꼼짝 못하게 될 것이니 조심하라는 조언을 들었다.

 

사실이었다.

 

2007년에 내가 쓴 책과 관련된 유일한 내용은 다른 직원 분을 통해서 요청을 받은 "목차"가 전부였다. 사실 당시에 내가 작성한 목차는 그냥 스프링 기술 목록을 쭉 나열해가면서 형식적으로 쓴 것이다. 아직 제대로 된 구상도 안된 마당에 목차가 어찌 나올 수 있을까. 그런데 얼마 후에 만난 김희정 부사장님은 "설마 이 걸 다 쓰실려는 것은 아니죠?"라는 말로 시작해서 책을 쓰는 데 필요한 일반적인 조언을 편안하게 해주셨다. 예를 들면 "책은 초보자들이 볼 수 있도록 쉽게 써야 해요. 욕심 내지 마시고 2권(2판 말고 2권)을 추가로 낼거라는 생각으로 꼭 필요한 내용만 뽑아서 먼저 1권을 써주세요. 뭘 넣을지 고민하지 마시고 뭘 뺄지 생각해보세요"와 같은 얘기였다. 일반적이고 편안한 얘기였는데 이 얘기가 한 번 두 번 반복되다보니 나중에는 원고를 쓰려고 워드를 열 때마다 머리 속에 "초보자, 쉬운 책, 2권 내용은 빼고 일단 1권용, 뭘 뺄까…"와 같은 말들이 머리 속에 떠돌아 다니는 정도가 됐다. 거의 강박관념이 되다보니, 한 문단을 써놓고 다시 읽어본 뒤에 "이걸 더 쉽게 풀어 써야햇"이라는 생각에 그걸 다시 풀어서 2페이지로 늘려 쓰게 되는 식이었다. 편안한 말투와 조언에도 순진하고 착한 나같은 엔지니어 출신 초보 저자가 얼마나 쉽게 세뇌될 수 있는지를 나중에야 깨달았다.

 

아무튼, 아무리 진도가 나가지 않아도 충격적인 얘기나 경고 같은 것은 전혀 들을 수 없었다. 오히려 내가 가장 많이 들은 얘기는 "많이 기대하고 있어요"였을 뿐. 또는 다른 책 얘기, 다른 번역 얘기, 다른 저자 얘기 등등. 과도한 친절을 받았을 때 쌓이는 부담감이 그렇게 늘어나고 있을 때 어느날 충격적인 얘기를 들었다.

 

바로 나를 출판사에 소개시켜준 정희용 편집장(아마 당시엔 마소 편집장이었을 것이다)이 어느날 메신저에 들어오더니 "형, 제발 책좀 빨리 써줘. 출판사 들어갈 때마다 내가 맨날 혼나. 도데체 이 사람은 책을 언제 쓰는 거냐고 나만 깨진단 말이야"라는 말을 남겼다.

 

두둥. 이런 저런 다른 바쁜 일들이 거의 머리 속을 점령하고 있어서 가끔 떠오르는 책을 써야겠다는 부담감을 자꾸 뒤쪽으로 몰아내고 있던 차에, 그런 얘기를 들으니 얼굴이 화끈거리고 가슴이 두근두근. "알았어 빨리 쓸게 걱정마"라고 말을 하고 나니 식은 땀이 흘렀다.

 

물론 그 일이 있고 나서도 2007년이 끝나기까지 원고는 한 줄도 쓰지 않았지만, 이전보다는 훨씬 커진 부담감으로 책의 내용과 구성을 구체적으로 생각하게 됐다. 그로부터 2년 넘게 더 시간이 걸리긴 했지만 그래도 그때 긴장속에서 구상했던 내용과 구성이 지금 책의 바탕이 되었다.  책 내용을 구상한 얘기는 다음에 하고, 일단 그때 느낌을 조금 더 적어봐야겠다.

 

희용이의 얘기를 듣고 나니 나에게 조언해주던 여러 다른 역자, 저자 내지는 출판사에 들락 거리던 사람들의 얘기가 떠올랐다. 편안하게 대해준다고 내가 너무 방심했나하는 생각이 들기도 했다. 그러면서 한편으로는 의심이 들기도 했다. 과연 희용이의 얘기는 얼마나 진실일까? 지금까지도 의문이다. 세 가지 가정을 해봤다. 첫째는 정말 김 부사장님은 내가 책을 빨리 안써서 대단히 화가 나있었고, 그 때문에 나를 추천해준 희용가 정말 매번 혼났다는 것. 그래서 맘 착한 희용이가 견디다 못해 나한테 얘기를 했다는 생각. 두 번째는 사실 김 부사장님은 편안하게 "책이 좀 늦어지는 것 같은데, 어쩌나"라는 식으로 편안하게 얘기했지만 희용이가 이를 과정해서 자기가 맨날 혼난다고 중간에서 상황을 조작했다는 것. 경험도 없는 초짜 저자를 소개해준 사람으로서 부담이 있으니 그랬을 수도 있다는 생각. 마지막으로는 스스로 찔린 희용이가 얘기를 지어냈을 것이라는 것. 사실은 김 부사장님은 별다른 얘기가 없었음에도 진도가 안나가는 것을 눈치챈 희용이가 꾀를 내서 나한테 부담이 가도록 "내가 형 때문에 맨날 혼나. 살려줘"라고 했을 수도 있다는 생각.

 

얼마전에 처음으로 확인해보니 희용이는 당연히 첫 번째라고 대답했다. 나는 세 번째라고 믿고 싶은데…

 

몇 가지 이후에 일어난 일을 참고해서 생각해보면 첫 번째였을 가능성이 높다. 예를 들어 책이 거의 마무리될 즈음에 아마도 내가 부담이 많이 없어졌을 것이라고 생각하셨는지 김희정 부사장님은 이런 얘기를 하셨다. "그동안 재촉해 드리지 못해서 미안해요. 재촉한다고 빨리 썼을 것도 아니고해서…". 또, 희용이는 추천사에 "책이 나오지 못하게 될까바 조마조마 했다"고 쓰기도 했다. 흑.

 

남은 의문은 희용이가 나에게 그 얘기를 전달한 것이 단지 나랑 친한 사이였고, 소개한 사람 입장에서 얘기를 해줘야 겠다는 스스로의 판단에서 였는지 아니면 김 부사장님의 고도의 계산, 즉 측면 공략의 결과였는지이다. 원래 군대나 직장에서도 고참이 신입에게 직접 뭐라고 하지 않는다. 다 중간을 불러서 대신 깬다. 사실 신병 입장에서는 그게 더 견디기 힘들다. 내가 이병 때 당시 소속해 있던 군악대 분위기가 좀 늘어졌을 때가 있었다. 특히 행사나가서 삑사리 나는 게 늘면서 당시 최고참들이 좀 화가났던 것 같다. 연습실로 집합. 그리고 자기 바로 아래 교육 기수를 불러내서 우리가 보는 앞에서 교육 기수를 굴렸다. 차라리 다 같이 깨주면 좋은데… 그 뒤에 일어난 일은 설명 안해도 알만할 것이다. 사실 직접 구를 때는 맘이라도 편하다. 오히려 우리가 잘못한 것 때문에 중간 기수가 깨지는 것을 보는게 더욱 힘든 일이었다.

 

차라리 내가 직접 잔소리를 들었다면 나았을 텐데, 착한 희용이가 나 때문에 맨날 혼나고 다닌 다는 얘기를 들으니 두 배로 마음이 아팠다. 부담은 세 배로 커졌고. 내가 궁금한 것은 과연 그 때 일이 고도의 계산에 따라 일어난 일이지의 여부인데. 그 뒤로도 직접 대면하거나 대화를 할 때는 나에게 계속 친절하게만 얘기해주신 것을 보면 이게 참 헷갈린다. 적당히 의심은 가지만 사실 확실히 알 수 없을 때 사람은 더 긴장하게 된다. 아마 나에게 조언해 줬던 역자, 저자 분들이 경험했던 강한 압박감도 아마 그런 혼란이 가중되서 발생한 것이 아닐까. 친절한 정면 공략과 강력한 측면 공격의 콤보.

 

그 날 이후로 책을 빨리써야 겠다는 생각과 부담 없이 하루도 잠자리에 든 적이 없는 것 같다. 문제가 있으면 그걸 해결해야 부담이 풀린다. 일 때문에 받은 스트레스는 일을 해버리면 풀린다. 그런데 이 놈의 책은 하루 이틀에 쉽게 해결할 수 있는 것이 아니니, 그 스트레스가 얼마나 대단했을까.

 

그런 부담 속에서 본격적으로 시작된 책 구성과 저술 시작, 그리고 호주로의 이주 등등에 대해서는 다음 시간에 계속.

 

토비의 스프링 3이 나오기까지 (4)

 

토비의 스프링 3이 나오기까지의 이야기를 담은 토비 스토리 네 번째 이야기.

 

다시 2007년. 스프링 책을 어떤 식으로 쓸 것인지 질문을 받으면 항상 이런 얘기를 했다. 기존 스프링 책들은 1장에서 스프링 역사로부터 시작해서 J2EE과 스프링의 관계 등등의 장황한 스프링 소개를 한 뒤에, 바로 2장에서 IoC를 몽땅 다루고, 3장에서 AOP를, 4장에서 JDBC를 다루는 식으로 접근한다. 내가 느낀 문제는 스프링을 처음 접하는 사람에게 스프링의 프로그래밍 모델이 뭔지 감을 잡기도 전에 2장에서 스프링의 모든 DI 고급기법까지 다 설명하는 것이다. DI가 뭔지 아직 감을 잡지도 못한 사람한테 나도 아직 잘 사용하지 못하는 빈의 라이프사이클 메소드니 빈/빈팩토리 포스트프로세서니 하는 것까지 다 설명을 해버리면 여기서 벌써 기가 죽는다. 머리 속에선 스프링이란 뭔가 복잡한 설정방법을 알아야 하는 것이라고 단정짓게 된다. 그리고 나서 바로 AOP로 넘어간다. AOP는 더 가관이다. AOP를 다루는 장의 처음 몇 페이지는 온통 생소한 용어소개 뿐이다.  AOP, 애스팩트, 조인포인트, 포인트컷, 위빙, 어드바이스, 인트로덕션, 횡단관심이 어쩌고 저쩌고. 아무리 깔끔한 정의를 적어놨다고 한들 용어가 머리속에 제대로 들어올리가 없다. AOP를 이용한 로깅이니 보안이니 하는 예제까지 다루고 포인트컷 표현식 따위나 포인트컷 확장 빈 등록, 자동 빈 생성기 이런 것들이 마구 소개되는 것을 보면 일단 AOP는 제껴두자고 마음을 먹게 된다. SpringMVC는 어떤가? 갑자기 7가지 디스패처서블릿의 전략이 쭉 소개된다. 그리고 공포의 SimpleFormController가 떡 하니 등장하면 정말 기가 팍 죽는다. 어려운 SpringMVC를 쓰느니 익숙한 스트럿츠1을 사용하든지, 아니면 일단 처음 접근(만)은 간단한 웹워크, 스트럿츠2가 더 나아보일 것이다.

 

모 교육센터의 강사로 활동했던 친한 형 한명은 스프링을 제대로 공부해보겠다고 여러 책을 붙잡고 밤낮을 끙끙댔음에도 도무지 뭐가 뭔지 모르겠다는 푸념을 하기도 했다. 특히 AOP는 설명을 아무리 읽고 또 읽어도 이해가 되지 않는, 안드로메다 외계 테크롤로지로 보인다는 것이다. 그냥 배껴서 쓸 수 있는 예제 하나 없을까 찾기에 바빴다. 아마 적지 않은 개발자들이 그런 비슷한 과정을 밟지 않을까 하는 생각이 들었다. 스프링이 유행이라니까 다음 프로젝트부터 적용하라는 위로부터의 일방적인 지시가 떨어지고, 급한 마음에 시중에 나와있는 책들을 구해서 공부를 해보는데 이게 난생 처음 들어보는 용어와 복잡해보이는 XML이 난무하고, 책의 예제를 따라해봐도 대충 어떻게 배껴서 비슷하게 만들면 되겠다는 감은 오지만 도대체 스프링이 뭔지, 뭐하러 쓰는지 마음에 다가오는 것이 없고, 이걸 도대체 뭐하러 써야 하나하는 불만이 들기 쉽상일 것이다. 내가 직접 들은 그런 불만만 해도 적지 않다. 사실 그런 유행에 휩쓸려 스프링을 급하게 사용하기 시작하다가 스프링에 안좋은 인상만 남게 되는 일도 흔했다. 그래서 한동안은 스프링을 쓰지 말라고 말려야 겠다는 생각이 들기도 했다. 그래서 블로그에 "스프링을 쓰기 위해서 스프링을 쓰지 말자"라는 얘기를 적기도 했다. 단지 스프링이 유행이니까 사용해야겠다는 생각으로 스프링을 사용하지는 말라는 얘기다.

 

스프링은 쉽지 않다. 왜냐하면 스프링은 쉽지 않은 자바 엔터프라이즈 애플리케이션의 개발을 다루고 있기 때문이다. 또 스프링은 한 가지 단순한 접근방법만 파는 대신 수 많은 옵션과 다른 프레임워크와의 조합을 적극적으로 제공하기 때문이기도 하다. 자유도가 매우 높은 RPG 게임과 비슷하다고나 할까. 대신 스프링을 관통하는 기본 원칙과 프로그래밍 모델, 디자인 패턴은 매우 명확하고 분명하다. 문제는 스프링 책이나 교육이라는 것이 지면과 시간의 한계 때문에 레퍼런스식 설명에 그치거나 아니면 간단한 예제 하나에  매몰되기 쉽상이라는 것이다. 특히 예제 중심의 접근은 초반에는 쉬워보이지만, 자칫하면 특정 방식의 스프링 사용방법이 전부이거나 가장 좋은 것이라는 잘못된 인식을 줄 수 있고, 예제 코드를 기계적으로 복사해서 전혀 컨텍스트가 다른 곳에서 사용하는 일이 일어날 수도 있다. 스프링이 지지하는 탄탄하고 일관된 프로그래밍 모델 + 다양한 기술의 선택과 조합 대신 개념 없는 대충대충 프로그래밍 모델 + 특정 기술과 개발 패턴의 기계적인 적용만 남게 되는 문제가 일어날 수 있다는 뜻이다.

 

물론 현명한 개발자들은 그런 자료와 서적, 교육 등을 통해서 얻은 지식을 기존 경험과 잘 결합시켜서 스프링의 본질이 무엇인지 깨닫고 지혜롭게 응용할 줄 알 것이다. 하지만 적지 않은 초보자들은 그런 오해를 하기 쉽다.

 

그래서 스프링 책을 쓰기가 막막했다. 어쨌든 스프링의 기술을 다뤄야 하니, IoC, AOP, JDBC, MVC 등의 내용을 하나씩 설명할 수 밖에 없을테고, 동시에 스프링을 통해서 만들어지는 엔터프라이즈 애플리케이션의 전체 그림, 그리고 실제 코드를 예제로 보여주지 않을 수도 없는 노릇이니 내가 우려하던 그런 문제들을 쉽게 피할 방법은 없다고 생각이 됐다. 그래도 스프링 설명을 너무 관념적으로 가져가거나 현실과 동떨어진 설명을 택하는 것은 피해야겠다고 생각했다. 예를 들어 DI를 설명하면서, 절대로 실전에서는 경험해본 적이 없을 것이 분명한 도메인 오브젝트 내의 DI를 들어 설명하는 것 따위는 피해야 할 것이라고 생각했다. 실전에서 자주 접하는 코드이면서, 그래도 스프링의 특징을 잘 드러낼 수 있는 POJO에 로직이 잘 드러나있는 그런 코드가 뭐가 없을까 하는 고민을 계속 했다.

 

그래서 한 동안은 쌈박한 예제 하나만 먼저 만들어보면 책을 쓰는 것은 어렵지 않겠다고 생각했다. 프로그래밍 서적에서 자주 사용되는 쇼핑몰이나 블로그 따위는 사실 스프링으로 만들만한 애플리케이션도 아니고, 스프링의 POJO 중심의 개발이 주는 장점을 보여줄만한 예제로서 적합하지도 않았다. 그래서 실제 SI현장의 도메인에서 예제를 찾아보려고 했다. 그렇다고 특정 도메인의 예제를 사용하면 도메인을 이해하지 못하는 독자들에게 이중의 부담이 될 수 있으니 누구나 쉽게 이해하고 알만한 것이 뭐가 없을까 고민했다. 나는 스프링으로 제조업체의 ERP 전체를 개발해본 경험이 있으니 제조업체의 다양한 도메인에 스프링을 어떻게 적용할지에 대한 충분한 이해는 있었다. 그 중 쉬운 것을 찾자면 재고 관리 시스템에 괜찮다는 생각이 들었다. 다양한 재고 관리 기법을 DI를 이용해서 교체해서 로직을 적용하는 것도 구상해봤다. 하지만 깔끔하게 책의 예제로 쓸만한 도메인 로직으로 축소해 내기가 쉽지는 않았다. 그래서 주변의 SI 전문가-컨설턴트에게 예제에 사용할만한 도메인 모델을 좀 요청해봤다.

 

여러명의 SI업체나 금융계에서 활동하는 컨설턴트에게 요청을 해봤지만 다들 대답만 시원하게 했을뿐 건네주는 것이 없었다. 실제 도메인의 모델을 다 주자니 복잡하기도 하고, 보안의 문제도 있고 그렇다고 책의 예제로 할만큼 단순화 하자니 귀찮고, 그래서 대답만 하고 다들 나몰라라. 대표적으로, 개발자가 아닌 CBD와 모델링 컨설턴트 출신의 영회는 자기가 교육할 때마다 쓰던 모델이 있으니 걱정말라고 큰소리만 뻥뻥 치고는 끝까지 모델 그림 한장 제공해주지 않았다.

 

그렇게 시간이 지나면서 쌈박한 예제 하나만 있으면, 이를 만들어가는 과정을 담아서 책을 쓰면 되겠다는 환상이 서서히 깨지기 시작했다. 예제에 사용할 도메인 모델과 로직은 얼마든지 내 스스로 만들어도 그만이라고 생각을 했지만, 문제는 특정 예제 하나를 중심으로 스프링을 설명하는 것이 얼마나 위험한지에 대한 염려가 커졌기 때문이다.

 

2007년 봄에 벨기에에서 열린 스프링원 유럽에 참석했을 때 스프링 2.1(당시엔 2.5가 아니고 2.1이 계획이었다)에 포함된 애노테이션을 이용한 DI 방식이 나온다는 것을 처음 알게됐다. 그리고 얼마지나서 2.1이 2.5로 버전이 바뀌어서 출시되면서 새롭게 @MVC 웹 기술이 포함되었다는 것도 보게됐다. 그 외에도 제법 다양한 방식으로 스프링의 기술의 폭이 넓어졌다. 스프링 애플리케이션을 만들 때 선택할 수 있는 옵션의 종류가 많아진 것이다. 그리고 그해 11월 샌프란시스코에서 열린 QCon에 참석했을 때 로드 존슨의 스프링 2.5 세션에 들어갔는데, 로드 존슨이 2.5의 새로운 기능을 소개하기에 앞서서 ‘스프링은 선택이다(Spring is about choice)’라느 유명한 말을 던지면서 스프링을 사용할 때 적절한 기술을 선택하고 조합하는 것이 얼마나 중요한지 강조하는 것을 들었다. 1.x에서는 엔터프라이즈 개발에 꼭 필요한 필수 기술을 추가하는 것에 집중했다면, 2.x에 들어와서는 다양한 기술과 설정에 대한 접근방법을 제공해서 개발자 자신의 선택의 폭을 넓히는 데 주력했다고 보여졌다. 그런 마당에 특정 접근방법 한 두가지밖에 적용할 수 없는 예제 하나로 책을 써버리면 적지 않은 사람들이 그게 스프링을 사용하는 유일한 내지는 최고의 방법이라고 오해하기 쉽상일 것이라는 걱정이 들었다. 그래서 그 즈음에 엔터프라이즈 애플리케이션 예제 하나를 완성해나가는 과정을 담아서 책을 쓰겠다는 생각을 포기했다.

 

또, 다시 고민 시작. 그러는 중에 정희용 편집장을 통한 측면 공격으로 상당한 내상을 입은데다, 쏟아져 나오기 시작하는 스프링 2.5책을 보면서 책을 빨리 내야 한다는 부담이 크게 가중되고 있었다.

 

그런데 사실 그때 가장 큰 고민은 앞으로 어디에서 살아야할 것인가 였다. 평화는 태어났고, 일단 처가와 본가를 오가며 생활은 할 수 었지만, 어디엔가 정착이 필요했다. 여러 가지 후보가 있었다. 일단 한국에서 계속 지낸다면 쉽게 일은 할 수 있을 듯 싶었다. 당시에 많은 기업에서 스프링 컨설팅이나 프레임워크 개발요청이 끊이지 않았다. 일은 내가 맘에 드는 것을 골라서 얼마든지 할 수 있는 상황이었다. 재외동포비자를 받았으니 장기체류를 하면서 내국인과 동일한 혜택을 받고 일하는 데도 아무런 문제가 없었다. 한편으로는 미국으로 가고 싶은 마음도 들었다. 미국에서도 끊임없이 호출이 있었다. 내가 말하기도 전에 먼저 이민변호사와 협의해서 이민에 필요한 수속과정을 알아보고 있던 기업도 있었다. 스폰서가 되줄테니 오기만 하라는 기업이 여럿 있었으니 원한다면 얼마든지 미국으로 가서 생활하고 장기적으로 미국으로 영구이주하는 것도 고려할 수 있는 상황이었다. 동시에 중국으로 가고 싶은 마음도 들었다. 2007년에 처음으로 방문했던 중국은 상당히 매력적이었다. 중국에 비즈니스를 시작하고 한국과 호주에 연계해서 일을 할 수 있겠다는 생각도 들었다. 투자를 하겠다는 사람도 나왔고 비즈니스 리서치를 위해서 여러 번 방문도 했고, 현지 코디네이터를 해주실 전문가도 알아두었다. 무엇보다도 한국과 가깝다는 것이 매력적이었다. 이렇게 한국, 미국, 중국을 놓고 저울질 하고 있었지만 한편으로는 호주 생각이 간절했다.

 

나의 20대 후반과 30대 초반을 보낸 곳. 안정적인 한국의 직장 생활을 포기하고 바닥으로 내려가 모든 것을 다 도전하면서 생활해왔던 시간들, 그리고 내가 좋아하는 깨끗하고 아름다운 자연과 친절한 사람들, 여유있는 삶 등등. 나에게는 제2의 고향과도 같은 곳이고 마음의 안정을 누릴 수 있는 곳이기도 하다. 특히 평화가 태어나고는 복잡한 서울이 싫어졌다. 뭔가 새로운 도전을 하면서 다른 곳으로 갈 수도 있었지만 아마도 그런 삶을 살다보면 평화와 같이 시간을 많이 보내기 힘들 것이라는 생각이 들었다. 돈이나 성공, 직업과 비즈니스의 안정보다는 가족과 많은 시간을 보낼 수 있는 평화로운 삶을 선택하고 싶다는 생각이 들었다. 한국에서 생활하는 동안 아침 6시에 집을 나서서 밤 11시 반이 되야 돌아오는 생활에 익숙해있었다. 평화는 자는 모습 밖에 보지 못했다. 주말에도 세미나나 각종 모임에 나가느라 많은 시간을 보낼 수 없었다. 같이 다닐만한 곳도 많지 않았다.

 

그래서 많은 고민 끝에 다시 호주로 돌아가기로 마음을 먹었다. 그와 동시에 본격적으로 책을 쓰는데 시간을 쓸 수 있겠다는 기대가 들었다.

 

그러던 어느날 기선이와 함께 분당의 KT IDC에 서버 작업 때문에 방문할 일이 있었다. 분당으로 가면서 기선이랑 이런 저런 얘기를 하는 도중에 갑자기 애자일 자바(Agile Java)라는 책이 떠올랐다. 애자일 자바는 테스트 코드를 이용해서 자바의 기능을 설명하는 독특한 방식으로 주목을 끌었던 자바 입문서이다. 영회가 만들어서 한 동안 활발한 활동을 펼치다 지금은 사라진 애자일 자바 네트워크(AJN)는 바로 이 책을 이용해서 스터디를 하는 모임으로 출발한 것이다. 아무튼 그 책의 독특한 설명방법이 떠오르면서, 스프링도 그렇게 설명할 수 있지 않을까 하는 생각이 들었다. 스프링과 테스트는 뗄 수 없는 관계다. 스프링이 POJO 프레임워크라고 본다면 POJO 프레임워크로서 스프링의 가치는 절반은 기술과 환경에 독립된 코드라는 것이 둘 수 있고 다른 절반은 POJO가 가지는 테스트 편의성에 둘 수 있을만큼 테스트는 스프링에서 아주 중요한 의미를 가진다. 당연히 스프링 책에서 테스트에 대한 내용을 충분히 넣고, 강조할 생각은 가지고 있었지만 아예 테스트를 이용해서 스프링의 기술을 설명할 생각은 미처 못하고 있었다. 그런데 갑자기 애자일 자바가 떠오르면서 내 책도 그렇게 가야겠다는 생각이 들었다. 책 이름은 애자일 자바를 배껴서 애자일 스프링!

 

일단 잠정적으로 책 이름은 애자일 스프링으로 정했고, 학습 테스트 코드를 활용해서 스프링의 다양한 기능을 보여주고 설명하는 방식으로 내용을 작성해야겠다는 생각이 들었다. 그러면 특정 방식에 제한되는 예제에 매몰되지 않고 스프링의 다양한 접근방법을 보여줄 수 있겠다는 생각이 들었다.

 

이렇게 해서 2007년이 지나가고 드디어 스프링 책을 쓰기 시작한 2008년 밝았다. 여기서부터는 내일 다시.

 

토비의 스프링 3이 나오기까지 (5)

 

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

 

일년여의 고민끝에 스프링 책을 어떻게 쓸지 큰 그림을 그린 채로 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월이었다.

 

토비의 스프링 3이 나오기까지 (6)

 

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

 

본격적으로 책을 쓰기로 결심하고 나서 가장 먼저 시작한 일은 스프링 공부였다. 스프링에 대해서는 누구보다 더 많이 연구했고 알고 있다고 자신하지만, 그래도 내가 자주 사용하지 않는 옵션들과 접근방법들에 대해서 꼼꼼하게 점검해볼 필요가 있다는 생각이 들었다. 스프링 2.5.6의 레퍼런스 매뉴얼을 처음부터 꼼꼼하게 읽어나가면서 그 내용 하나 하나를 학습 테스트로 만들기 시작했다. 코드를 만들어 확인해보지 않은 지식은 내 지식이라고 할 수 없다는 평소의 지론대로 내가 써보지 않은 옵션과 조합, 설정 방식 등을 모두 한 번씩 적용해가며 테스트 코드를 만들어 나가기 시작했다. 학습테스트를 이용한 학습방법은 내 블로그에도 한 번 썼듯이 매우 유용하고 확실한 기술 습득 방법이다. 애자일 자바는 자바 언어 수준에서 초보적인 학습테스트를 활용한 것이다. 그렇게 레퍼런스의 내용을 빠짐없이 테스트로 만들어나가면서 스프링의 다양한 기술조합을 공부하다보니 시간이 적지 않게 흘렀다. 내가 익숙지 않은 몇 가지 기술과 테스트 작성하기가 힘들어보이는 웹 기술을 빼고 나머지 모든 스프링 기술에 대해서 학습 테스트 작성을 끝내고 나니 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년 가까이 되가는 마당에, 그나마 썼던 원고는 영회의 이단 옆차기로 모두 날려버린 상태. 그리고 완전히 백지에서 다시 쓰기로 마음먹은 상황에서 김희정 부사장님을 만나게 된 이야기. 그리고 영회에 대해서 복수의 칼을 갈기 시작하고 일년 간의 치밀한 계획 끝에 복수에 성공한 이야기 등등은 내일 계속.

토비의 스프링 3이 나오기까지 (7)

 

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

 

날려버린 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 회장 전격 교체작전 등등에 대해서는 내일 다시.

 

토비의 스프링 3이 나오기까지 (8)

 

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

 

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

 

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

 

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

 

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

 

그런데 정작 내가 감동한 것은 그 후의 일이다. 영회가 특강을 했던 교육원 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%쯤은 밥을 먹이는데 들어갔다. 까다로운 입맛에 맞춰서 음식을 준비해야 하고, 한번 시도해서 안되면 다시 다른 음식을 준비해야 했다. 아무거나 주면 잘 먹고 자기가 먼저 밥 달라고 한다는 애들 얘기를 들으면 그렇게 부러울 수가 없었다. 물론 평화가 더 어렸을 때는 주는 대로 잘 받아먹었고, 우리도 음식을 골고루 먹이려고 제법 많은 노력을 들였다. 인스턴스나 미리 준비된 음식은 거의 먹이지 않고 다양한 재료를 골고루 먹게 하려고 노력했다. 하지만 입맛 까다로운 나를 닮은 평화는 자기가 음식을 거부할 수 있음을 알게되면서부터는 쉽게 입을 열지 않았다. 게다가 자기 그릇에 놓인 음식이 맘에 안드는데 자꾸 먹으라고 채근하면 짜증이나서 음식이나 그릇을 던져버리는 일도 있었다. 그때마다 혼을 내고 타일러봐도 별 소용이 없었다. 그렇게 하루 하루가 전쟁이었다. 잠을 재우는 것도 쉽지 않았다. 낮잠을 제대로 못자면 저녁 때 힘들어하고 짜증을 많이 내기 때문에 낮잠을 꼭 재워야 하는데, 이게 타이밍을 놓치면 쉽지 않다. 정 안되면 차를 태우고 한 바퀴 돌면서 재우기도 했는데 어떨 때는 한 시간 넘게 운전을 해도 잠이 들지 안을 때도 있었다.

 

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

 

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

 

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

 

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

 

토비의 스프링 3이 나오기까지 (9)

 

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

 

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

 

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

 

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

 

저자의 성의가 부족해서 잘못된 사실이나 설명을 책에 남기는 것은 어떻게든 피하고 싶었다. 그래서 스프링 기술에 대한 설명은 문서만 참고해서 작성하지 않고 일일이 학습테스트를 만들어서 내 눈으로 동작하는 것을 직접 확인하려고 노력했다. 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시.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

토비의 스프링 3이 나오기까지 (11)

 

점점 지겨워지긴 하지만 마무리는 해야 하니까. 처음 이 글을 쓰기 시작했을 때 생각처럼 어떤 시간이었든 책을 써왔던 지난 시간을 한번 정리하고 나서 다 잊어야지. 차마 글로는 옮길 수 없는 유쾌하지 못했던 기억들이 더 많았던 지난 2년여간의 시간들. 어쨌든 정리는 하고 넘어가야 하니까.

 

한국에서 돌아온 뒤 거의 하루 15시간 이상 책을 쓰는 데 매달렸다. 일단 흐름을 타고 나니 1부를 마무리 하는 것은 쉬웠다. 스프링 핵심기술 소개는 6장에서 마무리했지만 거기서 만족할 수 없었다. 단지 스프링이 이렇게 OO와 DI를 비롯한 핵심가치를 자신에게 적용했다는 것을 이해하는데 만족하지 말고 그것이 스프링 사용자 자신의 코드에도 그대로 적용될 수 있기를 바랬다. 그래서 7장을 썼다. 내용은 엉성할지 모르겠지만 7장은 내가 이 책에서 가장 아끼는 장이다. 책을 통해서 내가 가장 하고 싶었던 이야기이기도 하고. 그리고 1부의 마무리로 처음 써놨던, 버리려고 했던 1장을 넣기로 했다. 물론 거의 새로 쓴 것이긴 하지만. 원래 가장 먼저 얘기하려고 했던 도대체 스프링이란 무엇인가라는 질문과 그에 대한 내 생각을 간략하게 정리했다. 1부 끝. 한국을 다녀와서 며칠 지나지 않아 1부를 마쳤다.

 

그리고 스프링의 기술을 주제별로 설명하는 2부 시작. 2부는 1부보다 훨씬 쉬울 것이라고 생각했다. 그저 스프링의 기술을 쭉 나열해가며 사용방법을 설명하고 평소에 생각해뒀던 선택 기준에 관한 내 의견을 넣으면 될 테니까. IoC/DI를 다루는 10장에서 이미 600페이지가 훌쩍 넘었다. 800페이지가 목표니까 이제 얼마 안남았다고 생각했다. 미리 준비해뒀던 학습 테스트 코드도 많은 도움이 됐다. 그리고 스프링 3.0도 RC버전이 출시되고 최종 릴리스가 눈 앞에 보였다.

 

이제 끝인가 보다 생각하면서 12월이 시작됐다. 그리고 처음으로 용기를 내서 김희정 부사장님께 먼저 연락을 했다. 늦어도 12월 말까지는 초고를 드릴 수 있을 것 같다고 말씀드렸다. 스프링은 예상과 달리 계속 지연되서 12월 중순에나 나오게 됐고 약속대로 스프링 출시에 맞춰서 책이 나올 수 있을 것 같다고 얘기했다. 물론 스프링이 늦게 나올 것이란 건 충분히 예측했던 일이었으니 다르긴 뭐가 달라. –_-; 죄송하니까 말이라도 그렇게 했어야지.

 

아내도 11월 말에 학기를 마쳤고 집안일을 전담할 수 있게 됐다. 나는 그저 12월 무더위와 싸우면서 미친듯이 마무리 해나가면 될 것 같았다. 하지만 예상치 못했던 일이 생겼다. 아내가 임신을 한 것이다.

 

결혼 후 거의 7년만에 평화를 가질 때는 병원의 도움을 받아야 했다. 쉽게 아이가 생기는 체질이 아니라고 했다. 아내는 계속 둘째를 원했다. 혼자는 외로우니까 친구처럼 지낼 형제가 있어야 한다고. 나도 둘째가 있으면 좋겠다고 생각은 했다. 하지만 쉽게 생길 것이라고 기대를 하지는 않았다. 아마 또 병원에 다녀야 하지 않을까 싶었다. 그런데 어느날 갑자기 둘째가 생겼다.

 

병원에 가보니 5주라고 했다. 한편으로 기뻤지만 다른 한편으로는 걱정이 시작됐다. 평화를 가졌을 때 지독하게 심한 입덧을 했던 것이 기억났다. 입덧이 없거나 가볍게 지나는 사람도 있지만 지독하게 심한 입덧을 경험하는 사람도 있다. 오죽 심하면 출산 때의 고통 때문이 아니라 입덧 때문에 아이를 가지는 것이 두렵다는 얘기를 할 정도다. 아내가 딱 그랬다.

 

입덧이 서서히 심해지면서 중병을 앓는 사람처럼 누워있어야만 있어야 했다. 물 조차도 마시기 힘들어 했다. 겨우 물 한모금을 마셔놓고 그보다 훨씬 더 많이 토하기도 했다. 평화를 가졌을 때 입덧하면서 자주 먹었던 누릉지를 만들어서 끓여주었지만 그것도 거의 입에 대기 힘들어했다. 평화 때보다 훨씬 빨리 입덧이 시작됐고 훨씬 더 심하게, 오래 진행됐다. 원래 둘째는 입덧이 덜하다는 얘기도 있는데 다 뻥이다. 평화 때처럼 친정에 가있을 수도 없었다. 그렇다고 누군가 와서 도와줄 사람도 없었다. 하루 종일 침대에 누워서 괴로워하다가 물 몇 모금, 묽게 만든 누릉지 조금 먹고 그리고 수시로 토하고. 냄새 때문에 방 밖으로 나오기도 힘들었다. 평화랑 놀아주는 것도 물론 불가능했다. 갑자기 모든 집안 일과 평화를 돌보는 것이 내 책임이 됐다. 겨우 짬을 내서 회사 일에 시간을 쓰고 나면 원고를 쓸 시간이 없었다.

 

아침에 일어나면 평화를 어린이집에 보낼 준비부터 해야 했다. 평화 점심 도시락을 만들고 간식과 준비물을 챙기고 평화를 깨워서 씻기고 아침을 먹이고 어린이집에 데려다 주고 왔다. 돌아오면 집안 청소와 설거지, 세탁을 하고 아내 상태에 따라서 먹을 음식을 준비해야 했다. 평화를 가졌을 때는 다른 음식에는 전혀 손을 대지 못했지만 누릉지 끓인 것은 겨우 겨우 먹었던 기억이 났다. 한국에서처럼 누릉지를 쉽게 구할 수 없으니 내가 직접 만들어야 했다. 밥을 후라이팬에 얇게 깔고 가장 약한 불에 1-2시간 두면 그럴싸한 누릉지가 만들어진다. 입덧이 심하면 맹물도 제대로 못삼킨다. 억지로 마셨다가 토하면 오히려 수분이 더 빠져나가서 좋지 않다. 그래서 누릉지를 끓어서 먹이려고 노력했다. 그것도 며칠 가지 못했다. 아예 하루 종일 물 몇 모금 말고는 아무것도 먹지 못하기 시작했다.

 

도저히 안되겠다 싶어서 병원에 가봤다. 의사는 상태가 안좋다고 구토억제제를 처방해줬다. 하지만 약을 먹어도 별 효과가 없었다. 입덧을 시작하고 입덧 시작하고 2주가 지났을때 몸무게가 5킬로나 빠져있었다. 동네 병원에서 검사를 해보더니 상태가 많이 안좋다고, 그대로 있으면 엄마도 태아도 위험하니 얼른 종합병원 응급실로 가라고 했다. 응급실 의사는 입원을 해야 할 수도 있다고 했다. 그나마 응급실에서 구토억제제 주사와 수액 두 팩을 맞고 나니 겨우 혈색이 돌아왔다. 수분이 공급되면서 상태가 호전되니 입원은 하지 않아도 괜찮겠다고 했다. 대신 보통 구토억제제로는 안될 것 같고 말기 암 환자나 수술한 환자들이 먹는 쎈 구토억제제를 먹으라고 했다. 그나마 그 약을 먹으면 잠시라도 역겨운 것이 덜해서 물이라도 조금씩 마실 수 있게 됐다.

 

평화도 당황했다. 항상 자기랑 놀아주고 안아주던 엄마가 하루 종일 침대에 누워있기만 한데다 엄마 곁에 가지 못하게 내가 자꾸 떼어 놓으니 속상했을 것이다. 나도 종일 집안일을 하거나 틈틈이 원고 몇 줄이라도 써야 했기에 평화랑 놀아줄 시간이 별로 없었다. 낮에는 어린이집에 보내고 돌아오면 좋아하는 비디오를 틀어주고 앉혀놓는 수밖에. 어린이집에 안가는 날은 하루 종일 비디오와 TV만 봤다. TV가 지겨워지면 나에게 와서 놀아달라고 칭얼거리며 손을 잡아 끌었다. 잠시 놀아주다가 괜찮은 것 같아 자리에 돌아와 원고를 좀 더 쓰고 있으면 어느새 다시 달려와서 나를 잡아 끌었다. 낮잠은 물론이고 밤에도 내가 평화를 재워야 했다. 운이 좋으면 같이 누워서 30분만에 잠들기도 하지만 보통 잠이 들려면 1-2시간은 걸렸다. 잠이 든 걸 확인하고 나와서 다시 아내를 돌보거나 집안일을 해야 했다.

 

집안일이라는게 정말 끝이 없었다. 아내는 본격적으로 구토억제제를 먹기 시작하면서 그나마 속에서 받아주는 시원한 수박이나 오렌지같은 과일 그리고 패들팝아라는 아이스크림을 계속 원했다. 매일 장을 봐와야 했다. 일주일에 3일은 평화를 어린이집에 보냈는데 그런 날은 좀 더 시간을 벌 수 있을 것 같지만 막상 도시락을 준비하고 짐을 챙겨 데려다 주고 데리고 오고 하는 시간을 고려해보면 어린이집에 가지 않는 날에 비해서 겨우 3-4시간 정도 시간을 벌 뿐이다. 아내 먹을 것을 준비하고 집안일을 하다보면 다시 평화를 데려와야 할 시간이 되는 경우도 흔했다.

 

막막했다. 도저히 책을 쓸 수 있는 시간이 없었다. 그나마 어린이집에 평화를 보내고 아내 필요한 것을 챙겨준 뒤에 잠깐, 그리고 평화를 재운 뒤에 늦은 밤 중에 잠깐. 그게 내가 낼 수 있는 시간의 전부였다. 운이 좋은 날은 4-5시간 어떤 날은 2-3시간씩 밖에 쓸 수 없었다. 고객사의 요구가 들어오면 한밤중에라도 일을 해야 했다. 2010년 계약을 다시 하기 위해서 분석자료를 준비하고 제안서를 쓰는 시간도 필요했다.

 

12월 말까지 원고를 마무리하겠다고 큰 소리쳐놨는데 12월 한달 내내 그나마 쓰던 장도 마무리를 할 수 없었다. 원래 계획은 12월 말에 초고를 넘기고 1월에는 마음 편하게 휴가를 떠나는 것이었다. 12월부터 1월은 호주의 최대 휴가철이다. 그때가 가장 더운 여름이니까. 하지만 계획은 다 무산됐다. 크리스마스고 연말연시고 그런 것도 없었다. 매일 매일 끝이 보이지 않는 막막함 뿐이었다. 아내는 끝도 없이 계속 되는 심한 입덧으로 매일 힘겨워 했고, 나는 다시 끝이 보이지 않는 책의 마무리에 괴로워 했다.

 

지금은 이렇게 담담히 글로 적지만 그때는 정말 견디기 힘들만큼 괴로웠다. 내 인생에서 그렇게 힘든 시간은 처음이었다. 도무지 끝날 것 같지 않은 막막함이 들 땐 그 상황을 벗어나는 길은 죽음 뿐이라는 생각도 들었다. 한 자도 못쓰고 종일 뛰어다니다가 걱정 속에서 잠이 들때도 많았다. 고통스러워 하는 아내를 보면서, 뭔가 변한 엄마 아빠 모습에 스트레스를 받는 평화를 보면서도 내가 아무 것도 해줄 수 있는 게 없다는 사실이 괴로웠다. 여유를 가지고 집중하기 힘들었지만 그래도 죽을 힘을 다해서 빨리 마무리 하려고 노력했다. 겨우 겨우 1월 말에 11장을 끝냈다. 처음 생각대로라면 12월에 한 주면 다 썼을 것인데 무려 두달이나 걸렸다. 12월 말에는 초고를 넘긴다고 큰 소리 처놨는데 또 연락이 없으니 김 부사장님은 얼마나 더 실망했을까하는 걱정도 들었다.

 

그런데 11장을 끝낼 즈음에 내가 큰 착각을 하고 있다는 것을 깨달았다. 약속한 페이지를 맞추기 위해너 나름 재밌고 깊이 있는 내용은 다 빼고 꼭 필요하다고 생각되는 중요한 내용만 고르고 골라서 넣었는데도 11장을 끝냈을 때 이미 페이지가 750이었다. 아직 2부에서 가장 중요하다고 생각하는  MVC/@MVC와 Aspect/AOP, Test 기타 기술 등등이 남았는데 남은 페이지는 겨우 50. 그동안 계속 800을 채우면 끝이다라고 생각하면서 썼는데, 사실은 분량조절을 잘못해왔다는 것을 그제야 깨달았다. 스프링 기술의 선택가능한 옵션을 빠짐없이 소개하고 간단한 선택 가이드를 제공해 주면 되는 2부도 생각보다 쓸게 많다는 것을 그제야 깨달았다.

 

이미 여러번 800페이지 정도만 쓰겠다고 장담을 했는데 이제와서 분량을 더 늘리겠다고 할 수도 없었다. 그렇다고 이미 써논 것을 다시 편집해서 내용을 줄이자니 그것도 막막했다. 처음부터 끝까지 하나의 코드가 계속 연결되는 1부는 어떻게 건드릴 자신이 없었다. 그래서 일단 그냥 되는데까지 쓰기로 작정했다. 책을 다 쓰고 800페이지를 넘어가는 내용은 빼서 PDF로 공개하든지 그냥 버리든지 할 생각이었다. 아깝지만 그나마 생략해도 어색해보이지는 않는 7장과 8장은 빼버릴까도 생각했다. 적절하게 주제별로 비율을 따져보고 미리 페이지 분배를 꼼꼼하게 하지 않고 써논 것이 잘못이었다.

 

한숨이 나왔지만 어쩌겠는가 계속 써야지. 그렇다고 MVC/@MVC를 대충 쓸 마음은 전혀 없었다. 그리고 여전히 칭얼대는 평화와 입덧하는 아내를 돌보며 집안일에 매달려야 했지만 마지막이라고 생각하고 죽을 힘을 다해서 12장,13장을 써내려갔다. 그리고 단 20일만에 당시 편집하던 워드 파일로 210페이지(실제 책에서는 270페이쯤 되는 것 같다)에 달하는 MVC/@MVC를 다 써버렸다. 테스트 코드는 이전보다 더 많이 만들었고. 초기에 학습 테스트를 만들 때는 웹 기술의 테스트를 만드는 것이 너무 어려워서 생략을 했다. 그래서 12장을 쓰면서야 겨우 MVC 테스트를 하기 위한 간단한 지원 도구를 만들었다. 그리고 방대한 스프링MVC 내용을 하나씩 다 테스트 해가면서 넣었다. 기존 MVC에 비해 기능은 방대하고 내부 동작 방식도 복잡한 @MVC는 문서가 너무 빈약했다. 레퍼런스나 API문서만 가지고는 보이지 않는 프레임워크 내에서 일어나는 일과 규칙을 다 파악할 수 없었다. 그래서 스프링 @MVC 소스 코드를 모두 분석해야만 했다. 그렇게 분석한 내용을 가지고 가정을 세우고 그것을 2-3중의 테스트로 검증하고난 뒤에야 겨우 그 내용을 추가하는 식으로 써 나갔다. 문서와 소스를 분석하고 테스트를 만들어 검증하는 시간을 빼면 거의 하루에 20페이지씩 쓴 것 같다. 지금 다시 돌아봐도 어떻게 그 여유도 없는 상황에서 그 많은 내용을 다 썼는지 상상이 되지 않는다. 더 이상은 물러날 곳이 없다는 절박함 때문에 초인적인 힘이 났던 것일까.

 

그리고 14,15,16장을 열흘만에 다 써버렸다.  그렇게 해서 3월 4일 초고를 끝냈다.

 

마지막 장의 정리 절을 쓰고 나니 1000페이지가 조금 넘었다. 저장 버튼을 누르는 데 눈물이 났다. 지난 2년 넘는 시간동안, 특별히 지난 3개월의 끔찍했던 시간이 떠오르면서 이제야 살았다는 생각이 들었다. 아직 원고를 리뷰하고 교정하는 시간이 남았지만, 그래도 일단 마무리 했다는 것에 안도할 수 있었다. 정말 기분이 좋았다. 그 뒤로 리뷰를 마치고 초고를 넘겼을 때, 출판사 편집을 거쳐서 최종 원고 수정을 마쳤을 때, 책이 인쇄되서 나왔다는 얘기를 들었을 때, 그리고 책을 받았을 때도 기쁘긴 했지만 처음 원고를 마쳤던 그날만큼은 아니었다.

출판사에서 특급우편으로 보내준 내 책이 며칠전에야 도착했다. 책을 받아서 가장 먼저 아내에게 건내주었다. 나랑 함께 그 힘든 시기를 보내왔던, 답답하게 오랜시간 책을 쓰고 있는 남편을 보면서 한번도 잔소리도 한 적이 없는 착한 아내. 책을 살펴보라고 건네주고 잠시 방에 들어왔다 다시 나와보니 아내가 울고 있었다. 힘들었던 그때가 생각나서, 그래서 더 감격스러워서 우는 것이라고. 아내도 그때 참 많이 힘들었던 것 같다.

 

지금까지 별 시덥지 않은 얘기와 투덜거림으로 긴 글을 써온 것은 사실 오늘 이 얘기를 적고 싶어서였다. 그때는 이런 글을 쓸 수가 없었다. 책을 마무리 하지 못한 나는 죄인이었다. 맘 편하게 내가 즐기고 싶은 기술을 살펴보는 것도 용납하기 힘들었고, 내가 다 잘못해서 책을 완료하지 못한 주제에 힘든다는 말을 하는 것도 비겁해 보였다. 그래서 힘들어도 힘들다고 내놓고 말을 할 수가 없었다.

 

하지만 이제는 괜찮겠지. 다 지났으니까. 긴장했던 시간들, 짜증났던 시간들, 가끔 재미와 행복을 느꼈던 시간들, 그리고 견디기 힘들만큼 힘들었던 시간들.. 그 과정을 거쳐야 책이 하나 탄생하는 것인가. 나만 그런거겠지.

 

2010년 1월 1일. 새해 첫날이었지만 별 다른 것은 없었다. 여전히 괴로워 하며 끙끙 앓는 아내와 바뀐 환경에서 힘들어하던 평화, 그리고 잠시라도 짬이 나면 크리스마스든 새해 첫날이든 상관없이 자리에 앉아서 DI가 어떻고 @Inject가 어떻고 하는 얘기를 써나가야 했던 나. 그냥 달력을 보면서 2010년인가보다, 여전히 책을 끝내지 못한 책로 2010년을 맞았구나 하는 생각을 했다.

 

그리고 일년에 겨우 한 두 번쓰는 일기를 썼다. 차마 블로그나 공개된 곳에는 쓸 수 없었던 나 혼자만의 이야기를 가끔 적는다. 거기에 2010년 새해 목표를 적었다. 살아남기. 올해목표는 일단 성공한 듯. 그 일부를 여기다 옮겨본다. 이제는 얘기해도 되니까.

 

—————————–

 

1 Jan 2010

힘겹게 시작한 2010년. 새해가 시작한다는 느낌도 없다. 아니 느낄 조그마한 여유도 없다. 입덧하는 은성. 거의 폐인이나 다름없이 온종일 누워서 앓기만 한다. 엄마의 변화 때문에 힘겨워하는 평화. 전에 안하던 짓들을 슬슬 한다. 손에 잡히지 않는 일. 시간도 돈도 여유가 없는데 왜 이렇게 몸이 더딜까. 그나마 는 것은 집안 일 실력 뿐.

 

평화가 말을 듣지 않는 것 때문에 미친 듯이 흥분하는 내 모습을 보면서 아빠로서 기본적인 자격도 없는 것이 아닐까 하는 괴로움.

 

막막함.

 

그래도 절망하거나 힘겨워 하지 않고, 그래도 하루 하루 산다. 오늘 못하면 내일 하고, 오늘 조금 잘못했으면 내일 조금 덜 잘못하려고 하고, 그렇게 포기하지 않고 산다. 이제 내 목표는 어떤 멋진 꿈이 아니라, 포기하지 않고 살아남는 것. 이 삶을 살아 내는 것이다. 살아남자.

 

…

 

휴. 힘을 내자.

 

아자 아자.

 

내가 잘하는 한가지.

 

포기하지 않는 것.

 

지저분하게라도, 서글프게라도, 꿋꿋하게 사는 것.

 

2010. 시작이다.

—————————–

 

토비의 스프링 3이 나오기까지 (12)

 

왜 그런지 연재가 끝났다고 생각하는 분들도 있지만 제목이 ‘토스3이 나오기까지’인데 아직 안 나왔으니까 계속.

 

일단 원고를 완성하고 나니 기분도 좋아졌고 마음에 여유도 생겼다. 때마침 아내도 입덧이 좋아져서 조금씩 식사를 하고 기력을 회복하게 되었다. 끝이 보이지 않던 터널을 빠져나온 느낌이었다.

 

원고 리뷰를 시작했다. 어색한 문장이나 설명 고치고 최신 버전에 맞춰서 코드 점검하는 정도만 하면 될 것 같았다. 길어야 한달이면 충분하겠지라고 생각했다. 1000페이지니까 일주일에 200. 5일만 일하면 하루에 40페이지. 40페이지 리뷰라면 껌이구나.

 

거의 일년 3개월 전에 썼던 1장부터 다시 보기 시작했다. 맘에 안들었다. 아무래도 감을 잡기 전이라 1장은 좀 이리 저리 고민해가면서 쓰긴 했지만 이 정도일 줄은 몰랐다. 문장은 질질 늘어지고 어떤 건 너무 급하게 설명하고 넘어가고 어떤건 횡설수설. 코드를 발전시켜나가는 흐름과 그것을 이용한 스프링 설명방식은 맘에 들었지만 그 외에는 너무 한심했다.

 

확 다 지워버리고 다시 쓰고 싶었지만 도저히 그럴 수는 없고, 어색하다고 보이는 문장은 모두 고치고 맘에 안드는 문단은 통채로 다시 썼다. 거의 30%쯤은 다시 쓴 듯. 1장은 나중에 한번 더 봤는데 그때도 맘에 안들었다. 열번이고 맘에 들때까지 고치고 싶었지만 결국 두번 보고 "에라 모르겠다" 하면서 그냥 포기. 나름 초보자도 이해할 수 있게 쉬우면서도 독특한 방법으로 스프링의 DI 개념을 설명하고, 1부에서 계속 얘기 할 내용의 핵심 메시지를 담고 싶었는데… 과연.

 

코드도 모두 다시 검증해서 넣었다. 원고 있는 코드를 가지고 다시 맨땅에서 부터 프로젝트를 만들어서 테스트를 하고 검증이 되면 그것을 다시 붙여넣는 식으로 작업을 했다. 맘에 안드는 다이어그램도 다시 수정. 그리고 가을에 만났을 때 김 부사장님이 알려준 기준에 맞게 일부 구성도 수정했다. 각주(-_-;;)도 모두 본문에 넣거나 박스로 뽑아냈고.

 

가장 손이 많이 간 것은 리스트나 그림의 번호를 참조(그림 1-1을 보시라 같은)하는 부분이다. 한장에 수십에서 백여개까지도 나오는 리스트는 번호 자동 생성기능을 이용해서 만들었기 때문에 중간에  삽입하거나 제거한다고 해도 자동으로 번호가 갱신되서 일일이 번호를 수정하는 번거로움은 없다. 하지만 본문에서 참조한 부분은 일일이 하드-코딩(?)을 한 탓에 리스트의 번호가 달라지면 모두 찾아서 수정을 해줘야 하는 번거로움이 있었다. 자동으로 리스트 번호와 연동이 되면 좋을텐데라고 투덜거리면서 작업을 했는데, 알고보니 워드에 그런 기능이 이미 있었다. 상호참조라고.

 

내용도 확정했고 특별히 더 넣거나 뺄 리스트나 그림은 없으니 그냥 한번씩 확인만 하고 말까했지만, 영양가 없을 때만 꼼꼼해지는 성격상 몽땅 다 상호참조로 바꾸기로 했다. 어떤 장은 백개도 넘는 리스트와 장마다 수십 개에 달하는 그림의 참고글에 상호참조 적용하는 것만 해도 방대한 작업이었다. 그게 메뉴를 타고 들어가서 매번 제일 앞으로 돌아가는 목록을 뒤져서 번호를 삽입하는 식이다 보니 작업이 무척 더뎠다. 그런데 막상 그렇게 확인을 하면서 상호참조를 넣다보니 안했으면 큰일날 뻔 했다는 생각이 들었다. 그 사이에 글을 수정하면서 본문에서 참조한 리스트나 그림의 번호가 틀린게 많았다.

 

일부 코드는 아예 수정이 필요한 것도 있었다. 1장을 쓸 때는 스프링 3.0이 겨우 M1이었다. 그때는 아씨아씨(이클립스에서 ACAC라고 치고 컨트롤-스페이스를 누르면 내가 테스트 만들 때 애용하는 AnnotationConfigApplicationContext이 나온다)가 없었기 때문에 XML없이 자바코드만 가지고 @Configuration를 사용하게 하려면 여러 줄의 코드가 필요했다. 하지만 나중에 ACAC가 나온 뒤로는 컨텍스트 생성자로 충분했다. 이런 식으로 원고를 쓸 때의 스프링 버전과 달라진 점이나 개선된 내용을 찾아서 적용하는 것도 큰 작업이었다.

 

처음 생각엔 이틀이면 충분했을 것 같았는데 1장을 퇴고(나도 폼나는 말 좀 써보자)하고 나니 이미 2주가 지났다.

 

다행히 2장부터는 그나마 수정할 데가 많지는 않았다. 1장을 마무리 할 때쯤엔 글을 쓰는 감도 조금 잡히고 리듬도 타고 하니 아무래도 처음 보다는 덜 어색해졌나보다. 표현이 어색한 것은 나중에는 크게 손대지 않았다. 고쳐봐야 여전히 어색하고. 차라리 출판사에서 편집하면서 세련되게 다듬어주기를 기대하는 것이 나을 듯 싶었다. 편집과정에서 어색한 문장과 표현은 모두 깔끔하게 다듬어 준다는 얘기를 어디선가 들은게 있으니까.

 

대부분 내용이나 코드는 크게 바뀔 것은 없었지만 일부 테스트 코드는 좀 더 나은 아이디어가 보이면 과감히 수정하기도 했다. 스프링에 관한 모는 내용을 다 넣은 것은 아니지만, 나름 중요한데도 깜빡하고 빼먹은 것이 보이면 추가하기도 했다. 일관성 없는 코드(리스트)도 통일을 해야 했다. 코드가 조금씩 바뀌면서 진행되다 보니 클래스 전체를 보여주는 경우는 드물었다. 물론 바뀔 때마다 전체 코드를 넣을 수도 있지만 양을 늘리기 위해서 별짓 다한다는 얘기를 듣기 딱 좋다. 그래서 바뀌는 부분만 골라서 삽입했다. 전체 코드의 변화를  보려면 아무래도 52단계로 쪼개서 넣은 CD의 예제 코드를 보거나 아니면 본인이 직접 해볼 필요가 있다.

 

남은 건 package와 import를 넣는냐의 문제였다. 클래스의 일부분이지만 그래도 어느 패키지의 어떤 클래스인지는 알려줘야 했다. 그래서 처음 클래스가 등장할 때는 package는 넣었다. 그게 예제라고 하고 파일 경로를 적는 것보다 나아보였다. 문제는 import. 이게 한 둘이 아닌데 이걸 다 넣으면 코드의 양이 두 배는 될 테고 책도 100-200페이지는 더 늘어날 것 같았다. 그래서 정말 특별한 경우에만 한 두 개의 import를 넣고 나머지는 다 생략했다. 이 때문에 책만 보고 코드를 따라하는 경우 이클립스에서 타입 이름을 보고 import를 자동으로 삽입해주는 Organize Imports 기능을 잘 사용하지 못하는 사람이라면 import문 때문에 고생할 수도 있겠다는 생각이 들었지만 어쩔 수가 없었다. 대신 쌩 초보자를 위해서 1부의 내용을 코딩하는 동영상을 만들고 이를 공개해주면 괜찮겠다 싶었다. 물론 책이 끝날 무렵엔 에너지를 다 소진해 버려서 아직도 그 동영상은 못 만들고 있긴 하지만. –_-;;

 

일부 부족한 설명과 중요한데 깜빡하고 빼먹은 내용 등을 추가한데다 캡션 없이 코드를 넣었던 것도 대부분 리스트-xx를 넣달아주고, 코드에 package나 import를 생략했다는 표시를 넣다보니 20페이지 정도 더 늘었다.

 

책을 쓰는 중에는 다들 하는 베타 리딩을 할까 생각했다. 하지만 원고를 마무할 즈음엔 베타 리딩이 엄두가 안났다. 오탈자나 기술적인 문제를 지적해주면야 고맙지만 구성이나 전개방법, 내용 등에 관한 피드백이 들어오면 아마 기절할지도 모를 거란 생각이 들었다. 그래도 기술적인 설명과 코드, API 사용등에 관해서 한번은 다른 사람의 점검을 받아야 겠다고 생각했다. 7년가까이 매일 만져오던 스프링이지만 내가 자주 사용하지 않아서 익숙하지 않은 기능을 설명할 때 실수했을 수도 있고, 아니면 내가 뭔가 착각하고 있었거나, 작성한 코드에 결함이 있을 수도 있었다. 게다가 자기가 쓴 글은 틀린 게 잘 안보인다. 그래서 기술적인 내용에 관한 검증을 기선이에게 부탁했다. 기선이는 스프링에 관해서는 오랜 동안 깊이 연구했고 최신 버전의 기능에도 익숙한데다 꼼꼼하기까지 해서 제격이었다. 기선이는 자기 할 일로 바쁜데도 흔쾌히 응해줬다. 그리고 내가 리뷰 하는 내내 책의 내용을 빠짐없이 읽고 코드를 모두 테스트 해보고 기술적인 설명은 근거가 될만한 레퍼런스 문서나 API항목을 일일이 찾아보면서 검증하는 등의 수고를 해서 오탈자를 제외하고도 수십 개의 크고 작은 오류를 지적해줬다.

 

기선이가 없었다면 아마 내가 그런 작업을 직접 해야 했을 거고 적어도 한 두 달은 시간이 더 걸렸을 것이다. 단지 오류를 발견해서 알려주는 것이 전부가 아니라 모든 기술적인 설명에 근거를 일일이 찾아서 점검도 해야 했기 때문이다. 기선이는 최종 원고 수정을 마칠 때까지 꼬박 두 번에 걸쳐서 책을 샅샅이 읽고 점검해줬다. 중간중간에 책을 읽은 느낌이나 생각을 블로그에 적기도 했다. 아참. 그래서 하고 싶은 얘기는 테크니컬 리뷰어는 기선이니까 설명에 기술적인 오류가 있다면 기선이에게 항의를… ( ”)

 

주로 내용과 코드, 설명을 점검하는 1차 퇴고를 마치고 나니 두달이 조금 넘었다. 거기에 틈틈이 기선이가 체크해서 보내준 내용을 적용했고. 원래 계획은 한번 더 전체 내용을 읽으면서 문장을 다듬어보는 것이었지만 이미 에너지는 거의 바닥나 있었다. 초고를 마무리 하느라 전력질주를 한데다 리뷰과정 중에도 거의 매일 12시간 이상 눈이 빠지게 모니터만 들여다 보고 있었으니 남은 기운이 없었다. 그래서 1장과 10장 정도만 다시 조금 손을 본 뒤에 5월 20일에 책 원고를 출판사에 보낼 수 있었다. 맨날 답이 없는 유령 저자에게 저술진행 확인 메일을 보내느라 수고해왔던 황지영 과장님에게 드디어 원고를 보내드립니다라는 답장을 보냈다.

 

그리고 책의 탈고를 알리는 블로그 글을 썼다.

 

저술 계약한지 3년이 넘도록 한번도 진행중인 원고를 출판사에 보낸 적이 없었다. 그 때가 처음이자 마지막이었다. 과연 출판사는 뭘 믿고 경험도 없는데다 약속을 밥먹듯이 어기는 저자를 원고 확인도 없이 기다려 주었을까 궁금했다. 나라면 수시로 원고 쓴 거 달래서 확인을 해봤을텐데. 내 책은 이미 포기한 것은 아닐까라고도 생각했다.

 

한편으로는 원고를 보냈으니 편집을 마치고 내가 다시 리뷰할 때까지 푹 쉴 수 있다는 생각에 마음이 편하면서도 다른 한편으로는 편집과정이 얼마나 험난할까 하는 걱정도 들었다. 주위에선 "안드로이드 같은 최신 기술이 워낙 인기라 스프링 같은 비인기 책은 아마 편집 작업에도 밀려서 찬밥일 것이다" 또는 "편집당해서 내용을 왕창 들어내야 할 것이다"라고 겁을 주기도 했다. 그래서 긴장도 많이 됐다.

 

이유야 어쨌든 처음 약속과 달리 1000페이지가 넘어버렸는데 이걸 내가 먼저 줄여서 넘길까 하다가 김 부사장님 반응을 먼저 살펴봤는데, 1000페이지라고 해도 크게 놀라시는 눈치는 아니었다. 일단 보고 판단하자는 생각이셨을까. 그래서 나도 모르겠다는 심정으로 원고에 손을 대지 않고 일단 그대로 넘겼다.

 

출판사에서는 편집 디자인, 최종 리뷰, 인쇄, 제본 등에 최소한 한달 반 정도의 시간이 필요하다고 했다. 늦어도 7월 초면 책이 나온다고 했다.

 

과연?

 

토비의 스프링 3이 나오기까지 (13)

 

드디어 마지막. 이렇게 길어질 줄은 몰랐는데. 내가 도대체 왜 시작한거지… 어휴.

 

초고를 넘기면 3주 정도 후에 편집된 원고를 받을 것이고 내가 최종 확인해서 넘겨주면 내 일은 끝이라고 들었다. 하지만 그 외에도 몇 가지 남은 작업이 있었다.

 

책에 나오는 내용을 담은 예제 프로젝트는 꼼꼼하게 만들어서 1부 52개, 2부 1개의 이클립스 프로젝트로 구성을 해두었다. 그런데 학습 테스트와 점진적인 빈 개발 스타일로 만들다 보니 정작 서버에 배치해서 돌려볼 수 있는 완전한 애플리케이션이 없다는 것이 마음에 걸렸다. 스프링의 많고 많은 접근방법 중에서 한 가지를 선택해서 예제를 만드는 식으로 책을 쓰는 것은 원치 않았지만 그래도 간단히 살펴볼 웹 애플리케이션 예제 하나쯤은 있어야 하지 않을까하는 생각이 들었다. 2부의 스프링@MVC에서 설명한 내용, 특히 폼과 바인딩 하는 부분은 실전에 적용된 샘플을 참고하도록 제공할 필요가 있을 듯 싶었다. 그래서 간단히 스프링사용자모임(springusergroup)이라는 이름으로 예제를 만들었다. 회원 등록과 로그인, 관리가 전부인 초간단 예제였지만 그래도 책에서 설명했던 내용을 최대한 반영해보려고 했다. JDBC와 JPA를 동시에 사용하는 DAO라든가 세션 스코프를 이용한 로그인 정보 관리, 또 도메인 오브젝트를 유지하면서 폼 바인딩을 하는 방법을 담으려고 노력했다. 책에서 끊임없이 테스트가 중요하다고 떠들어댔으니 테스트도 빼먹을 수 없었다. 단위테스트, 통합테스트 등을 적절히 섞어서 테스트 코드도 꼼꼼히 만들었다. 좀 더 복잡한 예제를 만들면 좋았겠다 싶지만 그것도 사실 겨우 만들었다. 점점 책과 관련된 일이 하기 싫어지는 걸 느꼈다.

 

부록도 썼다. 이미 오래전부터 스프링의 의존 라이브러리와 모듈 의존관계 등을 분석하고 블로그에 연재해온 것이 있으니 그걸 참고해서 부록을 작성하는 것은 어렵지 않았다. 사실은 SpEL 문법을 부록-C로 넣으려고 생각은 했지만 양도 많은 데 그것까지 굳이 넣어야 하나 고민하다 과감히 나몰라라 생략.

 

1부 코드를 작성하는 것을 동영상으로 만들어서 공개하기로 한 계획은 일단 취소. 도저히 기운이 없었다. 원고를 넘기고 긴장이 풀리면서 힘이 하나도 없어서 뭔가 할 의욕이 나지 않았다. 책과 관련된 모든 일에서 가능한 빨리 손을 떼고 싶었다.

 

편집을 기다리는 시간은 매우 길게 느껴졌다. 가장 궁금했던 것은 책의 분량이었다. 나는 처음 약속과 달리 1030페이지나 썼다. 다시 100-200페이지쯤 줄여야 하는 것일까, 뺀다면 뭘 뺄까 그런 생각을 하고 있었다. 그런데 어느날 놀라운 얘기를 들었다. 책을 편집해보니 1400쯤 나온다는 것이었다. 꺅. 내가 분명히 에이콘 기존 서적과 비교해서 페이지 분량이 일치하도록 템플릿 파일을 만들어서 썼는데 이게 무슨 일인가. 무려 400페이지나 더 늘어나다니!! 김 부사장님은 일단 편집을 통해서 최대한 페이지 수를 줄이도록 하고 있지만 그래도 얼마 안될거라고 하셨다. 그리고 1400페이지면 책 두께가 너무 두꺼워 지고 제본도 곤란하니 200페이지 정도 분량을 줄여보는 것이 어떻겠냐고 하셨다.

 

책의 내용을 줄일 각오는 하고 있었으니까 그건 문제는 아니었는데 책이 그래도 1200페이지나 된다고 하니 놀랄 수 밖에. 그런데 뭘 빼야 할까. 중복된 내용이 있으면 빼라고 하셨지만 중복이라고 생각되는 부분은 없었다. 차라리 덜 중요하거나 중요하지만 빼도 흐름에 지장을 주지 않는 장을 통채로 빼는게 나을 것 같았다. 예를 들면 스프링 학습방법을 설명하고 기타 기술 내용을 담은 16장이나, 스프링의 개념을 담은 8장 또는 내가 가장 아끼기는 하지만 빼도 다른 내용에 영향을 주는 것이 아닌 7장 같은 것을 생각하고 있었다. 또, 9장의 스프링 툴 소개 같은 것도 빼도 될 것 같고. 이런 내용은 PDF로 만들어서 CD에 넣거나 그냥 공개해버려도 되지 않을까도 생각했다.

 

이런 저런 생각을 하면서 며칠이 흘렀는데 다시 김 부사장님으로부터 연락이 왔다. 사장님께서 책 내용을 줄이지 말고 그대로 내라고 지시하셨다고. 저자가 힘들게 썼는데 왜 줄이냐고 하셨다는 것이었다. 감동이 몰려왔다. 원래 사장님이 쫌 멋지다는 건 알고 있었지만… 찡. 그런데 문제는 1400페이지로 책을 내려면 하드커버 제본을 해야 한다고 하셨다. 그리고 두께를 줄이기 위해서 질이 좋은 얇고 질기지만 무거운 종이로 해야 하고. 그래야 두께를 20%쯤 줄일 수 있다. 대신 종이와 제본 등에서 비용이 증가하기 때문에 책 값은 처음 계획보다 올라갈 수 밖에 없었다. 그래서 결국 1400페이지짜리로 무게가 살짝 나가는, 좋은 종이를 쓴 그러면서도 가격은 적당한 책이 나오게 된 것이다. 예상과 달리 두꺼운 책이 나온다는 사실에 놀라기도 했고, 그래서 책이 잘 안팔리면 어쩌나 걱정도 살짝 됐지만 그래도 기분은 좋았다.

 

7월 중순에 편집본이 왔다. 처음 예상과 달리 편집이 늦어진 것은 분명 내 탓일 것이다. 페이지 수는 거의 두 배 가까이 늘었고, 게다가 엉망인 문장 천지라 다듬고 정리하는 데도 시간이 많이 들었을 것이다. 또, 헤드퍼스트 흉내낸다고 코드에 일일이 화살표나 박스를 달고 코멘트를 넣은 것 때문에도 시간이 더 들었을 것이고. 처음엔 그냥 번호나 달고 코드 아래 본문에다 설명을 달았는데 분량은 늘어나는 데다 코드와 설명이 따로 있어서 읽기 불편할 것이라는 생각에 공간이 허용하는 만큼 코드 주위에 직접 설명을 달려고 노력했다. 편집본을 받아서 최종 리뷰를 하고 오탈자를 찾아내고 하는 작업에 다시 일주일쯤 시간이 걸렸다. 일주일 정도 매달려서 작업한 끝에 7월 19일에 최종 수정본을 보냈다.

 

추천인들이 결정되고 추천사도 받았고, 들어가며와 저자의 말도 다시 썼다. 저자의 말을 쓰면서 지난 3년의 시간을 다시 돌아봤다. 책 한권이 나오기까지 나에게 영향을 준 많은 사람들이 떠올랐다. 또, 겁도 없이 책을 쓰기로 하고, 적지 않은 스트레스 속에서 책을 쓰기 위해서 고군분투했던 시간, 실망하고 좌절하기도 했고 때로는 기쁘고 흥분했던 시간들이 생각이 났다. 책에 들어갈 내용이니 그런 얘기를 일일이 다 적을 수는 없었다. 간단한 소감과 책을 쓰는데 직접 도움을 주거나 영향을 주신 분들에 대한 감사의 말을 남겼다.

 

저자의 말의 원고를 넘기고 나니 정말 모든 것이 끝난 기분이었다.

 

하지만 인쇄되서 배포되는 책에는 차마 담을 수 없었던 지난 이야기를 어딘가 남기고 싶었다. 부끄러운 얘기도 있고, 밝혀지면 누군가 기분 나쁠 얘기도 있었지만 뭐.. 그래도 한번은 꼭  다 털어놓고 싶었던 지난 3년 간의 내 모습과 생각들이고 블로그는 그런데 쓰라고 만든 거니까. 시간이 좀 더 지나면 잊혀질지 모르는 내 기억과 느낌, 생각을 그래서 모두 꺼내봤다.

 

이제 속이 후련하고 마음이 편하다.

 

이제는 지난 시간들을 다 잊어버리고 다시 앞을 향해서 달려 나갈 수 있을 것 같다.