Codex를 사용하여 상업 서적 출판을 초고속화하는 노하우

저는 지금까지 감사하게도 여러 권의 상업 기술서를 출판할 기회를 얻었습니다.

오랫동안 라이터를 해온 것은 아니며, 엔지니어 업무를 병행하며 절반은 취미로 2년 정도 집필을 해오고 있습니다.

원래 Qiita를 쓰는 데 익숙하여 글 쓰는 속도가 빠른 점도 있지만, 특히 최근 반년 정도는 Claude Code나 Codex와 같은 코딩 AI 에이전트(Coding AI Agent)의 진화가 눈부셔, 모든 업무를 초고속화하는 데 사용할 수 있게 되었습니다.

이번에는 「상업 서적 출판(특히 IT 기술서)」에 초점을 맞추어, AI로 초고속화하는 테크닉을 소개합니다.

이 기사는 모두 직접 작성했습니다. 안심하고 읽어주세요.

"어, 서적의 본문을 AI에게 생성하게 한다고?"라고 생각하기 쉽지만, 그렇지 않습니다.

어디까지나 집필 이외의 주변 작업을 모두 AI로 반자동화하여, 저자는 집필에, 편집자는 리뷰에 집중할 수 있는 환경을 조성한다는 컨셉입니다.

"xx에 관한 서적을 집필해 줄 수 없겠느냐"라는 의뢰를 출판사의 편집자로부터 저자가 받는 형태에서 시작하는 기획이 많지 않을까 생각합니다.

먼저 집필 리포지토리(Repository)를 만듭시다. 여기서부터 AI화가 시작됩니다.

빈 폴더를 만들고, 그곳에서 VS Code로 Codex(혹은 Claude Code)를 열어, 음성 입력으로 첫 번째 프롬프트(Prompt)를 대량으로 쏟아붓습니다. 아래는 예시입니다:

SB Creative로부터 AWS의 AgentCore에 관한 서적 집필 의뢰가 왔으므로, 앞으로 이 디렉터리를 사용하여 기획부터 집필, 구성, 그리고 출판, 마케팅 등의 활동을 모두 진행해 나갈 것입니다. 이것은 GitHub의 프라이빗 리포지토리(Private Repository)에 푸시(Push)하여 운용할 예정이며, 나중에 공동 저자나 편집자 등 필요에 따라 추가해 나갈 예정입니다. 향후 네가 작업하기 쉽도록 필요한 Codex의 초기 설정이나 agents.md, 스킬, 규칙, 서브 에이전트(Sub-agent) 등 디렉터리 구조를 앞으로 작업하기 쉬운 형태로 정리해 주세요. 필요에 따라 마크다운(Markdown) 파일을 생성하고 정보를 정비하여 사용하기 쉽게 초기화 작업을 진행해 주세요. 다음은 공유된 기획서이므로, 원본을 복사하여 정리한 뒤 내용을 읽어 들여 md 파일로 별도로 정리해 두어. /Users/minorun365/Desktop/기획서.pptx

위의 내용은 샘플이지만, 5분 정도 말하여 이것의 10배 정도 되는 컨텍스트(Context)를 대량으로 제공합니다.

코딩 에이전트는 Codex나 Claude Code 등 어느 정도 인기가 있는 최신 것이라면 무엇이든 OK입니다. 저의 경우에는 집필 중에 Claude Code의 성능 저하가 심해져서 Codex로 갈아탔습니다.

Claude Code를 사용할 경우, 지금은 Opus 4.6을 사용하면 좀 낫습니다.

이하에서는 「Codex」라고 대표하여 기술하겠습니다.

친절한 편집자라면 목차 안(Draft) 등도 제안해 주겠지만, 어디까지나 기술서는 그 분야의 전문가인 저자가 구성을 주도해야 합니다.

어떤 방향성의 테마로, 어떤 사람을 타겟으로 하여, 어떤 식으로 장을 구성할 것인가. 경쟁 관계에 있는 기존 도서가 나와 있는가. 유사 테마 서적의 인기 정도는 어느 정도인가 등, Codex에게 조사를 시켜 리포트를 정리하게 하면서 함께 브레인스토밍(Brainstorming)하며 안을 검토합니다.

여기서도 중요한 것은 저자 자신이 머릿속 내용을 음성 입력으로 확실히 덤프(Dump)하면서, 골격이 되는 플롯(Plot)을 Codex에게 주는 것입니다. 콘텐츠 계열은 해당 테마에 대한 실무 경험이 부족한 사람이 AI에게 통째로 맡겨서 만들면, 그럴듯해 보이지만 내용이 빈약하고 얕은 작품이 되어버립니다.

편집자나 공동 저자와 회의를 했을 경우에는 회의록을 Codex에 읽혀서 정리하게 하고, 함께 검토에 참여하도록 합시다.

예를 들어 오프라인 회의 중에 iPhone 표준 녹음 앱으로 찍은 소리를 그대로 텍스트로 변환하여 복사할 수 있으므로, 그것을 Slack에 붙여넣고 논의의 중간 과정을 빠르게 마크다운으로 정리하게 한 뒤, 그것을 계속해서 다 함께 논의하며 Codex로 브러시업(Brush-up)시키는 인터랙티브(Interactive)한 회의 진행도 가능합니다.

작업 디렉터리는 GitHub의 프라이빗 리포지토리로 동기화하고, 편집자나 공동 저자도 처음부터 참여하게 합시다.

원고는 마크다운(Markdown)으로 쓰는 것을 추천합니다. 중간까지 Google Docs 등으로 작성했던 사람이라도 Codex에게 부탁하면 MCP(혹은 Apps)를 사용하여 읽어 들여, 적절하게 GitHub & md로 변환해 주므로 이행도 간단합니다.

제목의 레벨감이나 집필 규칙 등 DTP 상의 제약이 있는 경우에는 rules에 적어 둡시다. (물론 Codex 스스로 작성하게 합니다.)

저의 경우에는 과거에 쓴 저서의 페이지를 몇 장 iPhone으로 촬영한 뒤, 그 이미지를 Codex에 읽게 하고 "이것과 동일한 포맷으로 쓸 수 있도록 rules를 만들어 둬"라고 전달합니다.

내용 집필은 사람이 열심히 해야 합니다. 상업지처럼 높은 퀄리티를 요구하는 경우, 아직은 100% 수기(Handwriting)가 유리합니다.

다만, 다소 휘갈겨 쓴 내용이라도 세밀한 수정은 rules를 사용하여 나중에 Codex가 해줍니다.

나아가, 집필을 시작하기 전에는 Codex와 함께 브레인스토밍(Wall-hitting)을 하며 목차 안이나 장(Chapter)별 내용 구성 등을 브러시업(Brush-up)한 뒤, 그것을 보면서 쓰기 시작하면 원활합니다.

최근, 명백히 AI로 생성한 것 같다~ 싶은 상업 서적이 늘어났지요..

귀중한 일본의 출판 업계가 독자로부터 외면받지 않도록, 저자는 요령을 피우지 않고 노력하고 싶습니다.

AgentCore 책에서는 처음에 생각했던 목차 안으로는 AgentCore 장이 너무 무거워졌기에, 4부 구성으로 바꾸고 소제목 재구성 등을 대폭 진행했습니다.

이런 작업도 기존에는 매우 힘들었지만, Codex를 사용하면 아주 쉽습니다.

기술적인 면은 Web Search나 MCP 등을 통해 최신 문서를 계속 참조하게 하는 것은 말할 것도 없습니다.

AgentCore의 경우, 문서 업데이트조차 따라가지 못하거나 문서에 오류가 있는 케이스도 가끔 있었기 때문에, 집필 내용에 오류가 없는지 항상 CLI와 GUI 콘솔(MCP로 브라우저 조작) 양쪽 모두를 Codex가 자동 검증하여 사실 관계를 확인(Back-up/Verification)하도록 했습니다.

편집자분이 고마워하셨던 것은 페이지 수 예측 스킬입니다. 원고의 초창기 단계에서, 기출간된 포맷에 비추어 볼 때 몇 페이지 정도가 될 전망인지 상당히 정확하게 계산해 주기 때문에, 출판 전 가격 조정 등을 하기 수월했던 것 같습니다.

원고에 삽입할 이미지 안도 파워포인트에 슬라이드를 추가해 나가고, 그것을 Codex가 이미지화하여 마크다운(Markdown)에 삽입하게 합니다. 한 번 성공하면 일련의 흐름을 스킬(Skill)로 만들어 둡니다.

이전에는 저도 Google Docs로 원고를 쓰고, 편집자분께 편집 제안이나 코멘트 형식으로 리뷰를 받곤 했습니다.

Codex와 작업할 때는 GitHub에 집약할 수 있으면 효율적이므로, 우선 GitHub 사용법(특히 Issue와 PR 작성 방법)을 Codex에게 절차로 작성하게 하여 편집자분께 공유했습니다.

각 장의 리뷰 내용은 대략적인 지시는 Issue에, 세세한 오타 수준의 수정 지시는 PR을 작성하도록 했습니다.

리뷰에 대한 저자의 대응은 매우 편해집니다. Codex에게 "편집자분으로부터 새로운 리뷰가 왔는지 확인하고, 리뷰 내용과 해당 장의 원고를 모두 읽은 뒤, 대응안을 Before/After가 알기 쉽게 하나씩 나에게 제안해 줘"라고 전달합니다.

그렇게 하면 일문일답 형식으로 리뷰 대응을 진행할 수 있어, 이동 중에 모바일 앱으로도 리뷰 대응을 이어갈 수 있습니다. PC에서 차분히 다시 쓰고 싶은 무거운 작업은 "나중에 할 거니까 To Do로 메모해 둬"라고 말하면 끝입니다.

기술서에서는 샘플 코드나 핸즈온(Hands-on)도 다수 작성합니다.

우선 최신 문서를 베이스로 하여, 독자가 이해하기 쉬운 최소한의 샘플 코드를 작성하고 그것의 동작 확인까지 Codex가 수행하게 합니다. 코멘트의 상세도나 코딩 규칙(Coding Rule) 등도 rules를 키워나가며 저자의 취향에 맞춰갑니다.

특히 핸즈온은 주의가 필요한데, 동작 환경과 라이브러리 버전을 고정하지 않으면 초보자가 막힐 수 있기 때문에, 저의 경우에는 GitHub Codespaces를 사용하며 라이브러리 계열은 교정 직전의 최신 버전으로 고정하고 있습니다.

버전 리스트는 당연히 Codex에게 정리하게 하고, 그것을 저자들 간에 공유하여 각 장에 반영되었는지 체크합니다.

집필 중에는 매일 라이브러리가 업데이트되므로, 매일 밤 자는 동안 자동으로 Codex를 실행시켜 모든 장의 샘플 코드와 핸즈온을 자동 E2E 테스트하게 하여, 아침에 일어나면 문제점 리포트가 나와 있도록 합니다.

몇 번이고 하고 싶지 않은 초기 설정이나, 도저히 재현하기 어려운 GUI 조작 등 일부는 자동 테스트용으로 어레인지(Arrange)하고 싶은 부분도 있으므로, 이 부분은 Skills로서 키워 나갑니다.

또한, 샘플 코드류는 모아 두었다가 출판 직전에 독자용 공개 리포지토리(Repository)로 별도로 분리합니다.

원고 리뷰가 끝나고 마크다운을 DTP로 입고하면, 게라(Gala/Proof)라고 불리는 지면 디자인에 맞춘 PDF가 올라옵니다.

이를 보고 편집자·저자가 '적자(Redline)'라고 불리는 수정 요청을 넣어가는데, 기존에는 PDF에 Acrobat 등의 코멘트 기능을 사용하여 하이라이트를 치거나 수정 지시를 기입하는 경우가 많았을 것입니다.

Codex를 사용하는 경우에는 항상 원고 마크다운 (Markdown)을 최신 상태로 유지하는 운영 방식을 취합니다.

편집자분들은 기존 방식대로 PDF에 빨간 글씨(수정 사항)를 기입해 주시는데, 이를 Codex로 파싱 (Parsing)하여 수정 지시 사항을 원고 md 파일에 반영합니다. 그 후 저자가 확인하며 신경 쓰이는 점은 모두 원고에 반영해 두고, 마지막으로 원고와 PDF의 차이점(Diff)을 검출하게 하여 그 차이점을 모두 PDF에 빨간 글씨 코멘트로 삽입하게 합니다.

이 또한 Codex로 자동화할 수 있습니다. (Python 라이브러리를 사용합니다)

또한, 각 장의 교정쇄 (Gala)는 당연히 Codex에게 여러 번 체크하게 하여, 최신 정보와의 불일치나 오탈자가 없는지 등을 확인하도록 했습니다. 사람이 보면 절대 알아채지 못할 실수도 99% 추출해 줍니다.

번거롭지만 장(Chapter) 단위로 나누어 리뷰하게 하는 편이 정밀도가 높아집니다.

여담입니다만, 구성 단계 중에 Claude Code의 /insights 명령어로 저의 작업 스타일을 분석시킨 결과가 다음과 같습니다.

출판이 다가오면 여러 분께 증정본을 전달하거나, X(구 Twitter)에서 캠페인을 진행하여 특제 티셔츠를 배포하는 등 프로모션 활동을 저자 스스로도 수행합니다.

증정처 관리나 히어링 폼 (Hearing Form) 작성, 티셔츠 발주 (배송지마다 별도 주문 필요) 등도 모두 Codex에게 맡겼습니다. 개인정보 취급에는 최신의 주의를 기울이도록 rules 등으로 규칙화하는 것은 물론, 1Password CLI를 사용하여 일시적으로 다루는 정보도 데이터로 노출되지 않도록 주의했습니다. 사람이 수동으로 Excel을 사용하여 관리하는 것보다 훨씬 안전하게 작업할 수 있었다고 생각합니다.

기술서의 힘든 점은 출판 후에도 독자로부터 문의를 받거나, 기술 업데이트로 인해 갑자기 서적의 내용이 낡아지거나 샘플 코드 (Sample Code)가 동작하지 않게 되는 부분입니다.

저는 Codex의 자동화 (Automation, Claude Code라면 루틴 (Routine)) 기능을 사용하여, 관련 라이브러리나 문서의 업데이트를 매일 아침 체크하고, 문제가 있으면 Issue를 생성하여 저자에게 통지하도록 하고 있습니다.

dependabot이 매일 생성하는 PR (Pull Request) 중에서도 독자의 핸즈온 (Hands-on) 흐름상 문제가 없는 것은 자동으로 머지 (Merge)하는 작업도 자동화해 두었습니다.

이런 식으로 두 권을 병행하며 책을 썼는데, 정말 죽을 만큼 힘들었습니다 ㅋㅋ

저도 공동 저자도 본업은 IT 기업의 엔지니어라 심야 시간이나 주말을 이용해 쓰고 있으니 어쩔 수 없네요.

최고의 서적으로 완성했으니, 꼭 한 권씩 손에 넣어주세요!!