---

---

목차

들어가며 — 4개의 바퀴로 굴러가는 바이브 코딩

Part 1 — 바이브 코딩의 이해

• 1장. 바이브 코딩 — 함수가 루프가 될 때
• 2장. Claude Code — 4요소가 측정 가능해진 사건

Part 2 — 4가지 구성 요소

• 3장. 시간 — 한입씩 도는 시대
• 4장. 공간 — 길어지면 썩는다
• 5장. 연결 — 호환성과 확장성
• 6장. 검증 — 시간이 지날수록 좋아지는 시스템

Part 3 — 실전 적용

• 7장. HIAO와 한입감과 가드레일 — 4요소 균형의 실무
• 8장. 설계도를 그려라 — 레이어가 보일 때까지
• 9장. 사람이 볼 수 있게 하자 — 개입과 정체성과 경계

마치며 — 4바퀴가 굴러가게 하라

부록 A — 4×4 진단 매트릭스 워크시트 부록 B — 4요소 어휘 일관성 표

---

들어가며 — 4개의 바퀴로 굴러가는 바이브 코딩

이 책을 쓴 이유

지난 1년, 나는 시니어 개발자이면서 동시에 AI 네이티브로 살았다. 30년의 코딩 습관과 갓 태어난 도구 사이에서 매일 두 시간씩 무너지고, 다시 짓고, 또 무너졌다. 그러다 어느 날 깨달았다. 내가 자꾸 같은 자리에서 무너진다는 것을. 무너지는 자리는 늘 같았다. 컨텍스트가 부패할 때, 한 작업을 너무 크게 잡았을 때, 도구가 갑자기 안 닿을 때, 검증을 빼먹었을 때.

이 네 자리를 묶을 단어가 없었다. 그래서 이 책을 쓴다.

4가지 구성 요소 — 4관점, 4축, 4바퀴, 4기둥

이 책은 바이브 코딩을 4가지 구성 요소로 풀어 낸다.

첫째는 시간이다. 도구 호출과 응답 사이를 도는 루프다. 둘째는 공간이다. 컨텍스트 윈도우를 채우는 일이고, 부패하지 않게 한입씩 자르는 일이다. 셋째는 연결이다. 모델이 세상에 닿는 손과 발이고, 그 닿음이 늘어나도 무너지지 않도록 호환성과 확장성을 기록하는 일이다. 넷째는 검증이다. 산출물이 옳은지 점검하는 건강검진이고, 막강한 AI 도구가 방향성 있게 일하도록 보호하는 가드레일이다.

이 넷을 어떻게 부를지에 따라 강조점이 달라진다. 4관점이라고 부르면 같은 시스템을 4가지 시야로 본다는 뜻이 된다. 보는 각도의 이야기다. 4축이라고 부르면 분석의 좌표계가 된다. 4 곱하기 4 매트릭스로 진단할 수 있다. 4바퀴라고 부르면 바이브 코딩이 그 위에서 굴러간다는 뜻이 된다. 한 바퀴라도 빠지면 굴러가지 않는다. 이 책의 부제이기도 하다. 4기둥이라고 부르면 만들어 낸 서비스나 플랫폼을 지탱하는 구조가 된다. 한 기둥이 약하면 그 위의 모든 것이 무너진다.

부르는 이름은 그때그때 다르다. 같은 넷을 보고(관점), 분석하고(축), 굴리고(바퀴), 떠받친다(기둥). 본문에서는 문맥에 맞게 혼용한다. 어색하지 않다. 같은 4요소가 상황에 따라 다른 도구가 되기 때문이다.

시니어이면서 AI 네이티브가 발견한 4요소

이 4요소는 어느 학자가 책상에서 분류한 게 아니다. 시니어 개발자가 AI 네이티브로 살면서 발견한 것이다.

종래의 소프트웨어 엔지니어링에서 한 사이클을 도는 일은 시간과 돈과 인력이라는 자원의 소비였다. 한 함수를 100번 고치고 싶어도, 한 모듈을 10번 다시 짓고 싶어도 못 했다. 하고 싶어도 못 했다. 자원이 비싸기 때문이었다. 그런데 바이브 코딩에서는 그게 가능해졌다. AI 도구가 한 사이클을 분 단위로 돌려 준다. 시간 비용이 사람의 시간이 아니라 토큰의 시간으로 바뀌었다. 그래서 우리는 이제 처음으로, 루프를 충분히 도는 일을 할 수 있게 됐다.

루프를 충분히 돌면 어떤 일이 일어나는가. 산출물이 구조화된다. 첫 시도는 평면이지만, 두 번째에서 모듈이 나뉘고, 세 번째에서 계층이 보이고, 네 번째에서 인터페이스가 정제된다. 즉 루프를 통해 코드가 자라난다. 종래에는 설계 후 한 번에 만들었다. 이제는 만들면서 설계가 자라난다.

가능해진 만큼, 어떻게 굴릴지가 새 질문이 됐다. 충분히 돌릴 수 있다는 가능성이 곧 좋은 결과를 보장하지는 않는다. 무한히 돌아도 한입이 아니면 무한 루프가 된다. 한입이라도 부패하면 같은 한입을 또 돌리게 된다. 한입이 한입씩 잘 도는데 검증이 없으면 잘못된 한입 위에 잘못된 한입이 쌓인다. 한입이 잘 검증되어도 도구가 한 곳에 묶여 있으면 다음 단계로 못 간다.

그래서 4요소다. 시간이 가능해졌으니, 공간을 짧게 박고, 연결을 넓게 열고, 검증을 단단하게 깐다. 이 네 자리가 같이 굴러가야 바이브 코딩이 굴러간다.

이 책의 구조

이 책은 3부 9장으로 구성된다.

Part 1 — 바이브 코딩의 이해는 두 장으로 짜였다. 1장에서 바이브 코딩이 무엇인지를 짚는다. 2장에서 그 가장 잘 만들어진 사례인 Claude Code를 짚는다. 4요소를 본격적으로 다루기 전에, 무엇이 변했는지를 먼저 기록하는 부다.

Part 2 — 4가지 구성 요소는 네 장으로 짜였다. 3장은 시간, 4장은 공간, 5장은 연결, 6장은 검증이다. 한 장씩 한 요소를 풀어 낸다. 각 요소가 어떻게 작동하는지, 무엇을 보호하는지, 어떤 도구로 다룰 수 있는지를 기록한다. 이 부가 책의 가장 두꺼운 부다.

Part 3 — 실전 적용은 세 장으로 짜였다. 저자 자신이 이 4요소를 어떻게 균형 잡는지를 기록한다. 7장은 HIAO와 한입감과 가드레일이다. 4요소를 실무에서 균형 잡는 이야기다. 8장은 설계도를 그려라이다. 요구사항 분석과 계층화의 실제다. 9장은 사람이 볼 수 있게 하자이다. 개입과 정체성과 경계의 이야기다.

마지막에 마치며가 있다. 4바퀴가 굴러가게 하라는 한 줄로 책을 닫는다.

읽는 분께

이 책은 완성된 정답이 아니다. 시니어이면서 AI 네이티브가 발견해 가고 있는 중간 보고서다. 4요소는 더 늘어날 수도, 다른 이름으로 불릴 수도 있다. 다만 지금 이 자리에서 가장 자주 무너지는 4자리가 어디인지, 그것만은 분명하다.

그리고 한 가지 더. 이 책의 모든 메시지가 한 줄로 모인다.

설계 없이는 코딩이 안된다.

이 한 줄이 4요소 위에서 4번 기록된다. 시간을 설계하지 않으면 무한 루프가 되고, 공간을 설계하지 않으면 부패하고, 연결을 설계하지 않으면 도구가 폭발하고, 검증을 설계하지 않으면 가소성이 죽는다. 4요소는 결국 4가지 설계의 형태다.

여러분의 워크플로우에 이 4바퀴를 얹어 보시기 바란다. 어떤 바퀴가 약한지, 거기서부터 시작하면 된다. 그 바퀴에 손을 대는 순간, 다른 세 바퀴도 같이 따라온다. 4요소는 그렇게 얽혀 있다.

이제 1장으로 가자.

---

---

1장. 바이브 코딩 — 함수가 루프가 될 때

함수에서 루프로

LLM 한 번 호출은 함수다. 들여보내는 프롬프트가 있고 받아 보는 텍스트가 있다. 변수가 둘이다. 두 개로 사고하면 충분했다. 프롬프트가 좋으면 출력이 좋고, 출력이 안 좋으면 프롬프트를 다시 짠다. 그 사이클이 프롬프트 엔지니어링 시대의 사고방식이었다.

에이전트는 다르다. 함수가 아니라 루프다. 프롬프트가 들어가면 모델이 도구를 부르고, 도구가 결과를 돌려주고, 그 결과가 다시 모델 입력에 합쳐지고, 모델이 또 도구를 부르고. 그렇게 도구 호출 없는 응답이 나올 때까지 돈다. 한 번 도는 것을 한 턴이라 부른다.

이게 핵심이다. 함수가 루프가 되는 순간 변수 두 개로는 부족해진다. 입력과 출력만으로 결과가 결정되지 않는다. 루프가 몇 번 도는지, 도구가 무엇이 연결되어 있는지, 컨텍스트가 얼마나 부풀었는지, 검증이 어디에서 작동하는지. 그 모든 것이 결과에 영향을 준다.

프롬프트 엔지니어링의 한계

프롬프트 엔지니어링은 함수 시대의 도구다. 한 번의 호출을 잘 짜는 기술. 좋은 프롬프트가 좋은 텍스트를 만든다. 그 한 번을 위해 모든 노력이 들어간다. 시스템 프롬프트, 역할 부여, 예시 박기, 단계별 사고 유도. 다 좋은 도구다.

그런데 에이전트 시대에는 그 한 번의 호출이 전체의 10분의 1도 안 된다. 한 턴에 도구가 5번 호출되면 LLM 호출이 6번이다. 한 작업에 10턴이 필요하면 LLM 호출이 60번이다. 그중 한 번을 아무리 잘 짜도 나머지 59번이 무너지면 결과가 안 나온다.

여기서 컨텍스트 엔지니어링이라는 새 단어가 나왔다. 한 번이 아니라 지속 가능한 컨텍스트 자체를 설계한다는 뜻이다. 그리고 그 다음 단어 — 하네스 엔지니어링도 나왔다. 모델 바깥의 인프라를 짠다는 뜻이다. 또 에이전트 엔지니어링이 나왔다. 에이전트가 어떤 결정을 내릴지를 짠다는 뜻이다.

세 단어가 늘어났다. 왜 늘어났는가. 함수 두 변수로는 부족하기 때문이다. 변수가 더 필요해졌기 때문이다. 그 추가 변수가 곧 시간, 공간, 연결, 검증의 4요소다.

바이브 코딩의 정의

본 강의 시리즈의 표어는 한 줄이다.

AI-Native Vibe Coding: No Design, No Code. 설계 없이는 코딩이 안된다.

바이브 코딩이라는 단어는 Andrej Karpathy가 박았다. 코드를 한 줄씩 타이핑하는 게 아니라, 분위기로 코드를 만들어 낸다는 뜻이다. 자연어로 의도를 박으면 AI가 코드를 쓰고, 실행하고, 고치고, 다시 기록한다. 사람은 의도와 검토만 한다.

하지만 그 분위기가 마법이 되려면 4요소가 같이 굴러가야 한다. 사람이 기록하는 분위기는 공간 1요소뿐이다. 시간·연결·검증은 에이전트가 알아서 한다고 가정한다. 그 가정이 깨지는 순간 바이브 코딩은 마법에서 무한 루프가 된다. 이게 바이브 코딩의 정의가 설계 없이는 코딩이 안된다인 이유다.

루프가 가능해진 시대

여기서 흥미로운 관찰 하나. 왜 지금 바이브 코딩이 가능해졌는가.

종래의 소프트웨어 엔지니어링에서 한 사이클을 도는 일은 자원의 소비였다. 한 함수를 100번 고치고 싶어도 못 했다. 한 모듈을 10번 다시 짓고 싶어도 못 했다. 자원이 비싸기 때문이었다. 사람의 시간이 비싸고, 인력이 비싸고, 검토가 비쌌다. 하고 싶어도 못 했다.

그런데 AI가 한 사이클을 분 단위로 돌려 준다. 시간 비용이 사람의 시간이 아니라 토큰의 시간으로 바뀌었다. 1만 원의 토큰으로 100사이클을 돌릴 수 있는 시대가 됐다. 이게 바이브 코딩이 가능해진 구조적 이유다.

루프를 충분히 돌리면 어떤 일이 일어나는가. 산출물이 구조화된다. 첫 시도는 평면이지만 두 번째에서 모듈이 나뉘고, 세 번째에서 계층이 보이고, 네 번째에서 인터페이스가 정제된다. 루프를 통해 코드가 자라난다. 종래에는 설계 후에 만들었다. 이제는 만들면서 설계가 자라난다.

이 자라남이 바이브 코딩의 본질이다. 그래서 4요소가 필요해졌다. 자라나려면 시간이 충분해야 하고, 공간이 짧아야 하고, 연결이 풍부해야 하고, 검증이 단단해야 한다. 4가지 자리가 같이 굴러가야 자라남이 작동한다.

예고 — 4요소를 한 장씩

다음 장에서 가장 잘 만들어진 바이브 코딩 도구인 Claude Code를 본다. 그 안에 4요소가 어떻게 기록되어 있는지를 코드 수준으로 본다. 그러고 나서 Part 2에서 4요소를 한 장씩 풀어 낸다.

바이브 코딩이 무엇인지 박았다. 이제 그 가장 잘 만들어진 사례 — Claude Code — 를 보러 가자.

---

2장. Claude Code — 4요소가 측정 가능해진 사건

한 번의 .npmignore 누락

2026년 3월 31일, Anthropic이 Claude Code v2.1.88을 npm에 올렸다. 그때 누군가 .npmignore 파일에 *.map 한 줄을 추가하는 걸 잊었다. 보안 연구자 Chaofan Shou가 그걸 발견했다. 59.8 MB의 source map 파일이 npm registry 누구나 다운로드 가능했다.

source map은 압축·난독화된 프로덕션 JavaScript 코드를 원본 TypeScript로 되돌릴 수 있는 매핑 정보다. 디버깅용으로는 천국이고 노출되면 지옥이다. Boris Cherny — Claude Code 책임자 — 가 공식 인터뷰에서 plain developer error라고 시인했다. 게다가 처음이 아니었다. 2025년에도 같은 일이 한 번 있었다. 같은 실수가 두 번.

Anthropic의 대응은 빠르고 표준적이었다. npm unpublish로 v2.1.88을 거두고, 관련 버전들을 deprecate로 마킹했다. 하지만 npm의 unpublish는 완벽한 회수가 아니다. 이미 다운로드된 캐시는 회수 못 한다. 발견 후 수 시간 내에 GitHub mirror가 push됐다. 지워지기 전에 이미 기록되었다.

50줄 vs 512K줄

유출된 자산의 규모는 충격적이었다. 복원된 TypeScript는 약 512,000줄, 파일 1,884개. 그중 도구의 베이스인 Tool.ts만 29,000줄. query engine만 46,000줄. 발견된 feature flag는 44개.

그런데 외부 분석가가 이 코드를 들여다보고 한 줄로 박은 관찰이 있다. AI loop는 약 50줄이라는 것이다. 쿼리 루프 자체 — while문에 도구 호출과 응답을 합치는 그 핵심 — 는 50줄 정도다. 나머지 511,950줄은 Product Engineering이다.

1.6%가 AI, 98.4%가 Infrastructure.

이게 우리에게 시사하는 게 핵심이다. Claude Code는 AI 도구가 아니라 AI가 일하는 제품 시스템이다. 우리가 AI 시대에 배워야 할 것은 모델이 아니라 모델 위에서 일하는 시스템 엔지니어링이다.

4요소가 측정 가능해진 사건

이 사고가 우리에게 준 가장 큰 선물은 측정 가능성이다.

전에는 Claude Code의 동작을 사용 후기로만 짐작했다. 어떤 시점에 잘리는 것 같다. 어떤 도구가 있다더라. 어떤 패턴이 있다더라. 추측의 영역이었다.

이제는 코드 수준으로 측정된다. 시간 요소 — 쿼리 루프가 7개의 transition site와 5개의 recovery 분기를 가진 상태 머신이라는 것. 공간 요소 — 시스템 프롬프트가 정적 7블록 + 동적 13블록으로 짜였고, Compaction이 5층 cascade로 작동하며 80% 임계는 13K buffer를 빼는 공식이라는 것. 연결 요소 — 도구 약 40개에 각각 독립된 권한 게이트가 있고, Subagent와 Mailbox 패턴으로 격리·위임된다는 것. 검증 요소 — Hooks가 6 이벤트 × 3 카덴스로 작동하며, PostSampling이라는 시스템 측 마지막 검증 레이어가 있다는 것.

본 책이 가르치는 핵심은 4요소다. 그런데 측정 안 되는 것은 가르칠 수 없다. 유출 덕에 우리는 Claude Code라는 가장 잘 만들어진 4요소 분업 사례를 코드 수준으로 따라 읽을 수 있게 됐다.

brain이 아니라 skeleton이 노출됐다

여기서 중요한 게 모델 가중치는 안 새고 코드만 새었다는 점이다. Claude 4, Sonnet, Haiku 같은 모델 자체는 안전했다. 노출된 건 Claude Code라는 제품이 그 모델을 어떻게 호출하고, 결과를 어떻게 정리하고, 도구를 어떻게 디스패치하는지 — 그 오케스트레이션 로직이다.

외부 분석가들이 한 표현이 좋아서 옮긴다.

brain이 아니라 skeleton이 드러났다.

두뇌(모델)는 안 새고, 골격(코드)은 다 새고. 이게 우리에게 학습 자료로는 최적의 누출이다. 모델 보안은 유지된 채, 엔지니어링 패턴만 공개된 거니까.

예고 — 4요소를 한 장씩

유출 사고 자체를 다루는 건 여기까지다. 이제 그 사고가 보여 준 4요소를 한 장씩 본다.

Part 2 — 4가지 구성 요소. 3장은 시간, 4장은 공간, 5장은 연결, 6장은 검증. 한 장씩 한 요소를 풀어 낸다. 각 요소가 어떻게 작동하는지, 무엇을 보호하는지, 어떤 도구로 다룰 수 있는지를 기록한다.

이제 4요소를 한 장씩 풀어 가자. 시간부터.

---

---

3장. 시간 — 한입씩 도는 시대

루프가 가능해진 시대

에이전트의 시간은 쿼리 루프의 시간이다. 다른 무엇이 아니다.

한 줄 의사코드로 박으면 — while문 안에서 도구 호출이 있을 때마다 그것을 실행하고, 결과를 다시 모델에 합쳐 한 번 더 부르고, 도구 호출 없는 응답이 나올 때까지 돈다. 한 번 도는 것을 한 턴이라 부른다.

이게 시간 요소의 본질이다. 그리고 이 본질이 흥미로운 건 — 종래의 소프트웨어 엔지니어링에서는 이런 루프가 사실상 불가능했다는 점이다. 사람이 한 사이클을 돌리는 비용이 너무 컸다. AI가 한 사이클을 분 단위로 돌려 주는 시대가 되어서야 — 이 루프가 처음으로 가능해졌다.

가능해진 만큼 — 어떻게 굴릴지가 새 질문이 된다. 충분히 돌릴 수 있다는 가능성이 곧 좋은 결과를 보장하지는 않는다. 한입이 아니면 무한 루프가 된다.

한입(One Bite Task)의 미학

쿼리 루프가 수렴하려면 — 한 턴에 처리하는 작업이 한입 크기여야 한다.

한입이 아니면 시간은 빙빙 돈다.

큰 작업은 — 도구를 5번, 10번, 100번 호출해도 안 끝난다. 한 턴 안에서 max_turns에 닿거나, Compaction이 너무 자주 발동하거나, 도구 결과 토큰이 컨텍스트를 부풀려 부패가 시작된다.

한입의 3가지 표시가 있다. 첫째, 명확한 시작과 끝. X 파일의 Y 함수에 Z 검증을 추가하라는 작업은 한입이다. 이 프로젝트를 리팩토링하라는 작업은 한입이 아니라 큰 덩어리다. 둘째, 3-5턴 안에 수렴. 도구 호출이 그 이상 길어지면 한입이 아니다. 셋째, 검증 가능한 산출. 한입 끝에 통과/실패가 명확해야 한다.

한입을 만드는 도구가 셋이다. Plan Mode — 큰 작업을 받기 전에 한입 N개로 분해. TodoWrite — 분해된 한입을 순서대로 박제. Subagent — 한 한입을 격리된 컨텍스트에서 처리. 시간 요소의 모든 도구는 한입을 만들기 위한 도구다.

7 transition site — 명시적 상태 머신

Claude Code의 query.ts에는 continue 지점이 정확히 7개 있다. 각각 다른 transition.reason을 갖는다. next_turn, reactive_compact_retry, max_output_tokens_escalate, max_output_tokens_recovery, stop_hook_blocking, token_budget_continuation, collapse_drain_retry.

쿼리 루프는 단순 while이 아니라 명시적 상태 머신이다. 7개 분기가 다 기록되어 있고, 각 분기는 한입이 깨졌을 때 어떻게 다시 돌까를 결정한다.

한입이 깨진다는 건 어떻게 알 수 있는가. Reactive compact, max output 4배 escalate, collapse drain — 이런 transition이 빈번해지면 — 그 한 턴이 한입이 아니었다는 증거다. 작업 단위 설계가 잘못된 것이고, 한입을 더 작게 잘라야 한다는 신호다.

5 recovery 전략 — 실패에서 다시 도는 분기

흥미로운 점은 — 7 transition 중 5개가 recovery 분기라는 것이다. 즉 시간 요소의 절반이 한입이 깨진 뒤 다시 돌기 위한 코드다. 정상 흐름의 코드보다 실패 처리의 코드가 더 무겁다.

분석가가 보고한 통계 하나. 한때 1,279개 세션이 50회 이상 연속 compaction 실패를 경험했다. 하루 25만 API 호출이 그것 때문에 낭비됐다. 그 사건 후 circuit breaker가 도입됐다. Claude Code도 실패를 통해 학습한 시스템이다. v1에 없던 recovery 분기가 매 메이저 릴리스마다 추가됐다.

우리 자신의 워크플로우도 동일하게 진화해야 한다. 내 워크플로우의 recovery 분기는 몇 개인가. 0개라면 첫 실패에서 무너진다. 가장 흔한 실패 3개를 적어보고, 각각 자동 처방을 박아두자. 그게 시간 요소의 견고함의 출발점이다.

우리 손에 있는 도구

시간 요소의 사용자 통제점은 셋이다. max_turns로 쿼리 루프 최대 반복을 기록한다. Plan Mode로 작업 시작 전 분해 단계를 기록한다. TodoWrite로 분해된 한입을 박제한다.

워크플로우 패턴은 단순하다. 사용자 요청(큰 덩어리)이 들어오면 Plan Mode로 한입 N개로 분해. TodoWrite로 N개 한입 박제. 한입 하나씩 쿼리 루프에서 3~5턴 수렴. 검증 → 다음 한입. 모든 한입 완료 → 종료.

시간은 한입과 명시적 게이트로만 안전해진다.

한입이 아니면 빙빙 돌고, 게이트가 없으면 첫 실패에 무너진다. 이게 시간 요소의 한 줄 정리다.

한입이 한입씩 잘 돌아도 — 한 한입이 부패하면 같은 한입을 또 돌리게 된다. 다음 장은 부패를 막는 일이다. 공간 요소다.

---

4장. 공간 — 길어지면 썩는다

공간은 유한하고, 길어지면 썩는다

에이전트의 공간은 컨텍스트 윈도우다. 그리고 그것은 유한하다.

Claude Sonnet의 컨텍스트 윈도우는 200K 토큰. Opus는 Pro 200K, Max 1M. GPT, Gemini, 어느 모델이든 컨텍스트 윈도우는 finite buffer다. 무한한 메모리가 아니다.

그래서 모든 에이전트 설계는 결국 — 유한한 버퍼 안에서 무엇을 살리고 무엇을 버릴지의 문제다. 그리고 한도 안에서도 — 길어질수록 부패한다.

컨텍스트 부패의 정체

컨텍스트 부패는 토큰 한도 초과가 아니다. 한도 안에서도 — 모델 성능이 점진적으로 떨어지는 현상이다.

부패의 4가지 증상이 있다. 첫째, 초반 지시 망각. 절대 X하지 마라고 했는데 30턴 뒤에 X를 한다. 둘째, 중복 작업 반복. 같은 파일을 두 번 읽고, 같은 결론을 두 번 기록한다. 셋째, 세부 사항 흐려짐. 처음에 정확했던 변수명·경로가 나중에 비슷한 것으로 대체된다. 넷째, 확신의 비대칭 증가. 부정확해질수록 오히려 더 단언적으로 답한다.

왜 부패하는가. LLM은 attention 메커니즘이다. 컨텍스트가 길어질수록 같은 토큰에 분산되는 attention의 질이 떨어진다. 200K 윈도우에 50K만 차 있을 때와 180K 차 있을 때의 모델은 같은 모델이 아니다. 후자는 부패한 모델이다.

부패는 토큰 한도의 문제가 아니라 attention 분산의 문제다. 한도 안에서도 부패한다.

한입감이 부패를 막는다

여기서 시간 요소(3장)와 공간 요소가 만난다. 한입이 부패를 막는다.

큰 덩어리를 한 턴에 처리하려고 하면 — 도구 결과가 컨텍스트를 부풀린다. 한 파일을 통째로 read 하면 그 결과가 KB 단위로 기록된다. 10번 read 하면 컨텍스트가 30%, 40% 이미 차 있다. 거기서 모델이 일을 하려면 — 부패한 공간 위에서 일하는 셈이다.

한입이 답이다. 한 한입은 작은 컨텍스트로 처리된다. 그리고 한입이 끝나면 — 다음 한입을 새 컨텍스트(또는 압축된 컨텍스트)에서 시작할 수 있다. 큰 덩어리를 한 번에 끝내려는 본능이 — 부패의 가장 흔한 원인이다.

그래서 시간(한입)과 공간(부패)은 같은 동전의 양면이다. 한입이 깨지면 공간이 부패하고, 공간이 부패하면 한입이 또 깨진다. 둘은 같이 무너진다. 둘은 같이 풀어야 한다.

7 정적 + 13 동적 + 200줄 CLAUDE.md

Claude Code의 시스템 프롬프트는 layered 구조다. 정적 7블록과 동적 13블록.

정적 7블록은 Identity, Safety, Tone, Tool list, Tool usage rules, Output format, Response style. 이 7개는 안 바뀌니까 prompt cache가 적중한다. 토큰 비용이 캐시 hit 가격으로 떨어진다. 보통 1/10 가격이다.

동적 13블록은 CLAUDE.md, working directory, git status, 환경 변수, 열린 파일, 플랫폼, 세션 메타, MCP manifest, 권한 상태, 최근 도구 결과, Compaction 요약, Memory 파일, 날짜·로케일. 이건 매 턴 바뀐다.

왜 이렇게 쪼갰는가. 답은 단순하다. prompt cache가 prefix matching으로 동작하기 때문이다. 앞부터 같은 토큰 시퀀스가 이어지는 만큼 캐시된다. 정적이 앞에 있으면 정적 부분이 통째로 cache hit, 동적이 뒤에 있으면 변하는 부분만 miss. 7+13의 순서 자체가 곧 캐시 전략이다.

사용자가 직접 통제할 수 있는 레이어는 거의 유일하게 CLAUDE.md다. L1(Anthropic 본사)과 L2(Claude Code 제품팀)는 우리가 못 건드린다. L4(git/cwd)는 자동이다. L3(CLAUDE.md)만이 우리 손에 있다.

Anthropic은 200줄 이하를 권장한다. 표면적 이유는 토큰 비용. 진짜 이유는 부패 저항이다. 길수록 adherence(준수도)가 떨어진다. 200줄짜리 짧은 CLAUDE.md는 attention이 안정되고, 모든 줄이 살아 있고, 캐시 비용도 낮다.

Compaction 5층 cascade — 부패의 5단 처방

공간이 한도에 가까워지면 Compaction이 작동한다. 한 가지 알고리즘이 아니라 5단 cascade다. 가장 싼 처방부터 시도한다.

1층 Budget Reduction. 룰 엔진. 비용 0. 도구 결과 cap 적용, 최근 N 턴만 보존, 나머지는 압축 candidate. 보통 여기서 끝난다.

2층 Snip. 정밀 가지치기. 비용 0. 오래된 메시지의 중복·무의미 부분 제거. 사용자/assistant 페어는 보존.

3층 Microcompact. 작은 LLM 호출. 도구 결과만 LLM으로 요약. 대화 흐름은 안 건드린다. 큰 파일 read 결과가 여기서 자주 정리된다.

4층 Context Collapse. feature flag 뒤의 실험적 단계. 카테고리 단위로 합친다.

5층 Auto-Compact. 마지막 보루. 큰 LLM 호출로 대화 전체를 한 요약으로 치환. 최근 N 턴은 원형 보존. CLAUDE.md는 디스크에서 다시 읽혀 재주입 — 사라지지 않는다.

별도로 Reactive Compact가 있다. API가 413 Payload Too Large를 반환하면 위 단계 다 무시하고 5층을 공격적으로 즉시 호출. 비상 브레이크다.

5층 cascade의 핵심 통찰은 — 비용이 점진 증가한다는 점이다. 1층은 0원, 5층은 큰 LLM 호출. 가장 싼 처방으로 먼저 막고, 안 되면 다음. 이게 production-grade 부패 관리의 본보기다.

우리 자신의 워크플로우에 시사하는 게 있다. 큰 파일을 무심코 read 하면 Microcompact가 트리거된다. grep + 라인 범위 read 패턴은 Compaction을 늦춘다. 도구를 어떻게 쓰느냐가 부패 진행 속도를 결정한다.

공간은 prefix와 cascade로만 부패에 저항한다.

공간이 짧고 안정적으로 기록되었다. 이제 — 도구가 늘어나도 그 짧은 공간이 무너지지 않게 해야 한다. 다음 장은 연결이다.

---

5장. 연결 — 호환성과 확장성

모델 + 도구 = 에이전트

여기서 모델이 에이전트가 된다. 이게 가장 결정적인 구분이다.

모델 자체는 토큰 인 → 토큰 아웃 함수일 뿐이다. 텍스트 생성기다. 에이전트가 아니다. 모델은 두뇌일 뿐이고, 두뇌만으로는 세상에 아무 영향을 못 준다. 파일 하나 못 읽고, 명령 하나 못 실행하고, API 하나 못 부른다.

모델이 에이전트가 되는 순간은 외부 도구가 연결되는 순간이다. 도구는 모델의 손과 발이다. Read, Write, Edit는 파일 시스템에 닿는 손. Bash는 셸을 실행하는 발. WebSearch, WebFetch는 인터넷에 닿는 더듬이. MCP 서버는 외부 서비스에 닿는 인공 신경. Subagent는 격리된 컨텍스트에서 일하는 분신.

모델 + 도구 = 에이전트. 이게 공식이다.

도구 없이는 그냥 챗봇이고, 도구가 붙는 순간부터 에이전트라 부른다. 그래서 연결 요소가 — 단순 옵션이 아니라 에이전트의 정체성이다.

Claude Code의 약 40 도구 + MCP

Claude Code에는 도구가 약 40개 기록되어 있다. 파일 도구로 Read, Write, Edit, MultiEdit. 검색 도구로 Glob, Grep. 실행 도구로 Bash. 웹 도구로 WebSearch, WebFetch. 계획 도구로 TodoWrite, Plan. 그리고 Task tool — 서브에이전트를 호출하는 도구.

여기에 MCP(Model Context Protocol)가 있다. Anthropic이 표준화한 외부 도구 통합 프로토콜이다. JSON-RPC 기반으로, 사용자가 만든 MCP 서버를 Claude Code에 붙이면 그 서버의 도구들이 Claude Code의 도구로 등록된다. GitHub MCP, Slack MCP, Database MCP — 어떤 외부 서비스든 MCP로 박을 수 있다.

Tool.ts 베이스만 약 29,000줄. 그중 상당량이 도구별 권한 분리 코드다. 각 도구마다 독립된 permission gate가 있다. Read가 허용돼도 Write는 별도 허용이 필요하다. 단일 글로벌 권한이 아니다.

호환성과 확장성

연결 요소를 한 단어로 표현하면 호환성이고, 또 한 단어로 표현하면 확장성이다.

호환성이란 — 어떤 도구를 붙여도 잘 동작한다는 뜻이다. Claude Code가 처음부터 알지 못한 도구라도, MCP 표준만 따르면 즉시 붙는다. Subagent에게 다른 도구 셋을 주어도 — 같은 인터페이스로 결과가 돌아온다. 확장성이란 — 도구가 늘어나도 시스템이 무너지지 않는다는 뜻이다. 10개에서 50개로 늘어도 — 권한 분리가 도구별로 기록되어 있고, Subagent 격리로 컨텍스트 부풀림이 막혀 있고, ToolSearch로 도구 정의가 on-demand 로드된다.

여기서 4요소의 trade-off가 명확해진다. 연결을 늘리면 공간이 부담을 받는다. 도구 정의가 컨텍스트를 먹는다. 연결을 늘리면 시간이 부담을 받는다. 도구 선택 분기가 늘어 한입이 깨진다. 연결을 늘리면 검증이 부담을 받는다. 외부 도구마다 검증 레이어가 필요하다. 무한정 연결은 4요소 전부를 약화시킨다.

Subagent + Mailbox 격리

Claude Code의 가장 흥미로운 패턴 중 하나는 Multi-Agent 패턴이다.

Lead Agent가 메인 세션이다. 사용자와 대화한다. 큰 작업이 들어오면 Subagent를 Task tool로 호출한다. 각 Subagent는 격리된 컨텍스트를 가지고, 자기 작업만 해서 결과를 반환한다. 여러 Subagent가 병렬 실행 가능하다.

Mailbox 패턴이 권한의 묘미다. Subagent가 작업 중 위험한 것을 만나면 — 단독으로 결정 못 한다. Lead의 mailbox에 요청을 보내고 대기한다. Lead가 평가해서 승인 또는 거부 — 그 결과로 Subagent가 재개된다.

왜 이렇게 설계했는가. 셋이 묶여 있다. 공간 분리 — Subagent가 격리된 컨텍스트를 가지니까 Lead의 컨텍스트가 안 부풀음. 시간 병렬화 — 여러 Subagent가 동시에 도니까 처리량 증가. 권한 격리 — Subagent는 위험 작업을 직접 승인 못 한다. 반드시 Lead의 결정을 거친다.

이 셋을 한 패턴이 동시에 푼다는 게 핵심이다. 그리고 — 본 위키의 HIAO 1-N-N 패턴이 정확히 이 구조다. Master + Cluster Manager + Specialized Agent. 우리가 외부적으로 의식해서 박은 그 패턴이 — 역으로 Claude Code 안에서도 동작하고 있다.

7장에서 이 HIAO 패턴을 본격적으로 다룬다.

MCP의 4요소 trade-off

MCP는 매력적이다. 외부 서비스를 즉시 도구로 붙일 수 있다. 그래서 사람들이 무한정 MCP를 추가하는 본능에 빠진다. 도구 많을수록 에이전트가 강해진다고 믿는다.

그런데 그 본능이 4요소 전체를 약화시킨다.

도구 폭발 — 너무 많이 연결되어 모델이 잘못된 도구를 선택한다. 컨텍스트 윈도우가 잠식된다. 도구 실종 — 핵심 MCP가 죽거나 인증이 만료되면 에이전트가 멎거나 환각으로 메운다. 손발 마비. 처방은 절제와 격리다. 필요한 도구만 노출, 도구 헬스체크, Subagent로 도구 셋 격리. depth=1로 재귀 폭발 방지.

연결은 격리와 절제로만 안전해진다.

연결이 호환·확장으로 기록되었다. 그러나 도구가 잘 닿아도 — 잘못된 결과 위에 잘못된 결과가 쌓이면 무너진다. 다음 장은 검증이다.

---

6장. 검증 — 시간이 지날수록 좋아지는 시스템

가소성 — 지식이 자라는 조건

검증은 에이전트의 건강검진이다. 자기 자신과 자기가 만든 결과물을 점검하는 메커니즘이다.

검증 없이 도는 에이전트는 잘못된 코드 위에 잘못된 코드를 쌓는다. 한 번 만든 코드는 틀린 채로 굳고, 한 번 내린 결정은 잘못된 채로 누적된다. 검증 메커니즘이 작동해야 비로소 잘못 됐다가 발견되고, 발견되어야 갱신된다.

검증의 본질은 가소성이다. 신경망에서 빌려온 용어인데, 에이전트 맥락에서는 — 기존 지식·결정·산출물이 새 정보에 의해 갱신될 수 있는 능력을 뜻한다. 검증 없이는 가소성도 없다. 가소성 없이는 지식이 자라지 않는다.

검증은 가소성의 전제이고, 가소성은 지식 성장의 조건이다.

이게 검증 요소가 가져오는 가장 큰 효과다. 검증 부재라면 — 잘못이 발견 안 되고, 잘못 위에 잘못이 쌓이고, 한 번 굳으면 안 갱신되고, 지식이 자라지 않는다. 시스템이 시간이 지날수록 망가진다. 검증이 작동하면 — 잘못이 발견되고, 갱신되고, 가소성이 작동하고, 지식이 자라고, 시스템이 시간이 지날수록 좋아진다.

건강검진과 가드레일

검증은 두 얼굴을 갖는다. 건강검진과 가드레일.

건강검진은 — 정합성과 일관성과 목표 지향을 본다. 코드가 의도한 대로 짜였는가. 모듈 간 인터페이스가 일관되는가. 지난 한입의 결정이 이번 한입과 충돌하지 않는가. 작업이 원래 목표 방향으로 가고 있는가. 이 모든 게 건강검진의 영역이다.

가드레일은 — 막강한 AI 도구가 방향성 있게 일하도록 하는 보호장치다. rm -rf / 같은 위험 명령을 차단한다. 비밀키를 외부로 흘리지 않게 한다. 사용자가 명시한 룰을 강제한다. 권한이 없는 작업을 막는다. 가드레일은 막는 일이다. 건강검진은 점검하는 일이다. 둘 다 검증이다.

그리고 한 가지 더 — 검증 자체도 계층적·구조화 되었는지를 검증한다. 이게 검증의 메타 차원이다. 검증 시스템이 잘 짜였는가를 검증하는 일. 이게 시간이 지날수록 검증 시스템 자체가 자라나게 만드는 메커니즘이다.

Hooks — 검증의 사용자 통제점

Claude Code의 Hooks는 검증 요소의 사용자 통제점이다. 공간 요소에서 CLAUDE.md가 사용자 통제점이라면, 검증 요소에서는 Hooks다.

Hooks는 6 이벤트, 3 카덴스로 분류된다. 세션 카덴스 — SessionStart, SessionEnd. 세션 시작·종료할 때 한 번씩. 턴 카덴스 — UserPromptSubmit(사용자 메시지 보낼 때), Stop(Claude가 end_turn한 후). 도구 호출 카덴스 — PreToolUse(모든 도구 실행 직전), PostToolUse(직후). 매 턴 도구 5개 쓰면 PreToolUse와 PostToolUse가 5번씩 호출된다.

Hooks가 받는 인자는 JSON으로 도구명, 도구 인자, 세션 ID, transcript 경로. 우리가 만든 외부 스크립트가 그 JSON을 받아서 처리한다. 그리고 Hooks가 반환하는 additionalContext가 다음 도구 결과에 prepend된다. 즉 Hook으로 Claude가 다음 턴에 더 많은 정보를 보게 만들 수 있다. 검증이 단순 차단이 아니라 컨텍스트 보강까지 한다.

Hooks의 강한 점은 — Anthropic의 권한 시스템보다 강하다는 것이다. PreToolUse 훅이 allow를 반환하면 Claude Code의 권한 시스템을 bypass한다. 우리가 박은 룰이 최종 권한이다.

실용 패턴 4가지만 박아 둔다. PreToolUse(Edit) — 변경 전 git stash 백업. 가소성: 잘못된 변경을 되돌릴 수 있음. PostToolUse(Edit) — 변경 후 prettier와 eslint 자동 실행. 성장: 매 변경이 검증된 후 누적. PostToolUse(Bash) — 위험 명령 감지 시 알림. 가소성 보호. Stop — 턴 종료 시 대화 요약을 외부 파일에 추가. 성장: 세션 간 지식 누적.

부재 vs 과잉 — 성장 정지 vs 진행 정지

검증 요소가 깨지는 모습은 양 극단이다.

검증 부재는 성장 정지다. 가드레일 없으면 rm -rf 실행, 비밀키 노출. 자기검증 없으면 잘못된 결과 위에 계속 쌓아 올림. 가소성 제로 — 한 번 굳으면 안 갱신. 지식이 자라지 않는다.

검증 과잉은 진행 정지다. 정상 작업까지 매번 승인 요청. 모든 호출이 막힌다. 가소성은 있지만 활용 안 됨.

처방은 permission_mode를 작업 위험도에 맞게 분리하는 것이다. 읽기 전용 작업은 acceptEdits — 자동 진행. 일반 코딩 작업은 default — 위험 작업만 승인. 배포·삭제 작업은 default 강 — 모든 destructive 작업 승인. 디버그 격리는 bypassPermissions — sandbox 내 자유 실행.

검증 요소의 시간 차원이 가장 중요하다. 1턴, 5턴에서는 차이 안 보인다. 30턴, 100턴 가야 드러난다. 그래서 검증 요소가 가장 자주 무시된다. 즉시 보상이 없으니까. 그러나 6개월 가면 — 검증을 박은 사람과 안 박은 사람의 차이가 결정적이다.

PostSampling — 시스템 측 마지막 레이어

검증 요소의 마지막 레이어는 시스템 측에 있다. PostSampling이다. Anthropic이 경쟁사의 distillation 학습을 막기 위해 박은 메커니즘이다.

메커니즘은 셋이다. Fake Tool Definitions — 시스템 프롬프트에 실재하지 않는 도구를 일부 섞어 둔다. 정상 사용에서는 모델이 안 부르도록 학습됐다. 그런데 누가 응답을 그대로 학습 시키면 그 가짜 도구가 같이 학습된다. 거기서 잡힌다. Summarized Reasoning — 모델의 전체 reasoning을 다 보여주지 않는다. PostSampling 단계에서 축약 요약으로 치환된다. Watermark — 응답에 통계적 시그니처를 삽입한다. 다른 모델이 학습하면 추적 가능하다.

이게 우리에게 시사하는 — 검증 요소는 사용자 측(Hooks)과 시스템 측(PostSampling)의 양 끝에서 작동한다. Hooks는 우리가 기록하는 검증, PostSampling은 Anthropic이 기록하는 검증. 두 검증 사이에 모델 응답이 있다.

좋은 시스템은 시간이 지날수록 좋아진다. 그게 검증 요소가 가져오는 효과다.

4요소를 한 장씩 박았다. 이제 — 이 넷을 어떻게 한 손에 쥐는가. Part 3 — 실전 적용으로 가자.

---

---

7장. HIAO와 한입감과 가드레일 — 4요소 균형의 실무

4요소 균형의 어려움

지금까지 4요소를 한 장씩 보았다. 한 요소만 풀면 다른 요소가 깨진다는 것을 반복해서 보았다. 한입이 깨지면 부패가 시작되고, 부패가 시작되면 도구가 잘못 선택되고, 잘못 선택된 도구의 결과를 검증 안 하면 다음 한입이 또 깨진다.

그러니 4요소는 따로 풀 수 없다. 한 손에 4요소를 같이 쥐어야 한다. 그게 실무의 어려움이다.

다행히 4요소를 동시에 푸는 패턴이 있다. 그 패턴이 HIAO 1-N-N이다. 그리고 그 패턴 위에 한입과 가드레일이 얹어진다. 이 셋이 — HIAO, 한입, 가드레일 — 실무에서 4요소 균형을 잡는 세 도구다.

HIAO 1-N-N 패턴

HIAO는 Hierarchical Input-Agent-Output의 약자다. 본 위키 운영 골격으로 채택한 1-N-N 계층 구조를 가리킨다.

Level 1은 Master Orchestrator. 한 명. 전략을 수립하고, 도메인을 3-4개로 분해하고, 충돌을 조정한다. 추상 Input을 도메인별 Instruction으로 풀어 낸다. Level 2는 Cluster Managers. 3-4명. 도메인 내 워크플로우를 설계하고, 하위에 분배하고, 결과를 취합한다. 추상 Instruction을 구체 시나리오로 풀어 낸다. Level 3는 Specialized Agents. 9-16명. 단일 목적 atomic task를 수행하고, 도구를 사용하고, 보고한다. 구체 Instruction을 데이터 Output으로 만든다.

각 계층의 사이클은 같다. Input(상위 지시) → Agent(페르소나가 사고) → Output(상위로 보고). 위에서 아래로는 점점 구체적·기술적인 지시가 흐른다. 아래에서 위로는 점점 요약·가치중심 인사이트가 흐른다.

왜 1-N-N인가. 한 명의 지휘자가 16명을 직접 지휘하면 — 컨텍스트가 폭발한다. 지휘자가 모든 상세를 알아야 하기 때문이다. 중간 팀장이 있으면 — 지휘자는 도메인 단위 지시만 하고, 팀장이 그 도메인의 상세를 풀어 낸다. 각 계층이 자기 추상 수준에서 일한다. 컨텍스트가 분산된다.

Subagent + Mailbox = HIAO의 동형

5장에서 이미 본 것이지만 — Claude Code의 Subagent + Mailbox 패턴이 정확히 HIAO의 동형이다. Lead = Master Orchestrator. Subagent = Cluster Manager 또는 Specialized Agent. Mailbox = 위계 간 검증 게이트.

이게 우연이 아니라는 게 핵심이다. 4요소를 동시에 풀려는 본능이 — 결국 같은 구조에 수렴한다. Anthropic이 Claude Code 안에서 박은 패턴, 본 위키가 외부에서 박은 패턴, 그리고 — 일반적인 큰 조직의 작업 분배 구조 — 셋 다 같은 본능이다. 작업이 커지면, 위계가 답이다.

작업이 커지면, 위계가 답이다.

한입과 HIAO의 결합

HIAO 위계가 작동하려면 — 각 Specialized Agent가 받는 작업이 한입 크기여야 한다.

한 Cluster Manager가 자기 도메인의 작업을 받으면 — 그것을 9-16개의 한입으로 분해해서 Specialized Agents에게 분배한다. 각 한입은 3-5턴에 수렴하는 작업이다. 9-16개가 끝나면 Cluster Manager가 결과를 취합해서 Master에게 보고한다.

이 패턴이 시간 요소(한입)와 연결 요소(계층)를 동시에 푼다. 한입이 시간을 안전하게 만들고, 계층이 연결을 확장 가능하게 만든다. 그리고 — 이 두 요소가 같이 작동하니까 공간 요소도 자동으로 보호된다. 각 Specialized Agent가 자기 한입의 컨텍스트만 보유하고, Master는 도메인 추상 수준의 컨텍스트만 보유한다. 부패가 부풀 자리가 없다.

가드레일이 묶어 준다

HIAO 위계와 한입 분해까지 박았다. 이제 마지막 한 요소 — 검증. 검증을 묶어 주는 게 가드레일이다.

HIAO에서 가드레일은 두 차원에서 작동한다. 수직 가드레일은 — 위계 간 검증. Subagent가 위험 작업을 만나면 단독 결정 못 한다. Lead의 mailbox에 요청을 보낸다. Lead가 평가해서 승인 또는 거부. 이게 수직 검증이다. 수평 가드레일은 — 같은 계층 안의 검증. Specialized Agent가 자기 한입을 끝낼 때마다 — Pre/PostHook이 작동해서 lint, 테스트, diff 검토가 자동 실행된다. 이게 수평 검증이다.

수직과 수평 가드레일이 같이 작동하면 — 4요소가 묶인다. 시간(한입)이 가드레일로 종료 조건을 갖고, 공간(부패)이 가드레일로 컨텍스트 폭발을 막고, 연결(도구)이 가드레일로 권한 누수를 막고, 검증(가소성)이 가드레일 자체로 작동한다. 4요소가 하나의 운영 시스템으로 굴러가기 시작한다.

HIAO가 위계를 박고, 한입이 단위를 박고, 가드레일이 묶어 준다.

4요소 균형의 패턴은 기록되었다. 그런데 — 작업이 들어왔을 때 어떻게 시작하는가. 다음 장은 설계도 그리기다.

---

8장. 설계도를 그려라 — 레이어가 보일 때까지

바이브 코딩의 함정 — 프롬프트에서 즉시 코드로

바이브 코딩에는 강한 함정이 하나 있다. 프롬프트를 박으면 AI가 즉시 코드를 쏟아 낸다는 점이다.

이 즉시성이 마법이지만 동시에 함정이다. 사용자가 요구사항을 말하자마자 — AI는 코드 생성을 시작한다. 사용자도 그 즉시성에 끌려간다. 한 줄 박고, 한 줄 받고, 또 한 줄 박고. 그러다 보면 — 설계 없이 코드가 만들어진다. 급하게 덤빈 결과다.

본 강의 시리즈의 표어가 여기서 가장 강하게 기록된다. 설계 없이는 코딩이 안된다. 바이브 코딩이라고 해서 설계가 면제되는 게 아니다. 오히려 바이브 코딩이라서 설계가 더 중요하다. AI는 설계가 없어도 일단 코드를 만들어 내기 때문이다. 잘못된 설계 위에서 일단 만든 코드가 — 가장 위험한 산출물이다.

환경적 요인과 요구사항 분석

설계도를 그리기 전에 두 가지를 본다. 환경적 요인과 요구사항.

환경적 요인이란 — 이 작업이 놓이는 맥락이다. 어떤 시스템 위에서 동작하는가. 어떤 사용자가 쓰는가. 어떤 제약이 있는가(시간, 예산, 호환성, 보안). 어떤 도구가 사용 가능한가. 어떤 도구는 못 쓰는가. 이 모든 게 환경 분석이다.

요구사항이란 — 이 작업이 무엇을 해야 하는가다. 기능 요구사항(무엇을), 비기능 요구사항(어떻게), 수용 기준(언제 끝났는가). 그리고 가장 중요한 — 한입의 단위. 이 작업을 어떻게 자를지. 한입의 단위가 곧 작업 단위 설계의 출발점이다.

여기서 4요소가 분석의 도구가 된다. 시간 관점에서 — 이 요구사항을 어떻게 한입 N개로 자를까. 공간 관점에서 — 각 한입의 컨텍스트가 200K 안에 들어가는가. 연결 관점에서 — 어떤 도구가 필요한가. MCP가 더 필요한가. 검증 관점에서 — 각 한입의 검증 기준은 무엇인가.

레이어가 보일 때까지 분석

여기서 가장 중요한 동사가 등장한다. — 분석하고, 또 분석하라.

처음 요구사항을 들으면 — 그것은 평면처럼 보인다. X 시스템을 만든다. Y 기능을 추가한다. Z 버그를 고친다. 한 줄로 기록된다. 그런데 그 한 줄을 풀어 보면 — 안에 여러 레이어가 숨어 있다. 데이터 레이어, 비즈니스 로직 레이어, 인터페이스 레이어, 배포 레이어. 또 풀어 보면 — 각 레이어 안에 여러 모듈이 숨어 있다. 또 풀어 보면 — 각 모듈 안에 여러 한입이 숨어 있다.

분석을 멈출 시점은 — 레이어가 보일 때까지다. 한 평면에서 시작해서 — 여러 레이어가 자연스럽게 떠오를 때까지 분석한다. 레이어가 안 보이면 — 아직 분석이 부족한 것이다.

레이어가 보이는 순간 — 작업이 자연스럽게 분배 가능해진다. 각 레이어가 한 도메인이 되고, 각 도메인이 한 Cluster Manager의 책임이 된다. 이게 HIAO 1-N-N 분해의 출발점이다.

서브 오케스트레이터가 보일 때까지

레이어가 보이면 다음 단계는 — 서브 오케스트레이터가 보일 때까지 더 분석하는 것이다.

여기서 자주 빠지는 함정이 — 지휘자 혼자 다 해버리려는 본능이다. 특히 바이브 코딩에서는 프롬프팅하면 바로 코드를 내쏟아 내기 때문에 — 지휘자(Master Orchestrator)가 모든 디테일까지 자기가 잡으려고 한다. 그러나 16명을 직접 지휘하는 건 — 지휘자의 컨텍스트를 폭발시킨다.

중간 단계의 팀장 — Cluster Manager — 의 역할이 분명해져야 한다. 각 도메인을 책임지고, 그 도메인의 한입들을 분배하고, 결과를 취합해서 지휘자에게 보고하는 역할. 이 중간 팀장이 명확해질 때까지 분석을 계속한다.

서브 오케스트레이터가 보이는 순간 — 에이전트들이 계층적·구조화되어 간다. 그리고 동시에 — 에이전트 간에 어떤 정보가 오고 가야 할지가 명확해진다. 지휘자는 도메인 추상 지시만 보낸다. 팀장은 도메인 안의 구체 시나리오로 풀어서 실무자에게 보낸다. 실무자는 한입 결과를 팀장에게 보고한다. 팀장은 도메인 결론을 지휘자에게 올린다.

지침서가 작성되기 시작하는 지점

에이전트 간 정보 흐름이 명확해지는 그 지점이 — 지침서가 작성되기 시작하는 지점이다.

지침서는 — 각 계층이 어떻게 일할지, 무엇을 받고 무엇을 주는지, 어떤 검증을 거치는지를 박은 문서다. Master를 위한 지침서, Cluster Manager를 위한 지침서, Specialized Agent를 위한 지침서. 각각 추상 수준이 다르다.

왜 지침서가 필요한가. AI 에이전트는 매번 같은 사람이 아니다. 한 세션의 Lead가 다음 세션의 Lead와 다른 컨텍스트를 갖는다. 그러나 지침서가 있으면 — 어느 세션의 Lead든 같은 방식으로 일한다. 지침서가 일관성을 기록하는 도구다.

그리고 지침서가 — 4요소 균형을 운영 차원에서 기록하는 가장 강한 도구다. 지침서에 한입의 크기가 기록되어 있고(시간), CLAUDE.md 200줄 규칙이 기록되어 있고(공간), MCP 절제 원칙이 기록되어 있고(연결), Hooks 패턴이 기록되어 있다(검증). 지침서가 4요소를 한 자리에 묶는다.

에이전트 간 정보 흐름이 명확해지는 지점이 지침서가 작성되기 시작하는 지점이다.

본 위키의 CLAUDE.md, WIKI_CLAUDE.md, WIKI_GUIDE.md가 정확히 이 지침서들이다. 어디에(CLAUDE.md), 무엇으로(WIKI_CLAUDE.md), 왜·어떻게(WIKI_GUIDE.md). 각각이 다른 추상 수준에서 작동하고, 함께 4요소 균형을 운영한다.

설계도가 그려졌다. 이제 마지막 — 그 설계도와 산출물이 사람에게 어떻게 보이게 할 것인가. 다음 장으로 가자.

---

9장. 사람이 볼 수 있게 하자 — 개입과 정체성과 경계

AI 산출물의 두 종류

AI가 만드는 산출물에는 두 종류가 있다. 최종 결과물과 중간 결과물.

최종 결과물은 — 우리가 사용자에게 보여 주려고 만든 것이다. 완성된 코드, 완성된 보고서, 완성된 슬라이드. 사람이 읽고 이해할 수 있게 만드는 게 당연하다. 그래야 가치가 있다.

그런데 중간 결과물은 다르다. AI가 작업 중에 만드는 것들 — 한입 단위의 부분 출력, 도구 호출 로그, 에이전트 간 메시지, 검증 결과, 임시 파일. 사람이 안 봐도 작업은 굴러간다. AI끼리 주고받으면 된다. 그래서 보통 — 중간 결과물의 가독성은 무시된다. AI가 알아보면 충분하다고.

이 책의 마지막 메시지는 — 그 가정을 뒤집어야 한다는 것이다.

왜 중간 결과물인가 — 개입과 정체성과 경계

중간 결과물도 사람이 읽고 이해할 수 있게 만들어야 한다. 세 가지 이유 때문이다.

첫째는 개입(intervention)이다. 바이브 코딩이지만 중간 중간 사람이 개입할 수 있어야 한다. AI가 잘못된 방향으로 가고 있을 때, 한입의 결과가 의도와 다르게 나왔을 때, 사람이 즉시 멈추고 방향을 잡을 수 있어야 한다. 그러려면 사람이 중간 결과물을 읽을 수 있어야 한다. 읽을 수 없으면 — 끝나고 나서야 잘못을 발견한다. 그땐 이미 돌이킬 수 없다.

둘째는 정체성(identity)이다. 이 시스템이 무엇을 하고 있는가. 사람이 책임지는 시스템인가, AI가 알아서 하는 시스템인가. 중간 결과물이 사람 가독이면 — 사람이 그 시스템의 일부로 일한다. 사람의 정체성이 기록된다. 중간 결과물이 사람 비가독이면 — AI가 블랙박스로 일한다. 사람의 정체성이 사라진다. 시스템이 마법처럼 굴러가는데 — 사람은 결과만 받는다.

셋째는 경계(boundary)다. 어디까지 AI가 하고, 어디부터 사람이 하는가. 중간 결과물이 사람 가독이면 — 그 경계가 명확해진다. 사람이 검토할 수 있는 자리에서는 사람이, AI가 처리할 수 있는 자리에서는 AI가. 경계가 흐려지면 — 책임이 흐려진다. 잘못이 일어나도 누구의 잘못인지 모른다.

사람을 위한 것이기에 — 능력 vs 책임

여기서 흔한 오해가 하나 있다. 중간 결과물을 사람 가독으로 만드는 이유가 — 사람의 능력이 뛰어나서가 아니라는 점이다.

AI가 코드를 더 잘 짤 수 있다. AI가 검증을 더 정확하게 할 수 있다. AI가 패턴을 더 빨리 발견할 수 있다. 능력의 문제가 아니다.

그러면 왜 사람이 봐야 하는가. 책임의 문제다.

이 시스템은 사람을 위한 것이다. 사용자가 사람이고, 결정권자가 사람이고, 책임자가 사람이다. AI는 도구다. 도구가 일을 잘하더라도 — 책임은 도구를 쓴 사람에게 있다. 그 책임을 지려면 — 도구가 무엇을 했는지 알아야 한다. 그러려면 중간 결과물이 사람 가독이어야 한다.

능력의 문제가 아니라 책임의 문제다. 사람이 사용하기 때문이고, 사람을 위한 것이기 때문이다.

이 한 줄이 9장의 핵심이다. 중간 결과물의 가독성은 — AI 시대에 사람의 자리를 기록하는 도구다. 이게 없으면 사람의 자리가 없어진다.

읽힐 수 있게 만드는 5가지 원칙

중간 결과물을 사람 가독으로 만드는 5가지 원칙이 있다.

첫째, 가독성. 자연어로 박으라. JSON이라도 이름을 명확하게. 둘째, 구조. 한 출력 안에 — 무엇을 했고, 어떤 결정을 내렸고, 다음 단계가 무엇인지가 보여야 한다. 셋째, 이름. 변수명, 파일명, 에이전트명이 — 그 자체로 의미가 박혀야 한다. agent1, agent2가 아니라 design-reviewer, code-builder 같은 이름. 넷째, 로그. 의사결정의 흔적이 남아야 한다. 왜 이 도구를 골랐는지, 왜 이 한입으로 잘랐는지. 다섯째, 요약. 한 한입 끝날 때마다 — 한 줄 요약이 박혀야 한다. 사람이 100개 한입 결과를 다 읽을 수는 없다. 요약을 읽고, 필요할 때만 상세로 들어간다.

이 5가지가 박히면 — 중간 결과물이 사람 가독이 된다. 그리고 흥미로운 건 — 5가지가 박히면 AI도 더 잘 일한다. 이름이 명확하면 도구 선택이 정확해진다. 로그가 남으면 검증이 작동한다. 요약이 박히면 부패가 늦춰진다. 사람을 위한 가독성이 — 결국 AI를 위한 가독성이기도 하다.

4요소가 다시 보이는 순간

마지막 관찰. 중간 결과물을 사람 가독으로 만들기 시작하면 — 4요소가 다시 보이기 시작한다.

시간이 보인다. 한입의 단위가 사람이 읽을 만한 크기인지가 자연스럽게 점검된다. 한입이 너무 크면 사람이 못 읽는다. 자른다. 한입의 미학이 살아난다. 공간이 보인다. 중간 결과물이 부풀면 사람이 못 읽는다. 짧게 자른다. 부패 저항이 살아난다. 연결이 보인다. 어떤 도구가 이 한입을 처리했는지가 명시된다. 도구 분배가 명확해진다. 검증이 보인다. 한 한입의 검증이 어떻게 작동했는지가 로그로 남는다. 가소성이 살아난다.

즉 사람 가독은 — 4요소를 다시 강제하는 메커니즘이다. 사람이 볼 수 있게 만들면 4요소가 명확해지고, 4요소가 명확해지면 바이브 코딩의 의미가 보이고, 바이브 코딩의 의미가 보이면 — 우리가 실수하지 않게 된다. 이게 본 책의 마지막 메시지다.

4요소가 다시 보인다. 그리고 — 바이브 코딩의 의미도 보인다. 마치며로 가자.

---

마치며 — 4바퀴가 굴러가게 하라

책의 한 줄 — 다시 박기

이 책의 모든 메시지가 한 줄로 모인다.

AI-Native Vibe Coding: No Design, No Code. 설계 없이는 코딩이 안된다.

이 한 줄이 — 4요소 위에서 4번 기록되었다. 시간을 설계하지 않으면 무한 루프가 된다. 공간을 설계하지 않으면 부패한다. 연결을 설계하지 않으면 도구가 폭발한다. 검증을 설계하지 않으면 가소성이 죽는다.

4요소는 결국 4가지 설계의 형태다. 시간 = 작업 단위 설계(한입). 공간 = 컨텍스트 설계(부패 저항). 연결 = 위계 설계(HIAO 계층, 호환·확장). 검증 = 가소성 설계(건강검진과 가드레일).

4요소의 다중 은유 — 다시

들어가며에서 박은 4요소의 다중 은유를 마지막으로 다시 기록한다.

4관점으로 부르면 — 같은 시스템을 4가지 시야로 보는 일이다. 디버깅할 때 어디부터 볼지를 결정한다. 4축으로 부르면 — 분석의 좌표계가 된다. 4 곱하기 4 매트릭스로 진단한다. 각 축의 한도, 관측, 실패 동작, 튜닝 레버를 기록한다. 4바퀴로 부르면 — 바이브 코딩이 그 위에서 굴러가는 일이다. 한 바퀴라도 빠지면 굴러가지 않는다. 4기둥으로 부르면 — 만들어 낸 서비스나 플랫폼을 지탱하는 구조가 된다. 한 기둥이 약하면 그 위의 모든 것이 무너진다.

부르는 이름은 그때그때 다르다. 같은 넷을 — 보고, 분석하고, 굴리고, 떠받친다. 같은 4요소가 상황에 따라 다른 도구가 된다. 그래서 혼용 가능하다.

시니어이면서 AI 네이티브의 다음 한 걸음

이 책은 시니어이면서 AI 네이티브가 발견해 가고 있는 중간 보고서다. 발견 → 운영 → 전수의 세 단계 중 — 발견의 단계를 박았다.

다음 단계는 운영이다. 각자의 워크플로우에 4요소를 얹어서 — 어떤 바퀴가 약한지, 어떤 기둥이 흔들리는지, 어떤 축이 비어 있는지를 측정한다. 본문 부록 A의 4×4 매트릭스 워크시트를 채워 보시기 바란다. 16칸이 다 채워지면 시스템이 견고하다. 비어 있는 칸이 그 시스템의 취약점이다.

그리고 그 다음은 전수다. 다른 시니어, 다른 AI 네이티브에게 — 이 4요소를 전달한다. 각자의 도메인에 맞게 변형되고, 새로운 은유가 더해지고, 어쩌면 5번째, 6번째 요소가 발견될 수도 있다. 이 책은 그 시작점이지 종착점이 아니다.

마지막 한 줄

바이브 코딩은 마법처럼 시작된다. 프롬프트 한 줄에 코드가 쏟아지고, 한 시간이면 프로토타입이 굴러간다. 그 마법이 — 한 주 가면 무한 루프가 되고, 한 달 가면 부패한 컨텍스트가 되고, 세 달 가면 망가진 시스템이 된다.

마법이 시스템이 되려면 — 4바퀴가 같이 굴러가야 한다. 시간(한입), 공간(부패 저항), 연결(호환·확장), 검증(가소성). 이 넷을 의식하는 사람의 시스템은 — 시간이 지날수록 좋아진다. 이 넷을 의식하지 못하는 사람의 시스템은 — 시간이 지날수록 망가진다.

그래서 책의 마지막 한 줄은 한 명령형이다.

4바퀴가 굴러가게 하라.

그게 바이브 코딩이 마법에서 시스템으로 바뀌는 자리다. 그게 시니어이면서 AI 네이티브가 발견한 길이다. 그게 — 이 책이 박은 한 가지다.

끝.

---

부록 A. 4×4 진단 매트릭스 워크시트

본인 워크플로우에 4요소를 적용해 보시기 바란다. 각 칸에 — 현재 본인이 박아둔 것 — 을 적는다. 비어 있다면 다음 한 주의 작업으로 채운다.

16칸이 다 차야 시스템이 견고하다. 비어 있는 칸이 그 시스템의 취약점이다.

4×4 매트릭스 — 한도, 관측, 실패, 튜닝 × 4요소

각 요소에 같은 4가지 질문을 던진다.

한도(Cap)는 — 이 요소의 상한선을 어디에 두었는가다. 시간 요소라면 max_turns, 공간 요소라면 token budget, 연결 요소라면 도구 수 한도, 검증 요소라면 가드레일 범위.

관측(Signal)은 — 이 요소가 어떻게 굴러가는지 어떻게 측정하는가다. 시간 요소는 turn count, 공간 요소는 token usage, 연결 요소는 tool error rate, 검증 요소는 test/lint fail rate.

실패 동작(Fallback)은 — 이 요소가 한도에 닿거나 깨지면 무엇이 일어나는가다. 시간은 강제 종료, 공간은 컴팩션, 연결은 도구 fallback, 검증은 사람 호출.

튜닝 레버(Knob)는 — 이 요소를 운영 중에 어떻게 조절하는가다. 시간은 maxTurns / Plan, 공간은 CLAUDE.md, 연결은 MCP 선택 / Subagent, 검증은 permission_mode / Hook.

워크시트 — 본인이 직접 채우기

다음 4 × 4 = 16 칸을 채워 본다. 빈 칸이 다음 작업이다.

이 워크시트를 한 달 후에 다시 펼쳐 보시기 바란다. 이전에 비어 있던 칸이 채워졌는지 — 그것이 본인 시스템의 진화를 측정하는 가장 단순한 방법이다.

---

부록 B. 4요소 어휘 일관성 표

본 책에서 4요소를 부르는 단어를 일관되게 박았다. 독자가 본인의 글이나 발표에서 4요소를 다룰 때 — 같은 어휘 시스템을 쓰면 좋다. 다음은 본 책이 사용한 어휘다.

통합 부름 — 4요소를 한꺼번에 부르는 단어

4요소를 통합해서 부르는 단어로 — 4관점, 4축, 4바퀴, 4기둥, 4구성요소가 있다. 본문에서 문맥에 맞게 혼용한다.

디버깅 맥락에서는 4관점이 어울린다. 분석 매트릭스 맥락에서는 4축이 어울린다. 운영 맥락에서는 4바퀴가 어울린다. 구조 맥락에서는 4기둥이 어울린다. 그리고 책의 정체성을 박을 때는 4구성요소.

각 요소의 대표 어휘 + 조연 어휘

시간 요소

대표 어휘 — 루프 조연 어휘 — 한입, 쿼리 루프, 도는 것, 7 transition, 5 recovery

공간 요소

대표 어휘 — 부패(의 막음) 조연 어휘 — 한입감, 컨텍스트 윈도우, 채우는 것, 짧고 안정적, Compaction 5층, 7 정적 + 13 동적, CLAUDE.md 200줄

연결 요소

대표 어휘 — 호환성·확장성 조연 어휘 — 손과 발, 닿는 것, 도구, 위계, Subagent + Mailbox, MCP, HIAO 1-N-N

검증 요소

대표 어휘 — 건강검진 조연 어휘 — 가소성, 가드레일, 점검, 성장, 정합성, 일관성, 목표 지향, Hooks 6×3, permission_mode, PostSampling

사용 원칙 — 일관성

한 글 안에서는 — 같은 요소를 같은 대표 어휘로 부르는 것이 좋다. 독자가 헷갈리지 않게. 그러나 — 통합 부름(4관점·4축·4바퀴·4기둥)은 문맥에 따라 자유롭게 혼용해도 어색하지 않다.

이게 4요소를 글로 다룰 때의 한 줄 가이드다.

---