"What matters is not how fast you type, but how well you specify." — Andrej Karpathy (2024 Stanford 강연)

---

도입 — 한 표가 모든 것을 바꾼다

2024 년 가을, Andrej Karpathy 가 한 장의 슬라이드를 띄웠다. 슬라이드 제목은 단순했다. "Software 1.0 / 2.0 / 3.0."

이 표 한 장이 우리가 코드 라고 부르는 것의 정의 자체를 흔들었다. 4 년 전이라면 "코드 = 사람이 키보드로 친 텍스트" 였다. 지금은 그 정의가 더 이상 작동하지 않는다. 1 장에서는 그 표가 왜 여러분의 이력서와 직접 연결되는지 를 본다.

핵심 메시지를 미리 박아 두자.

여러분이 학교에서 4 년 동안 훈련해 온 타이핑 속도 는 더 이상 핵심 역량이 아니다. 새 레버리지는 컨텍스트를 통제하고 설계를 정의하는 능력 이다.

---

Karpathy 의 3 단계

표를 옮긴다.

이 표를 처음 보면 두 가지 오해가 자주 일어난다. 둘 다 미리 짚어 두자.

오해 1 — "3.0 이 1.0 / 2.0 을 대체 한다." ❌

3.0 은 1.0 / 2.0 위에 쌓인 층 이다. AI 가 짜는 코드는 여전히 1.0 (명시 프로그래밍) 의 결과물이고, AI 모델 자체는 2.0 (신경망) 으로 만들어졌다. 3.0 은 그 두 층을 사람이 자연어로 지휘 하는 새 인터페이스다.

오해 2 — "3.0 시대에는 코딩 능력이 필요 없다." ❌

코딩 능력은 어디로 옮겨갔을 뿐 사라지지 않았다. 옮겨간 자리가 어디인지 — 그것이 일차 산출물의 이동 이다.

---

일차 산출물의 이동 — 코드에서 명세로

표의 마지막 열을 다시 보라.

• 1.0 시대 일차 산출물 = 소스 코드
• 2.0 시대 일차 산출물 = 모델 가중치
• 3.0 시대 일차 산출물 = 명세 (Spec) + 테스트

여러분이 학교에서 평가받아 온 모든 과제 — 알고리즘 풀이, OOP 과제, DB 시험 — 의 산출물은 소스 코드 였다. "동작하는 코드를 짠 사람이 점수를 받았다."

3.0 시대에는 AI 가 코드를 짠다. 여러분의 일차 산출물은 AI 가 무엇을 만들지를 정의한 명세 + 그것이 잘 만들어졌는지 검증한 테스트 다. 코드는 부산물이고, 명세와 테스트가 본체다.

이 한 줄이 이력서에서 "AI 협업 설계 능력" 과 "검증 루프 설계 경험" 이라는 항목으로 나타난다. 그 항목들이 명세 작성 능력 + 테스트 설계 능력 을 다른 이름으로 부른 것뿐이다.

---

한 사례 — Elisa 1 주일 39,000 줄

이 변화가 얼마나 강력한지 한 가지 사례로 보자.

Elisa 프로젝트 (2025) — 1 인 개발자, 1 주일, 39,000 줄, 1,500 테스트, 76 커밋.

여러분이 학기 프로젝트에서 3 인 팀, 3 주, 3,000 줄 을 만들어 본 적이 있다면 이 숫자가 어떤 의미인지 안다. 1 인 1 주일에 학기 프로젝트 13 개 분량 이 나왔다.

비결은 무엇이었을까? AI 가 강해서 가 아니다. 사례를 자세히 들여다보면 인간이 한 일은 명확하다:

• 아키텍처 + 명세
• 테스트 골격 (1,500 테스트가 수동으로 짜였다)
• 검증 루프 설계

AI 가 한 일은 — 타이핑 39,000 줄. 즉 인간 = 설계자, AI = 타이핑 머신. 3 주 → 1 주일 의 단축은 AI 의 능력 이 아니라 역할 분담의 재정의 에서 나왔다.

(이 사례는 부록 A 의 사례 색인에서 Elisa 프로젝트 로 다시 만난다. 출처와 1 차 인터뷰 링크가 거기에 있다.)

---

민주화 효과 — 진입 장벽이 낮아졌다, 설계 부담은 그대로

3.0 시대의 부산물은 또 하나 있다 — 민주화. 자연어가 보편 인터페이스가 되면서 4 가지 영역에서 비개발자가 직접 소프트웨어를 만들기 시작했다.

• 저널리스트 → 데이터 시각화 도구
• 생물학자 → 분석 파이프라인
• 프롭테크 전문가 → 허가 자동화 도구
• 교육자 → 맞춤 학습 도구

이걸 보면 "누구나 쉽게 만들 수 있는 시대" 라는 인상을 받기 쉽다. 절반은 맞고 절반은 틀렸다.

진입 장벽 — 사라졌다. ✅ 설계 부담 — 그대로다. ❌

그래서 현장에서는 3 개월의 벽 이라는 현상이 벌어진다 (4 장에서 자세히 다룬다). 1~2 개월 만에 빠르게 만든 시스템이 3 개월째에 무너진다. 왜? 진입 장벽이 사라졌으니 설계도 사라져도 된다고 착각 했기 때문에.

이게 이 책의 출발점이다. 3.0 시대는 코딩이 쉬워진 시대 가 아니다. 코딩의 위치 가 옮겨간 시대 다. 그 옮겨간 자리가 명세와 검증 이고, 그것이 설계 의 또 다른 이름이다.

---

1 장 정리

표어로 다시 기록한다.

AI-Native Vibe Coding: No Design, No Code.

AI-Native 가 시대 를 기록한다 — 우리는 이미 LLM 이 일하는 시대에 산다. No Design, No Code 가 그 안에서 무엇이 무너지는지 를 기록한다 — 설계가 없으면 코드가 안 만들어지는 게 아니라 잘못 만들어진다. 1.0/2.0/3.0 표는 그 시대 를 그린 한 장의 그림이다.

다음 장에서는 우리만 이 말을 하는 게 아니라는 사실 을 본다. Karpathy 본인, Cursor CEO Truell, GitHub, Sam Altman — 도구를 만든 사람들이 모두 같은 말을 한다.

"여러분이 매일 쓰는 도구를 만든 사람들조차 설계 먼저 라고 말한다."