클라우드 청구서가 커졌을 때 “무엇을 꺼야 하나”부터 묻기 쉽습니다. 그러나 비용을 낸 서비스의 소유자와 사용 목적을 모르면, 필요한 자원까지 끄거나 같은 비용이 다음 달 다른 이름으로 돌아옵니다. 운영에서 가장 먼저 할 일은 절감률 경쟁이 아니라 비용을 설명할 수 있는 구조를 만드는 것입니다.
1. 주인 없는 자원과 태그 누락
테스트 인스턴스, 오래된 스냅샷, 임시 스토리지, 미사용 IP는 보통 “누가 만들었는지”가 흐려진 뒤 남습니다. 소유자·서비스·환경·만료일 같은 최소 태그를 정하고, 태그가 없는 비용을 월간 보고서에서 따로 보여 주세요. 태그는 나중에 붙이면 과거 비용을 완전히 되살리지 못할 수 있으므로 생성 시점의 규칙이 중요합니다.
2. 개발·스테이징 환경의 상시 가동
개발 편의를 위해 24시간 켜 둔 환경은 실제 사용 시간이 짧아도 비용을 만듭니다. 무조건 자동 종료하기보다, 업무 시간·야간 배치·대기 서비스처럼 꺼도 되는 범위를 팀과 합의하세요. 종료 정책에는 예외 신청, 재기동 방법, 데이터 보존 여부가 함께 있어야 운영 사고를 줄일 수 있습니다.
3. 저장소와 백업의 보존 기간
백업은 있어야 하지만 모든 복사본을 영구히 빠른 저장소에 둘 필요는 없습니다. 데이터 분류, 복구 목표, 보존 의무, 접근 빈도를 기준으로 계층과 보존 기간을 정합니다. ‘오래된 것 삭제’가 아니라 ‘왜 보관하는지 설명할 수 없는 것 확인’이 더 안전한 접근입니다.
4. 약정·예약보다 사용량 측정이 먼저
할인 약정은 사용 패턴이 비교적 안정적일 때 검토할 수 있는 선택지입니다. 측정 없이 먼저 약정하면 변화한 서비스 구조와 맞지 않아 오히려 관리가 어려워집니다. CPU·메모리·요청량·전송량·예약 사용률을 일정 기간 관찰하고, 담당자가 바뀌어도 해석 가능한 보고서를 남기세요.
월간 7개 점검표
- 태그가 없거나 소유자가 불명확한 비용이 있는가.
- 개발·스테이징 환경의 가동 시간이 목적과 맞는가.
- 미연결 디스크·스냅샷·IP·로드밸런서가 있는가.
- 백업과 로그의 보존 기간이 문서화되어 있는가.
- 전송 비용과 관리형 서비스의 급증 원인을 확인했는가.
- 예산 경보의 수신자와 대응자를 정했는가.
- 이번 달의 비용 변화가 사용자·매출·트래픽 변화와 함께 설명되는가.
FinOps Foundation은 계정·태그·라벨·메타데이터로 비용의 책임을 연결하고 공유 비용 배분 기준을 문서화할 것을 제시합니다. FinOps Allocation 가이드와 AWS 비용 배분 전략을 참고해 플랫폼별 설정으로 옮길 수 있습니다.
확인일: 2026-08-28. 실제 삭제·축소·약정 변경은 서비스 영향과 복구 계획을 확인한 뒤 단계적으로 실행하세요.