여러 에이전트가 조사, 문서 작성, 코드 수정, 검증을 나눠 처리하도록 설계할 때 가장 먼저 나오는 질문은 “몇 개를 붙이면 빨라질까”입니다. 그러나 CTO와 개발 리드가 먼저 답해야 할 질문은 다릅니다. 이 업무가 서로 독립적으로 나눌 수 있는가, 그리고 각 작업자가 중간에 멈춰도 다음 작업자가 같은 상태에서 이어받을 수 있는가입니다.
멀티 에이전트는 자동화 기능을 몇 개 더 추가하는 일이 아닙니다. 상태를 저장하고, 작업을 배정하고, 권한을 제한하고, 실패한 실행을 복구하며, 비용이 통제 범위를 넘지 않게 하는 분산 시스템 설계에 가깝습니다. 이 장치 없이 에이전트 수부터 늘리면 처리량보다 충돌, 중복 호출, 잘못된 결과의 확산, 원인 추적 불가 문제가 먼저 커질 수 있습니다.
먼저 가를 일: 병렬 업무인가, 하나의 판단 흐름인가
단일 에이전트와 멀티 에이전트의 선택은 모델 성능보다 업무의 의존 관계에 좌우됩니다.
여러 문서를 각각 분류하거나, 지역별 데이터를 따로 수집하거나, 서로 독립된 테스트 케이스를 실행하는 일은 병렬화 후보입니다. 각 작업의 입력과 완료 조건을 분리할 수 있고, 한 작업의 오류가 다른 작업의 결론을 바꾸지 않는다면 여러 실행자를 배정할 여지가 있습니다.
반대로 정책 해석, 계약 검토, 장애 원인 분석, 복잡한 설계 결정처럼 앞선 판단이 다음 판단의 전제가 되는 업무는 분업이 오히려 해로울 수 있습니다. 작업자들이 부분 결론을 자주 주고받는 동안 문맥이 쪼개지고, 누가 최종 판단을 수정할 권한을 갖는지도 흐려집니다.
Google Research와 MIT가 여러 에이전트 구성과 작업 유형을 비교한 연구에서는, 순차적 계획이 중요한 작업에서 멀티 에이전트 구성이 성과를 낮춘 경우가 있었고, 독립적으로 나눌 수 있는 금융 추론 작업에서는 중앙 조정 방식이 개선을 보였습니다. 여기서 얻을 수 있는 실무적 결론은 “에이전트가 많을수록 좋다”가 아닙니다. 업무 그래프가 병렬인지, 순차인지부터 명세해야 한다는 점입니다.
요구사항 단계에서 업무를 다음 세 부류로 나누면 논의가 빨라집니다.
| 업무 유형 | 권장 시작 구조 | 확인할 조건 |
|---|---|---|
| 단일 판단형 | 단일 에이전트와 사람 승인 | 하나의 문맥 안에서 판단해야 하는가 |
| 독립 처리형 | 작업 큐 기반 병렬 실행 | 입력, 완료 조건, 결과가 서로 분리되는가 |
| 집계·조정형 | 중앙 오케스트레이터와 전문 작업자 | 부분 결과의 충돌을 누가 해결하는가 |
여기서 오케스트레이터는 다른 에이전트보다 더 똑똑한 역할이 아닙니다. 작업을 쪼개고, 실행 순서를 정하고, 결과를 검증 단계로 넘기며, 실패한 작업을 다시 처리할지 중단할지 결정하는 제어 계층입니다.
요구사항 문서에는 프롬프트보다 실행 계약을 먼저 적는다
멀티 에이전트 프로젝트가 흔들리는 이유 중 하나는 역할 설명만 있고 실행 계약이 없기 때문입니다. “조사 에이전트”, “검토 에이전트”, “배포 에이전트”라는 이름만으로는 운영할 수 없습니다. 각 역할마다 아래 항목을 요구사항으로 고정해야 합니다.
- 입력: 어떤 데이터, 문서 버전, 사용자 요청을 받는가
- 출력: 자유 텍스트인지, 구조화된 필드인지, 다음 단계가 사용할 식별자가 무엇인지
- 완료 조건: 어떤 결과가 나오면 성공으로 처리하는가
- 실패 조건: 근거 부족, 도구 오류, 시간 초과, 권한 거부를 어떻게 구분하는가
- 재시도 규칙: 같은 입력을 다시 실행해도 되는가, 사람에게 넘겨야 하는가
- 권한 범위: 읽기, 초안 생성, 외부 시스템 변경, 결제·배포 실행 중 어디까지 허용하는가
- 비용 한도: 작업 하나가 사용할 수 있는 호출 횟수, 토큰, 실행 시간, 외부 도구 비용의 상한은 얼마인가
특히 출력은 가능한 한 구조화해야 합니다. 예를 들어 “검토 결과를 작성한다”보다 판정, 근거 문서 ID, 확신 부족 사유, 사람 검토 필요 여부처럼 다음 단계가 검사할 수 있는 필드를 정하는 편이 낫습니다. 자연어 보고서는 사람이 읽기 좋지만, 시스템이 재시도·집계·감사를 처리하기에는 모호합니다.
상태를 에이전트의 대화창 밖으로 꺼낸다
장시간 실행되는 에이전트에서 가장 위험한 상태는 계획, 진행 상황, 승인 정보가 대화 문맥에만 남는 경우입니다. 실행 프로세스가 중단되거나 컨텍스트 한도에 닿으면, 새 에이전트는 이전 작업이 어디까지 진행됐는지 알 수 없습니다. 같은 외부 요청을 다시 보내거나, 이미 처리한 데이터를 다시 바꾸는 문제가 생길 수 있습니다.
따라서 에이전트가 기억해야 할 정보를 다음처럼 분리해 저장하는 편이 안전합니다.
- 업무 상태: 작업 ID, 현재 단계, 입력 버전, 담당 실행자, 시도 횟수
- 업무 산출물: 수집 결과, 생성한 파일, 도구 호출 결과, 검증 기록
- 결정 기록: 왜 다음 단계로 넘어갔는지, 어떤 규칙과 승인에 따라 실행했는지
- 권한 상태: 발급된 권한의 범위, 만료 시각, 승인 취소 여부
이 구조에서는 에이전트가 죽어도 작업 자체가 사라지지 않습니다. 새 실행자는 저장된 상태를 읽고 재개할 수 있습니다. 다만 “이전 작업을 이어서 한다”는 요청만으로는 충분하지 않습니다. 재개 시에는 입력 버전이 바뀌었는지, 외부 도구 호출이 이미 성공했는지, 사람이 중간에 취소했는지를 먼저 확인해야 합니다.
실패 복구와 권한 분리를 MVP에 포함한다
초기 PoC에서는 한 에이전트가 파일을 읽고, 외부 API를 호출하고, 결과를 배포하는 흐름이 빠르게 만들어집니다. 운영 단계에서 이 구조를 그대로 유지하면 오류 한 번이 넓은 범위의 변경으로 이어질 수 있습니다.
권한은 역할별로 나누는 편이 좋습니다. 조사 역할에는 읽기 권한만 주고, 초안 작성 역할은 격리된 저장소에만 쓰게 하며, 고객 데이터 변경이나 배포처럼 되돌리기 어려운 작업은 별도 승인 단계를 통과하게 합니다. “최종 검토 에이전트가 있으니 괜찮다”는 설계는 충분하지 않습니다. 검토자도 잘못된 입력이나 누락된 상태를 바탕으로 판단할 수 있기 때문입니다.
운영 초기에는 다음 신호를 장애 지표로 삼을 수 있습니다.
- 같은 업무 ID에서 동일한 외부 호출이 반복된다.
- 완료된 작업이 다시 대기열로 돌아온다.
- 서로 다른 에이전트가 같은 레코드나 파일을 동시에 수정한다.
- 상위 작업은 성공으로 끝났지만 하위 작업의 실패가 남아 있다.
- 비용 또는 호출량이 업무량 증가보다 빠르게 늘어난다.
- 사람 승인이 필요한 작업이 자동 완료로 기록된다.
이 신호는 모델 품질 문제라기보다 작업 상태, 멱등성, 권한 경계가 빠졌다는 경고일 수 있습니다. 멱등성이란 같은 요청을 여러 번 받아도 결과가 한 번 실행한 것과 같게 만드는 성질입니다. 외부 시스템을 변경하는 에이전트에는 특히 중요합니다.
구현은 단일 흐름 검증에서 시작해 조정 계층을 추가한다
요구사항이 정리됐다면 처음부터 역할 수를 늘리지 말고 다음 순서로 구축하는 편이 낫습니다.
1단계, 단일 에이전트 기준선을 만든다.
한 업무를 입력, 처리, 결과 검증, 사람 승인까지 연결합니다. 이 단계의 산출물은 작업 상태 모델, 입력·출력 스키마, 실패 코드, 비용 측정 방식입니다. 멀티 에이전트로 얻는 이점은 이 기준선과 비교해야 판단할 수 있습니다.
2단계, 독립 작업 하나만 분리한다.
예를 들어 조사와 요약, 테스트 실행과 결과 정리처럼 경계가 분명한 작업을 큐로 분리합니다. 산출물은 작업 계약서, 재시도 정책, 중복 실행 방지 키, 작업별 권한 목록입니다.
3단계, 중앙 조정 규칙을 코드와 정책으로 고정한다.
오케스트레이터가 어떤 조건에서 작업을 생성하고, 어느 실패에서 중단하며, 충돌한 결과를 누구에게 보내는지 정합니다. 이 규칙을 에이전트의 임의 판단에만 맡기지 않는 편이 좋습니다. 산출물은 상태 전이도, 승인 경로, 예외 처리 표입니다.
4단계, 실패 주입 검증을 한다.
모델 응답 지연, 도구 호출 실패, 중복 메시지, 권한 만료, 작업자 중단을 의도적으로 발생시킵니다. 이때 확인할 것은 답변의 품질만이 아닙니다. 작업이 중복 실행되지 않는지, 중단된 작업을 재개할 수 있는지, 사람에게 넘겨야 할 건이 누락되지 않는지를 봐야 합니다.
5단계, 운영 대시보드와 변경 통제를 붙인다.
업무별 진행 상태, 실패 사유, 재시도 횟수, 도구 호출, 승인 이력, 비용을 같은 작업 ID로 추적합니다. 역할 프롬프트나 도구 권한을 바꿀 때도 버전을 남겨야 특정 기간의 오류를 재현하고 비교할 수 있습니다.
멀티 에이전트 확장은 기능 로드맵보다 운영 설계 로드맵으로 다뤄야 합니다. 다음 요구사항 회의에서는 “에이전트를 몇 명 둘 것인가”보다, 가장 먼저 병렬화할 업무 하나를 고르고 그 업무의 상태 전이, 중단 기준, 승인자를 한 장의 표로 합의해 보십시오. 그 표가 없으면 역할을 늘려도 시스템은 늘어난 만큼 더 복잡해질 가능성이 큽니다.
