바이브 코딩의 스케일이 멈춘 순간
2025년 2월, Andrej Karpathy는 X에 농담처럼 보이는 글을 올렸습니다. 그는 "바이브 코딩"을 LLM이 내놓는 것을 제대로 읽지 않고 그대로 받아들이는 행위라고 묘사했습니다. "나는 그냥 뭔가를 보고, 뭔가를 말하고, 뭔가를 실행하고, 뭔가를 복사 붙여 넣을 뿐이다. 그런데 대체로 잘 돌아간다."
실제로 대체로 잘 돌아갔습니다. 약 1년 동안은요.
2025년 말이 되자 업계에 청구서가 도착하기 시작했습니다. 2025년에 발표된 Forrester 리서치는 AI가 상당 부분 관여한 코드가 주요 이슈 발생률이 약 1.7배에 달한다는 점을 발견했습니다. 보안 업체들의 별도 감사 결과, 프롬프트 스타일과 언어에 따라 AI 생성 코드의 보안 결함 비율은 40~62퍼센트로 나타났습니다. 모델은 존재하지 않는 API를 환각하고, 입력 검증을 건너뛰며, 로그에 비밀값을 흘리고, 실제로 존재하지 않는 함수를 자신만만하게 호출합니다.
무너진 것은 단일 프롬프트와 단일 컨텍스트 윈도우가 실제 코드베이스를 감당할 수 있다는 가정이었습니다. 레포는 더 커졌고, 컨벤션은 더 구체적이 됐습니다. 사이드 이펙트(마이그레이션, 배포, 유료 API 호출)는 더 위험해졌습니다. 그린필드 앱에서는 마법처럼 느껴졌던 워크플로가, 5년치 결정이 쌓인 서비스를 가리키는 순간 무너졌습니다.
균열은 세 가지 방식으로 드러났습니다. 모델이 세션 중간에 프로젝트 컨벤션을 잊어버리고, 팀이 몇 달에 걸쳐 지운 패턴을 다시 도입했습니다. 긴 세션에서는 무관한 컨텍스트가 너무 많이 쌓여서 모델이 실제 과제를 무시하기 시작했습니다. 에이전트는 아무도 막지 않으니 파괴적인 명령을 거리낌 없이 실행했습니다. "main에 푸시하지 말 것"이라는 프롬프트는 약 95퍼센트 작동했지만, 이는 곧 20번 중 1번은 실패했다는 뜻이기도 합니다.
2025년 말까지 Claude Code, Cursor, 또는 유사 도구를 진지하게 쓰는 모든 팀은 모델 주변에 동일한 형태의 스캐폴딩을 어떤 식으로든 직접 구축해 두었습니다. 다만 그 이름이 아직 없었을 뿐입니다.
Karpathy가 붙인 새 이름, 에이전틱 엔지니어링
2026년 2월, Karpathy가 다시 글을 올렸습니다. 새 용어는 "에이전틱 엔지니어링"이었습니다.
그는 바이브 코딩은 장난감 모드를 묘사한 것이었다고 말했습니다. 에이전틱 엔지니어링은 실제로 무언가를 출시하는 사람들이 하고 있는 일을 가리킵니다. 프로젝트 고유의 컨텍스트 파일을 작성하고, 좁은 범위의 스킬을 정의하고, 격리된 작업을 위한 subagent를 띄우고, 결정론적 hook으로 도구 사용을 통제하는 것입니다. 타이핑은 여전히 모델이 합니다. 인간은 모델이 작동하는 시스템을 설계하는 일을 합니다.
두 게시물 사이에 툴링이 성숙했습니다. Anthropic의 Claude Code Best Practices는 CLAUDE.md 컨벤션과 subagent 패턴을 문서화했습니다. Building Agents with the Claude Agent SDK는 에이전트 루프와 hook의 역할을 정리했습니다. Skills는 2025년 10월에 도착했습니다. 작은 마크다운 파일로, 작업이 트리거할 때만 에이전트가 로드합니다. Cursor 2.0은 클라우드 VM 위의 백그라운드 에이전트와 git-worktree 격리, 최대 여덟 개의 병렬 에이전트를 출시했습니다.
Martin Fowler의 "Context Engineering for Coding Agents"는 이 모든 것을 묶는 원칙을 포착했습니다. 더 이상 한 줄의 텍스트를 최적화하는 프롬프트 엔지니어링이 핵심이 아닙니다. 핵심은 컨텍스트 엔지니어링입니다. 모델이 무엇을, 언제 보고, 그 컨텍스트로 무엇을 할 수 있는지를 결정하는 일입니다.
이는 Anthropic만의 이야기가 아닙니다. Cursor는 이를 rules와 background agents라고 부릅니다. GitHub Copilot은 AGENTS.md 컨벤션을 사용합니다. Gemini CLI는 GEMINI.md를 사용합니다. 이름은 다릅니다. 형태는 같습니다.
에이전틱 엔지니어링의 네 기둥
각 기둥을 깊이 파고들기 전에, 나란히 놓고 보는 편이 도움이 됩니다. 비슷해 보이지만(모두 "에이전트에게 주는 무언가") 해결하는 문제가 다릅니다.
| 기둥 | 저장하는 것 | 로드 시점 | 없을 때의 실패 양상 |
|---|---|---|---|
| CLAUDE.md | 항상 참인 프로젝트 컨텍스트: 스택, 컨벤션, 명령어, 강한 규칙 | 모든 세션 시작 시 자동으로 | 모델이 컨벤션을 다시 만들어내고, 패키지 매니저를 잊으며, yarn 레포에서 npm install을 실행 |
| Skills | 좁은 범위의 절차적 지식(rebase, 스키마 마이그레이션, Stripe 리뷰) | 작업 설명이 스킬과 매칭될 때 온디맨드로 | 모델이 도메인 특화 단계를 즉흥적으로 구성해 순서를 틀림 |
| Subagents | 단일 역할을 위한 새로운 컨텍스트 윈도우와 시스템 프롬프트 | 메인 에이전트가 정의된 작업을 위임할 때 | 사이드 퀘스트가 메인 컨텍스트를 오염시키고, 한 번의 잘못된 도구 호출이 세션 전체를 망가뜨림 |
| Hooks | 도구 이벤트(PreToolUse, PostToolUse, Stop)에서 실행되는 셸 커맨드 | 트리거가 발생할 때마다 결정론적으로 | 위험한 명령이 통제 없이 실행되고, 포매터가 돌지 않으며, "항상 X 하라"는 프롬프트가 소리 없이 실패 |
패턴은 이렇습니다. CLAUDE.md는 모델이 알고 있는 것입니다. Skills는 모델이 찾아볼 수 있는 것입니다. Subagents는 모델이 도움을 청할 수 있는 또 다른 존재입니다. Hooks는 모델이 피할 수 없는 것입니다.
각 기둥은 나머지 셋이 해결할 수 없는 특정 실패 양상을 위해 존재합니다.
CLAUDE.md: 권고 레이어
CLAUDE.md(또는 도구에 따라 AGENTS.md, GEMINI.md)는 레포 루트에 있는 마크다운 파일입니다. 에이전트는 모든 세션 시작 시 이를 읽고 배경 컨텍스트로 다룹니다.
이것은 소비자 제품에서 말하는 의미의 메모리가 아닙니다. 인간인 당신이 작성하는 파일이며, 에이전트가 1년간 팀에 있었다면 자연스럽게 알게 됐을 내용을 담습니다.
여기에 들어갈 것:
- 스택과 버전: "Next.js 16 App Router, React 19, Yarn 1.22 (npm 금지), Node 22."
- 레포 레이아웃: 각 디렉터리가 무엇을 담당하는지.
- 명령어:
yarn dev,yarn test,yarn build:ci. 어떤 것을 안전하게 실행할 수 있는지 메모. - 강한 규칙: "절대
main에 직접 푸시하지 말 것. 항상 feature 브랜치를 만들 것." - 스타일 컨벤션: 탭 너비, 자주 걸리는 lint 룰, 네이밍 규칙.
- 도메인 단축어: 제품 고유의 용어집.
여기에 들어가지 말아야 할 것: 가끔 하는 작업의 단계별 지시(Skills로), 긴 레퍼런스 문서(모델이 대충 훑으므로 링크로 빼는 편이 낫습니다), 그리고 비밀값(CLAUDE.md 내용은 컨텍스트로 로드되며 컨텍스트는 다시 인용될 수 있습니다).
대부분의 팀이 빠지는 함정은 무엇이든 다 넣은 CLAUDE.md입니다. 모든 코딩 표준과 모든 아키텍처 결정을 담은 4,000줄짜리 파일. 모델은 매 작업마다 이를 전부 로드하고, 관련 있는 5퍼센트와 무관한 95퍼센트를 동등하게 다루기 시작합니다. 토큰 비용은 올라가고, 특정 규칙 준수율은 떨어집니다.
좋은 CLAUDE.md는 위키보다 포스트잇에 가깝습니다. 한 화면 분량의 핵심 컨텍스트를 목표로 하세요. "X를 할 때..."로 시작하는 섹션을 쓰고 있다면 그 X는 스킬로 빠져야 할 가능성이 큽니다. CLAUDE.md는 "항상 참"을 위한 것이고, Skills는 "특정 상황에서 참"을 위한 것입니다.
Skills: 적시 로딩되는 지식 파일
Skills는 작은 마크다운 파일(보통 200줄 미만)로, 작업과 매칭될 때만 에이전트가 로드합니다. 각 스킬에는 이름, 설명, 본문이 있습니다. 설명은 에이전트가 먼저 읽어서 전체 스킬을 끌어올지 결정하는 데 사용합니다.
Anthropic은 2025년 말에 Skills를 일급 개념으로 출시했습니다. 정해진 디렉터리에 스킬 파일을 넣어 두면, 프런트매터가 사용 시점을 설명합니다. 작업을 계획할 때 에이전트는 사용 가능한 스킬 설명을 스캔하고, 설명이 매칭되는 것을 로드합니다.
좋은 스킬 예시:
rebase-cleanly:develop에 rebase하는 방법, 충돌 해결 규칙, rebase 후 테스트가 깨졌을 때 할 일.review-stripe-integration: Stripe 웹훅, 멱등성 키, price ID를 건드리는 변경을 위한 체크리스트.add-shadcn-component: 이 레포에 shadcn/ui 컴포넌트를 추가하는 정확한 명령과 import 컨벤션.debug-flaky-test: CI 테스트가 간헐적으로 실패할 때 팀이 선호하는 작업 순서.
각각은 절차적이고 좁습니다. 각각은 CLAUDE.md에 담기에는 디테일이 너무 많지만, 모델의 일반 지식에 맡기기에는 너무 중요합니다.
멘탈 모델은 이렇습니다. CLAUDE.md는 첫 출근일에 신입에게 기초를 알려주는 동료입니다. 스킬은 새벽 2시에 Stripe 웹훅이 터졌을 때 신입에게 건네는 런북입니다. 런북을 외우지는 않습니다. 필요할 때 읽습니다.
Skills는 조합됩니다. 에이전트는 한 작업에서 세 개의 스킬을 한꺼번에 로드할 수 있습니다("새 API 라우트 추가" + "Zod로 입력 검증" + "Vitest 테스트 작성"). 조합을 미리 예측해 둘 필요가 없습니다.
스킬 설명은 생각보다 중요합니다. 모호한 설명("코드 관련 일에 도움이 됩니다")은 아예 트리거되지 않거나 모든 작업에서 트리거됩니다. 상황을 명확히 지명하는 설명을 쓰세요. "사용자가 브랜치 rebase, 머지 충돌 해결, 커밋 히스토리 정리를 요청할 때 사용."
Subagents: 격리된 컨텍스트의 작업자
Subagent는 메인 에이전트가 호출할 수 있는 에이전트입니다. 자체 시스템 프롬프트, 자체 컨텍스트 윈도우, 자체 도구 권한을 가집니다. 작업이 끝나면 결과를 메인 에이전트에 반환하고 사라집니다.
순진한 해석은 "subagents는 병렬화를 위한 것"입니다. 그것도 일부 맞습니다(Cursor 2.0은 최대 여덟 개의 병렬 백그라운드 에이전트를 광고합니다). 그러나 병렬화는 핵심 이점이 아닙니다. 핵심 이점은 컨텍스트 격리입니다.
Subagents가 빛을 발하는 세 가지 패턴:
1. 리서처. 에이전트에게 200개의 파일을 검색해 요약하라고 시키고 싶습니다. 메인 에이전트가 직접 하면 200개의 파일이 전부 메인 컨텍스트에 들어가지만, 정작 필요한 것은 세 문장짜리 요약뿐입니다. 리서치 subagent가 200개의 파일을 읽고, 요약하고, 한 단락만 돌려줍니다. 메인 컨텍스트는 깨끗하게 유지됩니다.
2. 리뷰어. 커밋 전에 diff에 대한 신선한 시선이 필요합니다. 리뷰어 subagent는 "코드 리뷰" 스킬을 로드하고, 다른 컨텍스트 없이 diff를 읽고, 이슈를 보고합니다. 메인 에이전트가 당신과 나눴던 구현 논쟁의 기억이 없기 때문에, 문제를 합리화해 넘기지 못합니다.
3. 위험한 작업. 마이그레이션 스크립트. 대규모 리네임. 스키마 변경. 에이전트가 격리된 상태에서 계획하고 실행한 뒤 보고합니다. 무언가 잘못되면 그 잔해는 subagent의 컨텍스트에 갇힙니다.
실제 비용도 있습니다. 각 subagent는 또 다른 모델 호출이고 또 다른 컨텍스트 윈도우입니다. 코디네이션 복잡도가 늘어납니다. 모든 작업에 subagent를 띄우는 팀은 토큰을 태우고 속도가 느려집니다.
경험 규칙은 이렇습니다. 다음 세 가지 중 하나가 참일 때 subagent를 띄우세요. (1) 작업이 메인 컨텍스트에 잡동사니를 잔뜩 쏟아부을 것 같을 때. (2) 신선한 시선이 작업에 도움이 될 때. (3) 작업이 위험해서 샌드박싱하고 싶을 때. 그 외에는 메인 세션에서 계속 작업하세요.
VoltAgent의 awesome-claude-code-subagents 같은 오픈소스 모음은 미리 만들어진 수백 개의 subagent를 정리해 둡니다. 대부분의 팀은 범용 subagent 수십 개보다 자기 코드베이스에 맞춘 커스텀 subagent 서너 개로 가장 좋은 결과를 냅니다.
Hooks: 결정론적 가드레일
Hooks는 모델이 말로 빠져나갈 수 없는 부분입니다. 도구 이벤트에 연결된 셸 커맨드입니다. 이벤트가 발생하면 명령이 실행됩니다. 모델은 거기에 발언권이 없습니다.
대표 이벤트:
- PreToolUse: 도구 호출 전에 발생. 호출을 차단할 수 있습니다.
- PostToolUse: 도구 호출 후에 발생. 포매터, 밸리데이터, 사이드 이펙트에 유용합니다.
- Stop: 에이전트가 턴을 마칠 때 발생. 알림에 유용합니다.
- Notification: 특정 에이전트 메시지에서 발생.
안전성에서 Hooks가 프롬프트를 이기는 이유는 이렇습니다. 프롬프트는 확률적입니다. "절대 rm -rf를 실행하지 마라"처럼 명확한 지시도 가끔은 실패합니다. 모델이 결국 패턴 보완을 하기 때문입니다. 셸이 명령을 보기 전에 rm -rf를 grep해 0이 아닌 값으로 종료하는 hook은 0퍼센트만큼 실패합니다. 그것은 정규식이지 바이브가 아닙니다.
가지면 좋은 hook 셋:
pre-bash-guard (Bash에 대한 PreToolUse). 명령을 읽어 위험 패턴을 차단합니다. rm -rf /, 보호 브랜치에 대한 git push --force, DROP TABLE, .env* 파일 직접 덮어쓰기. 30줄짜리 셸 스크립트가 프롬프트로는 안정적으로 막을 수 없는 재앙에서 당신을 구합니다.
post-edit-prettier (Edit/Write에 대한 PostToolUse). 에이전트가 .ts나 .tsx 파일을 편집한 뒤 prettier를 실행합니다. 결정론적으로 잡아 두면 세션 전체에 스타일이 일관되게 유지됩니다.
notify-on-stop (Stop). 에이전트가 장시간 작업을 마쳤을 때 macOS 알림이나 Slack 핑을 날립니다. 삶의 질이지만, 일하는 방식을 바꿉니다. 10분짜리 작업을 시켜놓고 옆에서 지키고 있을 필요가 없어집니다.
작은 성능 비용이 있습니다. 각 hook은 프로세스 스폰입니다. 실제로는 모델 자체 지연 시간에 비하면 거의 느껴지지 않으며, 결정성을 얻는 값으로는 충분히 쌉니다.
멘탈 시프트는 이렇습니다. 안전성을 모델에게 부탁하는 것이라고 생각하기를 멈추세요. 안전성은 환경이 강제하는 것이라고 생각하기 시작하세요. CI 파이프라인이 테스트를 강제하는 것과 같은 방식입니다. 모델은 빠른 주니어입니다. Hooks는 그 주니어가 끌 수 없는 pre-commit hook입니다.
네 기둥이 함께 작동하는 방식
실제 팀의 셋업이 어떻게 생겼는지 글로 풀어 보겠습니다.
레포 루트에는 CLAUDE.md가 있습니다. 약 80줄. 스택(Next.js 16, React 19, Yarn, Node 22), 디렉터리 레이아웃, 테스트 명령, 배포 규칙, 도메인 용어 다섯 개를 담은 용어집이 적혀 있습니다.
.claude/skills/ 아래에는 스킬 파일 여섯 개. rebase-cleanly.md, add-api-route.md, review-stripe.md, debug-firestore.md, write-deep-dive.md, sql-migration.md. 각각 80~150줄입니다.
.claude/subagents/ 아래에는 세 개. reviewer는 커밋 전에 실행되어 diff 이슈를 보고합니다. researcher는 메인 에이전트가 10개 이상의 파일을 읽어야 할 때 호출됩니다. test-runner는 테스트가 처음 시도에서 실패할 때 호출되어, 메인 컨텍스트를 오염시키지 않으면서 실패를 격리합니다.
.claude/hooks/ 아래에는 네 개. pre-bash-guard.sh는 위험 명령을 차단합니다. pre-edit-env-guard.sh는 .env.local 편집을 차단합니다. post-edit-prettier.sh는 .ts/.tsx 편집 후 prettier를 실행합니다. notification.sh는 장시간 작업이 끝나면 macOS에 핑을 날립니다.
평범한 세션은 이렇게 흘러갑니다. 개발자가 에이전트에게 "사용자 북마크를 반환하는 새 API 라우트를 추가해줘"라고 요청합니다. 에이전트는 CLAUDE.md를 읽고, add-api-route 스킬과 매칭해 로드하고, 파일을 작성합니다. post-edit hook이 prettier를 실행합니다. 테스트를 작성하면 prettier가 다시 실행됩니다. 리뷰어 subagent에게 diff 리뷰를 요청합니다. 리뷰어가 입력 검증 누락을 지적하면 메인 에이전트가 추가합니다. 개발자가 커밋을 요청합니다. pre-bash hook이 브랜치를 확인하고 커밋을 허용합니다. stop hook이 개발자에게 핑을 보냅니다.
이 흐름 어디에도 긴 프롬프트가 필요하지 않았습니다. 프롬프트는 "사용자 북마크를 반환하는 새 API 라우트를 추가해줘" 하나였습니다. 나머지는 모두 환경에 미리 짜여 있었습니다.
빌더들이 계속 반복하는 안티패턴
이 스택을 잘못 도입한 팀들에서 나온, 피해야 할 패턴 몇 가지를 정리합니다.
거대한-하나의-CLAUDE.md. 어떤 팀은 CLAUDE.md를 3년치 모든 결정의 덤프장처럼 다룹니다. 결과는 5,000줄짜리 파일이고, 모델은 그것을 로드하긴 하지만 내재화하지는 못합니다. "npm을 쓰지 말라"는 규칙이 두 페이지짜리 아키텍처 정당화 사이에 끼어 들어가면, 모델은 정당화를 가져가고 규칙을 잊습니다. CLAUDE.md는 짧게 유지하세요.
Hook 없이 가기. 어떤 팀은 hook을 전혀 두지 않고 프롬프트에만 의존해 에이전트를 안전하게 두려 합니다. 대체로 작동합니다. 그게 바로 문제입니다. rm -rf나 git push --force에 "대체로 작동"은 충분하지 않습니다. 결과가 "한 시간치 작업을 잃었다"라면 프롬프트로 괜찮습니다. 결과가 "프로덕션 테이블을 날렸다"라면 hook이 필요합니다.
Subagent 난립. 어떤 팀은 상상할 수 있는 모든 역할에 subagent를 만듭니다. 리서처, 리뷰어, 플래너, 서머라이저, 네이머, 리팩터러, 다큐멘터러, 테스터. 각각이 또 하나의 파일이고, 또 한 묶음의 토큰이고, 또 하나의 코디네이션 부담입니다. Subagent로 성공하는 팀은 보통 명확한 역할을 가진 세에서 다섯 개의 subagent를 운영합니다. 스무 개가 아닙니다.
문서 덤프로서의 Skill. Skill은 옛 위키 페이지를 옮기는 자리가 아닙니다. 스킬이 800줄이라면, 모델은 트리거될 때마다 800줄을 로드합니다. 스킬이 길다면 그것은 사실 두 개의 스킬일 가능성이 큽니다.
Skills를 CLAUDE.md처럼 다루기. 항상 참인 컨텍스트를 스킬에 넣으면 가끔만 로드됩니다. "절대 npm을 쓰지 말라"는 팀 전체 규칙은 모든 작업에 적용되므로 CLAUDE.md에 들어가야 합니다.
에이전트를 10초간 막는 Hook. 매 편집마다 전체 테스트 스위트를 돌리는 hook은 에이전트를 못 쓰게 만듭니다. Hook은 빨라야 합니다. 비싼 검증은 CI의 몫입니다.
이번 주에 바로 도입할 수 있는 실전 셋업
여기까지 읽었고 시작점을 원한다면, 가벼운 버전은 이렇습니다. 시니어 엔지니어 한 명이 하루면 세팅할 수 있고, 바이브 코딩 기본값보다 의미 있게 안정적인 에이전틱 코딩을 만들기에 충분합니다.
CLAUDE.md(약 50줄). 스택과 버전. 패키지 매니저(그리고 절대 쓰지 말아야 할 것). 최상위 디렉터리. 다섯 개의 강한 규칙(main에 푸시 금지, .env.local 건드리지 말 것, 이 테스트 명령어를 사용할 것). 짧은 도메인 용어 목록. 더 추가하고 싶은 충동을 누르세요.
스킬 두 개. rebase-cleanly.md(팀의 rebase 단계, 최대 80줄)와 review-changes.md(코드 리뷰 체크리스트, 최대 100줄).
리뷰어 subagent 하나. review-changes.md를 로드하고, diff를 읽고, 이슈를 보고합니다. 커밋 전에 호출됩니다.
Hook 세 개. Bash에 대한 PreToolUse는 rm -rf, 보호 브랜치에 대한 git push --force, .env* 파일 편집을 차단합니다. Edit/Write에 대한 PostToolUse는 편집된 .ts/.tsx 파일에 prettier를 실행합니다. Stop은 에이전트가 종료될 때 macOS 알림을 날립니다.
여기까지입니다. CLAUDE.md + 스킬 두 개 + subagent 하나 + hook 세 개. 아마 여덟 개 정도의 파일이 든 폴더, 모두 버전 관리되고, 팀의 나머지 구성원이 리뷰할 수 있습니다.
이후로는 반복하게 됩니다. 일주일이 지나면 에이전트가 자꾸 헛발질하는 작업들이 보이고, 새 스킬로 코드화하게 됩니다. 나쁜 명령의 카테고리가 보이고, pre-bash 가드에 추가하게 됩니다. 리서처 subagent가 메인 컨텍스트를 깨끗하게 유지해 줬을 순간이 보이고, 하나를 추가하게 됩니다. 네 기둥은 형태이고, 그 안의 내용은 당신의 것입니다.
바이브 코딩에서 에이전틱 엔지니어링으로의 전환은 한 단계 더 영리해지는 일이 아닙니다. 그것은 운영 규율을 향한 한 걸음입니다. 프로덕션에서 돌아가는 다른 시스템을 다루듯이 에이전트를 다루는 것입니다. 컨벤션, 가드레일, 관심사 간의 격리를 갖춘 상태로. 마법은 줄이고, 엔지니어링은 늘리며, 첫 달이 지나도 스케일이 유지되는 워크플로를 만드는 일입니다.
자주 묻는 질문
이 내용은 Claude Code 전용인가요, 아니면 Cursor나 다른 에이전트에도 적용되나요?
기둥들은 도구를 가로질러 적용되며, 이름만 다릅니다. Cursor는 "rules" 파일과 "background agents"를 씁니다. GitHub Copilot은 AGENTS.md를 씁니다. Gemini CLI는 GEMINI.md를 씁니다. Hooks는 아직 보편적이지 않지만(Claude Code의 구현이 가장 성숙합니다), 대부분의 도구가 어떤 형태의 대응물을 제공합니다. 멘탈 모델(컨텍스트 레이어, 온디맨드 지식, 격리된 작업자, 결정론적 가드)은 구현이 달라도 일반화됩니다.
Skill을 만드는 것과 CLAUDE.md에 전부 넣는 것의 차이는 무엇인가요?
로딩 방식이 다릅니다. CLAUDE.md는 모든 세션 시작 시 로드됩니다. Skills는 설명이 작업과 매칭될 때만 로드됩니다. 열 개의 다른 작업을 위한 절차적 지식을 모두 CLAUDE.md에 넣으면, 모델은 매 작업마다 그 전부를 로드하고, 컨텍스트는 대부분 무관한 내용으로 채워지며, 특정 규칙 준수율이 떨어집니다. Skills는 CLAUDE.md를 짧게 유지하고, 절차적 디테일을 필요할 때 꺼낼 수 있게 합니다.
Subagent를 만들 때와 그냥 더 긴 프롬프트를 쓸 때를 어떻게 구분하나요?
세 가지 조건이 당신을 subagent 쪽으로 밀어줍니다. (1) 작업이 메인 컨텍스트에 많은 내용을 쏟아부을 것 같을 때. (2) 메인 에이전트가 쌓은 추론으로 오염되지 않은 신선한 시선이 필요할 때. (3) 작업이 위험해서 샌드박싱하고 싶을 때. 그 외에는 더 긴 프롬프트나 스킬이 보통 더 나은 선택입니다. Subagents는 토큰과 코디네이션 비용이 듭니다.
Hooks가 에이전트를 느리게 만들지 않나요?
각 hook은 프로세스 스폰이므로, 하는 일에 따라 밀리초에서 초 단위가 추가됩니다. 실제로는 모델 자체 지연 시간에 묻혀 거의 보이지 않습니다. 긴 hook(모든 편집마다 전체 테스트 스위트 실행)은 에이전트를 굼뜨게 만들 수 있고, 그런 작업은 CI에 두는 편이 맞습니다. 좋은 규칙은 이렇습니다. PreToolUse hook은 일반적인 경우 200ms 이내에 종료해야 하고, 포매터 같은 PostToolUse hook은 누구도 알아채지 못할 만큼 1~2초 정도까지는 괜찮습니다.
CLAUDE.md를 레포에 커밋해야 하나요?
네, 거의 항상 그렇습니다. CLAUDE.md는 팀 아티팩트입니다. 모두(사람이든 에이전트든)가 따라야 하는 컨벤션을 인코딩합니다. 커밋하면 팀 전체의 에이전트가 동일한 컨텍스트로 작업하고, 다른 코드처럼 리뷰됩니다. 로컬에만 둘 만한 것은 개발자별 권한 설정 정도입니다(Claude Code는 그 용도로 settings.local.json을 지원합니다).
맺는말
1년 간격으로 올라온 Karpathy의 두 게시물은 2025년 AI 코딩에 일어난 일을 깔끔하게 묶어 줍니다. 첫 번째는 놀아도 된다는 허가였습니다. 두 번째는 청구서가 도착한 순간이었습니다. 바이브 코딩은 발견 모드로서는 유용했습니다. SDK를 먼저 배우지 않고도 이 모델들이 무엇을 할 수 있는지 사람들에게 가르쳐 줬습니다. 그것이 출시를 위한 모드는 아니었습니다.
그것을 대체하는 것은 실제 시스템에서 일해 본 사람이라면 익숙한 모습입니다. 불변값을 적어 둡니다(CLAUDE.md). 절차를 패키징합니다(Skills). 위험하거나 컨텍스트가 많이 드는 작업을 위해 격리된 작업자를 떼어 냅니다(Subagents). 경계에 가드레일을 설치합니다(Hooks). 이 중 어느 것도 이국적이지 않습니다. 취미 프로젝트와 월요일 아침에 아무도 대기하지 않아도 돌아가는 서비스를 구분 짓는, 동일한 운영 규율입니다.
실제로 운영되는 팀들의 셋업에서 놀라운 점은 그 크기가 작다는 것입니다. 여덟 개의 파일. 전부 합쳐 천 줄 남짓. 리뷰어 subagent 하나. Hook 세 개. 이것만으로도 가끔 데이터베이스를 날리는 모델을 그러지 않는 팀원으로 바꿔 줍니다. 레버리지는 분량에 있지 않습니다. 올바른 불변값을 올바른 기둥에 두는 것에 있습니다.
2026년 중반에도 여전히 순수 바이브 코딩 모드에 있다면, 뒤처진 것은 아닙니다. 생산성 향상의 대부분이 모델을 지루하게 만드는 데서 나오는 단계에 있는 것입니다. 더 예측 가능하게, 더 제약되게, 더 리뷰 가능하게. 의도적으로 마법을 줄이는 것. 그것이 해야 할 일입니다.