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