Kubecost 해설: 청구액을 실제로 바꾸는 Kubernetes FinOps

Kubecost는 OpenCost 위에 구축된 Kubernetes 비용 배분·최적화 플랫폼으로, 클러스터 텔레메트리를 클라우드 제공자의 청구 데이터와 결합해 지출을 네임스페이스, 워크로드, 팀이라는 실제 오너에게 귀속시킵니다. 청구서에 추정치가 아닌 책임자가 필요할 때 도입하세요. 다만 그 수치는 클라우드 청구 정합화 이후에야 신뢰할 수 있고, 절감으로 이어지는 것은 운영 리듬과 짝지었을 때뿐입니다.

대부분의 플랫폼 팀은 Kubernetes 비용에 익숙합니다. 월간 클라우드 청구서가 도착하고, 재무팀은 왜 더 늘었는지 묻고, 엔지니어링은 "워크로드가 더 늘었어요"라고밖에 답하지 못합니다. 청구서가 보여주는 것과 플랫폼 팀이 설명할 수 있는 것 사이의 이 간극이 바로 FinOps가 운영 비용 최적화를 위해 해결하려는 문제입니다. 진짜 질문은 이 일을 위해 엔터프라이즈 플랫폼이 필요한가입니다. 대부분의 팀에게는 그렇지 않다는 답이 나옵니다. OpenCost와 Kubecost는, 운영 리듬과 짝지어 쓴다면 플랫폼 팀이 필요한 가시성을 제공해 줍니다.

압력은 실재한다

Kubernetes 비용 회계는 더 이상 단일 클러스터나 단일 클라우드의 문제가 아닙니다. 대부분의 팀은 클러스터 플릿을 운영하며, 여러 클라우드 제공자를 가로지르는 경우도 많고, 온프레미스 컨트롤 플레인과 매니지드 서비스를 함께 쓰기도 합니다. 컨테이너는 노드 간을 이동하고, 노드는 영역 간을 이동하며, 같은 워크로드가 지연 또는 컴플라이언스 요구를 충족하기 위해 여러 리전에서 실행되기도 하므로 비용 귀속은 더 어려워집니다.

업계 데이터는 같은 문제를 수년 동안 보여 왔습니다. 2021년 CNCF FinOps 설문은 대부분의 팀이 Kubernetes 지출을 안정적으로 측정하지 못하며, 주된 이슈는 과다 프로비저닝과 책임 부재라고 진단했습니다. 2025년에도 같은 이야기였습니다. AWS, GCP, Azure에서 2,100여 조직의 실제 클러스터 데이터를 사용한 Cast AI 2025 Kubernetes Cost Benchmark에서, 평균 CPU 사용률은 10%, 메모리 사용률은 **23%**에 그쳤습니다. 이 수치들은 설문 응답이 아니라 프로덕션 텔레메트리에서 나온 것입니다. 4년이 지나도 문제는 변하지 않았고, 오히려 플릿이 커지면서 더 선명해졌습니다.

진짜 문제는 Kubernetes가 너무 비싸다는 게 아닙니다. 대부분의 팀이 자신들이 무엇에 돈을 쓰고 있는지에 대한 충분한 가시성을 갖고 있지 않다는 점입니다.

Kubecost는 실제로 무엇인가?

Kubecost는 비용 배분, 최적화, 거버넌스를 위한 Kubernetes 플랫폼입니다. 2024년 IBM이 인수한 이후, Kubecost는 오픈소스판과 엔터프라이즈판 모두를 제공합니다. 핵심은 OpenCost 위에 얹혀 있으며, 데이터 컬렉터, 클라우드 비용 인제스터, 예측 서비스, 노드별 네트워크 비용 DaemonSet, 빠른 ClickHouse 기반 어그리게이터 같은 여러 마이크로서비스로 구성된 클러스터 내 에이전트 스택으로 동작합니다. Kubernetes 텔레메트리를 클라우드 제공자의 청구 데이터와 결합해, Kubecost는 상세한 비용 배분 뷰를 제공하며, 클라우드 청구 통합을 구성하고 정합화하면 정확도가 올라갑니다.

플랫폼은 세 가지 기둥을 중심으로 만들어졌습니다.

• 비용 배분은 네임스페이스, 라벨, 서비스, 워크로드, 또는 Collection 단위로 지출을 집계합니다. Kubecost v3는 Kubernetes와 외부 클라우드 측 비용을 중복 제거된 단일 단위로 묶는 그룹화 개념을 추가했습니다. 비용은 CPU, 메모리, 영구 볼륨, GPU, 네트워크 트래픽에 걸쳐 추적됩니다.
• 최적화 권장사항은 실제 사용량에 근거해 적정 리소스 리퀘스트를 제안하고, 더 저렴한 노드 타입을 제안하며, 일률적인 디폴트 대신 분위수 기반의 컨트롤을 팀이 설정할 수 있게 해줍니다. 권장사항은 기록 보존을 위해 아카이브할 수 있고 CSV 또는 PDF로 내보낼 수 있습니다.
• 알림과 거버넌스는 구성 가능한 예산 액션, 스케줄 리포트, Slack/이메일 알림 형태로 제공됩니다. 알림은 별도의 알림 서브시스템이 아니라, 해당 예산 옆에 자리합니다.

Kubecost 설치는 어떻게 흘러가는가

비용 데이터 수집은 클러스터 내부에서 시작됩니다. 시작할 때 FinOps 에이전트는 가격 ConfigMap을 위해 Kubernetes API에 워치를 걸어 두어, 커스텀 가격 규칙을 재시작 없이 적용할 수 있게 합니다. 또한 노드별 가격을 해석합니다(클라우드 제공자 가격을 얻을 수 없을 때는 계산된 값으로 폴백). 그 다음 각 Network Costs DaemonSet 파드에서 메트릭을 수집하고, 새로운 바이너리 스냅숏을 생성하며, 구성되어 있다면 Azure Blob Storage나 AWS S3 같은 외부 스토리지에 씁니다.

Network Costs DaemonSet는 netlink 소켓을 통해 커널 conntrack 테이블을 구독해 각 플로우의 방향별 바이트와 패킷 카운터를 파싱하고, Kubernetes API 워치를 통해 파드, 노드, 서비스, 엔드포인트 상태를 메모리 내 맵으로 유지합니다. 이 맵을 사용해 관측된 연결을 특정 워크로드에 연결합니다.

이 에이전트들이 내부 스냅숏을 공유 스토리지로 보내는 동안, Cloud Cost Ingestor는 외부 재무 데이터를 관리합니다. 스케줄에 따라 실행되어 클라우드 제공자의 청구 내보내기에 연결하고, 일별 CSV를 가져오고, 과거 데이터를 백필합니다. 클라우드 제공자는 청구 데이터를 몇 시간 지연해서 공개하기 때문에, Kubecost는 짧게 기다린 뒤 클러스터 데이터와 클라우드 청구를 정합화합니다. 즉, 가장 최근 1~2일의 비용 데이터는 추정치일 뿐이며, 더 오래된 데이터는 (클라우드 청구 통합이 정상 동작한다는 전제하에) 완전히 정합된 상태가 됩니다.

Aggregator는 메인 엔진이며 임베디드 ClickHouse 데이터베이스를 사용합니다. 멀티 클러스터 배포에서는 여러 에이전트 클러스터의 스냅숏을 하나로 모읍니다. 구성을 위해 여러 ConfigMap을 확인하고, 아무것도 없으면 디폴트로 폴백합니다. 에이전트 스냅숏을 수집하고, 구성된 경우 외부 청구 CSV도 수집한 뒤, 이들을 다단계 SQL 파이프라인에 흘려보내 겹치는 비용을 정합화하고 중복 제거하며, 다른 마이크로서비스가 소비하는 최종 비용 테이블을 만들어 냅니다. Aggregator는 또한 ClickHouse에서 테이블별·해상도별 TTL을 설정하여 데이터 보존을 관리하므로, 세밀한 윈도우는 며칠 안에 만료되고 롤업은 수 주에서 수 개월 동안 유지됩니다.

마지막으로 Forecasting Service는 예측적 비용 모니터링 도구 역할을 하며, 이 데이터를 사용해 비용 예측을 생성합니다. 동시에 Cluster Controller는 Aggregator의 최적화 인사이트를 사용해 적정화 권장사항을 클러스터에 직접 적용하는 등 액션을 취합니다.

먼저 실제 오너에게 배분하라

Kubecost는 각 노드에서 실행 중인 파드들에 노드 비용을 분배합니다. 일반적으로는 리소스 리퀘스트로 가중치를 둔 뒤, 결과를 CPU, 메모리, PV, GPU, 네트워크에 걸쳐 네임스페이스, 라벨, 서비스, 워크로드, 또는 Collection 단위로 집계합니다.

이 접근을 효과적으로 만드는 것은 기술적 셋업만이 아니라 좋은 조직화입니다. 각 네임스페이스는 팀, 제품, 부서 같은 실제 오너와 맞물려야 합니다. 이 매핑이 자리 잡으면, 배분 뷰는 스프레드시트 없이도 어떤 팀이 어떤 비용을 책임지는지 보여줍니다. 이미 team, cost-center, product 같은 라벨을 쓰는 팀은 동일한 목적으로 이를 활용할 수 있고, Collections는 라벨 기반 뷰를 다루기 쉽게 해줍니다.

라벨은 시간이 지나면서 바뀔 수 있고, 네임스페이스는 늘어날 수 있으며, 누군가는 결국 default에 배포합니다. 매주 라벨이 없는 버킷을 검토하면 데이터를 정확하고 유용하게 유지하는 데 도움이 됩니다.

실제 사용량 기준으로 리퀘스트를 적정화하라

이것이 청구서를 가장 크게 움직이는 레버입니다. 개발자들은 보통 CPU와 메모리 리퀘스트를 방어적으로 설정한 뒤 다시 보지 않으며, 리퀘스트와 사용량의 간극은 그대로 청구서에 나타납니다. 앞서 인용한 "CPU 10% / 메모리 23%" 벤치마크는 재무팀이 수치를 요구할 때 활용할 수 있는 설득력 있는 근거입니다.

확실하게 절감을 찾아내는 패턴은 워크로드별로 몇 주 동안 리퀘스트 vs 실제 CPU와 메모리를 그려본 다음, 각 워크로드의 리퀘스트를 실제로 쓰는 만큼으로 내려주는 것입니다. 한 서비스 메시 배포의 실제 사례에서는 프록시 사이드카가 각각 100밀리코어로 설정되어 있었습니다. 노드는 서류상 약 200개의 파드를 수용할 수 있었지만, 모든 파드가 자기 자신의 요청 위에 100밀리코어의 사이드카 요청을 갖고 있었기에 스케줄러는 약 90개 파드 즈음에서 할당 가능한 CPU를 다 써버렸습니다. 리퀘스트 적정화를 거친 후, 노드당 파드 밀도는 애플리케이션 변경도, 노드 플릿 변경도 없이 세 배로 늘었습니다.

Kubecost 3.0은 이 루프를 더 단단하게 만듭니다. Container Request Sizing Insights는 사용량 시각화를 UI에 직접 보여주고, 권장사항을 아카이브할 수 있으며, CSV/PDF 내보내기에는 라벨이 포함되고, 분위수 기반 컨트롤로 예측 가능한 서비스에는 더 빡빡한 권장 백분위를, 버스트성 워크로드에는 더 느슨한 백분위를 설정할 수 있습니다. 엔터프라이즈 티어는 커스텀 프로파일, 일시 정지 제어, 감사 이력, 권장 절감액과 실현된 절감액의 비교를 갖춘, 클러스터 전반에서 동작하는 Automated Container Request Sizing UI를 더합니다. 오픈소스 티어는 EKS 프라이머리 클러스터에서 최대 250코어까지의 무료 할당을 받습니다.

프로덕션에서는 보통 분위수 기반 권장 정책이 가장 효과적인 접근입니다.

• CPU 리퀘스트를 지난 1주 또는 1개월 실제 CPU 사용량의 90백분위에 맞추고, 거기에 안전 마진을 더합니다. Kubernetes VPA의 디폴트는 CPU에서 약 15%입니다. CPU는 시분할 공유되므로, 여유가 있을 때 커널은 버스트성 워크로드에 추가 용량을 쓰게 해줍니다. 드문 스파이크를 대비해 패딩을 더 늘려도 보통은 리퀘스트만 늘릴 뿐 큰 이득은 없습니다.
• 메모리 리퀘스트는 피크 사용량의 높은 백분위에 맞추고, 거기에 안전 마진을 더합니다. 메모리는 시분할 공유가 아니므로 한도를 넘기면 점진적 성능 저하가 아니라 OOM 킬이 발생할 수 있습니다. 피크의 약 90백분위를 목표로 잡고, 마진을 더하세요. VPA의 디폴트는 메모리에서 약 20%입니다.

이 설정이 QoS 클래스를 결정합니다. 파드가 Guaranteed로 간주되는 것은 모든 컨테이너의 CPU와 메모리 리퀘스트가 리밋과 같을 때뿐입니다. 어느 한 컨테이너라도 그렇지 않으면 파드 전체는 Burstable로 다뤄지고, 모든 컨테이너가 리퀘스트나 리밋을 설정하지 않으면 BestEffort로 다뤄집니다. 이 셋업은 대부분의 워크로드에 잘 맞습니다. 완전한 Guaranteed 클래스는 엄격한 지연 SLA를 가진 중요한 워크로드를 위해 남겨두고, 그 경우 CPU와 메모리 리퀘스트를 리밋과 일치시키세요. 그러면 약간의 헤드룸은 낭비될 수 있지만, 최선의 축출 보호와 필요하다면 전용 CPU 핀닝까지 얻을 수 있습니다.

이 모든 것을 자동화하기 전에 추가 피드백을 받고 싶다면, VPA를 몇 주 동안 권장 전용 모드로 돌리거나 오픈소스 KRR을 사용할 수 있습니다. KRR, VPA 권장 모드, Kubecost의 권장값을 비교해 보는 편이 어느 한 도구의 숫자만 믿는 것보다 더 신뢰할 만합니다.

캐퍼시티 대비 리퀘스트를 북극성 지표로

클러스터 효율성에 대해 가장 많은 것을 알려주는 비율은 CPU와 메모리에 걸친 총 파드 리퀘스트 ÷ 총 노드 할당 가능 용량입니다. 즉, 지불하는 용량 중 얼마나 많은 부분이 실제로 파드에 의해 요청되는가입니다. 이것이 Kubecost의 리퀘스트 적정화가 기반으로 삼는 지표입니다. Kubecost는 권장사항을 계산하는 기준이 되는 여러 타깃을 함께 제공합니다. Production 0.65, Development 0.80, High Availability 0.50 (Cluster Right-Sizing API). 이보다 낮으면 누구도 요구하지 않는 용량을 짊어지고 있는 것이고, 이보다 높으면 해당 클러스터 클래스가 유지해야 할 헤드룸을 다 써버린 것입니다. Kubecost는 또한 맥락에 따라 사이징에 쓸 사용률을 골라 씁니다. Development는 추세 85백분위, Production은 98백분위, HA는 99.9백분위이며, 단 1일 윈도우에서만 그렇습니다. 더 긴 윈도우에서는 최대 사용량이 쓰입니다. 자주 인용되는 "85백분위"는 Development의 1일 디폴트일 뿐이며 보편적인 설정이 아닙니다.

당신이 보는 것은 이 비율이고, 이를 움직이는 것은 오토스케일러(Karpenter, Cluster Autoscaler)입니다. 단, 리퀘스트가 정직할 때만 그렇습니다. 그래서 Kubecost의 리퀘스트 적정화가 어떤 오토스케일링 이야기보다도 상류에 자리합니다. 오토스케일러는 리퀘스트에 반응하고, Kubecost는 그 리퀘스트가 현실을 반영하는지를 말해줍니다.

최근 며칠의 데이터는 설계상 방향성만 보여줍니다. 정합화에는 하루치 청구 데이터가 필요하므로, 약 48시간 윈도우 동안 비용은 노드가 온디맨드가 아니라는 것을 입증할 수 없는 한 공개 온디맨드 가격으로 남습니다. Spot은 별도로 구성한 AWS Spot Data Feed를 통해서만 더 일찍 정확해집니다 (Cloud Billing Integrations). 효율은 정합된 가격과 별개로, 비용과 분리해서 읽으세요. Node Group Sizing(v3.0에서 재구축된, 예전의 Cluster Right-Sizing)은 이를 액션으로 바꿉니다. 구성 가능한 윈도우 동안 클러스터 내 CPU, RAM, GPU 사용률을 노드 용량 대비 분석하고, 노드 그룹별로 노드 수 변경이나 인스턴스 타입 전환을 권장합니다. 프리셋 프로파일 또는 커스텀 메트릭(usage.max/p95/p85/avg 또는 request.max/avg)에서 실행되며, 리소스별 타깃 사용률 임계값을 가지고 있고, 평균 요청 리소스보다 아래로는 절대 가지 않습니다. 각 제공자의 표준 라벨로 노드 그룹을 감지하므로 EKS, AKS, GKE에서 별도 셋업 없이 동작합니다 (v3.x 문서).

항상 켜져 있을 필요가 없는 워크로드를 찾아라

배분과 적정화를 처리했다면, 그럴 필요가 없는데도 종일, 매일 돌아가는 워크로드를 살펴보세요. 한 플랫폼 팀의 리뷰에서, 워크로드의 31%가 거의 하루 종일 CPU의 25%도 채 쓰지 않았는데도 Kubernetes 비용은 그 해에 약 18% 늘었습니다. 엔지니어들이 용량 튜닝과 알림 대응에 많은 시간을 썼고, 팀마다 오토스케일링 규칙을 제각각으로 설정했기 때문입니다.

분류는 세 가지 버킷으로 나뉩니다. 진짜로 과한 스펙을 가진 프로덕션 서비스는 위의 적정화 루프로 돌려보내야 합니다. 비프로덕션 환경(dev, integration, demo)은 주말이나 야간에 돌아갈 필요가 거의 없으니, 이 범주에서는 스케줄 기반 scale-to-zero가 가장 ROI 높은 변경입니다. 재시도 허용도가 있는 배치 및 스테이트리스 워크로드는 약 2분의 중단 통지와 맞바꾸어 약 90% 할인을 받을 수 있는 Spot 인스턴스의 후보입니다.

Kubecost는 사용도가 낮은 워크로드를 찾는 데 도움을 줍니다. Kubecost 3.0의 Advanced Filters로 UI에서 곧바로 AND/OR 조건을 사용해 네임스페이스, 라벨, 서비스로 워크로드를 빠르게 정렬할 수 있습니다. 다른 곳에서 작업할 필요가 없습니다.

약정 커버리지와 사용률을 따로 추적하라

예약 용량과 절감 약정은 불필요한 클라우드 비용의 흔한 원천입니다. 팀은 종종 이를 무시하고 전액 온디맨드 가격을 내거나, 사놓고서는 실제로 쓰이고 있는지 확인하지 않아 더 이상 필요 없는 리소스의 할인을 그대로 두기도 합니다. 주의해야 할 두 가지 중요한 지표가 있으며 서로 헷갈리기 쉽습니다.

• 커버리지는 약정으로 보호되는 정규 사용량의 비율입니다.
• 사용률은 약정을 실제로 얼마나 쓰고 있는지를 뜻합니다.

클라우드 제공자마다 도구는 다르지만, 모두 세 가지 주요 유형 중 하나에 들어맞고, 계산 방식은 어디서나 동일합니다.

좋은 접근은 100%를 노리는 대신 약정 사용률을 80%~95% 사이로 유지하는 것입니다. 100%를 노리면 미사용 인스턴스 제거, 인스턴스 타입 변경, 트래픽 감소 대응 같은 일상적 변경의 여지가 없어집니다. 분기 리뷰에서는 효율적으로 보일 수 있지만 일상 운영에서는 문제를 일으킵니다. 커버리지는 60%~75%를 노리는 것이 합리적입니다. 이 범위는 좋은 할인을 받기에 충분히 높으면서 분기마다의 변경을 허용할 만큼 낮습니다. 이 범위들은 클라우드 제공자가 정한 규칙이 아니라 실무 경험에 기반한 것입니다.

Kubecost에서는, 실제 클라우드 청구서가 준비될 때까지 우선 클라우드 제공자의 공개 온디맨드 가격으로 비용을 추정합니다. 청구서가 일반적으로 약 48시간 안에 사용 가능해지면, Kubecost는 추정치를 실제 비용으로 갱신합니다. 이 갱신에는 Reserved Instances, Savings Plans, 약정 요금, Spot 가격, 그리고 Enterprise Discount Program 같은 특별 요율이 포함됩니다.

언제 상용 FinOps 플랫폼을 대신 써야 할까?

대부분의 팀은 오픈소스 차트로 시작해야 합니다. 필요가 커진 다음에 상용 티어를 살펴봐도 늦지 않습니다.

몇 개의 클러스터에서 네임스페이스별 배분, 기본 권장사항, Slack 알림만 필요하다면 오픈소스 버전으로 충분합니다. 하지만 여러 클라우드에 걸친 다수의 클러스터를 운영하고, 자동 수정이 필요하며, 벤더 관리 이력을 원하거나, 재무팀에 상세하고 정합된 할인 수치를 제공해야 한다면 상용 플랫폼은 그만한 값을 합니다. 결정은 이런 필요에 기반해야 하며, 단순히 대시보드가 어떻게 생겼는지에 기반해서는 안 됩니다.

운영의 현실

• ClickHouse와 통합 에이전트가 옛 스택을 대체한다. v3에서는 2.x의 DuckDB 저장소가 ClickHouse 데이터베이스로 교체되었습니다. 이 변화로 배분과 클라우드 비용 API 쿼리가 규모가 큰 환경에서도 훨씬 더 빠르고 안정적이게 됩니다. 또한 Prometheus의 필요성을 없애 메모리 사용을 줄이고 배포를 쉽게 만들면서도, 여전히 OpenCost 표준 메트릭을 제공합니다.

• 이력은 기본값이 아닌 의도적 선택이다. 어떤 스토리지 백엔드를 쓰든, 보존 기간이 만들 수 있는 기간별 비교 보고의 상한선입니다. 월별 리포트는 최소 30일을, 전년 동기 대비는 1년을 필요로 합니다. 클러스터 내 보존 비용이 계층화 파이프라인을 구축하는 엔지니어링 시간보다 빠르게 늘어난다면 콜드 데이터를 오브젝트 스토리지로 계층화하세요.

• 정합화 지연은 구조적이다. 24~48시간의 청구 정합화 지연은 Kubecost의 속성이 아니라 클라우드 제공자 청구 내보내기의 속성입니다. 그 위에서 운영 모델을 세우세요. 어제가 아니라 지난주 데이터를 기준으로 논의하세요.

• 멀티 클러스터에는 전략이 필요하다. 오픈소스 Kubecost는 클러스터 간 페더레이션이 가능하지만, 그 경험은 상용 멀티 클러스터 어그리게이터보다 거칩니다. 다섯이나 여섯 개를 넘는 클러스터에서는 클러스터별 Kubecost를 돌리고 외부에서(예컨대 자체 웨어하우스에서) 집계할지, 아니면 상용 멀티 클러스터 경로에 비용을 지불할지 일찍 결정하세요. 둘 다 옹호할 수 있지만, 둘 사이에서 표류해서는 안 됩니다.

• EKS 애드온이 빠른 시작 경로를 제공한다. Kubecost v3 무료 티어는 30일 동안 미화 10만 달러의 지출 한도를 갖지만, Amazon EKS 최적화 Kubecost 번들은 AWS에서 그 지출 한도의 예외로 명시되어 있습니다.

• 운영 모델이 결과물이다. 팀이 Kubecost를 설치하지만 정기 리뷰를 마련하지 않으면, FinOps 도구가 없는 팀과 똑같이 표류합니다. 표준 접근은 플랫폼 엔지니어, 재무 분석가, 로테이션 중인 SRE 같은 작은 FinOps 그룹을 두고, 매주 만나 캐퍼시티 대비 리퀘스트 비율을 검토하고, 가장 과다 프로비저닝된 워크로드를 식별하며, 월별 비용에 큰 변화가 있는 네임스페이스를 점검하는 것입니다. 더 작은 팀이라면 플랫폼 엔지니어와 CTO가 격주로 30분만 리뷰해도 같은 결과를 얻을 수 있습니다.

실무적 권고

Kubernetes 플랫폼에 FinOps 접근을 검토 중이고 상용 제품을 선택할 계약상 의무가 없다면, 오픈소스 Kubecost 3.x를 파일럿하는 것부터 시작하세요. 설치는 한 오후면 끝낼 수 있습니다. 적어도 하나의 네임스페이스를 지정 오너에게 할당하고, 한 팀에 2주 동안 리퀘스트 대비 사용량 대시보드를 제공하며, 플랫폼 팀이 볼 수 있는 채널에 캐퍼시티 대비 리퀘스트 비율을 공유하세요. 이 지표들의 정기적 리뷰가 일상이 된다면 FinOps가 자리 잡은 것입니다. 그렇지 않다면 상용 플랫폼을 도입한다고 해도 근본 문제는 해결되지 않습니다.