기업용 에이전트 인프라는 샌드박스·네트워크·신원 세 경계로 나뉜다

10월 22일부터 24일까지 열리는 QCon 상하이 2026에서 'Agent as a Service' 트랙의 한 세션이 기업용 에이전트 인프라 구축 방법을 다룬다. 발표자는 SAIC(상하이자동차) 그룹 클라우드컴퓨팅센터 아키텍트 Fang Yuchen(方宇晨)이다. 그는 기업 환경에서 에이전트 인프라의 핵심 질문이 '에이전트를 어떻게 실행할 것인가'에서 '에이전트의 실행 경계와 신원 경계, 네트워크 경계를 어떻게 세울 것인가'로 옮겨갔다고 본다.

그가 제시하는 구조는 세 층으로 나뉜다. 먼저 컴퓨트 격리다. 에이전트는 모델이 생성한 알 수 없는 코드를 실행하므로 파일시스템과 커널 수준 격리가 함께 필요하고, 기존 컨테이너 격리만으로는 안전 경계를 감당하기 어렵다는 것이 그의 설명이다. 이를 위해 Kubernetes Agent Sandbox를 신뢰 실행 환경으로 두고 gVisor나 Kata 같은 런타임을 선택지로 쓴다. 웜 풀(warm pool), 템플릿, 유휴 자원 회수(idle reclaim), 스냅샷 같은 기능도 함께 언급됐다.

네트워크는 두 단계로 나뉜다. 3·4계층 경계는 OVN-Kubernetes로 테넌트별 독립 네트워크 도메인을 만들어 구성한다. Kubernetes NetworkPolicy만으로는 부족하다는 판단이다. 7계층은 Istio 서비스 메시와 테넌트 단위 이그레스 게이트웨이로 서비스·API 접근 평면을 만든다. 에이전트가 인터넷과 모델 API, 사내 시스템에 동시에 접근해야 하는 상황에서 접근 경로를 통제·관측 가능한 형태로 모으는 것이 목표다.

신원과 자격증명 관리는 Keycloak을 중심으로 한다. 에이전트마다 별도의 쿠버네티스 서비스 어카운트를 부여하고, Keycloak에 역할과 스코프, 오디언스를 설정한 뒤 짧은 수명의 JWT를 발급받아 쓴다. 실제 접근 허용 여부는 Istio의 AuthorizationPolicy가 결정한다. 외부 API 키는 에이전트 안에서 걷어내 중앙에서 관리하고, 이그레스 게이트웨이를 지날 때 교체하는 방식이다. 자격증명이 에이전트에 직접 들어가면 읽히거나 유출될 수 있다는 문제의식에서 나온 설계다.

배경에는 에이전트의 역할 변화가 있다. AI 애플리케이션이 콘텐츠 생성에서 자율 실행으로 넘어가면서 브라우저를 조작하고 MCP 도구와 내부 업무 시스템을 호출하는 사례가 늘고 있다. 실행 격리 요구가 높아지고, 접근 권한은 더 엄격하게 통제해야 하며, 자격증명 노출 위험도 커진다. 발표자는 이 구조가 쿠버네티스와 성숙한 오픈소스 기술 위에 올라가 있어 특정 벤더에 묶이지 않는다고 밝혔다.

개발자 입장에서 눈여겨볼 지점은 에이전트 보안을 프롬프트나 도구 권한 설정만으로 해결하지 않는다는 것이다. 실행 런타임, 네트워크 도메인, 토큰 발급과 교체라는 인프라 계층에서 경계를 나누고, 각 경계를 기존 쿠버네티스 도구로 구현한다. 사내에 에이전트를 여러 팀에 제공하려는 조직이라면 테넌트 격리와 단기 토큰, 이그레스 지점의 키 교체 같은 패턴을 참고할 만하다.

다만 이 내용은 컨퍼런스 세션에서 공개된 설계 제안이며, 실제 운영 환경에서 어느 규모로 검증됐는지는 원문에서 확인되지 않는다. gVisor와 Kata 중 무엇을 어떤 기준으로 고르는지, 웜 풀과 스냅샷을 운영할 때 드는 비용이 어느 정도인지 같은 세부 수치도 제시되지 않았다. 도입을 검토한다면 각 구성요소의 운영 부담을 별도로 따져봐야 한다.