Skip to content

Latest commit

 

History

History
46 lines (26 loc) · 7.05 KB

hidden_purposes.md

File metadata and controls

46 lines (26 loc) · 7.05 KB

<프로그래머의 책쓰기> 또 다른 의도...

★ 이 글을 읽으신 길벗의 베테랑 기획자께서 제가 너무 일반화하여 오해살 부분이 있다며 여러 말씀을 주셨습니다. 말씀 참고하여 “두 번째 의도” 끝에 부연하였습니다.

<프로그래머의 책쓰기>는 제목이 말하듯 프로그래머를 위한 책쓰기 가이드입니다. 글쓰기조차 익숙하지 않은 대부분 프로그래머에게 막연하기만 한 책쓰기를 권장하고 진입장벽을 낮춰주고자 하는 것이죠.

그런데 여기서 끝이 아닙니다. 실은 두 번째, 세 번째 의도가 숨어 있습니다.

두 번째 의도

는 바로 IT 출판 기획자를 위한 레퍼런스 혹은 교육자료 축적입니다.

프로그래머에게 책쓰기가 낯설듯, 대부분 IT 출판 기획자에게 IT는 낯섭니다. 전문용어와 코드가 난무하며 여유, 재치, 해학, 반전, 갈등, 해피엔딩 같은 건 찾아볼 수 없습니다. 재미없고 이해도 안 되니, 어느 정도 거리가 느껴지는 것은 당연하겠죠. 그 결과… IT 출판 기획자를 구하기가 너무 어렵습니다. ^^ IT도 잘 알면서 책을 만들려는 사람은 거의 없고, IT를 모르는 사람이 훌륭한 IT 출판 기획자로 성장하기도 만만치 않습니다.

또한, 출판 기획이 시스템보다는 개인 역량에 많이 의존합니다. 제가 이 바닥 경력이 길지 않아 단정하긴 조심스럽지만, 적어도 제 좁은 식견으로는 그런 경향이 강합니다. 물론 제가 팀플레이와 공유가 생활화된 개발 쪽에 몸담다 와서 더 그렇게 느껴지기도 할 겁니다. 어쨌든 개인 역량에 크게 의존한다는 말은 곧 ‘개인 노하우 == 경쟁력’이란 등식으로 이어지고, 그래서인지 자신의 것을 다 내보이고 함께 성장하는 문화가 개발 쪽보다는 확실히 약해 보였습니다.

공유를 하려면 남들도 이해할 수 있게 체계적으로 정리해야 합니다. 반대로 바라보면, 공유 문화가 약하면 정리 기술이 잘 발달하지 못하겠죠. 2014년, 창립 20주년이 넘은 우리나라 최대 IT 전문 출판사에 입사해 느낀 점도 이와 다르지 않았습니다. 책을 만드는 외적인 프로세스는 잘(지나치게 ^^) 정리되어 있지만 책 자체를 어떻게 만드는지에 관한 ‘정리된’ 노하우는 상대적으로 크게 빈약했고, 그나마 (제 기준으로는) 단편적이거나 추상적이었습니다. 멋진 책을 만든 노하우가 후대로 이어지기 어려운 상황!

IT 책 기획이란 일이 더 어렵게 느껴지는 이유였습니다. 다른 분야 책을 만들던 사람이나 IT 기술에 익숙한 사람은 그나마 적응해나갈 수 있지만, 둘 다 익숙지 않은 신입 IT 출판 기획자는 그 게이트조차 무사히 통과하기가 쉽지 않아 보였습니다.

그래서 이런 자료가, 특히 패턴별 가이드가 다양하게 갖춰진다면 조금 달라질 것 같습니다. 지금 공개한 것보다는 훨씬 많아져야겠지요. 그렇게만 되면 신입 기획자를 든든한 동료로 이끌기가 한걸음 수월해질 것 같습니다. 제가 출판인으로 전직한 후 줄곧 갈구한 자료이기도 하고요. ^^

다시 말해, <프로그래머의 책쓰기>를 출판 기획자들도 많이 보고, 더 많은 기획자가 자신만의 멋진 가이드를 만들어 동료와 공유하고 후임에게 물려줬으면 합니다.

편집자 공유 문화에 관하여

편집자들 공유 문화는 강합니다. 다만, IT인이 아닌 책을 만드는 사람들이다 보니 주로 책으로 만들어서 공유합니다. 많은 공과 시간을 들여 기획, 편집, 제작, 마케팅 등 다양한 층위의 관련 경험을 책으로 내고 공유하고 있습니다. SBI 출판 협회를 만들고 매년 기수를 선발해서 6개월, 주 40시간 무상 교육을 하며 출판 종사자를 키워내는 교육도 합니다.

이 글에서 말한 제 취지를 더 정확히 풀어보면 “IT 전문서 기획 쪽에 아직 부족한 부분이 있어 보이니 함께 채워가 보자”입니다. 그 방법이 개발자 친화적이라면 일거양득일 것 같고요. 그래서 나름의 방식을 시도해봤고, 이렇게 중간 결과와 의도를 밝혀 화두를 던져봤습니다. ^^ (빠르게 피드백 주신 한동훈 님 감사합니다! 이런 게 제가 원한 것이죠!! 다른 분들과도 편하게 이런저런 이야기 나누면 좋겠습니다.)

세 번째 의도

프로그래머/출판 기획자 사이의 원활한 커뮤니케이션을 위한 토대 마련입니다.

설계를 논할 때 디자인 패턴을 아는 사람과의 이야기 방식은 패턴을 모르는 사람과의 이야기 방식과 다릅니다. 디자인 패턴은 그 의도와 구체적인 형태를 잘 정의해놓았고, 주로 쓰이는 분야와 장단점도 많이 알려졌습니다. 상대에게 패턴의 이름을 내뱉는 것만으로 이 모든 것을 함께 전달하게 되어 논의가 훨씬 빠르게 진행됩니다. 맘에 드는 패턴들을 포함해 대략적인 설계가 나오면, 이를 실제 문제를 가장 잘 풀어내는 형태로 변형하고 구체화하여 구현에 들어가죠.

IT 책쓰기 패턴은 프로그래머와 출판 기획자가 만나 새로운 책의 큰 그림을 그릴 때 똑같은 기능을 합니다. 패턴들을 늘어놓고, 대상 독자의 특성과 책의 주제와 경쟁서와의 차별점 등을 고려해 맘에 드는 후보 패턴들을 고릅니다. 이를 기초로 적절히 재구성하고 고유한 향을 뿌리면 책 한 권의 설계가 완성되는 식이죠.

IT 책쓰기 패턴은 화성 토박이 프로그래머와 모태 금성인 출판 기획자 모두가 이해할 수 있는 구체적인 가이드입니다(적어도 그렇게 만들고자 합니다). 그래서 둘의 역사적인 첫 만남이 아래 같이 서로 동상이몽하는 줄 모르고 흡족해하며 헤어지는 일이 크게 줄어드리라 기대합니다.

기획자가 생각한 (대중적으로) 예술적인 책의 설계도 프로그래머가 생각한 (공학적으로) 예술적인 책의 설계도

마치며

이러한 이유로 <프로그래머의 책쓰기>, 특히 패턴별 집필 가이드를 프로그래머뿐 아니라 IT 출판 업계의 기획자들도 관심 있게 보고, 응용하고, 함께 발전시켜갔으면 하는 바람입니다. 그리하여 여러 사정으로 번역서에 크게 의존하는 국내 IT 전문서 시장에, 우리 프로그래머가 쓴 책이 조금 더 많이 제때 출간되는 데 미약하나마 밑거름이 된다면 편안히 눈을 가..ㅁ...