매달 청구되는 클라우드 비용을 보며 한숨부터 나오는 스타트업이 적지 않다. 초기에는 빠른 서비스 출시에 집중하느라 인프라 비용까지 신경 쓸 여유가 없었고, 어느 순간 월 수백만 원이 넘는 청구서가 쌓여 있다. 이 글에서는 실제 스타트업들이 쿠버네티스 인프라를 어떻게 최적화해서 월 비용을 절반 가까이 줄였는지, 단계별 사례를 비교 분석한다. 끝까지 읽으면 우리 팀에 맞는 비용 절감 전략을 직접 설계할 수 있는 판단 기준을 얻게 된다.
비용 폭탄의 원인부터 파악해야 절감이 시작된다
어디서 새는지 모르면 막을 수 없다
많은 스타트업이 처음 쿠버네티스를 도입할 때 리소스 요청(requests)과 제한(limits)을 넉넉하게 잡는다. 장애가 무서우니까. 그런데 이 ‘넉넉함’이 곧 낭비가 된다. CNCF 연간 조사에 따르면 쿠버네티스를 운영하는 조직 중 68%가 실제 사용량 대비 과다 프로비저닝 상태라고 응답했다.
한 국내 SaaS 스타트업의 사례를 보면, 20인 규모 팀에서 AWS EKS 클러스터에 월 1,200만 원을 지출하고 있었다. 원인 분석 결과 CPU 평균 사용률은 12%, 메모리는 28%에 불과했다. 나머지 자원은 그냥 돈을 태우고 있었던 셈이다.
비용 가시성 확보가 첫 번째 과제
Kubecost나 OpenCost 같은 도구를 붙이면 네임스페이스별, 워크로드별 비용이 눈에 보인다. 이 단계를 건너뛰고 바로 인스턴스 타입을 바꾸거나 스팟을 도입하면, 어디가 효과적이었는지 측정 자체가 안 된다. 쿠버네티스 비용 모니터링 도구 비교 체크리스트를 참고하면 도구 선택에 도움이 된다.
스타트업 쿠버네티스 클라우드 비용 절감, 노드 사이징 재설계에서 시작하기
과잉 스펙 노드를 걷어내는 과정
앞서 언급한 SaaS 스타트업은 c5.2xlarge(8코어, 16GB) 노드 6대로 클러스터를 운영했다. 실제 파드들의 리소스 요청 합산을 분석해보니 4코어 노드 4대면 충분했다. 문제는 단순히 작은 인스턴스로 교체하는 것이 아니라, 파드 간 bin-packing 효율까지 고려해야 한다는 점이다.
비교하면 이렇다.
- 변경 전: c5.2xlarge × 6대 → 월 약 780만 원(온디맨드 기준)
- 변경 후: c5.xlarge × 4대 + 오토스케일링 → 월 약 310만 원
- 절감 효과: 약 60%
다만 노드를 작게 쪼개면 시스템 데몬셋(kube-proxy, aws-node 등)이 차지하는 오버헤드 비율이 올라간다. 너무 작은 인스턴스를 선택하면 오히려 비효율적이다. 노드당 최소 4코어 이상을 권장하는 이유가 여기에 있다.
스팟 인스턴스와 오토스케일링, 어떤 조합이 실제로 효과적이었을까
스팟 도입 시 생긴 장애와 극복 방법
또 다른 핀테크 스타트업 사례가 흥미롭다. 이 팀은 비용 절감을 위해 전체 워크로드의 80%를 스팟 인스턴스로 전환했다가 한 달 만에 롤백했다. 결제 처리 파드가 스팟 회수(interruption) 때 비정상 종료되면서 트랜잭션 유실이 발생한 것이다.
이후 전략을 수정했다. Stateless 워크로드(API 서버, 배치 작업)만 스팟으로, Stateful 워크로드(결제, DB)는 온디맨드로 분리 운영하는 혼합 전략을 채택했다. 결과적으로 온디맨드 대비 약 45% 비용 절감에 성공하면서도 장애 발생률은 스팟 전면 도입 때의 1/10 수준으로 떨어졌다.
Karpenter vs Cluster Autoscaler
오토스케일링 도구 선택도 비용에 직접 영향을 미친다. Cluster Autoscaler는 노드 그룹 단위로 스케일링하기 때문에 반응 속도가 느리고, 인스턴스 타입이 고정된다. 반면 Karpenter는 파드의 리소스 요청을 실시간으로 분석해서 최적의 인스턴스 타입을 자동 선택한다.
실제 적용 사례를 살펴보면, 커머스 스타트업 한 곳이 Cluster Autoscaler에서 Karpenter로 전환한 뒤 노드 프로비저닝 시간이 평균 4분에서 45초로 단축됐고, 유휴 자원 비율도 35%에서 15%로 줄었다. 이것만으로 월 180만 원을 추가 절감한 셈이다.
중간 점검, 실제 절감 효과를 어떻게 검증할 것인가
숫자로 증명해야 지속된다
비용 최적화를 진행하면서 가장 자주 빠지는 함정이 있다. 처음 한두 달은 효과가 극적으로 나타나지만, 이후 트래픽이 늘거나 새 서비스가 추가되면 비용이 다시 올라가는 패턴이다. 이를 막으려면 주 단위로 다음 지표를 추적해야 한다.
- CPU/메모리 사용률: 목표 60~70% 유지
- 파드당 비용: Kubecost의 cost-per-pod 메트릭
- 노드 bin-packing 효율: 할당된 리소스 대비 실제 사용 비율
- 스팟 인터럽션 빈도: 주당 발생 횟수와 복구 시간
한 가지 주의할 점이 있다. 비용만 극단적으로 줄이면 안정성이 희생된다. 앞서 소개한 핀테크 사례처럼 모든 워크로드에 동일한 절감 전략을 적용하는 것은 위험하다. 쿠버네티스 공식 문서의 파드 스케줄링 가이드에서도 워크로드 특성에 따른 분리 배치를 권장하고 있다.
월 비용 50% 줄인 인프라 최적화, 핵심 전략 요약과 다음 단계
세 가지 레버를 동시에 당겨야 효과가 난다
지금까지 살펴본 사례들을 종합하면 비용 절감은 단일 전략으로 달성하기 어렵다. 노드 사이징 최적화, 스팟 혼합 운영, 오토스케일러 고도화를 함께 적용했을 때 비로소 50% 이상의 절감 효과가 나타났다. 아래 표로 정리하면 각 전략별 기대 절감 수준이 명확해진다.
- 노드 라이트사이징 단독 → 20~30% 절감
- 스팟 혼합(60:40) 추가 → 누적 35~45% 절감
- Karpenter 전환 추가 → 누적 45~55% 절감
모든 팀에 같은 공식이 통하지는 않는다
트래픽 패턴이 불규칙한 서비스, GPU 워크로드가 포함된 ML 파이프라인, 규제로 인해 특정 리전에 묶인 인프라라면 절감 전략의 우선순위가 달라진다. FinOps Foundation의 프레임워크에서 제시하는 ‘Inform → Optimize → Operate’ 단계를 따르면 자사 상황에 맞는 접근법을 체계적으로 설계할 수 있다. 절감이 가능하다고 해서 무조건 빠르게 적용하는 것보다, 워크로드를 분류하고 우선순위를 정하는 과정이 먼저다.
결론
쿠버네티스 비용 절감의 핵심은 세 가지다. 비용 가시성 확보, 노드 사이징 재설계, 스팟과 오토스케일링의 전략적 조합. 오늘 당장 할 수 있는 첫 걸음은 Kubecost나 OpenCost를 클러스터에 설치해서 현재 리소스 사용률부터 확인하는 것이다. 그 숫자가 보여야 어디를 먼저 손댈지 판단할 수 있다. 팀 차원의 비용 거버넌스로 확장하고 싶다면, 클라우드 거버넌스 체크리스트부터 점검해 보길 권한다.