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

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

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

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

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

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

 

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

Related posts:

  1. [토스3] 테스트를 위한 필드 주입 유틸
  2. 토비의 스프링 3이 나오기까지 (12)
  3. [토스3] 스프링 3.0.4 <mvc:default-servlet-handler/>를 이용해서 UrlRewriteFilter없이 깔끔한 URL을 만들기
  4. 토비의 스프링 3이 나오기까지 (11)
  5. 토비의 스프링 3이 나오기까지 (7)
  6. 토비의 스프링 3이 나오기까지 (6)
  7. 토비의 스프링 3이 나오기까지 (5)
  8. 토비의 스프링 3이 나오기까지 (3)
  9. 토비의 스프링 3이 나오기까지 (2)
  10. 토비의 스프링 3이 나오기까지 (1)
  11. 토비의 스프링 3 출간지연과 동영상 소식
  12. [토스3] 매핑 가능한 BeanPropertySqlParameterSource
  13. [토스3] 스프링 JDBC DAO에 lazy-loading 적용하기 (2)
  14. [토스3] 스프링 JDBC DAO에 lazy-loading 기능 적용하기
  15. 스크린캐스트 – 테스트와 스프링

Facebook comments:

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

  1. 9편은 유독 장편이구만..

    2006년에 이대 후문에서 W출판사 편집장님이랑도 만났거든.
    블로그에 나오는 개빈 킹씨 책 번역 관련해서.. ㅋㅋ

  2. 영회/ 어머나 그러네.

  3. 너무 길어요..
    담부터는 한 페이지씩 써주세요. ^^

  4. 결국 제 지론은 이겁니다.

    “끝이 좋으면 모두 다 좋다”

    읽고 보니, 담번부터는 저술 계약을 할 때 저자의 지루함을 위해 번역서 한권 더 세트 계약을 해야겠다는 생각이.

    그나저나 우리 스프링 문서 번역하려다 물거품됐던 기억도 살그머니…나면서…;
    그날 처음 만나 연을 맺은 그 성철님과 세원님의 책이 이제 담주면 나오네요~!! 알랍~~ 여러분~

  5. 책 내용도 좋지만 이 뒷이야기도 재미나네요!!

  6. 94z6Mb bruferhoknas, [url=http://jypcsydunfmz.com/]jypcsydunfmz[/url], [link=http://rsefwshtrtjy.com/]rsefwshtrtjy[/link], http://iydtzitiutoh.com/

  7. Thank you for this blog. That’s all I can say. You most definitely have made this blog into something thats eye opening and important. You clearly know so much about.

  8. mbt shoes uk 토비의 스프링 3이 나오기까지 (9) » Toby’s Epril

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha