클라우드 비용 절감 진단 점검표 · 2026

총액만 보면 무엇이 올랐는지 보이지 않습니다. 지난달과 이번 달 청구서를 계정과 서비스 단위로 나란히 놓고 증가분이 큰 순서로 줄을 세웁니다. 대개 위쪽 서너 줄이 증가분의 대부분을 차지합니다. 그 줄을 다시 자원 단위로 내려가 어느 자원이 언제부터 늘었는지 봅니다. 늘어난 날짜가 배포나 마케팅 이벤트, 신규 기능 출시와 겹치는지 확인하면 원인 후보가 좁혀집니다. 주인이 비어 있는 항목은 따로 셉니다. 태그가 없어 어느 팀 것인지 모르는 자원은 아무도 줄이자고 말하지 않으므로 다음 달에도 같은 자리에 남습니다. 이 첫 표가 없으면 뒤의 모든 점검이 감으로 흐릅니다.

한 달치만 놓고 보면 계절이나 이벤트로 오른 값과 구조로 오른 값이 섞입니다. 최소 서너 달을 같은 형식으로 나란히 놓고 계단처럼 한 번 뛴 뒤 유지되는 항목과 매달 조금씩 오르는 항목을 갈라 표시합니다. 앞의 것은 대개 특정 변경이 원인이고 뒤의 것은 쌓이는 자원이 원인입니다. 원인 후보를 좁힐 때는 배포 이력과 인프라 변경 기록을 같은 달력에 겹쳐 놓습니다.

청구액이 올랐다는 사실만으로는 문제인지 아닌지 판단이 서지 않습니다. 사업이 두 배가 됐는데 청구서가 1.5배면 그 달은 잘한 달입니다. 그래서 총액 옆에 사업 단위로 나눈 값을 하나 만들어 둡니다. 주문 1건당 비용, 활성 사용자 1명당 비용, 처리한 요청 100만 건당 비용 가운데 우리 서비스를 가장 잘 설명하는 하나를 고르고 매달 같은 방식으로 셉니다. 이 값이 유지되거나 내려가면 총액이 올라도 설명이 됩니다. 이 값이 오르면 사용량과 무관하게 무엇인가 어긋난 것입니다. 보고 자리에서 필요한 문장도 여기서 나옵니다. 단위를 고를 때는 재무가 이미 쓰는 지표와 맞추는 편이 낫습니다. 인프라만 쓰는 별도 지표를 새로 만들면 그 값은 다음 분기에 아무도 보지 않습니다.

개발과 시험 환경이 밤과 주말에도 켜져 있는지부터 봅니다. 업무 시간에만 쓰는 환경을 끄는 조치는 되돌리기 쉽고 운영 서비스에 닿지 않습니다. 그다음이 크기입니다. 최대 사용률이 낮은 채로 몇 주를 보낸 인스턴스, 오래된 세대에 남아 있는 인스턴스, 자동 확장 최소 대수가 필요보다 높게 잡힌 그룹을 목록으로 만듭니다. 크기를 줄일 때는 평균이 아니라 최대치를 봅니다. 평균만 보고 줄이면 월말이나 배치 시간대에 문제가 납니다. 로드밸런서 뒤에 트래픽이 오지 않는 대상이 붙어 있는지, 정지한 인스턴스에 디스크만 남아 계속 과금되는지도 같은 자리에서 봅니다. 할당만 받고 어디에도 붙지 않은 고정 IP와 쓰이지 않는 로드밸런서, 이름이 남아 있는 옛 배포 환경도 여기서 걸립니다.

연결되지 않은 볼륨, 삭제한 서버가 남긴 스냅샷, 기한 없이 쌓이는 백업, 수명주기 규칙이 없는 오브젝트 스토리지가 대표 항목입니다. 스냅샷은 하나하나가 작아 눈에 띄지 않지만 세대가 쌓이면 원본보다 커집니다. 보관 기간을 정하고 그 기간이 지나면 자동으로 지워지도록 만드는 편이 매달 손으로 지우는 것보다 확실합니다. 로그도 저장소입니다. 어떤 로그를 며칠 두는지, 감사 요건이 요구하는 기간이 얼마인지 확인하고 나머지는 저렴한 계층으로 내리거나 지웁니다. 지우기 전에는 무엇을 위해 남겼는지 담당자에게 한 번 묻습니다. 재해 복구용으로 남긴 것을 비용으로만 보고 지우면 그 값은 사고가 났을 때 청구됩니다. 오브젝트 스토리지는 저장한 양보다 요청 수와 계층 이동에서 값이 붙는 경우가 있으므로 청구 항목을 세부까지 펼쳐 봅니다.

전송 요금은 자원 목록에 줄로 서지 않아 원인을 찾기 어렵습니다. 인터넷으로 나가는 트래픽, 가용 영역과 리전을 넘나드는 내부 통신, NAT 게이트웨이를 지나는 요청을 나눠 봅니다. 데이터베이스와 애플리케이션이 다른 가용 영역에 있으면 평범한 조회 하나하나에 전송 요금이 붙습니다. 이미지와 정적 파일이 원본 서버에서 직접 나가고 있다면 캐시를 앞에 두는 것만으로 나가는 양이 줄어듭니다. 캐시를 이미 쓰고 있어도 적중률이 낮으면 요금은 두 번 붙습니다. 로그와 백업을 다른 리전으로 복제하고 있다면 그 복제가 규제 요건인지 관행인지 확인합니다.

관리형 데이터베이스와 검색, 큐, 캐시는 켜 두는 것만으로 값이 붙습니다. 개발용으로 만든 클러스터가 프로젝트가 끝난 뒤에도 도는 경우가 흔합니다. 다중 가용 영역 구성과 읽기 전용 복제본이 개발 환경에까지 그대로 복사돼 있는지 확인합니다. 상용 소프트웨어 라이선스가 인스턴스 시간에 얹혀 청구되는 구성이라면 라이선스 값이 인스턴스 요금보다 큰 경우도 나옵니다. 클라우드 청구서 밖에서 나가는 값도 같은 표에 올립니다. 모니터링과 로그 수집, 알림, 배포 도구 구독료가 사용량을 따라 오르는 구조이면 인프라를 줄여도 총액이 그대로일 때가 있습니다.

같은 점검을 다음 분기에 다시 하지 않으려면 값이 저절로 갈리게 만들어 둡니다. 계정과 프로젝트를 환경별로 나누면 개발 환경의 값이 운영 환경에 섞이지 않습니다. 팀별로 나누면 청구서가 그대로 배분표가 됩니다. 태그는 항목을 늘리기보다 서너 개를 강제하는 쪽이 지켜집니다. 소유 팀, 환경, 서비스, 종료 예정일 정도면 대부분의 질문에 답이 나옵니다. 태그가 없는 자원은 만들어지지 않게 막고 이미 붙지 않은 자원은 담당자를 찾을 때까지 목록에 남겨 둡니다. 종료 예정일 칸이 있으면 시험용으로 켠 자원이 반년 뒤에도 도는 일이 줄어듭니다. 이 정리가 끝나면 다음 달 청구서를 열 때 원인을 찾는 대신 값이 맞는지 확인하면 됩니다.

약정과 예약 구매는 할인율이 커서 가장 먼저 손대고 싶어집니다. 순서를 뒤집으면 낭비까지 함께 묶입니다. 지금 크기가 맞는지 확인하기 전에 1년이나 3년을 약정하면 줄일 기회가 그 기간 동안 잠깁니다. 앞의 점검을 마치고 남은 사용량 가운데 사업이 어떻게 되든 계속 쓰는 바닥 구간만 약정으로 덮고 그 위는 온디맨드로 둡니다. 기간을 정할 때는 조직 개편과 서비스 종료, 대규모 전환 계획이 그 기간 안에 있는지 달력에서 먼저 봅니다. 약정을 중간에 넘기거나 바꿀 수 있는지, 계정을 나눠도 할인이 따라가는지도 계약 전에 확인합니다.

목록이 만들어지면 절감액 대신 위험으로 정렬합니다. 끄고 다시 켜면 되는 것, 되돌리는 데 배포가 필요한 것, 되돌릴 수 없는 것 세 묶음으로 나눕니다. 첫 묶음은 그 주에 끝내고 마지막 묶음은 담당자 확인과 작업 창을 잡아 진행합니다. 항목마다 되돌릴 조건과 책임자를 함께 적습니다. 무엇을 왜 껐는지가 남아 있지 않으면 몇 달 뒤 장애 조사에서 원인을 찾는 데 시간이 듭니다. 정리한 계정은 그대로 두면 되돌아옵니다. 새로 만드는 자원에 태그를 강제하는 규칙, 예산 임계를 넘겼을 때 담당 팀에 먼저 알리는 순서, 비용 리뷰를 정기 회의에 얹는 일정까지 같은 점검표에 넣습니다. 조치가 끝난 항목은 지우지 말고 언제 무엇을 했는지 남겨 둡니다. 다음 분기에 같은 자원이 다시 목록에 올라오면 그때 판단을 되풀이하지 않아도 됩니다.

직접 볼 사람이 없으면 진단을 맡깁니다. 제안을 비교할 때는 절감액보다 과금 구조를 먼저 봅니다. 절감액의 일부를 가져가는 성과 연동 방식은 조치를 앞당기는 대신 약정처럼 오래 묶이는 항목을 권하는 쪽으로 기울기 쉽습니다. 클라우드 사용료를 재판매하는 구조라면 사용량이 줄 때 상대의 매출도 줄어든다는 점을 계산에 넣습니다. 무엇이 남는지도 계약 전에 정합니다. 보고서 한 부가 아니라 태그 규칙과 예산 경보, 조치 목록과 되돌릴 조건이 우리 계정 안에 남아야 다음 분기에 같은 진단을 다시 사지 않습니다. 워크로드를 모르는 상태에서 사용률만 보고 자른 목록은 마감과 배치 일정에서 사고를 냅니다. 각 자원이 어떤 업무 주기를 위해 있는지 담당자에게 묻는 절차가 제안에 들어 있는지 확인합니다. 첫 계약은 짧게 끊는 방법도 있습니다. 진단과 위험 낮은 조치까지만 한 번 맡겨 봅니다. 그때 남은 문서와 실제로 내려간 항목을 보고 다음 범위를 정하면 제안서 대신 실제 결과를 근거로 삼게 됩니다.