Cost Explorer = 가계부. 지난 비용을 그래프로 들여다보고, 이 추세면 앞으로 얼마 나올지 예측한다.
AWS Budgets = 카드 사용 알림. 한도를 미리 정해두면 가까워지거나 넘을 때 먼저 알려준다.
CUR(Cost and Usage Report) = 거래 명세 원본. 가장 상세한 라인 아이템을 S3로 내보내 맞춤 분석에 쓴다.
비용 할당 태그 = 지출 항목 라벨. 태그를 붙이고 활성화까지 해야 팀·프로젝트별로 비용이 갈린다.
흐름 한 줄: 본다(Cost Explorer) → 막는다(Budgets) → 깊이 판다(CUR) → 누구 것인지 가른다(태그).
어제 우리는 같은 자원도 구매 방식에 따라 값이 달라진다는 걸 배웠다. 그런데 아무리 잘 골라도 얼마를 어디에 쓰고 있는지 보이지 않으면 최적화도, 통제도 불가능하다. 오늘은 비용을 들여다보고(분석), 미리 막고(예산 경고), 자세히 뜯어보고(상세 보고서), 누가 무엇에 썼는지 구분(태그)하는 네 가지 도구를 정리한다.
핵심 질문은 셋이다: "지난 비용은 어떻게 생겼나?", "예산을 넘기 전에 알 수 있나?", "이 비용이 어느 팀·프로젝트 것인가?"
온프레미스 시절에는 비용 질문이 이미 끝나 있었다. 서버를 사는 순간 값이 정해졌고, 그다음 몇 년은 전기 요금 정도만 오갔다. "이번 달에 우리 팀이 얼마 썼지?"라는 질문 자체가 잘 나오지 않았다. 이미 나간 돈이었기 때문이다.
클라우드는 정반대다. 세 가지가 한꺼번에 바뀌었다.
비용이 매 순간 발생한다 — 켜둔 시간이 곧 돈이다. 어제 잠깐 켜본 서버를 끄지 않으면 오늘도, 내일도 요금이 붙는다.
누구나 자원을 켤 수 있다 — 클라우드의 장점인 "주문형 셀프서비스"가 비용 측면에서는 위험이 된다. 결재 없이 클릭 몇 번이면 자원이 생기고, 켠 사람이 잊으면 아무도 모른다.
항목이 잘게 쪼개진다 — 청구서 한 장에 수백 줄이 찍힌다. 눈으로 훑어서는 무엇이 늘었는지 알 수 없다.
그래서 도구가 없는 조직의 클라우드 청구서는 "월말에 열어보고 놀라는 편지"가 되기 쉽다. 테스트하려고 잠깐 띄운 서버 한 대, 지우는 걸 잊은 디스크 스냅샷 — 각각은 작지만 한 달을 곱하면 무시할 수 없는 금액이 된다. 더 나쁜 건 월말에야 알게 된다는 점이다.
[도구가 없는 조직]
자원 생성 ──── 한 달 내내 아무도 모름 ──── 월말 청구서 (놀람)
[도구를 쓰는 조직]
자원 생성 ─ 태그로 라벨 ─ Budgets 경고 ─ Cost Explorer 점검 ─ 예상했던 청구서
(누구 것) (한도 임박) (어디가 늘었나)
오늘 배우는 네 도구는 이 그림의 아래쪽 줄을 만드는 부품들이다. 비용을 사고가 난 뒤에 확인하는 것에서, 나기 전에 다루는 것으로 바꾸는 게 목표다.
직원 열 명 남짓한 어느 스타트업이 클라우드로 옮긴 첫 달을 상상해 본다. 예산은 넉넉히 잡았는데 청구서가 그 두 배로 나왔다. 원인은 신입 개발자가 성능 테스트용으로 띄운 큰 서버들을 하나만 끄고 나머지를 잊은 것이었다. 잘못한 사람을 찾는 게 요점이 아니다. 그 조직에는 "누가 무엇을 켰는지"를 보여주는 장치도, "예산의 절반을 넘었다"고 알려주는 장치도 없었다는 게 진짜 문제다.
"클라우드 비용을 지속적으로 보고, 배분하고, 최적화하는 일을 조직의 습관으로 만드는 것"을 클라우드 재무 관리(Cloud Financial Management)라고 부른다. AWS Well-Architected Framework의 비용 최적화(Cost Optimization) 기둥과 같은 이야기다.
AWS Cost Explorer는 과거 비용·사용량을 시각화하고 미래를 예측하는 분석 도구다. 그래프와 표로 "지난 6개월 동안 어떤 서비스에 얼마를 썼는지", "이 추세면 다음 달은 얼마쯤 나올지"를 보여준다. 서비스별·리전별·태그별로 쪼개 볼 수도 있다.
쓰임은 명확하다. 어떤 서비스가 비용을 잡아먹는지 찾아내고, RI나 Savings Plans 추천도 받아 최적화 기회를 발견한다. 한마디로 "과거를 분석하고 미래를 내다보는" 도구다.
비유하자면 가계부다. 가계부를 쓰는 이유는 돈을 안 쓰기 위해서가 아니라 어디로 새는지 알기 위해서다. 총액만 보면 "이번 달은 많이 썼네" 이상을 알 수 없지만, 식비·교통비·구독료로 쪼개면 "구독료가 조용히 늘고 있었구나"가 드러난다. Cost Explorer가 하는 일이 정확히 이것이다.
Cost Explorer가 비용을 쪼개는 기준은 여러 가지다.
쪼개는 기준
이런 질문에 답한다
서비스별
"우리 비용의 절반은 어느 서비스에서 나오나?"
기간별(일·월)
"언제부터 늘기 시작했나?"
리전별·계정별
"안 쓰는 줄 알았던 곳에서 요금이 나오나?"
태그별
"어느 팀·프로젝트의 비용인가?" (태그 활성화 필요)
실무에서 Cost Explorer를 여는 순간은 청구서가 늘었을 때 "어디가 늘었는지"를 찾기 위해서다. 총액 → 서비스 → 리전 → 자원으로 좁혀 가는 것이 비용 조사의 기본 동선이다. 예측 기능도 같은 맥락으로, "지금 속도면 예산을 넘긴다"는 판단을 월 중간에 내릴 수 있게 해준다.
어느 온라인 교육 서비스의 청구서가 갑자기 크게 늘었다. 총액만 봐서는 원인을 알 수 없었지만 Cost Explorer에서 서비스별로 쪼개니 데이터 전송 비용만 유독 튀어 있었다. 파고들어 보니 새로 올린 고화질 강의 영상이 CDN 없이 매번 원본 스토리지에서 직접 나가고 있었다. 서비스가 느려진 것도, 장애가 난 것도 아니어서 비용 그래프를 보기 전에는 아무도 이상을 눈치채지 못했다. 비용 가시성이 곧 아키텍처 문제의 조기 경보가 되는 전형적인 장면이다.
"비용 추이 시각화", "서비스별 분석", "향후 비용 예측"이 보이면 Cost Explorer다. 분석·예측이 핵심이지, 한도 경고를 보내는 도구는 아니다(그건 Budgets).
⚠️ 함정: Cost Explorer는 사람이 열어봐야 보이는 도구다. 알아서 문자나 메일을 보내주지 않는다. 시험 문항에 "자동으로 알림을 받아", "한도에 도달하면 통보" 같은 표현이 섞여 있으면 정답은 Cost Explorer가 아니라 Budgets다. 반대로 "그래프로 확인", "추세 분석", "예측"이라면 Cost Explorer다. 이 두 도구를 가르는 단어는 결국 "보러 간다" vs "알려준다"이다.
AWS Budgets는 비용·사용량 예산을 설정하고, 그 한도에 가까워지거나 초과하면 알림(이메일/SNS)을 보내는 도구다. 예를 들어 "월 $500"으로 예산을 잡고 "80%(=$400)에 도달하면 알려줘"라고 설정하면, 청구서가 폭탄이 되기 전에 미리 손쓸 수 있다.
Cost Explorer와 자주 헷갈리지만 역할이 다르다. Cost Explorer는 "이미 쓴 비용을 분석", Budgets는 "앞으로 새지 않도록 미리 경고"다. 둘은 보완 관계다.
항목
Cost Explorer
AWS Budgets
초점
과거 비용 분석·미래 예측
예산 설정·임계치 알림
주된 동작
시각화/리포트 조회
한도 도달 시 사전 경고
언제
"얼마 썼는지 보고 싶다"
"예산 넘기 전에 알고 싶다"
비유하자면 카드 사용 알림 문자다. 문자가 오는 이유는 명세서를 볼 줄 몰라서가 아니라 명세서는 한 달 뒤에 오고 그때는 이미 늦기 때문이다. Budgets는 클라우드 요금에 이 알림을 붙여준다. 콘솔에 들어가 보지 않아도 알림이 먼저 찾아온다.
예산은 금액(비용 예산)뿐 아니라 사용량 자체를 기준으로도 잡을 수 있고, 예약 인스턴스·Savings Plans를 사두고 잘 쓰고 있는지(활용률·커버리지)를 감시하는 용도로도 쓸 수 있다.
알림을 거는 기준은 두 가지다. 실제(actual) 기준은 이미 쓴 금액이 임계치에 닿았을 때 울리고, 예측(forecasted) 기준은 "이 추세면 넘겠다" 싶을 때 미리 울린다. 앞은 확실하지만 늦고, 뒤는 빠르지만 추정이다. 그래서 보통 둘을 함께 걸어둔다.
한 소규모 게임 스튜디오가 신작 테스트 서버를 올리며 개발용 계정에 별도 예산을 걸어두었다. 곧 "이 추세면 이번 달 예산을 넘길 것으로 보인다"는 예측 알림이 왔고, 확인해 보니 부하 테스트 스크립트가 종료 처리에 실패해 매번 서버를 새로 만들고만 있었다. 월말 청구서로 알았다면 한 달 치를 다 물었을 일을, 알림 덕분에 며칠 치로 끊었다.
"예산 설정", "임계치 초과 시 알림", "비용 폭탄 예방"이 보이면 Budgets다. "분석/예측"이면 Cost Explorer.
⚠️ 함정: Budgets는 기본적으로 알려주는 도구다. 예산을 넘겼다고 해서 AWS가 알아서 서비스를 끄거나 계정을 잠그지 않는다. 시험 보기에 "예산을 초과하면 자동으로 리소스가 중지된다"처럼 적혀 있으면 오답 신호로 본다. 자동 조치가 필요하면 알림에 별도의 조치를 연결해 직접 설계해야 한다. 클라우드의 기본 태도는 "고객의 워크로드를 마음대로 멈추지 않는다"이며, 통제는 고객 책임이라는 공동 책임 모델과도 결이 같다.
AWS Cost and Usage Report(CUR)는 AWS가 제공하는 가장 상세한 비용·사용량 데이터다. 모든 사용 라인 아이템을 시간 단위까지 쪼개 S3 버킷으로 내보내며, Athena·QuickSight 같은 분석 도구와 연결해 깊이 파고들 수 있다.
Cost Explorer가 "대시보드 수준의 시각화"라면, CUR은 "원천 데이터(raw data) 그 자체"다. 회계팀이 정밀하게 비용을 배분하거나, 대규모 조직이 맞춤 분석을 해야 할 때 쓴다.
비유하자면 은행 거래 명세 원본이다. 은행 앱의 "카테고리별 지출" 요약 화면이 Cost Explorer라면, 세무사에게 넘기는 모든 거래가 한 줄씩 찍힌 원본 파일이 CUR이다. 원본은 보기 불편하지만, 요약 화면이 답해 주지 못하는 질문까지 답할 수 있다.
언제 원본이 필요할까. 부서별 정산이 소수점까지 맞아야 할 때, 그리고 "고객 한 명당 인프라 비용"처럼 AWS가 미리 만들어 두지 않은 각도로 보고 싶을 때다.
[CUR이 지나가는 길]
AWS 청구 데이터 ──> S3 버킷에 파일로 적재 ──> 분석 도구(Athena/QuickSight 등)
(라인 아이템) (내가 소유한 저장소) (내가 원하는 질문)
정리하면 Cost Explorer는 "AWS가 만들어 준 화면을 본다", CUR은 "내가 원하는 화면을 직접 만든다"는 차이다. 데이터를 다룰 사람과 도구가 있는 조직에서 진가를 발휘하며, 소규모 팀이라면 Cost Explorer만으로도 대체로 충분하다.
"가장 상세한", "라인 아이템 수준", "S3로 내보내 맞춤 분석"이 보이면 CUR이다. 가벼운 조회·예측은 Cost Explorer, 정밀 원천 데이터는 CUR로 구분한다.
함정: CUR을 켰다고 해서 콘솔에 새 그래프가 생기지 않는다. CUR이 하는 일은 파일을 내 S3 버킷에 떨어뜨려 주는 것까지이고, 그 뒤로 무엇을 할지는 고객 몫이다. 시험 보기에서 "가장 상세한", "raw", "내보내기", "맞춤 분석"이라는 단어가 함께 나오면 CUR, "바로 보기 좋은 그래프"라면 Cost Explorer라고 갈라둔다.
비용 할당 태그는 리소스에 붙인 태그(키-값, 예: Project=alpha, Team=marketing)를 청구 데이터에서 비용 구분 기준으로 활성화하는 기능이다. 그러면 Cost Explorer나 CUR에서 "마케팅팀이 쓴 비용", "alpha 프로젝트 비용"처럼 태그별로 비용을 쪼개 볼 수 있다.
태그 없이는 모든 비용이 한 덩어리로 보여 "이게 누구 비용이냐"를 따질 수 없다. 그래서 부서별 비용 청구(쇼백/차지백)나 프로젝트 단위 정산에 필수다.
[태그가 비용 가시성을 만든다]
태그 없음 → 전체 비용 한 덩어리, 책임 소재 불분명
태그 있음 → Team/Project/Env 별로 비용 분리, 정확한 배분
비유하자면 영수증에 붙이는 지출 항목 라벨이다. 서랍에 영수증을 몽땅 넣어두면 총액은 알아도 "이번 출장에 얼마 썼나"는 알 수 없다. 영수증마다 '출장', '회식', '비품'이라고 적어 두면 그때부터 분류가 가능해진다. 클라우드에서 그 라벨 역할을 하는 게 태그다.
태그가 실제로 비용 리포트에 나타나려면 두 단계를 다 밟아야 한다. ① 리소스에 Team=marketing 같은 키-값을 붙이고, ② 청구 화면에서 그 태그를 비용 할당 태그로 활성화한다. ②를 잊으면 태그는 붙어 있는데 리포트에는 아무 변화가 없다. "태그를 다 달았는데 왜 안 보이죠?"의 답은 대부분 여기에 있다.
태그는 고객이 직접 정하는 사용자 정의 태그(Team, Project, Env, CostCenter 등)와 AWS가 자동으로 붙여주는 AWS 생성 태그로 나뉜다. 비용 배분에 실제로 쓰이는 건 대부분 앞쪽이다.
그리고 조직이 먼저 정해야 할 게 하나 있다 — 이름 규칙이다. 태그 키는 대소문자를 구분해서 Team, team, TEAM이 서로 다른 태그로 취급된다. 사람마다 다르게 적으면 비용이 세 갈래로 흩어져 아무것도 집계되지 않는다. 그래서 성숙한 조직은 태그를 표준 목록으로 관리한다.
이렇게 갈라 놓은 비용은 쇼백(showback) — "당신 팀은 이만큼 썼습니다"라고 보여만 주기 — 이나 차지백(chargeback) — 그 금액을 실제로 팀 예산에서 차감하기 — 으로 쓰인다. 둘 다 태그 없이는 시작조차 할 수 없다. "태그는 비용 관리의 전제 조건"이라고 외워도 좋다.
사업부 세 곳이 하나의 계정을 함께 쓰던 회사를 떠올려 본다. 청구서는 한 장으로 오고 그 금액은 통째로 정보시스템팀 예산에서 나갔다. 결과는 예상대로였다 — 자원을 만드는 건 사업부, 돈을 무는 건 정보시스템팀. 아무도 아끼지 않았다. 이 회사가 한 일은 요금제를 바꾸는 것도, 서버를 줄이는 것도 아니었다. 태그 규칙을 정하고, 태그를 켜고, 매달 사업부별 비용을 공유하기 시작한 것이 전부였다. 그것만으로 안 쓰는 자원이 눈에 띄게 정리됐다. 비용은 보이는 순간부터 관리되기 시작한다.
"부서·프로젝트별 비용 구분", "비용을 팀에 배분", "태그 기준으로 청구"가 보이면 비용 할당 태그다. 분석 도구(Cost Explorer/CUR)는 태그가 켜져 있어야 태그별로 비용을 보여줄 수 있다.
함정: 태그를 나중에 활성화하면 활성화한 시점 이후의 데이터부터 태그별로 갈린다. 지난달 청구서가 소급해서 예쁘게 나뉘지는 않는다. 그래서 태그 규칙은 계정을 늘리기 전, 자원이 많아지기 전에 먼저 정해두는 편이 압도적으로 편하다.
태그가 없으면 나눌 수 없고, Cost Explorer가 없으면 볼 수 없고, Budgets가 없으면 늦게 알고, CUR이 없으면 깊이 팔 수 없다. 네 가지는 서로를 대체하지 않는다.
네 도구는 하나의 비용 관리 흐름을 이룬다. 비용을 시각화해 새는 곳을 찾고, 예산 알림으로 초과를 예방하고, 상세 보고서로 정밀 분석하며, 태그로 책임 소재를 분명히 한다. 이 도구들은 켜 두는 것만으로는 아무 일도 하지 않는다. 그래프는 누군가 열어 봐야 하고, 예산 알림은 누군가 받아 조치해야 한다. 비용 관리는 기술보다 습관과 책임의 문제에 가깝다.