청구서가 부하보다 먼저 늘어나는 이유
월말 클라우드 청구서를 열어 본 팀이라면 한 번쯤 겪는 장면이 있다. 트래픽은 평온했고 장애도 없었다. 서비스 지표는 어느 달보다 안정적이었는데 비용 그래프만 우상향한다. 쿠버네티스를 도입하면 자원을 효율적으로 쓰게 되리라 기대했지만, CNCF의 2024년 FinOps 조사에서 응답 조직의 49%가 도입 후 클라우드 지출이 오히려 늘었다고 답했다.
실마리는 활용률 숫자에 있다. 같은 조사에서 클러스터의 평균 CPU 활용률은 10%, 메모리는 20% 수준이었다. 값을 치른 자원의 대부분이 일하지 않고 있다는 뜻이다. Datadog의 2024년 조사는 더 직접적이다. 컨테이너 비용의 83%가 유휴 자원, 그러니까 확보해 두고 쓰지 않는 용량에 흘러간다. Flexera가 집계한 전 세계 클라우드 지출의 낭비 비율이 27%이고 그중 최대 단일 항목이 유휴 컴퓨트라는 사실까지 겹쳐 보면, 특정 팀의 운영 미숙이 아니라 업계 전반의 구조다.
쿠버네티스가 비싼 게 아니다. 청구서를 키우는 주범은 부하가 아니라 부하 없는 예약이다. 쿠버네티스에서 각 컨테이너는 requests 값으로 자신이 쓸 CPU와 메모리를 미리 신고하고, 스케줄러는 실제 사용량이 아니라 이 신고량을 기준으로 노드의 자리를 배정한다. 신고가 과하면 쓰지 않는 자원도 점유로 계산되고, 그 점유가 노드 수를 늘리고, 늘어난 노드가 청구서가 된다. 비용 최적화는 더 싼 인스턴스를 고르는 일이 아니라 예약과 실사용의 간극을 측정하고 회수하는 일이다.
유휴의 두 얼굴: 파드와 노드
유휴는 한 종류가 아니다. Datadog의 분해로는 유휴 비용의 54%가 클러스터 수준의 오버프로비저닝, 즉 필요보다 크거나 많은 노드에서 나오고, 29%는 워크로드 수준의 과도한 요청에서 나온다. 두 층은 원인도 처방도 다르다.
워크로드 유휴부터. 엔지니어는 배포 시점에 requests를 정해야 하는데 정확한 값을 알기 어려우니 관행적으로 여유를 둔다. 피크 트래픽에 한 번 놀란 팀은 그 피크에 맞춰 requests를 고정하고, 이후 아무도 내리지 않는다. requests와 limits를 같게 잡은 Guaranteed 등급은 축출로부터 가장 안전한 대신 예약 낭비도 가장 크다. 안정성과 예약 효율은 트레이드오프인데, 대부분의 조직은 이 저울에서 무의식적으로 안정성 쪽에 전부를 걸어 왔다. CNCF 조사에서 응답자의 70%가 비용 초과의 주원인으로 오버프로비저닝을 지목했다.
클러스터 유휴는 더 조용히 쌓인다. 파드가 아무리 알뜰해도 노드가 크고 많으면 소용이 없다. 노드 오토스케일링이 없거나 스케일다운이 보수적이면 빈 노드가 체류한다. 전통적인 Cluster Autoscaler는 새 노드를 띄우는 데 34분이 걸리는 것으로 알려져 있다. 확장이 느리니 팀은 여유 노드를 상시 유지하게 되고, 그 안전 마진이 제도화된다. Karpenter처럼 4560초 안에 노드를 공급하고 파드를 재배치해 빈 노드를 정리하는 도구가 주목받는 이유는 속도 자체가 아니라, 빠른 공급이 상시 여유분이라는 관행을 불필요하게 만들기 때문이다. 빈 노드의 체류 시간이 곧 돈이다.
파드의 requests만 손보는 최적화는 29%의 축만 건드린다. 더 큰 54%는 노드의 크기와 수, 회수 속도에 있다. 파드와 노드를 함께 움직여야 유휴가 닫힌다.
보이게 한 다음 깎는다
두 층의 유휴를 줄이려는 시도는 대개 그보다 앞선 지점에서 좌초한다. 무엇이 얼마나 낭비되는지 아무도 모르는 상태에서 출발하기 때문이다. FinOps Foundation의 2025년 집계에서 쿠버네티스 비용을 팀별로 보여 주는 쇼백(showback)을 구현한 조직은 13%, 실제 비용을 팀에 청구하는 차지백(chargeback)은 14%에 그쳤다. 클라우드 청구서는 인스턴스 단위로 나오는데 쿠버네티스는 한 노드에 여러 팀의 파드를 섞어 놓는다. 이 간극을 메우는 장치가 없으면 청구서의 어느 줄이 어느 팀의 결정에서 나왔는지 아무도 답하지 못한다.
FinOps 방법론이 Inform, Optimize, Operate 순서를 고집하는 이유가 여기에 있다. 성숙도 슬로건이 아니라 작업 순서다. 먼저 재고, 그다음 깎고, 마지막에 자동화한다. OpenCost가 CNCF 인큐베이팅 프로젝트가 되고 Kubecost가 IBM에 인수된 흐름은 네임스페이스와 파드 단위의 비용 가시성이 부가 기능이 아니라 FinOps의 본류 인프라가 됐다는 증거다. 다만 이 도구들은 대시보드가 아니라 회계의 전제다. team, env, app 같은 라벨이 없는 워크로드는 어떤 도구로도 귀속시킬 수 없다. 라벨과 네임스페이스, 네임스페이스별 총량을 제한하는 ResourceQuota는 기술 장치이기 이전에 소유권의 최소 단위다. 엔지니어가 배포 명세에 적는 requests와 라벨이 곧 회계 항목이 된다. 비용은 재무 부서의 스프레드시트가 아니라 배포 스펙의 부산물이다.
요청, 노드, 가격: 순서를 지키면
가시성이 갖춰졌다면 회수는 세 층을 순서대로 밟는다.
먼저 요청. 실사용 데이터를 근거로 requests를 재조정한다. VPA를 권고 모드로 두거나 KRR, Goldilocks 같은 도구로 권고치를 받아 검증을 거쳐 적용하는 것이 일반적인 출발점이다. CPU requests 대비 limits를 1:4, 메모리를 1:2로 두는 관행이 자주 언급되지만 출발점이지 진리가 아니다. 특히 메모리 limits를 과하게 잡으면 노드 수준의 메모리 고갈로 이어질 수 있어 CPU보다 보수적으로 다뤄야 한다.
다음은 노드. HPA로 파드 수를 수요에 맞추고, Karpenter류의 노드 오토스케일러로 노드를 수요에 맞춘다. 흔한 함정이 하나 있다. HPA와 VPA를 같은 CPU나 메모리 메트릭 위에 동시에 올리면 한쪽이 파드를 늘리는 동안 다른 쪽이 파드 크기를 바꾸면서 서로의 판단 근거를 무너뜨린다. death spiral이라 불리는 악순환이다. 수평 확장은 요청량 같은 부하 신호에, 수직 조정은 권고와 검증된 리사이즈에 역할을 분리해야 한다. 자동화 도구를 넣으면 끝이라는 기대는 이 설계 오류 앞에서 무너진다. 쿠버네티스 1.33에 베타로 들어온 In-Place Pod Resize처럼 재시작 없이 자원을 조정하는 장치가 수직 조정의 위험을 낮추는 쪽으로 진화하고 있어, 이 회수 루프는 점점 덜 아파지고 있다.
가격은 마지막이다. 안정적 베이스라인에는 약정 할인을, 중단을 견디는 워크로드에는 스팟 인스턴스를, 호환되는 워크로드에는 ARM 계열을 배치한다. 측정 없이 산 스팟과 약정은 과대한 노드를 싸게 유지할 뿐이다. 낭비의 단가를 낮추는 것은 낭비의 형태를 바꾸는 것이지 없애는 것이 아니다. 반대로 앞의 두 층을 닫은 뒤의 할인은 줄어든 베이스라인에 배수로 작용한다. 브라질 핀테크 PicPay가 EKS와 Karpenter로 노드 운영을 재구성해 월 비용을 절반 넘게 줄인 사례는 특정 도구의 승리가 아니라 노드 민첩성, 요청 조정, 할인 흡수가 같은 방향으로 겹쳤을 때의 폭을 보여 준다.
여유 있는 requests가 안정성의 보험 아니냐는 반론이 남는다. 절반만 맞다. 보험은 SLO와 PodDisruptionBudget, 버스트를 허용하는 limits로 사는 것이다. 상시 과다 예약은 보험이 아니라 매달 갱신되는 세금이고, Guaranteed 등급은 지연에 민감한 핵심 경로에만 아껴 쓸 때 의미가 있다.
빈 예약을 설계에서 끊는 팀
결국 질문은 세 개다. requests는 실사용을 반영하는가. 빈 노드는 얼마나 빨리 회수되는가. 각 비용은 라벨을 따라 책임 주체에게 도달하는가. 쇼백 13%라는 현실은 대부분의 조직이 아직 첫 질문 앞에도 서지 못했다는 뜻이지만, 그만큼 가시성 확보라는 첫걸음만으로도 앞서갈 수 있다는 뜻이기도 하다.
유휴 83%는 인프라의 실패가 아니다. 오케스트레이터에게 과도한 예약을 허용한 설계 결정들이 청구서라는 언어로 번역된 결과다. 청구서를 줄이는 팀은 더 싼 머신을 산 팀이 아니라, 비어 있는 예약을 설계 단계에서 허용하지 않는 팀이다.