들어가며: 왜 지금 멀티 에이전트 아키텍처인가?
스포티파이가 광고 플랫폼을 멀티 에이전트 아키텍처로 재구축했다는 소식은 단순한 기술 업그레이드 이상의 의미를 갖습니다. 이는 AI 에이전트 시대에 맞춰 인프라 자체를 재설계한 사례이기 때문입니다.
Cloudflare의 Browser Run 팀은 기존 Browser Isolation(BISO)과의 인프라 공유에서 발생하던 여러 문제를 해결하기 위해 Durable Object(DO) 기반 Containers로의 전면 마이그레이션을 단행했습니다. 이 글에서는 그 결정의 배경, 구체적인 아키텍처 변화, 그리고 실무에서 얻을 수 있는 교훈을 살펴보겠습니다.
본 사례의 원문은 Cloudflare 블로그에서 확인할 수 있습니다.
아키텍처 변화의 핵심: Containers 도입과 리전별 풀 전략
1. 기존 아키텍처의 한계
BISO와의 공유 인프라는 다음과 같은 문제를 안고 있었습니다.
- 느린 컨테이너 이미지: BISO의 큰 이미지 크기로 인해 시작 시간이 길어짐
- 글로벌 분산 부족: 최적의 리전에 브라우저가 배치되지 않아 레이턴시 증가
- 사용 패턴 충돌: BISO의 긴 세션과 Browser Run의 짧고 폭발적인 사용 패턴이 맞지 않아 스케일링 병목 발생
2. Containers로의 점진적 마이그레이션
Cloudflare 팀은 Worker를 요청 경로에 삽입하여 일부 사용자에게만 Container 기반 브라우저를 제공하는 방식으로 점진적 전환을 시작했습니다. 이는 A/B 테스트 성격의 안전한 접근법이었습니다.
3. 리전별 프리워밍 풀 (Pre-warmed Pools)
DO와 Container 간의 지리적 거리 문제를 해결하기 위해 리전별로 미리 워밍된 브라우저 풀을 구성했습니다.
# 의사 코드: 리전별 풀에서 가장 가까운 브라우저 할당
def assign_browser(user_region):
# 리전별 DO-Container 쌍 중 최저 레이턴시 선택
best_pair = min(
region_pools[user_region],
key=lambda pair: latency(user_region, pair.do) + latency(pair.do, pair.container)
)
return best_pair.container
이 전략 덕분에 사용자 → DO, DO → Container 두 구간 모두에서 레이턴시를 최소화할 수 있었습니다.
실시간 상태 관리: KV에서 D1 + Queues로의 전환
초기에는 Workers KV를 사용해 컨테이너 상태를 저장했지만, KV의 결과적 일관성(최소 30초 캐시 TTL) 이 치명적인 병목이 되었습니다.
"KV에서 컨테이너를 'available'로 읽었지만, 실제로 라우팅할 때는 이미 할당된 상태인 경쟁 조건(Race Condition)이 발생"
해결책: D1 + Queues
D1의 트랜잭션 특성을 활용해 원자적 할당을 보장했습니다.
-- 브라우저 획득 쿼리 (의사 코드)
WITH candidate_pool AS (
-- 레이턴시 기반 후보 풀 선정
)
UPDATE containers
SET status = 'picked'
WHERE sessionId IN (
SELECT sessionId
FROM candidate_pool
ORDER BY RANDOM()
LIMIT ?5
)
RETURNING data
배치 쓰기(100행 배치) 를 통해 P95 쓰기 시간 0.1ms를 달성했으며, Queue를 이용한 비동기 상태 업데이트로 지연 시간 2초 미만을 유지했습니다.
{
"queues": {
"consumers": [
{
"queue": "production-core-containers-queue-weur",
"max_batch_size": 100,
"max_batch_timeout": 1,
"max_retries": 1
}
]
}
}
한국 개발 생태계에서의 적용 맥락
국내 SI/스타트업 환경에서도 실시간 상태 공유가 필요한 서비스 (예: 실시간 채팅, 협업 툴, 게임 서버)에서 유사한 패턴을 적용할 수 있습니다. 특히 KV 대신 RDBMS(MySQL, PostgreSQL)의 트랜잭션을 활용하거나, Redis Streams + 배치 처리 조합으로 대체할 수 있습니다.
결론: 멀티 에이전트 아키텍처의 교훈
Cloudflare Browser Run 사례는 다음과 같은 핵심 인사이트를 제공합니다.
- 점진적 전환(A/B 테스트) 이 대규모 마이그레이션의 리스크를 줄인다.
- 지리적 분산 아키텍처에서는 리전별 프리워밍 풀이 레이턴시 해결의 핵심이다.
- 실시간 상태 관리는 결과적 일관성보다 트랜잭션 기반 접근이 더 적합할 수 있다.
- Customer Zero 전략(자사 제품을 먼저 사용)은 제품 품질 향상에 큰 도움이 된다.
다음 단계 학습 방향
- AI 에이전트 개발에 관심이 있다면 2026년, 에이전틱 개발이 현실이 되다: Spotify x Anthropic 대담에서 본 5가지 핵심 인사이트를 참고하세요.
- 멀티 에이전트 아키텍처의 더 깊은 사례는 스포티파이가 광고 플랫폼을 멀티 에이전트 아키텍처로 재구축한 이유에서 확인할 수 있습니다.
이 기술의 한계 및 주의사항
- 초기 Containers 플랫폼은 문서화와 관측성이 부족하여 초기 학습 비용이 높습니다.
- Queue 백로그로 인한 상태 지연 가능성이 있으며, 이에 대한 fallback 전략(백업 리전)이 필수적입니다.
- 모든 서비스에 이 아키텍처가 적합한 것은 아닙니다. 트래픽 패턴이 짧고 폭발적인 경우에 특히 효과적입니다.