하네스 엔지니어링 — 바이브 코딩에서 에이전틱 코딩으로
Karpathy의 “바이브 코딩은 바닥을, 하네스 엔지니어링은 천장을 올린다”는 명제를 출발점으로, 2026년 왜 harness-engineering이 핵심 역량인지 큰 그림을 정리한 7분짜리 개론 영상.
핵심 요약
- 2025년 = 에이전트의 해, 2026년 = 하네스의 해, 2027년 = 에이전트가 스스로 하네스를 만드는 해라는 단계론.
- 프롬프트 엔지니어링이 “잘 해줘”라는 부탁이라면, 하네스 엔지니어링은 “잘 할 수밖에 없는 구조”를 만드는 일.
- 도구는 적을수록 좋다 — 선택지 과잉은 에이전트의 집중력을 빼앗는다 (넷플릭스 30분 고민 비유).
- 검증 자동화 (테스트 + 에이전트 간 상호 리뷰)가 하네스의 동력. 사람은 최종 판단만.
- “생각은 아웃소싱 할 수 있다. 하지만 이해는 아웃소싱 할 수 없다.” — Karpathy 인용.
IDEAS
- 바이브 코딩은 모든 사람의 바닥을 올렸지만, 하네스 엔지니어링은 천장을 올린다.
- OpenAI 엔지니어는 하루 10억 토큰을 쓰면서 코드를 한 줄도 치지 않는다.
- IBM 엔지니어는 “2026년은 하네스의 해”라고 컨퍼런스에서 선언했다.
- 2025년은 에이전트가 코드를 쓸 수 있다는 걸 증명한 해, 2026년은 그 에이전트를 통제·신뢰하는 해.
- 2027년에는 에이전트가 작업 요청을 받으면 스스로 하네스를 설계하고 검증까지 끝낸 결과를 돌려줄 것.
- 지금은 정확히 그 사이 — 에이전트는 충분히 강력한데 하네스는 사람이 직접 만들어야 하는 시점.
- 하네스를 직접 설계할 수 있는 사람과 그저 AI에 해달라고 하는 사람 사이의 격차는 점점 벌어진다.
- Software 1.0 = 직접 코드, 2.0 = 데이터로 모델 학습, 3.0 = 프롬프트가 곧 프로그래밍.
- 코드를 만드는 건 어렵지 않다 — 진짜 문제는 그 코드가 “쓸 만한지” 검증하는 일.
- 프롬프트 엔지니어링은 모델에게 잘 해 줘라고 부탁하는 것, 하네스 엔지니어링은 잘 할 수밖에 없는 구조를 만드는 것.
- Claude Code 자체도 Anthropic이 설계한 하네스 안에서 동작한다 — MCP 추가·스킬·훅 설정도 사실 하네스 설계였다.
- 에이전트는 도구가 많으면 어떤 도구를 쓸지 고민에 에너지를 써서 정작 일에 집중을 못한다.
- “요즘 좋더라”하는 스킬을 다 설치했더니 Claude Code가 이상해졌다면 다 지우고 핵심만 남겨라.
- 가장 쉬운 검증 자동화는 테스트 — 에이전트가 코드를 짰으면 테스트 통과 여부를 자동 확인.
- 한 단계 더 나아가면 에이전트가 에이전트의 결과를 리뷰 — Claude Code + Codex 조합이 그 예.
- 자동 리뷰가 돌면 사람은 최종 판단만 하면 된다 → 한번 세팅해 두면 연속적으로 돌아가는 것이 하네스의 힘.
- 프롬프트는 채팅창만이 아니다 — 폴더 구조, 파일 이름, 코드 스타일이 전부 프롬프트다.
- 일관된 프로젝트 구조 = 일관된 새 코드. 지저분한 프로젝트 = 지저분한 새 코드.
- 좋은 하네스를 만드는 건 프로젝트 전체를 하나의 거대한 프롬프트로 만드는 것.
- 환불·결제 수수료 같은 구조적·설계적 판단은 여전히 인간의 영역.
- 하네스 엔지니어링의 본질 = 잘하는 실행은 에이전트에, 못하는 판단은 환경에서 잡아주기.
- “생각은 아웃소싱 할 수 있지만, 이해는 아웃소싱 할 수 없다” — 코드는 AI가 짜도, “왜 이 구조여야 하는가”는 사람이 이해해야 한다.
INSIGHTS
- 2025→2026→2027 단계론은 단순한 트렌드 예측이 아니라 “사람이 어디까지 손에서 놓을 수 있느냐”의 단계로 읽힌다. 2026년에 하네스 역량을 쌓아야 2027년 자가 하네스 시대에 환경을 설계할 줄 아는 사람으로 남는다.
- 부탁 vs 구조 프레이밍은 Prompt-Engineering과 harness-engineering의 차이를 가장 직관적으로 설명한다. 프롬프트는 매번 개입을 요구하지만, 하네스는 개입 횟수 자체를 줄이는 것이 목표.
- “도구는 적을수록 좋다”는 Thin-Harness-Fat-Skills 원칙과 같은 결 — 단, 그 안에서도 핵심 스킬은 강화하라는 점에서 단순 미니멀리즘과는 다르다.
- 에이전트-간 상호 리뷰(Claude Code + Codex)는 Agentic-Engineering의 실용적 단위 패턴. “다른 모델 검증 게이트”가 마지막 사람 개입을 대체할 수 있는 가장 즉시 적용 가능한 하네스 포인트.
- “프로젝트 전체가 프롬프트”라는 시각은 AI-컨텍스트-동기화·AI-인물-일관성과 같은 결의 일관성 원칙을 코드베이스 전체로 확장한 것.
- Karpathy의 “이해는 아웃소싱 할 수 없다”는 AI를-선생님으로-쓰는-학습법과 정확히 맞물린다 — AI가 결과물을 만들수록 이해 자체에 대한 사람의 책임은 오히려 커진다.
QUOTES
“바이브 코딩은 모든 사람의 바닥을 올려 주는 거고 에이전틱 엔지니어링은 천장을 올리는 겁니다.” — Karpathy 인용
“오픈AI 엔지니어는 하루에 10억 토큰을 쓰면서 코드를 한 줄도 안 친다고 말했고, IBM 엔지니어는 컨퍼런스에서 2026년은 하네스의 해라고 선언했습니다.”
“프롬프트 엔지니어링은 모델에게 ‘잘 해 줘’라고 부탁하는 거고 하네스 엔지니어링은 ‘잘 할 수밖에 없는 구조’를 만드는 겁니다. 부탁과 구조 — 이 차이가 핵심입니다.”
“잘 정리된 방에서 일하면 일이 잘되고 어지러운 방에서 일하면 일이 안 되는 것. 에이전트도 똑같습니다.”
“생각은 아웃소싱 할 수 있다. 하지만 이해는 아웃소싱 할 수 없다.” — Karpathy 인용
“바이브 코딩으로 코드를 만드는 건 이제 누구나 하지만, 하네스를 이해하는 사람이 진짜 결과를 만들 겁니다.”
REFERENCES
- andrej-karpathy (person) — “바닥/천장” 비유, Software 1.0/2.0/3.0, “이해는 아웃소싱 할 수 없다” 인용 출처
- openai (org) — “하루 10억 토큰” 엔지니어 사례
- IBM (org) — “2026년은 하네스의 해” 컨퍼런스 선언
- anthropic (org) — Claude Code 하네스 설계 주체
- claude-code (tool) — 대표적 하네스 사례
- cursor (tool)
- openai-codex (tool) — Claude Code와 함께 쓰는 상호 리뷰 조합
- Jay-Choi-인디해커-라이프 (channel) — 영상 진행자
FACTS
- 영상 길이: 6분 58초 (418초)
- 업로드: 2026-05-20
- OpenAI 엔지니어 1인 하루 토큰 사용량 = 10억 토큰 (인용)
- 카파시가 “바이브 코딩”이라는 단어를 만든 시점 = 2025년 (영상 시점 기준 “작년”)
- Software 1.0 (코드 작성) → 2.0 (모델 학습) → 3.0 (프롬프트 = 프로그래밍) 단계 구분
- 2025 = 에이전트의 해, 2026 = 하네스의 해, 2027(예측) = 에이전트가 스스로 하네스를 만드는 해
HABITS / RECOMMENDATIONS
- “요즘 좋다”는 스킬을 무작정 다 설치하지 말고, 지금 작업에 필요한 것만 남겨라. 핵심 스킬 몇 개를 강화하는 것이 낫다.
- 에이전트가 코드를 짰으면 테스트 자동 실행 → 통과 확인까지를 하네스 안에 포함시켜라.
- Claude Code + Codex처럼 다른 모델/에이전트가 결과를 상호 리뷰하게 하라 — 사람은 최종 판단만.
- 프로젝트의 폴더 구조·파일 이름·코드 스타일을 일관되게 유지하라 — 이것이 곧 프롬프트다.
- 작업 중간중간 사람이 자주 개입해야 한다면 → “아직 하네스가 부족하다”는 신호.
- 결제 수수료·환불 같은 구조적/설계적 결정은 AI에 위임하지 마라. “왜 이 기능이 필요한가”는 사람의 이해 영역.