코드를 치기 전에 벌어지는 일

Part I — The Shift

바이브 코딩, 그 다음

2025년 2월, Andrej Karpathy가 트윗 하나로 시대를 정의했다. "vibe coding" — 코드를 읽지 않고, 느낌대로 AI에게 시키고, 에러가 나면 에러 메시지를 다시 붙여넣는 코딩. 1년 뒤, 같은 사람이 이번엔 다른 단어를 꺼냈다. "agentic engineering."

이름이 바뀐 게 아니다. 문제의 크기가 바뀐 것이다.

패러다임 전환 타임라인

2025.02
Karpathy, "vibe coding" 명명. AI에게 코드를 시키고, 결과만 확인하는 워크플로우가 보편화되기 시작한다.
2025.09
GitHub, Spec Kit 오픈소스 공개. 스펙 주도 개발(SDD) 도구가 등장. "스펙이 먼저, 코드는 나중"이 공식화된다.
2025.12
Veracode, AI 코드 보안 보고서. AI 생성 코드의 보안 결함률 45%. Fortune 50 기업에서 취약점 10배 증가.
2026.02
Anthropic, Agent Teams(Swarms) 출시. Claude Code에서 여러 AI 에이전트가 팀을 이뤄 병렬 작업하는 시대가 열린다. Opus 4.6과 함께 공식 릴리스.
2026.02
Karpathy, "agentic engineering" 명명. 바이브 코딩의 한계를 인정하고, 설계 중심의 에이전트 오케스트레이션을 제안한다.

바이브 코딩은 사라지지 않았다. 프로토타입, 해커톤, 사이드 프로젝트에서는 여전히 유효하다. 하지만 진짜 프로젝트로 넘어가는 순간, 벽에 부딪힌다. 데이터가 말해준다.

1.7x

AI 코드의 이슈 발생 배율

CodeRabbit 2025

45%

AI 코드의 보안 결함률

Veracode 2025

2.74x

AI 코드 취약점 발생 배율

Veracode 2025

75%

AI 답변을 신뢰하지 못해 사람을 찾는 개발자

Stack Overflow 2025

네 가지 지표가 같은 이야기를 한다. AI가 만드는 코드는 빠르지만 위험하고, 그 위험을 인간이 일일이 걸러내고 있다. 빠르게 만들수록, 느리게 끝나는 역설이 발생한다.

AI가 코드를 생성하는 속도가 인간이 코드를 이해하는 속도를 추월했다. 이것이 이해 부채다.

Comprehension Debt — 2026

Part II — The Bottleneck

코드 리뷰의 한계

전통적인 코드 리뷰는 인간이 인간의 속도로 만든 코드를 검수하는 시스템이다. 하루에 PR 2~3개, 변경 사항 수백 줄. 합리적인 리듬이었다. AI가 코드를 쓰기 시작하면서, 이 리듬이 깨졌다.

Boris Cherny(Claude Code 창시자)는 두 달 넘게 PR의 100%를 AI로 작성했다. 30일간 259개 PR, 497 커밋, 4만 줄 추가 — 전부 Claude가 썼다. 리뷰어 한 명이 감당해야 할 코드량은 급증했지만, 리뷰어가 하루에 읽을 수 있는 양은 변하지 않았다.

Before — Human Pace

기존 워크플로우

개발자가 코드 작성 (시간~일)
PR 제출, 리뷰 요청
리뷰어가 코드 읽기 (30분~2시간)
피드백, 수정, 머지
속도 제한: 인간의 코딩 속도

리뷰 비용 = 코딩 시간의 일부

After — AI Pace

AI 속도 워크플로우

AI가 코드 생성 (초~분)
PR 10개 동시 제출
리뷰어가 AI 코드 읽기 (???)
이해 부채 누적
속도 제한: 인간의 이해 속도

리뷰 비용 > 코딩 시간 — 역전

Simon Willison의 황금률은 단순하다 — "설명 못 하는 코드는 커밋하지 않는다." 그런데 AI가 하루에 쏟아내는 코드를 전부 설명할 수 있는 개발자가 몇이나 될까.

코드 리뷰는 스케일하지 않는다. 개발자 한 명이 리뷰할 수 있는 코드량에는 물리적 한계가 있다. 그래서 다른 접근이 필요하다 — 리뷰 대신 검증. 코드 대신 테스트.

테스트 없는 에이전트는 블랙박스다.
테스트가 있는 에이전트는 도구가 된다.

Input설계서Specification

Guardrail테스트Test Suite

ExecutorAI 에이전트Agent

AGENTIC ENGINEERING

Verified Code

에이전틱 엔지니어링의 공식은 단순하다. 설계서가 AI의 방향을 정하고, 테스트가 AI의 결과물을 검증하고, 개발자는 이 루프를 감독한다. 코드는 마지막에 나오는 부산물이다.

Part III — The New Role

그래서 뭘 해야 하나

개발자의 역할이 바뀌고 있다. 코드를 치는 사람에서, 코드를 치기 전에 결정하는 사람으로. 에이전틱 엔지니어링 시대의 개발자에게는 세 가지 새로운 역할이 요구된다.

Role 01

아키텍트

시스템 구조를 설계하고, 기술 선택을 결정한다. AI가 코드를 쓰더라도, 설계 결정은 인간의 몫이다.

Role 02

테스트 설계자

AI가 생성한 코드를 검증할 테스트를 설계한다. 무엇을 테스트할지 결정하는 것이 코드를 쓰는 것보다 가치 있다.

Role 03

감독자

AI 에이전트의 워크플로우를 설계하고, 에이전트 간 오케스트레이션을 관리한다. 지침, 규칙, 가드레일을 작성한다.

Addy Osmani가 핵심을 짚었다. "에이전트가 코드를 읽고 스스로 알아낼 수 있는 건가? 그렇다면 문서에서 삭제하라." 반대로 말하면, AI가 스스로 알아낼 수 없는 것 — 프로젝트의 맥락, 아키텍처 결정, 테스트 전략 — 이 개발자가 관리해야 할 진짜 자산이다.

흔한 착각 3가지

AI가 좋아지면 테스트는 필요 없어진다? — 모델 성능이 올라가도 환각은 0이 되지 않는다. 존재하지 않는 메서드를 호출하고, 해피 패스만 통과하는 코드를 자신있게 내놓는다. 테스트는 보험이 아니라 필수다
큰 프로젝트도 바이브 코딩으로 된다? — 컨텍스트 윈도우 안에 전부 들어가면 된다. 코드베이스가 그 한계를 넘는 순간, AI는 자기가 이전에 쓴 코드도 잊어버린다. 문서화된 설계가 없으면 일관성이 붕괴한다
코드를 읽지 않아도 된다? — Simon Willison의 원칙은 여전히 유효하다. 이해하지 못한 코드는 머지하지 않는다. AI가 산출물을 만드는 방법이 달라질 뿐, 이해의 책임은 사라지지 않는다

이 시리즈는 "코드를 치기 전에" 해야 할 일을 다룬다. 어떤 방법론을 선택하고, 어떤 문서를 작성하고, 어떤 테스트를 설계하고, 어떻게 스케일링하는지. 5편에 걸쳐 하나씩 풀어간다.

시리즈 로드맵

코드를 치기 전에 벌어지는 일

바이브 코딩의 한계, 에이전틱 엔지니어링의 등장, 개발자의 새 역할. 지금 읽고 있는 글이다.

why — paradigm shift

SDD vs DDD — 어떤 방법론이 맞나

Spec-Driven Development와 Document-Driven Development 비교. 프로젝트 규모별 선택 기준과 복붙 설정 프롬프트.

what — methodology

설계서가 곧 코드다

CLAUDE.md 작성법, 폴더 구조, 에이전트 설계. 복붙으로 프로젝트 세팅을 완성하는 프롬프트 5개.

how — setup

테스트가 진짜 코드다

TDAID(Test-Driven AI Development), 에이전트 검증 루프, 교차 리뷰. 테스트를 먼저 쓰는 AI 개발 워크플로우.

how — verification

100줄에서 10만줄까지

3-Tier 컨텍스트 아키텍처, 코드베이스 최적화, Agent Teams. 프로젝트 규모별 올인원 설정 프롬프트.

scale — architecture

내 프로젝트의 AI 코드 리스크를 진단하고 싶다면

아래 프롬프트를 Claude나 ChatGPT에 붙여넣으세요. 대괄호 [ ] 안의 내용을 자신의 환경에 맞게 수정하세요.

내 프로젝트의 AI 코딩 리스크를 진단해줘. 프로젝트 정보: - 언어/프레임워크: [예: TypeScript + Next.js / Python + FastAPI / Java + Spring Boot] - 코드베이스 규모: [예: ~5,000 LoC / ~50,000 LoC / ~200,000 LoC] - AI 코딩 도구: [예: Claude Code / Cursor / GitHub Copilot] - 팀 규모: [예: 1명 / 5명 / 20명] - 테스트 커버리지: [예: 없음 / 30% / 80%] - 문서화 수준: [예: README만 / CLAUDE.md 있음 / 상세 스펙 문서] 진단 항목: 1. 이해 부채 리스크 — AI 생성 코드 중 설명 못 하는 비율 추정 2. 보안 리스크 — OWASP Top 10 중 이 스택에서 흔한 취약점 3. 스케일링 리스크 — 코드베이스가 2배 커질 때 예상 문제 4. 코드 리뷰 병목 — 현재 리뷰 프로세스의 한계점 5. 테스트 갭 — 커버되지 않는 영역 출력: 리스크 등급(상/중/하) + 각 항목별 구체적 개선 액션 3개씩

바이브 코딩에서 에이전틱 엔지니어링으로 전환하고 싶다면

아래 프롬프트를 AI에 붙여넣으세요. 현재 상태를 입력하면 단계별 전환 로드맵을 받을 수 있습니다.

내 개발 워크플로우를 바이브 코딩에서 에이전틱 엔지니어링으로 전환하는 로드맵을 만들어줘. 현재 상태: - 주로 사용하는 AI 도구: [예: Claude Code / Cursor / Copilot] - 현재 워크플로우: [예: "아이디어 → 바로 AI에게 코드 요청 → 에러 수정 반복" / "간단한 설계 후 AI 코딩"] - 프로젝트 성격: [예: 사이드 프로젝트 / 팀 서비스 / 엔터프라이즈] - 가장 큰 고민: [예: "AI 코드 품질 불안" / "프로젝트가 커지면 AI가 맥락을 잃음" / "테스트가 없어서 불안"] 4단계 전환 로드맵을 만들어줘: 1단계 — 문서 먼저 (1주) CLAUDE.md 또는 프로젝트 규칙 파일 생성 기존 코드에서 아키텍처 결정 문서화 2단계 — 테스트 먼저 (2주) 핵심 모듈에 테스트 추가 새 기능은 테스트 → AI 구현 순서로 3단계 — 스펙 먼저 (2주) 기능 요청을 스펙 문서로 작성 스펙 → 태스크 분해 → AI 구현 → 테스트 검증 루프 4단계 — 에이전트 설계 (지속) 서브에이전트 정의, 워크플로우 자동화 코드 리뷰 → 테스트 자동 검증으로 전환 각 단계에서: - 구체적 액션 아이템 3개 - 예상 시간 - 성공 기준 (이 지표가 나오면 다음 단계로) - 흔한 함정과 회피 방법 출력: 주차별 실행 계획 + 각 단계 완료 체크리스트

바이브 코딩, 그 다음

코드 리뷰의 한계

그래서 뭘 해야 하나

아키텍트

테스트 설계자

감독자

코드를 치기 전에 벌어지는 일

SDD vs DDD — 어떤 방법론이 맞나

설계서가 곧 코드다

테스트가 진짜 코드다

100줄에서 10만줄까지

코드는 마지막이다설계와 테스트가 먼저다

코드는 마지막이다
설계와 테스트가 먼저다