클라우드 청구서는 아무도 슬라이드에 넣지 않은 아키텍처의 부분을 찾아내는 재주가 있습니다.

AI 에이전트(AI agents)에 대해 모두가 토큰(tokens)에 대해 이야기하는 것을 좋아합니다. 어떤 모델이 더 저렴한가? 어떤 라우터(router)가 더 똑똑한가? 에이전트가 문제를 "성공적으로 조사했으며" 아무것도 변경하지 않았다고 설명하는 동안 얼마나 많은 컨텍스트(context)를 소모했는가?

하지만 Google Cloud의 최근 GKE Agent Sandbox 포스트는 매우 실질적으로 느껴지는 또 다른 비용 형태를 지적합니다. 바로 유휴 에이전트(idle agent)입니다.

비싼 추론(inference)을 수행하는 에이전트가 아닙니다. 대규모 리포지토리(repo)를 컴파일하는 에이전트도 아닙니다. 버튼 하나를 클릭하는 데 왠지 3분이 걸리는 브라우저 테스트를 실행하는 에이전트도 아닙니다.

기다리고 있는 에이전트입니다.

agent waiting for the next task while the meter runs

Google의 주장은 주의를 기울일 만큼 구체적입니다. 중단(suspend) 및 재개(resume) 기능이 있는 GKE Agent Sandbox를 사용하면 간헐적인 워크로드(intermittent workloads)에 대해 최대 3.5배 더 많은 에이전트를 실행할 수 있으며 에이전트당 비용을 최대 75%까지 절감할 수 있습니다. 이는 클라우드 제공업체가 최적화의 단위가 변했음을 조용히 말하고 있는 것입니다.

흥미로운 지표는 더 이상

모든 유휴 간격(idle gap)이 실행 환경을 계속 '웜(warm)' 상태로 유지한다면, 청구서는 터무니없어 보이기 시작할 것입니다. 당신은 작업의 유령(ghost)에 비용을 지불하고 있는 셈입니다. 에이전트는 생각하고 있지 않습니다. 컴파일하고 있지도 않습니다. 유용한 작업을 수행하고 있지도 않습니다. 그저 나중에 무언가 일어날지도 모른다는 이유로 샌드박스(sandbox)를 점유하고 있을 뿐입니다.

토큰이 청구서의 전부는 아닙니다

토큰 비용은 모델 호출(model call)과 직결되므로 이해하기 쉽습니다. 표로 만들 수도 있고, 대시보드를 구축할 수도 있습니다. 누군가가 "분류(classification) 작업에는 더 저렴한 모델을 사용해야 합니다"라고 말하는 회의를 열면, 모두가 책임감 있는 발언이라며 고개를 끄덕일 수 있습니다.

실행 비용(Execution cost)은 훨씬 더 복잡합니다.

에이전트에게는 실행할 장소가 필요합니다. 이러한 장소에는 컨테이너(containers), 브라우저(browsers), 파일 시스템(filesystems), 패키지 캐시(package caches), 테스트 데이터베이스(test databases), 네트워크 규칙(network rules), 비밀 정보(secrets), 로그(logs), 그리고 현대적인 JavaScript 툴링(tooling)을 견뎌낼 수 있는 충분한 CPU와 메모리가 포함될 수 있습니다.

이는 비용이 모델 제공업체 내부에만 머물지 않는다는 것을 의미합니다.

모델 주변의 대기실(waiting room)에서도 비용이 발생합니다.

조직이 수백 또는 수천 개의 간헐적인 에이전트(intermittent agents)를 운영한다면, 유휴 하한선(idle floor)이 중요해집니다. 2분 동안 깨어 있다가 20분 동안 기다리는 작업자는 대부분 유휴 비용(idle cost) 문제입니다. 이를 모든 리포지토리(repo), 모든 예약된 유지보수 작업, 그리고 모든 PR 리뷰 봇(PR review bot)에 곱하면, 갑자기 지루했던 인프라 계층이 청구서를 흥미롭게 만드는 주범이 됩니다.

참으로 멋진 일입니다. 인턴을 자동화했더니 임대료 문제를 발견하게 되었군요.

일시 중단(suspend) 및 재개(resume)는 플랫폼 기능입니다

GKE 에이전트 샌드박스(Agent Sandbox) 이야기가 중요한 이유는 일시 중단(suspend)과 재개(resume)가 단순히 영리한 리소스 트릭이 아니기 때문입니다. 그것은 플랫폼의 약속입니다.

이는 "컨테이너를 실행한다"는 것과는 다른 문제입니다.

그것은 작업자(worker)를 위한 세션 관리(session management)에 더 가깝습니다. 플랫폼은 어떤 상태를 유지할지, 무엇을 동결(frozen)할지, 무엇을 축출(evicted)할지, 무엇을 로그로 남길지, 무엇에 비용을 청구할지, 그리고 너무 많은 에이전트가 동시에 깨어날 때 어떤 일이 일어날지를 결정해야 합니다.

every suspended agent waking up because one webhook sneezed

중단(Suspend)과 재개(Resume)는 600개의 에이전트가 동시에 깨어나, 비용 최적화 작업을 즐거운 제품 이름이 붙은 '천둥 치는 들쥐(thundering herd)' 현상으로 바꿔버린 이유를 설명해야 하는 사람이 되기 전까지는 지루하게 들립니다.

밀도는 새로운 장애 모드(failure modes)를 생성합니다

높은 밀도는 매력적입니다. 당연한 일이죠. 동일한 인프라에서 더 많은 에이전트를 실행하는 것은 제목에 "의견은?"이라고 적혀 전달되는 바로 그 종류의 차트입니다.

하지만 밀도에는 항상 그림자가 따릅니다.

에이전트가 더 많은 인프라를 공유한다면, 공정성(fairness)을 이해해야 합니다. 여러 에이전트가 깨어날 때 어떤 에이전트가 CPU를 할당받을까요? 어떤 세션이 웜 상태(warm)를 유지하도록 허용될까요? 어떤 작업은 공격적으로 일시 중단할 만큼 충분히 저렴할까요? 어떤 작업은 사람이 능동적으로 기다리고 있기 때문에 낮은 지연 시간(low-latency) 응답이 필요할까요?

또한 정리(cleanup) 작업도 필요합니다.

유휴(Idle) 에이전트가 항상 예의 바르게 유휴 상태인 것은 아닙니다. 어떤 것들은 멈춰(stuck) 있습니다. 어떤 것들은 절대 일어나지 않을 조건을 기다리고 있습니다. 어떤 것들은 파일, 잠금(locks), 브라우저 상태 또는 자격 증명(credentials)을 필요 이상으로 오래 붙잡고 있습니다.

비용 문제는 운영(operations) 문제로 변합니다:

• 얼마나 많은 에이전트가 활성(active), 유휴(idle), 중단(suspended) 또는 사망(dead) 상태인가
• 세션이 얼마나 오래 유지되는가
• 각 세션이 어떤 상태를 유지하는가
• 깨어남 폭풍(wake-up storms) 동안 어떤 일이 발생하는가
• 사용자가 세션의 존재를 잊은 후 세션의 소유권은 누구에게 있는가
• 어떤 예산이 청구서 모양의 교훈을 멈추게 할 것인가

이 중 그 어느 것도 모델 지능(model intelligence)이 아닙니다.

이 모든 것이 프로덕션(production)입니다.

Kubernetes는 다시 금융 접점(finance surface)이 되고 있습니다

Kubernetes는 이미 많은 운영상의 혼란을 API 객체로 바꾸어 놓았습니다. Pods, Jobs, CronJobs, Services, 할당량(quotas), 제한(limits), 우선순위 클래스(priority classes), 오토스케일러(autoscalers), 정책(policies) 등이 그것입니다. 이곳은 엔지니어링 의도, 리소스 가용성, 그리고 조직의 정치가 YAML에서 만나는 지점입니다.

에이전트는 그 사실을 더욱 명확하게 만듭니다.

에이전트가 장기 실행 워커(long-lived workers)가 되면, 스케줄링 결정은 곧 비용 결정이 됩니다. 샌드박스(sandbox)를 일시 중단(suspending)하는 것은 비용 결정입니다. 세션(session)을 활성 상태(warm)로 유지하는 것은 제품 결정입니다. 유휴 작업(idle work)을 축출(evicting)하는 것은 신뢰성 결정입니다.

이것이 "에이전트당 비용(cost per agent)"이라는 문구가 유용한 이유입니다. 이 지표는 플랫폼 팀이 단순한 클러스터 활용률(cluster utilization) 너머를 바라보게 만듭니다. 에이전트 플랫폼이 여전히 경제적으로 어리석게 운영되고 있더라도, 클러스터는 충분히 바빠 보일 수 있기 때문입니다.

과거의 사고 모델은 "vCPU가 얼마나 필요한가?"였습니다.

최근의 질문은 "얼마나 많은 대기 시간을 감당할 수 있는가?"입니다.

이것이 더 나은 질문이자, 더 성가신 질문입니다.

첫 번째 대시보드는 창피함을 느껴야 합니다

만약 제가 오늘 내부 에이전트 플랫폼을 구축한다면, 약간은 무례하게 느껴지는 대시보드부터 시작할 것입니다.

그라데이션이 들어가 있고 커다란 친절한 글씨로 "AI 생산성 해제"라고 적힌 장엄한 경영진용 대시보드 같은 것은 아닙니다. 제발 그러지 마세요. 우리는 이미 충분히 고통받았습니다.

저는 다음과 같은 투박한 카운터들을 원할 것입니다:

• 활성 에이전트 (active agents)
• 유휴 에이전트 (idle agents)
• 일시 중단된 에이전트 (suspended agents)
• 평균 유휴 시간 (average idle time)
• 활성 분당 비용 (cost per active minute)
• 웨이크업 지연 시간 (wake-up latency)
• 타임아웃으로 종료된 세션 (sessions killed by timeout)
• 소유자가 없는 세션 (sessions with no owner)

그런 다음 모든 곳에 소유자 라벨(owner labels)과 예산 라벨(budget labels)을 붙일 것입니다.

대시보드가 문화를 해결해주지는 않습니다. 대시보드의 절반은 그저 비싼 벽지일 뿐입니다. 하지만 에이전트의 경우, 보이지 않는 비용이 위험한 비용입니다. 아무도 유휴 세션을 볼 수 없다면, 아무도 그것을 정리하지 않을 것입니다. 어떤 워크플로(workflow)가 하루 종일 CI를 기다리고 있는지 아무도 알 수 없다면, 아무도 그것을 재설계하지 않을 것입니다.

제품의 형태는 아직 초기 단계입니다

저는 그 해답이 "모두가 GKE에서 에이전트를 실행해야 한다"라고 생각하지 않습니다. 그것은 매우 깔끔한 결론이겠지만, 보통 그런 결론은 벤더(vendor)가 작성했을 때 나타나는 특징입니다.

더 넓은 관점의 논점이 더 유용합니다: 에이전트 플랫폼에는 생명주기 제어(lifecycle controls)가 필요합니다.

실행 계층(execution layer)이 어디에 있든, 질문은 계속해서 반복됩니다:

• 에이전트는 어떻게 시작되는가?
• 어떻게 일시 중지(pause)되는가?
• 어떻게 재개(resume)되는가?
• 어떻게 중단(stop)되는가?
• 유휴 부분에 대한 비용은 누가 지불하는가?

명사들 이면에는 똑같이 지루한 진실이 남아 있습니다: 에이전트는 하나의 워크로드 (workload)라는 점입니다. 만약 에이전트가 충분히 오래 실행되고 충분히 자주 대기한다면, 스케줄링 (scheduling), 생명주기 (lifecycle), 할당량 (quotas), 정리 (cleanup), 그리고 비용 회계 (cost accounting)가 필요합니다.

핵심 결론 (the punchline)

AI 에이전트 비용은 단순히 모델 라우팅 (model-routing) 문제만이 아닙니다.

그것은 실행 (execution) 문제입니다.

대기 중인 에이전트도 여전히 귀하의 플랫폼의 일부입니다. 일시 중단 (suspended)될 수도 있고, 저렴할 수도 있습니다. 활성 작업자 (active worker)와 비교하면 거의 무료에 가까울 수도 있습니다. 하지만 그것은 아무것도 아닌 상태가 아닙니다.

이것이 바로 GKE 에이전트 샌드박스 (GKE Agent Sandbox) 비용 이야기가 흥미로운 이유입니다. 이는 많은 팀이 고통스러운 방식으로 재발견하게 될 현상을 지칭하고 있습니다.

유휴 에이전트 (Idle agents)는 실제 워크로드 (workloads)입니다.

이들은 값비싼 백그라운드 소음 (background noise)이 되기 전에 지루한 생명주기 관리 (lifecycle management)를 필요로 합니다.

에이전트 인프라의 미래는 단지 가장 똑똑한 모델이나 가장 예쁜 채팅창에 의해 결정되지 않을 것입니다. 클라우드 청구서를 장애 보고서 (incident report)로 만들지 않으면서 수천 명의 대기 중인 작업자를 실행할 수 있는 플랫폼이 승리할 것입니다.

마법은 줄이고.

일시 중단 (suspend)과 재개 (resume)는 늘리고.

늘 그렇듯, 프로덕션 (production)은 데모가 캘린더 초대장을 받고 시간당 비용을 청구하기 시작하는 곳입니다.

참고 문헌 (references)

• Google Cloud: Do more with less: How GKE can reduce your cost per agent by 75%
• Kubernetes documentation: Resource quotas
• Kubernetes documentation: Pod priority and preemption

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