모델이 똑똑해지면 코드가 좋아질까요? Anthropic은 "아니요, 하네스가 결과를 결정합니다"라고 답했어요. 2026년 3월 24일에 공개한 공식 엔지니어링 블로그에서요.
이게 뭔데?
Anthropic Labs팀의 Prithvi Rajasekaran이 쓴 이 글은 두 가지 문제를 동시에 풀려는 시도에서 시작했어요. 하나는 Claude가 예쁜 프론트엔드를 만들게 하는 것, 다른 하나는 몇 시간 동안 사람 개입 없이 완전한 앱을 만들게 하는 것이에요.
핵심 통찰은 간단해요. 같은 모델이라도 하네스(harness) 설계에 따라 결과물의 품질이 완전히 달라진다는 거예요. Anthropic의 기존 "Building Effective Agents" 블로그에서 이미 "가능한 한 가장 단순한 솔루션을 찾고, 필요할 때만 복잡성을 추가하라"는 원칙을 세웠는데, 이번 글은 그 원칙을 실제로 적용하고 진화시킨 실전기예요.
여기서 "하네스"란 LLM을 감싸는 전체 실행 환경을 뜻해요. 프롬프트, 도구 연결, 에이전트 간 협업 구조, 피드백 루프 등 모델 바깥의 모든 시스템이에요. Aakash Gupta의 표현을 빌리면, 모델이 엔진이라면 하네스는 자동차 자체예요 — 최고의 엔진도 핸들과 브레이크 없이는 쓸모없어요.
이 주제가 지금 뜨거운 이유는 업계 전체가 같은 결론에 도달하고 있기 때문이에요. Manus는 6개월간 하네스를 5번 다시 짰고, LangChain은 Deep Research를 4번 재설계했고, Vercel은 에이전트 도구의 80%를 삭제하고 오히려 더 나은 결과를 얻었어요. OpenAI도 하네스 엔지니어링 개념을 공식화했고요.
뭐가 달라지는 건데?
Anthropic 블로그가 말하는 핵심 문제는 두 가지예요.
첫 번째, 컨텍스트 불안(Context Anxiety). 에이전트가 컨텍스트 윈도우가 차면 일관성을 잃어요. 더 심각한 건, 자기가 한계에 도달했다고 "느끼면" 일을 조기에 마무리하려는 경향이에요. Sonnet 4.5에서 이 현상이 심해서 컨텍스트를 아예 리셋하는 방식을 택했어요.
두 번째, 자기 평가의 실패. AI에게 자기 결과물을 평가하라고 하면, 품질이 뻔히 떨어지는데도 "잘했어요!"라고 답해요. 특히 디자인처럼 주관적 판단이 필요한 영역에서 이 현상이 심했고요.
이 두 문제를 풀기 위해 Anthropic은 GAN(Generative Adversarial Network)에서 영감을 받아 Generator와 Evaluator를 분리하는 구조를 설계했어요.
| 기존 방식 (단일 에이전트) | Anthropic의 접근 (분리 구조) | |
|---|---|---|
| 자기 평가 | 자기가 만들고 자기가 평가 → 항상 후한 점수 | 만드는 AI와 평가하는 AI가 다름 |
| 디자인 품질 | 안전하고 예측 가능한 레이아웃 반복 | 평가 기준에 따라 반복 개선, 미술관급 시도 |
| 장시간 작업 | 컨텍스트 차면 일관성 상실 | Planner-Generator-Evaluator 3단 구조 |
| 비용 vs 품질 | 20분, $9 — 핵심 기능 작동 안함 | 6시간, $200 — 완전히 동작하는 앱 |
프론트엔드 디자인 실험에서 Anthropic은 4가지 평가 기준을 만들었어요: 디자인 퀄리티, 독창성, 기술적 완성도, 기능성. 특히 "독창성" 기준에서 "수정 안 된 스톡 컴포넌트나 AI 슬롭 패턴(보라색 그래디언트 위 흰색 카드 등)은 감점"이라고 명시했어요. AI가 만든 티가 나는 디자인을 명확히 페널티로 잡은 거예요.
Evaluator에게 Playwright MCP를 줘서 실제 페이지를 내비게이션하고 스크린샷을 찍으며 평가하게 했어요. 5~15번의 반복을 거치면서 점수가 올라갔고, 한 실험에서는 네덜란드 미술관 웹사이트를 만드는 중 10번째 반복에서 CSS 원근법으로 3D 갤러리 공간을 만드는 창의적 도약이 나왔어요.
핵심만 정리: 진화의 3단계
- 1단계: 2-에이전트 하네스 (2025년 11월)
Initializer + Coding Agent. 작업을 피처 단위로 쪼개고, 컨텍스트 리셋으로 세션 간 핸드오프. Sonnet 4.5 기반. 이미 이것만으로 기본 에이전트보다 훨씬 나은 결과를 냈어요. - 2단계: 3-에이전트 하네스 (Opus 4.5)
Planner + Generator + Evaluator. 한 줄짜리 프롬프트를 16개 피처 10개 스프린트로 확장. 스프린트마다 계약(Contract) 체결 후 구현-평가 반복. 2D 레트로 게임 메이커를 6시간 $200에 완성 — 단일 에이전트(20분, $9)와는 차원이 다른 결과물. - 3단계: 단순화된 하네스 (Opus 4.6)
스프린트 구조 제거, 평가를 마지막 1회로 축소. Opus 4.6이 더 똑똑해졌기 때문에 가능했어요. 브라우저 DAW(디지털 오디오 워크스테이션)를 약 4시간 $125에 완성. - 핵심 교훈: 하네스의 모든 컴포넌트는 "모델이 혼자서 못하는 것"에 대한 가정이다
모델이 발전하면 그 가정을 다시 검증해야 해요. 더 이상 필요 없는 부분은 걷어내고, 새로운 가능성을 위한 부분을 추가하는 거예요. Anthropic은 이걸 명시적으로 실천했어요 — Opus 4.6이 나오자 스프린트 분해를 제거하고, 대신 AI 기능 내장에 대한 프롬프팅을 추가했어요.
Anthropic의 핵심 문장
"하네스의 흥미로운 조합의 공간은 모델이 발전해도 줄어들지 않는다. 대신 이동한다. AI 엔지니어의 흥미로운 일은 그 다음 새로운 조합을 계속 찾아내는 것이다."
LangChain의 Lance Martin은 이걸 리처드 서튼의 "쓰라린 교훈(Bitter Lesson)"에 비유했어요. 범용적 방법이 결국 정교하게 설계된 시스템을 이긴다는 원칙이 이제 모델 학습이 아니라 애플리케이션 레이어에도 적용된다는 거예요. "시간이 지나면 모델이 좋아지고, 구조를 걷어내고, 가정을 제거하고, 하네스를 더 단순하게 만들어야 한다".
기존 포스트와의 관계
워킹 레퍼런스의 기존 글 Harness Engineering — AI 코딩 에이전트의 야생마를 길들이는 법은 Commands, Skills, Hooks 같은 실전 프레임워크를 다룹니다. 이 글은 Anthropic 공식 블로그의 설계 철학과 진화 과정에 초점을 맞춘 별도 레퍼런스예요.
