Build composable, interoperable multi-agent systems with A2A on AWS

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AWS의 두 계정에서 LangChain과 Strands 기반 에이전트 3개를 A2A와 양방향 OAuth로 연결해, 내부 구현이나 비밀정보를 공유하지 않는 조직 간 협업 구조를 제시한다.

📌 핵심 요약

• A2A는 조직과 프레임워크가 다른 에이전트의 발견·통신·작업 교환을 표준화하며, 고객과 프레임워크마다 별도 통합 코드를 작성해야 하는 부담을 줄인다. Linux Foundation 프로젝트이며 AWS도 지원한다.
• 참조 아키텍처는 기업과 SaaS 제공자의 AWS 계정 2개에 에이전트 3개를 배치한다. 기업의 LangChain 오케스트레이터와 컨텍스트 에이전트는 Amazon ECS와 AWS Fargate에서, Strands 기반 규정 준수 에이전트는 Amazon Bedrock AgentCore에서 실행된다.
• 각 조직은 자체 Amazon Cognito 사용자 풀을 사용하고, 온보딩에서는 자격 증명 공급자 URL·클라이언트 ID·범위·엔드포인트 URL 등 공개 값만 교환한다. 양방향 OAuth 인증을 적용하며 조직 간 비밀정보는 공유하지 않는다.
• 오케스트레이터는 시작 시 Agent Card의 스킬을 LangChain 도구로 구성하고 모델이 호출 여부를 결정한다. SaaS 에이전트는 등록된 콜백 주소의 기업 컨텍스트 에이전트에서 내부 정책과 계정 메타데이터를 받아 합성 데이터 기반의 규정 준수 검사를 수행한다.
• 배포에는 같은 지원 리전의 AWS 계정 2개, 필요한 모델 접근 권한, Python 3.10 이상 환경 등이 필요하다. 노트북 3개를 기업→SaaS→기업 순서로 실행하며 예상 시간은 각각 약 3분·5분·20분이다. 리소스 사용 비용이 발생하고, 테스트 후 노트북 3과 노트북 2 순서로 정리하도록 안내한다.

🧩 주요 포인트

1. Agent Card와 A2A 인터페이스를 호환되게 유지하면 내부 프레임워크·도구·모델을 변경할 수 있어, ISV의 구현 변경과 고객 통합 사이의 결합을 낮춘다.
2. 자체 Amazon Cognito 사용자 풀과 등록된 콜백 주소를 사용하는 양방향 OAuth 구조는 조직별 인증 경계를 유지하면서 기업의 내부 컨텍스트를 SaaS 작업에 결합한다.
3. A2A는 에이전트 간 협업을, MCP는 에이전트와 자체 도구·데이터 연결을 담당한다. 외부 인터페이스와 내부 도구 연결을 구분하므로 두 프로토콜을 함께 사용할 수 있다.

🧠 상세 정리

1. 조직 경계를 넘는 에이전트 통합의 과제

서로 다른 조직이 만들고 운영하는 에이전트가 협업하려면 상대의 내부 구현을 공개하거나 동일한 프레임워크를 채택하지 않고도 서로를 발견하고 작업을 교환할 수 있어야 한다. 원문은 A2A가 없는 경우 고객과 프레임워크 조합마다 맞춤형 통합 코드가 필요하다고 설명하며, 표준 프로토콜로 이 부담을 줄이는 접근을 제시한다. ISV는 고객이 이미 사용하는 A2A 호환 프레임워크와 연동되는 에이전트를 제공할 수 있고, 이 패턴은 파트너·고객·서로 다른 내부 팀 사이에도 적용된다. 시스템이 확장될 때는 오케스트레이터에 Agent Card를 등록해 스킬을 추가하므로 이미 실행 중인 에이전트를 변경할 필요가 없다는 것이 원문의 설명이다. A2A는 현재 Linux Foundation 프로젝트이며 AWS도 이를 지원하고, 이번 글은 기존의 Agent Card 발견·구조화된 작업 실행·A2A 서버 패턴 설명에서 더 나아가 프레임워크 간 상호운용성과 조직 간 신뢰 경계, 양방향 OAuth를 다룬다.

2. 두 AWS 계정에 배치한 에이전트 3개의 역할

참조 아키텍처는 기업용 AWS 계정과 SaaS 제공자용 AWS 계정을 분리하고, 그 안에서 에이전트 3개가 A2A로 협력하도록 구성한다. 기업 측의 Enterprise Orchestrator는 사용자 질문을 받아 필요한 외부 작업을 요청하고 결과를 요약하며, Enterprise Context Agent는 내부 정책과 계정 관련 메타데이터를 제공한다. 두 기업 에이전트는 Amazon ECS와 AWS Fargate를 사용하고, Amazon VPC의 프라이빗 서브넷에서 퍼블릭 IP 주소 없이 실행된다. SaaS 측의 Compliance SaaS Agent는 Strands Agents SDK로 구현되어 제공자 계정의 Amazon Bedrock AgentCore에서 실행되며, 기업의 내부 정책에 따라 AWS 계정의 규정 준수 상태를 검사하는 역할을 맡는다. 기업의 LangChain 기반 구성과 SaaS의 Strands 기반 구성은 상대방의 프레임워크나 SDK에 의존하지 않으며, 조직 경계를 넘는 통신에는 A2A를 사용한다.

3. 공개 값 교환과 양방향 OAuth 요청 흐름

온보딩에서는 양측이 자격 증명 공급자 URL, 클라이언트 ID, 범위, 엔드포인트 URL 같은 공개 값만 교환하고, 상대 조직의 Amazon Cognito 사용자 풀이 발급한 토큰을 신뢰하도록 설정한다. 사용자 앱은 기업 사용자 풀에서 액세스 토큰을 받아 Amazon API Gateway의 HTTPS 사용자 API로 질문을 보내고, 이후 응답을 폴링한다. API Gateway는 VPC 링크와 내부 Network Load Balancer를 통해 요청을 오케스트레이터로 전달하며, 모델이 규정 준수 검사가 필요하다고 판단하면 오케스트레이터는 AWS Secrets Manager에 저장된 자체 클라이언트 시크릿으로 기업 사용자 풀의 토큰을 발급받는다. 오케스트레이터의 A2A 요청을 받은 SaaS 에이전트는 온보딩 때 등록된 콜백 URL에서 기업 컨텍스트 에이전트의 Agent Card를 확인한 뒤, SaaS 제공자의 사용자 풀에서 토큰을 받아 기업 측으로 콜백한다. 사용자 API는 기업 자체 풀의 토큰만, 파트너 API는 SaaS 제공자의 콜백 토큰만 허용하며, 이 과정에서 조직 간 비밀정보를 공유하지 않는다.

4. Agent Card를 이용한 기업 측 도구 구성

Enterprise Orchestrator에서는 LangChain이 에이전트 프레임워크와 도구 호출 추상화를 제공하고, Amazon Bedrock의 Anthropic Claude Sonnet 4.6이 추론을 담당한다. 오케스트레이터는 시작할 때 SaaS 에이전트의 정해진 공개 URL에서 Agent Card를 읽고, 카드에 기술된 각 스킬에 대응하는 LangChain 도구를 생성한다. 이후 사용자 질문에 어떤 도구가 필요한지는 모델이 판단하므로, 원문은 오케스트레이터에 하드코딩된 라우팅 로직이 필요하지 않다고 설명한다. 오케스트레이터는 OAuth bearer 토큰을 포함한 A2A 요청으로 검사를 의뢰하고, 반환된 결과를 경영진이 읽을 수 있도록 요약한다. Enterprise Context Agent는 LangChain과 Amazon Nova Lite를 사용해 내부 정책, 데이터 분류, 업무 중요도, 담당 팀의 온콜 연락처 등을 제공하며, 배포 구현에는 AgentCard·AgentExecutor·명세에 맞는 JSON-RPC 경로를 제공하는 공식 a2a-sdk[http-server]==1.2.2가 고정되어 있다.

5. 기업 컨텍스트를 활용하는 SaaS 검사와 구현 독립성

Compliance SaaS Agent는 기업의 내부 정책을 기준으로 AWS 계정을 검사하며, 원문은 프로덕션 환경의 공개 스토리지 금지와 기밀 데이터의 저장 시 암호화를 정책 예시로 든다. 실제 운영에서는 검사 도구를 AWS Config, AWS Security Hub, Amazon GuardDuty 등에 연결할 수 있지만, 이 데모는 여러 계정의 규정 준수 발견 사항을 모사하는 합성 데이터를 사용한다. SaaS 에이전트는 검사 전에 기업 컨텍스트 에이전트에 콜백해 어떤 계정이 프로덕션인지, 어떤 정책을 적용해야 하는지, 누구에게 에스컬레이션해야 하는지를 확인한다. 콜백 대상은 고객이 온보딩 때 등록한 주소로 한정되며, 원문은 양측이 서로 호출하는 이 구조를 에이전트가 동등한 협업 주체로 작동하는 패턴으로 설명한다. 기업에는 SaaS 에이전트의 내부 도구·시스템 프롬프트·모델 선택을 공개하지 않고 카드에도 선별된 스킬 하나만 게시하므로, Agent Card와 A2A 인터페이스의 호환성을 유지하면 제공자가 내부 구조를 바꾸더라도 고객 통합을 유지할 수 있다.

6. 워크로드별 모델 선택과 A2A·MCP의 역할

Amazon Bedrock은 여러 파운데이션 모델에 대한 API 접근을 제공하므로, 이 구성에서는 각 에이전트의 작업 성격에 맞춰 모델을 다르게 선택한다. 복잡한 추론을 수행하는 오케스트레이터와 SaaS 에이전트에는 Anthropic Claude Sonnet 4.6을, 메타데이터 조회를 담당하는 컨텍스트 에이전트에는 Amazon Nova Lite를 사용하며, 원문은 요구사항에 따라 다른 모델을 선택할 수 있다고 설명한다. A2A는 내부 구현을 노출하지 않는 에이전트들을 동등한 주체로 연결하는 반면, MCP는 클라이언트·서버 방식으로 에이전트와 자체 도구 또는 데이터 소스를 연결하는 역할을 맡는다. 따라서 실제 운영에서는 SaaS 에이전트가 내부 검사 도구에 접근할 때 MCP를 사용하면서, 기업에 제공하는 외부 인터페이스에는 A2A를 적용할 수 있다. 이때 내부 도구 연결 방식이 바뀌어도 외부 A2A 인터페이스는 유지할 수 있으므로, 원문은 두 프로토콜을 서로 다른 문제를 해결하는 구성 요소로 구분한다.

7. 배포 전제조건과 비용 고려사항

배포에는 동일한 AWS 리전에 있는 기업용·SaaS 제공자용 계정 2개가 필요하며, 원문이 제시한 리전은 us-east-1, us-east-2, us-west-2다. 두 계정 모두 Amazon Bedrock의 Anthropic Claude Sonnet 4.6 접근 권한이 필요하고 기업 계정에는 Amazon Nova Lite 접근 권한도 필요하며, 최초 실행 전에 각 계정에서 Anthropic 최초 사용 양식을 제출하고 실행 주체에 문서에 명시된 AWS Marketplace 권한을 부여해야 한다. 실행 환경은 Python 3.10 이상의 Jupyter로, 로컬에서는 JupyterLab·AWS CLI 버전 2·계정별 AWS IAM Identity Center 프로필을 준비하고 컨테이너 이미지는 AWS CodeBuild가 빌드하므로 Docker는 필요하지 않다. 대안으로 각 계정에 Amazon SageMaker AI 노트북 인스턴스를 둘 수 있고 원문은 ml.t3.medium이면 충분하다고 설명하며, 각 계정에는 AWS CloudFormation 스택과 포함 리소스를 생성할 IAM 권한도 필요하다. 기업 계정에서는 NAT 게이트웨이, AWS Fargate 작업 2개, 내부 Network Load Balancer, 인터페이스 VPC 엔드포인트 2개가 주요 상시 실행 리소스이며, Amazon Bedrock과 Amazon Bedrock AgentCore의 사용량 비용 및 리전별 가격 차이도 고려해야 한다. 모델 가용성은 리전에 따라 달라 현재 문서를 확인해야 하고, 실행을 마치면 비용이 계속 발생하지 않도록 안내된 정리 절차를 수행하도록 설명한다.

8. 노트북 배포 순서와 제공된 설명의 범위

배포는 Jupyter에서 노트북 3개를 정해진 순서에 따라 셀 단위로 실행하는 방식이며, 먼저 GitHub 저장소를 복제하고 로컬용 AWS 프로필 2개 또는 계정별 노트북 인스턴스를 준비한다. 기업 계정의 노트북 1은 약 3분 동안 기업 측 인증 구성을 만들고 onboarding-request.json을 작성하며, 이 파일을 SaaS 제공자에게 전달한다. SaaS 계정의 노트북 2는 약 5분 동안 규정 준수 에이전트를 배포하고 onboarding-response.json을 생성하며, 기업은 이 응답 파일을 받아 약 20분이 걸리는 노트북 3에서 기업 에이전트를 배포하고 종단 간 테스트를 실행한다. 온보딩 파일에는 공개 값만 포함되며, 테스트가 끝난 후에는 노트북 3의 Clean up을 먼저 실행하고 노트북 2의 Clean up을 실행하도록 안내한다. 원문이 강조하는 결과는 프레임워크 간 상호운용성, 조직 경계를 넘는 기능 조합, OAuth를 이용한 양방향 협업이지만, 제공된 본문은 SaaS 규정 준수 에이전트 구현 절의 도입부에서 끊겨 있어 후속 구현 코드나 실제 테스트 결과는 확인할 수 없다.

🧾 핵심 주장 / 시사점

• Agent Card를 통한 스킬 공개는 외부에 제공하는 기능의 계약 역할을 한다. 내부 도구 이름이나 프레임워크 대신 이 계약을 유지하는 것이 조직 간 통합의 안정성에 중요하다.
• SaaS가 기업의 내부 정책과 계정 맥락을 조회하는 양방향 협업은 외부 검사 기능과 기업별 판단 기준을 결합한다. 제공된 데모의 검사 자료는 합성 데이터이므로 실제 서비스 연결에 따른 동작까지 입증한 것으로 볼 수는 없다.
• 노트북은 배포와 종단 간 테스트 경로를 제공하지만, 실제 실행에는 모델 접근 권한·리전별 가용성·상시 리소스 비용이 함께 영향을 준다. 제공된 본문만으로 테스트 성공 여부를 확인할 수는 없다.

✅ 액션 아이템

• Agent Card와 A2A 인터페이스의 호환성을 기준으로 기존 에이전트 연동과 내부 구현 변경의 영향을 검토.
• Amazon Cognito 사용자 풀의 상호 신뢰, 공개 값만 교환하는 온보딩, 등록된 콜백 주소를 사용하는 양방향 OAuth 구성을 확인.
• AWS 계정 2개와 Python 3.10 이상 환경 및 모델 접근 권한을 준비하고, 노트북 3개를 순서대로 실행한 뒤 비용을 고려해 노트북 3→노트북 2 순서로 정리.

❓ 열린 질문

• Agent Card에 새 스킬을 추가할 때 기존 A2A 인터페이스와의 호환성은 어떻게 유지할 것인가?
• 양방향 OAuth에서 각 Amazon Cognito 사용자 풀의 상호 신뢰와 등록된 콜백 주소를 어떻게 검증할 것인가?
• 노트북 3개의 배포에 사용할 지원 리전에서 필요한 모델 접근 권한을 확보할 수 있으며, 리소스 사용 비용은 어느 정도인가?