실무의 업무는 “질문 한 번, 답변 한 번”으로 끝나지 않습니다. 자료를 찾고, 비교하고, 계산하고, 양식에 맞춰 정리하는 여러 단계로 이뤄집니다. 단일 프롬프트로는 이런 흐름을 안정적으로 처리하기 어렵습니다. 그래서 우리는 역할이 나뉜 여러 에이전트를 오케스트레이션합니다.
왜 단일 프롬프트로는 부족한가
- check_circle단계가 많아질수록 하나의 프롬프트는 길어지고, 지시가 서로 충돌해 정확도가 떨어집니다.
- check_circle중간 단계의 오류를 잡아내거나 재시도하기 어렵습니다.
- check_circle어느 단계에서 무엇이 잘못됐는지 추적·디버깅이 거의 불가능합니다.
오케스트레이션 핵심 패턴
1) Planner – Worker – Critic
Planner가 작업을 단계로 쪼개고, 각 Worker가 검색·계산·작성 같은 단일 책임을 수행하며, Critic이 결과를 검증하고 미흡하면 되돌립니다. 역할을 나누면 각 프롬프트가 짧고 명확해져 정확도가 올라갑니다.
2) 도구 사용(Tool Use)
LLM이 직접 계산하거나 최신 데이터를 “기억”하게 두지 마세요. 사내 API·DB 조회·계산기를 도구로 노출하고 에이전트가 호출하게 하면 환각이 줄고 결과가 결정론적으로 안정됩니다.
3) 휴먼 인 더 루프(Human-in-the-loop)
환불 승인, 외부 발송처럼 되돌릴 수 없는 행동 앞에는 사람 확인 단계를 둡니다. 자동화의 속도와 통제권을 동시에 가져가는 가장 현실적인 타협점입니다.
설계 원칙
에이전트를 무한정 늘리지 마세요. 단계가 명확히 분리되고, 각 단계가 검증 가능하며, 실패 시 어디서 멈출지 정의돼 있어야 합니다. “똑똑한 하나”보다 “검증 가능한 여럿”이 운영에 강합니다.
관측 가능성(Observability)
멀티 에이전트는 강력하지만 블랙박스가 되기 쉽습니다. 각 단계의 입력·출력·도구 호출·토큰 비용을 추적(trace)으로 남겨야 운영이 가능합니다. “왜 이 답이 나왔는지”를 단계별로 설명할 수 없다면 프로덕션에 올릴 수 없습니다.
요약
역할 분리 · 도구 사용 · 사람 확인 · 추적 가능성. 이 네 축이 멀티 에이전트 자동화를 데모에서 운영으로 넘기는 다리입니다.