작년 말부터 준비한 토비의 스프링 3 증보판이 마무리되서 지난 주말부터 인터넷 서점에서 예판을 시작했다. 실제 출간일은 이달 말이다.

이번 증보판은 스프링 3.0을 기준으로 설명한 토비의 스프링 3 내용에 스프링 3.1내용을 200여페이지 추가한 것이다. 덕분에 책을 두 권으로 분리해야 했고 두권을 합쳐 전체 페이지 수가 1700이 넘게 되었다. 분책을 하다보니 각 권만 선택해 책을 보는 독자들의 편의를 위해 앞의 부속글과 부록, 찾아보기 등이 양 권에 모두 들어가서 페이지 수가 좀 더 늘어났다.

Vol1은 예전 1부 내용에 user 예제 코드를 스프링 3.1의 DI 스타일로 업그레이드 하는 과정과 그 특징을 설명하는 내용을 추가했다. Vol2는 예전 2부의 스프링 기술 설명에 각 장마다 스프링 3.1에 새로 등장한 내용을 다루는 절을 추가했다. 스프링 3.0 내용도 일부 추가된 것이 있다. 3.0.3이후에 나온 mvc 네임스페이스의 일부 태그에 관한 설명이 MVC를 다루는 장에 추가됐다.

책이 두 권으로 분권됐기 때문에 낱권으로 구매가 가능하다. 물론 세트로 구입할 수도 있다.

그 밖에 하고 싶은 얘기가 정말 많긴 한데… 이번엔 그냥 여기까지만.

기선이가 두 번째 스크린캐스트를 IBM DW 로컬 컨텐츠로 공개했다. YouTube로 가서 보면 HD급 화질로도 볼 수 있다.

내가 쓴 토비의 스프링 3은 책의 내용을 그대로 강의 교재로 쓰기에는 그리 적절한 책은 아니다. 분량도 많은 데고, 책 내용도 시간을 충분히 가지고 스스로 학습하거나 스터디 등을 통해서 토론식으로 공부하려는 사람에게 적합하다. 하지만 책의 핵심 내용을 추려서 교육과정을 만든다면 나쁘지 않다. 책은 강의나 교육을 통해서 얻은 지식을 심화해주는 보조교재로 사용될 수 있을테니까.

반대로 책의 분량에 기가 질려서 선듯 공부하기 힘들다고 느껴지는 사람이라면 짧은 교육을 통해서 먼저 감을 잡고, 그리고 나서 본격적으로 책을 보는 것도 좋겠다.

책만 가지고 공부하는 데 부담을 느끼는 사람이나 아니면 빠른 시간에 스프링 개념을 잡고 전체 내용을 살펴보기 원하는 사람들이라면 내 책의 테크니컬 리뷰어 역할을 해줬던 기선이가 강의하는 교육에 참여해봐도 괜찮을 것 같다.

기선이는 이미 두 차례 한빛교육센터에서 토비의 스프링 3의 내용을 중심으로 한 "스프링 3.0 이해와 선택"이라는 교육과정을 진행했다. 또, NHN, LGCNS, SDS 의 초청을 받아서 현장에서 같은 내용의 교육을 진행하기도 했다. 내가 직접 강의를 들어본 것은 아니지만 강의를 받은 사람들의 피드백을 보면 제법 괜찮은 내용인 것 같다. 스프링을 처음 접하는 사람뿐 아니라 이미 스프링을 이용한 개발경험이 있는 사람들도 도움이 많이 되었다고 한다.

10월에는 강남의 한빛교육센터에서 같은 내용의 교육이 진행된다고 한다. 이번이 공식적인 6번째 교육이니 그만큼 기선이의 강의실력도 많이 늘었을 것이라고 기대된다. 관심있는 사람이라면 인원이 차기 전에 얼른 신청하는게 좋을 것 같다. 모든 수강생에게는 교재인 토비의 스프링 3이 한 권씩 제공된다.

내가 이렇게 기선이 교육을 홍보하는 이유는….

나한테 떨어지는 로얄티가 있기 때문이다. 강의 한번 할 때마다 로얄티로 내가 가장 좋아하는 땅콩버터구이 오징어 한봉지씩 보내주기로 약속이 되어있다. :)

다음 오징어는 언제나 오려나… 냠냠.

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

 

초고를 넘기면 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년 간의 내 모습과 생각들이고 블로그는 그런데 쓰라고 만든 거니까. 시간이 좀 더 지나면 잊혀질지 모르는 내 기억과 느낌, 생각을 그래서 모두 꺼내봤다.

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

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

왜 그런지 연재가 끝났다고 생각하는 분들도 있지만 제목이 ‘토스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월 초면 책이 나온다고 했다.

과연?

 

이제 내일 마지막으로 편집과정과 최종 책이 나온 얘기를 하면 되겠구나. 이젠 즐거운 얘기만 남았네.

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha