에이전트 오케스트레이션은 여러 AI 에이전트가 하나의 목표를 중심으로 역할을 나누어 협력하도록 조직하는 방식이다. 핵심 질문은 단 세 가지다. 다음 단계를 누가 결정하는가, 각 일을 누가 맡는가, 그리고 각자의 결과를 마지막에 어떻게 모아 쓸 만한 하나의 답으로 만드는가. 이것이 해결하는 것은 단일 에이전트를 더 강하게 만드는 것이 아니라, 여러 에이전트가 함께 일할 때 충돌하지 않도록 하는 것이다.
워크플로, 단일 에이전트와 무엇이 다른가
워크플로는 시작 전에 단계를 고정해 둔 체크리스트다. 어느 단계를 먼저 할지, 각 단계에서 어떤 도구를 호출할지, 어떤 순서로 진행할지 모두 미리 정해져 있다. 절차가 고정되고 결과를 예측할 수 있는 일에 맞는다. 오케스트레이션은 다르다. 경로는 달리면서 정해진다. 총괄자가 중간 결과를 보고 어떤 길이 막혔다는 것을 알면, 그 자리에서 사람을 바꾸고 순서를 바꾸며, 심지어 목표 자체를 바꿀 수도 있고, 예상치 못한 갈림길이 나타나도 처음부터 다시 시작할 필요가 없다. 단일 에이전트는 또 다른 선택이다. 하나의 모델이 처음부터 끝까지 전부 맡고, 맥락을 온전히 자기 손에 쥐고 있다. 단순하고 직접적이지만, 과제가 복잡해지면 손이 모자라기 쉽다. 맥락이 넘치거나, 어느 한 단계에서 맴돌게 된다. 오케스트레이션은 일을 쪼개어 복잡한 과제에 조율할 줄 아는 팀을 붙여 주는 것이지, 한 사람이 만능이기를 기대하는 것이 아니다.
세 가지 조직 방식, 저마다의 성격
주관자 방식이 가장 흔하다. 하나의 총괄 에이전트가 과제를 나누고 일을 배정하며 결과를 검증하고, 나머지 에이전트는 실행만 맡는다. 책임 소재가 명확하고 문제가 생겨도 원인을 찾기 쉽지만, 총괄자의 판단이 틀리면 팀 전체가 함께 빗나간다. 파이프라인 방식은 정해진 순서대로 바통을 넘긴다. 수집 담당이 자료를 검증 담당에게 넘기고, 검증이 끝나면 집필 담당에게 넘긴다. 흐름이 투명하고 비용 계산도 쉽지만, 어느 한 고리가 막히면 뒤가 전부 멈춘다. 탈중앙 협상 방식에는 보스가 없다. 여러 에이전트가 서로 메시지를 주고받으며 스스로 과제를 맡고 스스로 협상한다. 유연하고 장애에 강하며, 경계가 모호하고 반복적인 논의가 필요한 탐색형 과제에 맞지만, 오가는 대화가 토큰을 많이 먹고 수렴이 느리다는 대가가 있다.
오케스트레이션이 실제로 풀어야 할 난제
오케스트레이션을 실제로 동작하게 하려면 다섯 가지 관문을 넘어야 한다. 과제를 어떻게 합리적으로 나눌 것인가, 중간 상태를 어디에 두고 누가 유지할 것인가, 의견이 갈릴 때 누가 결정할 것인가, 어느 단계가 실패하면 어떻게 다시 시도할 것인가, 그리고 한 번의 호출에 비용이 얼마나 드는가이다. 경쟁사 보고서를 예로 들어 보자. 총괄자는 과제를 수집, 검증, 집필 세 갈래로 나누어 병렬로 진행한다. 수집한 데이터는 건마다 출처를 밝혀야 하고, 검증자는 건마다 사실 여부를 확인하며, 집필자는 마지막에 원고를 하나로 묶는다. 서로 모순되는 주장이 나오면 되돌려 다시 확인한다. 분업, 공유, 충돌, 재시도, 비용, 다섯 가지가 한 번에 전부 등장한다. 중간 상태를 유지하는 것이 바로 에이전트 메모리의 역할이다. 상태를 잃으면 협업 전체가 무너진다. 하지만 오케스트레이션은 만병통치약이 아니다. 과제 자체가 한두 단계뿐이고 한 사람이 몇 분이면 끝낼 수 있는 일에 억지로 도입하면, 조율 지연과 토큰 비용만 늘고 답이 더 좋아진다는 보장도 없다. 판단 기준은 단순하다. 과제가 하나의 에이전트가 감당하기 어려울 만큼 복잡하고, 단계도 미리 정해 둘 수 없을 때 비로소 오케스트레이션을 고려하면 된다.
