[기술해설] Agentic AI 시대의 Kubernetes 인프라 활용: Agent Sandbox 입문

Tech Story/DevOps & Container

[기술해설] Agentic AI 시대의 Kubernetes 인프라 활용: Agent Sandbox 입문

 

kt cloud Container Service팀 박지선 님

 

요약 SUMMARY

이 글에서는 Kubernetes Agent Sandbox의 주요 CRD와 AI 에이전트의 상태 유지·격리·유휴 상태 관리 방식을 다룹니다.
StatefulSet 방식과의 차이, WarmPool을 이용한 사전 준비 및 런타임 선택 시 주의사항을 정리합니다.

#AgentSandbox #Kubernetes #AgenticAI #CRD #SandboxWarmPool

하루가 다르게 AI 워크로드의 패러다임이 빠르게 바뀌고 있습니다.

 

초기 AI 인프라(AI v1으로 칭함)는 단순했습니다. 짧은 추론 요청 처리만 했으면 됐었으나 최근 등장한 자율형 AI 에이전트(AI v2으로 칭함)는 전혀 다른 특성을 가집니다.

구분 AI v1 (추론 서비스) AI v2 (자율 에이전트)

의미

 API 엔드포인트 뒤에 추론 모델 서빙 스스로 판단하고 행동하는 에이전트

상태

stateless stateful

실행 패턴

 요청 → 응답 → 종료 계속 실행하며 도구 호출, 상태 유지

활동

지속적 상태 유지, 고유 ID, 격리 환경 필요

신뢰 수준

내부 코드 외부·비신뢰 코드 실행 가능

 

이 패러다임 변화는 인프라 선택에도 직접적인 영향을 미칩니다.

 

Kubernetes를 인프라로 한 AI v1 서비스를 하려면 심플했습니다. 무상태 추론 Pod를 Deployment로 올리고, HPA로 수평 확장하면 그만이었습니다.

 

하지만 AI v2 에이전트를 기존 Kubernetes 리소스인 StatefulSet, Service, PVC 조합으로 운영하려 하면 운영 복잡도가 급격히 올라갑니다. 이 문제를 해결하기 위해 Kubernetes SIG Apps는 Agent Sandbox 프로젝트를 공개했습니다.

Agent Sandbox: 격리되고 상태를 유지하는 싱글톤 워크로드를 쉽게 관리하기 위한 Kubernetes CRD 및 컨트롤러

 

Google을 포함한 여러 기업에서 관심을 가지고 있는 이 Agent Sandbox 프로젝트에 대해 소개해 보겠습니다.

 

Namespace 격리로는 부족한 이유

 

"Kubernetes는 Namespace로 이미 격리되어 있지 않나?"라는 의문이 자연스럽게 나옵니다. 결론부터 말하면, Namespace 격리와 Agent Sandbox가 해결하는 문제는 레벨이 다릅니다.

 

Namespace는 Kubernetes API 레벨의 논리적 분리입니다. RBAC, NetworkPolicy로 "누가 어떤 리소스에 접근할 수 있는가"를 제어합니다. 이 모든 격리는 컨테이너 안의 코드를 신뢰한다는 전제 위에 있습니다.

 

AI 에이전트는 이 전제를 깨뜨립니다. AI 에이전트처럼 외부에서 들어온 임의의 코드를 실행하는 경우가 많기 때문입니다.

사용자 입력 → "이 Python 코드 실행해줘" → 에이전트 → exec()
                                                   ↓
                                        악성 코드가 커널 취약점 exploit
                                                   ↓
                                        Namespace와 무관하게 호스트 탈출 가능

컨테이너는 호스트 OS 커널을 공유하기 때문에, Namespace 격리만으로는 커널 레벨 탈출을 막을 수 없습니다.

 

이를 해결하기 위해 커널 격리를 제공하는 gVisor 또는 Kata Containers를 선택적으로 사용할 수 있도록 Agent Sandbox는 설계되었습니다.

 

단, Agent Sandbox 자체는 CRD + 컨트롤러이며 기본 런타임은 일반 runc입니다. 비신뢰 코드를 실행하는 경우에만 runtimeClassName으로 gVisor/Kata를 지정합니다.

# 기본 (신뢰 코드)
runtimeClassName 미지정 → runc (일반 컨테이너)

# 비신뢰 코드 실행 시 (보안 강화)
runtimeClassName: gvisor  → 유저스페이스 커널로 호스트 완전 격리
runtimeClassName: kata    → 경량 VM으로 하드웨어 수준 격리

 

2026년 3월 기준 최신 릴리스는 v0.4.2이며, 아직 v1alpha1 단계의 오픈소스 프로젝트 입니다.

Agent Sandbox 상세 리소스 설명

API 정의

 

Agent Sandbox는 크게 두 개의 API 그룹으로 구성됩니다.

 

Core API (agents.x-k8s.io/v1alpha1)

리소스 역할
Sandbox 단일 에이전트 실행 환경 (메인 리소스)
SandboxTemplate 재사용 가능한 Sandbox 정의 템플릿

 

Extensions API (extensions.agents.x-k8s.io/v1alpha1)

리소스 역할
SandboxWarmPool 콜드 스타트 방지용 사전 프로비저닝 풀
SandboxClaim WarmPool에서 Sandbox를 즉시 할당 요청
  • 콜드 스타트(Cold Start): Pod가 요청을 받고 실제로 처리 가능한 상태가 되기까지 걸리는 지연 시간입니다. AI 에이전트는 대부분의 시간을 유휴(idle) 상태로 보냅니다. 리소스 절약을 위해 Scale-to-Zero(Pod=0)로 내리면, 다음 요청이 올 때마다 이 과정을 처음부터 반복합니다.

 

주요 용어 정의

 

Sandbox: AI 에이전트 하나를 실행하는 최소 단위입니다.

 

다음과 같은 특징 3가지를 가집니다.

  • 안정적 네트워크 ID: metadata.name 기반의 고정 DNS 호스트명 제공 (StatefulSet와 동일)
  • 격리 runtime 지원: gVisor(runsc), Kata Containers를 runtimeClassName으로 선택 가능
  • Scale-to-Zero: 유휴 상태 에이전트를 0으로 축소하고 상태를 보존한 채 재개 가능

단일 Sandbox 대신 상위 Controller 를 생성하여 control할 수도 있습니다.

용어 기능 Kubernetes 유사 리소스
SandboxTemplate 여러 Sandbox에서 공통으로 사용할 컨테이너 스펙을 정의 -
SandboxWarmPool Template 보고 Sandbox N개 자동 생성·유지
Cold Start의 지연을 제거		 Deployment와 yaml 형식 유사
SandboxClaim SandboxWarmPool에서 Sandbox 하나 할당 요청 PV(SandboxWarmPool) ↔ PVC(SandboxClaim) 관계와 유사

[기술해설] Agentic AI 시대의 Kubernetes 인프라 활용: Agent Sandbox 입문
출처: https://github.com/kubernetes-sigs/agent-sandbox

 

 

Agent Sandbox 사용

Agent Sandbox가 기존 StatefulSet 방식과 어떻게 다른지 비교합니다.

 

기존 방식 예시 (StatefulSet + Service + PVC)

# 에이전트 하나를 위해 3가지 리소스가 필요
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-agent
spec:
  replicas: 1
  serviceName: my-agent
  selector:
    matchLabels:
      app: my-agent
  template:
    metadata:
      labels:
        app: my-agent
    spec:
      containers:
      - name: agent
        image: my-agent:latest
        volumeMounts:
        - name: data
          mountPath: /workspace
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi
---
apiVersion: v1
kind: Service
metadata:
  name: my-agent
spec:
  clusterIP: None
  selector:
    app: my-agent
  ports:
  - port: 8080

리소스 3개를 동기화해서 관리해야 하고, 강한 격리(gVisor/Kata)를 추가하려면 RuntimeClass 설정까지 별도로 필요합니다.

 

Agent Sandbox 방식

 

단일 Sandbox 리소스 생성해서 사용하는 방식과, SandboxTemplate 이용하는 방식으로 나뉩니다.

 

SandboxTemplate 를 이용한 생성은 SandboxTemplate 생성 → SandboxWarmPool 생성 (replicas: 3) → SandboxClaim 생성 (1개) 순서대로 진행하여 사용합니다.

 

SandboxTemplate 정의

 

재사용 가능한 에이전트 템플릿을 작성합니다.

apiVersion: agents.x-k8s.io/v1alpha1
kind: SandboxTemplate
metadata:
  name: python-agent-template
  namespace: default
spec:
  podTemplate:
    spec:
      containers:
      - name: agent
        image: python:3.12-slim
        ports:
        - containerPort: 8888
        readinessProbe:
          httpGet:
            path: /
            port: 8888
          initialDelaySeconds: 0
          periodSeconds: 1
        livenessProbe:
          httpGet:
            path: /
            port: 8888
          initialDelaySeconds: 2
          periodSeconds: 10
        resources:
          requests:
            cpu: "250m"
            memory: "512Mi"
            ephemeral-storage: "512Mi"
        # gVisor 격리 사용 시 아래 주석 해제
        # runtimeClassName: gvisor
      restartPolicy: Never

 

WarmPool 구성

  • 지정한 수만큼 Sandbox를 미리 생성해서 대기시켜 두는 풀입니다. 새 요청이 들어올 때 Pod 시작 오버헤드(~1초)를 제거하는 것이 목적입니다.
apiVersion: extensions.agents.x-k8s.io/v1alpha1
kind: SandboxWarmPool
metadata:
  name: python-agent-pool
  namespace: default
spec:
  updateStrategy:
    type: Recreate
  replicas: 3  # 3개 미리 준비
  sandboxTemplateRef:
    name: python-agent-template # 이미 생성한 SandboxTemplate 사용

 

SandboxClaim으로 즉시 할당

  • WarmPool에서 미리 준비된 Sandbox를 즉시 할당 요청하는 리소스입니다.
apiVersion: extensions.agents.x-k8s.io/v1alpha1
kind: SandboxClaim
metadata:
  name: my-claim
  namespace: default
spec:
  sandboxTemplateRef:
    name: python-agent-template

 

주의사항

  1. Kubernetes 버전 요구사항

Agent Sandbox는 Kubernetes 1.35 기준으로 빌드되었으며, client-go의 N-3 호환성 정책에 따라 실질적으로 1.32 미만 클러스터에서는 동작을 보장하지 않습니다.

  1. gVisor / Kata Containers 런타임 미설치 시

runtimeClassName: gvisor를 지정했는데 노드에 gVisor가 설치되어 있지 않으면 Pod가 Pending 상태에서 멈춥니다.

kubectl describe sandbox my-agent
# Events:
#   Warning  FailedScheduling  No nodes available with runtime class gvisor

해결 방법: runtimeClassName 필드를 제거하거나 노드에 gVisor를 설치합니다. KinD 환경에서는 기본적으로 runc 사용을 권장합니다.

마무리

Agent Sandbox는 Kubernetes를 AI 에이전트 전용 런타임으로 확장하는 공식 프로젝트입니다.

 

아직 v0.4.2, v1alpha1 단계이지만 Google Cloud(GKE), Red Hat 등 주요 벤더가 공식 지원을 시작했고 커뮤니티 활동도 활발합니다.

 

다음편에서는 Agent Sandbox를 직접 설치하고, 여러 AI Agent를 Agent Sandbox위에서 동작시키는 hands on을 해보겠습니다.

 

 

kt cloud 클라우드 플랫폼 서비스 바로가기 배너

자주 묻는 질문 FAQ

Q AI 에이전트를 Kubernetes에서 실행할 때 StatefulSet이 부족한 이유는 무엇인가?
A AI 에이전트는 장기 실행·싱글톤·유휴 상태가 잦은 특성을 가지며, 이를 위해 설계된 Sandbox CRD가 필요합니다.

관련 / 출처 REFERENCES

🔗 ↗
kt cloud 클라우드 서비스 바로가기
kt cloud 데이터센터(IDC) 서비스 바로가기
kt cloud AI 서비스 바로가기
저작자표시 비영리 변경금지 (새창열림)

'Tech Story > DevOps & Container' 카테고리의 다른 글

[플랫폼설계] DevOps에서 Platform Engineering으로: kt cloud의 여정  (0) 2026.10.02
[활용사례] DevOps 엔지니어가 주목하는 MCP 생태계와 kt cloud PLATFORM 적용기  (0) 2026.09.23
[구현사례] 신규 프로젝트를 복제 한 번으로 시작하기: 보일러플레이트 템플릿 표준화  (0) 2026.09.22
[기술사례] 대규모 Kubernetes 환경의 중단 없는 진화를 위한 선택: kt cloud의 Chkk 기반 클러스터 관리  (0) 2026.08.24
[사례연구] 사내 개인용 개발환경 이미지 실험기 2부: 만들면서 마주친 것들과 풀어간 방법  (0) 2026.08.14

'Tech Story/DevOps & Container'의 다른글

  • 현재글[기술해설] Agentic AI 시대의 Kubernetes 인프라 활용: Agent Sandbox 입문

관련글