AWS AgentCore Gateway, AI 에이전트의 사설망 접근을 제품 기능으로 끌어올리다

AWS가 Bedrock AgentCore Gateway의 사설 리소스 접근용 VPC egress 구성을 공개했다. 에이전트가 내부 API와 MCP 서버를 쓰면서도 공용 인터넷 노출을 줄이는 방향이다.

비공개 네트워크가 에이전트 제품의 품질 기준이 됐다

AI 에이전트의 도구 호출은 이제 데모용 HTTP 요청 수준에 머물기 어렵다. 실제 업무 환경에서는 결제, 물류, 고객 지원, 보안 관제, 데이터 분석 도구가 대부분 내부 네트워크 경계 안에 있고, 접근 권한은 팀·계정·환경별로 나뉜다. 이런 리소스를 에이전트에게 연결하려면 모델 호출만큼이나 네트워크 경로, 인증, 감사 가능성, 장애 격리가 중요해진다.

AWS 블로그가 다룬 AgentCore Gateway VPC egress 구성은 이 지점을 정면으로 겨냥한다. AgentCore Gateway가 사설 엔드포인트에 접근할 때 Resource Gateway라는 관리형 진입점을 두고, 지정된 서브넷마다 Elastic Network Interface를 배치해 트래픽이 VPC 내부 경로를 타도록 한다. 에이전트가 내부 도구를 호출하더라도 대상 전체 VPC를 넓게 여는 방식이 아니라, 특정 도메인 이름이나 IP 주소로 정의된 Resource Configuration을 통해 접근 범위를 좁히는 구조다.

이 변화가 중요한 이유는 에이전트 플랫폼의 평가 기준이 달라지고 있기 때문이다. 초기에는 어떤 모델을 붙였는지, 어떤 프롬프트가 가능한지, 어떤 도구 목록을 보여주는지가 주로 비교됐다. 그러나 운영 단계에서는 에이전트가 사내 API를 호출한 흔적을 남길 수 있는지, 사설망 연결을 임시 우회로가 아니라 제품 기능으로 다루는지, 계정 분리와 네트워크 분리를 조직 정책에 맞출 수 있는지가 더 큰 차이를 만든다.

Resource Gateway가 좁히는 접근 범위

Resource Gateway의 의미는 단순한 터널링보다 작동 범위를 좁히는 데 있다. AWS 설명에 따르면 Resource Gateway는 사설 리소스가 있는 VPC 안의 진입점 역할을 하고, AgentCore Gateway에서 오는 트래픽은 이 진입점을 통해 대상 엔드포인트로 이동한다. Resource Configuration은 AgentCore Gateway가 닿을 수 있는 리소스를 도메인 이름이나 IP 주소 단위로 정의한다.

이 설계는 에이전트 보안에서 자주 생기는 모호함을 줄인다. “에이전트가 우리 내부망에 접근한다”는 표현은 너무 넓다. 운영자가 실제로 알아야 할 것은 어떤 Gateway Target이 어떤 VPC, 어떤 서브넷, 어떤 보안 그룹, 어떤 엔드포인트에 닿는지다. Resource Configuration이 단일 엔드포인트 중심으로 접근을 제한하면, 에이전트 도구 연결을 승인할 때 검토 단위가 더 작아진다.

특히 MCP 서버를 내부에 두는 팀에는 이 구분이 중요하다. MCP는 에이전트가 도구와 데이터를 발견하고 호출하는 공통 접점으로 확산되고 있지만, 서버가 내부 업무 시스템과 연결될수록 공개 노출 위험도 커진다. AgentCore Gateway가 MCP 호환 도구 연결을 제품 기능으로 내세우고, VPC 내부 리소스 접근 방식을 함께 설명한 것은 에이전트 생태계가 도구 표준과 네트워크 보안을 동시에 풀어야 한다는 신호다.

managed와 self-managed 사이의 선택은 조직 구조를 드러낸다

AWS는 이번 구성에서 managed VPC resource 모드와 self-managed Lattice resource 모드를 나눠 설명한다. managed 모드에서는 VPC ID, 서브넷, 보안 그룹 같은 대상 설정을 제공하면 AgentCore 쪽에서 Resource Gateway를 생성하고 관리한다. 빠르게 연결을 만들고 싶은 팀, 네트워크 세부 구현보다 에이전트 기능 출시 속도가 중요한 팀에는 이 경로가 현실적이다.

반대로 self-managed 방식은 VPC Lattice Resource Gateway와 Resource Configuration을 조직이 직접 만들고 참조한다. 이 경로는 더 많은 설정 책임을 요구하지만, 서브넷 배치, 보안 그룹 규칙, IPv4 주소 수, 리소스 공유와 해제 같은 통제면을 더 분명하게 가져갈 수 있다. 특히 cross-account 연결이나 중앙 네트워크 팀이 있는 조직에서는 이 차이가 작지 않다.

흥미로운 점은 이 선택이 기술 취향보다 조직 구조를 반영한다는 것이다. 스타트업이나 단일 제품팀은 managed 방식으로 충분할 수 있다. 반면 금융, 공공, 대기업처럼 네트워크 경계와 계정 분리가 엄격한 곳은 self-managed 방식을 검토할 가능성이 높다. 에이전트 도입이 커질수록 “모델을 무엇으로 쓸 것인가”만큼 “누가 네트워크 리소스를 소유하고 승인할 것인가”가 구매·아키텍처 논의의 중심으로 올라온다.

MCP 서버를 안쪽에 두는 설계가 남기는 숙제

AgentCore Gateway의 사설망 접근은 에이전트를 더 안전하게 만들 수 있지만, 그것만으로 운영 문제가 사라지는 것은 아니다. 내부 MCP 서버나 REST API를 에이전트에게 연결하면 권한 모델, 입력 검증, 호출 한도, 로그 보존, 실패 시 차단 기준을 별도로 정해야 한다. 네트워크 경로가 사설이면 외부 노출 위험은 줄어들지만, 에이전트가 잘못된 도구를 과도하게 호출하거나 민감한 내부 작업을 실행할 가능성은 여전히 남는다.

그래서 이번 발표를 읽을 때는 “AWS가 사설 연결을 지원한다”에서 멈추면 부족하다. 기업은 AgentCore Gateway Target을 업무 단위로 나누고, 각 Target이 접근할 API를 최소화하며, 에이전트가 호출하는 도구의 감사 로그를 애플리케이션 로그와 함께 보관해야 한다. private REST API나 Amazon EKS 위 MCP 서버를 연결할 수 있다는 사실보다 더 중요한 것은, 그 연결을 언제 끊고 어떻게 검토할지까지 운영 규칙으로 만드는 일이다.

개발팀 입장에서는 에이전트 도구를 처음부터 인터넷 공개 API로 설계하지 않아도 된다는 선택지가 넓어진다. 이미 VPC 안에서 검증된 내부 API를 작은 범위로 노출하고, 테스트 계정·스테이징 엔드포인트·읽기 전용 권한부터 연결해볼 수 있다. 다만 프로덕션 쓰기 작업까지 맡기려면 네트워크 연결 성공보다 더 높은 기준이 필요하다. 호출 전 승인, 실패한 요청의 자동 중단, 비용과 지연 시간 모니터링, 권한 축소 절차가 함께 있어야 한다.

독자가 먼저 확인할 지점

이 소식은 기능 이름보다 운영 조건을 먼저 봐야 한다. 어떤 권한이 필요한지, 어떤 경로로 데이터가 이동하는지, 실패했을 때 사람이 확인할 수 있는 로그가 남는지가 실제 도입 판단의 기준이다.

팀 적용 시나리오

작은 팀은 한두 개의 대표 업무에만 적용해 응답 품질과 검증 비용을 비교하는 편이 안전하다. 큰 조직은 권한 경계, 감사 로그, 네트워크 분리, 비용 상한을 먼저 설계한 뒤 제한된 부서에서 파일럿을 시작해야 한다.

확인 체크리스트

공식 문서의 지원 범위, 가격과 사용량 제한, 권한 모델, 실패 시 되돌리기 방법, 공개 서비스에 미치는 영향을 순서대로 확인해야 한다. 이 다섯 가지가 불명확하면 발표 내용이 좋아 보여도 운영 도입은 늦추는 편이 낫다.

기업이 도입 전에 확인해야 할 기준

도입 판단은 서비스 이름보다 운영 증거로 해야 한다. 첫째, 에이전트가 접근하는 내부 API와 MCP 서버를 업무 단위로 분리해야 한다. 둘째, 각 연결마다 승인자, 네트워크 경로, 로그 보존 기간, 실패 시 차단 방법을 정해야 한다. 셋째, 개발 환경과 운영 환경의 VPC 구성을 섞지 말아야 한다.

작은 파일럿에서는 고객 데이터나 결제 시스템처럼 위험한 대상보다 읽기 전용 지표, 사내 문서 검색, 낮은 권한의 업무 API부터 시작하는 편이 좋다. 이 단계에서 호출 성공률, 지연 시간, 권한 오류, 감사 로그 품질을 확인하면 이후 더 중요한 내부 시스템으로 넓힐지 판단할 수 있다.

참고한 공식 자료

• AWS ML Blog
• AgentCore docs
• AgentCore page

실제 도입 시나리오로 보면 무엇이 달라지나

가장 이해하기 쉬운 예시는 사내 주문 조회 에이전트입니다. 사용자가 "지난달 특정 고객사의 미배송 주문을 찾아줘"라고 묻는다면 에이전트는 CRM, 주문 DB, 물류 API, 권한 시스템을 함께 봐야 합니다. 이 리소스들은 대부분 공용 인터넷에 열어두면 안 됩니다. 기존에는 이를 위해 별도 프록시 서버를 만들거나, 에이전트가 호출할 수 있는 제한 API를 새로 만들어야 했습니다.

AgentCore Gateway의 VPC egress는 이 구조를 제품 기능으로 끌어올립니다. 에이전트가 사설망 안의 도구를 호출하되, 네트워크 경로와 보안 그룹, IAM 권한, 감사 로그를 클라우드 운영 방식으로 관리하게 만드는 접근입니다. 개발자는 모델 프롬프트만 설계하는 것이 아니라 "이 에이전트가 어떤 내부 도구에 접근할 수 있는가"를 인프라 코드와 운영 정책으로 설명해야 합니다.

운영자가 먼저 물어야 할 질문

이 기능이 있다고 해서 모든 내부 API를 에이전트에게 열어도 된다는 뜻은 아닙니다. 첫 질문은 "연결할 수 있는가"가 아니라 "연결해도 되는가"입니다. 에이전트는 일반 사용자보다 더 많은 맥락을 결합할 수 있으므로, 작은 권한도 예상보다 큰 정보 접근으로 이어질 수 있습니다. 따라서 도입 전에는 도구별 최소 권한, 호출 기록, 사용자별 권한 위임, 실패 시 차단 방법을 먼저 정해야 합니다.

확인 체크리스트

• 에이전트가 접근할 내부 리소스 목록을 최소 단위로 나눴는가?
• 서브넷과 보안 그룹이 업무 환경별로 분리되어 있는가?
• MCP tool별 읽기·쓰기 권한과 destructive action이 문서화되어 있는가?
• 호출 로그에서 사용자, tool, 대상 리소스, 실패 원인을 추적할 수 있는가?
• 장애가 났을 때 에이전트 기능만 끄고 기존 업무 시스템은 유지할 수 있는가?

이번 발표의 의미는 "AWS가 또 하나의 네트워크 옵션을 추가했다"가 아닙니다. AI 에이전트를 기업 내부 시스템에 넣으려면 모델보다 연결 경계가 더 중요해지는 단계에 들어섰다는 신호입니다.