단일 에이전트는 빠르다. 하지만 운영은 속도보다 안정성이 중요하다. 진짜 성과는 ‘잘하는 한 명’이 아니라 ‘역할이 분리된 팀’에서 나온다.
1. 왜 단일 에이전트는 금방 한계에 닿는가
초기 자동화는 대부분 한 명의 똑똑한 에이전트로 시작한다. 요청을 이해하고, 자료를 찾고, 실행하고, 검수까지 한 번에 처리한다. 데모 단계에서는 이 방식이 가장 인상적이다. 문제는 업무가 늘어나는 순간 시작된다. 같은 에이전트가 기획과 실행, 검증을 모두 맡으면 문맥이 섞이고, 우선순위가 흔들리고, 실패 원인을 추적하기 어려워진다.
특히 반복 운영에서 치명적인 건 ‘실패의 형태가 매번 다르다’는 점이다. 오늘은 API 키 누락, 내일은 셀렉터 변경, 모레는 모델 응답 형식 변경으로 깨진다. 단일 에이전트 구조에서는 이 모든 실패가 하나의 블랙박스처럼 보인다. 고치는 데 시간이 걸리고, 재발을 막기도 어렵다. 결국 자동화의 목표였던 시간 절감이 오히려 장애 대응 시간으로 상쇄된다.
2. Planner-Worker-Reviewer: 역할 분리가 성능을 만든다
멀티 에이전트 운영의 핵심은 복잡한 기술이 아니다. 역할을 분명히 나누는 일이다.
- Planner: 요청을 작업 단위로 쪼개고 우선순위를 정한다.
- Worker: 실제 실행을 담당한다. 파일 수정, API 호출, 데이터 변환 같은 작업을 수행한다.
- Reviewer: 결과를 검수한다. 포맷, 정책, 품질 기준, 실패 패턴을 확인한다.
이 구조의 장점은 간단하다. 문제의 위치가 빨리 보인다. 계획이 틀렸는지, 실행이 누락됐는지, 검수가 약했는지를 단계별로 확인할 수 있다. 한 단계가 실패해도 전체를 다시 돌리지 않고 해당 단계만 재시도할 수 있어 운영 비용이 줄어든다.
중요한 건 각 역할의 입출력 계약을 고정하는 것이다. 예를 들어 Planner는 항상 JSON 체크리스트를 내보내고, Worker는 단계별 로그와 산출물 경로를 남기고, Reviewer는 pass/fail과 수정 포인트를 남기게 한다. 계약이 고정되면 모델이 바뀌어도 파이프라인이 무너지지 않는다.
3. 실전 운영의 승부처: 실패 복구 루프와 승인 게이트
멀티 에이전트의 성패는 ‘정상 흐름’이 아니라 ‘비정상 흐름’을 어떻게 다루느냐에서 갈린다. 실전에선 반드시 실패가 발생한다. 그래서 자동화에는 실패를 전제로 한 복구 루프가 필요하다.
권장 루프는 이렇다. Reviewer가 fail을 반환하면 Worker는 재시도하되, 동일 오류가 2회 반복되면 Planner에 상향한다. Planner는 작업을 더 작은 단위로 쪼개 재계획하고, 위험도가 높은 작업(배포, 삭제, 외부 전송)은 승인 게이트로 보낸다. 이때 인간 운영자가 승인하거나 수정 지시를 내리면 다시 Worker로 내려보낸다.
여기에 두 가지 운영 원칙을 더하면 안정성이 크게 올라간다.
첫째, 권한 최소화. Worker는 필요한 도구만 접근하게 하고, 위험 명령은 기본 차단한다. 둘째, 관측 가능성. 각 단계 로그를 남기고, 실패 유형을 태깅해 재발 패턴을 본다. 자동화는 ‘한 번 잘 도는 것’보다 ‘망가졌을 때 빨리 복구되는 것’이 훨씬 중요하다.
결국 멀티 에이전트 오케스트레이션은 화려한 기술 쇼가 아니다. 운영 가능한 시스템 설계다. 단일 에이전트가 빠른 프로토타입에 강하다면, 역할 분리된 에이전트 팀은 장기 운영에 강하다. 오늘의 목표가 단순한 데모가 아니라 매일 반복되는 성과라면, 이제 질문은 분명해진다. “어떤 모델을 쓸까?”가 아니라 “어떤 역할 구조로 실패를 관리할까?”
자동화의 다음 단계는 더 똑똑한 에이전트 한 명이 아니다. 서로 다른 책임을 가진 에이전트들이 같은 목표를 향해 협업하는 팀이다. 그리고 그 팀을 설계하는 순간, 우리는 도구를 쓰는 사람이 아니라 시스템을 운영하는 사람이 된다.
