AI 에이전트 사내망 연결 전, 5칸 egress 계약 체크리스트

핵심 요약

• 사내망 연결은 네트워크 개통이 아니라 업무 경로별 책임을 정하는 일입니다.
• 같은 에이전트라도 사내 DB 읽기, 외부 SaaS 호출, MCP 도구 실행은 데이터와 실패 영향이 달라 별도 판단이 필요합니다.
• 허용 목록만으로는 부족합니다. 요청 ID와 agent/task ID, 허용·차단 사유, 경로 소유자를 함께 남겨야 합니다.
• 목적 또는 소유자가 비어 있거나, 키의 범위·만료·회수 방법이 없으면 연결을 보류하는 편이 안전합니다.

왜 ‘사내망에 연결됐다’는 말만으로는 부족할까요?

AI 에이전트는 한 번의 작업 안에서 문서를 읽고, 사내 데이터를 조회하고, 외부 서비스를 호출하며, 도구 서버를 실행할 수 있습니다. 이때 “사내 VPC에 연결했다”는 설명은 출발점일 뿐입니다. 실제 검토에서는 어떤 작업이 어떤 데이터를 어느 방향으로 보내는지, 실패했을 때 누가 끊고 무엇을 남길지를 확인해야 합니다.

Google Cloud의 Agent Gateway 문서는 VPC 연결을 별도 템플릿과 구성 조건으로 다룹니다. 이는 관리형 에이전트 연결에도 네트워크 경로와 구성 단위가 있다는 제품 사실을 보여 줍니다. 반면 OpenAI의 Agents 문서는 관리형 실행 환경, SDK, 직접 통합에서 실행 위치와 도구 실행의 책임이 달라질 수 있음을 설명합니다. 두 자료를 함께 읽으면 특정 제품이 더 안전하다는 결론이 아니라, 연결 방식이 달라지면 검토해야 할 책임도 달라진다는 실무 원칙을 얻을 수 있습니다.

5칸 egress 계약: 경로를 문장 대신 운영 가능한 기록으로 바꾸기

egress 계약은 외부 또는 경계 밖 대상에 닿는 한 경로를 다섯 칸으로 기록하는 간단한 양식입니다. 보안팀의 거대한 정책 문서를 대체하려는 도구가 아닙니다. 배포 승인, 변경 검토, 장애 대응에서 빠지기 쉬운 정보를 같은 순서로 확인하기 위한 작업용 카드입니다.

1. 목적: 이 호출이 완료해야 하는 업무 결과를 한 문장으로 적습니다. “도구 사용”이 아니라 “고객 요청 번호로 배송 상태를 읽어 답변 초안을 만든다”처럼 씁니다.
2. 대상·방향: 출발 주체, 목적지, 읽기 또는 쓰기, 전송되는 데이터 분류를 적습니다. 내부 조회와 외부 전송을 같은 경로로 뭉치지 않습니다.
3. 자격증명: 어떤 서비스 계정 또는 토큰을 쓰는지, 최소 권한인지, 만료와 회수 담당자가 있는지 확인합니다. 공유 키 하나를 여러 도구가 쓰는 경우에는 보류 사유가 될 수 있습니다.
4. 승인·차단: 정상 허용 조건과 즉시 차단 조건을 적습니다. 예를 들어 쓰기 호출은 별도 승인 토큰이 없으면 실패하도록 만들고, 허용되지 않은 목적지는 기본적으로 막습니다.
5. 관측·소유: 요청 ID, agent/task ID, 목적지, 결과, 허용·차단 사유를 어디에 남기는지와 책임자를 정합니다. 로그는 모으는 것만으로 충분하지 않고, 누가 확인하고 끊을지까지 이어져야 합니다.

사내 DB·외부 API·MCP를 같은 표로 판단해 보겠습니다

다음은 고객 지원 에이전트가 세 가지 연결을 동시에 요구하는 상황의 예시입니다. 조직의 실제 데이터 등급과 정책이 우선이지만, 표의 빈칸은 승인 전에 해결해야 할 질문을 드러내 줍니다.

이 예시에서 가장 위험한 상태는 기술적으로 연결은 되지만 책임 칸이 비어 있는 경우입니다. 예를 들어 외부 API 키가 만료되어도 누가 교체하는지 없고, 실패한 요청을 어떤 작업이 만들었는지 찾을 수 없다면 운영 비용은 시간이 갈수록 커집니다. 연결 수를 줄이는 것보다, 경로별 책임을 좁히고 추적 가능하게 만드는 것이 먼저입니다.

허용, 보류, 차단을 가르는 네 가지 실패 조건

배포 전에는 작게 확인하고, 장애 때는 경로만 먼저 끊으세요

배포 전 체크리스트

1. 경로별 목적, 대상, 방향, 데이터 범위를 작성합니다.
2. 자격증명의 범위, 만료일, 회수 담당자를 확인합니다.
3. 외부 전송과 쓰기 작업이 조건 미충족 시 기본적으로 실패하도록 설계합니다.
4. 요청 ID, agent/task ID, 허용·차단 사유가 같은 기록에서 연결되는지 시험합니다.
5. 경로 소유자, 비상 차단 방법, 다음 재검토 날짜를 명시합니다.

장애가 발생했을 때의 순서

1. 문제가 난 경로만 즉시 차단합니다. 조사 전에 전체 기능을 넓게 열어 두지 않습니다.
2. 영향을 받은 agent/task ID, 목적지, 시간, 허용 또는 차단 사유를 보존합니다.
3. 자격증명을 회수하거나 범위를 축소합니다. 새 키를 서둘러 배포하기 전에 기존 경계가 왜 실패했는지 확인합니다.
4. 계약의 예외와 탐지 공백을 업데이트합니다.
5. 가장 작은 재현 사례로 다시 검증한 뒤에만 경로를 재개합니다.

기존 운영 문서와 어떻게 연결하면 좋을까요?

egress 계약은 에이전트의 실행 경계를 정리하는 문서와 함께 쓰면 더 효과적입니다. 먼저 에이전트 실행 공간과 권한 경계를 정리한 뒤, 외부 도구는 단계적으로 검증하는 방법으로 좁게 시험해 보세요. 원격 작업을 넘겨받는 팀이라면 세션 인수 기록에도 경로 소유자와 차단 상태를 남기는 편이 좋습니다.

이 프레임이 자동으로 보장하지 않는 것

VPC 연결, 허용 목록, MCP 연결, 관리형 실행 환경은 각각 유용한 통제 수단일 수 있습니다. 그러나 이 중 어느 하나도 조직의 데이터 분류, 보존 규칙, 계약상 의무, 접근 정책을 대신하지는 않습니다. 제품별 지원 조건과 구성 제약은 공식 문서에서 다시 확인해야 하며, 실제 승인 기준은 조직의 보안·법무·데이터 책임자와 맞춰야 합니다.

특히 이 글의 예시 표는 배포 판단을 돕는 틀입니다. 모든 조직에 동일한 로그 보존 기간이나 네트워크 정책을 처방하는 규칙은 아닙니다.

자주 묻는 질문

VPC에 연결하면 외부 경로 검토는 끝난 것 아닌가요?

아닙니다. VPC 연결은 네트워크 경로를 구성하는 한 요소입니다. 해당 경로가 어떤 업무를 위해 어떤 데이터를 어디로 보내는지, 어떤 자격증명과 차단 조건을 쓰는지는 별도로 확인해야 합니다.

허용 목록만 잘 관리하면 충분한가요?

허용 목록은 목적지를 제한하는 데 도움이 됩니다. 다만 같은 목적지라도 읽기와 쓰기, 사용하는 키, 요청을 만든 작업, 책임자가 다를 수 있습니다. 그래서 허용 목록은 계약의 대상·방향 칸을 보완하지만 나머지 칸을 대체하지는 못합니다.

MCP 도구 서버는 내부에 있으니 더 단순하게 봐도 될까요?

아닙니다. 내부 서버라도 도구가 어떤 입력을 받고 어떤 작업을 수행하며, 쓰기 작업에 누구의 승인이 필요한지 정해야 합니다. 내부라는 이유만으로 범위가 넓은 권한을 부여하지 않는 편이 좋습니다.

처음에는 어떤 경로부터 계약을 만들면 좋을까요?

외부 전송, 쓰기 작업, 민감한 데이터 조회처럼 실패 영향이 큰 경로부터 시작하세요. 한 경로를 다섯 칸으로 완성한 뒤 같은 양식을 다른 경로에 확장하면 됩니다.

마무리: 연결 요청을 ‘운영 가능한 약속’으로 바꾸세요

AI 에이전트의 연결 요청은 빠르게 늘어나지만, 모든 연결을 넓게 허용할 필요는 없습니다. 각 경로의 목적과 책임을 다섯 칸으로 나누면 승인 판단은 더 분명해지고, 장애 때 영향 범위도 더 빨리 좁힐 수 있습니다. 다음 연결 요청에서는 먼저 표의 빈칸부터 찾아보세요. 빈칸이 남아 있다면, 아직 연결을 열 때가 아닐 수 있습니다.

참고 자료

• Google Cloud, Set up Agent Gateway — Agent Gateway의 VPC 연결 템플릿과 구성 조건을 확인할 수 있는 공식 문서입니다.
• Gemini Enterprise Agent Platform release notes — 기능 변화와 적용 시점은 이 공식 릴리스 노트에서 최신 상태를 확인할 수 있습니다.
• OpenAI API, Agents guide — 에이전트 실행 환경과 도구 실행 책임의 차이를 살펴볼 수 있는 공식 문서입니다.