클라우드 청구서에서 낭비 찾는 법: 31개 점검 항목 전체 공개

---

기업들은 클라우드 지출의 평균 29%를 낭비한다. Flexera가 매년 내는 State of the Cloud 2026년판 수치이고, 5년 만의 최고치다. AI 워크로드가 늘면서 낭비율이 다시 올라갔다. 스타트업 구간은 더 심해서 30~40%로 추정된다.

월 3,000만 원을 쓰는 회사라면 매달 900만 원 안팎이 유휴 인스턴스와 잊힌 볼륨, 구세대 사양 속으로 사라진다. 1년이면 주니어 개발자 두세 명 연봉이다.

흥미로운 건, 이 낭비의 대부분이 청구서에 이미 적혀 있다는 사실이다. 계정에 들어가 볼 필요도 없다. 읽는 사람이 없을 뿐이다.

나는 18년째 인프라를 만들고 있고, 지금은 B2B SaaS 기업에서 금융권 폐쇄망 Kubernetes와 Azure 인프라를 운영한다. 그동안 손으로 하던 비용 진단의 판단 기준을 최근 전부 룰셋으로 옮겼다. 이 글은 그 31개 점검 항목의 전체 목록이다. 숨기는 것 없이 다 적었다. 이 글만 따라 해도 상당 부분은 직접 잡을 수 있다.

시작하기 전에: 어떤 파일을 봐야 하나

콘솔의 비용 대시보드 말고, 원장 파일을 받아야 한다.

• AWS: Cost & Usage Report(CUR) 또는 Data Exports. 리소스 ID 포함 옵션을 켜는 것이 핵심이다. 급하면 Cost Explorer CSV도 되지만, Usage Type 기준으로 그룹핑해서 받아야 진단 가치가 있다.
• Azure: Cost Management의 Export(ActualCost). 구독 범위가 아니라 청구 계정 범위로 뽑으면 구독 누락이 없다.

기간은 최소 3개월. 한 달치는 스파이크인지 추세인지 구분이 안 된다.

여기서 실전 함정 하나. 한국어 콘솔에서 받은 Cost Explorer CSV에는 합계가 Total costs($)가 아니라 총 비용($) 열과 합계 행으로 들어 있다. 이걸 모르고 전체를 더하면 총액이 정확히 2배로 나온다. 직접 스크립트를 짜서 검증하다 잡은 버그인데, 엑셀로 손집계하는 분들도 똑같이 당하는 지점이다.

그리고 판정마다 신뢰도를 구분해야 한다. 나는 세 단계로 나눈다.

등급	의미	예시
확정	청구 데이터만으로 사실이 확정됨	gp2 볼륨 잔존, 유휴 EIP 과금
추정	청구 데이터 기반, 보수 계수를 적용한 추정	스냅샷 정리 가능분, 미연결 볼륨
정밀진단	사용량 메트릭이 있어야 확정됨	CPU 3% 미만 유휴 컴퓨트, DB 과다 사양

이 구분이 없는 비용 리포트는 믿지 않는 게 좋다. "월 500만 원 절감 가능!"이라는 숫자에 확정과 희망이 섞여 있으면, 그 리포트로는 아무 의사결정도 할 수 없다.

A. 유휴 리소스 — 8개 항목

돈을 내고 있는데 아무 일도 하지 않는 것들. 가장 잡기 쉽고, 가장 흔하다.

1. 미사용 공인 IP — 청구서에서 ElasticIP:IdleAddress 같은 항목을 찾으면 끝. 연결 안 된 IP는 그 자체로 과금된다. (확정)
2. 미연결 볼륨 의심 — 볼륨 비용이 컴퓨트 비용의 35%를 넘으면 인스턴스 삭제 후 남은 고아 볼륨을 의심한다. 청구서에는 연결 상태가 없으므로 보수적으로 일부만 잡는다. (추정)
3. 스냅샷 무한 누적 — 스냅샷 비용이 월 단위로 계속 우상향이면 수명주기 정책이 없다는 신호다. 월별 수열 자체가 증거다. (추정)
4. 유휴 컴퓨트(CPU 3% 미만) — 청구서에는 사용률이 없다. 이건 정밀진단 영역이지만, 경험상 컴퓨트비의 8~15%가 여기서 발견된다. (정밀진단)
5. 유휴 로드밸런서 — LB 시간요금은 나가는데 LCU(처리량) 과금이 0에 수렴하면 트래픽 없는 LB다. (추정)
6. 트래픽 없는 NAT 게이트웨이 — NAT 시간요금은 있는데 데이터 처리 바이트가 0이면 확정 낭비. (확정)
7. 유휴 데이터베이스 — DB 인스턴스 요금 대비 IO·백업 과금이 극단적으로 적으면 의심. (추정)
8. 중지 인스턴스의 잔존 과금 — 인스턴스를 꺼도 볼륨과 IP는 계속 과금된다. 1·2번과 묶어서 본다. (정밀진단)

B. 과다 프로비저닝 — 8개 항목

일은 하는데, 필요보다 비싼 몸으로 하는 것들.

9. 구세대 인스턴스 — AWS 4세대 이하(m4, t2 등), Azure v3 이하가 남아 있으면 동급 최신 세대 대비 가격·성능에서 15~40% 손해 구간이다. 청구서의 인스턴스 타입만으로 확정된다. (확정)
10. 비프로덕션 24×7 가동 — dev/staging 태그가 붙은 리소스가 월 650시간 이상 돌면 밤에도 주말에도 켜져 있는 것이다. 평일 주간 스케줄만 적용해도 절반이 사라진다. (확정)
11. x86→ARM 전환 기회 — Graviton/Ampere 전환은 공칭 20~40% 절감. 호환성 검증이 필요하니 하한으로만 잡는다. (추정)
12. gp2→gp3 미전환 — gp2가 남아 있으면 그냥 손해다. 같은 성능에 단가가 약 20% 싸고, 무중단 전환된다. 이 항목이 아직도 대부분의 청구서에서 나온다. (확정)
13. 프로비전드 IOPS 과다 — piops 비용이 EBS 비용의 30%를 넘으면 워크로드 대비 과설정 의심. (추정)
14. 온디맨드 GPU 상시 가동 — GPU 비용은 있는데 Spot 사용이 0이면, 학습용 워크로드를 정가로 돌리고 있을 가능성이 크다. (추정)
15. DB 과다 사양 — CPU p95를 봐야 확정되므로 정밀진단. 다만 청구서에서 DB 인스턴스 크기와 비용 규모는 바로 나온다. (정밀진단)
16. 캐시/서치 클러스터 과다 — ElastiCache·OpenSearch류 비용이 컴퓨트비의 20%를 넘으면 검토 대상. (추정)

C. 스토리지 · 네트워크 · 로그 — 8개 항목

한 번 설정하고 잊어버린 것들. 조용히, 꾸준히 샌다.

17. 객체 스토리지 전량 표준 티어 — S3 표준 비용은 있는데 IA/Glacier/Intelligent-Tiering이 전부 0이면, 수명주기 정책이 아예 없다는 확정 신호다. (확정)
18. 수명주기 정책 부재 — 17번의 조치 항목. 90일 미접근 데이터부터 내리면 된다. (확정)
19. 로그 저장 비용 과다 — CloudWatch Logs(또는 Log Analytics) 저장 비용이 총비의 2%를 넘으면 대부분 무기한 보존이 원인이다. 감사용만 아카이브로 빼고 나머지는 90일 만료. (추정)
20. 로그 수집(ingest) 과다 — 수집 비용이 로그비의 60% 이상이면 디버그 레벨을 프로덕션에서 수집 중일 가능성. 샘플링과 필터로 잡는다. (추정)
21. NAT 데이터 처리비 과다 — NAT 처리 바이트 비용이 시간요금의 2배를 넘으면, S3·ECR·CloudWatch로 가는 트래픽이 NAT를 경유하고 있다는 뜻. VPC 엔드포인트로 우회하면 그 비용은 사라진다. (확정)
22. AZ 간/리전 간 전송비 — 총비의 1% 이상이면 배치 구조 검토. (확정, 조치는 아키텍처 의존)
23. 인터넷 아웃바운드 과다(CDN 부재 의심) — 아웃바운드가 총비의 5%를 넘으면 CDN 캐시율부터 본다. (추정)
24. 객체 스토리지 요청 비용 이상 — 요청 비용이 스토리지 비용의 30%를 넘으면 폴링이나 LIST 남용 패턴이다. (추정)

D. 약정 · 요금제 · 거버넌스 — 7개 항목

구조의 문제. 금액이 가장 크게 걸려 있는 영역이기도 하다.

25. Savings Plan/RI 커버리지 부족 — 온디맨드 컴퓨트 중 약정 커버 비율이 50% 미만이면, 직전 3개월 최저 사용선 기준으로 1년 약정만 걸어도 확정 절감이 나온다. 워크로드 유지가 전제이므로 각주 없이 쓰면 안 되는 숫자다. (확정)
26. 약정 과다/유휴 약정 — 반대로 약정 수수료는 나가는데 커버되는 사용량이 비정상적으로 적으면, 약정을 사놓고 안 쓰는 중이다. (추정)
27. Spot 미활용 — 비프로덕션 컴퓨트가 있는데 Spot 사용이 0이면 잠재 절감 30% 구간. 중단 허용 워크로드 한정. (추정)
28. Azure Hybrid Benefit 미적용 — Windows 라이선스 비용이 청구서에 있고 온프레미스 라이선스를 보유했다면 바로 적용 대상. (확정)
29. 미태깅 비용 — 태그 커버리지가 70% 미만이거나 환경(env) 미상 비용이 절반을 넘으면, 그 영역은 낭비 탐지 자체가 불가능하다. 절감액이 아니라 거버넌스 리스크로 다뤄야 한다. (확정)
30. 크레딧 의존 — 크레딧이 총비의 20%를 넘으면 만료 후 실부담액을 gross 기준으로 미리 계산해둬야 한다. 스타트업 크레딧 소진 시점이 최대 위기다. (확정)
31. 서포트 플랜 적정성 — 서포트 비용 비율을 보고, 플랜만큼 쓰고 있는지 질문한다. (확정, 안내)

등급은 이렇게 매긴다

항목별 절감액을 다 더하면 안 된다. 규칙 두 개가 합계를 지킨다.

하나, 정밀진단 항목은 합산에서 뺀다. 청구서만으로 확정 못 하는 숫자를 합계에 넣는 순간 리포트 전체가 과장이 된다. 범위("월 $28~52 잠재")로만 쓴다.

둘, 중복을 지운다. 구세대 t2 인스턴스가 dev 환경에서 24×7 돌고 있다면 9번(세대 교체)과 10번(스케줄링)이 같은 리소스를 두 번 센다. 하나만 잡는다. 보수적으로.

그다음이 등급이다.

월 낭비 추정액 = Σ(확정) + Σ(추정)        # 정밀진단 제외
낭비율 = 월 낭비 추정액 ÷ 월평균 지출
A: <10% · B: <18% · C: <27% · D: <36% · F: ≥36%

업계 평균이 29%이니, C등급이 "평균 언저리"다. 그리고 경험상 대부분의 스타트업 청구서는 C에서 시작한다.

실제로 돌려보면 이렇게 나온다

이 룰셋을 실환경 두 곳에 돌려본 결과다.

월 500만 원대 Azure 환경은 B등급(낭비율 13%)이 나왔다. 재미있는 건 낭비의 절반이 단 한 곳 — 스테이징 클러스터의 24×7 가동(10번 항목)이었다. 야간·주말 자동 중지 스케줄 하나만 걸면 낭비율 6%대, A등급 구간에 들어간다. 진단이 복잡해 보여도 처방은 이렇게 단순한 경우가 많다.

월 $6,000대 AWS 환경은 A−(9.6%)로 우수했다. 그런데 등급과 별개로, 지출의 47%가 DB 인스턴스 하나에 몰려 있었다. 사용률 메트릭이 없는 청구서만으로는 그 적정성을 판정할 수 없어서(15번, 정밀진단) 합계에 넣지 않았을 뿐이다. 등급이 좋다고 끝이 아니라는 얘기다 — 최대 레버는 종종 목록 밖에 있다.

왜 전부 공개하는가

이 목록만 있으면 직접 할 수 있다. 실제로 그러라고 쓴 글이다. 위 항목 중 절반은 콘솔에서 반나절이면 처리된다.

동시에, 나는 이 진단 과정을 시스템으로 만들었다. 비용 파일을 넣으면 31개 항목을 자동 점검하고, 항목마다 근거 수치와 신뢰도 등급이 각주로 붙은 성적표가 나온다. 판단 기준은 내가 설계했고, 발송 전 검수와 서명도 내가 한다.

비용 파일 하나만 올리면 48시간 안에 무료로 보내드린다. 계정 접근 권한은 필요 없다. 파일은 30일 후 자동 파기된다.

→ 무료 성적표 받기 · 샘플 리포트 먼저 보기

(직접 해보실 분을 위해: AWS Cost & Usage Report 30초 추출 가이드는 다음 글에서 다룬다.)

---

참고 자료

• Flexera, State of the Cloud Report 2026 — 클라우드 낭비율 29%
• FinOps Foundation, State of FinOps 2026 — GPU 지출 비중 18%
• McKinsey — 체계적 FinOps 점검 시 20~30% 절감 범위