필자가 속한 팀에 개발한 멀티 에이전트 AI 시스템은 데모에서는 괜찮았다. 한 에이전트는 고객 문의를 처리하고 다른 에이전트는 일정을 관리하고 세 번째는 문서를 처리했다. 각 에이전트 개별적으로는 아주 잘 작동했다.

그러나 프로덕션에서는 불협화음을 내기 시작했다. 일정 관리 에이전트는 고객 문의 처리 에이전트가 아직 요구사항을 수집하는 중인데도 예약을 잡았고, 문서 에이전트는 이미 두 턴이 지나간 대화의 컨텍스트를 사용해 파일을 처리했다. 확장성을 감안해 설계되지 않은 애드혹 API 호출을 통해 에이전트끼리 서로 기다리는 상황이 발생하면서 종단 간 지연은 약 200밀리초에서 거의 2.4초까지 증가했다.

문제는 에이전트가 아니었다. 모든 개별 에이전트는 각자의 영역에서 잘 작동했다. 문제는 이들 사이에 조정 인프라, 즉 ‘이벤트 중추’가 없었다는 점이다. 이벤트 중추는 여러 에이전트가 동일한 리소스를 두고 경쟁하는 개별 에이전트의 집합이 아니라 하나의 시스템으로 작동하게 해주는 시스템이다.

통신과 헬스케어 전반에서 엔터프라이즈 규모의 프로덕션 AI를 운영하는 필자의 동료들 사이에서도 같은 패턴이 계속 나타나고 있다. 에이전트의 급증은 현실이다. 그런데 이들을 조정하기 위한 툴은 그 속도를 따라가지 못하고 있다.

그림 1 : 멀티 에이전트 조정 – 전(N²개의 연결)과 후(이벤트 중추)

Sreenivasa Reddy Hulebeedu Reddy

에이전트 간 직접 통신은 왜 제대로 되지 않는가

멀티 에이전트 시스템의 직관적인 접근 방식은 직접 통신이다. 즉, 에이전트 A가 에이전트 B의 API를 호출하고 에이전트 B가 응답하는 단순한 점 대 점 통합이다. 대다수 팀이 초기 마이크로서비스를 구축하는 방식과 비슷한 구주로, 에이전트가 2~3개 수준일 때는 잘 작동한다.

그러나 이 방식은 금방 한계에 부딪힌다. 에이전트 수가 늘어날수록 연결 수는 이차함수적으로 증가한다. 5개의 에이전트에는 10개의 연결이 필요하다. 10개에는 45개, 20개에는 190개가 필요하다. 각 연결은 잠재적인 장애 지점이자 지연의 원천이며, 사람이 계속 조정해야 하는 과제다.

게다가 직접 통신은 숨은 종속성을 유발한다. 에이전트 A가 에이전트 B를 호출할 때 A는 B의 상태, 가용성, 현재 워크로드를 알아야 한다. 이 지식은 에이전트 간의 결합도를 높여 결과적으로 전문화된 여러 구성요소로 기능을 분산하고자 하는 원래의 목표에 역행하게 된다. B의 API 계약을 변경한다면 B를 호출하는 모든 에이전트를 업데이트해야 한다.

우리 팀은 이전에도 마이크로서비스에서 이와 똑 같은 경험을 한 적이 있다. 마이크로서비스는 서비스 대 서비스 직접 호출에서 메시지 버스로, 이후 서비스 메시로 진화했다. AI 에이전트도 같은 경로를 따르는 중이다. 다만 그 과정이 몇 년이 아니라 몇 개월로 압축될 뿐이다.

이벤트 중추 패턴

이벤트 중추는 중앙 조정 계층으로, 멀티 에이전트 AI 시스템에 맞게 설계된 3개의 속성이 있다.

첫째, 순서가 있는 이벤트 스트림이다. 모든 에이전트 행동은 전역 시퀀스 번호가 있는 이벤트를 생성한다. 어떤 에이전트든 이 이벤트 스트림을 읽어 현재 시스템 상태를 재구성할 수 있으므로 에이전트가 서로 직접 질의할 필요가 없다. 이 질의가 바로 우리 시스템에서 지연이 발생했던 지점이다.

둘째, 컨텍스트 전파다. 각 이벤트에는 원래의 사용자 요청, 현재 세션 상태, 그리고 모든 제약이나 기한이 포함된 컨텍스트 엔벨로프가 저장된다. 에이전트는 이벤트를 수신하면 부가적인 호출 없이 전체 상황을 파악할 수 있다. 이전 아키텍처에서는 에이전트들이 요청 하나를 처리하기 위해 3~5번 왕복 호출을 수행하면서 컨텍스트를 조합했다. 셋째, 조정 프리미티브다. 이벤트 중추는 일반적인 패턴에 대한 기본 지원을 제공한다. 여기서 일반적인 패턴이란 에이전트 간 순차적 인계, 병렬 분산과 집계, 신뢰도 점수에 기반한 조건부 라우팅, 긴급 요청이 들어올 때의 우선순위 선점 등이다. 기본 지원되지 않을 경우 각 에이전트 쌍마다 독립적으로 이런 패턴을 구현해야 하므로 로직 중복과 비일관성이 발생한다.

from collections import defaultdict import time  class EventSpine:      def __init__(self):          self.sequence = 0          self.subscribers = defaultdict(list)       def publish(self, event_type, payload, context):          self.sequence += 1          event = Event(              seq=self.sequence,              type=event_type,              payload=payload,              context=context,              timestamp=time.time()          )          for handler in self.subscribers[event_type]:              handler(event)          return event      def subscribe(self, event_type, handler):            self.subscribers[event_type].append(handler)

그림 2 : 이벤트 중추 아키텍처 – 순서가 있는 이벤트와 컨텍스트 전파가 포함된 요청 흐름

Sreenivasa Reddy Hulebeedu Reddy

이벤트 중추가 해결하는 3가지 문제

문제 1 : 에이전트 간 경합. 조정 기능이 없는 상태에서 일정 관리 에이전트는 문의 처리 에이전트가 요구사항 수집을 끝내기 전에 회의를 예약했고, 고객은 중요한 세부 정보가 누락된 일정 초대를 받았다. 이벤트 중추는 종속적 작업에 대해 순차 처리를 강제함으로써 이 문제를 해결했다. 일정 관리 에이전트는 요구사항 완료 이벤트를 구독하고, 고객 문의 처리 에이전트가 필요한 정보를 모두 수집했다는 확인을 수신한 이후에만 동작한다.

문제 2 : 컨텍스트의 유효 기간 경과. 두 번째로 일반적인 실패 모드는 에이전트가 오래된 정보를 기반으로 의사결정을 내리는 현상이었다. 고객이 대화 중 전화번호를 수정했음에도 문서 에이전트는 3턴 전에 가져온 컨텍스트를 참고해서 이전 번호로 서류를 생성했다. 이벤트 중추는 모든 이벤트에 현재 컨텍스트 엔벨로프를 연결하는 방법으로 이 문제를 해결했다. 문의 처리 에이전트가 업데이트를 게시하면 연결된 컨텍스트는 최신 상태를 반영하므로 다운스트림 에이전트가 오래된 데이터를 기반으로 동작할 일이 없다.

문제 3 : 연쇄 장애. 직접 호출 체인에서는 에이전트 하나가 실패하면 다운스트림 에이전트는 멈춘 채로 응답을 기다리거나 같이 실패한다. 하나의 문서 처리 시간 만료가 연쇄적으로 일정 관리 실패, 문의 처리 시간 만료로 이어질 수 있다. 이벤트 중추는 데드 레터 큐, 시간 만료 정책, 대체 라우팅을 도입했다. 문서 처리 에이전트에서 지연이 증가하면 단순화된 대체 핸들러로 이벤트가 자동으로 다시 라우팅되고, 대체 핸들러는 파이프라인 전체를 실패시키는 대신 작업을 이후에 처리하도록 큐에 넣는다.

그림 3 : 이벤트 중추가 해결하는 세 가지 문제 – 전후 비교

Sreenivasa Reddy Hulebeedu Reddy

결과

결과적으로 시스템의 성능 체질이 바뀌었다. 종단 간 지연이 약 2.4초에서 약 180밀리초로 줄었다. 개선은 주로 에이전트 간 연쇄적인 왕복 호출을 제거한 데서 비롯됐다. 6개의 에이전트가 컨텍스트를 구축하기 위해 점 대 점 요청을 하는 것이 아니라, 이제 각 에이전트가 이벤트 스트림을 통해 정확히 필요한 정보를 수신한다.

배포 이후 첫 분기에서 에이전트와 관련된 운영 사고가 71% 감소했다. 제거된 사고는 대부분 이벤트 기반 조정에서는 구조적으로 불가능한 경합 상황, 그리고 오래된 컨텍스트 버그였다.

에이전트들이 중복 작업을 수행하지 않게 되면서 에이전트 CPU 사용률은 약 36% 감소했다. 이전 아키텍처에서는 여러 에이전트가 동일한 고객 데이터를 공유 서비스에서 각각 독립적으로 가져왔다. 중추를 통한 컨텍스트 전파가 이뤄지면서 이제 이 데이터를 한 번만 가져오면 이벤트 엔벨로프를 통해 공유된다.

중복 처리는 완전히 제거됐다. 이전 아키텍처에서는 두 에이전트가 동시에 동일한 요청을 처리하고 있는지 여부를 감지할 안정적인 방법이 없었다. 이벤트 중추의 전역 시퀀스 번호는 자연스러운 중복 제거 기능을 제공한다. 정량화하기는 어렵지만 개발자 생산성도 개선됐다. 이제 시스템에 새로운 에이전트를 추가할 때 모든 기존 에이전트와 점 대 점 통합을 할 필요 없이 관련 이벤트를 구독하기만 하면 된다. 최근 추가한 한 에이전트는 프로토타입에서 프로덕션까지 2일이 걸렸다. 이전에는 2주가 걸렸던 일이다.

# Example: Sequential handoff with fallback  class AgentCoordinator:      def __init__(self, spine: EventSpine):          self.spine = spine          spine.subscribe('inquiry.complete', self.on_inquiry_complete)          spine.subscribe('scheduling.complete', self.on_scheduling_complete)          spine.subscribe('agent.timeout', self.on_agent_timeout)       def on_inquiry_complete(self, event):          # Sequential: scheduling only starts after inquiry          self.spine.publish(              'scheduling.request',              payload=event.payload,              context=event.context  # Fresh context propagated            )        def on_agent_timeout(self, event):          # Fallback: route to dead-letter queue          self.spine.publish(              'fallback.process',              payload=event.payload,              context={**event.context, 'fallback_reason': 'timeout'}	}

AI 에이전트를 확장하는 기업에 주는 메시지

멀티 에이전트 AI는 미래의 개념이 아니다. 두 개 이상의 AI 기반 기능을 운영하는 모든 기업에서 이미 현실이다. 챗봇, 추천 엔진, 문서 처리기가 있다면 이를 의도적으로 설계했든 그렇지 않든 이미 멀티 에이전트 시스템을 갖고 있는 것이다.

에이전트 수가 증가함에 따라 조정 문제도 커지게 된다. 필자가 만나는 모든 기업이 조정 인프라를 추가하는 속도보다 더 빠르게 AI 기능을 추가하고 있다. 운영 사고는 바로 그 격차에서 발생한다.

이벤트 중추 패턴은 에이전트의 급증이 혼란으로 이어지지 않도록 하는 아키텍처 기반을 제공한다. 이는 업계가 10년 전 마이크로서비스에서 얻은 교훈과 동일하다. 즉, 분산 시스템에는 팀 간의 선의에 기반한 API 계약뿐만 아니라 명시적인 조정 인프라가 필요하다는 것이다.

복잡성이 통제를 벗어나기 전에 지금 조정 아키텍처에 투자하는 기업은 앞으로 AI 확장을 성공적으로 이루게 된다. 뒤로 미루는 기업은 나중에 큰 압박 속에서, 더 많은 사고를 겪고 더 높은 비용을 치르면서 해야 할 것이다.
dl-itworldkorea@foundryco.com