AI agent가 실험용 스크립트에서 프로덕션 워크로드로 이동하면 배포 기준이 완전히 달라집니다. 로컬에서 잘 도는 LangChain, LlamaIndex, custom agent loop도 Kubernetes에 올리는 순간 container security, secret management, autoscaling, observability, tool permission 문제가 생깁니다.
최근 Cloud Native Now는 OCI와 OKE를 예로 Docker 기반 AI agent를 Kubernetes에 배포하는 흐름을 정리했습니다. Oracle Cloud를 쓰지 않는 팀에도 핵심은 유효합니다. AI agent는 일반 API 서버와 비슷하지만, 모델 호출, 도구 실행, 외부 API 접근, 긴 작업 상태를 다루기 때문에 몇 가지 운영 규칙을 더 가져야 합니다.
이 글은 EKS, GKE, AKS, OKE 어디서든 적용 가능한 Docker AI Agent 운영 체크리스트를 정리합니다.
첫 번째 기준은 non-root입니다. 프로덕션 agent container를 root로 실행하면 모델이 호출한 도구나 취약한 dependency가 컨테이너 내부에서 더 큰 권한을 갖습니다. Dockerfile 단계에서 전용 user를 만들고, Kubernetes securityContext에서 runAsNonRoot, allowPrivilegeEscalation false, readOnlyRootFilesystem true를 기본으로 두세요.
두 번째는 minimal base image입니다. python:3.11보다 python:3.11-slim이 낫고, 가능하면 distroless까지 검토할 수 있습니다. 이미지가 작을수록 CVE 표면과 cold start 시간이 줄어듭니다. pip install --no-cache-dir 같은 기본 hygiene도 지켜야 합니다.
세 번째는 health check입니다. Agent는 내부적으로 모델 API나 tool server에 의존하므로 단순 process alive만으로는 부족합니다. /health는 프로세스 상태를, /ready는 필수 dependency 접근 가능 여부를 확인하게 나누는 편이 좋습니다. 모델 provider 장애까지 readiness에 넣을지는 신중해야 합니다. 외부 모델 장애 때문에 모든 pod가 endpoint에서 빠지면 traffic blackhole이 생길 수 있습니다.
AI agent는 모델 API key, vector DB credential, SaaS token, MCP server token을 많이 다룹니다. 이 값을 Docker image나 Git에 들어가는 Kubernetes manifest에 넣는 순간 사고가 납니다. Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, OCI Vault 중 하나를 사용하고, pod에는 runtime에 주입하세요.
권장 패턴은 두 가지입니다. 작은 팀은 External Secrets Operator처럼 cluster secret으로 동기화하는 방식이 단순합니다. 보안 요구가 높은 팀은 workload identity를 사용해 pod가 secret manager에서 직접 읽도록 설계합니다. 이 경우 service account와 IAM role 매핑이 중요합니다.
또한 secret rotation을 전제로 코드를 작성해야 합니다. 장기 실행 agent가 시작 시점에만 key를 읽으면 rotation 후 장애가 납니다. 일정 주기로 key를 다시 읽거나, 짧은 TTL token을 발급받는 구조가 더 안전합니다.
AI agent는 외부 API를 많이 부릅니다. 문제는 “모델이 어떤 도구를 호출할 수 있는가”와 “pod가 어떤 네트워크로 나갈 수 있는가”가 다를 때 생깁니다. 애플리케이션 코드에서 tool allowlist를 둬도, pod가 인터넷 전체로 나갈 수 있으면 우회 가능성이 남습니다.
Kubernetes NetworkPolicy 또는 cloud firewall로 egress를 제한하세요. 모델 endpoint, vector DB, 내부 tool gateway, 필요한 SaaS API만 허용하는 방식입니다. MCP server를 별도 workload로 띄운다면 agent pod에서 해당 service로만 접근하게 합니다. 내부 관리자 API나 metadata endpoint 접근은 차단해야 합니다.
Tool gateway 패턴도 추천합니다. Agent가 GitHub, Slack, Jira, CRM을 각각 직접 호출하지 않고 중앙 gateway에 요청하게 하면 권한, 승인, audit, rate limit을 한 곳에서 처리할 수 있습니다. Kubernetes에서는 gateway를 별도 service로 두고, agent namespace에서 gateway로만 egress를 허용할 수 있습니다.
일반 API 서버는 요청을 받고 바로 응답합니다. 하지만 agent는 5분, 30분, 몇 시간 동안 일할 수 있습니다. Kubernetes pod는 언제든 재시작될 수 있으므로 작업 상태를 메모리에만 두면 안 됩니다.
긴 작업은 job_id를 만들고 상태를 외부 저장소에 기록해야 합니다. 최소 필드는 status, current_step, last_tool_call, checkpoint_payload, retry_count, created_at, updated_at입니다. Redis, Postgres, DynamoDB 중 팀 스택에 맞는 것을 쓰면 됩니다. 중요한 것은 pod가 죽어도 다른 pod나 worker가 이어받을 수 있어야 한다는 점입니다.
Queue도 필요합니다. HTTP 요청 안에서 agent loop를 끝까지 돌리면 timeout과 retry 문제가 생깁니다. API는 작업을 생성하고, worker가 queue에서 실행하고, 클라이언트는 polling이나 websocket으로 상태를 보는 구조가 안정적입니다.
AI agent 비용은 모델 token뿐 아니라 pod runtime, tool API, vector search, browser automation, 로그 저장 비용으로 나뉩니다. Kubernetes autoscaling도 CPU만 보면 부족합니다. Agent workload는 CPU가 낮아도 모델 응답을 기다리며 오래 점유될 수 있습니다.
HPA 기준에는 queue depth, active job count, average job duration 같은 지표를 넣는 편이 좋습니다. KEDA를 쓰면 queue 기반 scaling이 편합니다. 또한 concurrency limit을 둬야 합니다. 한 사용자가 100개 agent job을 만들 수 있으면 모델 비용과 외부 API quota가 순식간에 터집니다.
캐시도 중요합니다. 같은 문서 요약, 같은 embedding, 같은 검색 결과를 반복 호출하지 않도록 request hash 기반 cache를 둡니다. 다만 사용자별 권한이 다른 데이터는 공유 캐시하면 안 됩니다. tenant_id와 permission scope를 cache key에 포함하세요.
Agent 장애의 원인은 모델보다 tool에 있는 경우가 많습니다. 권한 실패, rate limit, schema 변경, timeout, partial write, 외부 API 장애가 흔합니다. 따라서 로그와 trace는 tool call 단위로 남겨야 합니다.
최소 지표는 agent_job_duration, model_latency, tool_latency, tool_error_rate, approval_wait_time, retry_count, token_usage, cost_estimate, queue_lag입니다. Trace에는 job_id, user_id, tenant_id, tool_name, external_call 여부, approval_id를 넣습니다. 민감한 prompt와 response 전문은 저장 정책을 따로 정하고 masking하세요.
AI agent 배포는 “컨테이너로 감싸서 올리기”가 아닙니다. 권한 있는 자동화를 클러스터에 넣는 일입니다. 일반 API 서버보다 더 엄격한 secret, network, state, approval, observability 기준이 필요합니다. 이 기준을 먼저 잡아두면 특정 클라우드나 프레임워크가 바뀌어도 운영 구조는 흔들리지 않습니다.
