"실전 자동화 업무를 위해 여러 명의 AI 에이전트(분석 담당, 요약 담당, 포맷팅 담당)를 연결해 두었는데, 앞 단계 에이전트의 답변이 0.1초만 늦어져도 뒤쪽 에이전트들이 줄줄이 대기 상태에 빠지며 전체 처리 시간이 10배 이상 폭증했습니다."
AI 에이전트 시스템을 단일 에이전트에서 복수의 에이전트가 협업하는 '멀티 에이전트(Multi-Agent) 파이프라인'으로 확장하다 보면, 누구나 마주하게 되는 거대한 벽이 있습니다. 바로 에이전트 간 순차적 대기 현상으로 인한 '병목 및 속도 지연(Pipeline Bottleneck)' 문제입니다.
A 에이전트가 완벽한 결과를 출력할 때까지 B, C 에이전트가 아무 일도 못 하고 대기하는 동기식(Synchronous) 구조를 그대로 두면, 처리해야 할 데이터가 수십 건으로 늘어나는 순간 전체 시스템이 사실상 멈춰버리기 일쑤지요. 오늘은 제가 직접 겪었던 '멀티 에이전트 병목으로 인한 시스템 마비 잔혹사'와 이를 깔끔하게 해결해 낸 '비동기 이벤트 기반(Event-Driven) 이벤트 큐 & 병렬 오케스트레이션 파이프라인' 구축기를 이야기해 볼게요.
1. "10초면 끝날 작업이 왜 3분이나 걸리지?" - 동기식 순차 처리의 함정
웹에서 최신 데이터를 긁어오는 '수집 에이전트', 내용을 검증하는 '검증 에이전트', 핵심을 요약하는 '요약 에이전트', 그리고 HTML로 가공하는 '포맷팅 에이전트' 총 4개를 직렬 연결한 포스팅 파이프라인을 구축했을 때였습니다. 단 1건의 요청을 처리할 땐 약 15초가 걸려 제법 그럴듯해 보였지요.
하지만 동시에 10건의 작업을 연속 처리하도록 명령을 내리자 대참사가 시작되었습니다. 1번 작업의 요약 에이전트가 결과를 낼 때까지 2번, 3번 작업의 수집 에이전트조차 동작하지 못하고 순서대로 줄을 서며 기다린 것입니다. 결과적으로 전체 작업 시간이 3분을 훌쩍 넘어가며 API 타임아웃(Timeout) 에러가 줄줄이 터져 나왔습니다.
에이전트 하나하나의 성능이 아무리 좋아도, 파이프라인 전체를 직렬(Sequential) 구조로 묶어두는 순간 전체 시스템의 속도는 가장 느린 에이전트의 속도에 갇혀버린다는 사실을 뼈저리게 깨달았습니다.
2. 시행착오: 무작정 `asyncio` 병렬 루프만 돌렸더니...
속도 지연을 해결하기 위해, 처음에는 Python의 `asyncio.gather()`를 활용해 모든 작업을 한꺼번에 병렬로 실행시키는 단순한 방법을 선택했습니다.
하지만 이번엔 'API Rate Limit(초당 요청 제한) 폭주와 429 에러'라는 더 큰 폭탄이 터졌습니다. 10개의 에이전트가 동시에 API를 호출하자마자 제공업체 측의 분당 토큰 제한(TPM)을 초과해 버렸고, 실패한 에이전트들이 엉뚱한 가짜 데이터를 반환하며 시스템 전체 데이터가 꼬여버린 것이지요. 무작정 속도만 올리려다 시스템의 안정성을 송두리째 무너뜨린 순간이었습니다.
💡 몬이쌤의 생각: 학원에서 아이들에게 채점표를 나누어 줄 때, 앞 아이가 채점을 끝낼 때까지 뒤 아이들이 손을 놓고 줄 서서 기다리게 하면 교실이 마비됩니다. 채점이 끝난 시험지만 따로 '제출함(큐)'에 던져두고, 아이들은 즉시 다음 문제집을 풀게 만드는 '독립적 작업 흐름'이 만들어져야 교실이 원활하게 돌아갑니다.
3. 해결책: '비동기 메세지 큐(RabbitMQ/Celery) & 이벤트 기반 오케스트레이션' 3단계 프로토콜
서버 과부하와 병목 현상을 동시에 해결하기 위해, 저는 순차적 직렬 연결을 끊어내고 '3단계 비동기 이벤트 기반(Event-Driven) 파이프라인'으로 완전히 재설계했습니다.
- 1단계 [작업 단위의 메시지 큐(Message Queue) 이관]: 에이전트 간 직접 호출 관계를 완벽히 제거했습니다. A 에이전트가 작업 결과를 마치면, B 에이전트를 직접 부르는 대신 경량 메시지 큐에 결과 이벤트(Event)를 발행(Publish)하고 즉시 다음 일을 하러 떠납니다.
- 2단계 [분산 워커(Worker) 노드 디스패치]: 메시지 큐에 이벤트가 수신되면, 준비된 독립적 B 에이전트 워커가 이를 구독(Subscribe)하여 자율적으로 처리합니다. 이때 동시 실행 워커 수를 3~5개로 제한하여 API Rate Limit을 완벽히 준수합니다.
- 3단계 [비동기 결과 합산 & 멱등성(Idempotency) 보장]: 모든 에이전트의 작업 결과는 고유 작업 ID(Task ID)를 태깅하여 분산 저장소에 비동기로 누적되며, 중복 실행이나 순서 꼬임이 발생하더라도 동일한 최종 결과물만 나오도록 멱등성을 보장했습니다.
4. 결과: 전체 작업 처리 속도 80% 단축 & API 에러 0건!
비동기 이벤트 기반 오케스트레이션 파이프라인을 도입한 결과, 10건의 대용량 작업을 한꺼번에 처리할 때 소요되던 시간이 3분에서 단 35초로 무려 80% 이상 대폭 단축되었습니다!
에이전트들이 더 이상 서로의 작업이 끝나기를 줄 서서 기다리지 않게 되었을 뿐만 아니라, 동시 실행 워커 제한을 통해 API Rate Limit 폭주나 서버다운 걱정 없이 비단결처럼 부드러운 자동화 시스템을 완성할 수 있었지요.
여러 명의 AI 에이전트를 효율적으로 다룬다는 것은 단순히 커다란 모델을 여럿 연결하는 것이 아닙니다. '에이전트 간의 강한 결합을 끊어내고, 메시지 큐를 통해 각자가 가장 잘하는 일에만 독립적으로 몰입할 수 있도록 판을 짜주는 시스템 구조 설계'가 핵심입니다.
여러분의 멀티 에이전트 시스템도 작업량이 늘어날수록 답답하게 느려지거나 타임아웃 에러가 발생한다면, 직렬 연결 프롬프트를 고집하지 말고 비동기 이벤트 큐를 도입해 보세요. 놀라울 정도로 눈부신 처리 속도와 안정성을 경험하시게 될 겁니다.