프로덕션 에이전트를 만들다 보면 가장 먼저 부딪히는 현실 문제가 있습니다. 모델은 잘 붙었는데, 정작 에이전트가 접근해야 하는 대상이 사설 API, 내부 데이터베이스, VPC 뒤쪽 서비스라는 점입니다. Amazon의 공식 글 Configuring Amazon Bedrock AgentCore Gateway for secure access to private resources(https://aws.amazon.com/blogs/machine-learning/configuring-amazon-bedrock-agentcore-gateway-for-secure-access-to-private-resources/)는 이 문제를 꽤 실무적으로 다룹니다. 요지는 간단합니다. 에이전트가 내부 도구를 써야 한다고 해서, 모든 MCP 서버나 API를 공용 인터넷으로 노출시키는 방식은 이제 그만두자는 겁니다. Bedrock AgentCore Gateway의 VPC egress 구조를 이용하면 사설 네트워크 안에서 필요한 리소스만 제한적으로 연결할 수 있습니다.
많은 팀이 에이전트 도입 초기에 가장 쉬운 길을 택합니다. 내부 API 앞단에 임시 퍼블릭 엔드포인트를 만들고, 토큰 인증만 붙인 뒤 연결하는 방식입니다. 데모는 빨리 됩니다. 문제는 운영에 올리는 순간 보안팀과 네트워크팀이 바로 막는다는 겁니다. 그게 맞습니다.
에이전트는 일반 서비스보다 더 넓은 도구 접근이 필요할 때가 많습니다. 검색, 조회, 쓰기, 배포, 티켓 시스템, 사내 문서 등 여러 시스템에 손을 뻗기 때문입니다. 그래서 네트워크 경계 설계가 더 중요합니다. 연결 편의성만 보고 퍼블릭 노출을 늘리면, AI 도입보다 공격면 확대가 먼저 옵니다.
AWS 글은 AgentCore Gateway가 VPC 내부 리소스에 접근할 때 Resource Gateway, Resource Configuration, 서비스 네트워크 연결 개념을 사용한다고 설명합니다. 이름은 복잡해 보여도 설계 포인트는 단순합니다.
즉 “에이전트가 내부망에 들어온다”가 아니라, “에이전트가 특정 사설 엔드포인트에 제한적으로 도달한다”로 생각해야 합니다.
글에서 말하는 managed 모드는 설정이 단순합니다. VPC ID, 서브넷, 보안그룹을 주면 AgentCore가 Resource Gateway를 대신 관리합니다. 이 방식은 빠르게 시작하기 좋습니다.
특히 이런 경우에 맞습니다.
장점은 운영 부담이 적다는 점입니다. 단점은 가시성과 세밀한 통제가 제한된다는 점입니다. 네트워크를 많이 다뤄본 팀이라면 “쉽지만 블랙박스가 늘어난다”고 느낄 수 있습니다.
반대로 self-managed Lattice resource 모드는 더 많은 제어권을 줍니다. 리소스 게이트웨이 생성, 리소스 구성, 교차 계정 연결, AWS RAM 공유까지 직접 다룹니다.
이 방식이 필요한 상황은 보통 아래 같습니다.
쉽게 말해 managed는 속도, self-managed는 통제입니다. 둘 중 무엇이 좋은지가 아니라, 조직의 보안 거버넌스 수준에 맞춰 선택해야 합니다.
글이 강조하듯 Resource Configuration은 단일 리소스 범위로 접근 대상을 좁히는 게 핵심입니다. 사설 API 하나만 필요하면 그 API만 열어야지, 서브넷 전체를 사실상 신뢰 구역으로 만들면 안 됩니다.
에이전트가 네트워크상 도달 가능하다고 해서, 그 리소스에 무엇이든 하게 두면 안 됩니다. MCP 서버 내부 권한, API 토큰 범위, 읽기/쓰기 구분은 별도로 제어해야 합니다. 네트워크와 애플리케이션 권한을 같이 설계해야 합니다.
사설 리소스 접근은 실패했을 때 디버깅이 어렵습니다. 네트워크 경로, 보안그룹, 엔드포인트 정책, 애플리케이션 인증 실패가 뒤섞이기 때문입니다. 연결 전에 로그 수집 지점을 정하지 않으면 장애가 나도 원인 추적이 오래 걸립니다.
MCP는 도구 표준이지 보안 솔루션이 아닙니다. 사설망 안에 두는 건 출발점일 뿐입니다. 호출 가능한 툴 목록, 입력 검증, 자격증명 위임 범위, 감사 로그를 꼭 같이 설계해야 합니다.
AWS 글은 세 가지 예시를 듭니다. 프라이빗 API Gateway, EKS 위 MCP 서버, 사설 REST API입니다. 실무에서는 읽기 전용 도구부터 시작하는 게 좋습니다.
예를 들면 이런 순서가 안전합니다.
처음부터 배포 API나 데이터 수정 API를 연결하면 테스트 범위가 커지고, 보안 검토도 길어집니다.
첫째, 에이전트가 어떤 내부 리소스에 접근해야 하는지 목록을 좁히세요. 둘째, 각 리소스가 읽기인지 쓰기인지 구분하세요. 셋째, 네트워크 연결과 애플리케이션 권한을 별도 표로 관리하세요. 넷째, 실패 로그를 어느 계층에서 볼지 정하세요. 다섯째, managed와 self-managed 중 어느 쪽이 조직 구조에 맞는지 먼저 결론 내리세요.
결론적으로 이 글의 핵심은 복잡한 AWS 설정법 자체가 아닙니다. 에이전트를 진짜 업무 시스템에 연결하려면, 공개 인터넷 우회가 아니라 최소 노출·최소 권한·명시적 연결이라는 원칙으로 가야 한다는 점입니다. 에이전트 기능보다 네트워크 구조가 먼저 운영 품질을 결정하는 순간이 분명히 옵니다. 그때 이 아키텍처 고민을 미루면 나중에 더 크게 돌아옵니다.
