장시간 자율 코딩을 위한 에이전트 하네스 설계: GAN에서 영감 받은 멀티 에이전트 아키텍처

AI가 스스로 코드를 작성하고 검증하는 시대가 왔습니다. Anthropic이 공개한 연구에서는 장시간 동안 자율적으로 동작하는 AI 코딩 에이전트를 어떻게 설계할 수 있는지, 그리고 왜 단순한 접근법이 실패하는지를 심층적으로 다루고 있습니다. 이 글에서는 GAN(적대적 생성 신경망)에서 영감을 받은 멀티 에이전트 아키텍처의 핵심을 정리합니다.

단순 구현이 실패하는 두 가지 이유

장시간 에이전트 코딩에서 반복적으로 나타나는 핵심 실패 원인은 두 가지입니다.

첫째, 컨텍스트 불안(Context Anxiety). 긴 작업을 수행하다 보면 AI 모델이 초기 지시 사항을 잊거나 일관성을 잃습니다. 이를 해결하기 위한 주기적인 컨텍스트 리셋은 토큰 오버헤드와 응답 지연을 유발하지만, 장기 작업의 신뢰성을 확보하기 위해 불가피한 선택이었습니다.

둘째, 자기 평가(Self-Evaluation) 문제. AI는 자신이 만든 결과물을 스스로 비판적으로 평가하는 데 본질적인 한계가 있습니다. 외부의 독립적인 피드백 없이는 “기술적으로 작동하지만 실질적으로 형편없는” 결과물을 계속 양산하게 됩니다.

GAN에서 영감 받은 해결책: 생성자 vs 평가자

연구팀은 딥러닝의 GAN 구조에서 아이디어를 가져왔습니다. GAN이 생성자(Generator)와 판별자(Discriminator)의 경쟁으로 품질을 높이듯, 에이전트 하네스도 생성자 에이전트와 평가자 에이전트를 독립적으로 운용합니다.

평가자는 Playwright MCP를 통해 실제 브라우저에서 결과물과 상호작용하며 스크린샷을 찍고, 사전에 정의된 기준으로 점수를 매기고 비평을 작성합니다. 이 피드백이 생성자에게 전달되어 반복적으로 품질이 개선됩니다.

인상적인 사례로, 네덜란드 미술관 웹사이트 제작 시 9번째 반복까지는 깔끔한 다크 테마를 만들던 시스템이 10번째 반복에서 CSS perspective로 렌더링한 3D 공간으로 사이트를 완전히 재구상했습니다. 단일 패스에서는 기대하기 어려운 창의적 도약이었습니다.

풀스택으로 확장: 3-에이전트 아키텍처

프론트엔드를 넘어 풀스택 개발로 확장하면서 아키텍처는 세 개의 에이전트로 구성됩니다.

• 기획자(Planner): 한 줄의 프롬프트를 세부 기능 스펙으로 확장
• 생성자(Generator): 실제 코드 작성
• 평가자(Evaluator): 런타임 환경에서 통합 테스트 수행

에이전트 간 통신은 파일 기반으로 이루어집니다. 각 스프린트 시작 전 생성자와 평가자가 “스프린트 계약(Sprint Contract)”을 협상하여 완료 조건을 사전에 합의합니다. 이것이 모호한 고수준 스펙과 테스트 가능한 구현 사이의 간극을 메웁니다.

레트로 게임 메이커 실험: Solo vs Full Harness

같은 과제를 단독 에이전트(Solo)와 전체 하네스(Full Harness)로 비교했습니다.

항목	Solo Harness	Full Harness
소요 시간	20분	6시간
API 비용	$9	$200
게임 플레이 가능 여부	불가 (로직 오류)	가능 (완전 작동)

비용과 시간은 20배 차이가 났지만, 결과물의 품질은 차원이 달랐습니다. Solo 방식은 UI 레이아웃은 구성했지만 게임 엔진이 전혀 작동하지 않았습니다. 브릿지 스크립트 누락이 원인이었는데, 이는 단일 에이전트가 복잡한 다계층 시스템 아키텍처를 일관되게 설계하는 데 한계가 있음을 보여줍니다.

반면 Full Harness는 스프라이트 애니메이션, AI 에셋 생성기, 게임 내보내기 기능까지 포함한 완전한 통합 시스템을 구축해냈습니다.

Claude Opus 4.6과 하네스 단순화

Opus 4.6 모델이 출시되면서 상황이 달라졌습니다. 장기 계획 능력 향상, 확장된 컨텍스트 윈도우, 지시 이행 안정성 강화로 인해 기존 하네스가 보완해야 했던 많은 결함들이 모델 자체로 해소되었습니다.

가장 큰 변화는 스프린트 분할 구조의 제거입니다. 이전에는 긴 작업을 짧은 스프린트로 쪼개야 했지만, Opus 4.6에서는 단일 세션 내에서 전체 코드베이스를 일관되게 작성할 수 있게 되었습니다.

다만 기획자와 평가자 에이전트는 유지되었습니다. 기획자 없이는 생성자가 요구사항 범위를 자의적으로 축소하는 경향이 있었고, 평가자는 여전히 복잡한 중첩 코드의 미세한 결함을 찾아내는 가치 있는 역할을 수행했습니다.

DAW(디지털 오디오 워크스테이션) 생성 실험

가장 도전적인 실험으로 브라우저 기반 DAW를 구축했습니다. 총 3시간 50분, $124.70의 비용이 소요되었으며 3번의 QA 루프를 거쳤습니다.

최종 결과물은 다중 트랙 어레인지 뷰, Web Audio API 기반 믹서 라우팅, 재생 커서 동기화 컨트롤 모듈을 갖춘 완전 기능 DAW였습니다. AI 에이전트 모듈을 통해 텍스트 프롬프트로 BPM, 키 설정, 멜로디 시퀀스 생성까지 가능했습니다.

핵심 시사점

이 연구에서 도출된 실무 교훈을 정리하면 다음과 같습니다.

1. 모델이 업그레이드될 때마다 하네스를 재검토하라. 모델 성능이 향상되면 기존 하네스의 방어 로직 일부는 불필요한 복잡성이 됩니다. 제거된 복잡성을 새로운 상위 기능으로 전환해야 합니다.

2. 역할 분리가 핵심이다. 코드를 생성하는 에이전트와 검증하는 에이전트를 엄격히 분리하는 것이, 모든 컨텍스트를 하나의 모델에 집어넣는 방식보다 월등히 높은 성공률을 보장합니다.

3. 단순함에서 시작하라. 가장 단순한 해결책을 먼저 적용하고, 한계에 부딪힐 때만 복잡성을 높이는 실용주의적 원칙이 중요합니다.

자주 묻는 질문 (Q&A)

Q1. 멀티 에이전트 방식이 단독 에이전트보다 항상 더 좋은가요?

A. 그렇지 않습니다. 단순한 작업에서는 Single Agent가 훨씬 빠르고 저렴합니다. 멀티 에이전트는 복잡한 장시간 작업, 특히 다계층 시스템 아키텍처가 필요하거나 주관적 품질 평가가 중요한 경우에 진가를 발휘합니다. Full Harness는 Solo 대비 20배 이상의 비용이 들지만, 그만큼 복잡한 결과물을 요구할 때 사용해야 합니다.

Q2. 평가자 에이전트를 어떻게 “엄격하게” 만들 수 있나요?

A. Claude 모델은 기본적으로 긍정 편향성을 가지고 있어 명백한 버그도 “치명적이지 않다”고 판단하는 경향이 있습니다. 연구팀은 수많은 하네스 실행 로그를 분석하여 인간 시니어 엔지니어의 QA 기준과 어긋나는 판단 사례를 수집하고, 이를 시스템 프롬프트에 구체적인 실패 기준으로 명시하는 반복적인 프롬프트 튜닝을 통해 해결했습니다.

Q3. 에이전트 간 통신을 왜 파일 기반으로 하나요?

A. 파일 기반 통신은 각 에이전트가 독립적인 컨텍스트 윈도우를 유지할 수 있게 해줍니다. API나 메모리 공유 방식 대비 구현이 단순하고, 실행 과정을 추적하거나 디버깅하기도 쉽습니다. 또한 어느 한 에이전트가 실패해도 파일에 저장된 중간 결과물을 통해 재시작할 수 있는 내결함성도 확보됩니다.

Q4. Opus 4.6 이후로는 평가자 에이전트가 필요 없어지는 것 아닌가요?

A. 아직은 그렇지 않습니다. 모델 성능이 향상될수록 평가자의 개입 빈도는 줄어들지만, 복잡한 중첩 코드의 미세한 로직 오류나 주관적 UI 품질 평가에서는 여전히 독립적인 검증 레이어가 가치를 발휘합니다. 모델이 처리 가능한 작업의 복잡도가 높아지는 만큼, 우리가 요구하는 소프트웨어의 복잡도도 함께 높아지기 때문입니다.

Q5. 이런 멀티 에이전트 시스템을 개인 프로젝트에도 적용할 수 있나요?

A. 가능합니다. OpenClaw, Claude API, Cursor 등을 활용하면 개인 개발자도 유사한 구조를 구현할 수 있습니다. 단, 비용을 고려하여 간단한 프로젝트에는 Single Agent를 사용하고, 복잡한 장시간 프로젝트에서만 멀티 에이전트를 도입하는 것이 현실적입니다. 기획자-생성자-평가자 역할을 명확히 정의하는 것부터 시작해보세요.

---