"왜 책을 쓰시나요?" 대형 출판사 계약을 파기하며 배운 것들

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

개발자라면 누구나 한 번쯤 서점의 기술 서적 코너에서 자신의 이름이 박힌 책을 상상해 보곤 합니다. 저 역시 커리어를 시작하던 시절, 오라일리(O'Reilly)나 위키북스의 두툼한 책들을 보며 언젠가는 저런 지식의 정수를 남기고 싶다는 꿈을 꿨었죠. 하지만 기술 리더로서 조직을 운영하고 제품을 만들다 보니, '무언가를 만드는 과정' 자체가 결과물만큼이나 중요하다는 사실을 뼈저리게 느끼곤 합니다. 최근 카네기 멜론 대학의 오스틴 헨리(Austin Z. Henley) 교수가 자신의 블로그를 통해 공개한 "책 계약을 취소한 사연"은 엔지니어링과 비즈니스 사이의 미묘한 줄다리기를 적나라하게 보여주어 많은 생각을 하게 만들었습니다. 오늘은 그의 실패담을 통해 우리가 제품과 콘텐츠를 대하는 태도에 대해 이야기해보고자 합니다.

오스틴 교수는 꽤 인기 있는 기술 블로거입니다. "프로그래머가 시도해봐야 할 도전적인 프로젝트들" 같은 글들이 수백만 조회수를 기록하면서 자연스럽게 대형 출판사들의 러브콜을 받게 되었죠. 처음엔 자비 출판을 고려하다가, 물류 처리와 유통 채널, 그리고 무엇보다 '편집자의 강제성'이 있다면 지지부진한 집필 속도를 높일 수 있을 거란 기대로 계약서에 서명했습니다. 주제는 매력적이었습니다. 웹 크롤러, 컴파일러, HTTP 서버, 에뮬레이터 같은 '근본 있는' 기술들을 직접 구현해보는 튜토리얼북이었죠.

하지만 막상 프로젝트가 시작되자, 우리가 현업에서 흔히 겪는 '기획 의도와 비즈니스 요구사항의 충돌'이 시작되었습니다. 출판사는 철저히 상업적인 논리로 접근했습니다. 컴파일러를 만드는 심도 있는 기술서에 갑자기 "초보자를 위해 파이썬 기초와 패키지 설치법(pip)을 앞부분에 넣어달라"고 요구했습니다. 독자층을 넓히기 위한 전략이었겠지만, 저자 입장에서는 책의 핵심 철학인 '밑바닥부터 원리를 파헤치는 즐거움'을 해치는 일이었습니다. 저자의 개성이나 깊이보다는, 서가에 꽂혔을 때 무난하게 팔릴 수 있는 '표준화된 상품'을 원했던 것입니다.

가장 결정적인 갈등은 'AI'였습니다. ChatGPT 열풍이 불자 출판사는 "윗선 지침이니 모든 책에 AI 내용을 포함하라"고 압박했습니다. 오스틴 교수는 고전적인 프로그래밍 원리를 다루는 이 책의 성격과 맞지 않는다며 거부했지만, 출판사는 집요했습니다. 결국 그는 타협안을 제시하다가 "이건 내가 쓰려던 책이 아니다"라는 결론에 도달하게 됩니다.

이 과정은 우리가 소프트웨어를 개발할 때 겪는 상황과 놀랍도록 닮아있습니다. 처음에는 명확한 문제 해결을 위해 시작된 프로젝트가, 이해관계자들의 요구사항을 하나둘 수용하다 보면 어느새 본질은 사라지고 기능만 덕지덕지 붙은 '괴물(Feature Creep)'이 되곤 합니다. 특히 요즘처럼 AI가 트렌드인 시기에는 더욱 그렇습니다. 기술적 타당성이나 제품의 본질과는 무관하게 "일단 AI 기능을 넣자"는 의사결정이 내려질 때가 있습니다. 풀링포레스트에서도 항상 경계하는 부분입니다. 기술은 도구일 뿐, 그 자체가 목적이 되어 제품의 본래 가치를 훼손해서는 안 됩니다.

경제적인 관점에서의 ROI(투자 대비 수익) 분석도 흥미롭습니다. 오스틴 교수가 제안받은 선인세는 5,000달러(약 650만 원) 수준이었고, 로열티는 12~15%에 불과했습니다. 개발자가 1년 넘게 주말과 밤을 갈아 넣어 얻는 보상치고는 턱없이 부족합니다. 게다가 판권에 대한 통제권도 잃게 되죠. 그는 결국 "돈이 목적이 아니라면, 내가 쓰고 싶은 내용을 내 방식대로 쓰는 것이 맞다"는 깨달음을 얻고 계약을 파기했습니다.

우리는 종종 '완주' 자체에 너무 큰 의미를 부여하곤 합니다. 하지만 방향이 잘못되었다면, 그리고 그 과정에서 내가 지키고자 했던 핵심 가치(Core Value)가 훼손된다면, 과감하게 '중단'하거나 '피봇(Pivot)'하는 용기도 필요합니다. 오스틴 교수는 비록 책 계약은 취소했지만, 그 경험을 통해 자신이 진짜 전달하고 싶었던 지식의 형태가 무엇인지, 그리고 타인의 플랫폼에 의존할 때 치러야 할 대가가 무엇인지 명확히 배웠습니다.

개발자로서, 혹은 기술 리더로서 무언가를 만들 때 항상 자문해봐야 합니다. "이것은 누구를 위한 기능인가?", "트렌드를 쫓느라 본질을 놓치고 있진 않은가?" 오스틴 교수가 지키고 싶었던 것은 단순히 원고 뭉치가 아니라, '스스로 원리를 깨우치는 즐거움'이라는 엔지니어링의 정수였을 겁니다.

저 또한 풀링포레스트에서 팀원들과 함께 제품을 만들며 끊임없이 고민합니다. 외부의 화려한 트렌드나 무리한 확장이 우리 서비스의 본질을 흐리게 두지 않겠다고 다짐합니다. 때로는 멈추는 것이, 혹은 남들이 가지 않는 길을 고집하는 것이 가장 빠른 길일 수도 있으니까요. 여러분이 지금 만들고 있는 코드는, 그리고 그 안에 담긴 철학은 안녕하신가요?