Table of contents
- Karpathy가 자기가 만든 단어를 폐기했다
- Vibe coding이 풀었던 것
- 1년 동안 드러난 함정
- Karpathy의 두 단어 — Specification vs Verification
- Agentic engineering의 실제 작동
- ”이해를 outsource할 수는 없다”
- 코딩 속도에서 판단의 깊이로
Karpathy가 자기가 만든 단어를 폐기했다
Andrej Karpathy(OpenAI 공동 창립자, 전 Tesla AI 디렉터)가 vibe coding이라는 단어를 만든 건 정확히 2025년 2월이었다. 자기 X(트위터) 글 한 줄에서 시작했다.
“You fully give in to the vibes, embrace exponentials, and forget that the code even exists.”
그 1년 뒤 — 2026년 2월 Sequoia AI Ascent 2026 무대에서 — 그가 같은 단어를 passé(한물 갔다)라고 선언했다. 새로운 자리는 agentic engineering이라고 이름 붙였다.
쉽게 말해, AI에게 요청하고 결과를 그대로 받는 시대가 1년 만에 AI가 만든 코드를 사람이 책임 있게 운영하는 시대로 넘어가고 있다는 선언이다. 같은 사람이 같은 무대 격에서 자기 말을 뒤집은 건 흔한 일이 아니다 — 그래서 이 전환은 기술 트렌드의 일반적인 진동이 아니라 paradigm 자체가 한 칸 옮겨갔다는 신호로 읽힌다.
Vibe coding이 풀었던 것
먼저 vibe coding이 왜 그렇게 빠르게 퍼졌는지부터 본다. Karpathy의 다음 한 줄이 그 본질을 압축한다.
“I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.”
코드를 읽지 않고 받아들이는 워크플로우다. diff를 한 줄씩 검토하지 않고 전부 accept, 버그가 나면 고치는 게 아니라 우회하는 식이다. 이 거친 흐름이 한 가지를 결정적으로 풀었다 — 소프트웨어를 만드는 사람의 정의를 넓혔다.
“Vibe coding raises the floor. It lets almost anyone create software by describing what they want.”
2026년 시점의 데이터가 이 말을 뒷받침한다. State of vibe coding 2026 보고서에 따르면:
- 92% 의 미국 개발자가 매일 AI 코딩 도구를 쓴다
- 46% 의 새 코드가 AI 생성이다
- 63% 의 vibe coder가 non-developer다
- Y Combinator Winter 2025 스타트업 중 21% 의 코드베이스가 91% 이상 AI 생성
소프트웨어를 만들 수 있는 사람의 풀이 한 자릿수 배수로 늘었다. 이 부분은 vibe coding이 분명히 풀었고, 그 가치는 사라지지 않는다.
1년 동안 드러난 함정
같은 보고서의 다른 절반이 vibe coding의 한계를 보여준다.
품질 지표 (1년 누적)
- AI 생성 코드의 45% 가 OWASP Top-10 취약점을 포함
- AI 공저 코드가 인간 작성 코드보다 1.7배 많은 major issue
- 코드 churn(재작성률) 41% 증가, 코드 중복 4배 증가
- Refactoring 비율 25% (2021) → 10% 미만 (2024)
- 개발자 63% 가 AI 코드 디버깅에 직접 작성보다 더 시간을 쓴다고 응답
신뢰도 그래프도 거꾸로 가고 있다.
신뢰의 후퇴
- AI 도구에 대한 호감도: 77% (2023) → 60% (2026)
- AI 코드 정확도 신뢰: 43% (2024) → 33% (2026)
가장 인상적인 건 METR 연구의 생산성 역설이다.
AI를 쓰는 개발자가 실제로는 19% 더 느렸다. 본인들은 20% 더 빠르다고 믿었다.
체감과 측정이 정반대다. vibe 자체가 잘못된 신호를 줬다는 의미다. 시장에 드러난 사고들도 같은 결을 가진다 — Replit이 사용자 DB를 통째로 날린 사건, Lovable이 생성한 앱 10% 이상에서 개인정보 노출, Enrichlead의 유지 불가능한 코드베이스 붕괴.
문제의 근원은 코드를 모르는 채 코드를 쌓는 것이다. 처음 한두 달은 작동한다. 그러나 오류·취약점·기술 부채가 지수적으로 누적되고, 어느 시점부터 사람이 그걸 풀어낼 능력이 없어진다.
Karpathy의 두 단어 — Specification vs Verification
Karpathy가 Sequoia 발표에서 가장 중요하게 짚은 개념적 분기점이 있다. AI가 무엇을 잘하고 무엇을 못하느냐를 정확하게 가르는 두 단어다.
“Traditional software automates what you can specify in code.
LLMs and reinforcement learning automate what you can verify.”
flowchart LR
classDef spec fill:#4a90d9,color:#fff,stroke:#2c5d8f
classDef verify fill:#5ca45c,color:#fff,stroke:#3d7a3d
A[전통 소프트웨어]:::spec --> A1["Specify할 수 있는 것을 자동화<br/>(if X then Y)"]
B[LLM·RL]:::verify --> B1["Verify할 수 있는 것을 자동화<br/>(결과를 채점할 수 있는 영역)"]이 구분이 왜 중요한가. Verify가 가능한 영역(코드, 수학, 테스트 — 답이 맞는지를 기계가 즉시 확인할 수 있는 자리)에서는 LLM이 빠르게 강해진다. 거기선 agent가 수십 번 시도하고 평가받으며 자기 답을 다듬는 강화학습 루프가 작동한다.
반대로 Verify가 모호한 영역(아키텍처, 도메인 결정, 사용자 경험, 보안 모델, 시스템 경계) — 답이 맞는지를 즉시 채점할 수 없는 자리에서는 LLM이 평탄하게 강하지 않다. Karpathy는 이걸 jagged intelligence(들쭉날쭉한 지능)라고 부른다.
“Agents aren’t smoothly capable everywhere. They spike in heavily-trained domains and behave strangely in others.”
Vibe coding은 모든 영역을 verify-able한 것처럼 다룬 실수다. 코드 한 줄 한 줄은 verify할 수 있지만, 시스템 전체가 올바른가는 verify되지 않는다.
Agentic engineering의 실제 작동
여기서 agentic engineer의 자리가 정의된다. Karpathy의 말로 옮기면 이렇다.
“The agentic engineer does not blindly accept generated code.
They design specs, supervise plans, inspect diffs, write tests, create evaluation loops, manage permissions, isolate worktrees, and preserve quality.”
flowchart TB
classDef vc fill:#c0392b,color:#fff,stroke:#7d1f15
classDef ae fill:#5ca45c,color:#fff,stroke:#3d7a3d
subgraph V["Vibe coding (2025)"]
direction TB
V1["요청 → 결과 → accept all"]:::vc
V2["diff 안 읽음"]:::vc
V3["테스트 없이 다음 단계"]:::vc
V4["권한 격리 없음"]:::vc
end
subgraph A["Agentic engineering (2026)"]
direction TB
A1["spec 작성 (의도 명시)"]:::ae
A2["plan 검토 (실행 전)"]:::ae
A3["diff 검사 (실행 후)"]:::ae
A4["test + eval 루프"]:::ae
A5["worktree·권한 격리"]:::ae
end
V --> A여섯 가지 실천이 핵심이다.
1. Spec을 먼저 쓴다. 코드를 부르기 전에 의도·제약·성공 조건을 한두 페이지로 적는다. agent가 이 spec 위에서 plan을 세운다. 사람이 plan을 코드로 옮기기 전에 검토한다.
2. Plan을 실행 전에 검토한다. Claude Code의 plan 모드 같은 게 정확히 이 자리다. agent가 무엇을 어떻게 할지 먼저 보여주고, 사람이 이걸 진행해도 되는지 결정한다.
3. Diff를 한 줄씩 본다. agent가 만든 변경을 전부 accept하지 않는다. 안 보인 줄은 안 본 거다. 코드를 읽지 않으면 그 코드는 자기 코드가 아니다.
4. Test와 eval 루프를 만든다. agent의 작업이 맞는지를 기계가 채점할 수 있는 자리를 만든다. 이게 agentic engineering의 verify 측면이다 — agent의 출력이 회귀하지 않는지를 매번 자동으로 본다. 89%의 production agent 팀이 observability를 도입했고, 52%가 evals를 운영한다.
5. Worktree를 격리한다. agent가 작업하는 자리를 사용자의 작업 환경과 분리한다. git worktree, 컨테이너, 별도 브랜치 — agent의 실수가 사람의 in-progress 작업을 망가뜨리지 못하게 한다.
6. 권한을 명시적으로 관리한다. agent가 무엇을 읽을 수 있고·쓸 수 있고·실행할 수 있는지를 사전에 정한다. Claude Code의 permission 모드, MCP 서버의 capability negotiation이 이 자리에 있다.
이 여섯 가지가 vibe coding과 agentic engineering의 실질적인 차이다. 작업 시간은 비슷하거나 약간 더 늘어나지만, 코드 품질의 산포가 줄고 디버깅 시간이 폭발하지 않는다.
”이해를 outsource할 수는 없다”
Agentic engineering의 가장 중요한 원칙은 기술적 실천이 아니라 인지적 입장이다. Karpathy의 표현이 가장 정확하다.
“You can outsource your thinking, but you can’t outsource your understanding.”
생각의 실행은 agent에게 맡길 수 있다. 그러나 왜 그 결정인지·언제 그게 무너지는지·어떤 trade-off가 깔려 있는지에 대한 이해는 사람이 가져야 한다. Karpathy가 든 MenuGen 예시가 이걸 잘 보여준다.
agent가 사용자 결제 흐름을 짜면서 Stripe 결제와 Google 계정을 이메일로 매칭하는 코드를 만들었다. 코드 자체는 작동한다. 그런데 이메일 매칭은 sub 식별자가 아니다 — 사용자가 이메일을 바꾸면 결제 이력이 끊긴다. 이건 코드 버그가 아니라 시스템 설계의 결함이다.
“A human needs enough product and engineering judgment to insist on persistent user IDs.”
이런 결정은 코드를 읽어서 발견되는 게 아니다. 시스템이 어떻게 진화할지에 대한 직관에서 발견된다. 그 직관은 학습으로 쌓이는 것이라 agent에 위임할 수 없다.
같은 결로 Karpathy가 던진 마무리 한 줄이 글의 핵심이다.
“The best agentic engineers will outperform the best traditional engineers by more than 10x — not because they type less, but because they understand more.”
10배 차이는 코드를 더 빨리 쳐서가 아니다. 시스템을 더 깊이 이해하고, 그 이해를 agent의 작업에 정확히 투영해서 만들어진다. 이게 vibe coding의 대체가 아니라 위로 한 단 올라간 자리인 이유다.
코딩 속도에서 판단의 깊이로
엔지니어링 리더 입장에서 이 전환이 의미하는 게 둘 있다.
채용·평가 기준의 이동. 얼마나 빨리 코드를 쓰는가는 점점 의미가 줄어든다. 그 자리를 얼마나 정확히 spec을 쓰고, plan을 검토하고, eval을 설계하고, agent의 출력을 판단하는가가 메운다. 시니어와 주니어의 격차가 코딩 속도에서 판단의 깊이로 옮겨간다.
조직 도구의 재정비. Vibe coding 시기엔 Cursor·Claude Code·Copilot 같은 IDE 통합이 주역이었다. Agentic engineering 시기엔 spec 도구, plan 검토 UI, eval 플랫폼(LangSmith, Galileo, Braintrust 등), worktree 격리 도구가 같이 들어온다. 도구 스택이 한 번 더 두꺼워진다.
개인 개발자 입장에서 가장 빠른 변화는 daily 워크플로우에 들어가는 새 단계들이다. Plan 모드 한 번 쓰는 것, diff를 한 줄씩 검토하는 것, eval을 글마다 한 번 돌리는 것 — 한두 주만 의식적으로 하면 손에 붙는다.
Karpathy의 1년 전 vibe는 환영이 아니었다. 시장의 진짜 신호였고, 1년 만에 그 신호의 한계가 드러났을 뿐이다.
Sources:
Loading comments...