Three Clouds, Three Native Agents

개요

Google Cloud Run, AWS Bedrock AgentCore, Azure Container Apps를 각각 사용하여 구축된 세 개의 AI 에이전트가 동일한 질문에 동시에 답변하고, 이들의 응답 중 중앙 코디네이터가 중앙값으로 취합하는 프로젝트입니다.

주요 내용

* 다중 클라우드 에이전트 아키텍처: GCP, AWS, Azure 세 가지 주요 클라우드 벤더의 네이티브 에이전트 기능을 활용하여 동일한 질문에 대한 응답을 비교합니다.
* 보안 및 인증 메커니즘: 장기 보관되는 자격 증명(credential) 없이, 필요 시점에 발급되는 토큰을 통해 각 에이전트 간의 인증을 처리합니다. A2A v1.0 프로토콜을 사용하여 에이전트 간 통신을 수행합니다.
* 코디네이터의 역할: 세 에이전트로부터 받은 응답의 중앙값을 계산하여 최종 결과를 도출하며, 이를 위해 각 클라우드의 API를 호출합니다.
* 페더레이션 기반 인증: 각 클라우드 벤더의 OIDC(OpenID Connect) 통합 기능을 활용하여, 별도의 서비스 계정 키를 저장하지 않고도 다른 클라우드의 에이전트를 호출할 수 있도록 합니다.
* 배포 및 실행: GitHub 저장소를 통해 전체 시스템을 로컬 환경에 약 1분 안에 배포하고 실행할 수 있으며, 세 에이전트와 코디네이터를 포함합니다.
* 실제 배포 시 고려 사항:
* 코디네이터가 실행될 클라우드 환경 결정이 시스템의 비밀 키(secret) 수를 결정합니다. GCP Cloud Run은 이 과정에서 제로 시크릿(zero secrets)을 달성할 가능성이 높습니다.
* 클라우드 간 연동 시 httpx.Auth와 같은 단일 인터페이스를 사용하여 다양한 인증 메커니즘을 통합합니다.
* 에이전트 카드(.well-known/agent-card.json)도 에이전트 자체와 동일한 인증 메커니즘을 사용해야 합니다.
* audience와 subject에 대한 명확한 정의 및 제약 조건 설정이 중요하며, GCP의 경우 format=full 옵션을 사용하여 모든 클레임이 포함된 토큰을 받아야 합니다.
* AWS와 Azure의 페더레이션 설정 시 서로 다른 방식으로 접근해야 하며, 오류 메시지가 구체적인 문제점을 직접적으로 나타내지 않을 수 있습니다.
* 모든 인증 경계에서 공급자(provider)의 원시 응답을 기록하는 것이 디버깅에 유용합니다.
* 재현성을 위해 시스템을 무(zero)에서 최소 한 번 재구축하는 것이 권장됩니다.
* 콜드 스타트(cold start) 시간과 웜 런(warm run) 시간의 차이를 명확히 인지하고, 이를 바탕으로 성능 테이블을 작성해야 합니다.
* 핵심 구조:
* Credential Seam: httpx.Auth를 사용하여 호출자가 사용하는 세 가지 메커니즘을 알 필요 없이 인증을 처리합니다.
* Participant Interface: 클라우드 벤더를 구현체로 취급하여 분기(branch)를 줄입니다.
* Instrument, not a Demo: 각 계층별 오류 추적을 통해 시스템의 상태를 명확히 파악합니다.
* Scoped Controls: 단일 구성 요소에 대한 제어를 통해 시스템의 기능 저하 시에도 오류를 숨기지 않도록 합니다.

시사점

본 프로젝트는 여러 클라우드 환경에서 네이티브 에이전트와 페더레이션 인증을 활용하여 복잡한 시스템을 구축하고 운영하는 실질적인 방법론을 제시하며, 특히 보안, 재현성, 오류 처리 및 성능 측정에 대한 중요한 실무적 통찰을 제공합니다.