17 억 달러의 유령 청구서 — 아무도 검증할 수 없는 클라우드 과금의 신뢰 위기

세계 최대 클라우드의 청구서가 17 억 달러를 잘못 표시했다는 것은 단발성 버그인가, 아무도 검증할 수 없는 클라우드 과금 구조의 신뢰 위기인가.

도입 — 하룻밤 사이 뜬 유령 청구서

2026 년 7 월 17 일 새벽, 수많은 AWS 사용자가 자기 계정의 Cost Explorer 에서 상식을 벗어난 숫자를 보았다. 월 사용액이 5 달러도 되지 않는 계정에 수십억, 어떤 경우에는 수조 달러의 추정 청구액이 찍혔다. 한 사용자는 6600 억 ($660 trillion) 달러라는, 지구상의 어떤 화폐 시스템으로도 결제 불가능한 숫자를 보고했다. Hacker News 에 오른 스레드의 제목은 “AWS: Inaccurate Estimated Billing Data — $1.7 billion” 이었고, 1278 점과 744 개의 댓글을 모으며 그날의 1 위에 올랐다. 17 억 달러는 그 스레드가 대표로 내건 숫자였을 뿐, 실제 화면에 뜬 금액의 스펙트럼은 그보다 훨씬 넓었다.

AWS 는 빠르게 움직였다. AWS Health Dashboard 에 태평양 시간 7 월 17 일 오전 1 시 33 분 열린 이슈가 등록되었고, 문구는 간결했다. Cost Explorer 가 “부정확한 추정 청구 데이터를 반영하고 있다 (reflecting inaccurate estimated billing data)” 는 것이다. AWS 는 조사 시작 90 분 안에 근본 원인을 특정했다고 밝혔다. 원인은 “추정 청구 계산 하위 시스템 내의 단위 가격 문제 (an issue with unit pricing within the estimated billing computation subsystem)” 로 기술되었다. 무엇보다 AWS 는 못을 박았다. “표시된 청구 추정치는 실제 사용량과 요금을 반영하지 않는다 (The displayed billing estimates do not reflect actual usage and charges).” 즉 실제 인보이스, 결제 처리, 청구 기록은 영향을 받지 않았고, 사용자가 취할 조치는 없으며, 잘못된 숫자는 올바른 값으로 백필 (backfill) 될 것이라는 안내였다. 완전 복구는 7 월 18 일 정오 (태평양 시간) 로 예정되었다.

이 사건의 표면은 단순하다. 추정치를 계산하는 파이프라인의 단위가 틀렸고, 실제 돈이 오간 것은 아니며, 몇 시간 안에 정정되었다. 그러나 1278 점이라는 반응의 크기는 표면보다 깊은 곳을 가리킨다. 문제의 핵심은 “17 억 달러가 실제 청구되었는가” 가 아니다. 문제는 “월 5 달러짜리 계정에 17 억 달러가 뜰 수 있다면, 정상적으로 보이는 매달의 청구서를 사용자는 무엇으로 검증하는가” 이다. 이 글은 사실관계에서 시작해, 클라우드 과금의 불투명성과 검증 불가능성이라는 구조적 문제로, 그리고 FinOps 라는 산업이 왜 이 공백 위에서 자라났는가로 나아간다.

현상 — 청구 오류의 사실관계

먼저 무엇이 어떻게 틀렸는지를 정확히 짚어야 한다. AWS 의 과금은 사용량 기반 후불제다. 각 서비스는 사용량을 계량 (metering) 해 이벤트로 방출하고, 이 계량값은 SKU · 리전 · 단위 (unit) 를 키로 삼아 가격표 (pricing plan) 와 매칭된다. GB 당 몇 센트, 요청 100 만 건당 얼마, vCPU-시간당 얼마 같은 규칙이다. Cost Explorer 는 이 계량과 가격을 결합해 월중 누적액 (month-to-date) 과 월말 예상액 (forecast) 을 시각화하는 도구다. 사용자가 매일 보는 “이번 달 예상 청구액” 은 바로 이 파이프라인의 산출물이다.

7 월 16 일 오후 7 시 38 분 (태평양 시간) 무렵, 이 파이프라인의 어딘가에서 단위가 뒤틀렸다. 정황을 가장 설득력 있게 설명한 것은 전직 AWS 엔지니어를 자처한 Hacker News 사용자 donavanm 이었다. 그는 자신이 과거에 겪은 동형의 사고를 이렇게 회고했다. “단위 오류다. 내 경우엔 GB 당 5 센트를 부과할 _생각_이었는데, 단위 (GB) 를 빠뜨렸고, 그러면 청구 시스템은 기본값으로 바이트를 쓴다 (It’s a unit error. In my case we _meant_ to charge like 5¢/GB, but missed the unit (GB), and then the billing system defaults to bytes).” GB 를 바이트로 오인하면 배율이 정확히 10 억 배 (2 의 30 제곱, 약 10.7 억) 어긋난다. 월 몇 달러가 수십억 달러로, 몇백 달러가 수조 달러로 튀는 정확한 산수가 여기서 나온다. 사용자가 본 6600 억 달러라는 숫자는 무작위한 고장이 아니라, “제대로 된 작은 숫자에 10 억을 곱한” 결정론적 결과였다는 뜻이다.

여기서 두 가지를 분리해야 한다. 첫째, 이것은 추정 계산 계층 (estimated billing computation) 의 사고이지 실제 인보이스 계층의 사고가 아니었다. AWS 의 최종 청구는 Cost and Usage Report (CUR) 로 라인 아이템까지 확정되며, 결제는 그 위에서 일어난다. 이번 오류는 그 앞단의 “예측/표시” 파이프라인에 국한되었다. 둘째, 그럼에도 사용자 체감의 충격은 실재했다. AWS Budgets 와 CloudWatch 청구 경보는 추정치를 기준으로 알림을 쏘기 때문이다. 사용자 yuchen20 의 증언이 이 구조를 압축한다. “예산이 18 달러 ($18) 임계값을 넘었다는 경고 메일을 연속 세 통 받았다. 열어 보니 비용이 7800 만 (78 million) 이었다. 정서적 피해 (I got 3 consecutive emails warning that my budget crossed its $18 threshold. Opened it up: cost was 78 million. EMOTIONAL DAMAGE).” 실제 돈은 움직이지 않았지만, 경보 시스템은 추정치를 진실로 취급했고, 그래서 심야에 수십만 관리자의 휴대폰이 울렸다.

이런 종류의 사고가 AWS 에서 처음이 아니라는 증언도 나왔다. 사용자 scott_w 는 이렇게 적었다. “아니, AWS 에서 이건 드물지 않다. 10 년 전 Kinesis 를 만지다가 비슷한 버그를 만났고 200 만 달러 ($2m) 청구 경보에 심장이 멎을 뻔했다 (Nah, this is not uncommon in AWS. I came across a similar bug 10 years ago when playing with Kinesis and nearly had a heart attack at a $2m billing alert).” 청구 오경보는 클라우드 초창기부터 반복된 장르였다는 것이다. 흥미로운 대비도 스레드에 올라왔다. 사용자 golly_ned 는 AWS 의 내부 문화를 이렇게 꼬집었다. “그들은 한 고객에게 0.26 달러 ($0.26) 를 과다 청구한 사건에 대해 방대한 ‘CoE (Correction of Errors)’, 즉 오류 정정 사후 분석을 요구한 것으로 유명하다 (They famously required an extensive ‘CoE’, correction of errors, post-mortem, in an instance of over-charging a customer $0.26).” 26 센트의 과다 청구에는 엄격한 사후 분석을 돌리는 조직이, 계정당 10 억 배의 표시 오류를 하룻밤 방출했다는 대비는 그 자체로 이 사건의 성격을 드러낸다. 이것은 부주의한 회사의 사고가 아니라, 지극히 엄격한 회사조차 잡지 못하는 종류의 사고라는 것이다.

원인이 단위 하나였다는 사실은 소프트웨어 엔지니어에게 익숙한 통증을 건드렸다. 사용자 ibejoeb 의 한 줄이 그 통증을 정확히 짚는다. “이게 인보이싱이라고? 순수하게 결정론적이길 바라는 도메인이 있다면, 그건 인보이싱일 것이다 (This is invoicing? If ever there was a domain that was purely deterministic, you’d hope it was invoicing).” 돈을 다루는 코드는 가장 결정론적이고 가장 잘 검증되어야 할 코드다. 그런데 바로 그 코드가 단위 하나로 무너졌다. 왜 테스트가 이것을 잡지 못했는가에 대해서는 사용자 CobrastanJorji 가 조직론적 진단을 내놓았다. “테스트 1 은 새 시스템이 청구 항목을 방출하는지 검증할 것이다. 테스트 2 는 청구 시스템 안에 있을 것이다. 그러나 그들은 이 둘을 함께 테스트하지 않을 것이다 (Test 1 will verify the new system emits billing entries; Test 2 will be in the billing system. But they won’t test the two things together).” 계량을 방출하는 서비스 팀과 그것을 가격과 곱하는 청구 팀은 각자의 단위 테스트를 통과했지만, 두 시스템의 경계에서 단위 계약 (unit contract) 이 어긋나는 통합 지점은 누구의 테스트에도 속하지 않았다는 진단이다. Mars Climate Orbiter 를 파운드-초와 뉴턴-초의 단위 불일치로 잃은 사고의 소프트웨어판이다.

심층 — 검증 불가능성, 그리고 FinOps 의 부상

사실관계만 보면 이 사건은 몇 시간 만에 정정된 표시 버그다. 그러나 1278 점이 가리키는 진짜 신경은 다른 곳에 있다. 핵심 질문은 이렇다. 월 5 달러 계정에 17 억 달러가 뜰 수 있는 시스템에서, 매달 정상적으로 보이는 청구서를 사용자는 무엇으로 검증하는가. 답은 불편하다. 검증할 수 없다.

클라우드 과금의 구조적 특성은 정보 비대칭이다. 계량값을 생성하는 쪽은 클라우드 사업자이고, 사용자는 그 계량의 산출물만을 본다. 온프레미스 시절 사용자는 서버 대수, 전력 계량기, 회선 대역을 직접 셀 수 있었다. 클라우드에서는 “이번 달 S3 GET 요청이 정확히 몇 건이었는가”, “리전 간 egress 가 몇 GB 였는가” 를 사업자의 계량기 밖에서 독립적으로 잴 방법이 사실상 없다. 사용자는 자기 애플리케이션의 로그로 근사치를 만들 수 있을 뿐, 사업자가 청구의 근거로 삼는 계량값 자체를 재구성할 수 없다. 이번 사고는 그 계량-가격 곱셈의 한 축인 “단위” 가 10 억 배 틀려도 사용자가 알아챌 수 있는 유일한 경로가 “숫자가 상식을 벗어나 보인다” 뿐임을 증명했다. 만약 오차가 10 억 배가 아니라 1.3 배였다면, 아무도 알아채지 못했을 것이다.

이 검증 불가능성이 특히 아픈 곳이 egress, 즉 데이터 유출 요금이다. 컴퓨트와 스토리지는 그나마 직관과 연결된다. 인스턴스 개수, 디스크 용량은 셀 수 있다. 그러나 네트워크 트래픽은 엔지니어의 멘탈 모델에서 오랫동안 “거의 공짜” 로 취급되어 왔다. CPU 와 메모리가 희소 자원이라고 배운 세대는 시스템을 설계할 때 서비스 간 통신을 사실상 무료로 가정한다. 그러나 클라우드에서 리전 간, AZ 간, 인터넷으로 나가는 바이트에는 GB 당 요금이 붙는다. 한 미디어 기업의 CFO 가 월 240 만 달러 ($2.4M) 청구서를 열어 보니 약 80 % 가 서버도 데이터베이스도 아닌, 그저 바이트를 이곳에서 저곳으로 옮긴 egress 였다는 사례는 이 구조를 압축한다. 한 스타트업은 Google Cloud 번역 API 사용량이 예기치 않게 튀어 45 만 달러 ($450,000) 인보이스를 받았고, 이의 제기 끝에 돌려받은 크레딧은 5 만 달러 ($50,000) 에 그쳤다. 조사에 따르면 기업의 42 % 가 자사의 월 클라우드 청구액을 예측하지 못한다. 이 42 % 라는 숫자야말로 이번 사고의 배경이다. 예측할 수 없는 것은 검증할 수도 없다.

바로 이 공백 위에서 FinOps 라는 산업이 자라났다. FinOps 는 클라우드 지출을 엔지니어링 · 재무 · 사업 부문이 공동으로 책임지는 실천 체계이자, 그 실천을 돕는 도구의 시장이다. AWS Cost Explorer, GCP 의 Billing, Azure 의 Cost Management 같은 사업자 기본 도구가 있음에도 CloudZero, Vantage 같은 서드파티 도구가 성장하는 이유는 단순하다. 사업자 기본 도구는 “얼마 나왔는가” 를 보여 주지만, “왜 나왔는가”, “어느 제품 · 기능 · 팀이 이 비용을 유발했는가” 를 보여 주지 않는다. CloudZero 는 클라우드 지출을 제품 · 기능 · 엔지니어링 팀에 매핑해, 모든 달러를 그것을 유발한 개발자와 기능까지 역추적하는 것을 표방한다. Vantage 는 멀티클라우드 가시성과 무료 티어로 소규모 팀에도 진입한다. 이 도구들이 파는 것은 본질적으로 “사업자가 주지 않는 투명성” 이다.

그러나 여기에 이번 사건이 던지는 날카로운 아이러니가 있다. FinOps 도구조차 사업자의 계량값을 원천으로 삼는다. CloudZero 도 Vantage 도 결국 AWS 의 CUR 과 Cost Explorer API 를 읽어 들여 분석한다. 즉 서드파티 도구는 사업자가 준 숫자를 더 예쁘게, 더 세밀하게 귀속시킬 뿐, 그 숫자 자체가 맞는지를 독립적으로 검증하지는 못한다. 이번처럼 소스인 추정 파이프라인이 10 억 배 틀리면, 그 위에 얹힌 모든 FinOps 대시보드도 함께 10 억 배 틀린다. 투명성 산업 전체가 검증할 수 없는 단일 원천 위에 서 있다는 사실이야말로, 17 억 달러의 유령 청구서가 드러낸 가장 불편한 구조다. FinOps 는 불투명성의 해결책이 아니라, 불투명성을 견딜 만한 것으로 만드는 완충재에 가깝다.

작업 문화에 대한 냉소도 스레드에 있었다. 사용자 qurren 은 이렇게 적었다. “Amazon 같은 빅테크에서 사람들이 얼마나 신경 쓰는지 과대평가하고 있다. 문자 그대로 모든 것이 당근이 아니라 채찍으로 굴러가는 곳에서, 그 작업 문화는 직원이 제품 품질을 자발적으로 신경 쓰도록 초대하지 않는다 (You overestimate how much people give shits at big techs like Amazon. When literally everything is driven with sticks instead of carrots, the work culture does not invite employees to proactively care about product quality).” 이 진단이 옳든 그르든, 요점은 개인의 태만이 아니다. 26 센트 과다 청구에 CoE 를 돌리는 조직조차 이 사고를 막지 못했다면, 문제는 개인의 주의력이 아니라 시스템의 경계면에서 단위 계약을 강제하지 못하는 구조에 있다. 신뢰는 개인의 성실함이 아니라 검증 가능한 인터페이스에서 나온다. 그리고 클라우드 과금에는 사용자가 접근할 수 있는 검증 가능한 인터페이스가 없다.

전망·실무 시사점

이 사건이 실무자에게 주는 함의는 “AWS 를 떠나라” 가 아니다. 클라우드의 대안은 대부분 더 나쁜 검증 가능성을 가진다. 더 정확한 함의는 넷이다.

첫째, 추정치와 확정치를 계약상 명확히 분리하라. 이번 사고의 유일한 실질적 위안은 오류가 추정 계층에 갇혔다는 점이다. 실무에서도 이 분리를 자기 시스템에 반영해야 한다. Budgets 경보와 CloudWatch 청구 알림은 추정치를 기준으로 작동하므로, 심야 페이지 (page) 를 실제 지출 사고로 오인하지 않도록 런북 (runbook) 에 “추정치 급등 시 CUR 의 확정 라인 아이템을 교차 확인한다” 는 절차를 넣어야 한다. 이번처럼 경보만 울리고 실제 청구는 정상인 경우, 이 교차 확인이 불필요한 심야 대응을 걸러 낸다.

둘째, 단위 계약을 시스템 경계에서 강제하라. CobrastanJorji 의 진단은 AWS 만의 문제가 아니다. 계량을 방출하는 서비스와 그것을 가격 · 소비하는 시스템 사이의 경계는 어느 조직에나 있다. 각 팀의 단위 테스트를 통과해도 경계의 단위 불일치는 남는다. 방출되는 값에 단위를 타입으로 못 박고 (예: Bytes 와 Gigabytes 를 서로 다른 타입으로 두어 암묵적 변환을 금지), 경계에서 단위를 검증하는 통합 테스트를 별도 소유자에게 배정해야 한다. 돈과 물리량을 다루는 시스템일수록 이 규율의 부재가 곧 10 억 배의 오차로 번진다.

셋째, egress 를 설계 시점의 1 급 비용으로 취급하라. 네트워크를 공짜로 가정하는 멘탈 모델은 아키텍처에 그대로 새겨진다. 리전 간 복제, 멀티 AZ 채터 (chatter), 대용량 데이터 내보내기는 청구서에서 컴퓨트를 앞지를 수 있다. 서비스 배치, 캐싱 계층, CDN 오프로드, 데이터 지역성 (locality) 을 설계 단계에서 egress 비용 관점으로 검토해야 한다. 240 만 달러의 80 % 가 egress 였다는 사례는 예외가 아니라 데이터 집약 서비스의 흔한 형태다.

넷째, FinOps 도구의 한계를 명확히 인식하라. CloudZero, Vantage 는 귀속 (attribution) 과 가시성에서 사업자 기본 도구를 능가한다. 그러나 이들은 사업자의 계량값을 검증하지 못한다. 서드파티 도구를 도입하는 이유는 “비용을 검증하기 위해서” 가 아니라 “비용을 제품 · 팀 단위로 귀속시켜 의사결정에 쓰기 위해서” 임을 분명히 해야 한다. 진짜 검증, 즉 계량 자체가 맞는지의 확인은 오직 사업자만이 할 수 있으며, 이번 사고는 그 사업자조차 틀릴 수 있음을 보였다. 유일하게 남는 방어선은 자기 애플리케이션 측에서 독립적인 사용량 카운터를 두어 사업자 청구와 대조하는 것뿐이다. 완전한 검증은 아니어도, 10 억 배의 오차는 이 대조로 즉시 잡힌다.

거시적으로는 규제와 표준화의 압력이 커질 것이다. 유럽의 데이터법 (Data Act) 이 이미 클라우드 전환 비용과 egress 요금을 겨냥하고 있고, 청구 투명성은 그 논의의 자연스러운 다음 항목이다. 이번 사고는 하이퍼스케일러의 과금이 얼마나 검증 불가능한 블랙박스인지를 대중적으로 보여 준 사건으로 인용될 것이다. 사업자 입장에서 신뢰는 마케팅의 문제가 아니라 인프라의 문제다. 검증 가능한 청구 인터페이스 — 계량의 감사 로그, 서드파티가 대조할 수 있는 원천 데이터, 단위가 명시된 라인 아이템 — 를 제공하는 것이 장기적으로 하이퍼스케일러의 방어선이 된다.

결론 — 버그는 정정되었지만 비대칭은 그대로다

17 억 달러의 유령 청구서는 몇 시간 만에 백필되어 사라졌다. 실제 돈은 움직이지 않았고, AWS 의 대응 — 90 분 내 원인 특정, 명확한 공지, 사용자 무조치 안내 — 은 위기관리의 관점에서 흠잡을 데가 적다. 이 사건을 “단발성 단위 버그” 로 읽는 것은 사실에 부합한다. 그러나 그것은 절반의 독해다.

나머지 절반은 이렇다. 월 5 달러 계정에 17 억 달러가 뜰 수 있다는 것은, 그 시스템이 매달 뿌리는 정상적으로 보이는 숫자를 사용자가 검증할 방법이 없다는 뜻이다. 10 억 배의 오차는 상식으로 걸러졌지만, 1.3 배의 오차는 아무도 걸러 낼 수 없다. FinOps 산업 전체가 이 검증 공백 위에 세워졌고, 그 도구들조차 사업자의 계량값을 원천으로 삼기에 원천이 틀리면 함께 틀린다. donavanm 이 회고한 “단위를 빠뜨리면 바이트가 기본값이 된다” 는 한 줄은, 개인의 실수담이 아니라 신뢰의 구조에 관한 진술이다. 사용자는 계량을 볼 수 없고, 오직 사업자가 계량이 맞다고 말해 주기를 신뢰할 뿐이다.

그러므로 리드 질문 — 단발성 버그인가, 신뢰의 위기인가 — 에 대한 정직한 답은 “둘 다” 다. 버그는 정정되었고 비대칭은 그대로다. 정정된 것은 숫자였고, 정정되지 않은 것은 사용자가 그 숫자를 검증할 수 없다는 사실이다. 1278 점이 정말로 반응한 것은 17 억이라는 금액이 아니라, 그 금액이 뜰 수 있었다는 사실이 폭로한 구조였다. 클라우드 청구서의 숫자를 우리는 여전히 믿을 수밖에 없다. 이번에 달라진 것은, 그 믿음이 검증이 아니라 신뢰였음을 모두가 잠시 또렷이 보았다는 점뿐이다.

출처: