아키텍처 비교: 단일 vs A2A

모듈 1에서 단일 에이전트를 경험한 후, 모듈 4의 A2A 멀티에이전트 시스템을 사용해보면 응답 속도가 눈에 띄게 느려진 것을 체감할 수 있습니다. 이 페이지에서는 두 아키텍처의 요청 흐름을 비교하고, 성능 차이의 원인을 코드 수준에서 분석합니다.

핵심 메시지: A2A 멀티에이전트는 독립성과 확장성을 위해 지연시간을 trade-off한 아키텍처입니다. 느려진 것이 아니라, 얻는 것이 다릅니다.

요청 흐름 비교

Module 1: 단일 에이전트 (3홉)

사용자 요청이 하나의 에이전트를 통해 직접 처리됩니다.

Module 4: A2A 멀티에이전트 (8-10홉)

사용자 요청이 HostAgent를 거쳐, A2A 프로토콜을 통해 전문 에이전트로 전달됩니다.

성능 병목 분석

1. LLM 호출 2배 이상 (가장 큰 원인)

	Module 1	Module 4
LLM 호출 횟수	1-2회 (추론 + 결과 해석)	3-4회 이상 (HostAgent 라우팅 + Child Agent 추론 + 결과 해석 x2)
소요 시간	5-15초/회	5-15초/회 x 2배

Module 1에서는 하나의 LLM이 "어떤 도구를 쓸지 판단"과 "도구 결과 해석"을 모두 수행합니다. Module 4에서는 HostAgent의 LLM이 "어떤 에이전트에 보낼지"를 판단하고, Child Agent의 LLM이 "어떤 도구를 쓸지"를 다시 판단합니다. LLM 호출이 가장 비용이 크기 때문에, 이것이 지연의 주요 원인입니다.

2. 스트리밍 손실

A2A Server(agent_executer.py:149)에서 httpx.post()로 AgentCore Runtime을 호출할 때, 동기식 단일 요청으로 전체 응답이 완료될 때까지 대기합니다:

# agent_executer.py:149 — 동기식 HTTP POST (스트리밍 없음)
resp = self.http.post(agent_url, json=payload, headers=headers)

Module 1에서는 agent.stream_async()로 토큰 단위 스트리밍이 가능하지만, Module 4에서는 Child Agent의 전체 응답이 완성된 후에야 HostAgent로 전달됩니다. 사용자 입장에서는 중간 진행 상황 없이 오래 기다리는 것처럼 느껴집니다.

3. 추가 네트워크 홉

Module 1의 AgentCore → MCP → Lambda 경로에 비해, Module 4는 3개의 네트워크 홉이 추가됩니다:

추가 홉	설명	예상 지연
HostAgent → ALB	Application Load Balancer 라우팅	1-5ms
ALB → ECS (A2A Server)	컨테이너 라우팅	1-5ms
ECS → AgentCore API	Child Runtime HTTP 호출	50-200ms

개별 홉의 지연은 크지 않지만, TLS 핸드셰이크, 커넥션 풀링, DNS 해석 등의 오버헤드가 누적됩니다.

4. OAuth 토큰 오버헤드

A2A Server가 Child Runtime을 호출할 때마다 Cognito client_credentials 토큰이 필요합니다(agent_executer.py:103-140). 토큰 캐시(30초 전 갱신)를 사용하지만, 첫 요청이나 캐시 만료 시 Cognito 토큰 엔드포인트 호출이 추가됩니다:

# agent_executer.py:27-41 — OAuth 토큰 캐시 (30초 전 갱신)
class _OAuthTokenCache:
    def valid(self, now_ts: float) -> bool:
        return self.token is not None and now_ts < (self.expire_epoch - 30)

5. Cold Start x3

	Module 1	Module 4
microVM 초기화	1회 (TroubleshootingAgent)	3회 (HostAgent + Connectivity + Performance)
Cold Start 시간	10-30초	10-30초 x 3 (병렬 가능하나 최악의 경우 직렬)

각 에이전트가 독립된 AgentCore Runtime(microVM)에서 실행되므로, 최초 호출 시 3개의 Runtime이 모두 초기화되어야 합니다. HostAgent가 먼저 시작되고, send_message_tool을 통해 Child Agent를 호출할 때 해당 Runtime의 Cold Start가 발생할 수 있습니다.

6. Bedrock 동시접속 제한

HostAgent 내부에서 Bedrock API 동시 호출을 2개로 제한하는 보호장치가 있습니다(agent.py:126):

# agent.py:126 — Bedrock API 동시 호출 제한
self._bedrock_semaphore = Semaphore(2)
self._min_delay_between_calls = 1.0  # 최소 1초 간격

참고: 이 Semaphore는 HostAgent 자체의 Bedrock 호출만 제한합니다.

• 단일 사용자 요청 처리 시에는 큰 영향이 없습니다

• 동시 사용자가 다수일 때 대기(queueing)가 발생합니다

• Child Agent(Connectivity/Performance)에는 적용되지 않습니다 — 각각 독립 Runtime에서 실행됩니다

정량적 지연 비교

아래 수치는 us-east-1 리전 기준 예상치입니다. 실제 값은 환경에 따라 다를 수 있습니다.

단계	Module 1	Module 4	차이
Cold Start	10-30초 (1회)	10-30초 (최대 3회)	+20-60초 (최악)
LLM 추론 (라우팅)	-	5-15초	+5-15초
LLM 추론 (실행)	5-15초	5-15초	동일
LLM 추론 (결과 해석)	3-8초	3-8초 x 2	+3-8초
도구 호출 (Lambda)	1-5초	1-5초	동일
네트워크 홉	~50ms	~300ms	+250ms
OAuth 토큰	-	0-500ms	+0-500ms
총 응답시간 (Warm)	~15-30초	~30-60초	약 2배
총 응답시간 (Cold)	~30-60초	~60-120초	약 2배

장단점 비교

A2A 멀티에이전트의 장점

장점	설명
독립 배포	각 에이전트를 독립적으로 업데이트 가능. Connectivity Agent만 패치해도 전체 시스템 영향 없음
팀 독립성	네트워크팀은 Connectivity Agent, 성능팀은 Performance Agent를 각각 개발/운영
언어/프레임워크 비종속	Child Agent를 Python이 아닌 다른 언어로 구현 가능 (A2A는 HTTP/JSON 프로토콜)
보안 격리	각 에이전트가 독립 microVM에서 실행되어 보안 경계 분리
동적 디스커버리	Agent Card(/.well-known/agent-card.json)를 통해 런타임에 에이전트 기능 발견
장애 격리	Performance Agent가 장애 시에도 Connectivity Agent는 정상 동작

A2A 멀티에이전트의 단점

단점	설명
지연시간 증가	LLM 호출 2배 이상 + 네트워크 홉 추가로 응답 시간 약 2배
운영 복잡도	3개의 독립 Runtime + 2개의 ECS 서비스 + ALB 모니터링 필요
비용 증가	LLM 호출 비용 2배 + ECS/ALB 인프라 비용 추가
디버깅 난이도	요청이 여러 서비스를 경유하여 문제 추적이 어려움 (분산 트레이싱 필요)
스트리밍 미지원	A2A Server의 동기식 호출로 중간 진행 상황 전달 불가
Cold Start 누적	최대 3개의 microVM이 순차적으로 초기화될 수 있음

언제 어떤 아키텍처를 선택할 것인가?

단일 에이전트 (Module 1 패턴)

• 도구가 10개 이하로 관리 가능한 경우

• 하나의 팀이 전체 에이전트를 소유하는 경우

• 빠른 응답 시간이 최우선인 경우 (실시간 채팅, 인터랙티브 진단)

• 도메인이 하나로 명확한 경우

A2A 멀티에이전트 (Module 4 패턴)

• 도메인이 다양하고 도구 수가 많아 하나의 컨텍스트에 담기 어려운 경우

• 여러 팀이 독립적으로 에이전트를 개발/배포해야 하는 경우

• 에이전트별 독립 스케일링이 필요한 경우 (성능 에이전트만 스케일업)

• 장애 격리가 중요한 프로덕션 환경

• 에이전트를 점진적으로 추가/제거해야 하는 경우

핵심 요약

A2A 멀티에이전트가 느린 것은 설계 결함이 아니라 의도된 trade-off입니다. 마이크로서비스가 모놀리스보다 네트워크 호출이 많아 느려지는 것과 같은 원리입니다. 단일 에이전트는 속도, A2A는 확장성과 독립성에 최적화된 아키텍처입니다. 실제 프로덕션에서는 요구사항에 따라 적절한 아키텍처를 선택하세요.