대기업의 시스템화(OpenAI·Anthropic·Stripe·LangChain)부터 거장의 규율(Mitchell Hashimoto·Kent Beck), 그리고 코드 경험 제로의 개인(花叔)까지. 일곱 개의 서로 다른 하네스가 어떻게 만들어졌고 무엇을 증명했는지 전수 검토한다.
엔지니어 3명, 5개월, 코드 100만 라인, 수기 0줄. 숫자도 충격적이지만 그 뒤의 방법론이 더 해부할 가치가 있다.
2026년 2월 13일, OpenAI가 블로그 「Harness engineering: leveraging Codex in an agent-first world」를 발표했다. 저자는 Codex 팀의 Technical Staff Member인 Ryan Lopopolo. 글은 길지 않지만 데이터 밀도가 극도로 높다.
가장 반직관적인 데이터 — 3명에서 7명으로 늘린 뒤 1인당 처리량이 오히려 증가했다. Brooks의 법칙(인원 추가는 소통 비용을 지수적으로 늘려 프로젝트를 늦춘다)은 전통 개발에서 거의 철칙이지만 Codex 팀은 이를 깼다. 초기 1인 산출은 전통 엔지니어의 약 0.25배 수준이었으나 후기에는 3–10배로 치솟았다. 이유 — 이들은 코드를 쓰지 않고 AI가 코드를 쓰는 환경을 설계했기 때문이다. 인원 추가는 코드 조율 비용이 아니라 하네스의 완성도를 높였고, 하네스가 완성될수록 각자가 동시에 부릴 수 있는 agent가 늘어났다. Ryan Lopopolo의 표현 — 「팀의 최우선 업무가 코드 작성이 아니라 Codex agent를 신뢰성 있게 동작시키는 일이 되자, 모든 것이 바뀌었다.」
"From the agent's point of view, anything it can't access in-context while running effectively doesn't exist." 당연해 보이지만 이 원칙이 철저한 행동을 강제했다 — 팀은 Google Docs의 기획 문서와 Slack의 의사결정 기록을 전부 코드 저장소로 이관했다. Notion에 아무리 상세한 요구사항을 써도 agent는 한 글자도 보지 못한다.
"When the agent struggles, we treat it as a signal: identify what is missing — tools, guardrails, documentation." agent가 망치면 모델을 탓하지도 파라미터를 만지지도 않는다. agent의 공구함에 무엇이 빠졌는지 — 도구인지, 가드레일인지, 문서인지 — 를 점검한다.
"Encode taste into codebase... if you can articulate what it is about the code you don't like, the next step is to write that down." — 코드의 어디가 마음에 안 드는지 말로 표현할 수 있다면, 다음 단계는 그것을 규칙으로 써 내리는 것이다.
아키텍처 계층도 단단하다 — Types → Config → Repo → Service → Runtime → UI, 고정 방향으로만 의존 가능, 위반 시 CI 불통과.
Ryan의 말 — 「이런 아키텍처는 통상 팀이 수백 명이 될 때까지 미루는 것이다. 그러나 agent-first 개발에서는 가장 이른 전제 조건이다. 제약 자체가 속도의 원천이기 때문이다.」
컨텍스트 엔지니어링과 아키텍처 제약 외에 전담 역할이 하나 더 있다 — 가비지 컬렉션 agent. 코드도 기능도 만들지 않고 주기적으로 돌며 한 가지 일만 한다: 문서의 모순과 아키텍처 위반을 스캔한다. 문제를 발견하면 표적화된 리팩터링 PR을 자동 생성하고, 인간은 1분 안에 리뷰를 끝낸다. 본질적으로 코드베이스의 엔트로피 증가에 맞서는 일이다 — agent가 코드를 많이 쓸수록 비일관성 유입 확률이 높아지므로, 다른 AI가 남긴 혼란을 청소하는 트집 전문 AI가 필요하다.
숫자는 훌륭하다. 그러나 진지하게 생각할 문제가 있다. 속도 10배가 산출 품질 10배를 뜻하지 않는다. 1인당 하루 3.5개의 PR — 누가 충분한 코드 리뷰를 하는가. 6개월 뒤 요구사항이 바뀔 때 이 100만 라인은 고치기 쉬운가. AI가 쓴 코드와 인간이 쓴 코드의 결정적 차이 — 인간은 코드를 쓸 때 미래의 자신이 이해하기 쉽도록 무의식적으로 구조적 단서를 남긴다. AI는 그렇지 않다. 눈앞의 과제만 해결하고, 6개월 뒤 이 코드를 유지보수할 사람을 고려하지 않는다.
Martin Fowler 팀도 이 맹점을 지적했다. Birgitta Böckeler의 분석 — 이 프레임은 내부 품질과 유지보수성에 주목하지만 기능과 행동의 정확성에 대한 검증이 빠져 있다. 하네스는 AI가 빨리 쓰게 할 뿐 아니라 유지보수 가능하게 써야 한다. OpenAI의 실험은 속도를 증명했지만 장기 비용은 여전히 물음표다.
LangChain의 사례가 더 깨끗한 검증이다 — 코딩 agent의 Terminal Bench 2.0 점수가 52.8%에서 66.5%로, 순위는 Top 30에서 Top 5로 뛰었다. 모델은 전혀 바꾸지 않았다. 시스템 프롬프트·도구 구성·미들웨어 훅만 고쳤다. 같은 두뇌에 고삐만 바꿔도 성적은 하늘과 땅 차이다.
OpenAI가 대규모 팀의 시스템화를 대표한다면, Mitchell Hashimoto는 개인 개발자의 소박한 지혜를 대표한다 — agent가 실수한다 → 방어책을 엔지니어링한다 → 영원히 재발하지 않는다.
HashiCorp 공동창업자이며 Terraform·Vagrant·Packer의 창조자. Infrastructure as Code 영역에서 피해 갈 수 없는 인물이다. HashiCorp를 떠난 뒤 Zig로 처음부터 작성한 터미널 에뮬레이터 Ghostty를 전업 개발 중이다. 스스로를 「게임을 사랑해서 물건을 만드는 software craftsman」이라 칭한다. AI 기업 지분이 없어 AI에 대한 관점이 대부분의 사람보다 중립적이다. 2026년 2월 5일 발표한 「My AI Adoption Journey」의 첫 단락부터 매우 Mitchell답다.
대부분의 사람은 1단계에서 4단계로 건너뛴다 — AI가 쓸 만하다 싶으면 바로 위임을 시작한다. Mitchell은 2단계에서 「무용한 일」에 막대한 시간을 썼다. 이미 손으로 끝낸 일을 agent에게 다시 시키는 것. 바로 이 단계가 agent 행동 패턴에 대한 깊은 이해를 만들었고, 이후의 모든 것이 그 위에 세워졌다.
Mitchell은 Ghostty의 AGENTS.md를 GitHub에 공개했다. 모든 줄이 agent의 과거 실수 하나에 대응한다.
루트의 AGENTS.md에는 빌드 명령(zig build, zig build test), 디렉터리 구조, 포매팅 요구가 있다 —
평범해 보이지만 모두 agent가 밟았던 구덩이다. 예컨대 -Dtest-filter로 표적 테스트를 돌리라고 알려 준다.
전량 테스트는 너무 느린데, 이를 모르는 agent는 매번 전량을 돌려 시간을 낭비한다.
.agents/commands/ 디렉터리 — 검증된 agent 명령 모음. 대표작은 Nu 스크립트로 작성한 /gh-issue: GitHub issue를 Markdown으로 포맷해 agent가 문제를 진단하고 근본 원인을 설명하고 방안을 제안하게 유도하되, 코드 직접 작성은 명시적으로 금지한다. Mitchell은 하루 5회 이상 사용한다.Mitchell의 하드라인 — "I'm not shipping code I don't understand." 그는 자신을 software architect로 위치시킨다: 코드 구조·데이터 흐름·상태 관리를 책임지고 agent가 구현 세부를 채운다. 비유는 「bowling with bumpers」 — 범퍼를 세워 두면 공을 어떻게 던져도 도랑에 빠지지 않는다.
Mitchell과 OpenAI를 나란히 놓으면 공통점이 뚜렷하다 — 양쪽 모두 하네스를 미리 설계하지 않았고, 실천 속에서 길러 냈다. OpenAI의 다섯 원칙은 5개월의 실험에서, Mitchell의 AGENTS.md는 agent와의 무수한 씨름에서 나왔다. 화이트보드 앞에서 완벽한 청사진을 그리고 시공한 사람은 없다. Mitchell의 방법은 특히 개인 개발자에게 맞는다 — 관측성 인프라도, 아키텍처 계층화도, 가비지 컬렉션 agent도 필요 없다. 빈 파일 하나와 규율 하나면 된다: agent가 실수하면 규칙 한 줄. 3개월 뒤 그 파일이 곧 하네스다. Simon Willison이 공유하고 Pragmatic Engineer가 심층 보도하고 Martin Fowler 팀이 프레임을 확장한 이유는 방법이 고급이어서가 아니라, 누구나 즉시 시작할 수 있을 만큼 소박하기 때문이다.
Mitchell 방법의 정수는 한 문장이다 — agent가 어떤 실수를 할지 예단하지 마라. 실수하게 두고, 그 구멍을 영구적으로 막아라. 파일이 길어지는 것은 문제가 아니다. 당신의 해자(垓字)가 깊어지는 것이다.
$9로 단일 Agent를 돌리면 20분 만에 결과가 나오지만 핵심 기능이 동작하지 않는다. $200으로 3-Agent 협업을 돌리면 6시간이 걸리지만 완전히 동작한다. 비용은 20배지만 품질은 급이 다르다. 배후에는 GAN에서 온 직관이 있다 — 모델에게 자기비판을 가르치기보다, 트집 전문 모델을 따로 두는 편이 낫다.
영감의 출처가 의외다 — 생성적 적대 신경망(GAN). Anthropic은 직접 썼다: 코드 리뷰와 QA는 구조적으로 GAN의 판별기(discriminator)와 동등하다. 생성자는 계속 생성하고 평가자는 계속 도전하며 적대 속에서 산출 품질을 함께 끌어올린다. 직관은 단순하다 — 누구도 자기 작품을 비판하는 데 능하지 않고, AI도 마찬가지다. 원시 Claude 모델을 평가자로 쓰면 성적이 나빴다. 너무 관대했고, 버그가 심각하지 않다고 스스로를 설득했다. 독립적이고 트집 전문인 평가자로 바꾸자 효과가 완전히 달라졌다.
| 방안 | 시간 | 비용 | 결과 |
|---|---|---|---|
| 단일 Agent | 20분 | $9 | 핵심 기능 사용 불가 — 게임 엔티티 입력 처리 파손 |
| 3-Agent 협업 | 6시간 | $200 | 완전히 동작하는 애플리케이션 + AI 기능 통합 |
20배 이상 비싸다. 그러나 $9짜리 산출은 아예 쓸 수 없다 — 「싸지만 조금 못한」 것이 아니라 「된다」와 「안 된다」의 차이다.
Sprint Contract — 코드를 쓰기 전에 계약부터. 매 Sprint 시작 전 생성자가 구현 방안과 성공 기준을 제안하고, 평가자가 그 기준의 테스트 가능성을 심사하며, 양측이 합의에 도달한 뒤에야 코드를 쓴다. 인간 팀의 기술 리뷰와 똑같되, 리뷰 참여자 양쪽이 모두 AI다.
이 시스템을 만드는 과정에서 Anthropic은 전에 아무도 논하지 않던 문제를 발견했다 — 모델이 자신의 컨텍스트 윈도에 대해 불안을 느낀다. Sonnet 4.5는 자기 컨텍스트 윈도를 인식한 최초의 모델이다. 이 자기 인식은 예상 밖의 방식으로 행동에 영향을 줬다: 진행 상황을 능동적으로 요약하고, 한계에 근접했다고 느끼면 버그 수정을 더 조급하게 밀어붙였다. 치명적인 것은 잔여 토큰 추정이 「매우 정밀하지만 틀렸다」는 점이다. 압축(compaction)만으로 부족해 컨텍스트 리셋 — 주기적으로 윈도를 완전히 비우고 구조화된 인계 상태로 새 Agent를 기동 — 을 도입해야 했다. Opus 4.5에서 이 행동이 저절로 사라져 context reset을 하네스에서 완전히 제거할 수 있었다. 반직관적 사실 하나가 드러난다 — 하네스의 최적 설계는 고정이 아니며 모델 능력에 따라 동적으로 조정되어야 한다. Evaluator는 유/무의 결정이 아니라, 과제가 모델의 신뢰 가능한 독립 수행 범위를 넘어설 때에만 투입할 가치가 있다.
아키텍처 다음은 사람이다. Boris Cherny — Anthropic Staff Engineer, Claude Code의 창시자. 공개된 작업 방식이 많은 이의 상상을 뒤집었다.
@.claude 태그로 갱신. 시간이 지나면 이 파일은 모든 줄이 실제 실수에 대응하는 고도로 맞춤화된 제도적 지식 베이스가 된다.| 메커니즘 | 내용 |
|---|---|
| CLAUDE.md | 지속 기억. 3층 구조 — 전역(~/.claude/), 프로젝트(./CLAUDE.md, git으로 팀 공유), 하위 디렉터리(monorepo). 매 세션 자동 로드 |
| Hooks | 확정적 행동 보장. CLAUDE.md의 「권고」와 달리 동작을 반드시 발생시킨다. 6개 생명주기 훅 — SessionStart, PreToolUse, PostToolUse, PermissionRequest, Stop, PostCompact. 「규범에 유의하라」는 권고, hooks의 eslint는 물리적 차단 |
| Skills | 주문형 로드되는 도메인 지식. .claude/skills/에 SKILL.md로 정의. CLAUDE.md는 매번 로드, Skills는 필요할 때만 — 자동 트리거 또는 /skill-name 수동 호출 |
| MCP | 외부 서비스 통합 — DB 조회, 모니터링 데이터 분석, Figma에서 디자인 시안 가져오기 |
| Memory | 파일 기반 세션 간 지식 베이스. Claude가 Pokemon 플레이 중 정확한 스텝 카운트를 유지하고, 컨텍스트 리셋 후 자기 노트를 읽어 수 시간 시퀀스를 이어 간 사례 |
| Subagents | 격리된 전문화 Agent. 독립 컨텍스트에서 탐색 후 정제된 요약(1000–2000 토큰)만 반환 — 탐색 작업이 메인 대화를 오염시키지 않는다 |
Anthropic의 총평 — 가장 성공적인 팀은 Claude Code를 코드 생성기가 아니라 사고 파트너로 대한다.
2026년 3월 31일, 하나의 사고가 Claude Code 하네스의 실체를 모두에게 보여 줬다.
npm 패키지의 .npmignore에 한 줄이 빠져 59.8MB의 source map이 정상 배포와 함께 공개망에 올라갔다.
TypeScript 소스 512,000줄이 완전히 노출되었다. 유출 코드에서 흥미로운 것 두 가지 —
150회 이상 등장하는 KAIROS(백그라운드 상시 구동 자율 데몬 모드. 미공개지만 코드는 이미 존재 —
지금의 Claude Code가 필요할 때 부르는 조수라면 KAIROS는 늘 곁에서 지켜보다 개입하는 수호자다),
그리고 Claude 4.6 변형의 내부 코드네임으로 확인된 Capybara.
하네스 엔지니어링 관점에서 가장 흥미로운 것은 기술 세부가 아니라 후과다.
유출 소스를 쓰지 않고 완전 재구현한 clean-room 저장소가 2시간 만에 50,000 스타를 얻었다 — GitHub 역사상 최속 성장일 가능성이 있다.
Anthropic은 8,000건 이상의 저작권 삭제 요청을 냈다가 96건으로 축소했다.
.npmignore 한 줄의 누락이 하네스 전체를 노출시켰다 — 아이러니하게도 이것이 이 책의 핵심 논지를 증명한다:
하네스는 공학 문제이며, 미세한 공학적 부주의 하나가 전부를 무너뜨릴 수 있다.
다만 유출의 의외의 소득도 있다 — 공개 문서보다 깊은 CLAUDE.md 상속 체계, hooks 시스템, 4종의 memory, 9단계 컨텍스트 압축이
마케팅 자료의 약속이 아니라 실제로 돌아가는 프로덕션 코드임을 커뮤니티가 검증할 수 있었다.
매주 1,300개의 AI 생성 Pull Request, 전부 인간 수기 코드 제로. 1,370명의 엔지니어가 설정 없이 즉시 사용. Stripe의 Minions는 공개 자료가 가장 풍부한 엔터프라이즈급 하네스 사례다. 그러나 가장 흥미로운 발견은 — 이 시스템이 돌아가는 첫 번째 이유가 AI 모델 자체와 거의 무관하다는 점이다.
Claude Code가 모든 노트북과 개발 머신에 사전 설치되어 있고 rules·token·인증이 전부 구성되어 있다 — 개봉 즉시 사용.
Minions의 바탕은 Stripe가 처음부터 만든 것이 아니다. Block(구 Square, Jack Dorsey의 회사)이 오픈소스로 공개한 코딩 Agent Goose를 깊이 개조했다. Goose는 Apache 2.0 라이선스로 1년 만에 GitHub 27,000+ 스타, 350+ 기여자, 100+ 릴리스를 기록했고 MCP로 3,000+ 서비스에 연결된다. Block 내부 신규 코드 커밋의 90%가 AI 생성이며 Goose가 핵심 엔진이다.
흥미로운 생태 — Block이 힘(오픈소스 기반 Agent)을 제공하고, Stripe가 고삐(엔터프라이즈 하네스)를 제공한다. Stripe의 개조 핵심은 Goose를 무인(無人) 모드로 최적화하는 것이었다. 원판은 개발자가 터미널 앞에서 대화식으로 쓰도록 설계되었지만, Minions는 엔지니어가 메시지 한 통 던지고 자리를 뜨면 Agent가 백그라운드에서 전체 흐름을 독립적으로 완주해야 한다. 단순해 보이는 전환이지만 실시간 인간 개입 없이 온갖 경계 상황을 처리해야 하는 요구다.
각 Minion은 devbox — Stripe의 완전한 코드 트리, 예열된 Bazel 빌드 캐시와 타입 체크 캐시가 사전 설치된 표준화 AWS EC2 인스턴스 — 위에서 돈다. warm pool에서 devbox 하나를 띄우는 데 10초가 걸리지 않는다. 이 인프라 디테일이 이야기 전체의 핵심이다. 주당 1,300 PR을 보면 본능적으로 묻는다 — 어떤 모델을 썼나, 파라미터는, 파인튜닝은? 답은 뜻밖이다.
인간 엔지니어들이 비표준 개발 환경, 불완전한 테스트 커버리지, 혼란한 빌드 시스템을 쓰는 회사라면 AI Agent가 와도 돌아가지 않는다. 인프라가 모델보다 중요하다.
Stripe가 발견한 최대 난관은 기술이 아니라 교육이었다. 엔지니어들의 AI 기대치 보정이 문제였다 — 한 번에 다 해내리라 기대하는 쪽도, 보일러플레이트나 쓰는 물건으로 보는 쪽도 Minions를 비효율적으로 썼다. 팀이 최종적으로 만든 심적 모델은 소박하다 — AI를 갓 입사한 유능한 엔지니어로 상상하라. 모든 언어를 알고 알고리즘·자료구조에 능하지만, 비즈니스 맥락을 모르고 Stripe 코드베이스에 낯설고 Stripe의 일하는 방식을 모른다. 갓 입사한 천재에게 「결제 시스템 리팩터링해」라고 던지고 떠나지 않듯, 컨텍스트와 경계와 수용 기준을 준다. AI에게도 똑같다.
또 하나의 발견 — 팀 내부에서 공유되는 prompt가 중앙집중식 교육보다 유효하다. 팀의 누군가가 좋은 prompt 패턴을 찾아 팀 채널에 공유하면, 동료들의 습득 속도가 어떤 공식 가이드보다 빠르다. 소집단 내 경험 전파의 효율이 하향식 교육을 압도한다.
1,300 PR이 대단해 보이지만 오해하지 말 것 — 모든 AI 생성 PR은 여전히 인간 review를 거친다. Stripe는 AI에게 어떤 것도 자동 merge시키지 않는다. AI가 코딩과 테스트를, 인간이 최종 판단을 맡는다. 다만 review는 처음부터 한 줄씩 읽는 방식이 아니라 자동화된 신뢰 신호 — 전면적 테스트 커버리지, 합성 end-to-end 테스트, 신속 롤백을 지원하는 블루-그린 배포 — 에 크게 의존한다. 인간 reviewer가 보는 것은 보증 없는 AI 코드 뭉치가 아니라 완전한 테스트 파이프라인을 통과하고 상세 결과가 첨부된 PR이다. Review의 무게중심이 「이 코드가 맞는가」에서 「이 접근이 합리적인가」로 이동했다. Boris Cherny의 말과 공명한다 — 엔지니어의 핵심 기여는 코드가 아니라 판단력이다. Minions 체계에서 코드 생산은 Agent가 접수했지만 판단권은 늘 인간의 손에 있다.
「AI를 조직에 대규모로 안착시키려면?」에 대한 Stripe의 실질적 답 — 최고의 모델 선정도 전용 파인튜닝도 아니다. 먼저 인프라를 점검하라. 테스트 커버리지는 완전한가. 빌드 시스템은 표준화되었는가. 10초 안에 깨끗한 개발 인스턴스가 뜨는가. 코드 규범과 review 프로세스는 명확한가. 답이 「아직」이라면 필요한 것은 AI Agent가 아니라 기초 공사다. AI Agent는 나쁜 엔지니어링 관행을 고쳐 주지 않는다. 증폭할 뿐이다. 좋은 관행의 증폭은 효율이고 나쁜 관행의 증폭은 재앙이다. Minions는 난데없는 흑마술이 아니라 10여 년 공학 투자의 복리다. 이 책에서 가장 섹시하지 않지만 가장 실용적인 결론 — 좋은 하네스 엔지니어링은 AI에서 시작하지 않는다. 좋은 엔지니어링에서 시작한다.
모델을 고정하고 하네스만 바꿔 점수가 52.8%에서 66.5%로 올랐다. 「병목은 말이 아니라 고삐에 있다」를 증명하는 현재 가장 단단한 데이터일 것이다.
Terminal Bench 2.0은 표준화된 코딩 agent 벤치마크다. ML·디버깅·생물학·보안·게임 등 89개 과제로 구성되며 일부는 실행 10분, 도구 호출 100회 이상에 달하는 고복잡도 과제다 — Hello World류의 장난감 테스트가 아니다.
| 지표 | 최적화 전 | 최적화 후 | 변화 |
|---|---|---|---|
| Terminal Bench 2.0 점수 | 52.8% | 66.5% | +13.7%p |
| 순위 | Top 30 | Top 5 | 25계단 상승 |
| 사용 모델 | GPT-5.2-Codex | GPT-5.2-Codex | 전혀 바꾸지 않음 |
세 번째 행이 요점이다. 모델은 처음부터 끝까지 동일하다. 바꾼 것은 세 가지뿐 — 시스템 프롬프트, 도구 구성, 미들웨어 훅. LangChain은 영리한 결정을 내렸다: 최적화 공간을 의도적으로 압축했다. agent 하네스에서 조정 가능한 것(프롬프트·도구·hooks·middleware·skills·subagent 위임·기억 시스템…)을 전부 건드리면 어떤 변화가 효과를 냈는지 판별할 수 없기 때문이다.
핵심 변화 — 「당신은 우수한 코딩 어시스턴트다」류의 공허한 말이 아니라, agent가 구조화된 워크플로를 따르도록 강제해 사고의 순서 자체를 제약했다.
LoopDetectionMiddleware는 파일별 편집 횟수를 추적하다가 같은 파일이 N회 편집되면 「다른 방법을 고려하라」는 프롬프트를 주입한다. LangChain 원문 — "Agents can exhibit myopic behavior once committed to a plan, resulting in 'doom loops' where they make small variations to the same broken approach repeatedly." doom loop는 agent의 가장 흔한 병증이다 — 한 방향에 갇히면 미세 변형을 반복하는데, 본질적으로 같은 나쁜 방법의 N개 변종이다. 틀린 방향으로 갈수록 「거의 다 왔다」고 느끼는 사람과 같다. 이 미들웨어는 수정을 금지하지 않고, 임계 도달 시 멈춰 생각하라고 일깨울 뿐이다 — 부드러운 개입, 단단한 트리거.
| Hook 포인트 | 트리거 시점 | 전형적 용도 |
|---|---|---|
| before_agent | 호출 시작 시 1회 | 기억 로드, 자원 연결 |
| before_model | 매 모델 호출 전 | 히스토리 절삭, PII 필터링 |
| wrap_model_call | 모델 호출 전체를 감쌈 | 캐시, 재시도, 동적 도구 가용성 |
| wrap_tool_call | 도구 실행을 감쌈 | 컨텍스트 주입, 도구 접근 제어 |
| after_model | 모델 응답 후 | human-in-the-loop 개입 |
| after_agent | 완료 시 1회 | 결과 저장, 자원 정리 |
내장 미들웨어로 PIIMiddleware(개인정보 필터링), SummarizationMiddleware(토큰 한계 접근 시 히스토리 요약), ModelRetryMiddleware(API 재시도와 백오프) 등이 있다. Middleware의 가치는 디커플링이다 — 팀별 관심사 분리, 비즈니스 로직과 agent 코어의 분리, 조직 간 로직 재사용.
| 추론 구성 | 점수 |
|---|---|
| 전 구간 xhigh (최고 추론) | 53.9% — 대량 타임아웃 |
| 전 구간 high | 63.6% |
| reasoning sandwich (xhigh → high → xhigh) | 66.5% |
전 구간 최고 추론이 53.9%로 전 구간 high보다 10%p 가까이 낮다. 이유는 타임아웃 — 과제마다 시간 제한이 있는데 매 스텝 심층 사고를 하면 끝나기 전에 시간이 소진된다. 샌드위치 전략: 서두(계획)는 xhigh로 방향을 분명히, 중간(구현)은 high로 신속히, 마지막(검증)은 다시 xhigh로 꼼꼼히. 자원 배분이 자원 총량보다 중요하다 — 자원이 제한된 거의 모든 장면에 성립하는 결론이다.
매 라운드의 개선에 인간의 확인이 필요하다 — 완전 자동이 아니며, 과적합 방지에서 인간의 판단력은 여전히 불가결하다.
| 실패 모드 | 증상 | 하네스 처방 |
|---|---|---|
| 자기 확인 편향 | 쓰고 나서 괜찮다 느끼고 테스트를 안 돌림 | PreCompletionChecklist |
| Doom loops | 같은 파일에 10회+ 같은 나쁜 방법을 반복 | LoopDetection |
| 환경 불숙지 | 낯선 디렉터리 구조 탐색에 대량 시간 낭비 | LocalContext 주입 |
| 시간 관리 실패 | 추론 강도가 높아 타임아웃 | reasoning sandwich |
더 똑똑한 모델로 바꾸는 것이 아니라, 같은 모델에게 더 나은 실행 환경을 주는 것이다.
30년의 소프트웨어 공학 지혜가 AI 코딩과 만났다. TDD는 낡은 유산이 아니라 천연의 하네스다.
단위 테스트를 써 봤다면 그 방법론은 십중팔구 Kent Beck에게서 왔다. 극한 프로그래밍(XP)의 창시자, 테스트 주도 개발(TDD)의 발명자, 애자일 선언의 공동 서명자. 1999년 출간한 「Extreme Programming Explained」는 업계 전체의 프로세스 이해를 바꿨다. AI 코딩이 폭발하자 Beck은 방관하지 않았다. Claude Code로 직접 B+트리 라이브러리(BPlusTree3)를 Rust와 Python으로 구현했고, 성능은 프로덕션 수준에 근접했다. 그리고 자신의 CLAUDE.md를 공개했다.
Beck은 BPlusTree3 블로그에서 솔직하게 썼다 — 처음 두 번의 시도는 실패했다. 복잡도가 과도하게 누적되어 AI가 완전히 갇혔다. agent는 점점 복잡해지는 코드베이스에서 길을 잃고 어디를 어떻게 고칠지 몰랐다. 핵심 교훈 — 설계 결정에 더 적극적으로 개입해 AI의 선행 코딩(coding ahead)을 막아야 한다. AI에게는 과제를 받자마자 즉시 구현을 시작하고 계획과 설계를 건너뛰는 본능이 있다. 막지 않으면 코드 분량으로 설계 결함을 덮다가 시스템 전체가 유지 불가능해질 때까지 간다. 하네스 없는 agent가 저지르는 실수와 똑같다. 차이는 Beck이 문제의 소재를 안다는 것 — 같은 실수가 인간 팀에서 벌어지는 것을 30년 동안 목격했기 때문이다.
| 구분 | Augmented Coding | Vibe Coding |
|---|---|---|
| 무엇에 신경 쓰는가 | 코드 품질, 복잡도, 테스트 커버리지 | 시스템 행동과 최종 결과 |
| 가치관 | 수기 코드와 동일 — 깨끗하게 동작하는 코드 | 돌아가면 됨, 에러는 AI에 되먹임 |
| 인간의 역할 | 설계 결정을 주도, AI가 실행 | 요구를 기술, AI가 전권 |
| 적합한 장면 | 장기 유지보수가 필요한 프로덕션 코드 | 프로토타입, 일회성 스크립트, 탐색 프로젝트 |
Beck의 입장은 명확하다 — 둘 다 가치가 있지만 섞으면 안 된다. 문제는 vibe coding이 나쁜 것이 아니라, augmented coding이 필요한 장면에서 vibe coding을 하는 사람이 너무 많다는 것이다. 주말 해커톤 프로젝트라면 vibe coding으로 충분하다. 백만 사용자를 감당할 프로덕션 시스템이라면 augmented coding을 택하는 편이 낫다.
Kent Beck의 존재가 증명하는 것 — 하네스 엔지니어링은 AI 시대에 허공에서 솟아난 신물(新物)이 아니다. TDD 자체가 하나의 하네스다. 워크플로를 제약하고(테스트 먼저), 피드백 메커니즘을 제공하며(통과/실패), 가장 흔한 실수(코드를 쓰고 테스트하지 않음)를 방지한다. Tidy First도 마찬가지 — 변경의 입도를 제약해 모든 수정을 추적·검증 가능하게 만든다. 1999년에 제안된 원칙들은 AI를 위해 설계되지 않았지만 천연적으로 AI에 맞는다. 좋은 공학 규율은 실행자가 인간인지 기계인지 따지지 않는다. TDD가 인간에게 유효한 이유는 인간이 게을러 테스트를 안 쓰기 때문이고, AI에게 유효한 이유는 AI도 게을러 테스트를 안 쓰기 때문이다.
나(저자)는 코드를 손으로 써 본 적이 한 번도 없다. 모든 제품은 AI가 썼다. 이 장은 나의 하네스가 빈 파일 하나에서 어떻게 자라났는지를 다룬다.
앞서 다룬 인물들 — Mitchell Hashimoto는 HashiCorp와 Terraform을 만들었고, Kent Beck은 TDD를 발명했으며, OpenAI 엔지니어들은 수십 년 코드를 썼고, LangChain 팀은 ML 파이프라인에 정통하다. 그들의 하네스는 깊은 프로그래밍 경험에서 자라났다. 저자는 아니다. 「예전에 쓰다가 그만둔」 것이 아니라 처음부터 쓴 적이 없다. 모든 제품이 첫 줄부터 AI 생성이다.
코드를 써 본 적 없는 사람이 백만 사용자 제품을 만들고 AI 코딩 길들이기에 관한 책을 쓴다 — 확실히 이상한 조합이다. 그러나 바로 그래서 흥미로운 표본이다. 하네스 엔지니어링이 노련한 프로그래머의 전유물이라면 천장이 너무 낮다. 코드 경험 제로인 사람도 모색을 통해 유효한 하네스를 세울 수 있다면 이 일의 의미는 훨씬 커진다.
저자의 CLAUDE.md는 빈 파일에서 시작했다. Claude Code가 프로젝트 루트의 CLAUDE.md를 자동으로 읽는다는 것은 알았지만 무엇을 써야 할지 몰라 비워 뒀다. 그러자 AI가 실수하기 시작했다.
시달릴 때마다 한 줄. 3개월 뒤 CLAUDE.md는 수십 줄이 되었다 — 파일 조직 규칙, 문체 요구, 이미지 처리 흐름이 전부 한 파일에. 문제도 함께 왔다: 너무 잡다했다. 공중계정 글을 쓸 때 iOS 개발 규칙을 읽고, 영상을 다룰 때 샤오홍슈 규칙의 간섭을 받았다. 그래서 첫 리팩터링을 했다. 루트 CLAUDE.md를 라우터로 바꿨다 — 현재 과제가 어느 워크스페이스에 속하는지 판별하고 해당하는 하위 CLAUDE.md를 가리키는 일만 한다. 공중계정 → 01-공중계정 글쓰기/CLAUDE.md, 영상 → 03-영상 제작/CLAUDE.md, 앱 개발 → 해당 프로젝트의 CLAUDE.md.
라우터의 핵심 가치 — 대화마다 관련 규칙만 로드하고 무관한 컨텍스트를 AI에게 밀어 넣지 않는다. 컨텍스트는 희소 자원이니 아껴 쓴다. 이 라우터 구조가 여러 회사의 multi-agent 라우팅과 같은 발상임은 나중에야 알았다. 아키텍처 설계를 알아서가 아니라 순전히 몰려서 한 일이다 — 파일이 커지면 AI가 헷갈리니 쪼갤 수밖에 없었다.
이 순환이 계속 돈다. 빈 파일 → 규칙 추가 → 잡다해짐 → 라우터 리팩터링 → 규칙만으로 부족 → hooks 추가 → hooks 과다 → skills 캡슐화 → skills 간 충돌 → 재리팩터링. Mitchell Hashimoto의 Ghostty 설정 파일처럼 저자의 하네스도 모든 규칙 뒤에 시달린 경험이, 모든 skill 뒤에 열몇 번 반복된 고통스러운 흐름이 있다. 그는 Terraform의 경험에서 출발했고 저자는 제로에서 출발했지만 성장 패턴은 같다.
저자가 하네스를 설계할 수 있는 것은 타고난 시스템 설계 감각도, 방법론 서적 덕도 아니다. AI와 협업한 수천 시간 동안 그 행동 패턴을 관찰했기 때문이다 — 언제 게으름을 피우는지, 언제 환각을 일으키는지, 언제 부드러운 당부가 아니라 하드 제약이 필요한지. 이 판단력은 코드 경험이 아니라 다른 경험 — AI와 반복해서 씨름한 경험 — 에서 온다.
그러나 남에게 「왜 이렇게 하는가」를 가르치라 하면 막힌다. 많은 결정이 직관이다. 직관은 구덩이를 밟으며, 구덩이는 대량 반복에서, 대량 반복은 시간에서 온다. 노련한 프로그래머의 「몇만 줄 쓰면 자연히 안다」와 사실 같은 이야기다. 저자는 트랙을 바꿨을 뿐이다 — 밟은 구덩이가 문법 오류와 메모리 누수가 아니라 AI의 환각과 게으름이다.
Martin Fowler의 걱정 — 신입이 첫날부터 on the loop라면 다음 세대의 하네스 설계자는 누가 기르는가 — 은 옳지만 방향이 조금 다를 수 있다. 그는 아무도 코드를 안 쓰고 아무도 저층을 모르게 될 것을 걱정한다. 저자의 존재는 다른 가능성을 증명한다 — 코드를 쓰지 않고도 하네스 설계 경험을 축적할 수 있다. 다만 축적해야 할 경험의 총량은 줄지 않는다. AI와 씨름하는 데 쓴 시간은 junior developer가 코드를 배우는 데 쓰는 시간과 비슷할 것이다. 그 시간을 문법과 자료구조가 아니라 AI의 성미와 워크플로 설계에 썼을 뿐이다. 그러므로 문제는 「코딩 경험」의 대체 가능성이 아니라 — 어떤 경험이든, 충분히 많은 경험 자체가 하네스 설계의 전제라는 것이다. 지름길은 없다. 트랙을 바꿨을 뿐이다.
이 시스템 전체는 어느 날 앉아서 설계한 것이 아니다. 빈 파일 하나에서 시작해 8개월에 걸쳐 조금씩 자라났다.
코드 경험이 없거나 적다면 앞 장들을 읽고 초조할 수 있다 — Mitchell Hashimoto는 Terraform을 만들었고 Kent Beck은 TDD를 발명했는데 그런 축적이 내게 어디 있나. 저자의 조언 — 많이 생각하지 말고 먼저 빈 CLAUDE.md를 열어라. 아무것도 쓰지 않아도 된다. AI가 짜증 나는 첫 실수를 하면 적어 넣어라. 두 번째 실수를 하면 또 적어라. 3개월 뒤 돌아보면 그 파일은 이미 당신만의 하네스가 되어 있다. 전부 당신의 장면, 당신의 통점, 당신의 작업 방식이므로 고도로 맞춤화되어 있다.
누구의 하네스도 설계된 것이 아니다. 좋은 하네스는 AI와 반복해서 씨름하는 가운데 자라난다. 필요한 것은 프로그래밍 경험이 아니다. AI의 우둔함을 견딜 인내와, AI와 씨름하는 직관을 쌓을 시간이다.
어쩌면 Martin Fowler가 정말 걱정해야 할 것은 「아무도 코드를 안 쓴다」가 아니라 「아무도 충분한 시간을 들여 충분한 구덩이를 밟으려 하지 않는다」일지 모른다. 그것도 확실하지는 않다. 확실한 것은 — 저자는 충분히 밟았고, 당신도 할 수 있다는 것이다.