"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

이 책을 선택한 이유

저는 Claude Code를 거의 써본 적이 없습니다.평소엔 antigravity IDE를 메인으로 쓰고, 해커톤이나 "뭔가 만들고 싶다"는 충동이 생겼을 때만 AI 에이전트를 꺼내 드는 편이라서요. 학습 중심으로 움직이는 지금 시점엔 서브에이전트나 하네스까지는 아직 필요하지 않다고 생각했고, antigravity나 코파일럿으로도 충분했습니다.

그런데도 이 책을 고른 이유는 두 가지였습니다.

• 첫째, "Claude Code는 뭐가 다를까?" 라는 단순한 궁금증.
• 둘째, 이남희 저자님의 책이라는 것. 책을 많이 읽다 보면 시간에 쫓겨 쓰인 책과, 공들여 쓰인 책의 차이가 느껴질 때가 있습니다. 저자님은 분명히 후자입니다. 이전 책을 인상 깊게 읽기도 했고, 42에서 강연도 들었던 터라, AI처럼 흐름이 빠른 주제를 어떻게 풀어내셨을지가 궁금했습니다.

💡 antigravity-ide. 바이브 코딩 초보자에게 꽤 친화적이다.

💡 정성스럽게 책을 쓰는 "이남희" 저자님

이 책에서 내가 얻은 것

AI 시대의 개발자란?

책을 읽을 때마다 찾아보는 키워드인 것 같습니다.

과거의 '좋은 개발자'가 문제를 해결하고 빠르고 정확하게 코드를 작성하는 사람이었다면, 지금은 AI 도구를 통해 여러 작업을 지시하고 조율하여 문제를 즉각적으로 수정하는 역할(Orchestrator)이라고 볼 수 있다.(중략)
그럼에도 불구하고 변하지 않는 것들이 있다. 문제가 발생했을 때 해당 문제를 해결해나가는 능력과 시시각각 변하는 비즈니스 도메인에 대한 이해, 법적/윤리적 이슈에 대한 판단력은 여전히 필수적인 역량이다. 부서 간, 역할 간 커뮤니케이션 능력 역시 마찬가지다.

저자 두 분은 변하지 않는 것들도 짚어줍니다. 문제 해결 능력, 비즈니스 도메인 이해, 법적·윤리적 판단력, 커뮤니케이션 역량 — 이것들은 AI가 대체하지 못하는 영역이고, 오히려 지금일수록 더 중요해집니다. 오케스트레이터가 되려면 결국 "무엇을 시킬지" 알아야 하니까요.

저자 두 분이 클로드 코드를 선택한 이유. WHY가 명확합니다.

개인적으로 가장 인상 깊었던 페이지는 p43이었습니다. 도구 선택의 이유를 이렇게 정리합니다.

1. 성장 속도가 빠르다
2. 에이전트 방식이 AI 코딩의 미래 방향을 대표한다.
3. 도구에 종속되지 않는 방법론 학습에 적합하다. 이 책의 목표는 특정 도구에 버튼 위치를 알려주는 것이 아니다.

• AI와 어떻게 협업할지, 작업을 어떻게 분해할지, 결과를 어떻게 검증할지에 대한 방법론을 다룬다.

세 번째가 핵심입니다. 이 책의 목표는 버튼 위치를 알려주는 게 아닙니다. AI와 어떻게 협업할지, 작업을 어떻게 분해할지, 결과를 어떻게 검증할지에 대한 방법론을 다룹니다. Claude Code가 1년 뒤에 바뀌더라도, 이 책에서 얻은 사고방식은 남는 구조입니다.

실패의 비용이 달라졌다.

과거의 실패는 무거웠다. 현재의 실패는 몇 시간 투자로 판단이 가능할 정도로 가벼운 노력만 기울이면 된다. 개인 차원에서 빠르게 시도하고 접을 수 있다. '안 되는 걸 알았다'라는 것 자체가 의미 있는 성과가 된다.

덧붙여 책에서 다루는 "실패 비용의 변화"도 기억에 남습니다. 과거의 실패는 무거웠지만, 지금은 몇 시간 투자로 판단이 가능할 만큼 가벼워졌다고요. '안 되는 걸 알았다'는 것 자체가 의미 있는 성과가 된다 — 이 문장이 생각보다 오래 머물렀습니다.

모델 선택 가이드

책에서 소개하는 모델 선택 기준이 antigravity와 구조가 거의 같아서, 대조해서 정리해봤습니다.

도구가 달라도 "무거운 판단은 큰 모델, 빠른 실행은 작은 모델"이라는 원칙은 동일합니다.

TDD와 SDD

실전 적용: 해커톤에서 구현 못 한 파트 추가 구현하기

책의 내용을 머릿속에서만 이해하는 게 아쉬워서, 이전 해커톤에서 구현하다 만 프로젝트를 꺼냈습니다.

요구사항 → 계약(타입) 정의 → 실패하는 테스트 작성 → 코드 작성 → 테스트 통과 → 커밋

1) SDD(Specification-Driven Development): 무엇을 만들지 문서와 타입으로 먼저 정의하고, 그것을 기준으로 개발

• 스펙 문서 작성하기
  • 어떤 데이터 구조를 쓸 것인가?
  • 어떤 함수가 필요한가?
  • 어떤 컴포넌트를 수정할 것인가.
• 타입 계약 파일 작성
  계약서. 모든 파일이 이 계약을 따라야 함.
  

export interface Recipe {
  id: number;
  name: string;
  kind: string;
  time: string;
  difficulty: string;
  servings: string;
  ingredients: { name: string }[];  // 구조를 계약으로 고정
  steps: string[];
}

이 타입 계약이 곧 설계서입니다. 이후 모든 코드는 이 계약을 따릅니다.

2) TDD(Test-Driven Development): 코드를 짜기 전에 테스트를 먼저 작성하고, 테스트를 통과하도록 코드를 짭니다.

• 3단계 사이클: Red → Green → Refactor
  🔴 RED → 실패하는 테스트 작성 (아직 코드가 없으니 당연히 실패)
  🟢 GREEN → 테스트를 통과하는 최소한의 코드 작성
  🔵 REFACTOR → 코드를 개선하되 테스트는 계속 통과

💡 해당 레포지토리: https://github.com/erdoslibrary/gdg_daejeon_hackathon

해커톤 당시에는 김치 볶음밥 하나만 레시피로 설정해서 배포했었는데요.
기존 기능은 건드리지 않고 레시피 추천 기능을 안전하게 완성했습니다.

┌─────────────────────────────────────────────────────────────────┐
│                      개발 시작 전                           │
│                                                            │
│   feature_recipe_recommendation.md      CLAUDE.md          │
│   ┌──────────────────────────────┐   ┌──────────────────┐       │
│   │ - 무엇을 만들 것인가        │   │ - 건드려도 되는    │       │
│   │ - 어떤 데이터 구조인가      │   │   파일            │       │
│   │ - 어떤 UI인가              │   │ - 절대 건드리면    │       │
│   └──────────────────────────────┘   │   안 되는 파일     │       │
│              SDD 명세서            └──────────────────┘       │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                    feat/recipe 브랜치                            │
│                                                                 │
│  Step 1           Step 2          Step 3          Step 4        │
│  recipes.json  →  getTodayRecipe  →  RecipePanel  →  페이지 연결  │
│       │                │                │               │       │
│   [테스트 통과?]   [테스트 통과?]  [테스트 통과?]        [빌드 통과?]   │    
│       ✅               ✅               ✅             ✅       │
│                                                                 │
│  ※ 테스트 실패하면 다음 단계로 못 넘어감                               │
│  ※ 금지 파일 수정 감지되면 자동 차단                                  │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                       PR 오픈                                    │
│                                                                 │
│   CodeRabbit 자동 리뷰                                            │
│   ┌──────────────────────────────────────────────────────────┐  │
│   │  ❌ steps.length 가드 없음    →  ✅ 수정 (실제 버그)         │  │
│   │  ❌ shellspec 절대경로        →  ✅ 수정 (이식성 문제)        │  │
│   │  ⚠️  getDayOfYear 오프바이원  →  🚫 유지 (영향 없음)          │  │
│   │  ⚠️  spec.sh 쿼팅 패턴       →  🚫 유지 (의도된 코드)         │  │
│   └──────────────────────────────────────────────────────────┘  │
│                    판단: 진짜 문제만 수정                           │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                     main 브랜치 merge                            │
│                                                                 │
│   main ───────────────────────────────────●                     │
│                                           ↑                     │
│   feat/recipe ──●──●──●──●──●────────────┘                      │
│                                                                 │
│   결과:                                                          │
│   ✅ 레시피 기능만 정확히 추가됨                                     │
│   ✅ 기존 채팅/유저 기능 전혀 영향 없음                               │
│   ✅ 엣지케이스 버그 없이 배포됨                                     │
└─────────────────────────────────────────────────────────────────┘

SDD와 TDD를 같이 적용하니 결과가 눈에 띄게 안정적이었습니다. 기존 코드를 건드리지 않고 기능을 붙이는 게 이렇게 깔끔하게 될 수 있구나 싶었고요.

결론

솔직히 말하면 터미널에서의 Claude랑은 아직 완전히 친하지는 않습니다. (/usage만 볼 줄 알면 되는 거 아닌가요… )
그런데 이 책은 "Claude Code를 잘 쓰는 법"보다 "AI와 어떻게 일할 것인가"를 먼저 이야기합니다. 그게 이 책을 읽고 나서 가장 남는 부분이었습니다. 도구는 바뀌어도 방법론은 남으니까요. 개발 흐름을 어떻게 구조화할지 고민하는 분께 추천하는 책입니다.