¶ 12권 — 클라우드 비용 관리와 최적화하기
클라우드 비용은 제품이 자리 잡은 뒤 방치되기 가장 쉬운 영역이다. 이 책은 특정 사례의 상세 이력이 아니라, 스타트업·중소 SW기업이 "우리 클라우드 비용을 어떻게 들여다보고 어디부터 손댈지" 판단할 수 있는 기준과 절차를 다룬다.
내용은 AWS를 기준으로 정리하되, 판단 기준 자체는 Azure·GCP에도 대체로 적용된다.
¶ 왜 클라우드 비용은 저절로 새는가
종량제(pay-as-you-go) 구조는 "쓴 만큼만 낸다"는 착각을 만들지만, 실제로는 꺼야 할 리소스를 꺼두지 않는 관성이 청구서에 쌓인다.
이는 관리를 못하는 조직만의 문제가 아니라 의식적으로 들여다보지 않으면 원래 이렇게 쌓이는 구조적 특성이며, 이 책의 목표는 완벽한 최적화가 아니라 반복 가능한 최소 점검 루틴을 만드는 것이다.
¶ 청구서 읽는 법 — Bills와 Cost Explorer의 차이
AWS Billing 콘솔에는 두 화면이 있다.
| 화면 | 용도 |
|---|---|
| Bills | 실제 청구 내역을 보여준다 — "얼마 나왔는지" 확인 |
| Cost Explorer | 절감 기회를 찾기 위한 심층 분석 도구 — "왜 이만큼 나왔고 어디서 줄일 수 있는지" 확인 |
이 두 화면의 역할을 구분해서 보는 것이 원칙이다.
¶ 비용이 새는 지점 찾기 — 태깅
리소스가 어느 팀·프로젝트·환경 소속인지 구분되지 않으면 Cost Explorer로도 "전체적으로 늘었다"는 것 이상을 알 수 없다.
스타트업 최소 태그 세트로 다음을 권장한다.
environmentteam/projectownercost-center
새 리소스 생성 시 태그가 없으면 실패하는 정책을 함께 도입하면 "나중에 태깅하겠다"는 부채를 막을 수 있다.
¶ 대표 비용 절감 레버 ① — 유휴 리소스 정리
유휴 RDS·로드밸런서, 연결되지 않은 Elastic IP, 활용도 낮은 EBS 볼륨은 대부분 지우는 것을 깜빡했거나 프로젝트 종료 후 남은 것이다. 특별한 기술 판단 없이 즉시 제거할 수 있는 가장 손쉬운 절감 레버다.
¶ 대표 비용 절감 레버 ② — 오버프로비저닝(rightsizing) 해소
"혹시 몰라서" 실제 필요보다 큰 인스턴스를 방치하는 상태를 해소하는 작업이다. 통상 10~20% 수준의 절감 여지가 확인된다는 분석이 있다.
- 프로덕션은 최소 2주 이상 실측 지표 관찰 후 rightsizing
- 개발·테스트는 애초에 업무 시간에만 켜지는 구조로 설계
¶ 요금제 최적화 — On-Demand, Savings Plans, Reserved Instances
판단 기준은 다음과 같다.
| 워크로드 특성 | 권장 옵션 |
|---|---|
| 자주 바뀜 | Savings Plans |
| 특정 구성이 1년 이상 고정적 | RI(Reserved Instances) |
| 사용 패턴이 안정되지 않은 초기 스타트업 | 최소 3개월 이상 관찰 후 커밋 검토 |
¶ 지속적 모니터링 체계 만들기
AWS Budgets로 3단계 알림을 구성한다.
- 실제 지출 80%에서 조기 경고
- 예측 지출 100%에서 사전 통지
- 실제 지출 100%에서 심각 초과 알림
이 알림을 상시 확인하는 Slack 채널로 연결한다. FinOps는 이 관리를 지속 가능한 체계로 만드는 운영 모델로, "Crawl, Walk, Run" 단계로 성숙도를 키워간다. 스타트업은 태깅과 월간 점검만으로 Crawl 단계의 핵심 조건을 충족한다.
¶ 핵심 포인트 — 비용은 조용히 쌓이는 기술부채다
클라우드 비용 누수는 코드의 기술부채와 성격이 같다. "이번만 이 사양으로", "테스트 끝나면 지워야지" 같은 작은 결정들이 매주 쌓여, 몇 년 뒤 청구서는 처음 설계와 전혀 다른 규모가 된다.
이 책이 강조하는 것은 완벽한 최적화 프로젝트가 아니라 반복 가능한 최소 점검 루틴이다.
¶ 참고할 만한 사례
인프랩(인프런·랠릿)의 태깅 기반 상위 서비스 우선 최적화로 연간 약 30만 달러 절감, 37signals(DHH)의 클라우드 탈출을 통한 연 200만 달러 절감 사례가 소개된다.
¶ 💬 질문이 있으신가요?
아래 댓글로 남겨주세요. 로그인 없이도 바로 남길 수 있습니다.