본문 바로가기

AI Development

Vibe Coding은 끝났다 — Karpathy가 선언한 Agentic Engineering 시대

반응형

2025년 2월, Andrej Karpathy가 트위터에 이런 글을 올렸어요.

"AI한테 코드 짜달라고 하고, 에러 나면 에러 붙여넣고, 다시 돌려보는 새로운 코딩 방식이 있어. Vibe Coding이라고 부를게."

개발자들이 열광했어요. AI한테 다 맡기고 그냥 돌아가면 됐으니까요.

그리고 딱 1년 후인 2026년 2월, Karpathy가 다시 말했어요.

"Vibe Coding은 이제 구식이야. 진짜 프로들은 Agentic Engineering을 해."


Vibe Coding이 뭐가 문제였나

Vibe Coding 방식:
1. "로그인 기능 만들어줘"
2. AI가 코드 생성
3. 돌아가면 OK, 에러 나면 에러 붙여넣기
4. 반복
5. 프로덕션 배포

문제:
- 코드 이해 없이 배포
- 보안 취약점 모름
- 아키텍처 일관성 없음
- 나중에 수정 불가능한 기술 부채

Stanford + MIT 연구(2026년 3월)에서 AI 생성 코드의 14.3%에 보안 취약점이 있다고 밝혔어요. Vibe Coding으로 빠르게 만든 앱들이 해킹당하기 시작했어요.


Agentic Engineering이 뭔가

Karpathy의 정의예요.

"99%의 시간 동안 코드를 직접 짜지 않는다. AI 에이전트들이 짜고, 나는 그걸 감독하는 오케스트라 지휘자다."

Vibe Coding:
개발자 → AI → 코드 → 그냥 배포

Agentic Engineering:
개발자(아키텍트/감독자)
    ↓ 명세/목표 제시
AI 에이전트들(구현자)
    ↓ 코드 생성 + 테스트
개발자(리뷰어)
    ↓ 검토 + 승인
배포

핵심 차이는 개발자의 역할이에요. 코드를 짜는 사람이 아니라 에이전트를 지휘하는 사람이 돼요.


Karpathy의 워크플로우 변화

2024년: 코드 80% 직접 작성, 20% AI 도움
2025년 12월: 뭔가 flip됨
2026년 현재: 코드 20% 직접 작성, 80% 에이전트 위임

그가 말한 핵심이에요.

"12월에 뭔가 뒤집혔어. 코드 직접 짜는 비율이 80:20에서 20:80으로 바뀌었고 계속 바뀌는 중이야."


실전 Agentic Engineering 워크플로우

1단계 — 스펙 먼저 (코드 없이)

# payment-cancel.spec.md

## 목표
결제 취소 API 구현

## 요구사항
- POST /payments/:id/cancel
- 취소 가능 조건: 결제 후 24시간 이내, COMPLETED 상태만
- 재고 롤백 필수 (트랜잭션)
- 환불 처리: 외부 PG사 API 호출
- 실패 시: 취소 상태 FAILED로 업데이트, 재고 롤백 없음

## 금지사항
- 24시간 초과 취소 시도: 400 에러
- 이미 취소된 건 재취소: 409 에러

## 테스트 케이스
1. 정상 취소
2. 24시간 초과 취소 시도
3. PG사 API 실패 시 롤백 확인

Vibe Coding은 이 단계를 건너뛰어요. Agentic Engineering은 여기서 시작해요.


2단계 — 에이전트에게 위임

나: "payment-cancel.spec.md 읽고 구현해줘.
     Repository → Service → Route → Test 순서로.
     각 단계 완료 후 보고해줘."

Claude: (스펙 읽기)
→ Repository 구현 완료. 확인해줘.
나: (리뷰) ㅇㅇ 진행해
→ Service 구현 완료. 특이사항: PG사 API 타임아웃 처리 추가함.
나: (리뷰) 타임아웃은 3초로 줄여줘
→ 수정 완료. Route 구현 시작할게.

에이전트가 구현하고, 나는 검토만 해요.


3단계 — 리뷰는 진짜로

Agentic Engineering에서 코드 리뷰가 제일 중요해요.

Vibe Coding 리뷰: "돌아가네? ㅇㅋ"

Agentic Engineering 리뷰:
□ 이 코드가 뭘 하는지 내가 설명할 수 있나?
□ 스펙에 명시된 모든 케이스 처리됐나?
□ 에러 처리가 적절한가?
□ 보안 취약점 없나?
□ 테스트가 실제 동작을 검증하나?

설명 못하면 → 배포 안 함

Google Chrome의 Addy Osmani가 말했어요.

"어떤 모듈이 뭘 하는지 설명 못하면 그 코드는 넣으면 안 된다."


4단계 — 자동 검증 파이프라인

에이전트가 많이 짤수록 검증도 자동화해야 해요.

# 모든 PR에 자동 실행되는 파이프라인

stages:
  1. 타입 체크 (TypeScript)
  2. Lint
  3. 단위 테스트
  4. 보안 스캔 (SAST)
  5. 통합 테스트
  6. E2E 테스트 (Playwright MCP)

모두 통과해야 머지 가능
→ 에이전트가 1000개 PR 만들어도 검증은 자동

Karpathy가 말한 핵심 원칙들

1. 토큰 처리량이 곧 속도

나쁜 방식:
에이전트 A 완료 → 에이전트 B 시작 → 에이전트 C 시작
(순차적)

좋은 방식:
에이전트 A + B + C 동시 실행
(Git Worktrees 활용)

"아이들 토큰은 기회 낭비다"

2. 매크로 액션으로 위임

나쁜 위임:
"getUser 함수 만들어줘"
"이제 validateUser 만들어줘"
"이제 updateUser 만들어줘"

좋은 위임:
"유저 관리 모듈 전체 만들어줘.
 CRUD + 검증 + 에러 처리 + 테스트 포함"

작은 단위로 쪼개면 오히려 비효율이에요.

3. 검증 가능한 목표 설정

나쁜 목표:
"결제 기능 만들어줘"

좋은 목표:
"결제 기능 만들어줘.
 완료 조건:
 - pnpm test 전부 통과
 - 결제 성공/실패 시나리오 E2E 테스트 통과
 - TypeScript 에러 없음"

에이전트가 스스로 완료 여부를 판단할 수 있어야 해요.


Vibe Coding vs Agentic Engineering 한눈에 비교

Vibe Coding Agentic Engineering

스펙 없음 먼저 작성
코드 리뷰 대충 철저하게
테스트 나중에 자동화 필수
보안 나중에 빌드인
적합한 상황 프로토타입, 해커톤 프로덕션
결과물 빠르지만 불안정 조금 느리지만 안정적

2026년 현실

Zapier: 전체 조직 89% AI 채택
TELUS: 13,000개 AI 솔루션으로 50만 시간 절감
Stripe: 에이전트가 주당 1,000개 PR 생성

공통점:
전부 Agentic Engineering 방식
→ 에이전트가 구현
→ 인간이 아키텍처 + 리뷰 + 품질 보증

내 워크플로우를 Agentic Engineering으로 바꾸는 법

지금 당장 할 수 있는 것:

1. CLAUDE.md에 프로젝트 스펙 완성
   (이미 했으면 OK)

2. 기능 구현 전에 .spec.md 파일 작성 습관 들이기

3. /feature 슬래시 커맨드에
   "스펙 파일 먼저 읽기" 추가

4. Git Worktrees로 병렬 에이전트 실행

5. Hooks로 자동 검증 파이프라인 구축

한 번에 다 할 필요 없어요. 하나씩 추가하면 돼요.


 

반응형