물론 필자의 경우 출판사로 넘기기 전에 적어도 3번 이상 전체를 읽어 보면서, 문맥이 이상하거나, 오타를 수정하는 작업을 수행한다.
그리고,
아무리 여러분들이 워드에 이쁘게 작업해서 넘겼다고 하더라도, 모두 text로 변환해서 글들을 교정한 다음에 이미지와 여러 틀에 맞추어 편집작업을 한다.
교정하는 과정에서 오타나 소스를 이상하게 나열할 수도 있기 때문에, 두 세번 정도 필자가 확인작업을 수행한다.
그 다음엔 index에 넣어야 할 단어들을 표시하기 위해서 한번 더 읽는다.
그리고, 조판 들어가기 전에 마지막으로 또 한번 읽는다.
그러니까 3+3+1+1 = 8 번.. 적어도 8번 읽고, 출판사 담당자 및 교정 담당자도 몇 번씩 읽어보기 때문에, 10번 이상 읽혀진 후 출간된다고 생각하면 된다.
그렇게 보는데도, 오타가 없을 수는 없다. (그리고, 몇번씩 읽어 본다고 하더라고, 저자에게 리뷰하라고 주는 시간이 많지는 않다. 보통 금요일 저녁에 받아서 일요일 저녁에 주고… 저녁에 받아서 다음날 아침에 주고… 뭐 그런 식이다.)
그리고, 책 중간 중간에 들어가는 삽화는 필자가 그려달라고 원고 중간중간에 표시할 수도 있고, 기획자가 알아서 그림을 추가할 수도 있다.
모든 작업이 끝나면 인쇄에 들어가는데, 인쇄 들어가면 더 이상 수정은 못한다고 한다. (2쇄 나올 때까지 오타 찍힌 책들을 팔 수밖에 없다.)
더 자세한 내용들은 출판사 업무이기 때문에, 내가 그리 잘 알지는 못한다. 더 궁금하신 분들은 출판사 직원들에게 물어보시길…
- 판과 쇄에 대하여
나도 책을 쓰기 전까지는 정확하게 잘 몰랐지만, 책이 나올때 판과 쇄라는게 있다.
보통 2nd edition, 2판으로 제목에 붙어서 책이 나오는 경우가 있다. 이렇게 제목과 내용이 많이 보완 및 upgrade되어 나오는 경우가 “판”이다.
이와는 다르게, 처음에 보통 1,000~3,000부 정도의 IT책을 찍는데, 그 찍는 단위가 쇄이다. 만약 1,000부 정도씩 찍어서 11쇄로 찍혀 있는 책을 샀다면, 그 책은 10,000 부 이상 팔린 책이라는 의미가 된다. (만약 저자의 인세가 몇 %인지 안다면, 저자가 얼마나 벌었는 지도 알 수 있다.)
그리고, 보통 쇄를 추가하는 경우는 200부 정도 남았을 때 추가한단다.(최초 부수에 따라 다르겠지만…)
참고로 내 Blog2Book 자바 튜닝 책은 출간된지 1년 반정도 된 지금 아직 2쇄라는 … (그래도 약 7개월만에 1쇄가 다 나갔다는…)
- 증정 준비
상황에 따라, 출판사에 따라, 번역을 하거나 집필을 하면 저자에게 본인이 작업한 책을 몇권 무료로 준다.
그 내용은 계약서에도 써 있다.
번역을 하거나 감수를 할때에는 몇권 안준다. 5~10권…
집필의 경우는 약 20권정도…
그래서, 필자의 경우는 Google Docs excel에 증정 대상자 목록을 집필 시작하면서 부터 관리한다.
특히 책을 쓰는데 도움이 되었거나, 업무에 도움을 많이 주신 분들에게는 보지는 않더라도, 한권 드리면 다들 좋아 하신다. ㅋㅋ
그런데, 갑자기 책을 드려야 하는 경우가 있을 수 있다. 예를 들어 대표이사 라던지, 높은 분들에게…
그렇기 때문에 증정리스트는 3~5권정도 여유분을 가져야만 한다.
- 홍보 하기
기본적으로 홍보는 출판사에서 알아서 한다.
좋은 기획자를 만나면, 홍보도 알아서 잘 해준다. 그래서 필자의 Blog2Book 자바 튜닝 책도, 기획자가 많이 도와 줘서 마소에 인터뷰도 올려주고, 이벤트도 기획해 주었다.
저자도 그냥 있기 보다는 본인 블로그나 기타 매체에 홍보하는 것도 좋다.
필자의 경우는 (지금 회사도 작진 않지만) 전에 큰 회사에 있어서, 사내 홍보팀에 홍보를 부탁하니 회사에서 한달에 한번씩 발간하는 사보 한페이지의 1/8도 되지 않는 부분에 할애를 해 주었다.그 쪽에 잘아는 사람이 있긴 했지만, 별로 마음에 안들어서 그냥 넘어갔다.(- -) 조금만 힘좀 쓰면, 매일 아침에 하는 사내 방송에 내 보내는 것도 많은 홍보가 될 것이다.
그리고, 팀이나, 커뮤니티에서 발간하는 뉴스레터가 있다면, 그 뉴스레터에 책에 대한 소개를 올리는 것도 많은 도움이 된다.
참고로 올해 11월에 출간될 예정인 Blog2Book Test 책은 내가 받을 집필료를 할애하여 구매하신 몇 몇 분들에게 좋은 선물을 제공하는 이벤트를 진행할 예정이오니 기대하기 바란다. 그리 큰 선물은 아니지만, 그리 작은 선물도 아니다. ㅋㅋ (상황이 어떻게 바뀔지 몰라 그 선물은 뭔지 지금 공개하진 않겠다.)
- 마음의 준비
이 연재의 마지막으로 마음의 준비에 대해서 당부 드리고 싶다.
물론 여러분들이 책을 쓴다면, 그 부수에 따라 달라지지만, 책에 대한 리뷰가 여러 곳에 등록된다. 그 중 인터넷 서점에 올라오는 글들은 유심히 보게 된다. 나도 그 리뷰 보고 책을 사기 때문에… 그리고, 그 글들은 올라가면 끝이다. 저자가 지울 수도 없다. - -;
그냥 내 책에 대해서 사람들이 어떻게 생각하는지 알고 있어야 한다는 이야기다.
추가로, 책이 나온 후부터 Google, Naver, Yahoo 등에서 책 제목으로 자주 검색해 보면 많은 리뷰를 볼 수 있다. 별별 다양한 의견들을 볼 수 있다.
그러한 의견들을 보면, 나의 책에 대해서 안티한 사람들이 적지 않다는 것을 알 수 있다.
내가 뭐 탁월한 천재도 아니고, 완벽한 사람도 아니기 때문에 실수를 할 수도 있지만, 우리나라 사람들(특히 IT하는 분들)은 똑똑한 분들이 굉장히 많기 때문에 많은 오류들을 찾아 내고, 부족한 부분들에 대한 글들을 블로그에 올린다.
그분들이 알지 모르겠지만, 나는 구글, 네이버, 야후에서 검색된 내 책에 대한 모든 리뷰를 거의 다 읽었다. (아마도…)
하지만, 나는 일일이 대꾸를 하지는 않는다. 사람마다 생각은 다르기 때문에...
안티한 사람들이 많더라도, 책이 많이 팔렸으니, 안티한 분들의 수도 그에 비례한다고 생각한다. (아닌가? )
그런데, 몇몇 오류를 갖고 그 책의 모든 내용이 신뢰할 수 없다고 매도하는 사람들이 있다. 그런 글들이나 말을 들으면 며칠간 기분이 안 좋은데, 어쩔 수 없다. 그냥 그러려니 하는 수 밖에…
그래서 필자가 이 절에서 하고자 하는 이야기는
“책이 나오기 전에 사람들의 다양성에 대한 마음의 준비를 해야 한다.”
는 것이다. 책에 대한 안티한 글들에 일일이 답할 필요도 없고, 열받아 할 필요는 없다. 여러분만 손해다. (그래서 이번 책에는 누가 이 책을 읽어야 하는지에 대한 설명도 포함하였다. 제발 좀 누가 읽어야 하는 책인지 확인해 보고 사서 보시면 고맙겠다.)
지금까지 짧으면 짧고, 길다고 하면 긴 "How to write a book" 연재를 마치고자 한다. 분명 도움이 되실 분이 있을꺼라 생각하고, 집과 출근버스에서 정리한 내용들이다. 마지막으로 이 글을 읽어주신 여러분께 한가지 당부를 드리고 싶다.
책의 내용이 저자의 의도와 100% 맞는 독자도 있고, 1%도 맞지 않는 독자도 있을 것이다. 바이블을 원하는 독자가 입문자를 위한 책을 읽을 경우 그러한 만족도는 많이 떨어질 것이다. 그렇다고, 그 책을 "쓰레기"나 "수박 겉핥기"로 매도하지는 말아 주기 바란다.
책을 쓰는 것은 저자의 이름을 걸고 하는 작업이다.
여러분들이 아무생각 없이 읽을 수도 있는 책의 한 챕터(장)를 쓰기 위해서는 적어도 2주, 많으면 한달이라는 시간이 소요된다.
그 책을 읽고 나서 리뷰를 쓸 때에는 한시간도 걸리지 않을 것이다. 따라서, 블로그나 인터넷 서점에 책 리뷰를 올릴 때에는 저자의 노력을 조금이라고 생각해 주고 써 주었으면 한다.
그래야, 그 저자의 다음 책들을 기다리는 독자를 위해서 여기 저기서 열심히 책을 쓰고 있는 저자, 번역자,그리고 출판사 담당자들에게 힘이 된다.
출판사마다 작업의 방식이 다를 수 있고, 집필자마다 순서가 다를 수 있다. 절대적인 방법이 아니라는 것을 알아두기 바란다. 그리고, 순서대로 읽어주기 바란다.
그럼 세번째... 어떻게 시작해야 할 지에 대해서 알아보자. 집필을 하기 위해서 먼저 해야 하는 것은 "목차"를 만드는 것이다. 다른 것이 우선 아니냐고?
아니다.
먼저 목차를 만들어야 한다. 물론 목차를 만들기 전에는 앞에서도 이야기 했지만, 무엇에 대해서 책을 쓸 지에 "주제"를 선정하고, 자료를 모으는 작업은 선행되어야 한다. 하지만, 이 작업은 책을 쓰지 않는다고 하더라도 누구나 본인이 하는 작업을 정리 할 때 필요한 작업이다.
그래서, 본격적인 집필 시작은 목차를 만드는 작업이라는 것이다.
목차는 뭐 상세 목차까지 적어주면 되겠지만, 그럴 필요는 없이 그냥 대분류 목차로 적어도 15~20개 정도 적어 두면 된다. (되도록이면 엑셀로) 만약 처음 집필하는 분이시라면, 상세 목차도 적어두면 좋을 것이다.
목차가 이쁘게 잘 선정 되었다면, 그 다음에는 출판사에 Contact 하는 것이다. -주변에 아는 사람이나 친구, 친구의 친구가 출판사와 아는 사람이거나, -친구중 저자가 있을 경우에는 그 아는 사람 통해서 Contact하는게 좋다.
만약 지인이 없어도 그냥 출판사에 Contact 해도 뭐라고 할 사람 아무도 없다.
메일로 연락해도 되고, 전화로 해도 되고, 만나도 된다. 아마도 여러분이 제시한 주제, 목차, 구성이 마음에 든다면 직접 만나서 이야기 하자고 할 것이다.
참고로 Blog2Book 자바 성능을 결정짓는... 책의 경우에는 A모 출판사에서 두명의 리뷰어에게 목차 리뷰를 받은 후 빠꾸를 먹었다. (이런책은 아무도 필요 없다는 어떤 리뷰어의 리뷰와 함께... 논란의 여지가 있을 수 있어 말씀드리지만, 다른 한분은 목차가 괜찮다고 하셨지만, 책의 주제를 다른방향(Advanced Java ? 뭐 그런 방향...)으로 바꾸어 보라는 의견을 주셨다.)
하지만 운 좋게도, 그 빠꾸를 먹은날 한빛미디어에 책을 서너권 집필한 저자와 만났는데, 그분이 직접 출판사와 연결 시켜 주셨다. 그때 그 지인이 이야기한 중요한 이야기는 "책을 쓰려고 할때, 자신이 원하는 방향의 책이 아니면 쓰지 않는 것이 나아요. 이책임(그땐 직급이 책임(과장)이었다.)님은 튜닝 책을 쓰려고 한거지 다른 책을 쓰려고 한게 아니잖아요..." 라는 말이다. 그 말에 용기를 얻고 한빛 담당자분과 만나서, 목차를 약간 수정하고 집필하기로 했다. 안 그랬으면, 아마도 그 책은 세상에 나오지도 못했을 것이다.
이 이야기를 왜 하냐면, 여러분들이 직접 쓰고 싶은 책이 있다면, 출판사 하나에서 빠꾸 먹었다고 포기하지 말라는 것이다.
그런데, 어느 출판사나 이익을 내야하기 때문에, 1000부도 팔릴 것 같지 않은 그런 책을 내지는 않는다. 다시 말하면, 여러분들도 사지 않을 그런 책은, 다른 사람도 안산다는 것이다.
필자는 이번에 테스트 책을 썼지만, 원래는 테스트 책을 쓸 생각도 없었다. 그냥 Rex Black 아저씨 책 중 기본이 되는 몇권중 한권을 번역하려고 했었다. 하지만, 그 결과는 4개 출판사에서 그러한 번역서는 시장성이 없다는 이유로 빠꾸 먹었다. - -; 그 4개 출판사와 Contact하는 중에 심심해서 적어 놓은 것이 이번에 나올 Blog2Book Test책의 목차다.
그것도 그냥 책 쓸려고 한 것도 아니고, 그냥 목차만 만들어 놓고 한번 정리해 보면 좋겠다고 생각하고, 출판사 담당자에게 그냥 함 보라고 보여 줬던 것이 화근(?)이 되었다. (그 담당자가 윗분에게 보여드리고, 그분이 한번 진행해 보라는 지시가 떨어져서리...)
여하튼, 출판사에서 OK하면, 책을 누가 보고, 누가 사고, 어떤 내용인지에 대한 소개서를 쓰고, 샘플챕터 하나 써서 내라고 한다.(아무리 목차가 좋아도 글이 맘에 안들면 안되니까...) 그리고 나서 마음에 들 경우, 계약금 받고 (보통 신사임당 10장에서 세금 좀 띄고) 계약서를 쓴다.
그런데, 여기서 한가지 유의할 점은, "뭐 그럴 필요 있나? 다 쓰고 나서 가져가지" 라는 생각을 할 수도 있을 것이다. 그런데, 샘플 챕터를 제출하는 이유는 필자의 어떤 점들을 고쳐야 할지를 확인하는 데에도 의의가 있다.
그렇게 다듬고, 나머지 부분을 작성하는 것과 모두 작성해 놓고 문체나 책의 방식을 수정하는 것은 엄청난 차이가 있을 것이다. (뭐 "난 상관 없어~~" 라는 분들은 그냥 다 써놓고 출판사를 만나도 된다.)
출판사마다 작업의 방식이 다를 수 있고, 집필자마다 순서가 다를 수 있다. 절대적인 방법이 아니라는 것을 알아두기 바란다. 그리고, 순서대로 읽어주기 바란다.
두번째 이야기로, 제목에 있는 자료 모으기에 대해서 알아보자.
제목대로 자료만 잘 모으면 두번째 이야기에서 필자가 말하고자 하는 것은 끝난다. (본인이 자료를 잘 모은다고 생각하면 이 글은 안 읽어도 된다.)
그렇다면, 어떻게 하면 자료를 잘 모으는 것일까?
구글링만 잘하면 자료를 잘 모은다고 할 수 있을까?
꼭 그런것 만은 아니다.
필자가 Blog2Book 자바 튜닝 책을 쓰려고 마음 먹은 것은 출판되기 3년전 이었다. 그냥 말 그대로, 마음만 먹고, 자료를 모으기 시작했다. Sun, IBM, HP등 IT 관련 회사의 뉴스레터를 구독하고, 만약에 튜닝과 관련 있는 내용이라면, 그리고, 내가 경험한 내용도 체계적으로 정리해 놓으려고 노력했다.
그런데, 여기서 중요한 것은 자료를 모으는 것도 중요하지만, 정리하고, 분류하는 것도 중요하다는 것이다.
만약 집에 양말을 보관하는 곳이 두군데 이상이라면, 한곳의 양말이 떨어지면, 두번째 장소를 확인하고, 거기에도 없으면 세번째 장소를 찾아보게 될 것이다. 그 때 발생하는 시간 낭비는 급한 출근 및 등교시간에 적지 않은 시간이다.
여러분들이 모으는 자료도 마찬가지다.
뭐 ~~~ 메일 오면 바탕화면에 대충 저장하고, 나중에 잘 찾으면 되겠지… 라는 생각을 가진 분도 있을 것이고,
뭐 ~~~ 자바라는 글자만 들어가 있으면, 한 폴더에 다 모아서 저장해 놓는 분도 있을 것이다. (여러분들이 Mac을 쓴다면, 검색기능이 워낙 좋아서 신경 쓰지 않아도 되긴 하지만…)
그런데, 그렇게 하면 안 된다는 것이다.
꼭 책을 쓰기 위해서만이 아니라, 여러분이 프로젝트를 하거나, 무슨 일을 하더라도, 자료를 정리하고, 세부적으로 분류하는 습관을 가지면, 나중에 문서를 찾고, 참조할 때 매우 편리할 것이다.
예를 들어 자바도 각각의 패키지로 분류할 수 있고, 신기술도 여러 가지로 분류할 수 있다.
지금과 같은 정보의 홍수 속에, 이렇게 분류하는 것도 여러분들의 능력이다.
다음 글에서 설명하겠지만, 나중에는 이렇게 분류해 놓은 것에 순서만 붙이면, 그게 바로 목차가 된다.
그리고, 여러분들이 모아놓은 자료는 신뢰성이 있어야 한다. 필자가 쓴 책에 있는 내용에 딴지 거시는 분들도 많지만,(뭐 그 말들이 틀렸다는 건 아니고…) 여러분들이 모아 놓은 자료를 100% 신뢰해서는 안된다. 직접 눈으로 확인한 이후에 책에 넣어야만 한다.
보통 책을 집필할 당시에는 하루에 많으면 A4기준 5~10페이지를 쓰는 날도 있지만(그림 및 이미지가 많을 때에는 ㅋㅋ) 하루에 3장 정도 쓰는게 일반적인 속도다.(하루에 책쓰는데 아침과 저녁에 각 한시간씩 두시간 투자할 경우…)
그런데, 한 부분에서 필자도 잘 모르고, 막히는 경우에는 해당 부분의 글을 쓰기 위해서 3주가 소요될 수도 있다. (더 자세한 이야기는 네번째 이야기인 집필하기에서…)
여러분들이 아무리 많은 자료를 모았다고 생각되더라도, 책을 집필할 때에는 많이 부족하다는 것을 느낄 것이다. 그래도 일단 모아라…
자바의 GC 방식에는 여러가지가 있지만, 최근에 나온 기술에는 G1이라는 것이 있다. 최근에 나온 JDK 6.0 update 14에는 early access 로 G1을 사용할 수 있도록 했다. G1을 적용하기 위해서는 java start option에 -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC 라고 명시해 주면 된다.
추가로 G1을 사용할 때 GC로 인한 최대 대기시간을 지정하기 위한 -XX:MaxGCPauseMillis=<X> 옵션을 추가할 수 있으며, -XX:GCPauseIntervalMillis=<X> 옵션을 통해서 GC 대기 사이의 간격을 지정할 수 있다. 그런데 여기서 중요한 것은 이 옵션은 Goal 이다. Promise나 guarantee 가 아니라는 것이다. (목표일 뿐이고, 이건 약속이나 보장한다는 것이 아닐 뿐이고~~)
G1이 다른 GC와 다른 것은 GC를 담당하는 New와 Old의 장벽이 사라졌다는 것~~~ 자세한건 아래 링크의 비됴나 문서를 함 보시길~~~
오늘 팀장님께서 복사한 문서를 한번 읽어 보라고 주셨다.
9개의 자바 성능 팁에 대해서 아~주 간단하게 정리되어 있는 문서다. (2페이지에 걸친...)
그 장의 첫번째 구문에는 Michael A. Jackson 이라는 할아버지가 쓴 글귀가 있다.
The First Rule of Optimization : Don't do it
The Second Rule of Optimization (for experts only) : Don't do it yet.
이 문서가 언제 쓴 문서인지는 모르겠지만.... 이 글귀는 약간 이해는 안된다. ^^;
Tip #1 : Object creation is bad
Tip #2 : static is good ==> I don't think so 다.
Tip #3 : Table switch good, lookup switch bad
Tip #4 : Small methods are good methods
Tip #5 : Exceptions are exceptional
Tip #6 : Use decorator patterns with care
Tip #7 : instanceof is faster on classes
Tip #8 : Use synchronized minimally
Tip #9 : Beware external libraries
먼저 위의 인터뷰 내용을 읽어보자.
Garbage First Collector가 뭔지 대충 감을 잡을 것이다.
분명 대부분 안읽어 보시겠지만....적어도 아래 줄들은 일어 주기 바란다.
G1=next-generation low-pause garbage collector
G1 will ultimately replace the Concurrent Mark-Sweep (CMS) garbage collector
G1, even though it is generational, there is no physical separation between the two generations.
Three Objectives of G1 The first objective is consistent low pauses over time.
The second objective is to avoid, as much as possible, having a full GC.
The final objective is good throughput.
if you care about getting the job done as quickly as possible, and don't care much for how long your application is going to be stopped by the garbage collector, the throughput collector is the best choice.
if you have a batch job that is going to take a few minutes or a few hours and you want it to be done as quickly as possible, then a throughput collector is clearly the best choice.
But, if you are working on a very interactive job that needs to interact with people, other applications, or users through web pages, then a low latency garbage collector is the best choice.
Why does garbage collection take so long? ==> Garbage collection is very memory-bound. And memory speeds these days are quite slow compared to CPU speeds
그리고, 저 이너뷰 한 사람이 사진을 잘 찍는가본데, 사진과 개발과의 상관관계를 아래와 같이 이야기 했다.
You need to be committed and to be patient and try out things again and again, to make sure that you get it just right. I see some parallels between photography and development.
마지막엔 그가 이야기하는 아름다운 코드란....
Beautiful code is code that is simple, easy to understand, and efficient
란다.
물론 JVM 옵션 튜닝만 한다고 해서 답은 안나오겠지만,
튜닝할게 더이상 없다면, JVM 버젼 upgrade 및 옵션 튜닝을 해야 할 것이다.
아래는 이 글의 목차다.
뭐 다 읽기 귀찮으신 분들은 4.2 부터 적용해 보시면 된다.
1 Introduction
1.1 Goals
1.2 This is a Living Document
1.3 How to Use this White Paper
2 Best Practices
2.1 Use the most recent Java™ release
2.2 Get the latest Java™ update release
2.3 Insure your operating system patches are up-to-date
2.4 Eliminate variability
3 Making Decisions from Data
3.1 Beware of Microbenchmarks!
3.2 Use Statistics
3.3 Use a benchmark harness
4 Tuning Ideas
4.1 General Tuning Guidelines
4.1.1 Be Aware of Ergonomics Settings
4.1.2 Heap Sizing
4.1.3 Garbage Collector Policy
4.1.4 Other Tuning Parameters
4.2 Tuning Examples
4.2.1 Tuning Example 1: Tuning for Throughput
4.2.2 Tuning Example 2: Try the parallel old generation collector
4.2.3 Tuning Example 3: Try 256 MB pages
4.2.4 Tuning Example 4: Try -XX:+AggressiveOpts
4.2.5 Tuning Example 5: Try Biased Locking
4.2.6 Tuning Example 6: Tuning for low pause times and high throughput
4.2.7 Tuning Example 7: Try AggressiveOpts for low pause times and high throughput
5 Monitoring and Profiling
5.1 Monitoring
5.2 Profiling
6 Coding for Performance
7 Pointers
8 Feedback and the Java Performance Community
