본 책의 17 장 흐름 본문 을 주제별 9 챕터로 다시 묶은 색인. 재방문 / 검색 / 주제별 깊이 가 필요한 자리에서 사용. 본 책 SSOT: synthesis/booklet-9-chapters (위키 카드)

---

도입 — 왜 두 안이 공존하는가

본 책은 17 장 흐름 으로 쓰였다. 그러나 *책 다 읽고 재검색 할 때 — 17 장 1 ~ 17 의 *흐름이 주제별 검색에는 불편 * 하다. 그래서 주제별 9 챕터로 다시 묶은 색인 이 부록 F.

두 안 서로 다른 강점. 이 부록은 9 챕터 절단면 을 박아 둔 자리.

---

9 챕터 구조

3 Part × 3 Chapter = 9 Chapter.

Part 1. 바이브 코딩의 환상과 숨겨진 청구서
   Ch 1. '3 개월의 벽' — 유포리아에서 혼돈으로
   Ch 2. 시한폭탄 — 기술 부채와 보안 재앙
   Ch 3. 디버깅 불능 세대

Part 2. 성공하는 AI 코딩의 패러다임 시프트 — 에이전틱 엔지니어링
   Ch 4. 거인들의 경고 — 타이핑이 아닌 판단·설계
   Ch 5. SDD 의 실증 성과
   Ch 6. 하네스 엔지니어링 — 환경 통제로 +13.7 점

Part 3. 2026 실전 AI 코딩 아키텍처 가이드 — 도구 설계 철학
   Ch 7. 플랜 모드의 당위성
   Ch 8. 규칙 파일의 마법
   Ch 9. 오케스트레이션 + 5 대 검증

---

Part 1. 바이브 코딩의 환상과 숨겨진 청구서 (실패 사례 분석)

설계 없는 코딩이 초기 속도 를 주지만, 결국 기술 부채와 운영 참사 로 번진다는 구조적 한계.

Ch 1. '3 개월의 벽' — 유포리아에서 혼돈으로

핵심 주장: *계획 단계와 dev / prod 분리가 없으면 바이브 코딩은 운영 사고로 직결. *

1 차 출처 / 사례:

• PocketOS DB 삭제 (2026-04-28)
• Lemkin Replit DB 삭제 (Jason Lemkin, 2025-08)

본 책 위치: 본문 4 장 (3 개월의 벽 + 7 사고)

Ch 2. 시한폭탄 — 기술 부채와 보안 재앙

핵심 주장: AI 코드는 인간 대비 논리 오류 1.75× / 보안 취약 2.74× / 중복 4× (GitClear 2.1 억 줄 분석).

1 차 출처 / 사례:

• AI 코드 53% 보안 결함 통계
• GitClear 2.1 억 줄 분석 보고서

본 책 위치: 본문 4 장 후반 (53% 통계)

Ch 3. 디버깅 불능 세대

핵심 주장: 설계 없이 AI 에 위임 시 디버깅 능력 17%+ 하락 (Anthropic RCT).

1 차 출처 / 사례:

• Anthropic RCT 디버깅 능력 측정
• (일반화) AI Slop 의 디버깅 비용 상승

본 책 위치: 본문 4 장 + 7 장 (Context Rot)

---

Part 2. 성공하는 AI 코딩의 패러다임 시프트 — 에이전틱 엔지니어링

무지성 바이브 코딩의 종말 → Spec 중심·설계 중심 의 정량적 성공.

Ch 4. 거인들의 경고 — 타이핑이 아닌 판단·설계

핵심 주장: 엔지니어링 본질은 타이핑이 아니라 시스템 아키텍트 역할 (Altman · Karpathy 자기 부정).

1 차 출처 / 사례:

• Karpathy "Things get better in plan mode" (2026-04-24)
• Altman TU Berlin 인터뷰
• Truell "Start with a plan" (2026-03-18)
• GitHub "Missing structure" (2026-02-24)
• Sanger "코더 → 시스템 아키텍트"

본 책 위치: 본문 1·2·6 장 (3 인 인용 + 1:1 매핑)

Ch 5. SDD 의 실증 성과

핵심 주장: Spec-Driven Development 도입 시 프로그래밍 −56% / PR 리뷰 −31.8% (MIT / MS / DeputyDev).

1 차 출처 / 사례:

• LangChain 52.8 → 66.5 (Top 30 → Top 5)
• SWE-bench 12.5% → 53% (4×)
• Klarna 80% / Podium 90% / C.H. Robinson 600 시간

본 책 위치: 본문 12 장 (전체)

Ch 6. 하네스 엔지니어링 — 환경 통제로 +13.7 점

핵심 주장: 모델 변경 없이 하네스 설계만으로 * 코딩 벤치마크 52.8 → 66.5 (LangChain).

1 차 출처 / 사례:

• LangChain Terminal Bench 2.0 실험
• Microsoft Azure SRE 45% → 75%

본 책 위치: 본문 8·12 장 (4 계층 + 정량)

---

Part 3. 2026 실전 AI 코딩 아키텍처 가이드 — 도구 설계 철학

최상위 도구들이 왜 설계 우선 을 시스템적으로 강제 하는가.

Ch 7. 플랜 모드의 당위성

핵심 주장: Claude Code · Cursor 가 환각 차단 을 위해 Plan Mode 를 기본 UX 로 강제.

1 차 출처 / 사례:

• Claude Code 공식 "Explore-Plan-Code"
• Cursor "detailed implementation plan before code"

본 책 위치: 본문 2 장 + 8 장 (저장소 영향 지도)

Ch 8. 규칙 파일의 마법

핵심 주장: CLAUDE.md / .cursorrules / AGENTS.md = 영구 지시어 = 매 세션 리로드 되는 설계 문서.

1 차 출처 / 사례:

• Karpathy CLAUDE.md 65 줄 (GitHub 10 만 스타)
• Boris Cherny 2,500 토큰 원칙
• Don't 75% / Do 25% 황금 비율

본 책 위치: 본문 14 장 (전체) — *책의 행동 진입점

Ch 9. 오케스트레이션 + 5 대 검증

핵심 주장: 5 종 체크리스트 — Goal / Non-goals / Acceptance / Verification / Memory · Rules. 책상에 붙여 놓을 카드.

1 차 출처 / 사례:

• 16 장의 5 종 체크리스트
• Boris "AI 가 스스로 검증 하게 만드는 사람"
• 알렉스 4 대 전략 ↔ 하네스 1:1 매핑

본 책 위치: 본문 16 장 + 부록 E (워크시트)

---

17 장 ↔ 9 챕터 매핑표

같은 메시지의 서로 다른 절단면 을 한 표로.

---

재방문 추천 순서

본 책 다 읽은 뒤 *어떤 자리에서 9 챕터 색인을 다시 펴는가 * 의 가이드.

입사 후 첫 주 — 기술 부채 / 보안 이슈 만났을 때 → Part 1 / Ch 2

**프로젝트 3 주째 * — 3 개월의 벽 작은 버전 에 막혔을 때 → Part 1 / Ch 1·3

**팀 회의에서 AI 도입 발표 * 할 때 → Part 2 / Ch 4·5·6 (정량 근거 풀)

**입사 *6 개월차 CLAUDE.md 첫 작성 * 할 때 → Part 3 / Ch 8·9

*팀장 / 기술 리드로 승진 시점 — 전체 9 챕터 통독 (조직 단위로 옮기는 시점)

---

위키 카드 추적

이 부록의 모든 내용은 다음 위키 카드에서 도출됐다.

30_wiki/_shared/synthesis/booklet-9-chapters.md   ← 본 부록의 SSOT
30_wiki/_shared/synthesis/booklet-toc-17-chapters.md  ← 본문 17 장의 SSOT

두 카드 모두 위키 안에서 상호 참조. 주제 색인 (9 장) ↔ 흐름 골격 (17 장) 의 자매 관계로 박혀 있다 (서문 / 14 장 Karpathy LLM Wiki 패턴 참조).

---

"같은 메시지, 두 절단면. 처음 읽을 때는 흐름 으로 (17 장). 재방문 할 때는 주제 로 (9 챕터). 그래서 두 안이 공존 한다."