AI 에이전트는 왜 자기 코드를 칭찬할까, Anthropic의 GAN 영감 해법

같은 모델이 작성한 코드를 같은 모델이 리뷰하면, 과연 의미 있는 피드백이 나올까요? Anthropic이 3월 24일 엔지니어링 블로그에서 공개한 답은 명확합니다. 나오지 않습니다. "기본 설정 그대로의 Claude는 좋지 않은 QA 에이전트입니다"라는 솔직한 고백과 함께, Anthropic은 GAN(생성적 적대 신경망)에서 영감을 받은 Planner-Generator-Evaluator 3-에이전트 아키텍처 를 공개했습니다. 코드를 생성하는 에이전트와 평가하는 에이전트를 구조적으로 분리하여, AI 코딩 에이전트의 고질적인 품질 문제를 해결한 사례입니다.

결과는 극적입니다. 솔로 에이전트가 $9, 20분 만에 핵심 기능조차 작동하지 않는 코드를 내놓는 반면, 풀 하네스는 $200, 6시간에 걸쳐 완전히 작동하는 풀스택 애플리케이션을 만들어냅니다. AI 코딩이 "쓸 수 있느냐"에서 "얼마나 잘 쓰느냐"로 전환되는 시점에서, Anthropic이 내놓은 구조적 해법을 살펴보겠습니다.

프롬프트에서 하네스로, AI 엔지니어링의 세 번째 진화

이 이야기를 이해하려면 AI 엔지니어링이 지난 3년간 걸어온 경로를 먼저 짚어야 합니다.

2023-2024년은 프롬프트 엔지니어링 의 시대였습니다. 하나의 프롬프트를 최적화하는 데 모든 에너지가 쏠렸습니다. 2025년에는 컨텍스트 엔지니어링 으로 초점이 이동했습니다. 컨텍스트 윈도우에 무엇을 넣고 무엇을 뺄지, 어떤 정보를 어떤 순서로 배치할지를 설계하는 것이 핵심이 되었습니다. 그리고 2026년, 하네스 엔지니어링 이라는 세 번째 진화가 시작되고 있습니다.

하네스 엔지니어링은 에이전트를 감싸는 인프라 전체를 설계하는 것입니다. 프롬프트 하나를 다듬는 것도, 컨텍스트 구성을 최적화하는 것도 아닙니다. 여러 에이전트를 어떻게 배치하고, 어떤 순서로 상호작용시키며, 어떤 도구를 부여할지를 아키텍처 수준에서 결정합니다. Hugging Face의 Philipp Schmid는 이렇게 선언했습니다.

"2025년이 에이전트의 시작이었다면, 2026년은 에이전트 하네스의 해가 될 것입니다."

Anthropic이 이번에 공개한 블로그는 하네스 연구 시리즈의 세 번째입니다. 2025년 11월에는 2-에이전트 구조(Initializer + Coding Agent)를 소개하며 컨텍스트 리셋 기반 세션 관리를 다뤘습니다. 같은 해 12월에는 에이전트 설계의 일반 원칙을 정리한 "Building Effective Agents"를 발표했습니다. 이번 2026년 3월 포스트에서 3-에이전트 구조로 본격 진화하며, 근본적인 질문 하나에 정면으로 답합니다. 왜 AI 에이전트는 자기 코드를 제대로 평가하지 못하는가?

두 가지 근본 문제: 컨텍스트 저하와 자기 칭찬 편향

AI 코딩 에이전트가 단순 코드 완성을 넘어 수 시간에 걸친 자율적 애플리케이션 개발을 수행하면서, 업계 전반에서 두 가지 핵심 실패 모드가 관찰되어 왔습니다.

첫 번째는 컨텍스트 저하(Context Degradation) 입니다. 컨텍스트 윈도우가 채워지면서 모델이 일관성을 잃는 현상입니다. 일부 모델은 "컨텍스트 불안(context anxiety)"이라 불리는 행동을 보이는데, 컨텍스트가 차면 작업을 조기에 마무리하려는 경향이 나타납니다. 장기 실행 코딩 태스크에서 후반부 품질이 급격히 저하되는 주요 원인입니다.

두 번째, 그리고 더 근본적인 문제는 자기 칭찬 편향(Self-Congratulatory Bias) 입니다. 에이전트에게 자신이 생성한 결과물을 평가하라고 요청하면, 품질이 명백히 부족한 경우에도 자신감 있게 칭찬하는 현상이 벌어집니다. 특히 프론트엔드 디자인처럼 주관적 판단이 개입되는 작업에서 이 편향이 두드러집니다.

Anthropic 엔지니어 Prithvi Rajasekaran은 이 문제를 직설적으로 인정했습니다.

"기본 설정 그대로의 Claude는 좋지 않은 QA 에이전트입니다."

(원문: "Out of the box, Claude is a poor QA agent.")

문제의 핵심은 인지적 편향(cognitive priming)에 있습니다. 코드를 생성한 모델이 같은 세션에서 그 코드를 평가하면, 자신의 출력을 방어하는 방향으로 편향이 작동합니다. 그리고 이것은 프롬프트로 해결하기 어렵습니다. 아무리 "비판적으로 평가하라"고 지시해도, 자기 작업물에 대한 구조적 편향은 프롬프트 수준의 개입으로는 극복되지 않습니다.

이 한계를 인정한 것이 Anthropic의 해법이 시작되는 지점입니다.

GAN에서 배운 것: 생성자와 비평가를 분리하라

Anthropic이 찾은 해법의 영감은 의외의 곳에서 왔습니다. 바로 GAN(Generative Adversarial Network, 생성적 적대 신경망)입니다.

GAN은 Generator(생성자)와 Discriminator(판별자)를 적대적으로 배치하여, 둘 사이의 긴장 관계에서 품질을 끌어올리는 구조입니다. Anthropic은 이 핵심 아이디어를 차용했습니다. 코드를 생성하는 에이전트와 평가하는 에이전트를 완전히 분리한 것입니다.

"생성자와 평가자를 분리하는 것이, 생성자가 자기 작업을 비판하도록 만드는 것보다 훨씬 다루기 쉬웠습니다."

(원문: "separating the generator from the evaluator proved far more tractable than making a generator critical of its own work.")

단, 전통적 GAN과의 차이도 있습니다. GAN에서는 Generator와 Discriminator가 동시에 학습하지만, 하네스에서는 Generator가 코드를 생성하고, Evaluator가 피드백을 주면, Generator가 이를 반영하여 재생성하는 반복 루프(iterative loop) 구조를 따릅니다. 적대적 "학습"이 아니라 적대적 "반복"에 가깝습니다.

이 구조에 Planner(기획자)를 추가하여, 최종적으로 Planner-Generator-Evaluator 3-에이전트 아키텍처 가 완성되었습니다.

Planner: 네 문장을 풀 제품 스펙으로

Planner는 1-4문장의 짧은 프롬프트를 풀 제품 스펙 으로 확장하는 역할입니다. 범위(scope)와 고수준 기술 방향에 집중하며, 구현 세부사항은 다루지 않습니다. 예를 들어 "RetroForge - 2D Retro Game Maker"라는 짧은 프롬프트가 주어지면, 프로젝트 대시보드, 타일 기반 레벨 에디터, 픽셀아트 스프라이트 에디터, 엔티티 행동 시스템, 플레이 테스트 모드까지 10개 스프린트에 걸친 16개 기능 스펙으로 확장됩니다.

Generator: 스프린트 단위 코드 생성

Generator는 Planner의 스펙을 받아 실제 코드를 생성합니다. React, Vite, FastAPI, SQLite(이후 PostgreSQL) 등의 기술 스택을 사용하며, Git 버전 관리를 통해 각 스프린트의 결과를 추적합니다. 중요한 것은 각 스프린트 시작 전에 Evaluator와 "스프린트 계약(sprint contract)" 을 체결한다는 점입니다. "완료"의 정의를 사전에 합의함으로써, 평가 기준의 모호함을 구조적으로 제거합니다.

Evaluator: 실제로 앱을 만져보는 비평가

Evaluator가 이 아키텍처의 핵심입니다. 단순히 코드를 읽고 평가하는 것이 아니라, Playwright MCP 접근 권한 을 보유하여 실제 사용자처럼 실행 중인 애플리케이션을 테스트합니다. UI 버튼을 클릭하고, API 엔드포인트에 요청을 보내고, 데이터베이스 상태를 확인합니다. 결과는 주관적 점수가 아닌 하드 패스/페일(hard pass/fail) 로 판정됩니다. 그리고 생성 주기당 5-15회의 반복 평가가 이루어집니다.

프론트엔드 디자인 평가에서는 네 가지 기준이 적용됩니다. Design Quality (전체적 일관성), Originality (템플릿 기본값이 아닌 커스텀 결정의 증거), Craft (타이포그래피, 간격, 색상 조화의 기술적 실행), 그리고 Functionality (미학과 무관한 사용성)입니다.

한 사례에서는 네덜란드 박물관 웹사이트가 10번의 반복 평가를 거치면서, "CSS perspective로 렌더링된 체커보드 바닥의 3D 공간 경험"으로 피벗하는 결과를 만들어냈습니다. Generator-Evaluator 간의 적대적 긴장이 어느 에이전트도 단독으로 달성하지 못할 창의성을 이끌어낸 것입니다.

$9 솔로 vs $200 풀 하네스: 숫자가 말하는 품질 격차

Anthropic은 구체적인 성능 데이터를 투명하게 공개했습니다. 이것이 이번 발표의 가장 설득력 있는 부분입니다.

RetroForge(2D 레트로 게임 메이커) 프로젝트에서 솔로 에이전트 는 $9, 20분 만에 결과물을 내놓았습니다. 그러나 Anthropic의 평가에 따르면 "애플리케이션의 중심 기능이 작동하지 않았습니다." 반면 Opus 4.5 풀 하네스 는 $200, 6시간에 걸쳐 완전히 작동하는 풀스택 애플리케이션을 만들었고, UX 품질도 현저히 우수했습니다.

더 흥미로운 것은 Opus 4.6에서의 결과입니다. Digital Audio Workstation(DAW) 앱을 구축하는 과제에서 단계별 비용을 살펴보면 구조가 명확해집니다.

• Planner: 4.7분, $0.46
• Build 1라운드: 2시간 7분, $71.08
• QA 1라운드: 8.8분, $3.24
• Build 2라운드: 1시간 2분, $36.89
• QA 2라운드: 6.8분, $3.09
• Build 3라운드: 10.9분, $5.88
• QA 3라운드: 9.6분, $4.06
• 합계: 3시간 50분, $124.70

비용의 대부분은 Build(코드 생성)에 집중되고, QA(평가)는 전체 비용의 약 8%에 불과합니다. 평가자를 분리하는 것이 비용 효율적으로도 합리적이라는 것을 보여줍니다. 그리고 전체 비용이 Opus 4.5의 $200에서 Opus 4.6의 $124.70으로 37% 감소 했습니다.

컨텍스트 관리: 리셋에서 연속 세션으로

장기 실행 에이전트의 컨텍스트 관리 전략도 주목할 만합니다. Anthropic은 두 가지 접근을 비교했습니다.

컴팩션(요약 압축) 은 대화 이력을 요약하여 압축하는 방식입니다. 연속성을 유지할 수 있지만, 컨텍스트 불안을 완전히 해소하지 못합니다. 컨텍스트 리셋 은 윈도우를 완전히 비우고 구조화된 핸드오프로 새로 시작하는 방식입니다.

"컨텍스트 리셋이 Claude Sonnet 4.5에서 컴팩션보다 더 효과적이었습니다."

(원문: "Context resets — clearing the window entirely with structured handoffs — proved more effective than compaction for Claude Sonnet 4.5.")

그런데 Opus 4.6에서는 상황이 달라졌습니다. 모델 자체의 개선으로 컨텍스트 불안이 크게 감소하면서, 컨텍스트 리셋 없이 단일 연속 세션 으로 전체 빌드를 수행할 수 있게 되었습니다. Claude Agent SDK의 자동 컴팩션이 컨텍스트 증가를 관리하면서, 이전에는 필수적이었던 구조적 개입이 불필요해진 것입니다.

이것이 바로 다음 섹션에서 다룰 "하네스 진화의 역설"로 이어집니다.

하네스 진화의 역설: 단순해지지만 사라지지 않는다

이번 발표에서 가장 깊이 있는 인사이트는 기술적 세부사항이 아니라 메타적 관찰 에 있습니다.

Opus 4.5에서 Opus 4.6으로 업그레이드하면서 하네스에서 여러 컴포넌트가 제거되었습니다. 스프린트 분해가 사라졌고, 컨텍스트 리셋도 불필요해졌으며, 반복 평가가 최종 1회 패스로 축소되었습니다. 그럼에도 결과물의 품질은 유지되었고, 비용은 오히려 줄었습니다. 모델이 좋아지니 하네스가 단순해진 것입니다.

여기서 자연스러운 질문이 떠오릅니다. 모델이 충분히 좋아지면 하네스 자체가 필요 없어지는 것 아닐까요?

Anthropic의 답은 아닙니다.

"하네스의 모든 컴포넌트는 모델이 혼자서는 할 수 없는 것에 대한 가정을 인코딩하며, 그 가정들은 스트레스 테스트할 가치가 있습니다."

(원문: "Every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions are worth stress testing.")

그리고 더 핵심적인 관찰이 따릅니다.

"흥미로운 하네스 조합의 공간은 모델이 개선되어도 줄어들지 않습니다. 대신, 이동합니다."

(원문: "The space of interesting harness combinations doesn't shrink as models improve. Instead, it moves.")

이것은 "Bitter Lesson" 논쟁 과 직접 맞닿는 관찰입니다. Rich Sutton의 유명한 논문이 주장하듯, 역사적으로 컴퓨팅 파워의 단순한 증가(스케일업)가 정교한 엔지니어링을 항상 압도해 왔습니다. 하네스도 결국 모델 개선에 밀려 불필요해지는 것 아닐까요?

Anthropic의 하네스 연구 시리즈는 이에 대해 미묘한 답을 제시합니다. 네, 개별 하네스 컴포넌트는 모델 개선으로 불필요해질 수 있습니다. 하지만 더 강력한 모델은 더 야심찬 작업을 가능하게 하고, 그 야심찬 작업은 새로운 형태의 하네스를 요구합니다. 하네스의 "공간"은 줄어들지 않고 이동할 뿐입니다. Opus 4.5에서 필요했던 스프린트 분해가 사라졌다면, Opus 4.6에서는 아마 더 복잡한 멀티 서비스 아키텍처나 실시간 협업 기능 같은 새로운 도전이 하네스의 영역이 될 것입니다.

하네스 진화의 3단계를 정리하면 이렇습니다.

• Stage 1 (2025년 11월): 2-에이전트 구조. Initializer와 Coding Agent로 세션 간 컨텍스트 리셋을 통해 작업 연속성 확보
• Stage 2 (Opus 4.5): 3-에이전트 풀 하네스. 스프린트 계약, 반복 평가, GAN 영감 분리 구조의 완성형
• Stage 3 (Opus 4.6): 단순화된 3-에이전트. 스프린트 제거, 최종 1회 평가, 컨텍스트 리셋 불필요. 구조는 유지하되 복잡성은 감소

업계 반응: "하네스 엔지니어링의 해"

이 발표는 Hacker News 프론트페이지에 올랐고, 한국의 GeekNews에서도 28포인트로 프론트페이지에 게재되었습니다. 업계 반응은 크게 세 가지 흐름으로 나뉩니다.

업계 리더들의 열광

Box CEO Aaron Levie 는 X에서 이렇게 언급했습니다.

"에이전트 하네스의 포스 멀티플라이어가 지금 미쳤습니다. 업계가 어느 정도 아키텍처 일관성에 도달했지만, 아직 다양한 변형이 많습니다."

Cursor CEO Michael Truell 도 이에 화답하듯, Cursor가 수천 개의 코딩 에이전트를 오케스트레이션하는 새 에이전트 하네스를 구축했다고 공개했습니다. 주당 최대 1,000 커밋/시간에 도달하며, 장기 실행에서도 "신선하게" 유지된다고 밝혔습니다.

LangChain의 Viv 는 에이전트 스토리지와 에이전트 컴퓨트를 분리(decoupling)하는 패턴을 제안하며 논의를 확장했습니다. 각 에이전트에 전용 컴퓨트를 주면서 스토리지(레포/파일시스템)를 공유하면 자기 조직화가 가능하다는 아이디어입니다.

비판적 시각도 존재합니다

비용 문제 가 가장 직접적인 비판입니다. $200에 6시간이라는 수치는 기업 환경에서는 합리적일 수 있으나, 개인 개발자에게는 분명 부담입니다. 한 번의 실험에 $200을 쓸 수 있는 개발자가 얼마나 될까요?

Anthropic 생태계 종속 우려 도 제기됩니다. 2026년 1월 Anthropic이 타사 도구(OpenCode, Cursor, Windsurf)의 Claude 모델 접근을 제한하면서 개발자 신뢰에 금이 간 바 있습니다. DHH는 이를 "매우 고객 적대적"이라 평가했습니다. 하네스 설계가 Claude 생태계 내에서만 최적화된다면, 범용성에 한계가 있을 수 있습니다.

Bitter Lesson 가능성 도 언급됩니다. Aaron Levie 자신도 "이것이 결국 bitter lesson으로 사라질 수 있다"고 인정했습니다. Opus 4.5에서 4.6으로의 단순화가 실제로 이 방향을 보여주고 있습니다. 다만 Anthropic은 "하네스 공간이 이동할 뿐"이라는 반론을 내놓고 있어, 이 논쟁은 앞으로도 계속될 것입니다.

경쟁 구도: 각사의 접근은 어떻게 다른가

Anthropic만 멀티에이전트 코딩 품질 문제에 도전하고 있는 것은 아닙니다. 주요 AI 코딩 도구들의 접근을 비교해 보겠습니다.

Anthropic(Claude Code) 은 GAN 영감의 분리 평가자와 Playwright 테스트를 결합한 구조입니다. 생성과 평가의 적대적 긴장에서 품질을 끌어올리는 것이 핵심입니다.

Cursor 는 2.5 버전에서 비동기 서브에이전트 트리 구조를 도입했습니다. 수천 개의 에이전트를 동시에 오케스트레이션하여 규모의 수렴을 추구합니다. Anthropic의 "깊이 있는 반복"과 대비되는 "넓은 병렬"이라고 할 수 있습니다.

Devin 은 Interactive Planning과 Wiki를 통한 자율 실행에 초점을 맞추고 있습니다. 에이전트의 자율성을 극대화하는 방향입니다.

GitHub Copilot 은 PR 네이티브 코딩 에이전트로, GitHub의 코드 리뷰 워크플로우에 자연스럽게 통합되는 접근입니다.

아직 하나의 패턴이 지배적이라고 보기는 어렵습니다. 하지만 "단일 에이전트로는 부족하다"는 인식은 업계 전반에서 공유되고 있습니다.

전망: 하네스 엔지니어링은 어디로 향하는가

Anthropic의 이번 발표가 가리키는 방향은 몇 가지로 정리됩니다.

첫째, 에이전트 품질 보증이 다음 핵심 과제입니다. AI가 코드를 "쓸 수 있다"는 것은 이미 입증되었습니다. 이제 문제는 "얼마나 잘 쓰는가"입니다. Anthropic의 하네스 설계는 이 품질 격차를 "더 좋은 프롬프트"가 아니라 "아키텍처 분리"로 해결하려는 공개적 시도 중 하나입니다. 프롬프트 엔지니어링의 한계를 인정하고 구조적 설계로 전환한 것이 핵심 교훈입니다.

둘째, 비용 민주화가 필요합니다. $200에서 $124.70으로의 37% 감소는 고무적이지만, 여전히 개인 개발자에게는 높은 장벽입니다. 모델 비용의 하락과 효율성 향상이 지속되면 접근성이 크게 개선될 것입니다. 현재 추세대로라면 1-2년 내에 동일한 품질의 결과물을 $20-30 수준에서 얻을 수 있게 될 가능성이 있습니다.

셋째, Planner-Generator-Evaluator 패턴의 표준화 가능성입니다. 이 패턴이 업계 표준이 될 수도 있지만, Cursor의 서브에이전트 트리, Devin의 자율 계획 등 경쟁 접근이 존재합니다. 어떤 패턴이 어떤 유형의 작업에 가장 적합한지는 아직 결론이 나지 않았습니다.

넷째, 실무 적용은 이미 가능합니다. Anthropic은 이 연구의 실제 구현을 Claude Code의 Frontend Design Skill로 GitHub에 공개했습니다. Claude Code 사용자라면 지금 바로 이 3-에이전트 하네스를 활용할 수 있습니다.

우리가 목격하고 있는 것은 AI 코딩의 초점 이동입니다. "AI가 코드를 쓸 수 있는가?"라는 질문은 이미 답이 나왔습니다. 이제 질문은 "AI가 쓴 코드를 누가, 어떻게 검증하는가?"입니다. Anthropic의 답은 명확합니다. 같은 AI가 하되, 다른 자리에서, 다른 역할로, 다른 도구를 들고 해야 한다는 것입니다. GAN이 30년 전에 증명한 것처럼, 생성자와 비평가는 분리될 때 비로소 제 역할을 합니다.