How MoEngage turned over 400 APIs into agent tools with AgentCore Gateway

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

MoEngage는 AgentCore Gateway로 400개 안팎의 비공개 REST API를 권한별 에이전트 도구로 연결해, 자체 플랫폼 엔지니어링 작업 약 6개월을 절감한 것으로 추산하고 신규 API 연결 시간을 수일에서 수시간으로 줄였다.

📌 핵심 요약

• MoEngage는 1,350개 이상의 소비자 브랜드를 지원하며, 25개 엔지니어링 팀이 개발한 약 400개의 내부 REST API를 7개 AWS 리전의 비공개 VPC에서 운영한다. 데이터 상주 요건을 지키면서 에이전트가 기존 기능을 안전하게 이용하도록 연결하는 것이 과제였다.
• 팀마다 MCP 서버를 구축하면 20개가 넘는 서버의 배포·유지보수와 여러 서버 간 연동 부담이 발생하므로, 제품 팀은 OpenAPI 명세와 도구로 노출할 작업을 정의하고 AI Platform 팀이 MCP 계층 전체를 소유하는 구조를 선택했다.
• AgentCore Gateway는 OpenAPI 명세에서 MCP 도구를 생성하고, 에이전트별 IAM 역할과 Cedar 정책으로 도구 목록과 호출 권한을 서버에서 제한한다. VPC 인터페이스 엔드포인트와 Amazon VPC Lattice 기반 관리형 송신 연결을 사용해 내부 API 호출 경로를 비공개로 유지한다.
• 내부 에이전트 요청은 SigV4로 인증하며, 테넌트·사용자·역할·데이터베이스 정보는 모델이 설정할 수 있는 도구 인자 대신 X-MOE-* 헤더로 전달한다. 이 신원 정보는 도구 목록 조회나 검색에는 포함하지 않고 tools/call에만 전달한다.
• 도구당 약 50토큰인 전체 카탈로그는 20,000토큰을 넘으므로, 모델에는 우선 search_tools 하나만 제공하고 의미 검색 결과로 얻은 후보만 해당 턴에 호출할 수 있게 한다. 신규 API는 OpenAPI의 x-moe-mcp로 명시적으로 노출하며, 연결 시간은 수일에서 수시간으로 단축됐다고 설명한다.

🧩 주요 포인트

1. OpenAPI 명세를 제품 팀과 AI Platform 팀의 책임 경계로 삼음 → 팀별 MCP 구현과 중앙 플랫폼의 중복 개발 부담을 줄인다.
2. Cedar의 서버 측 권한 제한과 X-MOE-* 헤더 기반 신원 전달을 결합함 → 도구 접근 권한과 호출 신원을 모델의 선택이나 클라이언트 필터링에 맡기지 않는다.
3. 개 AWS 리전에서 재사용하는 비공개 연결과 search_tools 기반 검색을 적용함 → API 추가에 따른 네트워크 작업과 대규모 도구 목록의 컨텍스트 부담을 함께 줄인다.

🧠 상세 정리

1. 기존 기능을 에이전트에 안전하게 연결하는 문제

MoEngage는 1,350개 이상의 소비자 브랜드가 푸시, 이메일, 인앱, SMS, WhatsApp, RCS에서 개인화된 경험을 제공하도록 지원하는 고객 참여 플랫폼이다. 제품 뒤에는 25개 엔지니어링 팀이 만든 약 400개의 내부 REST API가 있으며, 이 API들은 7개 AWS 리전의 비공개 VPC에서 실행된다. 캠페인 생성, 세그먼트 조회, 전달 통계처럼 에이전트에 필요한 기능은 이미 운영 중이어서 새로운 기능 개발보다 기존 기능에 대한 안전한 접근이 핵심 과제였다. 특히 데이터 상주 약속에 따른 리전별 격리와 인터넷 비공개 원칙을 유지하면서, 모델이 신원을 통제하거나 수백 개의 도구 정의가 컨텍스트를 채우는 상황을 피해야 했다. 글은 AgentCore Gateway 도입으로 플랫폼 엔지니어링 작업 약 6개월을 절감한 것으로 추산하며, API 연결 시간이 수일에서 수시간으로 줄었다고 설명한다.

2. 팀별 MCP 서버와 자체 중앙 서버를 배제한 이유

MCP는 에이전트가 도구를 발견하고 호출하는 표준 방식을 제공하지만, MoEngage는 각 팀이 자체 MCP 서버를 운영하는 접근을 검토한 뒤 채택하지 않았다. 서버가 20개를 넘으면 배포 상태를 감시하고 패치하며 프로토콜 변화에 맞춰 호환성을 유지해야 할 대상도 그만큼 늘어난다. 캠페인과 세그먼트, 전달 통계를 함께 확인하는 에이전트는 여러 서버에 연결해 결과를 조정해야 하고, 제품 팀마다 본래 업무와 별개로 MCP 전문성을 확보해야 한다. 이에 제품 팀은 REST API와 잘 설명된 OpenAPI 명세를 제공하고 도구로 노출할 작업을 선언하며, AI Platform 팀이 MCP 계층을 전담하도록 책임을 나눴다. 자체 중앙 MCP 서버도 가능했지만, 도구 생성 파이프라인과 정책 파일 형식, 이름 변경용 별칭 관리, 회로 차단기까지 직접 개발하고 소유해야 한다는 부담이 남았다.

3. 비공개 연결·신원 분리·카탈로그 규모라는 제약

원문은 아키텍처를 결정한 제약이 네 가지라고 소개하지만, 제공된 본문에서 독립된 항목으로 구체적으로 설명하는 것은 공개 엔드포인트 금지, 모델의 신원 통제 금지, 대규모 도구 카탈로그 문제의 세 가지다. 내부 API는 추가 인증을 붙이더라도 외부에 공개할 수 없으며, API마다 NAT 게이트웨이·역방향 프록시·VPN 터널을 구성하면 7개 리전에서 네트워크 변경과 보안 검토 부담이 커진다. 모든 호출에 필요한 테넌트·사용자·역할·데이터베이스 정보를 모델에 보이는 인자로 전달하면 모델이 잘못 설정하거나 변경하도록 유도될 수 있다는 점도 제약이었다. 또한 도구당 JSON 스키마가 약 50토큰이면 전체 tools/list 응답은 20,000토큰을 넘어 실제 작업에 필요한 컨텍스트를 밀어낸다. 클라이언트 측 필터링은 전체 목록이 이미 전송된 뒤에 적용되므로 전송 부담을 해결하지 못하며, 허용되지 않은 쓰기 도구를 숨기는 권한 경계로도 충분하지 않다고 주장한다.

4. OpenAPI 도구 생성과 Cedar의 서버 측 권한 통제

Amazon Bedrock AgentCore Gateway는 OpenAPI 명세를 대상으로 등록하면 MCP 도구를 생성하고 실제 호출을 내부 서비스로 전달하는 완전관리형 MCP 서버다. 도구 이름은 Target___operationId 형식을 따르며, 예시로 CampaignsAPI___searchCampaigns가 제시되고 명세의 작업 추가·변경·삭제가 도구 구성에 반영된다. 제품 팀은 별도 MCP 서버 코드나 API 명세와 따로 동기화할 도구 정의를 관리할 필요가 없다는 것이 이 접근의 장점이다. 권한 측면에서는 각 에이전트가 자신의 IAM 역할로 인증하고, 정책 엔진이 Cedar 정책을 부분 평가해 응답을 직렬화하기 전에 해당 주체에게 허용된 도구 목록을 구성한다. 예시의 campaign-qa-bot-v1은 캠페인·세그먼트 읽기 도구를 이용할 수 있지만 쓰기 작업은 금지되며, 쓰기 도구는 tools/list 응답에 처음부터 포함되지 않는다.

5. 7개 리전에서 재사용하는 비공개 호출 경로

에이전트에서 내부 API로 이어지는 경로는 VPC 인터페이스 엔드포인트, AgentCore Gateway의 정책 평가, Amazon VPC Lattice를 통한 관리형 송신 연결로 구성된다. Amazon EC2나 컨테이너에서 실행되는 에이전트 서비스는 공식 MCP SDK, LangChain, Google ADK 또는 MoEngage 자체 실행기를 클라이언트로 사용할 수 있다. 클라이언트의 HTTPS 요청은 비공개 DNS가 설정된 VPC 인터페이스 엔드포인트로 전달되며, 게이트웨이는 정책을 확인한 뒤 내부 API로 호출을 라우팅한다. 이 내부 호출 경로에는 공개 구간이 없고, 개별 API를 연결할 때마다 MoEngage가 별도의 네트워크 구성을 만들고 운영할 필요도 없다. 새 API 연결이 네트워크 토폴로지 변경 대신 대상 추가로 처리되므로, API와 리전 수가 늘어날수록 반복되던 네트워크 작업을 줄이는 기반이 된다.

6. SigV4 인증과 모델 밖에서 전달하는 호출 신원

MoEngage는 내부 에이전트가 이미 IAM 역할을 가진 서비스라는 점을 고려해 내부 게이트웨이 인증에 JWT 대신 SigV4를 선택했다. 기존 자격 증명으로 요청에 서명할 수 있어 새로운 인증 정보를 발급·교체·저장할 필요가 없으며, Claude 등에서 사람이 인증하는 별도의 공개 MCP 서버는 AgentCore runtime에서 OIDC JWT를 사용하는 다른 접점으로 구분한다. 테넌트·사용자·역할·데이터베이스 문맥은 클라이언트 라이브러리가 작은 Identity 객체에서 X-MOE-* 헤더로 변환하므로, 모델은 이를 보거나 도구 인자로 설정할 수 없다. SigV4가 Authorization 헤더를 사용하기 때문에 전달해야 하는 bearer 토큰은 별도의 MoEngage 접두사 헤더에 넣으며, 헤더 전달 개수에도 제한이 있어 필요한 항목을 선별한다. 도구 목록 조회와 검색에는 테넌트 신원을 싣지 않고 tools/call에만 포함해, 신원 정보가 실린 요청이 실제 데이터 접근이라는 점을 감사 기록에서 분명하게 만든다.

7. 의미 검색으로 도구 발견과 컨텍스트 사용을 줄이는 방식

Cedar로 도구 범위를 제한해도 허용된 도구가 많을 수 있어, MoEngage의 클라이언트 라이브러리는 모델에 search_tools라는 단일 메타 도구를 먼저 제공한다. 모델이 필요한 작업을 설명하면 게이트웨이의 의미 검색이 후보를 반환하고, 해당 후보만 그 턴의 나머지 과정에서 호출 가능한 도구가 된다. 따라서 시작 시 컨텍스트에는 도구 정의 하나만 들어가며, 검색 이후에도 관련된 소수의 도구만 추가되어 전체 카탈로그를 넣는 부담을 피한다. 게이트웨이의 x_amz_bedrock_agentcore_search 기능을 사용하므로 별도의 도구 검색 계층을 직접 구현할 필요도 없어졌다. 검색이 식별자보다 설명을 바탕으로 이뤄지기 때문에 get_segment_user_count가 get_segment_size로 바뀌더라도 segment user count라는 요청으로 도구를 찾을 수 있다는 이름 변경 대응 효과도 제시한다.

8. OpenAPI의 명시적 노출 설정과 제공 본문의 한계

새 API를 에이전트 도구로 연결하려는 팀은 기존 OpenAPI 명세에 x-moe-mcp 블록을 추가하며, 예시에서는 /campaigns의 GET 작업에 listCampaigns라는 operationId를 지정한다. expose 설정은 external을 false, internal을 true로 두고, tool_description에는 상태나 채널로 캠페인을 찾는 목적과 반환되는 캠페인 ID·이름·상태·채널을 설명한다. 또한 반환된 campaign_id를 get_campaign의 상세 조회나 send_campaign의 실행에 사용할 수 있다고 안내하고, param_overrides에는 active와 scheduled의 의미 및 상태 생략 시 전체를 조회한다는 설명을 담는다. 본문은 이 블록의 설계 선택 네 가지를 설명하겠다고 예고한 뒤, x-moe-mcp 블록이 없는 엔드포인트는 도구가 되지 않는 명시적 선택 방식을 첫 번째 원칙으로 밝힌다. 다만 제공된 source_body는 이어지는 CI 설명 도중에 끊기므로, CI의 구체적인 동작이나 나머지 설계 선택은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 제품 팀의 기존 OpenAPI 명세를 도구 정의로 재사용하면, MCP 도입을 각 팀의 별도 구현 과제로 만들지 않고 기존 API 개발 책임과 연결할 수 있다.
• Cedar는 도구 접근 권한을 제한하고 X-MOE-* 헤더는 호출 신원을 전달하므로, 모델에 제공할 기능과 모델이 변경할 수 없어야 할 정보를 서로 다른 계층에서 통제한다.
• 서버 측 도구 범위 제한과 search_tools 기반 후보 검색은 함께 작동한다. 전자는 권한 경계를 만들고, 후자는 허용된 도구가 여전히 많을 때 컨텍스트 부담을 줄인다.

✅ 액션 아이템

• OpenAPI 명세와 x-moe-mcp를 기준으로 신규 API의 도구 노출 범위와 제품 팀·AI Platform 팀의 책임 경계를 검토한다.
• Cedar의 도구 목록·호출 권한 제한과 X-MOE-* 헤더의 신원 전달이 모델의 설정 권한 밖에서 적용되는지 확인한다.
• 7개 AWS 리전의 비공개 연결과 search_tools 적용을 기준으로 API 연결 시간 및 도구 컨텍스트 부담의 감소 효과를 평가한다.

❓ 열린 질문

• 신규 API 연결 시간이 수일에서 수시간으로 줄어든 효과는 API의 종류와 복잡도에 따라 어떻게 달라지는가?
• Cedar 정책이 제한한 도구 목록 안에서 search_tools는 필요한 후보를 얼마나 정확하게 찾아내는가?
• 7개 AWS 리전에서 비공개 연결을 재사용하면서 데이터 상주 요건은 어떻게 일관되게 충족하는가?