AI 에이전트의 급격한 부상은 엔지니어들이 클라우드 인프라와 리소스 관리를 생각하는 방식을 근본적으로 변화시키고 있습니다. Kubernetes는 10년 동안 컨테이너 오케스트레이션(Container Orchestration)의 표준 역할을 해왔지만, 그 설계는 현대의 자율 소프트웨어 에이전트에게 요구되는 장기 실행형의 복잡한 추론 루프(Reasoning Loops)보다는 수명이 짧고 상태가 없는(Stateless) 요청에 더 유리합니다.

상태가 없는 요청(Stateless Requests)을 넘어선 진화

지난 10년 동안 기술 산업은 Kubernetes를 소프트웨어를 실행하기 위한 결정적인 솔루션으로 간주했습니다. Kubernetes는 컨테이너를 성공적으로 조직화하고 플랫폼 팀이 서비스를 수평적으로 확장(Scale Horizontally)할 수 있는 통일된 언어를 제공했습니다. 하부 서버의 복잡성을 숨김으로써 개발자들이 하드웨어보다는 서비스에 집중할 수 있게 해주었습니다. 대부분의 현대적 클라우드 시스템은 HTTP 요청의 짧고 일회적인 특성을 처리하기 위해 이 모델에 의존합니다.

클라우드 네이티브(Cloud-native) 성장의 시대는 작업 단위가 짧고 교체 가능하다는 가정에 의존했습니다. 사용자가 요청을 트리거하면 서비스가 이를 처리하고, 컨테이너는 즉시 다음 작업으로 넘어가거나 종료됩니다. Kubernetes 스케줄러(Schedulers)는 이러한 특정 주기에 맞춰 구축되었으며, 메모리나 CPU 사용량을 기반으로 한 빈 패킹(Bin-packing)과 오토스케일링(Autoscaling)을 최적화합니다. 프로세스가 실패하면 시스템은 단순히 이를 다른 곳에서 재스케줄링합니다.

이 표준 모델은 현대 AI 워크로드의 요구사항을 충족하는 데 실패하고 있습니다. 에이전트는 장기간 지속되는 상태 유지형(Stateful) 프로세스로 작동합니다. 에이전트는 문제를 통해 추론하고, 외부 도구와 상호작용하며, 이전 결정에 따라 코드를 실행합니다. 단일 작업이 몇 시간 동안 지속될 수 있으며, 다양한 외부 시스템을 포함하고 이후 단계를 위해 접근 가능한 상태로 유지되어야 하는 데이터를 생성할 수도 있습니다.

이러한 변화로 인해, 컴퓨팅 계층(compute layer)은 에이전트 시맨틱스(agent semantics)를 지원할 수 있도록 진화해야 합니다. Kubernetes 커뮤니티는 이미 기존의 프리미티브(primitives)가 이러한 새로운 현실에 잘 부합하지 않는다는 점을 인식했습니다. 2026년 초, 메인테이너(maintainers)들은 새로운 추상화 계층으로 에이전트 샌드박스(Agent Sandbox)를 도입했습니다. 이러한 움직임은 전통적인 오케스트레이션(orchestration) 도구의 제작자들조차 자율 에이전트(autonomous agents)에게는 다른 실행 기반이 필요하다는 것을 깨달았음을 시사합니다.

전통적인 컨테이너(containers) 내에서 이러한 워크로드를 관리하는 것은 상당한 마찰을 초래합니다. 전통적인 시스템은 에이전트가 외부 모델의 응답을 기다리고 있을 경우, 실행 중인 에이전트를 종종 유휴 프로세스(idle process)로 간주합니다. 이는 부적절한 리소스 할당과 높은 실패율로 이어집니다. 이제 개발자들은 프로덕션 환경에서 신뢰할 수 있는 성능을 보장하기 위해, 단순한 요청-응답(request-response) 사이클보다 실행의 연속성(execution continuity)을 우선시하는 환경을 필요로 합니다.

에이전트 실행을 위한 핵심 요구사항

AI 에이전트를 위한 신뢰할 수 있는 인프라를 구축하려면 전통적인 웹 호스팅과는 다른 네 가지 특정 기둥(pillars)이 필요합니다. 첫째, 실행 환경(execution environments)은 밀리초(milliseconds) 단위로 프로비저닝(provision)되어야 합니다. 에이전트가 코드 스니펫(snippet)을 테스트하기 위해 샌드박스를 실행하는 데 몇 분이 걸린다면, 추론 루프(reasoning loop)가 너무 느려져 실질적인 사용이 불가능해집니다. 유연한 사용자 경험을 유지하기 위해서는 신속한 환경 생성이 필수적입니다.

둘째, 시스템에는 내구성이 있는 상태 관리(durable state management)가 필요합니다. 에이전트는 진행 상황을 잃지 않고 작업을 일시 중지하거나, 다른 프로세스에 작업을 넘기거나, 나중에 작업을 재개할 수 있어야 합니다. 처음부터 컨텍스트(context)를 재구성하는 것은 비용이 많이 들고 토큰(tokens)을 낭비합니다. 효과적인 인프라는 에이전트가 복잡한 작업의 전체 라이프사이클(lifecycle) 동안 히스토리(history)와 중간 출력값(intermediate outputs)을 유지할 수 있도록 합니다.

여러 에이전트 간의 조정(Coordination)은 세 번째 요구사항입니다. 실제 애플리케이션은 단일 에이전트에 의존하는 경우가 드물며, 대신 전문화된 도구들의 네트워크를 사용합니다. 인프라는 서브 에이전트(sub-agents)를 생성하고 이들 사이에서 구조화된 데이터(structured data)를 전달하는 것을 지원해야 합니다. 이를 위해서는 데이터 손실이나 보안 침해 없이 핸드오프(handoffs)가 이루어지도록 보장하기 위해, 동시 실행되는 프로세스들의 웹 전반에 걸친 의존성(dependencies)을 추적해야 합니다.

마지막으로, 자격 증명 관리(credential management)는 더욱 세밀하고 휴대 가능해야 합니다. 에이전트는 작업을 수행하기 위해 제3자 서비스(third-party services)와 빈번하게 인증해야 합니다. 이러한 비밀 정보(secrets)는 로그에 노출되거나 공유 환경 변수(shared environment variables)에 포함되지 않으면서 실행 컨텍스트(execution context)를 따라 이동해야 합니다. 에이전트가 서로 다른 플랫폼에서 사용자를 대신하여 행동할 권한을 가질 때, 보안이 유지되는 세션 기반의 ID 관리(identity management)는 매우 중요합니다.

이러한 요구사항과 레거시 시스템(legacy systems) 사이의 불일치는 운영 데이터에서 명확하게 드러납니다. 보고서에 따르면, 오버프로비저닝(overprovisioning)이 증가함에도 불구하고 전통적인 클러스터의 평균 CPU 사용률은 떨어지고 있습니다. 에이전트가 핵심적인 추론(reasoning)을 수행하는 동안 항상 높은 CPU를 소비하는 것은 아니기 때문에, 표준 오토스케일러(autoscalers)는 종종 에이전트의 활동을 잘못 해석합니다. 이는 실제 성능 병목 현상은 해결되지 않은 채 유휴 하드웨어에 비용을 낭비하는 결과로 이어집니다.

보안 및 실제 구현

상태가 없는 서비스(stateless services)에서 자율 에이전트(autonomous agents)로 전환될 때 위협 모델(threat model)은 크게 변화합니다. 표준 웹 서비스가 침해될 경우, 피해는 대개 해당 서비스의 특정 API로 제한됩니다. 그러나 침해된 에이전트는 자신이 보유한 모든 자격 증명과 접근 가능한 모든 시스템에 대한 권한을 갖게 됩니다. 에이전트는 스스로 코드를 생성할 수 있으며, 예측하기 어려운 비결정론적(non-deterministic)인 결정을 내릴 수도 있습니다.

표준 컨테이너 보안(Standard container security)은 이러한 리스크를 방어하기에 더 이상 충분하지 않습니다. 조직은 기본적으로 커널 수준의 격리(kernel-level isolation)와 엄격한 네트워크 송신(network egress) 규칙을 구현해야 합니다. 관측성(Observability) 도구 또한 에이전트를 인식할 수 있어야 하며, 단순히 리소스 사용량뿐만 아니라 에이전트 로직의 의도와 흐름을 추적해야 합니다. 이는 선택적인 업그레이드가 아니라, 에이전트를 대규모로 배포하는 모든 기업이 갖춰야 할 기초적인 요구사항입니다.

일부 엔지니어링 팀은 이미 이러한 과제들을 해결하기 위해 맞춤형 플랫폼을 성공적으로 구축했습니다. 샌드박스 처리된 가상 머신(sandboxed virtual machines)을 사용하고 개발 도구와 깊게 통합함으로써, 이 팀들은 내부 에이전트의 높은 채택률을 달성했습니다. 어떤 경우에는 자동화된 에이전트가 주요 리포지토리에 병합되는 모든 코드 변경 사항의 거의 3분의 1을 담당하기도 합니다. 이러한 성공은 빠르고 역량 있는 실행 계층(execution layer)을 보유한 데서 기인합니다.

초기 도입자들로부터 얻은 핵심 교훈은 성능이 AI 모델 자체보다는 인프라에 의해 제한되는 경우가 많다는 점입니다. 라이브러리를 복제하거나 종속성(dependencies)을 설치하느라 세션 시작이 너무 오래 걸린다면, 에이전트는 로컬 워크플로우와 경쟁할 수 없습니다. 인프라는 에이전트가 추론(reasoning) 프로세스를 시작하기도 전에 이러한 백그라운드 작업들을 처리할 수 있어야 합니다. 이러한 초점의 전환을 통해 모델이 가능한 한 빠르게 응답할 수 있게 됩니다.

생태계가 서서히 따라잡고는 있지만, 많은 팀이 여전히 레거시 기본 설정(legacy defaults)에 머물러 있습니다. 이들은 에이전트형 워크로드(agentic workloads)를 요청 중심(request-oriented)의 범주에 억지로 끼워 맞추려 시도하며, 그 결과 높은 비용과 신뢰할 수 없는 시스템을 초래합니다. 목적에 맞게 설계된 에이전트 컴퓨팅(purpose-built agent compute)으로의 전환은 이미 진행 중이며, 그 격차를 메울 도구들도 이미 존재합니다. 에이전트가 새로운 클래스의 컴퓨팅을 나타낸다는 점을 인식하는 것이 현대적이고 효율적인 기술 스택(tech stack)을 구축하기 위한 첫 번째 단계입니다.