<div id="readability-page-1" class="page"><div>
  <h2>하네스 없는 멀티 에이전트는 그냥 컨텍스트 엔지니어링이다</h2>
  
  <p><span>2026년 03월 31일 작성</span></p><h2 id="tldr">TL;DR</h2>

<ul>
  <li>에이전트는 “프롬프트가 다른 LLM”이 아니라, LLM·도구·컨텍스트·하네스가 결합된 <strong>실행 단위</strong>다.</li>
  <li>멀티 에이전트가 의미 있으려면, 각 에이전트가 자기만의 도구·복구 루프·검증 방식·컨텍스트 경계를 가진 <strong>독립적인 실행 구조</strong>여야 한다.</li>
  <li>하네스 없이 역할만 나눈 멀티 에이전트는, 하나의 LLM에게 더 많은 역할과 문맥 조각을 던져주는 것에 지나지 않는다.</li>
</ul>

<h2 id="시작하며">시작하며</h2>

<p>Anthropic의 long-running agent를 위한 하네스 설계 글<sup id="fnref:1" role="doc-noteref"><a href="#fn:1" rel="footnote">1</a></sup>을 읽으며, 예전부터 가지고 있던 멀티 에이전트에 대한 의문을 다시 정리하게 됐다.</p>

<p>“에이전트 스웜”이라는 말을 처음 들었을 때부터 계속 걸리는 것들이 있었다. 정말 여러 에이전트를 붙여놓으면 성능이 극적으로 좋아질까? 사람 개발자도 여러 명이 모여 토론한다고 항상 더 좋은 결론이 나오는 것은 아닌데, 에이전트라고 다를까? 특히 지금의 LLM은 꽤 고집스러운 편인데, 단순히 역할만 나눠놓는다고 서로를 잘 보완할 수 있을까?</p>

<p>이전 글에서 컨텍스트 엔지니어링<sup id="fnref:2" role="doc-noteref"><a href="#fn:2" rel="footnote">2</a></sup>과 하네스 엔지니어링<sup id="fnref:3" role="doc-noteref"><a href="#fn:3" rel="footnote">3</a></sup>에 대해 각각 다룬 적이 있다. 이번에는 그 두 관점을 엮어서, 멀티 에이전트가 언제 진짜 의미가 있고, 언제 그냥 규모만 커진 컨텍스트 엔지니어링에 불과한지를 정리해보려 한다.</p>

<h2 id="1-에이전트는-프롬프트가-다른-llm이-아니다">1. 에이전트는 프롬프트가 다른 LLM이 아니다</h2>

<p>멀티 에이전트를 이야기할 때 흔히 빠지는 함정이 있다. 시스템 프롬프트만 다르게 주면 에이전트가 된다는 생각이다. “너는 코드 리뷰어야”, “너는 테스터야”, “너는 아키텍트야”라고 역할을 부여하면 각자 다른 관점에서 문제를 바라볼 것이라는 기대.</p>

<p>하지만 에이전트는 단순히 “프롬프트가 다른 LLM”이 아니다. <strong>에이전트는 LLM, 도구, 컨텍스트, 그리고 하네스가 결합된 실행 단위에 가깝다.</strong></p>

<p>여기서 핵심은 컨텍스트와 하네스의 역할이 다르다는 점이다. 이전 글<sup id="fnref:3:1" role="doc-noteref"><a href="#fn:3" rel="footnote">3</a></sup>에서 다뤘듯이, <strong>컨텍스트 엔지니어링은 에이전트가 긴 주기 안에서 원하는 방향으로 계속 나아가게 해준다.</strong> 시스템 프롬프트, CLAUDE.md, RAG 문서, 메모리 등으로 “어디로 가야 하는지”를 알려주는 것이다. <strong>하네스 엔지니어링은 짧은 주기 안에서 에러를 복구하고, 다시 시도하고, 실패를 관리하면서 자율적으로 일하게 해준다.</strong> 린터, CI, 구조적 테스트, 재시도 루프 등으로 “가는 도중에 넘어져도 자동으로 일어나게” 하는 것이다.</p>

<p>프롬프트만 다르게 준 에이전트에는 이 둘 중 하네스가 빠져 있다. 큰 방향은 컨텍스트로 줄 수 있지만, 짧은 실행 주기에서의 오류 복구와 검증이 없다. 그래서 역할만 나눠놓으면 각자 열심히 일하는 것처럼 보이지만, 실수가 누적되고, 서로의 결과물을 제대로 검증하지 못하고, 결국 기대만큼의 성능이 나오지 않는다.</p>

<h2 id="2-멀티-에이전트가-의미-있는-조건">2. 멀티 에이전트가 의미 있는 조건</h2>

<p>그렇다면 멀티 에이전트는 언제 의미가 있을까?</p>

<p><strong>각 에이전트가 단순히 역할이나 프롬프트만 다른 것이 아니라, 각자 충분히 하네싱된 실행 구조를 가질 때다.</strong></p>

<p>예를 들어 Claude Code 같은 환경에서는 에이전트를 만들 때 각 에이전트별로 하네싱을 꽤 세밀하게 걸어줄 수 있다. 각 에이전트에 맞는 도구, 복구 루프, 검증 방식, 컨텍스트 경계까지 설계할 수 있다는 뜻이다.</p>

<p>구체적으로 무엇이 필요한가?</p>

<ul>
  <li><strong>도구 경계</strong>: 각 에이전트가 접근할 수 있는 도구가 분리되어야 한다. 코드 작성 에이전트에게는 파일 시스템과 린터를, 테스트 에이전트에게는 테스트 실행 환경과 커버리지 도구를, 리뷰 에이전트에게는 diff 도구와 아키텍처 검증 규칙을 주는 식이다.</li>
  <li><strong>복구 루프</strong>: 각 에이전트가 자기 영역에서 실패했을 때 스스로 복구할 수 있어야 한다. 코드 작성 에이전트가 린트 실패를 받으면 자동으로 수정하고, 테스트 에이전트가 실패한 테스트를 분석하여 원인을 보고하는 것.</li>
  <li><strong>검증 방식</strong>: 에이전트의 결과물을 기계적으로 검증하는 메커니즘이 있어야 한다. 희망이 아니라 강제다. 한 에이전트의 출력이 다음 에이전트의 입력이 되기 전에, 자동화된 검증을 거쳐야 한다.</li>
  <li><strong>컨텍스트 경계</strong>: 각 에이전트가 볼 수 있는 컨텍스트가 명확히 분리되어야 한다. 모든 에이전트가 같은 컨텍스트를 공유하면, 그것은 사실상 하나의 에이전트에게 여러 역할을 부여한 것과 다름없다.</li>
</ul>

<p>이 네 가지가 갖춰져야 멀티 에이전트는 <strong>실제로 독립적인 실행 단위</strong>로서 동작한다. 사람 조직에 비유하면, 단순히 “너는 프론트엔드, 너는 백엔드”라고 역할만 나누는 것과, 각 팀에 자체 CI/CD 파이프라인, 코드 리뷰 프로세스, 배포 권한, 모니터링 대시보드가 있는 것의 차이다.</p>

<h2 id="3-하네스-없는-멀티-에이전트의-실체">3. 하네스 없는 멀티 에이전트의 실체</h2>

<p>하네스 없이 역할만 나눈 멀티 에이전트는 어떻게 되는가?</p>

<p>겉으로는 여러 에이전트가 협업하는 것처럼 보인다. “기획 에이전트가 요구사항을 정리하고, 코딩 에이전트가 구현하고, 리뷰 에이전트가 검토한다”는 그림은 직관적이고 매력적이다.</p>

<p><strong>하지만 실제로는 하나의 LLM에게 더 많은 역할 분리와 더 많은 문맥 조각을 던져주는 것에 지나지 않을 수 있다.</strong> 각 에이전트가 독자적인 실행 환경이나 검증 메커니즘 없이 같은 LLM을 시스템 프롬프트만 바꿔 호출하는 구조라면, 그것은 결국 하나의 LLM에게 순차적으로 다른 역할을 맡기는 것과 본질이 같다.</p>

<p>이 상태에서 기대하는 만큼의 성능 향상도, ROI도 나오기 어렵다. 오히려 에이전트 간 통신 오버헤드, 컨텍스트 전달 과정에서의 정보 손실, 그리고 각 에이전트의 실수가 검증 없이 다음 에이전트로 전파되는 문제까지 더해진다.</p>

<p>사람 조직에서도 마찬가지다. 프로세스, 도구, 검증 체계 없이 역할만 나누면 오히려 커뮤니케이션 비용만 늘어난다. 에이전트도 다르지 않다.</p>

<h2 id="4-멀티-에이전트보다-먼저-해야-할-것">4. 멀티 에이전트보다 먼저 해야 할 것</h2>

<p>그래서 지금 시점에서 더 중요한 것은 에이전트 수를 늘리는 일이 아니라, <strong>개별 에이전트가 끝까지 안정적으로 일할 수 있도록 하네스를 설계하는 일</strong>이다.</p>

<p>하나의 에이전트가 린터, CI, 구조적 테스트, 재시도 루프를 갖추고 안정적으로 긴 태스크를 완수할 수 있는가? 이 질문에 “그렇다”고 답할 수 있을 때, 그제서야 두 번째 에이전트를 붙이는 것이 의미가 있다.</p>

<p>Anthropic의 long-running agent 하네스 설계 글<sup id="fnref:1:1" role="doc-noteref"><a href="#fn:1" rel="footnote">1</a></sup>에서도 강조하듯이, <strong>한 번에 하나의 기능만 구현하게 제한하고, 매 세션 종료 시 상태를 기록하고, 다음 세션이 이전 작업을 빠르게 파악하게 하는 것</strong>이 하나의 에이전트를 안정적으로 동작시키는 핵심이다. 이 기반이 없는 상태에서 에이전트를 여러 개 붙여봐야, 불안정한 단위들이 모여서 더 불안정한 시스템이 될 뿐이다.</p>

<h2 id="마치며">마치며</h2>

<p>멀티 에이전트가 효과를 가지는 순간은 에이전트를 많이 만들었을 때가 아니라, <strong>각 에이전트가 각자의 하네스를 가지고 실제로 독립적인 실행 단위처럼 동작할 때</strong>다.</p>

<p>그 전까지의 많은 멀티 에이전트는, 생각보다 그냥 규모가 커진 컨텍스트 엔지니어링일지도 모른다.</p>

<p>에이전트 수를 늘리기 전에, 하나의 에이전트가 넘어져도 스스로 일어날 수 있는 환경부터 만들자. 그것이 결국 멀티 에이전트로 가는 가장 빠른 길이다.</p>

<hr>



</div></div>

Haandol

TL;DR
에이전트는 “프롬프트가 다른 LLM”이 아니라, LLM·도구·컨텍스트·하네스가 결합된 실행 단위다.
멀티 에이전트가 의미 있으려면, 각 에이전트가 자기만의 도구·복구 루프·검증 방식·컨텍스트 경계를 가진 독립적인 실행 구조여야 한다.
하네스 없이 역할만 나눈 멀티 에이전트는, 하나의 LLM에게 더 많은 역할과 문맥 조각을 던져주는 것에 지나지 않는다.
시작하며
Anthropic의 long-running agent를 위한 하네스 설계 글1을 읽으며, 예전부터 가지고 있던 멀티 에이전트에 대한 의문을 다시 정리하게 됐다.
“에이전트 스웜”이라는 말을 처음 들었을 때부터 계속 걸리는 것들이 있었다. 정말 여러 에이전트를 붙여놓으면 성능이 극적으로 좋아질까? 사람 개발자도 여러 명이 모여 토론한다고 항상 더 좋은 결론이 나오는 것은 아닌데, 에이전트라고 다를까? 특히 지금의 LLM은 꽤 고집스러운 편인데, 단순히 역할만 나눠놓는다고 서로를 잘 보완할 수 있을까?
이전 글에서 컨텍스트 엔지니어링2과 하네스 엔지니어링3에 대해 각각 다룬 적이 있다. 이번에는 그 두 관점을 엮어서, 멀티 에이전트가 언제 진짜 의미가 있고, 언제 그냥 규모만 커진 컨텍스트 엔지니어링에 불과한지를 정리해보려 한다.
1. 에이전트는 프롬프트가 다른 LLM이 아니다
멀티 에이전트를 이야기할 때 흔히 빠지는 함정이 있다. 시스템 프롬프트만 다르게 주면 에이전트가 된다는 생각이다. “너는 코드 리뷰어야”, “너는 테스터야”, “너는 아키텍트야”라고 역할을 부여하면 각자 다른 관점에서 문제를 바라볼 것이라는 기대.
하지만 에이전트는 단순히 “프롬프트가 다른 LLM”이 아니다. 에이전트는 LLM, 도구, 컨텍스트, 그리고 하네스가 결합된 실행 단위에 가깝다.
여기서 핵심은 컨텍스트와 하네스의 역할이 다르다는 점이다. 이전 글3에서 다뤘듯이, 컨텍스트 엔지니어링은 에이전트가 긴 주기 안에서 원하는 방향으로 계속 나아가게 해준다. 시스템 프롬프트, CLAUDE.md, RAG 문서, 메모리 등으로 “어디로 가야 하는지”를 알려주는 것이다. 하네스 엔지니어링은 짧은 주기 안에서 에러를 복구하고, 다시 시도하고, 실패를 관리하면서 자율적으로 일하게 해준다. 린터, CI, 구조적 테스트, 재시도 루프 등으로 “가는 도중에 넘어져도 자동으로 일어나게” 하는 것이다.
프롬프트만 다르게 준 에이전트에는 이 둘 중 하네스가 빠져 있다. 큰 방향은 컨텍스트로 줄 수 있지만, 짧은 실행 주기에서의 오류 복구와 검증이 없다. 그래서 역할만 나눠놓으면 각자 열심히 일하는 것처럼 보이지만, 실수가 누적되고, 서로의 결과물을 제대로 검증하지 못하고, 결국 기대만큼의 성능이 나오지 않는다.
2. 멀티 에이전트가 의미 있는 조건
그렇다면 멀티 에이전트는 언제 의미가 있을까?
각 에이전트가 단순히 역할이나 프롬프트만 다른 것이 아니라, 각자 충분히 하네싱된 실행 구조를 가질 때다.
예를 들어 Claude Code 같은 환경에서는 에이전트를 만들 때 각 에이전트별로 하네싱을 꽤 세밀하게 걸어줄 수 있다. 각 에이전트에 맞는 도구, 복구 루프, 검증 방식, 컨텍스트 경계까지 설계할 수 있다는 뜻이다.
구체적으로 무엇이 필요한가?
도구 경계: 각 에이전트가 접근할 수 있는 도구가 분리되어야 한다. 코드 작성 에이전트에게는 파일 시스템과 린터를, 테스트 에이전트에게는 테스트 실행 환경과 커버리지 도구를, 리뷰 에이전트에게는 diff 도구와 아키텍처 검증 규칙을 주는 식이다.
복구 루프: 각 에이전트가 자기 영역에서 실패했을 때 스스로 복구할 수 있어야 한다. 코드 작성 에이전트가 린트 실패를 받으면 자동으로 수정하고, 테스트 에이전트가 실패한 테스트를 분석하여 원인을 보고하는 것.
검증 방식: 에이전트의 결과물을 기계적으로 검증하는 메커니즘이 있어야 한다. 희망이 아니라 강제다. 한 에이전트의 출력이 다음 에이전트의 입력이 되기 전에, 자동화된 검증을 거쳐야 한다.
컨텍스트 경계: 각 에이전트가 볼 수 있는 컨텍스트가 명확히 분리되어야 한다. 모든 에이전트가 같은 컨텍스트를 공유하면, 그것은 사실상 하나의 에이전트에게 여러 역할을 부여한 것과 다름없다.
이 네 가지가 갖춰져야 멀티 에이전트는 실제로 독립적인 실행 단위로서 동작한다. 사람 조직에 비유하면, 단순히 “너는 프론트엔드, 너는 백엔드”라고 역할만 나누는 것과, 각 팀에 자체 CI/CD 파이프라인, 코드 리뷰 프로세스, 배포 권한, 모니터링 대시보드가 있는 것의 차이다.
3. 하네스 없는 멀티 에이전트의 실체
하네스 없이 역할만 나눈 멀티 에이전트는 어떻게 되는가?
겉으로는 여러 에이전트가 협업하는 것처럼 보인다. “기획 에이전트가 요구사항을 정리하고, 코딩 에이전트가 구현하고, 리뷰 에이전트가 검토한다”는 그림은 직관적이고 매력적이다.
하지만 실제로는 하나의 LLM에게 더 많은 역할 분리와 더 많은 문맥 조각을 던져주는 것에 지나지 않을 수 있다. 각 에이전트가 독자적인 실행 환경이나 검증 메커니즘 없이 같은 LLM을 시스템 프롬프트만 바꿔 호출하는 구조라면, 그것은 결국 하나의 LLM에게 순차적으로 다른 역할을 맡기는 것과 본질이 같다.
이 상태에서 기대하는 만큼의 성능 향상도, ROI도 나오기 어렵다. 오히려 에이전트 간 통신 오버헤드, 컨텍스트 전달 과정에서의 정보 손실, 그리고 각 에이전트의 실수가 검증 없이 다음 에이전트로 전파되는 문제까지 더해진다.
사람 조직에서도 마찬가지다. 프로세스, 도구, 검증 체계 없이 역할만 나누면 오히려 커뮤니케이션 비용만 늘어난다. 에이전트도 다르지 않다.
4. 멀티 에이전트보다 먼저 해야 할 것
그래서 지금 시점에서 더 중요한 것은 에이전트 수를 늘리는 일이 아니라, 개별 에이전트가 끝까지 안정적으로 일할 수 있도록 하네스를 설계하는 일이다.
하나의 에이전트가 린터, CI, 구조적 테스트, 재시도 루프를 갖추고 안정적으로 긴 태스크를 완수할 수 있는가? 이 질문에 “그렇다”고 답할 수 있을 때, 그제서야 두 번째 에이전트를 붙이는 것이 의미가 있다.
Anthropic의 long-running agent 하네스 설계 글1에서도 강조하듯이, 한 번에 하나의 기능만 구현하게 제한하고, 매 세션 종료 시 상태를 기록하고, 다음 세션이 이전 작업을 빠르게 파악하게 하는 것이 하나의 에이전트를 안정적으로 동작시키는 핵심이다. 이 기반이 없는 상태에서 에이전트를 여러 개 붙여봐야, 불안정한 단위들이 모여서 더 불안정한 시스템이 될 뿐이다.
마치며
멀티 에이전트가 효과를 가지는 순간은 에이전트를 많이 만들었을 때가 아니라, 각 에이전트가 각자의 하네스를 가지고 실제로 독립적인 실행 단위처럼 동작할 때다.
그 전까지의 많은 멀티 에이전트는, 생각보다 그냥 규모가 커진 컨텍스트 엔지니어링일지도 모른다.
에이전트 수를 늘리기 전에, 하나의 에이전트가 넘어져도 스스로 일어날 수 있는 환경부터 만들자. 그것이 결국 멀티 에이전트로 가는 가장 빠른 길이다.
Anthropic - Effective harnesses for long-running agents ↩ ↩2
컨텍스트 엔지니어링 - 정적 컨텍스트와 동적 컨텍스트 ↩
쉽게 설명한 하네스 엔지니어링 ↩ ↩2

하네스 없는 멀티 에이전트는 그냥 컨텍스트 엔지니어링이다

댓글