# Claude로 책 기획, 39개 원고 구조까지 완성했다
## 📝 한줄 요약
Claude와 대화하며 만든 시니어 AI 입문서의 목차 초안을 실제 집필 프로젝트로 확장했습니다. 기존 4부 12꼭지, 14개 원고 파일을 7부 37꼭지, 총 39개 파일로 재구성하고 목차·원고 제목·파일명·집필 일정·출간기획서까지 하나의 기준으로 맞췄습니다.
**바쁘시면 이것만 읽어도 돼요:**
- **사용한 도구:** 초기 기획에는 Claude, 문서와 파일 구조 정리에는 VS Code의 GitHub Copilot
- **핵심 변화:** 4부 12꼭지에서 7부 37꼭지로 확장하고 서문·맺음말을 포함한 39개 원고 파일 생성
- **가장 중요한 원칙:** 목차를 기준 문서로 정하고 원고 제목, 파일명, 체크리스트, 출간기획서를 모두 동일하게 관리
- **인상적이었던 점:** 여러 문서를 하나씩 고치는 데서 끝나지 않고 파일 생성과 제목 검증까지 한 흐름으로 처리
- **시행착오:** 원문과 정확히 일치하지 않는 문장을 한꺼번에 바꾸려다 실패했고, 실제 파일을 다시 읽은 뒤 수정해 해결
- **배운 교훈:** AI에게 완성본을 한 번에 맡기기보다 기획, 구조화, 정합성 검사 순서로 나누면 결과가 훨씬 안정적
## 🎯 이런 분들께 도움돼요
- AI와 함께 전자책이나 강의안을 기획했지만 실제 집필 단계로 넘어가지 못한 분
- 목차, 원고 파일, 일정표의 제목이 제각각이라 관리가 어려운 분
- 개발 지식 없이 VS Code와 AI 코딩 도구로 여러 문서를 체계적으로 정리하고 싶은 분
- 처음 만든 AI 결과물을 반복해서 다듬는 방법이 궁금한 분
## 😫 문제 상황 (Before)
처음에는 “시니어가 AI를 두려워하지 않고 쉽고 재미있게 시작할 수 있는 책을 쓰고 싶다”는 생각에서 출발했습니다. 혼자 목차를 만들면 익숙한 주제만 반복하거나 설명이 너무 어려워질 것 같아 Claude를 기획 파트너로 삼았습니다.
첨부한 이전 사례글에서는 아이디어 요청, 보완점 검토, 우려사항 점검, 부록 제안, 소주제 세분화 순서로 대화를 나누며 7개 Part의 뼈대를 만들었습니다.
하지만 목차 초안이 있다고 바로 책을 쓸 수 있는 것은 아니었습니다. 실제 프로젝트 폴더에는 예전 기준인 4부 12꼭지와 서문·맺음말, 총 14개 원고 파일이 남아 있었습니다. 새 목차는 37개 꼭지인데 원고 파일과 집필 일정, 출간기획서는 여전히 이전 구조를 가리키고 있었습니다.
문서마다 제목을 따로 수정하면 다음과 같은 문제가 생길 수 있었습니다.
- 목차의 제목과 원고 파일명이 달라 원하는 파일을 찾기 어려움
- 원고 첫 제목과 집필 체크리스트의 표현이 달라 진행 상황을 헷갈림
- 출간기획서에는 7부라고 쓰고 실제 원고 폴더에는 12개 파일만 남는 불일치
- 제목을 다듬을 때마다 여러 문서를 다시 찾아 고쳐야 하는 반복 작업
이번에는 단순히 목차를 고치는 것이 아니라, **책의 기획을 실제로 집필할 수 있는 작업 구조로 바꾸는 것**이 목표였습니다.
## 🛠️ 사용한 도구
- **Claude:** 시니어 독자를 위한 주제 발굴, 시장 관점 검토, 목차 초안 구성
- **GitHub Copilot:** VS Code에서 Markdown 문서 수정, 원고 파일 재구성, 제목 통일, 항목 수 검증
- **Markdown:** 목차, 출간기획서, 집필 일정, 원고를 관리하는 공통 문서 형식
- **모델:** 작업 당시 세부 모델명은 별도로 기록하지 않음
- **참고 글:** [Claude와 함께 "시니어를 위한 AI 입문서" 기획하기](https://www.gpters.org/ai-writing/post/planning-introduction-ai-seniors-p1tKiHzZjdUFLMl)
## 🔧 작업 과정
### 1. 아이디어를 실제 목차 문서로 옮기기
이전 사례에서 Claude와 만든 목차는 좋은 출발점이었지만, 프로젝트 안의 문서와 원고는 예전 구조 그대로였습니다. 그래서 먼저 기존 목차의 Markdown 형식을 유지하면서 새 내용을 반영해 달라고 요청했습니다.
```
기획 폴더 안의 ‘목차.md’에 있는 내용을 형식은 그대로 유지하고 위의 내용으로 바꾸어줘. 그리고 원고 폴더에 있는 제목들도 위의 내용으로 바꾸어줘.
```
이 요청으로 책의 기준 제목은 **『가장 쉬운 시니어를 위한 AI 활용법』**으로 정리됐습니다. 목차는 AI의 개념부터 스마트폰 실습, 일상 활용, 인생 2막, 안전, 부록까지 이어지는 7부 구조가 되었습니다.
여기서 중요한 변화는 “좋은 아이디어 목록”이 “번호가 붙은 집필 목록”으로 바뀌었다는 점입니다. 무엇을 쓸지 고민하는 단계에서 어떤 순서로 쓸지 관리하는 단계로 넘어간 것입니다.
### 2. 기존 12개 원고를 37개 원고 구조로 재편하기
다음 문제는 원고 폴더였습니다. 기존 01번부터 12번까지의 파일은 새 목차와 맞지 않았습니다. 서문과 맺음말은 남기고 본문 파일만 새 구조로 다시 만들도록 요청했습니다.
```
원고 폴더의 내용을 ‘서문.md’과 ‘맺음말.md’를 남기고 형식을 위의 내용으로 바꾸어줘. 현재 01~12까지를 삭제하고 새로이 위에 있는 01~37까지로 만들어줘.
```
GitHub Copilot은 기존 본문 구조를 새 목차에 맞춰 다시 구성했습니다. 그 결과 원고 폴더에는 다음과 같이 총 39개 Markdown 파일이 자리 잡았습니다.
- 00번 서문 1개
- 01~37번 본문과 부록 원고 37개
- 99번 맺음말 1개
파일 수만 늘린 것이 아니라 각 파일의 첫 제목도 목차 제목과 맞췄습니다. 원고를 쓰기 시작할 때 빈 문서를 새로 만들거나 제목을 다시 입력할 필요가 없어졌습니다.
### 3. 제목을 한 번 정하고 모든 곳에서 같게 쓰기
문서가 많아지자 작은 표기 차이가 눈에 들어왔습니다. 같은 AI를 어떤 파일에서는 대문자로, 다른 파일에서는 소문자로 쓰거나 띄어쓰기와 문장부호가 조금씩 달랐습니다.
그래서 목차 제목, 원고 내부 제목, 파일명을 완전히 동일한 스타일로 맞추고 표현도 자연스럽게 다듬었습니다. 이 과정에서 세운 기준은 간단했습니다.
> 목차를 제목의 원본으로 삼고, 나머지 문서는 그 제목을 따라간다.
이 기준 하나가 생기자 이후 검증도 쉬워졌습니다. 사람의 눈으로 37개를 일일이 비교하는 대신 번호와 제목을 추출해 항목 수와 일치 여부를 확인할 수 있었습니다.
### 4. 집필 일정표를 39개 체크리스트로 확장하기
원고 파일은 39개인데 집필 일정표가 14개 기준이라면 실제 진행 상황을 관리할 수 없습니다. 서문부터 맺음말까지 모두 표시되도록 체크리스트를 확장했습니다.
```
집필 일정의 꼭지별 진행 체크리스트를 서문과 맺음말을 포함한 총 39개로 바꾸어줘.
```
이제 한 꼭지를 완성할 때마다 해당 항목에 표시할 수 있습니다. 목차는 독자에게 보여주는 순서이고, 체크리스트는 집필자가 움직이는 순서가 되었습니다. 두 문서가 같은 번호와 제목을 사용하니 다음에 무엇을 써야 할지도 바로 알 수 있습니다.
### 5. 출간기획서를 마지막 기준까지 동기화하기
목차와 원고를 정리한 뒤에도 출간기획서에는 이전 가제와 4부 12꼭지 정보가 남아 있었습니다. 마지막으로 제목 후보와 전체 목차를 현재 구조에 맞게 업데이트했습니다.
```
출간 기획서의 제목 가제 및 전체 목차 내용도 업데이트 해줘.
```
출간기획서에는 다음 내용이 반영됐습니다.
- 가제 1: 『가장 쉬운 시니어를 위한 AI 활용법』
- 가제 2: 『시니어도 쉽게 시작하는 AI 활용법』
- 가제 3: 『스마트폰으로 시작하는 AI 생활』
- 전체 구성: 7부 37꼭지와 서문·맺음말
- 전체 파일 수: 39개
- Part 6 안전 영역: 사기 예방, 개인정보 보호, 딥페이크 대응
처음에는 여러 문장을 한꺼번에 바꾸려 했지만 검색할 문구가 실제 원문과 정확히 일치하지 않아 수정이 실패했습니다. AI가 파일을 다시 읽고 현재 내용을 기준으로 교체한 뒤에는 정상적으로 반영됐습니다.
이 경험을 통해 “AI가 실패했다”는 결과만 보고 같은 요청을 반복하기보다, **AI가 어떤 원문을 기준으로 작업했는지 다시 확인하게 하는 것**이 더 빠른 해결책이라는 점을 배웠습니다.
마지막에는 목차와 출간기획서에서 Part 제목과 번호가 붙은 꼭지를 각각 추출해 비교했습니다. 검증 결과 Part 제목은 7개 모두, 꼭지 제목은 37개 모두 정확히 일치했습니다.
## ✅ 결과 (After)
### Before vs After
| 항목 | Before | After |
|------|--------|-------|
| 책 제목 | 시니어를 위한 AI 활용법 | 가장 쉬운 시니어를 위한 AI 활용법 |
| 전체 구성 | 4부 12꼭지 | 7부 37꼭지 |
| 원고 파일 | 서문·맺음말 포함 14개 | 서문·맺음말 포함 39개 |
| 집필 체크리스트 | 14개 기준 | 39개 항목 |
| 출간기획서 목차 | 이전 4부 요약 | 7부 37꼭지 전체 수록 |
| 제목 관리 | 문서마다 개별 표기 | 목차를 기준으로 통일 |
| 검증 방식 | 눈으로 확인 | Part 7개, 꼭지 37개 자동 비교 |
### 결과물
- `00-기획/목차.md`: 7부 37꼭지의 기준 목차
- `00-기획/출간기획서.md`: 새 가제와 전체 목차, 집필 원칙
- `00-기획/집필-일정.md`: 서문부터 맺음말까지 39개 체크리스트
- `01-원고/`: 번호와 제목이 정리된 39개 원고 파일
가장 큰 성과는 문서 개수가 늘어난 것이 아닙니다. 막연했던 책 아이디어가 “오늘 어느 파일을 열어 무엇을 쓰면 되는지” 알 수 있는 집필 시스템으로 바뀌었다는 점입니다.
## 💬 이 과정에서 배운 AI 활용 팁
### 효과적이었던 것
1. **기준 문서를 먼저 정하기**
목차를 제목의 원본으로 정하니 파일명, 원고 제목, 체크리스트를 어디에 맞춰야 하는지 명확해졌습니다.
2. **큰 작업을 단계로 나누기**
목차 수정, 파일 재구성, 제목 통일, 일정표 확장, 기획서 동기화 순서로 진행하니 각 단계의 결과를 확인하면서 다음 작업으로 넘어갈 수 있었습니다.
3. **숫자로 완료 여부 확인하기**
“대략 다 된 것 같다”가 아니라 Part 7개, 꼭지 37개, 원고 39개, 체크리스트 39개처럼 확인 기준을 숫자로 정했습니다.
4. **실패하면 원문부터 다시 읽히기**
문서 수정이 실패했을 때 같은 명령을 반복하지 않고 현재 파일 내용을 다시 확인한 뒤 교체하도록 요청하는 편이 효과적이었습니다.
5. **AI의 역할을 단계에 맞게 바꾸기**
Claude는 아이디어를 넓히고 검토하는 기획 파트너로, GitHub Copilot은 여러 파일을 실제로 정리하고 검사하는 실행 파트너로 활용했습니다.
### 이렇게 하면 안 돼요
1. **처음부터 완성된 책 전체를 한 번에 요청하지 않기**
범위가 너무 크면 제목과 파일 구조가 어긋나도 발견하기 어렵습니다.
2. **문서마다 제목을 따로 수정하지 않기**
기준 없이 개별 수정하면 비슷하지만 다른 제목이 계속 생깁니다.
3. **AI의 성공 메시지만 믿고 끝내지 않기**
파일 수와 제목 일치 여부처럼 사람이 이해할 수 있는 기준으로 마지막 검증을 요청해야 합니다.
4. **오류가 났을 때 무작정 재시도하지 않기**
무엇을 찾지 못했는지, 실제 파일에는 어떤 문장이 있는지 먼저 확인하면 원인을 더 빨리 찾을 수 있습니다.
## 🌍 다른 업무에 적용한다면?
이 방식은 전자책뿐 아니라 여러 문서가 같은 기준을 공유하는 작업에 적용할 수 있습니다.
- 강의 커리큘럼과 차시별 강의안 파일 만들기
- 유튜브 시리즈 기획표와 회차별 대본 관리하기
- 블로그 연재 목차와 게시글 초안 파일 구성하기
- 업무 매뉴얼의 목차, 세부 문서, 점검표 통일하기
- 연구 보고서의 장별 파일과 진행 일정 관리하기
핵심은 하나입니다. **사람이 기준을 정하고 AI에게 그 기준을 여러 문서에 일관되게 적용하도록 맡기는 것**입니다.
## 🚀 앞으로의 계획
문서 구조는 완성됐지만 책 자체는 이제부터 시작입니다. 다음 단계는 다음과 같습니다.
- Part 4·5·6처럼 실생활 활용도가 높은 꼭지부터 샘플 원고 작성
- 딥페이크와 보이스피싱 대응 등 안전 관련 내용의 최신 출처 조사
- 각 꼭지에 들어갈 스마트폰 화면과 단계별 안내 이미지 제작
- 시니어 독자에게 샘플 원고를 보여주고 어려운 표현과 글자 크기 점검
- 전체 원고 완성 후 PDF와 EPUB으로 변환
특히 첫 샘플 원고는 독자의 관심이 높고 정보의 정확성이 중요한 “AI 음성 사기와 딥페이크 대응하기”를 우선 검토할 계획입니다.
## 📋 재사용 가능한 프롬프트
### 프롬프트 1: 목차를 실제 원고 파일 구조로 바꾸기
> 아래 목차를 기준으로 집필 프로젝트를 정리해줘.
> 기존 문서의 형식은 유지하고, 서문과 맺음말은 보존해줘.
> 각 꼭지마다 번호가 붙은 Markdown 원고 파일을 만들고, 파일명과 문서의 첫 제목을 목차 제목과 동일하게 맞춰줘.
> 작업 후 Part 수, 꼭지 수, 전체 파일 수를 확인해서 알려줘.
>
> [여기에 목차 붙여넣기]
### 프롬프트 2: 여러 문서의 제목 정합성 검사하기
> [기준 목차 파일]을 제목의 기준으로 삼아 [원고 폴더], [집필 일정 파일], [출간기획서 파일]을 비교해줘.
> 번호, 띄어쓰기, 영문 대소문자, 문장부호까지 확인하고 차이가 있으면 기준 목차에 맞게 수정해줘.
> 수정 후 전체 항목 수와 불일치 항목이 남아 있는지 검증 결과를 표로 알려줘.
### 프롬프트 3: 수정 실패 원인 확인하기
> 같은 수정을 반복하지 말고 먼저 대상 파일의 현재 내용을 읽어줘.
> 이전 수정이 실패한 이유가 검색 문구 불일치인지, 파일 경로 문제인지, 인코딩 문제인지 구분해 설명해줘.
> 확인된 원인에 맞는 최소한의 수정만 적용하고 결과를 다시 검증해줘.
## 🖼️ 추천 이미지
- **문제 상황(Before) 섹션:** 기존 4부 12꼭지 목차와 14개 원고 파일이 보이는 화면
- **작업 과정 섹션:** VS Code에서 AI와 목차 및 파일 구조를 수정하는 대화 화면
- **결과(After) 섹션:** 01~37번과 서문·맺음말이 정렬된 원고 폴더 화면
- **결과(After) 섹션:** 목차와 출간기획서의 37개 제목이 일치한다는 검증 결과 화면
이 글은 초기 기획 과정을 정리한 [Claude와 함께 "시니어를 위한 AI 입문서" 기획하기](https://www.gpters.org/ai-writing/post/planning-introduction-ai-seniors-p1tKiHzZjdUFLMl)의 후속 작업을 바탕으로 작성했습니다.
