멀티에이전트를 효율적으로 구축하는 방법: 역할보다 작업 경계부터
에이전트 세 명에게 같은 요구사항을 보내면 결과도 세 개가 나온다. 하지만 누가 어느 부분을 책임지는지, 충돌한 결과를 누가 판단할지 정하지 않았다면 검토 작업만 늘어난다. 멀티에이전트는 여러 모델을 동시에 호출하는 기능이 아니라, 분리 가능한 일을 맡기고 하나의 결과로 검증해 합치는 작업 방식이다.
1. 먼저 단일 에이전트로 기준선을 만든다
시작부터 역할을 여러 개 만들 필요는 없다. 한 에이전트에게 적절한 도구와 명확한 지시를 주고 실제 작업을 수행하게 한다. 결과가 이미 충분하면 다중 구조는 호출 비용과 지연만 더할 수 있다. 작업이 반복해서 실패하거나, 독립적인 조사·검토 때문에 한 실행의 문맥이 너무 커질 때 분할을 검토한다. OpenAI의 에이전트 구축 가이드도 단일 에이전트에서 시작해 필요할 때 구조를 늘리는 접근을 권한다.
예를 들어 짧은 공지문을 다듬는 일은 한 에이전트가 작성과 교정을 끝낼 수 있다. 반면 여러 국가의 서로 다른 규정을 조사하고 각 출처를 확인해야 하는 보고서는 조사 범위를 분리할 여지가 있다. 판단 기준은 에이전트 이름이 아니라 독립된 입력, 산출물, 검증 방법이 있는지다.
2. 병렬로 맡길 수 있는 일과 순서가 필요한 일을 구분한다
두 작업이 서로의 결과를 기다리지 않아도 되면 병렬로 처리한다. 자료 조사에서 국가 A와 국가 B의 공식 문서를 각각 확인하는 일은 좋은 후보다. 반면 자료를 확정한 뒤 요약을 작성해야 한다면 조사와 요약을 동시에 시작하면 추측이 끼어들기 쉽다. Anthropic의 설계 가이드는 병렬 처리와 조정자·작업자 방식을 구분한다. 전자는 나눌 작업이 미리 정해져 있을 때, 후자는 입력마다 필요한 하위 작업이 달라질 때 쓴다.
간단한 선택 규칙: 입력과 절차가 고정돼 있으면 일반 코드나 정해진 순서의 워크플로로 처리한다. 작업을 동적으로 나눠야 하면 조정자가 필요한 작업자를 호출하게 한다. 사용자의 의도에 따라 전문 담당자로 대화의 제어권이 넘어가야 하면 인계 방식을 고려한다. 복잡도가 높다는 이유만으로 모든 작업을 자유로운 집단 토론으로 만들지 않는다.
3. 각 작업에 한 장짜리 계약을 준다
“시장 조사를 해줘”는 결과를 합치기 어렵다. 다음처럼 책임과 완료 조건을 적으면 다른 작업자와 경계가 선명해진다.
- 목표: 지정한 시장의 최근 공개 자료에서 고객 불편 세 가지를 찾는다.
- 범위: 지정한 국가와 제품군만 조사한다. 다른 국가의 수치는 사용하지 않는다.
- 입력: 제품 설명, 기준 날짜, 허용된 자료 목록을 전달한다.
- 산출물: 불편 항목마다 근거 링크, 자료 날짜, 한 줄 설명, 확인되지 않은 점을 적는다.
- 완료 조건: 링크가 열리고 주장을 직접 뒷받침하는지 확인한다. 근거가 없으면 ‘확인 불가’로 표시한다.
파일을 수정하는 작업이라면 담당 파일과 수정 금지 파일도 적는다. 두 작업자가 같은 파일을 동시에 바꾸면 합칠 때 충돌한다. 쓰기 권한은 필요한 범위로 제한하고 배포나 결제처럼 외부 상태를 바꾸는 단계에는 승인 지점을 둔다.
4. 전체 대화 대신 필요한 문맥만 전달한다
작업자에게 지난 대화를 통째로 복사하면 관련 없는 정보가 비용과 혼동을 늘린다. 작업 지시에는 원래 목표, 담당 범위, 반드시 지켜야 할 제약, 사용 가능한 자료, 기대하는 출력 형식만 담는다. 작업자는 결과와 근거, 미해결 문제를 짧게 돌려준다. LangChain의 인계 문서도 다음 단계에 필요한 내용만 선택해 전달하도록 설명한다.
단, 앞선 작업의 판단에 의존한다면 요약만으로 부족할 수 있다. 숫자, 원문 인용, 파일 변경 사항처럼 검증에 필요한 원자료의 위치를 함께 넘겨야 한다. 문맥을 줄이는 목적은 근거를 버리는 것이 아니라 재검토할 수 있는 형태로 만드는 데 있다.
5. 조정자는 결과를 합치기 전에 검사한다
조정자의 일은 여러 답변을 이어 붙이는 데서 끝나지 않는다. 각 작업의 완료 조건을 확인하고, 서로 다른 결과가 충돌하면 출처와 기준 날짜를 대조한다. 코드 작업이라면 테스트와 변경 파일 목록을 확인한다. 조사 작업이라면 링크가 실제 주장에 대응하는지 확인한다. 판단이 남은 항목은 최종 답변에 불확실성을 표시한다.
실패했을 때 무한히 재시도하지 않도록 재시도 횟수와 종료 조건도 정한다. 예를 들어 출처를 두 차례 확인해도 찾지 못하면 ‘자료 없음’으로 보고하고, 위험한 외부 작업은 담당자가 실패 원인만 기록한 뒤 사람에게 넘긴다. 여러 에이전트가 같은 오류를 반복할수록 비용만 늘 수 있다.
6. 빨라졌는지 숫자로 확인한다
멀티에이전트의 효율은 에이전트 수가 아니라 전체 작업 결과로 비교한다. 같은 종류의 실제 작업을 단일 방식과 다중 방식으로 처리하고 아래 항목을 기록한다. 표의 값은 예시 측정 항목이며 특정 구조의 성능을 보장하는 수치가 아니다.
| 측정 항목 | 확인할 질문 |
|---|---|
| 완료 시간 | 사용자가 검토 가능한 최종 결과를 받기까지 얼마나 걸렸는가? |
| 총 비용 | 작업자, 조정자, 재시도와 검증 호출을 모두 합쳤는가? |
| 정확성 | 출처 오류나 테스트 실패, 누락 항목이 얼마나 남았는가? |
| 재작업 | 결과 충돌과 불명확한 지시 때문에 사람이 얼마나 고쳤는가? |
예를 들어 두 작업자를 동시에 실행해 조사 시간은 줄었더라도, 결과를 합치는 데 오래 걸리고 출처 오류가 늘었다면 경계나 출력 형식을 다시 설계해야 한다. Anthropic의 평가 가이드는 실제 작업 사례로 기준선을 만들고 지연, 토큰 사용량, 비용, 오류를 함께 추적하도록 설명한다.
시작 전 체크리스트
- 단일 에이전트의 결과와 비용을 먼저 측정했는가?
- 동시에 맡길 작업들이 서로의 결과를 기다리지 않는가?
- 각 작업의 입력, 산출물, 담당 범위, 완료 조건이 적혀 있는가?
- 작업자에게 필요한 자료만 전달하면서 근거 위치는 보존했는가?
- 통합 검증, 재시도 한도, 사람의 승인 지점이 정해져 있는가?
- 전체 완료 시간과 총 비용을 단일 방식과 비교할 수 있는가?
결론: 작업 하나를 분리해 시험한다
처음부터 많은 에이전트를 만들기보다, 기존 작업에서 독립적으로 검증할 수 있는 부분 하나를 분리해 보자. 작업 계약을 쓰고, 결과를 합치는 책임자를 정하고, 같은 과제를 단일 방식과 비교한다. 이렇게 얻은 측정값이 다음 에이전트를 추가할 이유가 된다.