하네스 없는 멀티 에이전트는 그냥 컨텍스트 엔지니어링
TL;DR
- 각 에이전트의 결과를 검증하고 실패를 처리할 경로가 필요하다.
- 도구와 컨텍스트의 경계도 역할에 맞춰 나눈다.
- 에이전트 수를 늘리기 전에 하나의 실행 단위부터 안정화한다.
시작하며
Anthropic의 long-running agent를 위한 하네스 설계 글1을 읽으며, 예전부터 가지고 있던 멀티 에이전트에 대한 의문을 다시 정리하게 됐다.
“에이전트 스웜”이라는 말을 처음 들었을 때부터 계속 걸리는 것들이 있었다. 정말 여러 에이전트를 붙여놓으면 성능이 극적으로 좋아질까? 사람 개발자도 여러 명이 모여 토론한다고 항상 더 좋은 결론이 나오는 것은 아닌데, 에이전트라고 다를까? 특히 지금의 대규모 언어 모델(LLM)은 꽤 고집스러운 편인데, 단순히 역할만 나눠놓는다고 서로를 잘 보완할 수 있을까?
이전 글에서 컨텍스트 엔지니어링2과 하네스 엔지니어링3에 대해 각각 다룬 적이 있다. 이번에는 그 두 관점을 엮어서, 멀티 에이전트가 언제 진짜 의미가 있고, 언제 그냥 규모만 커진 컨텍스트 엔지니어링에 불과한지를 정리해보려 한다.
1. 역할별 프롬프트만으로 충분하지는 않다
멀티 에이전트를 이야기할 때 흔히 빠지는 함정이 있다. 시스템 프롬프트만 다르게 주면 에이전트가 된다는 생각이다. “너는 코드 리뷰어야”, “너는 테스터야”, “너는 아키텍트야”라고 역할을 부여하면 각자 다른 관점에서 문제를 바라볼 것이라는 기대.
역할별 프롬프트가 다른 관점을 끌어낼 수는 있다. 다만 내가 검토하려는 것은 역할 이름보다 모델이 어떤 도구와 정보를 쓰고, 어떻게 결과를 확인하는가다.
이전 글3에서는 모델이 판단할 정보를 제공하고 갱신하는 일과, 실행 결과를 검증하고 재시도하는 일을 구분했다. 시스템 프롬프트, CLAUDE.md와 검색한 문서는 판단할 컨텍스트를 제공한다. 린터, 테스트와 재시도 루프는 실행 중 오류를 찾아 고치게 한다. 이 둘을 연결한 실행 환경을 하네스로 다룬다.
역할별 프롬프트를 주었더라도 실행 결과를 검증하고 복구하는 경로가 없다면, 앞선 에이전트의 실수가 다음 에이전트로 넘어갈 수 있다. 여기에 통신 비용과 컨텍스트 전달 과정의 정보 손실까지 생기면 역할을 나눈 이득이 줄어든다.
2. 멀티 에이전트가 의미 있는 조건
내가 멀티 에이전트를 구성할 때 먼저 확인하고 싶은 것은 각 에이전트가 자기 작업을 끝내고 검증할 수 있는가다.
예를 들어 코딩 에이전트 여러 개에 일을 나눠 맡긴다면, 역할 이름뿐 아니라 각자가 쓸 도구와 정보, 실패 시 다음 행동, 결과를 확인할 방법을 함께 설계해야 한다고 생각한다. 에이전트를 생성하는 기능만으로 이런 절차가 자동으로 갖춰지는 것은 아니다.
- 도구 경계: 각 에이전트가 맡은 작업에 필요한 도구와 접근 범위를 정한다. 코드 작성 에이전트에게는 파일 시스템과 린터를, 테스트 에이전트에게는 테스트 실행 환경과 커버리지 도구를, 리뷰 에이전트에게는 diff 도구와 아키텍처 검증 규칙을 주는 식이다.
- 복구 루프: 실패를 누가 처리할지 정한다. 코드 작성 에이전트는 린트 실패를 받아 수정할 수 있고, 테스트 에이전트는 실패 조건을 기록해 수정 담당자에게 돌려줄 수 있다. 검증만 맡은 에이전트까지 코드를 고칠 필요는 없다.
- 검증 방식: 한 에이전트의 출력을 다음 에이전트에게 넘기기 전에 테스트나 아키텍처 검사로 확인한다. 확인하지 못한 조건은 다음 단계가 알 수 있게 남긴다.
- 컨텍스트 경계: 공통 목표와 요구사항은 공유하되, 역할별로 필요한 정보와 맡은 범위를 구분한다. 같은 자료를 읽더라도 다른 작업과 검증을 맡을 수 있다. 다만 모든 탐색 기록까지 복사하면 불필요한 정보와 앞선 판단의 오류도 함께 전달될 수 있다.
이 네 가지는 여러 에이전트가 자기 작업과 검증을 책임지게 하는 기준이다. 반드시 서로 다른 하네스를 만들어야 한다는 뜻은 아니다. Anthropic의 예제도 초기 설정과 코딩을 맡는 에이전트가 같은 도구와 하네스를 사용한다.1 공유할 기반과 역할별로 확인할 결과를 구분하는 것이 중요하다.
3. 멀티 에이전트보다 먼저 해야 할 것
이 조건을 갖추면 역할을 나누는 이유도 구체화된다. 예를 들어 서로 다른 모듈의 변경을 병렬로 진행하거나, 구현 때의 판단을 그대로 따르지 않도록 별도 에이전트에게 결과 검토를 맡길 수 있다. 다만 각 변경이 따로 통과해도 합쳤을 때 동작하는지는 다시 확인해야 한다.
그래서 나는 에이전트 수를 늘리기 전에 한 작업을 맡기고 그 결과를 확인할 수 있는 실행 단위부터 만들려 한다.
하나의 작업에서 린터, 자동 테스트, 재시도 경로가 어떻게 연결되는지 먼저 확인한다. 그 기반 위에서 역할을 나눴을 때 얻는 병렬 처리나 별도 검토의 이득이, 전달과 통합에 드는 비용보다 큰지 보려 한다.
Anthropic의 long-running agent 하네스 설계 글1에서도 강조하듯이, 한 번에 하나의 기능만 구현하게 제한하고, 매 세션 종료 시 상태를 기록하고, 다음 세션이 이전 작업을 빠르게 파악하게 하는 것이 하나의 에이전트를 안정적으로 동작시키는 핵심이다. 이 사례는 세션을 이어가는 방법을 보여준다. 동시에 여러 에이전트를 쓰는 편이 더 좋은지까지 입증한 것은 아니므로, 역할 분리의 효과는 맡길 작업에서 확인해야 한다.
마치며
나는 역할을 몇 개로 나눴는지보다, 실패했을 때 누가 어떤 근거로 다음 행동을 정하는지부터 보려 한다.
그 경로를 설명할 수 없다면 에이전트를 더 붙이기 전에 도구와 검증부터 보강하는 편이 낫다고 생각한다. 역할을 나눈 뒤에도 그 검증이 유지되어야 작업을 맡길 수 있다.