190개 연결망을 하나로, AWS가 제안하는 서버리스 A2A 게이트웨이 구현법

20개 에이전트의 190개 연결망을 단일 진입점으로 통합

기업이 여러 팀과 벤더, 인프라에 걸쳐 AI 에이전트를 배포하면 에이전트 간 통신을 관리하는 운영 부담이 증가한다. 여러 개의 AI 에이전트를 도입하면 각 에이전트마다 API 키를 따로 관리하고 연결 설정을 반복하는 번거로움이 발생한다. 중앙 오케스트레이터(전체 흐름을 제어하는 시스템)가 없는 환경에서 에이전트 20개를 운용할 경우, 최대 190개의 점대점(Point-to-Point, 두 지점을 직접 연결하는 방식) 연결망을 개별적으로 설정해야 한다. 이러한 구조는 새로운 에이전트가 추가될 때마다 기존 연결을 다시 확인해야 하는 운영 오버헤드를 만들며, 일관되지 않은 인증 정책으로 인해 보안 위험을 높이고 시장 출시 속도를 늦춘다.

AWS는 이를 해결하기 위해 모든 에이전트 앞에 단일 진입점을 두는 중앙 집중형 게이트웨이 패턴을 제안한다. 게이트웨이는 에이전트가 Amazon ECS(컨테이너 관리 서비스), AWS Lambda(서버리스 함수 서비스), Amazon Bedrock AgentCore Runtime, 혹은 타 클라우드나 하이브리드 환경 중 어디에서 구동되든 관계없이 단일 도메인 내에서 경로 기반 라우팅(요청 경로에 따라 목적지를 배정하는 방식)을 수행한다. 클라이언트는 `/agents/{agentId}` 형태의 경로를 통해 필요한 에이전트에 접근하며, 게이트웨이가 이를 해석해 적절한 백엔드로 요청을 전달함으로써 통신 구조를 표준화한다.

서버리스 스택 기반의 게이트웨이 아키텍처 구성

전체 인프라는 AWS의 서버리스 스택을 통해 구축되어 운영 효율성을 극대화한다. Amazon API Gateway(REST API)가 단일 진입점 역할을 수행하며, REST API 방식을 채택해 SSE(Server-Sent Events, 서버에서 클라이언트로 데이터를 실시간 전송하는 방식) 스트리밍을 지원함으로써 에이전트의 실시간 응답을 가능하게 한다. 실제 게이트웨이 로직은 AWS Lambda가 처리하며, 데이터 저장소인 Amazon DynamoDB(NoSQL 데이터베이스)에는 에이전트 ID와 백엔드 URL을 매핑한 레지스트리, 권한 테이블, 그리고 분당 요청 수를 기록하는 RateLimitCounters 테이블이 저장된다.

사용자 인증은 Amazon Cognito가 OAuth 2.0 클라이언트 자격 증명 흐름을 통해 담당하며, 인증된 사용자에게는 JWT(JSON Web Token, 인증 정보를 담은 전자 서명 토큰)가 발급된다. 백엔드 에이전트 접속에 필요한 OAuth 클라이언트 비밀키는 AWS Secrets Manager에서 ARN(Amazon Resource Name, AWS 리소스 고유 식별자) 기반으로 조회하여 보안성을 높인다. 또한 Amazon Titan Text Embeddings(텍스트를 수치 벡터로 변환하는 모델)를 사용해 에이전트 설명을 벡터화하고 Amazon S3 Vectors에 저장함으로써, 단순 이름 매칭이 아닌 자연어 쿼리를 통한 시맨틱 검색(의미 기반 검색)으로 에이전트를 발견할 수 있는 구조를 갖춘다.

JWT 스코프 기반의 IAM 정책 변환과 권한 제어

Lambda Authorizer는 인증 단계에서 JWT 스코프를 분석하여 API Gateway 레벨에서 경로별 접근을 제어하는 권한 매핑 구조를 구현한다. 인증된 클라이언트가 제출한 JWT 내의 스코프(예: `billing:read`, `support:write`)를 Permissions 테이블에서 조회하여, 해당 사용자가 접근 가능한 에이전트 목록을 확인한다. 이후 Lambda Authorizer는 이 정보를 바탕으로 `/agents/agent-a/*`와 같은 특정 경로에 대해서만 접근을 허용하는 IAM(Identity and Access Management, AWS 리소스 접근 제어 정책) 정책을 동적으로 생성하여 반환한다.

이러한 구조를 통해 권한이 없는 요청은 백엔드 람다 함수에 도달하기 전 API Gateway 단계에서 즉시 차단되어 보안 리스크를 최소화한다. 또한 Proxy Lambda는 Amazon DynamoDB의 원자적 카운터(Atomic Counter, 동시성 문제 없이 수치를 증감시키는 기능)와 TTL(Time-to-Live, 설정 시간이 지나면 데이터를 자동 삭제하는 기능)을 조합해 사용자 및 에이전트별로 요청 쿼터를 관리한다. 제한 수치를 초과한 요청에는 `Retry-After` 헤더를 포함한 429 상태 코드를 반환하여 시스템 전체의 안정성을 유지한다.

A2A 표준 프로토콜 준수와 시맨틱 검색 기반 발견

게이트웨이는 에이전트 간 통신 표준인 A2A(Agent-to-Agent) 프로토콜을 준수하여 상호운용성을 확보한다. A2A 표준은 두 가지 바인딩 방식을 지원하는데, 먼저 JSON-RPC(원격 프로시저 호출을 위한 경량 데이터 교환 형식) 바인딩은 에이전트당 단일 엔드포인트를 사용하며 요청 본문에 실행할 메서드를 포함해 전송한다.

{ "jsonrpc": "2.0", "method": "get_weather", "params": { "location": "Seoul" }, "id": 1 }

전통적인 웹 API 방식을 선호하는 클라이언트를 위해서는 HTTP+JSON/REST 바인딩을 함께 제공하여 리소스 중심의 직관적인 URL 경로 설정을 지원한다. 클라이언트는 개별 백엔드 서버의 주소를 일일이 등록할 필요 없이 게이트웨이가 제공하는 표준 인터페이스를 통해 기능을 호출한다. 여기에 Amazon S3 Vectors에 저장된 벡터 데이터를 활용한 시맨틱 검색을 결합하면, 사용자가 필요한 업무를 일상어로 입력했을 때 시스템이 의미적으로 가장 유사한 설명을 가진 에이전트를 찾아 연결해 주는 고도화된 발견 프로세스를 제공한다.

Terraform 기반의 배포와 레지스트리 중심 운영 기준

전체 게이트웨이 인프라는 IaC(Infrastructure as Code, 코드로 인프라를 관리하는 방식) 도구인 Terraform을 통해 원클릭으로 배포된다. 사용자는 aws-samples 리포지토리의 코드를 활용해 `terraform/terraform.tfvars` 파일에서 설정을 마친 뒤 아래 명령어를 통해 환경을 구축한다.

bash

terraform apply

이 과정을 통해 DynamoDB 테이블, Cognito 사용자 풀, Amazon ECR, Lambda 함수, API Gateway, IAM 역할이 한 번에 생성되며, 프록시 Lambda 컨테이너가 자동으로 빌드 및 푸시된다. 실제 적용 시에는 `examples` 폴더의 Weather Agent와 Calculator Agent 예제를 통해 독립적인 배포를 검증할 수 있으며, 관리자 권한의 JWT를 사용해 아래와 같이 레지스트리에 에이전트를 등록한다.