Kubernetes 비용 관리 도구 비교기: OpenCost vs Kubecost, 그리고 AWS SCAD까지

시작은 늘 그 질문이었다

쿠버네티스를 운영하는 팀이라면 한 번쯤 겪는 장면이 있습니다. 월말 클라우드 요금 고지서를 열고 "어? 이번 달 왜 이렇게 많이 나왔지?" 하고 잠깐 멈칫하는 순간이요. AWS Cost Explorer를 켜봐도 EC2, EBS, 로드 밸런서 항목만 보일 뿐, 정작 알고 싶은 건 안 보이더라고요.

• 어떤 네임스페이스가 비용을 끌어올리고 있는지
• 어떤 파드가 리소스를 많이 잡아먹는지
• 실제로 쓰는 비용과 그냥 예약만 걸어둔 유휴 비용이 각각 얼마인지

특히 마지막이 쿠버네티스의 진짜 함정이었습니다. 노드 비용은 실제로 지불하지만, 파드는 리소스 요청량(request) 기준으로 스케줄링되거든요. 어떤 팀이 "혹시 몰라서" CPU 4개를 요청해놓고 실제로는 절반만 쓰더라도, AWS 청구서에는 그 비효율이 한 줄도 드러나지 않습니다. 청구서는 노드 단위로만 말을 하고, 그 노드 안에서 무슨 일이 벌어지는지는 침묵하죠.

금융권에서 OpenAPI나 결제 플랫폼을 운영하면서 비슷한 구조를 자주 봤습니다. 자원을 잡아두는 쪽과 비용을 청구받는 쪽의 단위가 어긋나면, 누군가는 반드시 "우리 팀이 진짜 이만큼 썼냐"고 따지기 시작합니다. 그 질문에 숫자로 답하지 못하면 비용 논의는 늘 감정 싸움으로 끝나더라고요.

그래서 비용 측정 도구를 찾기 시작했고, 가장 먼저 눈에 띈 것이 OpenCost였습니다.

OpenCost, 생각보다 탄탄한 기반

OpenCost는 쿠버네티스와 클라우드 비용을 실시간으로 측정하고 할당하는 오픈소스 프로젝트입니다. CNCF 인큐베이팅 프로젝트이고 Apache 2.0 라이선스라 무료로 쓸 수 있어요.

흥미로운 건 출발점입니다. 원래는 Kubecost가 개발한 비용 할당 엔진에서 시작됐거든요. Kubecost가 이 엔진을 오픈소스로 풀면서 AWS, Google, Microsoft, Adobe 같은 곳이 참여했고, 쿠버네티스 비용 계산 방식에 대한 일종의 명세를 함께 만들어낸 결과물이 지금의 OpenCost입니다. 경쟁 제품의 핵심 엔진이 표준의 씨앗이 된 셈인데, 이런 구조는 꽤 드뭅니다.

"비용 모니터링의 프로메테우스"가 되겠다는 목표처럼, 다른 도구들이 기반으로 삼을 수 있는 중립적인 데이터 계층을 만드는 게 핵심이에요. 클러스터, 노드, 네임스페이스, 파드처럼 우리가 실제 머릿속에서 쓰는 단위로 비용을 할당해주고, CPU, GPU, 메모리, 영구 볼륨까지 계산에 넣습니다.

EKS에 설치해보기

설치는 예상보다 단순했습니다. 좋은 의미로요.

알아둘 점이 두 가지 있습니다. OpenCost는 공식 Helm 차트로만 설치되고(예전의 독립 매니페스트는 제거됐습니다), Prometheus가 필수입니다. OpenCost는 메트릭을 스스로 수집하지 않고, Prometheus에 쌓인 사용량 데이터를 읽어 비용을 계산하거든요. 즉 OpenCost는 계산기지 저장소가 아니라는 뜻인데, 이 점이 나중에 발목을 잡습니다.

helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm repo update
helm install opencost opencost/opencost --namespace opencost --create-namespace

파드가 뜨자마자 UI로 포트 포워딩을 걸어 처음으로 클러스터를 비용 관점에서 들여다봤습니다. 네임스페이스별, 파드별 비용은 물론이고 요청한 리소스와 실제 사용한 리소스를 비교해주는 효율성 뷰까지. 딱 제가 원하던 그림이었어요.

그리고 며칠 그대로 켜뒀습니다.

현실과 마주한 순간

며칠 지나자 OpenCost UI의 데이터가 사라지기 시작했습니다. 과거 기록을 더 이상 불러오지 못하는 거예요.

저만 겪은 일이 아니었습니다. 커뮤니티 토론을 뒤져보니 같은 불만이 반복적으로 올라오더라고요. "OpenCost를 설정했고 데이터는 나오는데, 일주일쯤 지나면 과거 데이터를 볼 수 없다"는 식의 글들이었어요.

해결책으로 타임아웃 조정이니 로컬 실행이니 여러 방법이 제시되지만, 오래 써본 사람들의 대답은 한결같았습니다.

"데이터를 Prometheus로 내보내고 Grafana 대시보드를 쓰세요. 내장 UI보다 훨씬 낫습니다."

문제는 이게 임시방편이 아니라 의도된 아키텍처라는 점이었습니다. OpenCost에 딸린 UI는 단순 뷰어일 뿐 데이터 저장소가 아니에요. 실제 비용 내역은 Prometheus에 쌓이고, OpenCost 자체는 제한된 메모리 안에서 짧은 구간만 들고 있습니다.

결국 저는 OpenCost의 UI를 대시보드처럼 쓰려다 헛다리를 짚은 거였어요. 설계 의도는 OpenCost를 Prometheus에 데이터를 공급하는 엔진으로 두고, 대시보드는 Grafana에서 따로 세우는 구조였습니다.

이 차이가 생각보다 중요합니다. "OpenCost가 운영 환경에서 안 돌아간다"가 아니라, "OpenCost의 UI는 애초에 운영용 대시보드로 설계된 적이 없다"는 거니까요. 도구를 탓하기 전에 도구의 책임 범위를 잘못 읽은 쪽은 저였습니다.

다만 이 일로 한 발 물러서서 다시 생각하게 됐습니다. 제 상황에서 OpenCost + Prometheus + Grafana 조합이 정말 맞는 선택일까? 아니면 더 간단한 길이 있을까?

진짜 경쟁자, Kubecost

OpenCost의 실질적인 경쟁자는 Kubecost입니다. 둘 다 클러스터에 배포되고, 실시간 비용 할당을 처리하며, 같은 할당 엔진을 씁니다. 뿌리가 같으니 당연한 얘기죠.

Kubecost는 그 공유 엔진 위에 얹은 상용 제품인데, "상용"이라고 무조건 유료는 아닙니다. 무료 티어가 OpenCost 기본 설정보다 훨씬 많은 걸 해줘요.

Kubecost 무료 플랜은 단일 클러스터에 무제한 노드, 기록을 보존하는 내장 UI, 비용 절감 권장 기능을 제공합니다. 멀티 클러스터, 장기 기록 보존, SSO/RBAC, 요금 정산 기능은 유료 플랜(비즈니스 플랜 월 약 449달러부터)으로 넘어가고요.

EKS 사용자라면 잘 안 알려진 혜택이 하나 있습니다. EKS에 최적화된 Kubecost 번들이에요. AWS와 Kubecost가 공동 개발한 번들로, 일반 무료 티어 기능 외에 일부 상용 기능까지 추가 비용 없이 쓸 수 있습니다. 특히 Kubecost v3 무료 티어의 30일당 10만 달러 사용 한도에서 제외되기 때문에, EKS 사용자에게는 그 한도 자체가 문제되지 않아요.

EKS 설치 방법

OpenCost와 달리 Kubecost는 자체 Prometheus를 품고 있어서 기존 Prometheus가 없어도 됩니다. AWS는 두 가지 설치 경로를 제공해요.

1. EKS 애드온: EKS 콘솔이나 AWS CLI에서 바로 설치하는 가장 간단한 방법
2. Helm: 구성을 더 세밀하게 제어하고 싶을 때

중요한 변경이 하나 있습니다. Kubecost v3부터 Helm 차트가 ECR의 OCI 레지스트리로 옮겨갔다는 점이에요.

helm upgrade -i kubecost \
  oci://public.ecr.aws/kubecost/cost-analyzer \
  --namespace kubecost --create-namespace \
  -f https://raw.githubusercontent.com/kubecost/cost-analyzer-helm-chart/develop/cost-analyzer/values-eks-cost-monitoring.yaml

⚠️ 주의사항: Kubecost는 영구 저장소가 필요합니다. EKS 환경에서는 EBS CSI 드라이버가 깔려 있어야 해요. 파드가 Pending 상태로 멈춰 있다면 kubectl get pvc -n kubecost로 PersistentVolumeClaim 상태부터 확인해보세요. 경험상 비용 도구를 설치하다 막히는 지점의 절반은 스토리지에서 나옵니다.

AWS SCAD, 세 번째 선택지?

이쯤 되면 누군가는 묻습니다. "굳이 별도 도구를 깔아야 하나? AWS가 기본으로 안 주나?" 그 자리에 등장하는 게 **EKS용 AWS 분할 비용 할당 데이터(SCAD)**입니다.

그런데 SCAD는 OpenCost, Kubecost와 경쟁하는 제3의 선택지가 아닙니다. 범주 자체가 다른 도구예요.

OpenCost와 Kubecost는 비용 모니터링 도구입니다. 클러스터 안에서 돌면서 엔지니어에게 실시간 효율성 분석을 던져주죠. 반면 SCAD는 AWS 청구서에 정보를 덧붙이는 청구 데이터 기능이에요.

• SCAD: 재무 부서에 → "각 네임스페이스에 얼마가 청구됐나?"
• OpenCost/Kubecost: 엔지니어에게 → "지금 어디서 낭비가 나고 있나?"

같은 비용을 보더라도 보는 자리가 다릅니다. 한쪽은 청구서를 정산하려는 자리, 한쪽은 낭비를 잡으려는 자리예요. 이 둘을 한 도구로 욱여넣으려 하면 양쪽 다 어정쩡해집니다.

SCAD는 EC2 노드의 비용을 파드 수준까지 쪼개고, AWS 청구 데이터 위에 쿠버네티스 관련 항목을 표시합니다. 2025년 말부터는 최대 50개의 사용자 지정 쿠버네티스 파드 레이블을 비용 할당 태그로 가져올 수 있어서, 팀이나 환경별로 비용을 나눠 볼 수 있어요.

SCAD 설정하기

넘어가기 전에 중요한 점 하나를 짚겠습니다. SCAD 데이터는 AWS Cost Explorer에 안 보입니다. AWS 공식 문서에도 명시된 내용이에요. 분할 비용 할당 데이터는 비용 및 사용량 보고서(CUR)와 CUR 2.0의 데이터 내보내기를 통해서만 확인할 수 있습니다. Cost Explorer만 열어보고 "왜 SCAD 데이터가 없지?" 하며 헤매기 딱 좋은 함정이죠.

설정은 2단계 선택 방식이고, 관리/결제 계정에서만 할 수 있어요.

1. SCAD 활성화: AWS 청구 및 비용 관리 콘솔 → 비용 관리 기본 설정 → 일반 → 분할 비용 할당 데이터에서 Amazon EKS 선택

   비용 할당 방법은 세 가지입니다:

   • 리소스 요청: 파드의 CPU/메모리 요청량 기준 (가장 간단)
   • Amazon Managed Service for Prometheus: 요청량과 실제 사용량 중 높은 값 기준 (더 정확하지만 AMP 워크스페이스 필요)
   • Amazon CloudWatch Container Insights: CloudWatch 에이전트를 쓸 때의 대안

2. CUR에서 활성화: 새 비용 및 사용량 보고서에 분할 비용 할당 데이터 추가

약 24시간 안에 보고서에 파드 수준 데이터가 나타나기 시작합니다. 이후 Athena로 CUR을 쿼리하고 QuickSight에서 시각화하면 돼요. 실시간 대시보드가 아니라 청구 사이클을 따라가는 데이터라는 점, 이걸 기억하면 기대치가 어긋나지 않습니다.

실제로 무엇을 선택할 것인가

여기서 한 가지 정리하고 갑니다. 이건 셋 중 하나를 고르는 3자 경쟁이 아니라, 서로 다른 두 개의 결정입니다.

첫 번째 결정: OpenCost vs Kubecost

OpenCost를 선택할 만한 경우:

• 실시간 효율성과 적정 규모 조정이 필요
• Prometheus/Grafana 운영에 부담이 없음
• 완전한 벤더 중립성과 CNCF 인증을 중시
• 자체 대시보드나 플러그인 생태계를 활용하고 싶음

단, Prometheus와 Grafana를 함께 세워야 하고, 내장 UI를 대시보드로 착각하면 안 됩니다. 앞에서 제가 밟은 지뢰가 바로 이거였어요.

Kubecost 무료 티어를 선택할 만한 경우:

• 단일 클러스터에서 최소 노력으로 바로 돌릴 솔루션을 원함
• 기록을 유지하는 UI와 비용 절감 추천 기능이 필요
• 소규모 단일 클러스터 운영 (가장 실용적)

두 번째 결정: SCAD 사용 여부

SCAD는 앞선 도구를 대체하는 게 아니라 함께 얹는 겁니다. 재무 부서에서 청구서 기준의 정확한 비용 내역이 필요하다면 SCAD를 활성화하세요. 실제로 많은 팀이 재무 정산용으로는 SCAD를, 엔지니어링 효율성 분석용으로는 OpenCost나 Kubecost를 같이 씁니다.

주의할 점이 하나 있습니다. OpenCost와 Kubecost 무료 서비스 모두 온디맨드 정가 기준으로 가격을 매깁니다. 절약형 플랜, 예약 인스턴스, 스팟 인스턴스를 쓴다면 도구가 보여주는 숫자와 실제 청구 금액이 딱 맞지 않을 수 있어요. 효율성 추세를 보는 데는 충분하지만, "이게 그대로 청구액"이라고 믿으면 곤란하다는 뜻입니다.

결국 내린 결론

제 경우는 단일 EKS 클러스터, 노드 몇 개, 그리고 Grafana 스택까지 따로 세우지 않고도 돌아가는 솔루션을 선호하는 환경이었습니다. 그래서 클러스터 내 도구로는 Kubecost의 무료 EKS 번들을 쓰고, 재무 부서에서 정확한 비용 청구가 필요할 때 SCAD를 별도로 활성화하기로 정했습니다.

OpenCost로 시작한 걸 후회하지는 않습니다. 직접 배포해보면서 배운 게 있거든요. 비용 엔진과 비용 대시보드는 서로 다른 문제라는 것, "무료"라는 단어 안에 여러 의미가 섞여 있다는 것, 그리고 "AWS 기본 제공"과 "쿠버네티스 기반 비용 도구"는 같은 비용을 다루더라도 완전히 다른 영역이라는 것을요. 이런 건 비교표만 봐서는 안 보이고, 며칠 켜뒀다가 데이터가 사라지는 걸 직접 겪어야 몸에 남더라고요.

쿠버네티스를 운영하면서 "이 네임스페이스가 얼마 쓰고, 그중 낭비는 얼마냐"는 질문에 답하지 못한다면, 그건 작은 문제가 아닙니다. 다행히 그 답을 만들어주는 도구는 대부분 무료로 깔려 있어요. 진짜 갈림길은 도구의 유무가 아니라 자리의 문제입니다. 지금 풀려는 게 엔지니어링 효율성인지 재무 비용 청구인지를 먼저 정하고, 그 자리에 맞는 도구를 고르는 것. 순서를 바꾸면 멀쩡한 도구를 깔아놓고도 계속 헛다리를 짚게 됩니다.