이제 Pod는 에이전트가 아니라 작업자(Worker)입니다

Kubernetes 사람들은 훌륭한 배포 단위(deployment unit)를 사랑합니다.

스케줄링(scheduled)이 가능하고, 이름이 붙여지며, 관찰(observed) 가능하고, 재시작(restarted)할 수 있으며, 보안(secured)이 적용되고, 비용 청구(billed)가 가능한 무언가를 우리에게 준다면, 우리는 점심 식사 전까지 그것을 중심으로 하나의 철학을 구축할 것입니다.

수년 동안 Pod는 바로 그 무언가였습니다. Pod는 작업이 일어나는 작은 상자입니다. Pod는 컨테이너(containers)를 실행합니다. ServiceAccount를 통해 정체성(identity)을 얻습니다. 로그(logs), 레이블(labels), 리소스 요청(resource requests), 네트워크 정책(network policy), 그리고 플랫폼 팀이 점성술을 상담하지 않고도 논리적으로 파악할 수 있는 생명주기(lifecycle)를 가지고 있습니다.

그러다 AI 에이전트(AI agents)가 등장했고, 이 추상화(abstraction)의 냄새를 이상하게 만들었습니다.

CNCF는 Kubernetes Pod가 AI 에이전트를 위한 적절한 배포 단위인지 묻는 유용한 게시물을 발표했습니다. kagent 이야기는 당연한 곳에서 시작됩니다: 각 에이전트를 자체적인 Pod, Service, 그리고 ServiceAccount에서 실행하는 것입니다. 이는 Kubernetes 팀이 이미 알고 있는 도구들을 통해 격리(isolation), 정체성(identity), 정책(policy), 스케줄링(scheduling), 그리고 관찰 가능성(observability)을 제공합니다.

이것은 좋은 첫 번째 답변입니다.

하지만 아마도 최종적인 답변은 아닐 것입니다.

kubernetes realizing the agent is not just another microservice

흥미로운 점은 "Kubernetes가 나쁘다"거나 "Pod가 죽었다"는 것이 아닙니다. 흥미로운 점은 AI 에이전트가 우리가 '작업이 실행되는 곳'과 '작업이 무엇인지'를 분리하도록 강제하고 있다는 사실입니다.

이 구분은 매우 중요합니다.

Pod는 실행 장소입니다

Pod는 훌륭한 실행 장소입니다. Pod는 경계(boundary)를 제공합니다. 스케줄러(scheduler)에게 배치할 대상을 제공합니다. 관찰 가능성(observability)에 타겟을 제공합니다. 네트워크 정책(network policy)에 부착할 대상을 제공합니다.

일반적인 서비스(services)의 경우, 이는 잘 맞아떨어집니다.

서비스가 존재합니다. Pod는 그것의 인스턴스(instance) 하나를 실행합니다. 수요가 증가하면 더 많은 Pod를 실행합니다. 하나가 죽으면 다른 하나가 나타납니다. 애플리케이션의 정체성은 배포(deployments), 서비스 계정(service accounts), 레이블(labels), 네임스페이스(namespaces), 이미지(images), 그리고 일반적인 Kubernetes 구성 요소들에 묶여 있습니다.

AI 에이전트는 다릅니다.

에이전트(agent)는 하나의 작업을 위해 깨어나서, 30초 동안 실행되고, 세 개의 도구(tools)를 호출하고, 두 개의 보조 에이전트(helper agents)를 생성하고, 인간의 승인을 위해 일시 중지했다가, 나중에 재개하여, 패치(patch)를 작성한 뒤 사라질 수도 있습니다. 중요한 정체성(identity)은 Linux 프로세스가 아닙니다. 반드시 컨테이너(container)일 필요도 없습니다. 그것은 누군가를 대신하여 작업을 수행하는 논리적 행위자(logical actor)입니다.

그 행위자는 이동할 수 있습니다.

일시 중단될 수 있습니다.

재생(replayed)될 수 있습니다.

4단계를 실행했던 Pod보다 더 오래 지속되는 감사 이력(audit history)이 필요할 수도 있습니다.

이 모든 것이 단지 "어떤 Pod가 실행되었다"라고만 표현된다면, 당신은 핵심을 놓친 것입니다.

에이전트는 행위자 정체성(actor identity)을 가집니다

CNCF/kagent 기사는 에이전트-기질(agent-substrate)을 Kubernetes가 워커 풀(WorkerPools)과 실행 Pod를 관리하고, 기질(substrate)이 워커(Workers)와 행위자(Actors)를 관리하는 계층으로 설명합니다. Pod는 워커(workers)가 되고, 행위자(Actors)는 논리적 에이전트(logical agents)가 됩니다.

왜냐하면 진짜 질문은 Pod가 에이전트 코드를 실행할 수 있느냐가 아니기 때문입니다. 당연히 할 수 있습니다. 충분한 CPU, 권한, 그리고 잘못된 낙관주의만 있다면 Pod는 거의 무엇이든 실행할 수 있습니다.

더 나은 질문은 이것입니다: 어떤 객체(object)가 정체성(identity), 소유권(ownership), 정책(policy), 할당량(quota), 그리고 이력(history)을 담아야 하는가?

에이전트의 경우, 그 객체는 아마도 Pod보다 상위에 있어야 할 것입니다.

고객 성공(customer success) 팀의 Maria를 대신하여 활동하는 지원 에이전트를 상상해 보십시오. 에이전트는 티켓을 읽고, 대시보드를 확인하고, 환불 권장 사항을 초안으로 작성하고, 승인을 위해 일시 중지한 다음, API를 호출합니다. 어떤 정체성이 가장 중요할까요?

Pod 이름일까요?

워커 풀(worker pool)일까요?

서비스 계정(service account)일까요?

아니면 이것이 테넌트(tenant) br 내부에서 Maria를 대신하여, 쓰기 전 한 번의 인간 승인을 거친, 버전 2026-07-29인 에이전트 refund-reviewer였다는 사실일까요?

장애(incident)를 디버깅하고 있다면, 마지막 답변이 당신이 원하는 답변입니다.

Pod는 작업이 일어난 장소입니다.

행위자(Actor)는 작업이 일어난 이유입니다.

관찰 가능성(observability)은 컨테이너가 아니라 작업을 따라가야 합니다

이 지점에서 일반적인 플랫폼 대시보드들은 다소 부실해 보이기 시작합니다.

Pod별 로그(Logs)는 유용합니다. 컨테이너별 메트릭(Metrics)은 유용합니다. 서비스별 트레이스(Traces)는 유용합니다. Prometheus를 슬프게 만들고 싶지는 않습니다.

하지만 에이전트 작업(agent work)에는 또 다른 차원이 필요합니다.

저는 작업(task), 행위자(actor), 사용자 위임(user delegation), 도구 호출(tool calls), 승인(approvals), 네트워크 호출(network calls), 사용된 모델(model used), 재시도(retries), 그리고 최종 결과물(artifact)을 보고 싶습니다. 실행이 여러 작업자(worker) 사이를 건너뛰거나 일시 중단 후 재개되었더라도, 저는 그 흔적(trail)을 보고 싶습니다.

looking for the agent history in pod logs

만약 에이전트가 운영 환경을 망가뜨리는 풀 리퀘스트(pull request)를 생성했다면, "Pod가 두 번 재시작됨"은 사건의 본질이 아닙니다. 사건의 본질은 다음과 같습니다: 에이전트가 무엇을 믿었는지, 무엇을 변경했는지, 어떤 증거를 수집했는지, 그리고 누가 에이전트의 진행을 허용했는지입니다.

이것은 전통적인 서비스 관측성(service observability)이 아닙니다.

이것은 작업 관측성(work observability)입니다.

Kubernetes는 레이블(labels), 어노테이션(annotations), 이벤트(events), 감사 로그(audit logs), 그리고 커스텀 리소스(custom resources)를 통해 이 중 일부를 처리할 수 있습니다. 좋습니다. 기존의 메커니즘을 활용하세요. 하지만 사고 모델(mental model)은 변화해야 합니다. 수명이 짧은 Pod가 기존 도구들로 그래프를 그릴 수 있다고 해서, 그것이 항상 지속 가능한 책임 단위(durable unit of accountability)가 되는 것은 아닙니다.

정책은 리스크가 존재하는 곳에 있어야 합니다

동일한 문제가 보안에서도 나타납니다.

오늘날의 Kubernetes 정책은 대부분 Kubernetes 요소들, 즉 Pod, 네임스페이스(namespaces), 서비스 계정(ServiceAccounts), 네트워크 경로(network paths), 어드미션 규칙(admission rules), 이미지(images), 런타임 프로필(runtime profiles)에 부착됩니다. 이는 정책 모델이 "배포하고 기도하기"였던 과거에 비하면 좋고 성숙한 방식입니다.

하지만 에이전트의 리스크는 종종 논리적 행위자(logical actor) 및 위임된 작업(delegated task)과 결부됩니다.

공개 문서를 요약하는 에이전트와 고객 데이터를 읽을 수 있는 에이전트의 리스크는 동일하지 않습니다. Terraform 초안을 작성하는 것은 Terraform을 적용하는 것과는 다릅니다.

만약 Pod가 단지 실행 작업자(execution worker)일 뿐이라면, 정책 모델은 그 상위에 있는 행위자(actor)를 이해해야 합니다.

이는 초기에 지루한 질문들에 답하는 것을 의미합니다:

어떤 행위자(actor) 템플릿이 어떤 도구(tool)를 사용할 수 있습니까?
어떤 테넌트(tenant)가 이 워커 풀(worker pool)에 행위자를 스케줄링할 수 있습니까?
누가 작업을 위임한 인간 또는 서비스입니까?
이 행위자에게 허용되는 네트워크 목적지(network destination)는 무엇입니까?
어떤 작업은 계속 진행하기 전에 승인이 필요합니까?
완료 후 보존되어야 하는 아티팩트(artifact)는 무엇입니까?

Pod 자체는 중요합니다. 이는 경계의 일부를 강제하기 때문입니다. 하지만 위험은 행위자, 작업, 그리고 행사되는 권한에 존재합니다.

컨테이너만 보는 보안 도구들은 이야기의 일부를 놓칠 것입니다. 컨테이너 경계를 무시하는 에이전트 플랫폼 역시 혼란을 야기할 것입니다.

죄송합니다. 더 많은 내부 구조(plumbing)가 필요했습니다.

스케줄링은 소유권과 같지 않다

물론 비용 측면에서도 고려해야 합니다. 클라우드 컴퓨팅은 추상화를 청구서로 바꾸는 데 탁월한 능력을 가지고 있습니다.

가능한 모든 에이전트마다 Pod를 하나씩 두는 것은 시연하기에는 간단합니다. 하지만 대부분의 에이전트가 유휴 상태일 경우 낭비가 될 수도 있습니다. 에이전트는 간헐적(bursty)입니다. 작업과 함께 도착하고, 리소스를 소비하며, 기다린 다음 사라집니다.

이런 경우에는 워커 풀(Worker pools)이 합리적입니다. 고정된 실행 용량을 유지하고, 작업이 있을 때 논리적인 행위자들을 워커에 스케줄링하는 것입니다. 우리는 이미 작업을 노드와 분리하고, 함수를 런타임과 분리하며, 요청을 서버와 분리하고, 큐를 소비자로부터 분리했습니다.

함정은 스케줄링 계층이 소유권 계층이 되도록 내버려 두는 것입니다.

단지 어떤 행위자가 워커 abc에서 실행되었다고 해서 워커 abc가 비즈니스 작업을 소유한다는 의미는 아닙니다. 소유자는 에이전트를 생성한 팀, 제품, 테넌트, 서비스, 인간 위임, 또는 워크플로우입니다. 청구(Billing), 감사(audit), 할당량(quota), 그리고 정리(cleanup)도 이를 따라야 합니다.

그렇지 않으면 모든 조사는 일시적인 인프라를 통한 고고학이 됩니다.

그리고 네, 고고학은 숭고합니다. 하지만 여전히 형편없는 사고 대응 전략입니다.

실질적인 시사점

만약 Kubernetes에서 에이전트 인프라를 구축하거나 구매하고 있다면, 저는

Pod와 독립적으로 논리적 에이전트 (logical agent)를 식별할 수 있는가?
모든 동작을 사용자, 팀, 테넌트 (tenant), 정책 (policy), 그리고 버전 (version)에 연결할 수 있는가?
실행이 이동하거나 재개될 때 관측성 (observability)이 작업을 따라갈 수 있는가?
행위자 (actor) 수준과 컨테이너 (container) 수준 모두에서 정책을 강제할 수 있는가?
워커 (worker) 용량을 에이전트 소유권 (agent ownership)과 분리할 수 있는가?
고대 경전을 읽듯 무작위 Pod 로그를 뒤지지 않고도 "무슨 일이 일어났는가?"에 답할 수 있는가?

platform team discovering the boring abstraction was the product

만약 대답이 "예"라면, 좋습니다. 당신은 아마도 진정한 에이전트 플랫폼을 구축하고 있는 것입니다.

만약 대답이 "아니오"라면, 당신은 컨테이너에서 챗봇을 실행하면서 그것을 아키텍처라고 부르고 있는 것일지도 모릅니다.

하지만 이 차이는 매우 중요할 것입니다.

에이전트는 단순히 또 다른 워크로드 (workload) 유형이 아닙니다. 에이전트는 작업을 수행하는 위임된 행위자 (delegated actors)이며, 때로는 권한을 가지고, 때로는 여러 시스템에 걸쳐, 때로는 일시 중단과 재시도를 거치며 동작합니다. Pod는 에이전트를 실행할 수 있습니다. Pod는 에이전트의 일부를 격리할 수 있습니다. Pod는 플랫폼 팀에게 매우 유용한 제어권을 제공할 수 있습니다.

하지만 Pod가 에이전트의 전부는 아닙니다.

우리가 이 사실을 빨리 인정할수록, 차세대 에이전트 플랫폼을 구축하는 과정은 덜 고통스러울 것입니다.

Kubernetes는 여전히 이러한 메커니즘의 상당 부분을 실행하기에 적합한 장소입니다.

다만, 그 메커니즘이 무엇을 의미하는지 정의하기에 항상 적합한 장소인 것은 아닙니다.

references

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 20달러(USD)를 받고 싶다면 이 링크를 사용하세요.

Insights