토픽·구독 브로드캐스팅 시나리오

토픽·구독 브로드캐스팅 시나리오 (Topic and Subscription Example Scenarios)

AutoGen에서 에이전트 간 통신은 토픽(topic)이라는 방송 채널을 통해 이뤄져요. 그런데 "토픽을 어떻게 설계하느냐"에 따라 같은 메시지가 모든 에이전트에게 갈 수도, 일부에게만 갈 수도 있어요. 이 쿡북은 브로드캐스팅이 네 가지 시나리오에서 어떻게 달라지는지 보여줘요. 공통 예시로 세무 관리 회사가 고객 요청을 처리하는 상황을 사용할게요.

출처: Topic and Subscription Example Scenarios — AutoGen 공식 문서

시나리오 개요

세무 관리 회사는 세금 계획(planning), 분쟁 해결(dispute resolution), 컴플라이언스(compliance), 신고 준비(preparation) 등 다양한 서비스를 제공해요. 회사에는 각 분야 전문가인 세무 전문가들(TaxSpecialist)과, 운영을 총괄하는 세무 시스템 매니저가 있어요. 고객의 요청은 적절한 전문가가 처리하는데, 이 과정에서 고객-매니저-전문가 간 통신이 브로드캐스팅으로 이뤄져요.

다룰 브로드캐스팅 시나리오는 네 가지예요.

단일 테넌트, 단일 퍼블리싱 범위 (Single-Tenant, Single Scope of Publishing)
멀티 테넌트, 단일 퍼블리싱 범위 (Multi-Tenant, Single Scope of Publishing)
단일 테넌트, 다중 퍼블리싱 범위 (Single-Tenant, Multiple Scopes of Publishing)
멀티 테넌트, 다중 퍼블리싱 범위 (Multi-Tenant, Multiple Scopes of Publishing)

각 시나리오는 메시지 분배와 에이전트 상호작용에 서로 다른 접근을 취해요. 이를 이해하면 애플리케이션 요구사항에 가장 잘 맞는 통신 전략을 설계할 수 있어요.

1. 단일 테넌트 · 단일 퍼블리싱 범위

모든 에이전트가 단일 테넌트(예: 한 고객·사용자 세션) 안에서 동작해요.
메시지는 단일 토픽에 게시되고, 모든 에이전트가 그 토픽을 구독해요.
모든 에이전트가 토픽에 게시된 모든 메시지를 받아요.

세무 회사에서는 모든 세무 전문가가 모든 고객 요청과 내부 메시지를 받는 상황이에요. 모든 에이전트가 모든 메시지를 알아야 할 때 적합하죠.

구독: 모든 에이전트가 기본 구독(default subscription, 예: "default")을 사용
퍼블리싱: 메시지를 기본 토픽으로 게시
메시지 처리: 각 에이전트가 내용과 핸들러에 따라 처리 여부를 결정

장점은 단순하고 투명하다는 점, 고려사항은 에이전트·메시지가 많아지면 확장이 어렵고 불필요한 메시지를 많이 받을 수 있다는 점이에요.

# 런타임 생성
runtime = SingleThreadedAgentRuntime()
# ... 전문가 에이전트 등록 및 기본 구독 추가 ...
runtime.start()
await runtime.publish_message(ClientRequest("I need to have my tax for 2024 prepared."), topic_id=DefaultTopicId())
await runtime.stop_when_idle()

default 토픽에 게시한 세금 준비 요청 하나가 등록된 모든 전문가(TaxSpecialist_1, TaxSpecialist_2)에게 전달·출력되는 걸 볼 수 있어요.

2. 멀티 테넌트 · 단일 퍼블리싱 범위

여러 테넌트(여러 고객·사용자 세션)가 존재해요.
각 테넌트는 토픽 소스(topic source)를 통해 고유한 격리된 토픽을 가져요.
테넌트 내 모든 에이전트가 그 테넌트의 토픽을 구독하고, 필요하면 테넌트마다 새 에이전트 인스턴스를 만들어요.
메시지는 같은 테넌트 안의 에이전트에게만 보여요.

회사가 여러 고객(테넌트)을 동시에 서빙하는 상황이에요. 고객별로 전용 에이전트 인스턴스 집합을 만들고, 각 고객의 통신은 서로 격리돼요.

장점은 테넌트 격리(데이터 프라이버시·분리)와 테넌트 내 협업이 가능하다는 점, 고려사항은 여러 에이전트·토픽 세트를 관리해야 해 복잡해지고 리소스가 더 든다는 점이에요.

tenants = ["ClientABC", "ClientXYZ"]
# ... 
for tenant in tenants:
    topic_source = tenant  # 토픽 소스는 고객 이름
    topic_id = DefaultTopicId(source=topic_source)
    await runtime.publish_message(ClientRequest(f"{tenant} requires tax services."), topic_id=topic_id)

ClientABC와 ClientXYZ 각각의 고유 토픽으로 요청이 게시되고, 각 테넌트의 전용 전문가들만 자기 요청을 처리하는 걸 볼 수 있어요.

3. 단일 테넌트 · 다중 퍼블리싱 범위

모든 에이전트가 단일 테넌트 안에서 동작해요.
메시지는 서로 다른 토픽들에 게시돼요.
에이전트는 자신의 역할·전문 분야에 해당하는 특정 토픽만 구독해요.
메시지는 토픽에 기반해 일부 에이전트에게만 전달돼요.

세무 회사에서는 세무 시스템 매니저가 전문 분야에 따라 특정 전문가들과 통신해요. 예를 들어 "planning", "compliance" 같은 토픽이 각 전문 분야를 나타내고, 전문가는 자신의 분야 토픽만 구독해요.

장점은 메시지가 관련 에이전트에게만 도달해 처리 효율이 높아진다는 점, 고려사항은 토픽·구독 관리가 필요해 설정이 복잡해지고 시나리오 변경 시 구독을 갱신해야 한다는 점이에요.

4. 멀티 테넌트 · 다중 퍼블리싱 범위

여러 테넌트가 있고, 각 테넌트는 자신만의 에이전트 집합을 가져요.
각 테넌트 내에서 메시지가 여러 토픽에 게시돼요.
에이전트는 자신의 역할에 해당하는 테넌트 특정 토픽을 구독해요.
테넌트 격리와 대상 지정 통신을 결합해요.

예를 들어 Client A의 planning 전문가는 소스가 "ClientA"인 "planning" 토픽을 구독하죠. 각 고객의 세무 매니저는 테넌트 특정 토픽으로 자기 전문가들과 통신해요.

장점은 완전한 격리와 정밀한 메시지 라우팅이라는 점, 고려사항은 토픽·테넌트·구독을 꼼꼼히 관리해야 해 복잡하고 에이전트 인스턴스·토픽 증가로 리소스 영향이 있다는 점이에요.

for tenant in tenants:
    for specialty in TaxSpecialty:
        topic_id = TopicId(type=f"{tenant}_{specialty.value}", source=tenant)
        await runtime.publish_message(ClientRequest(f"{tenant} needs assistance with {specialty.value} taxes."), topic_id=topic_id)

정리

네 시나리오는 결국 누가 메시지를 받아야 하는가를 테넌트(격리 수준)와 토픽(대상 지정 수준) 두 축으로 조절하는 방법이에요. 단순한 전역 브로드캐스트부터, 테넌트+전문 분야까지 촘촘히 라우팅하는 정밀 제어까지, 요구사항에 맞춰 토픽 구조를 선택하면 돼요.

토픽·구독 브로드캐스팅 시나리오