들어가며 — 설계 없이는 코딩이 안 된다
슬라이드 2 · 들어가며 — 챕터 질문
우리는 왜 다시 "설계"를 말하는가?
2026년 4월 24일, 바이브 코딩이라는 단어를 만든 안드레 카파시(Andrei Karpathy)가 X에 한 줄을 올렸다. "Things get better in plan mode." (계획 모드일 때 더 좋아진다.)
단어를 만든 사람이 그 단어를 과거형으로 쓰기 시작한 시점 — 그것이 우리가 이 책을 시작해야 하는 자리다.
슬라이드 3 · 들어가며 — Software 3.0
Software 3.0 — 시대의 좌표
세 세대로 가르는 진화론:
Software 1.0 (규칙의 시대)
인간이 모든 규칙과 예외를 코드로 명시한다. C, Java의 시대. 일차 산출물: 소스 코드
Software 2.0 (데이터의 시대)
인간이 데이터를 모으면, 신경망이 패턴을 학습한다. PyTorch, TensorFlow의 시대. 일차 산출물: 소스 코드
Software 3.0 (자연어의 시대)
인간이 자연어로 의도를 정의하면, AI가 코드를 만든다. ChatGPT, Claude의 시대. 일차 산출물: 명세(Spec)와 테스트(Test)로 이동.
셋은 대체가 아니라 적층(stack)이다. 3.0 시대에도 1.0과 2.0은 그대로 작동한다. 다만 결정적 변화가 있다 — 개발자의 레버리지가 타이핑 속도에서 컨텍스트 윈도우 통제 능력으로 이동했다는 것.
슬라이드 4 · 들어가며 — 4 거인이 같은 결론에 도달했다
2026년의 수렴 — 4년 진화의 끝
네 사람은 서로 경쟁하는 회사를 운영한다. 그러나 2026년 같은 자리에 모였다:
Andrei Karpathy (Tesla 전 AI Director, 창시자)
"Things get better in plan mode." (X, 2026-04-24)
Michael Truell (Cursor CEO)
"Start with a plan." (X 팁 스레드, 2026-03-18)
GitHub (공식 블로그)
"Most multi-agent workflow failures come down to missing structure." (2026-02-24)
Sam Altman (OpenAI CEO)
"엔지니어링의 본질은 타이핑이 아니라 무엇을·왜 지어야 하는지 판단하는 것." (TU Berlin 인터뷰)
같은 결론: 설계 없이는 코드 한 줄도 없다.
이는 한 사람의 의견이 아니라 4년간 수렴된 산업적 사실이다.
슬라이드 5 · 들어가며 — Plan Mode가 표준이 된 이유
도구가 강제하는 증거
Claude Code · GitHub Copilot · Cursor — 세 도구가 서로 다른 회사에서 만들어졌다.
그런데 사용자에게 같은 순서를 강제한다:
Explore → Plan → Code
왜 이 순서인가?
바로 생성(immediate generation)보다 먼저 구조화(upfront structuring) 하는 것이 통계적으로 5.5배 더 효율적이기 때문이다.
한 벤치마크는 PRD(Product Requirements Document)를 선제 제공한 작업이 그렇지 않은 작업 대비 토큰 소비 5.5배 를 기록한다고 보고한다. 같은 결과를 5.5배 적은 토큰으로 얻는다는 의미다.
그러나 한 가지 미묘한 함정이 있다. Plan Mode가 표준이 됐다 는 사실이 우리도 자동으로 그 혜택을 받는다 를 뜻하지는 않는다. 도구는 Plan Mode를 제공할 뿐, 강제하지 않는다. 사용자가 직접 손가락으로 Plan 버튼을 클릭해야 한다.
슬라이드 6 · 들어가며 — 복리로 쌓이는 효능감을 먼저 누리자
효능감(Efficacy)은 기술에서 나오지 않는다
프로젝트 1에서 명세를 정확히 박은 사람 은 프로젝트 2에서 더 깨끗한 컨텍스트를 시작점으로 갖는다.
그가 작성한 CLAUDE.md와 Plan, 그가 만든 검증 루프와 하네스(Harness)가 다음 프로젝트의 부트스트랩 비용(bootstrap cost)을 0으로 떨어뜨린다.
같은 시간 동안:
- 같은 분기: 2배의 시스템
- 다음 분기: 4배의 시스템
- 다음 해: 10배의 시스템
도구의 위력은 그를 통해서만 누적된다.
옆자리 동료가 바로 생성 모드 로 같은 도구를 쓰는 동안, 그는 매 프로젝트마다 이전 프로젝트의 레버리지를 가산 해 다음 프로젝트에 기록한다.
2026년 5월 현재, 우리는 이 복리 효능감을 누릴 첫 번째 집단이 될 수 있다.
그 효능감은 기술이 좋아서가 아니라 설계를 먼저 기록하는 자세 에서 나온다. 카파시의 plan mode, Truell의 start with a plan, GitHub의 structure, Altman의 judgment — 네 거인이 가리키는 같은 자세다.
◆ 용어 정리
- Software 3.0: 자연어가 일차 인터페이스가 된 소프트웨어 시대. 일차 산출물이 코드에서 명세·테스트로 이동
- 컨텍스트 윈도우: 한 번의 추론에서 모델이 처리할 수 있는 토큰 범위. 모델의 단기 기억 용량
- Plan Mode: "탐색 → 계획 → 코드" 순서로 강제하는 개발 방식. 바로 생성보다 먼저 구조화
- 하네스(Harness): AI 가 일하는 환경 — CLAUDE.md, 검증 루프, 영구 지시어의 조합
- 복리(Compound Interest): 프로젝트 1의 설계가 프로젝트 2의 부트스트랩 비용을 0으로 만드는 누적 효과
◆ 다음 장으로
다음 Chapter 1 (Part 1) 은 AI와의 대화 가 시작된 자리로 들어간다.
거기서 우리는 가장 작은 질문에서 출발한다:
"왜 명령조(Imperative)가 정중한 부탁(Polite)보다 통계적으로 더 정확한 코드를 만드는가?"
그 작은 질문이, 4년 후 우리를 명세 주도 개발 의 자리로 끌고 온 첫 발걸음이다.