하네스 엔지니어링으로 책 쓰기

1단계. 소개

완성된 스킬을 내려받아 실행하면, AI 에이전트 팀이 자동으로 책 한 권을 완성합니다

리더를 위한 3줄 요약

얻는 것

코드 한 줄 쓰지 않고, 내 머릿속 전문 지식을 책 한 권 분량의 초안으로. 편집까지 끝난 Word 파일이 손에 들어옵니다.

내가 할 일

기획서 한 장(제목, 대상 독자, 목차)을 채우고, 준비된 명령 4개를 순서대로 누르는 것. 나머지는 AI 팀이 합니다.

왜 중요한가

한 번 잘 만든 이 생산 라인은 그대로 재사용됩니다. 다음 책은 기획서 한 파일만 갈아끼우면 됩니다. 사람이 아니라 시스템이 책을 찍어내는 셈입니다.

⏱️ 약 8시간에 한 권 🧐 리뷰어 9명 검수 ✅ 합격선 10점 만점에 9점

📚 SKILL · 바로가기 book_publishing · AI 책쓰기 하네스 스킬 github.com/airoasting/book_publishing →

📖

이 페이지는 하네스 엔지니어링이란?과 Claude Code 101을 먼저 읽으면 더 잘 이해됩니다.

출판사 조직을 한번 떠올려 보세요. 편집장이 큰 그림을 그리고, 리서처가 자료를 모으고, 작가가 글을 쓰고, 편집자가 다듬고, 교정자가 오탈자를 잡습니다. book_publishing 스킬 안에는 이 출판사가 통째로 들어 있습니다. 팀원 4명의 업무 매뉴얼(research·write·review·publish), 사장 역할의 규칙서(SKILL.md), 이번 책의 기획서(user-book-toc.md)까지 다 짜여 있습니다. 여러분이 새로 설계할 것은 없습니다. 레포를 내려받아 실행하면 됩니다.

사람이 약 3시간을 쓰고, AI가 약 5시간을 일하면, 합쳐서 약 8시간 만에 한 권이 나옵니다. 이 페이지는 그 스킬이 어떻게 짜여 있고, 어떻게 돌리는지를 지금부터 여섯 단계로 나눠 설명합니다.

✏️ 유저가 입력

🤖 AI 에이전트 4역할 · 스킬 4개 (슬래시 커맨드)

0

user-book-toc.md

기획서 한 파일

1

/research

웹 조사
(Tier 1·2·3 출처 분류)

2

/write

구조 설계 + 초안
(첫 호출에 청크 단위 1회 질의)

3

/review

내부 6단계 + 외부 3단계
+ 최종 수정

4

/publish

자동 검증 + Word 변환
+ 출판 메타데이터

실제 예시로 보기: 이 기획서 한 장이 이 책이 됩니다

아래는 이 하네스로 실제로 만든 책 『노트북LM으로 다 됨』의 결과물과, 그 결과를 만든 기획서(user-book-toc.md)입니다. 같은 파일 형식에 내용만 바꾸면 전혀 다른 책이 나옵니다.

최종 산출물 · 262페이지 완성본 (.docx → PDF)

262페이지 7부 + 활용법 20 프롤로그 · 에필로그 · 부록 A~D Word 서식 · 시각 자료 자동 삽입

이 책을 만든 기획서 · user-book-toc.md (발췌)

# 책 설정 (이 파일만 교체하면 다른 책을 쓸 수 있다) ## 기본 정보 - 제목: 노트북LM으로 다 됨 - 부제: 팀장이 바로 쓰는 실전 활용법 20 - 필명: AI ROASTING - 대상 독자: AI 도구에 관심이 있지만 기술 배경이 없는 직장인 - 판형: B5 (176mm x 250mm) - 목표 분량: 240~250페이지 (약 120,000~150,000자) - 기준 연도: 2026년 ## 페르소나 노트북LM을 팀 50명과 직접 써본 직장인 선배다. AI 전문가가 아니라 평범한 회사원이었는데, 노트북LM을 써보면서 업무가 달라진 경험이 있다. 말투: "나도 처음엔 몰랐는데, 써보니까 이렇더라"는 톤. 옆자리 선배가 커피 한 잔 들고 와서 알려주는 느낌으로, 독자를 동료로 대한다. ## 목차 ### 프롤로그: 일하는 방식, 노트북LM 이전과 이후로 나뉩니다 ### 제1부: 고수는 이렇게 씁니다 - 제 1장. 200페이지 보고서를 5분 만에 읽는 팀장 - 제 2장. 임원 보고 전날 밤을 바꾼 기획자 ... ### 제6부: 월요일 아침부터 바로 쓰는 실전 시나리오 - [활용법 12] 업무 보고서 30분 만에 초안 뽑기 - [활용법 13] 회의록에서 액션 아이템 자동 추출하기 ... ### 에필로그 / 부록 A~D / 참고문헌 ## 활용법 세부 가이드 각 활용법은 도입, 핵심 개념, 실전 워크플로우, 프롬프트 예시, 실전 팁, 핵심 정리 박스 6요소를 반드시 포함한다. ## 작성 스타일 - 문체: 자연스러운 한국어, 어미는 해라체로 통일 - em dash(—, –)는 절대 사용하지 않는다 - 불릿 포인트는 • (middle dot)를 사용한다 - 영어 표현 최소화: "Before/After" 대신 "사용 전/사용 후" ## 퍼블리싱 사양 - 본문 폰트: Pretendard 11pt, 줄간격 1.2 - 부 제목: 22pt 볼드, 색상 #1F4E79, 새 페이지에서 시작 - 각 활용법 끝에 "핵심 정리" 박스: 배경 #E8F0FE, 테두리 #1F4E79 - 시각 자료: 각 장마다 최소 1개, matplotlib로 생성

* 실제 파일은 목차 전체와 활용법 20개, 검증 규칙까지 약 290줄입니다. 여기서는 6개 섹션이 어떻게 채워지는지 보이도록 발췌했습니다.

하네스 없이 AI로 책 쓰기

매번 처음부터 지시를 다시 내려야 함
장마다 문체가 달라짐
사실 확인 없이 출판되는 위험
다른 책 쓸 때 또 처음부터 시작

하네스와 함께 AI로 책 쓰기

규칙이 파일에 저장되어 일관성 유지
9명의 리뷰어가 2라운드로 품질 검증
출처를 Tier 1·2·3으로 분류해 인용
user-book-toc.md만 교체하면 다른 책 제작 가능

시작 전 준비물

Claude Code가 설치되어 있어야 합니다 (Claude Code 101 참고)
터미널(맥) 또는 명령 프롬프트(윈도우)를 열 수 있어야 합니다
책의 주제를 미리 정해 두면 좋습니다 (예: "비개발자를 위한 AI 활용법")

2단계. 팀 구성

다운로드하면 이 팀이 이미 꾸려져 있습니다

여러분이 출판사 사장이라고 상상해 보세요. 책을 한 권 만들려면 작가만 있어서는 안 됩니다. 자료를 모으는 리서처도, 글을 다듬는 편집자도, 오탈자를 잡는 교정자도 있어야 합니다. 이 스킬은 그 팀을 이미 다 갖춰 두었습니다. 여러분이 사람을 뽑을 필요는 없고, 누가 무슨 일을 하는지만 알면 됩니다.

크게 보면 팀은 3명의 핵심 멤버로 움직입니다. 각각 슬래시 커맨드 하나로 실행됩니다.

🔍

리서처

웹에서 자료를 수집하고, 출처를 Tier 1·2·3으로 등급 매겨 정리합니다. 공식 문서가 1순위, 블로그·SNS는 신호 정도로만 사용합니다.

슬래시 커맨드: /research

✍️

저자

리서처가 모은 자료를 바탕으로 세부 목차를 설계하고, Part 단위로 끊어서 초안을 작성합니다. 첫 호출 때 청크 단위로 한 번에 질의해 흐름이 끊기지 않게 합니다.

슬래시 커맨드: /write

🧐

합평단 (9명)

비평·독자·5인 합평·편집자·프루프리더가 순서대로 원고를 다듬습니다. 마케터 1명은 외부 자문으로 따로 의견을 더합니다(본문 미반영).

슬래시 커맨드: /review

왜 9명이나 필요한가?

한 사람이 자기 글을 검토하면 자기 실수가 잘 안 보입니다. 시각이 다른 9명이 단계별로 보면, 비평가가 못 잡은 걸 독자가 잡고, 독자가 못 본 걸 사실 검증가가 잡습니다. "역할이 다른 눈"을 여러 번 통과시키는 게 품질을 끌어올리는 가장 확실한 방법입니다.

합평단 9명, 어떤 순서로 어디서 일하나

아래 표는 9명이 일하는 순서입니다. 위에서 아래로 한 줄씩 통과해야 다음 단계로 갑니다.

단계	리뷰어	이 사람이 잡는 것
내부 리뷰 1차 (초안 다듬기)	01 🔴 비평가	근거 없는 주장과 논리 비약을 잡습니다
내부 리뷰 1차 (초안 다듬기)	02 🟠 독자	어렵거나 흥미가 끊기는 부분을 지적합니다
합평 5인 2라운드 (품질 게이트)	03 사실 검증가	통계와 인용의 출처를 확인합니다
	04 구조 검증가	목차와 흐름의 일관성을 점검합니다
	05 논리 검증가	전제와 결론의 연결을 확인합니다
	06 독자 검증가	용어 설명과 이해도를 점검합니다
	07 서식 검증가	표기 규칙과 부호 통일을 검사합니다
외부 리뷰 (출판 직전)	08 📖 편집자	구성·서사·톤·완성도를 평가합니다
외부 리뷰 (출판 직전)	09 🔍 프루프리더	맞춤법·비문·부호 오류를 교정합니다

추가 멤버

퍼블리셔(/publish): 최종 원고를 Word 문서로 변환하고, 메타데이터·검증 리포트까지 자동 생성합니다.
마케터(외부 자문): 제목 임팩트·타겟 명확성·시의성에 한해 의견을 줍니다. 본문에는 반영하지 않으니 9명 합평단과는 분리해서 봅니다.

팀장 (사람 = 나)

어떤 책을 쓸지 기획서(user-book-toc.md)를 작성합니다.
각 단계를 슬래시 커맨드로 호출합니다.
최종 결과물을 직접 열어 보고 판단합니다. 마지막 결정은 사람의 몫입니다.

참고

이 9명은 "책 쓰기"에 특화된 팀입니다. 나중에 블로그나 사내 보고서 같은 다른 결과물에 이 방식을 응용하고 싶다면, 이 구성을 참고해 검증 단계를 줄이거나 도메인 전문가를 한 명 더 넣는 식으로 바꿀 수 있습니다. 핵심은 "그 결과물에 필요한 시각"을 빠짐없이 채우는 것입니다.

3단계. 작업 흐름

3명의 팀이 4단계로 움직입니다

팀이 정해졌으니, 이번에는 그 팀이 언제 어떤 순서로 일하는지를 봅니다. AI에게 "알아서 잘 해줘"라고 던지면 매번 결과가 달라집니다. 그래서 이 스킬은 "리서치 먼저, 집필 다음, 리뷰는 그 다음, 출판은 마지막"이라고 순서를 못 박아 두었습니다. 같은 입력에 거의 같은 품질이 나오는 이유가 바로 이 고정된 순서, 곧 하네스에 있습니다.

전체는 4단계입니다. 슬래시 커맨드 한 줄이 곧 한 단계입니다.

1

/research · 자료 수집 (10~20분)

웹에서 최신 자료를 수집하고, 출처를 Tier 1·2·3으로 등급 매겨 정리합니다. Tier 1은 공식 문서·정부 발표, Tier 2는 검증된 언론·학술, Tier 3은 블로그·SNS입니다. 본문 인용은 Tier 1을 최우선으로 합니다.

2

/write · 구조 설계 + 초안 (30~60분)

먼저 세부 목차(02_outline.md)를 짜고, 그 다음 Part 단위로 끊어서 초안을 작성합니다. 첫 호출 때 청크 단위 1회 질의로 한 번에 많이 받아 와야 흐름이 자연스럽게 이어집니다.

3

/review · 9명이 9단계로 검수 (40~90분)

내부 6단계(비평 → 수정 → 독자 → 수정 → 5인 합평 1라운드 → 반영) → 합평 2라운드 → 외부 3단계(편집자 → 프루프리더 → 최종 수정)를 차례대로 통과합니다. 한 단계에서 막히면 거기서 멈추고 수정한 뒤 같은 단계를 다시합니다.

4

/publish · 자동 검증 + Word 변환 (10~15분)

최종 원고에 verify.py를 돌려 자동 검사(분량·페르소나 일관성·금지 부호 등)를 통과시킨 뒤, .docx로 변환하고 메타데이터·마케팅 카피·검증 리포트까지 함께 생성합니다.

핵심 포인트 · 통과해야 다음으로 간다

3단계 안에는 "통과 못 하면 수정 후 재도전"하는 루프가 있습니다. 합평 1라운드에서 5명 중 한 명이라도 빨간불을 켜면, 본문을 고친 뒤 합평 2라운드로 다시 갑니다. 이 루프가 하네스의 가드레일입니다. AI가 한 번에 안 되면 사람이 봐야 한다는 뜻이 아니라, "AI가 같은 단계를 다시 하면서 스스로 고친다"는 뜻입니다. 마지막에는 원고를 10점 만점으로 자가 채점하고, 9점에 못 미치면 출판을 보류하도록 설계되어 있습니다. 리더 입장에서는 "일정 품질 아래로는 내보내지 않는다"는 기준선이 파일에 박혀 있는 셈입니다.

잠깐 · 표지는 왜 빠졌나?

표지는 이 하네스에서 다루지 않습니다. 표지는 디자이너가 책 내용을 본 뒤에 만드는 별개 작업이라, 본문 워크플로우와 분리되어 있습니다. 표지가 필요하면 외부 도구(예: Adobe Express 템플릿)나 디자이너에게 따로 맡기면 됩니다. "이 하네스의 책임 범위는 본문 원고와 Word 파일까지"라고 못 박아 두면 단계가 깔끔해집니다.

4단계. 파일 구조

팀도 순서도, 이미 파일로 저장돼 있습니다

2단계에서 "누가", 3단계에서 "어떤 순서로" 일하는지 봤습니다. 그 팀 구성과 순서는 여러분이 만드는 것이 아니라, 이미 파일로 저장돼 레포에 들어 있습니다. AI 에이전트는 사람과 달리 "구두로 알려준 규칙"을 기억하지 못합니다. 대신 매번 같은 파일을 읽고 시작합니다. 그래서 규칙·역할·기획이 전부 파일에 박혀 있는 것, 이것이 곧 하네스입니다.

전체 폴더는 아래 GitHub 레포와 똑같습니다. 핵심은 규칙서(SKILL.md), 기획서, 매뉴얼 4개입니다.

book_publishing/ ├── SKILL.md # 편집장: 전체 규칙과 품질 기준 ├── book/ │ └── ⭐ user-book-toc.md # 기획서: 이 파일만 교체하면 다른 책 제작 가능 ├── references/ # 팀원들의 업무 매뉴얼 (4개) │ ├── research.md # 리서처 │ ├── write.md # 저자 │ ├── review.md # 합평단 9명 │ └── publish.md # 퍼블리셔 ├── scripts/ │ └── verify.py # 자동 품질 검증 └── output/ # 최종 결과물 (.docx 등)

* /research부터 실행하면 중간 산출물이 쌓이는 draft/ 폴더가 자동으로 생기고, output/에 최종 파일이 채워집니다.

파일	역할	수정 가능 여부
SKILL.md	범용 규칙·품질 기준·작업 흐름을 정의합니다	수정 불가 (고정)
*references/.md**	4명 에이전트(리서처·저자·합평단·퍼블리셔)의 업무 절차	수정 불가 (고정)
scripts/verify.py	분량·페르소나·금지 부호를 자동 검사하는 스크립트	수정 불가 (고정)
book/user-book-toc.md	이번에 쓸 책의 제목·페르소나·목차·문체·퍼블리싱 사양	수정 가능 (교체)
draft/	리서치 노트·초안·리뷰 결과 등 중간 산출물	자동 생성
output/	최종 `.docx`·메타데이터·검증 리포트	자동 생성

왜 "수정 불가"와 "수정 가능"을 나누는가?

시험을 떠올려 보세요. 시험 규칙과 채점 기준은 고정이고, 답안지만 사람마다 다릅니다. 만약 시험을 보는 사람이 채점 기준까지 바꿀 수 있다면 그 시험은 의미가 없습니다. 여기서도 똑같습니다. SKILL.md와 매뉴얼 4개는 채점 기준이라 그대로 두고, user-book-toc.md가 답안지라 매번 새로 씁니다. 그래서 같은 하네스로 다른 책을 찍어낼 수 있는 것입니다.

기획서(`user-book-toc.md`)에는 정확히 6가지를 적습니다

조립식 가구 설명서를 떠올려 보세요. 부품이 6개 있는데 하나라도 빠지면 가구가 흔들립니다. 기획서도 같습니다. 6칸을 빠짐없이 채워야 AI가 책 한 권을 완성할 수 있습니다.

01

기본 정보

제목·부제·필명·대상 독자·판형·목표 분량·기준 연도·환율 표기 규칙 등 책의 메타데이터.

없으면? 분량과 목표가 모호해져 AI가 멋대로 결정합니다.

02

페르소나

책의 화자(캐릭터·말투·일관성 원칙). 프롤로그부터 부록까지 한 목소리를 유지하기 위한 설정.

없으면? 장마다 화자가 바뀌어 책이 누더기가 됩니다.

03

활용법 세부 가이드

챕터별 상세 작성 규칙 + 공통 6요소(도입·개념·워크플로우·프롬프트·팁·정리).

없으면? 장마다 구성이 달라지고 독자가 혼란스러워합니다.

05

작성 스타일

문체·어미·금지 부호·불릿 기호·영어 최소화 등. verify.py가 자동 검사하는 기준이 됩니다.

없으면? 어디는 해라체, 어디는 합니다체로 섞여 출판 불가.

06

퍼블리싱 사양

Word 서식(폰트·색·여백·표·이미지·정리 박스) + 이미지 생성 규칙(matplotlib 기준 등).

없으면? .docx로 변환 후 손으로 다 다시 손봐야 합니다.

핵심 · "교체 가능한 기획서"라는 발상

이 6칸이 잘 짜여 있으면, 새로운 책을 쓸 때 user-book-toc.md 한 파일만 갈아끼우면 끝입니다. AI 모델을 바꾸는 게 아니라, AI가 일하는 환경을 통째로 재사용하는 것입니다. 이게 하네스 엔지니어링의 핵심입니다.

5단계. 실행

스킬을 내려받아 AI 에이전트 팀을 돌립니다

4-A. 프로젝트 가져오기

먼저 GitHub에서 프로젝트를 가져옵니다. 터미널에서 아래 명령어를 입력합니다.

git clone https://github.com/airoasting/book_publishing.git cd book_publishing

4-B. 기획서(user-book-toc.md) 작성하기

Claude Code를 열고, 아래 프롬프트를 입력합니다. 이 파일 하나가 "이번에 쓸 책"을 결정합니다. 4단계에서 본 6칸을 빠짐없이 채우는 것이 핵심입니다.

user-book-toc.md 파일을 새로 작성해줘. 주제: [여기에 책 주제 입력] 대상 독자: [여기에 대상 독자 입력] 분량: 12~15만자 기준 연도: 2026 기존 user-book-toc.md의 6개 섹션(기본 정보·페르소나·목차·활용법 가이드·작성 스타일·퍼블리싱 사양) 형식을 그대로 유지하되, 위 주제에 맞게 제목·페르소나·목차·스타일을 새로 만들어줘.

4-C. 슬래시 커맨드를 순서대로 실행하기

기획서가 완성되면, 아래 커맨드를 순서대로 하나씩 실행합니다. 한 번에 다 누르지 말고, 단계마다 산출물을 열어서 눈으로 확인한 뒤 다음으로 갑니다.

순서	커맨드	하는 일	예상 소요 시간
1	`/research`	웹에서 자료를 수집하고 Tier 1·2·3으로 분류해 정리합니다	10~20분
2	`/write`	세부 목차를 설계한 뒤, Part 단위 청크로 초안을 작성합니다	30~60분
3	`/review`	합평단 9명이 내부 6단계 → 합평 2라운드 → 외부 3단계로 검수합니다	40~90분
4	`/publish`	verify.py로 자동 검증 후 .docx와 메타데이터를 생성합니다	10~15분

중간에 멈춰도 괜찮습니다

각 스킬은 draft/ 폴더의 파일 존재 여부를 자동으로 감지합니다. /write 도중 중단해도, 다시 /write를 실행하면 마지막 산출물부터 이어서 작업합니다. 게임의 자동 저장과 같은 원리입니다.

4-D. 4번의 커맨드 → 12개 산출물

위 4개 커맨드를 누르면 draft/ 폴더에 총 12개의 산출물 파일이 자동으로 만들어집니다. 마치 공장 컨베이어 벨트처럼, 한 산출물이 다음 산출물의 입력이 됩니다. 누가 만드는지를 색깔로 표시했습니다.

사람이 쓰는 시간

~3시간

AI 에이전트가 쓰는 시간

~5시간

총 소요

~8시간

기획서 작성 · 사람이 약 1시간

00 기획서 한 파일 채우기 user-book-toc.md 사람

1회전 · 초안 만들기 · 약 25분

01 리서치 01_research-notes.md 그린 · 리서처

02 구조 설계 (세부 목차) 02_outline.md 실버 · 설계자

03 초안 작성 03_draft-v1.md 블랙 · 저자

2회전 · 비평 + 독자 검토 · 약 150분

04 비평 리뷰 04_review-red.md 레드 · 비평가

05 1차 수정 05_draft-v2.md 블랙 · 저자

06 독자 리뷰 06_review-pink.md 핑크 · 독자

07 2차 수정 07_draft-v3.md 블랙 · 저자

3회전 · 합평 2라운드 · 약 125분

08 1차 합평 08_ensemble-review-1.md 5인 합평단

09 합평 1R 반영 09_draft-v4.md 블랙 · 저자

10 2차 합평 10_ensemble-review-2.md 5인 합평단

11 최종 반영 11_draft-final.md 블랙 · 저자

퍼블리싱 · 약 5분

12 Word 변환 + 검증 리포트 final.docx 라이트 · 퍼블리셔

강의 포인트 · 왜 블랙이 자꾸 등장하나?

위 12행을 보면 블랙(저자)이 4번(03 → 05 → 07 → 09 → 11) 등장합니다. 의도된 설계입니다. "본문을 고치는 사람은 끝까지 한 명"이어야 문체와 흐름이 흔들리지 않습니다. 다른 색깔(레드·핑크·5인 합평·라이트)은 지적만 하고 본문은 손대지 않습니다. 사람으로 치면 "감수는 여러 명이 하지만, 펜은 한 명이 잡는" 구조입니다.

6단계. 검증

"AI가 만든 거니까 알아서 잘 됐겠지"는 금물입니다. 결과물은 직접 눈으로 확인합니다

모든 커맨드 실행이 끝나면 output/ 폴더에 최종 .docx·메타데이터·검증 리포트(verify-report.md)가 생성됩니다. verify.py가 자동으로 잡아 주는 항목도 있지만, 마지막 결정은 사람의 몫입니다. 아래 6가지를 직접 확인합니다.

✅

목차 일치

user-book-toc.md의 목차와 실제 원고 구조가 일치하는가

✅

분량 충족

목표 분량(예: 12~15만 자)을 달성했는가

✅

페르소나 일관성

처음부터 끝까지 동일한 캐릭터와 말투를 유지하는가

✅

내부 참조 정확성

"3장에서 다룬 내용" 같은 참조가 실제와 일치하는가

✅

정보 일관성

동일 기능에 대한 설명이 장마다 모순되지 않는가

✅

마크다운 기호 제거

최종 Word 문서에 #, **, —, – 같은 기호가 남아있지 않은가

결과물에 문제가 있을 때 다시 던지는 프롬프트

draft/11_draft-final.md를 읽고, 아래 항목을 기준으로 최종 점검해줘: 1. user-book-toc.md의 목차와 실제 구조가 일치하는가 2. 페르소나와 문체가 처음부터 끝까지 일관되는가 3. 장 간 내부 참조("2장에서 다룬~")가 정확한가 4. 사실 관계와 통계 인용에 오류가 없는가 문제가 있으면 11_draft-final.md를 수정해줘.

다음 책으로 넘어가는 법

SKILL.md와 매뉴얼 4개는 그대로 두고, user-book-toc.md 한 파일만 새 기획서로 교체합니다. 그다음 /research부터 다시 누르면 끝입니다. 이 페이지가 결국 말하고 싶은 것은 한 가지입니다. AI 모델을 바꾸는 것이 아니라, 잘 만들어진 작업 환경을 한 번 내려받아 계속 재사용하는 것입니다.