시니어 AI 활용서 원고, 초안작성에서 목차 재검토까지(2주차 사례글 2차)

AI 활용서 작성법: 초안부터 목차 재검토까지

## 📝 한줄 요약

시니어 대상 "AI 입문 활용서" 원고 14편(서문~맺음말)을 하루 동안 GitHub Copilot으로 처음부터 집필하고, 같은 검토 지시문을 Codex와 Claude Code에게도 똑같이 내려 세 도구가 원고를 어떻게 다르게 고치는지 비교해 봤다. 이어서 며칠 뒤, 처음에 검토했던 7부 37꼭지짜리 목차 초안과 지금 잠정 확정한 4부 10장 목차를 Claude Code에게 나란히 비교시켜, 무엇을 지금 반영하고 무엇을 다음 기회로 미룰지 정리했다.

바쁘시면 이것만 읽어도 돼요:

- GitHub Copilot(GPT-5.6 Sol)으로 자료 정리부터 12개 장 + 서문 + 맺음말까지 원고 초안을 전부 작성

- 같은 원고, 같은 "구성·문체·맞춤법을 검토하고 승인하면 고쳐 달라"는 지시문을 Codex(GPT-5)와 Claude Code(Claude)에도 그대로 던져 3파전 교차 검증

- Copilot은 안전·법률 리스크까지 파고드는 "깐깐한 감수자", Codex는 제목·목차·본문을 통째로 뜯어고치는 "적극적인 편집장", Claude Code는 최소한만 건드리는 "보수적인 교열자"로 성격이 확연히 갈림

- 며칠 뒤에는 Claude Code에게 옵시디언에 흩어져 있던 두 개의 목차 파일(잠정 확정안 vs 처음 검토했던 초안)을 직접 찾아 읽고 비교하게 함 — 볼트 이름만으로는 실제 파일 경로를 못 찾자, 옵시디언 설정 파일(`obsidian.json`)까지 뒤져 정확한 경로를 스스로 찾아냄

- 초안에만 있고 확정안에는 빠진 내용(금융·연금, 보험, AI가 틀린 답을 할 수 있다는 경고, 부록 자료 등)을 3가지 반영 방식으로 정리해 제안받았지만, "이번 출간은 지금 확정안대로 진행하고, 증보판 낼 때 반영하겠다"고 결정 — 대신 그 내용을 나중에 다시 꺼내 쓸 수 있게 기록만 해 두기로 함

- 배운 점: AI에게 "알아서 고쳐 줘"라고 맡기기보다, 권장안 중 필요한 항목만 골라 "이것만 진행해 줘"라고 범위를 지정하는 것이 훨씬 안전했고, "지금 할 일"과 "나중에 할 일"을 구분해서 AI에게 맡기면 지금 당장의 목표(출간)에 흔들림 없이 집중할 수 있었다

## 🎯 이런 분들께 도움돼요

- 전자책이나 강의 자료처럼 긴 원고를 AI로 쓰거나 다듬고 있는 1인 저자

- 여러 AI 코딩 도구(Copilot, Codex, Claude Code 등)를 써보긴 했지만 "어떤 게 더 낫다"고 확신이 안 서는 분

- 비개발 분야(글쓰기, 콘텐츠 기획)에 AI 코딩 도구를 활용해 보고 싶은 분

- 목차나 기획안을 여러 버전으로 검토하다가 "이번엔 뭘 살리고 뭘 다음으로 미뤄야 하나" 고민 중인 분

- AI에게 "검토해서 고쳐 달라"고 맡길 때 어디까지 믿고 어디서부터 직접 판단해야 하는지 감을 잡고 싶은 분

## 😫 문제 상황 (Before)

50대 중반~70대 독자를 위한 "AI 입문 활용서" 전자책을 기획하고 있었다. 목차와 독자 페르소나, 출간기획서는 이미 만들어 둔 상태였지만, 실제로 12개 장 분량의 원고를 혼자 다 쓰려니 막막했다. 참고 자료(강의 원고, 통계, 정부 기관 안내문 등)는 쌓여 있는데 이걸 어떻게 정리해서 AI에게 넘겨야 할지도 감이 안 잡혔다.

그래서 첫 시작은 아주 소박한 질문이었다.

```

원고를 작성하게 전에 내가 가지고 있는 자료를 참고할 수 있게 하려고해. 어떻게 하면 되?

```

여기서부터 하루 사이에 서문부터 맺음말까지 14개 파일, 총 17만 자가 넘는 원고 초안이 완성됐다. 그런데 혼자 쓴 원고를 혼자 검토하려니 "내가 놓친 게 있지 않을까"라는 불안이 남았다. 그래서 같은 원고를 세 가지 AI 도구에 각각 올려 두고, 거의 똑같은 검토 지시문을 내려 서로 다른 시각으로 교차 검증을 받아 보기로 했다.

원고와 목차는 그렇게 한 번 정리됐지만, 사실 이 목차는 처음부터 지금 모습이 아니었다. 초반에는 7부 37꼭지짜리 훨씬 큰 초안을 검토했었고, 이후 "시니어 독자가 부담 없이 끝까지 읽을 수 있는 분량"을 목표로 4부 10장짜리 잠정 확정안으로 크게 줄인 상태였다. 문제는 그 과정에서 초안에만 있던 좋은 소재들(금융·연금, AI 오답 대응법, 각종 체크리스트 등)이 통째로 사라졌다는 점이었다. "이걸 다시 살릴 수 없을까?"라는 질문에서 두 번째 라운드가 시작됐다.

## 🛠️ 사용한 도구

- GitHub Copilot Chat (모델: GPT-5.6 Sol, 에이전트 모드) — 원고 최초 집필 및 1차 자체 검수

- Codex (모델: GPT-5, VS Code 확장) — 구조·제목 검토 및 대대적 재편집

- Claude Code (모델: Claude Sonnet 5, VS Code 확장) — 구조·제목 검토, 최소 수정 및 맞춤법 교정 / 이후 목차 비교·재검토 세션 진행

- 특이사항: 같은 원고를 C 드라이브(`C:\dev\ebook-real`)와 D 드라이브(`D:\ebook-real'`) 두 경로에 두고 도구별로 다른 경로에서 작업. 목차 재검토 시점에는 옵시디언 볼트 두 개(`D:\ebook-real'`, C:\dev\ebook(확장))를 오가며 비교

---

## 🔧 작업 과정

자료 정리부터 - "이 폴더에 뭘 어떻게 넣어야 AI가 알아서 참고하나요?"

맨 처음 막힌 지점은 기술이 아니라 정리였다. 참고 자료를 어떤 폴더 구조로 넣어야 나중에 AI가 잘 찾아 쓸 수 있을지 몰랐다.

```

원고를 작성하게 전에 내가 가지고 있는 자료를 참고할 수 있게 하려고해. 어떻게 하면 되?

```

Copilot은 03-참고자료/리서치 아래에 주제별 폴더(AI-기초, 스마트폰-활용, 건강, 여행, 보이스피싱, 개인정보보호 등)를 나누고, 자료마다 "연결할 장", "꼭 반영할 내용" 같은 메모를 남기는 방식을 제안했다. 저작권이 있는 책은 통째로 베끼지 말고 요약 후 출처를 표시하라는 실무적인 조언도 함께였다. 이 구조 그대로 자료를 넣자, 이후 모든 장의 집필 요청이 "그냥 챕터 번호만 말하면" 되는 수준으로 단순해졌다.

---

12개 장 + 서문 + 맺음말 - "2장의 원고를 만들어줘"

자료 정리가 끝난 뒤부터는 정말 담백하게 장 번호만 부르는 방식으로 집필이 진행됐다.

```

2장의 원고를 만들어줘

```

3장의 원고를 작성해 줘.

```

계속해서 4장의 원고를 작성해 줘

```

이런 식으로 5장, 6장… 12장, 맺음말까지 이어졌다. 중간에 한 번, "대주제와 소주제의 연결이 앞주제와 뒷주제가 항상 자연스럽게 연결될 수 있도록 작성해 주고, 이 사항을 기획 문서와 README에도 반영해 달라"는 요청을 넣은 게 이후 작업의 방향을 갈랐다. 이때부터 매 장의 도입부와 마무리에 "앞 장에서는 ~ 했습니다. 다음 장에서는 ~ 하겠습니다"라는 연결 문장이 규칙으로 자리 잡았고, 이 규칙은 나중에 세 도구 모두가 "이 책의 가장 큰 강점"으로 꼽게 된다.

서문은 맨 마지막에 따로 요청했다.

```

서문 원고를 작성해 주고, 이미지와 스크린샷 작업을 추후에 진행할 예정이니 일단 비워 둬. 그리고 독자 연령 범위는 50대 중반에서 70대로 통일해 줘.

```

---

Copilot의 자체 검수 - "출간 승인은 조건부 보류"

원고가 다 모이자 Copilot에게 스스로 전체를 다시 읽고 냉정하게 평가해 달라고 요청했다.

```

다시 한번 전체적인 구성이나 주제 선정, 앞뒤 주제 연결, 문체의 통일, 맞춤법 등을 면밀히 분석 검토하여 개선 방안을 제안하고 내가 승인하면 수정해 줘.

```

돌아온 답은 예상보다 훨씬 진지했다. "4부 12장 구성과 주제 선택은 승인 가능한 수준"이라면서도 "안전 관련 제목, 초보자용 설치·가입 과정, 근거 자료가 보완되지 않아 출간 승인은 조건부 보류가 적절하다"고 못 박았다. 특히 인상 깊었던 지적은 이런 것들이었다.

5장 제목은 복약 판단까지 AI에 물어봐도 된다는 인상을 주는데, 본문은 오히려 그걸 금지하고 있다 — 제목과 본문이 충돌
10장도 "AI로 구별하는 법"이라는 제목이 "AI는 판정자가 아니다"라는 본문 원칙과 정면으로 부딪힌다
9장(손주와 AI 놀이)에는 미성년자 계정·이용 약관 관련 조건이 빠져 있어, 실제 서비스 약관과 대조가 필요하다
1장은 공백 제외 2,372자인데 10~12장은 각각 5,500~6,000자로, 뒤로 갈수록 분량이 두 배 이상 무거워진다
표가 6열까지 넓어지는 부분(복약 기록표 등)은 전자책(EPUB)에서 스마트폰 화면에 맞지 않아 글자가 너무 작아진다

권장안은 6가지 항목(제목 수정, 초보자 실습 경로 보완, 분량 조정, 일화 반복 축소, 연결 문장 다듬기, 전자책 표 형식 개선)이나 됐지만, 전부 받아들이지는 않았다.

```

1. 5·10장 제목과 관련 기획 문서 수정

진행해 줘.

```

여섯 개 중 딱 하나만 골라 승인한 것이다. AI가 제안한 걸 통째로 받아들이지 않고, 지금 당장 필요한 것만 추려내는 이 판단이 이후 다른 두 도구를 쓸 때도, 그리고 며칠 뒤 목차를 재검토할 때도 똑같이 반복됐다.

---

Codex의 교차 검증 - "가장 큰 문제는 순서가 아니라 제목의 정확성"

같은 원고를 이번엔 c:\dev\ebook-real 경로에서 Codex(GPT-5)로 열어, 거의 같은 문장으로 다시 검토를 요청했다.

```

C:\dev\ebook-real 에서 작업하던 내용을 열어 줘.

```

전체 내용의 구성 및 주제와 내용을 면밀히 검토해 줘. 대주제와 소주제의 제목의 적정성, 대주제와 소주제간 앞뒤 주제 사이에 제목과 내용이 자연스러운 연결이 되는지 확인하고 개선 방안을 제시하고 내가 승인하면 변경해 줘.

```

흥미로운 점은, Codex도 Copilot과 완전히 독립적으로 같은 문제(10장 제목이 "AI가 진위를 판정한다"는 인상을 주는데 본문은 반대로 말한다)를 짚어냈다는 것이다. 서로 다른 두 AI가 같은 원고에서 같은 결함을 찾아낸 셈이다.

```

전체를 함께 변경해 줘

```

이번엔 Copilot 때와 달리 "전체를 함께" 승인했다. 그 결과 Codex는 훨씬 대담하게 움직였다. 목차와 기획서까지 포함해 총 17개 파일의 제목 체계를 통째로 손봤고, 반복되던 "Part" 표기를 정리했으며, 10장을 "보이스피싱"과 "가짜뉴스"라는 두 구역으로 명확히 나누고, 12장의 실습 6개를 3개 묶음으로 통합하고, 맺음말의 중복 요약을 줄였다. 심지어 2장 끝부분에 남아 있던 의미 없는 알파벳 R 한 글자까지 찾아내 지웠다.

```

본문의 형식 및 문체의 일관성, 맞춤법과 뛰어쓰기를 점검하고 개선해줘

```

이어진 문체·맞춤법 검토에서는 해보세요/해 보세요, 알려줘/알려 줘, 전문용어/전문 용어처럼 띄어쓰기가 흔들리는 지점들을 국립국어원 보조 용언 띄어쓰기 원칙에 맞춰 일괄 정리했고, 저자 시점이 3인칭("저자")과 1인칭("저")으로 섞여 있던 부분도 1인칭으로 통일했다. 마지막엔 14개 원고를 순서대로 합쳐 v1-gpt1차감수.md로 저장했다.

---

Claude Code의 교차 검증 - "계획을 세우다 스스로 뒤집은 순간"

세 번째로 D:\ebook-real' 경로에서 Claude Code에 같은 검토를 요청했다. Claude Code가 찾아낸 문제는 앞의 두 도구보다 훨씬 소소했다 — 실습 단계 표기가 장마다 "N단계"와 "실습 N"으로 갈려 있는 점, 12개 장 중 두 곳만 제목에 부제가 달려 있는 점 정도였다.

그런데 부제를 나머지 열 개 장에도 맞춰 추가하기로 승인받고 실제 작업에 들어간 순간, 모든 장의 제목 바로 아래에 이미 "핵심 메시지:" 요약 줄이 존재한다는 걸 뒤늦게 발견했다. 그대로 진행하면 제목 밑에 요약이 두 겹으로 겹치는 상황이었다. 그래서 다시 사용자에게 돌아가 "애초 제안과 반대로, 두 장의 부제를 오히려 지우는 게 낫겠다"고 방향을 뒤집어 확인받았다. 승인받은 계획도 실행 중에 더 나은 정보가 나오면 고집하지 않고 되돌아가 확인하는 편이 안전하다는 걸 보여준 순간이었다.

이후 진행한 문체·맞춤법 점검에서는 14개 파일을 전부 통독한 뒤, 서문의 "직접 해봅니다"(띄어쓰기 누락), 6장의 "보여줄"(같은 장 안에서 이미 "보여 주고"로 띄어 쓴 표현과 불일치), 12장에만 빠져 있던 "출간 전 확인 필요" 메모까지 딱 세 곳만 찾아 수정했다. 마지막으로 14개 원고를 합쳐 v1-claude1차감수.md로 저장했다.

---

목차 재검토 - 두 갈래 기획안, 어떤 걸 살릴까

며칠 뒤, 원고 검수와는 별개로 목차 자체를 다시 들여다볼 일이 생겼다. 옵시디언에 목차 문서가 두 개 있었다 — 지금 출간용으로 잠정 확정한 4부 10장짜리 목차와, 맨 처음 검토하다가 절반 넘게 덜어낸 7부 37꼭지짜리 초안. 확정안으로 좁히는 과정에서 빠진 내용 중에 다시 살리고 싶은 게 있는지 궁금해서, 두 옵시디언 링크를 그대로 Claude Code에 던졌다.

```

위의 첫번째 url은 전자책을 출간하려고 잠정 결정한 목차 구성이고, 두번째 url은 처음에 검토했던 목차 구성이야. 처음에 검토했던 목차 내용 중에서 일부를 발췌하여 잠정결정안에 추가 보완 했으면 해. 어떻게 하면 좋을까?

```

옵시디언 링크(`obsidian://open?vault=...`)만으로는 실제 파일이 어디 있는지 알 수 없었는데, 두 번째 볼트 이름 "ebook(확장)"으로는 파일 탐색이 바로 안 됐다. 이때 Claude Code가 스스로 옵시디언 설정 파일(`obsidian.json`)을 열어, 그 안에 기록된 볼트별 실제 경로 목록에서 C:\dev\ebook(확장)이라는 진짜 위치를 찾아냈다. 폴더 이름만 대충 짐작하지 않고, 프로그램이 남긴 "진짜 기록"을 뒤져서 답을 찾아낸 점이 인상적이었다.

두 목차를 나란히 읽은 Claude Code는 확정안이 "두려움 낮추기 → 활용 → 확장 → 주도권 지키기"라는 좁고 단단한 흐름인 반면, 초안은 훨씬 넓은 범위(사회 변화 인식, 프롬프트 요령, 금융·노후, 창작, AI 오답 대응, 각종 부록)를 다룬다고 정리했다. 그리고 전체를 다시 되살리기보다 세 가지 방식을 제안했다.

기존 장 안에 "팁 박스"로 흡수 (예: 프롬프트 요령, 접근성 설정, 사기 문자 체크리스트)
비중이 큰 항목은 새 장으로 승격 (예: 금융·연금·보험 장, "AI도 거짓말할 수 있다"는 걸 알려주는 장)
실용 자료는 부록으로 그대로 이식 (질문 100선, 추천 앱 지도, 용어 사전, 30일 다이어리 등)

```

잠점안 목차.md 파일 수정안을 보여주고 내가 승인하면 진행해줘.

```

승인 전 확인 절차를 요청하자, Claude Code는 실제로 목차.md 파일을 어떻게 고칠지 전체 마크다운 초안을 미리 보여줬다. 새 장 2개(05장 금융·연금, 09장 AI의 한계 이해하기)를 추가하고, 기존 장 4곳에 팁 박스를 끼워 넣고, 부록 섹션을 신설하는 구체적인 수정본이었다.

그런데 막상 초안을 보고 나니 판단이 달라졌다.

```

일단 반영하지 말고 보류해줘. 이번에는 출간하는데 목표를 두고 지금까지 검토한 잠정안으로 우선 진행하여 경험을 쌓은 다음에 증보판을 내며 추가 작업할 때 반영할 께.

```

지금 당장의 목표는 "일단 출간해서 경험을 쌓는 것"이지, "가장 완벽한 목차를 만드는 것"이 아니라는 판단이었다. Claude Code는 파일을 건드리지 않고, 대신 방금 정리한 보완 후보 내용을 별도의 기록 파일로 남겨 두었다 — 다음에 "증보판" 이야기가 나오면 언제든 다시 꺼내 쓸 수 있도록.

---

✅ 결과 (After)

Before vs After

| 항목 | Before | After |

| ----------------- | ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |

| 원고 상태 | 12개 장 + 서문·맺음말이 각각 낱개 파일로 흩어져 있음 | 통합본 2종(`v1-gpt1차감수.md`, v1-claude1차감수.md) 완성 |

| 제목·본문 불일치 | 5장·10장 제목이 본문 원칙과 충돌 (두 도구가 독립적으로 발견) | 두 곳 모두 본문 메시지에 맞춰 수정 완료 |

| 검토 시각 | 저자 혼자만의 검토 | GitHub Copilot, Codex, Claude Code 3개 도구의 교차 검증 확보 |

| 편집 강도 비교 | (해보기 전에는 알 수 없었음) | Copilot=안전·법률 이슈까지 지적하는 감수자, Codex=제목·구조를 통째로 재편하는 편집장, Claude Code=최소 변경만 하는 교열자로 성격 확인 |

| 목차 보완 고민 | "초안에서 뺀 내용, 다시 살려야 하나?" 막연한 고민만 있음 | 보완 후보를 3가지 방식(팁 박스/신설 장/부록)으로 구체화하고, "지금 반영 X, 증보판 때 반영"으로 결정 완료 |

결과물

C:\dev\ebook-real\v1-gpt1차감수.md — Codex가 제목·구조를 대폭 재편하고 문체까지 교정한 통합본
D:\ebook-real'\v1-claude1차감수.md, C:\dev\ebook-real\v1-claude1차감수.md — Claude Code가 최소한만 손본 보수적 통합본
두 버전을 나란히 남겨 두고, 최종 반영은 저자가 직접 두 버전을 비교하며 고르기로 함
목차.md는 수정하지 않고 잠정 확정안 그대로 유지, 보완 후보 목록만 별도로 기록해 둠 (증보판 작업 시 참고용)

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

"알아서 고쳐 줘" 대신 "권장안 중 몇 번만 진행해 줘"라고 범위를 지정하기 — Copilot이 6가지를 제안했을 때 1번만 승인한 것처럼, AI의 권장안은 메뉴판으로 쓰고 실제 실행 범위는 사람이 고르는 편이 안전했다.
같은 질문을 여러 AI 도구에 반복 투입해 교차 검증하기 — 서로 다른 세 도구가 "5장·10장 제목이 본문과 어긋난다"는 같은 문제를 독립적으로 짚어냈을 때, 그 지적을 훨씬 더 신뢰할 수 있었다.
작업 초반에 원고 전체를 관통하는 규칙(장 연결 문장 등)을 한 번 정해 두기 — 이후 모든 장 집필에 자동으로 적용되어, 세 도구 모두 "이 책의 가장 큰 강점"으로 꼽을 만큼 일관성이 유지됐다.
파일을 실제로 고치기 전에 "수정안부터 보여 달라"고 요청하기 — 목차 재검토 때처럼, 전체 수정본을 먼저 눈으로 확인한 뒤에야 "지금은 이게 아니다"라는 판단이 명확해졌다. 승인 전 미리보기 단계를 한 번 넣는 것만으로 되돌리기 어려운 수정을 막을 수 있었다.
"지금 할 일"과 "나중에 할 일"을 구분해서 AI에게 맡기기 — 좋은 아이디어라도 지금 목표(출간)와 맞지 않으면 즉시 실행하지 않고, 대신 나중에 다시 꺼내 쓸 수 있게 "기록만" 해 달라고 요청했다. AI에게 맡기면 이런 임시 보류 항목도 잊어버리지 않고 남길 수 있었다.

이렇게 하면 안 돼요

한 도구의 대대적인 재편집 결과를 그대로 최종본으로 확정하지 않기 — Codex처럼 17개 파일을 한 번에 고치는 방식은 속도는 빠르지만, 사람이 다시 한 번 전체를 읽어 보지 않으면 의도치 않은 축소·통합(예: 실습 6개→3개)이 그대로 굳어질 수 있다.
AI가 "안전 문제"를 지적했을 때 가볍게 넘기지 않기 — 9장의 미성년자 계정 조건처럼, 서비스 이용 약관과 관련된 지적은 문체 교정과 다른 층위의 문제이므로 별도로 확인이 필요하다.
좋아 보이는 보완안이라고 바로 실행하지 않기 — 목차 보완안은 내용 자체는 타당했지만, "지금 시점"에 맞는 결정은 아니었다. AI가 제시한 방안의 완성도와, 그걸 지금 실행하는 게 맞는지는 별개의 판단이다.

🌍 다른 업무에 적용한다면?

보고서, 제안서, 강의안처럼 "한 번 쓰고 끝"이 아니라 여러 차례 다듬어야 하는 글이라면, 초고는 한 도구로 빠르게 뽑고 검토는 성격이 다른 두세 개 도구에 병렬로 맡겨 보는 방식이 유용해 보인다. 특히 "이 지시문 그대로 다른 도구에도 던져 보면 뭐라고 할까"라는 실험은, 결과물의 완성도보다 내가 놓친 리스크를 찾는 용도로 훨씬 잘 맞았다. 또한 기획안이 여러 버전으로 갈라져 있을 때(예: 초기 브레인스토밍 vs 최종 확정안), 무작정 하나로 합치기보다 "지금 쓸 것"과 "나중에 참고할 것"을 나눠서 AI에게 기록을 맡겨 두면, 프로젝트가 산으로 가지 않으면서도 좋은 아이디어를 잃어버리지 않을 수 있다.

🚀 앞으로의 계획

두 통합본(`v1-gpt1차감수.md`, v1-claude1차감수.md)을 나란히 놓고, 항목별로 어느 쪽 표현이 더 나은지 직접 비교해 최종 원고를 확정할 예정이다. 이후에는 보류해 두었던 이미지·스크린샷 작업과, Copilot이 지적한 "전자책에서 읽기 어려운 넓은 표"를 세로형으로 바꾸는 작업을 진행할 계획이다. 목차는 지금의 4부 10장 확정안으로 우선 출간을 마치고, 독자 반응을 본 뒤 증보판을 낼 때 이번에 정리해 둔 보완 후보(금융·연금 장, AI 한계 이해 장, 부록 5종)를 다시 검토할 예정이다.

📋 재사용 가능한 프롬프트

프롬프트 1: 원고 구조·연결 검토

> 전체 내용의 구성 및 주제와 내용을 면밀히 검토해 줘. 대주제와 소주제의 제목의 적정성, 대주제와 소주제 간 앞뒤 주제 사이에 제목과 내용이 자연스러운 연결이 되는지 확인하고 개선 방안을 제시하고, 내가 승인하면 변경해 줘.

프롬프트 2: 문체·맞춤법 점검

> 본문의 형식 및 문체의 일관성, 맞춤법과 띄어쓰기를 점검하고 개선해 줘.

프롬프트 3: 선택적 승인 (권장안 중 일부만)

> [번호]번 항목만 진행해 줘. 나머지는 아직 반영하지 마.

> [수정할 부분]은 본인 상황에 맞게 변경하세요

프롬프트 4: 버전이 갈라진 기획안 비교·발췌

> [A 문서]는 지금 확정한 안이고, [B 문서]는 이전에 검토했던 안이야. B에 있는 내용 중 일부를 A에 발췌해서 보완하고 싶은데 어떻게 하면 좋을지 제안해 줘. 수정안을 먼저 보여주고, 내가 승인하면 그때 파일에 반영해 줘.

프롬프트 5: 지금은 실행하지 말고 기록만 남기기

> 이 내용은 지금 바로 반영하지 말고 보류할게. [이유/다음 시점]에 다시 참고할 수 있게 어딘가에 기록만 남겨 줘.

---

📐 맞춤법·문법 검사 결과

이 글은 국립국어원 어문 규범(한글 맞춤법, 표준어 규정) 기준으로 본문을 다시 통독하며 검토했습니다. 별도의 외부 맞춤법 검사 서비스(예: 부산대 "바른한글" 등)를 직접 호출할 수 있는 도구 접근 권한이 없어, 동일한 검사 기준(띄어쓰기·보조 용언·조사·어미 활용)으로 원고를 직접 대조하는 방식으로 점검했습니다. 발견된 항목은 다음과 같습니다.

| 위치 | 원문 | 수정 | 사유 |

| ------------------------ | ---------------------------------------------------------------- | ---------------------- | -------------------------------------------------------------------------------------------------------------------- |

참고: 표에서 "원문 유지"로 표시한 항목은 모두 인터뷰이(사용자)의 실제 발화를 코드블록으로 그대로 옮긴 부분입니다. 실제 대화 기록의 사실성을 지키기 위해 인용문 자체는 고치지 않았고, 저자가 작성한 서술형 본문에서만 맞춤법·띄어쓰기 오류를 찾아 수정했습니다. 검토 결과 서술형 본문에서는 별도의 맞춤법·띄어쓰기 오류가 발견되지 않았습니다.

😈 정말 찐찐찐 마지막 할인가!!! 24기 AI 스터디 😈