하네스의 핵심은 결국 멀티 에이전트였다

지난 3월 말, revfactory/harness라는 하네스 자동 구성 스킬을 만들었습니다.

현재 GitHub에서 8,300개 이상의 Star 를 받으며, 여러 사람들에게 도움을 주거나 영감을 주고 있습니다.

 

이 스킬은 겉으로 보면 사용자가 원하는 분야를 분석해 전문 에이전트 팀과 스킬, 오케스트레이션 구조를 자동으로 만들어 주는 도구입니다. Pipeline, Fan-out/Fan-in, Expert Pool, Producer–Reviewer, Supervisor, Hierarchical Delegation 등 여러 협업 구조 가운데 작업에 적합한 패턴을 선택하고, 에이전트 정의와 스킬, 검증 절차까지 구성합니다.

 

그러나 돌이켜보면 이 프로젝트의 핵심은 ‘하네스 파일을 자동으로 생성하는 것’이 아니었습니다. 처음부터 진짜 관심사는 에이전트를 중심으로 작업을 어떻게 분해하고, 행동을 어떻게 제어하며, 여러 에이전트가 어떻게 협력하고 서로의 결과를 검증하게 할 것인가였습니다.

 

 

 

하네스라는 이름보다 중요했던 것

하네스는 흔히 모델 바깥에 존재하는 실행 코드나 고정된 프레임워크로 이해됩니다. 실제로 Anthropic도 에이전트 하네스를 모델을 실제로 작동하는 에이전트로 바꾸는 주변 구조, 즉 실행 루프와 도구, 컨텍스트 관리, 가드레일을 포함하는 소프트웨어적 스캐폴딩으로 정의합니다.

 

그런 관점에서 보면 “에이전트와 스킬을 생성하는 것이 왜 하네스인가?”라는 질문이 나오는 것도 자연스럽습니다.

 

하지만 제가 생각한 하네스는 특정 런타임 코드에만 한정되지 않았습니다. 역할과 책임, 사용 가능한 도구, 컨텍스트의 범위, 작업 전달 방식, 실패 시 행동, 검증 기준과 종료 조건 역시 에이전트의 행동을 둘러싸는 하네스의 일부라고 보았습니다.

 

하네스에 필요한 요소를 반드시 외부 코드로만 구현할 필요는 없습니다. 충분히 강력한 모델에서는 그 구조의 일부를 에이전트 정의와 스킬, 프롬프트, 협업 규칙 안으로 흡수할 수 있습니다. 모델이 발전할수록 고정 코드가 담당하던 판단 중 일부는 에이전트가 맡게 되고, 하네스는 점차 ‘모든 행동을 미리 지정하는 시스템’에서 ‘에이전트가 올바른 결정을 내릴 수 있도록 경계와 피드백을 설계하는 시스템’으로 이동하게 됩니다.

 

이것이 제가 harness를 만들며 실험하고 싶었던 지점입니다.

 

 

여러 에이전트를 띄우는 것만으로는 부족하다

멀티 에이전트의 가치는 단순히 모델 인스턴스를 여러 개 실행하는 데서 나오지 않습니다.

 

핵심은 각 에이전트가 서로 다른 역할과 독립적인 컨텍스트를 가지고 문제를 바라보게 만드는 것입니다. 한 에이전트는 결과물을 만들고, 다른 에이전트는 비판하며, 또 다른 에이전트는 사실이나 테스트 결과를 검증할 수 있습니다. 작업을 여러 방향으로 나누어 동시에 탐색한 뒤 하나의 결과로 합칠 수도 있고, 여러 에이전트가 같은 문제를 서로 다른 방식으로 풀게 한 뒤 평가 에이전트가 가장 좋은 결과를 선택하게 할 수도 있습니다.

 

이 구조는 단일 에이전트에서 자주 발생하는 자기 확신, 목표 이탈, 중간 단계 누락을 줄이는 데 도움이 됩니다. Anthropic이 공개한 Dynamic Workflows의 대표 패턴 역시 Fan-out-and-synthesize, adversarial verification, generate-and-filter, tournament, loop-until-done 등으로 구성됩니다. 결국 작업 분해, 독립 실행, 상호 검증, 반복이라는 동일한 원리입니다.

 

 

 

장기 실행에서도 중요한 것은 에이전트의 의지만이 아닙니다. 진행 상태를 외부에 기록하고, 실패한 접근을 남기며, 체크포인트에서 다시 시작하고, 테스트와 평가 결과를 다음 행동의 피드백으로 제공해야 합니다.

 

Anthropic이 16개의 Claude 에이전트로 C 컴파일러를 만드는 실험을 진행했을 때도, 연구자가 가장 많은 노력을 투입한 부분은 병렬 실행 자체가 아니라 테스트 환경과 피드백, 진행 문서, 동기화 방식이었습니다. 이 실험은 약 2,000회의 Claude Code 세션을 거쳐 10만 줄 규모의 컴파일러를 만들었지만, 동시에 높은 비용과 코드 품질, 회귀 문제 등의 한계도 분명히 보여주었습니다.

 

멀티 에이전트의 성능은 에이전트 수가 아니라 에이전트가 실패를 발견하고 다시 시도할 수 있도록 설계된 환경의 품질에서 결정됩니다. 결국 좋은 멀티 에이전트 시스템은 좋은 하네스를 필요로 합니다.

 

 

 

품질 향상은 분명했지만, 아직 증명해야 할 것도 많다

revfactory/harness를 만들면서 제가 가장 강하게 체감한 것은 결과물의 품질과 일관성이었습니다.

 

공개한 자체 A/B 실험에서는 15개 소프트웨어 엔지니어링 과제에서 평균 품질 점수가 49.5점에서 79.3점으로 상승했고, 15개 과제 모두에서 하네스를 적용한 결과가 우세했습니다. 결과 분산도 32% 감소했습니다. 다만 이 실험은 표본이 15개로 작고 직접 측정한 결과라서, 아직 제3자의 반복 검증이 필요합니다.

 

외부의 실험들도 비슷한 가능성을 보여주고 있었습니다. Anthropic은 자사의 리서치 평가에서 Opus 4를 단독으로 사용한 시스템보다 Opus 4를 리드 에이전트로, Sonnet 4를 서브에이전트로 사용한 멀티 에이전트 시스템이 90.2% 높은 성능을 보였다고 밝혔습니다.

(출처: https://www.anthropic.com/engineering/multi-agent-research-system)

 

 

 

 

하지만 동시에 멀티 에이전트 시스템은 일반 채팅보다 약 15배 많은 토큰을 사용했고, 에이전트 사이의 의존성이 높은 작업에는 적합하지 않을 수 있다고 설명했습니다. 특히 모든 작업이 긴밀하게 같은 상태를 공유해야 한다면 협업 비용이 성능 향상을 넘어설 수 있습니다.

 

따라서 멀티 에이전트는 언제나 단일 에이전트보다 뛰어난 만능 구조가 아닙니다. 독립적으로 탐색할 수 있는 영역이 많고, 넓은 범위의 정보를 다뤄야 하며, 결과를 서로 검증할 가치가 높은 작업에서 특히 유리합니다.

중요한 질문은 “멀티 에이전트를 사용할 것인가?”가 아니라, 이 작업의 가치가 병렬화와 협업에 드는 비용을 정당화하는가?입니다.

 

 

 

예상보다 빨리 제품 기능이 되기 시작했다

harness를 만들 당시에도 이런 구조는 머지않아 Anthropic이나 OpenAI의 기본 기능 안으로 흡수될 가능성이 높다고 생각했습니다.

 

그 이유는 제가 특별히 미래를 잘 예측했기 때문이 아닙니다. 여러 연구와 제품 실험이 작업 분해, 병렬 실행, 전문화, 반복 검증이 실제 성능을 높일 수 있다는 같은 방향을 가리키고 있었기 때문입니다.

 

그리고 그 변화는 예상보다 빠르게 나타났습니다.

Anthropic은 2026년 2월 Claude Code에 병렬로 작업하고 자율적으로 협업하는 Agent Teams를 연구 프리뷰로 도입했습니다. 이어 5월 28일에는 하나의 세션에서 수십 개에서 수백 개의 서브에이전트를 실행할 수 있는 Dynamic Workflows를 공개했습니다. Claude가 작업을 분석한 뒤 오케스트레이션 코드를 직접 작성하고, 병렬 에이전트를 실행하며, 결과를 검증하는 방식입니다.

 

6월 2일 Anthropic이 공개한 후속 글의 제목은 아예 “A harness for every task”였습니다. 이 글은 Claude가 주어진 작업에 맞는 멀티 에이전트 하네스를 즉석에서 작성하고 오케스트레이션할 수 있다고 설명합니다. 사용자는 Dynamic Workflow를 직접 요청하거나 ultracode 설정을 통해 Claude가 필요한 경우 워크플로를 만들도록 할 수 있습니다.

7월 9일에는 OpenAI가 GPT-5.6과 함께 ultra를 공개했습니다. ultra는 기본적으로 네 개의 에이전트를 병렬로 조정하며, OpenAI는 BrowseComp, SEC-Bench Pro, Terminal-Bench 2.1에서 단일 에이전트 대비 더 높은 성능과 더 짧은 완료 시간을 보였다고 발표했습니다. Responses API에도 여러 서브에이전트를 병렬 실행하고 결과를 종합하는 Multi-agent 기능이 베타로 추가됐습니다.

 

이런 흐름은 revfactory/harness의 구현이 정답이었다는 증거는 아닙니다. 하지만 적어도 모델의 능력을 더 끌어내기 위해 하네스와 멀티 에이전트 구조가 결합되는 방향이 하나의 중요한 제품 흐름으로 자리 잡고 있다는 신호로는 볼 수 있습니다.

 

흡수된다고 해서 하네스가 사라지는 것은 아니다

플랫폼이 멀티 에이전트 기능을 기본 제공하면 별도의 하네스가 필요 없어지는 것처럼 보일 수도 있습니다.

 

저는 오히려 반대라고 생각합니다.

 

플랫폼이 제공하는 것은 에이전트를 생성하고 병렬로 실행할 수 있는 범용 능력입니다. 그러나 어떤 역할을 만들어야 하는지, 무엇을 병렬화해야 하는지, 어떤 정보를 공유하거나 격리해야 하는지, 누가 최종 결정을 내릴지, 어떤 기준으로 검증하고 언제 중단할지는 여전히 작업과 도메인에 따라 달라집니다.

 

런타임이 멀티 에이전트를 지원할수록 하네스의 관심사는 실행 인프라에서 팀 설계와 행동 설계로 이동합니다.

 

고정된 하네스와 동적으로 생성되는 하네스도 어느 한쪽이 다른 쪽을 완전히 대체하지는 않을 것입니다. 반복성과 감사 가능성, 규정 준수가 중요한 업무에서는 사전에 검증된 정적 구조가 유리합니다. 반대로 매번 문제의 형태가 달라지는 탐색적 작업에서는 에이전트가 즉석에서 팀과 워크플로를 구성하는 동적 방식이 효과적일 수 있습니다.

 

앞으로는 검증된 정적 규칙을 기반으로 에이전트가 작업별 구조를 동적으로 확장하는 혼합형 방식이 중요해질 가능성이 높습니다.

 

이제 더 연구해야 할 것은 에이전트다

지금은 멀티 에이전트가 널리 쓰이기 시작하는 극초기입니다. 어느 회사의 구현이 최종 형태가 될지, 정적 오케스트레이션과 동적 오케스트레이션 가운데 무엇이 우세할지 아직 알 수 없습니다.

 

그래서 지금 우리에게 필요한 것은 에이전트에 대한 더 많은 연구와 실험입니다.

 

에이전트의 역할을 어떤 수준으로 구체화해야 하는지, 어떤 정보와 도구를 제공해야 하는지, 행동의 자유와 통제 사이의 경계를 어디에 두어야 하는지 연구해야 합니다. 에이전트 간의 통신 구조와 공유 상태, 충돌 해결, 실패 전파, 비용 예산과 종료 조건도 다뤄야 합니다.

 

평가 방법 역시 최종 결과가 성공했는지만 보는 수준을 넘어가야 합니다. 품질뿐 아니라 결과의 분산, 비용, 지연 시간, 복구 가능성, 추적 가능성, 인간 개입의 빈도까지 함께 측정해야 합니다. 같은 결과에 도달했더라도 불안정한 경로를 거친 시스템과 반복 가능하고 설명 가능한 시스템은 동일한 품질의 하네스라고 할 수 없습니다.

 

멀티 에이전트는 마법이 아닙니다. 여러 에이전트를 붙인다고 자동으로 집단지성이 만들어지는 것도 아닙니다. 잘못 설계된 팀은 같은 실수를 반복하고, 서로의 작업을 방해하며, 더 많은 비용을 사용한 뒤 더 혼란스러운 결과를 내놓을 수도 있습니다.

 

결국 앞으로의 경쟁은 “몇 개의 에이전트를 동시에 실행할 수 있는가”만으로 결정되지 않을 것입니다.

 

누가 에이전트의 역할과 경계를 더 잘 정의하는가.누가 협업과 검증 구조를 더 정교하게 설계하는가.누가 실패를 관찰하고 하네스를 지속적으로 개선할 수 있는가.

 

 

 

하네스의 핵심은 에이전트를 감싸는 파일이나 코드의 형태가 아니었습니다. 에이전트가 오랫동안 방향을 잃지 않고 일하고, 서로 다른 관점으로 협력하며, 자신의 결과를 반복해서 의심하고 검증하게 만드는 구조였습니다.