17억 달러 청구서 오류: 클라우드 과금, 왜 아무도 다 이해하지 못할까

1. $17억 청구서, 월 사용료는 원래 $5도 안 됐다

2026년 7월 17일, nprateem이라는 AWS 사용자가 Hacker News에 글을 올렸다. 그의 AWS 월 예상 청구서 금액이 $1,700,000,000 — 17억 달러로 표시되고 있었다. 반면 그가 평소 내던 월 요금은 5달러가 채 안 됐다.

그는 눈을 의심했다. 눈을 비비고 다시 봤다. 하지만 틀린 게 아니었다.

이 사용자는 즉시 긴급 티켓을 생성했고, 글에서 “다른 분들도 이런 일 겪으신 분 있나요?”라고 물었다.

답은: 있다, 아주 많다.

Reddit과 X(구 Twitter)에는 순식간에 수많은 캡처 화면이 쏟아졌다. 지난달에 고작 $0.19를 쓴 사용자가 25억 달러에 가까운 예상 청구서를 받았다. 또 다른 사용자는 X에 이렇게 썼다. “방금 AWS 청구서에서 1.5조 달러를 봤는데, 내 영혼이 몸에서 빠져나갔다.” 이 글은 130만 회 조회와 약 1.9만 개의 좋아요를 받았다.

당황한 나머지 아예 계정의 모든 리소스를 지워버린 사용자도 있었다. “말할 것도 없이, 나는 패닉에 빠져서 이 계정의 모든 것을 파괴해 버렸다.”

하지만 이 숫자들은 실제로 청구된 금액이 아니었다. AWS는 빠르게 문제가 된 것은 “예상 청구서”이지 실제 요금이 아니라고 확인했다. 그렇지만 그 숫자를 보는 순간, 침착함을 유지한 사람은 아무도 없었다.

2. 무슨 일이 있었나?

AWS 공식은 사건 발생 90분 만에 원인을 설명했다. “예상 청구서 계산 하위 시스템의 단위 가격 책정 문제.” 겉보기엔 복잡해 보이지만, 풀어서 말하면 — 단위 하나를 잘못 쓴 것이다.

이 사건을 진짜로 명쾌하게 설명해 준 사람은 donavanm이라는 전직 AWS 엔지니어였다. 그는 Hacker News 댓글란에 이런 글을 남겼다(필자 번역).

“내가 AWS에 있을 때 똑같은 오류를 처리한 적이 있다. 이건 단위 오류다. 원래 $0.05/GB로 받으려고 했는데 단위(GB)를 빼먹었고, 그 바람에 과금 시스템이 기본값인 byte 단위로 계산했다. $0.05 per byte의 데이터 전송 요금은, 어떤 고객들은 몇 시간 만에 백만 단위의 청구서를 보게 됐다는 뜻이다. 새벽 2시에 고객 지원 팀에게 긴급 호출을 받았고, 3시에서 4시 사이에 고치고 수정본을 배포한 뒤 사과 메일을 보냈다.”

이 글에는 몇 가지 핵심 정보가 담겨 있다.

첫째, 이건 처음이 아니다. 같은 유형의 오류는 과거에도 발생했다 — 필자가 말하는 “과거”는 심지어 한 번 이상일 수 있다.

둘째, 오류의 증폭 배수가 놀랍다. 1GB = 1,073,741,824 bytes. “GB”를 쓰는 걸 잊으면 시스템은 기본값으로 byte 단위로 가격을 매기고, 청구서는 순식간에 10억 배 부풀어 오른다. $0.05의 사용료가 $53,687,091.20이 된다.

셋째, 이 오류는 출시 전에 자동으로 검출되지 않는다. 개발·테스트·배포의 모든 단계를 뚫고 지나가, 사용자가 청구서 캡처를 보고 패닉에 빠져 글을 올려 도움을 요청하고 나서야 발견됐다.

3. 왜 “단위 하나를 빠뜨리는 것”만으로 모든 방어선을 가뿐히 뚫고 지나갈까?

이것이 바로 이 사건에서 가장 불안한 부분이다.

donavanm은 AWS 과금 시스템의 작동 방식을 더 설명했다. 서비스의 계량 데이터(얼마나 리소스를 썼는지)와 가격 정보(단위당 얼마인지)는 따로 저장된다. 각 SKU(각 과금 항목 하나하나라고 생각하면 된다)는 “가격 책정 계획” 안에 정의되며, 단위 유형·적용 지역·단가 등의 정보를 포함한다. 계량 기록과 가격 책정 계획은 계정 ID, 지역, SKU 번호 같은 필드로 매칭된다.

가격 책정 계획에서 단위 유형을 잘못 채워 넣으면 — 원래 GB여야 할 것을 비워 두거나 byte로 써버리면 — 계량 데이터와 가격의 환산이 어긋난다. 그리고 이 오류를 막을 수 있는 자동 검사가란 게 없다.

Hacker News의 또 다른 사용자 댓글은 아주 날카로웠다.

“테스트는 없었나? 그냥 눈에 잘 띄지 않는 사소한 디테일 하나를 잘못 쓴 거 아니야 — 그리고 수십만 명의 관리자가 심장마비가 올 뻔한 청구서를 받았다고?”

다른 사용자가 이 질문에 답했다.

“테스트는 당연히 있다. 테스트 1은 서비스가 계량 데이터를 올바른 방식으로 내보내는지 검증한다(‘우리는 100 bytes 작업을 했고, 과금 시스템이 100 bytes 데이터를 받았는지 확인, 통과’). 테스트 2는 과금 시스템의 계산 로직을 확인한다(‘SKU#12345에 100개 GB 단위를 입력하면 $17 계산, 통과’). 하지만 이 두 테스트를 연결해 함께 돌려본 사람은 없었다 — 서로 다른 팀, 서로 다른 관리 계층이 걸려 있어서, 하기가 더 어렵기 때문이다.”

필자는 이 설명이 아주 통찰력 있다고 본다. 여기에는 흔한 공학 관리 문제가 드러난다. 각 단계가 따로따로는 다 맞지만, 합쳐 놓으면 틀어진다. HN 사용자 중에는 이런 보충 의견을 낸 사람도 있었다. “어떤 회의에서 ‘우리는 테스트가 진짜로 과금 프로세스를 한 번 돌게 해야 한다’고 말한 사람이 있었고, 그러자 누군가 ‘테스트가 진짜로 청구서를 발생시키게 하는 건 법적/재무적 문제일 수 있고, 심지어 범죄일 수도 있다’고 했고 — 그 뒤로 두 번째로 좋은 대안이 뭔지 따지는 사람은 없었다.”

4. 진짜 “악당”: 클라우드 과금의 복잡도

이 사건을 그저 “어떤 엔지니어가 설정을 빈틈없이 잘못 썼다”로 이해한다면 핵심을 완전히 놓치는 것이다.

진짜 악당은 클라우드 과금 시스템 자체의 복잡도다.

AWS에는 약 30만 개의 서로 다른 SKU(가격 책정 단위)가 있다. 300개가 아니라 30만 개다. 각 SKU는 저마다 독립된 가격 책정 로직을 갖는다 — 시간별, 트래픽별, 요청 횟수별, 저장 용량별, 지역별. 그리고 서로 겹쳐 쌓이기도 한다. 단순한 웹 요청 하나가 컴퓨팅 요금, 네트워크 전송 요금, 저장 읽기 요금, 로그 기록 요금, 모니터링 데이터 요금을 동시에 유발할 수 있다. 각 항목마다 저마다의 가격 단위와 규칙이 있다.

사용량 데이터의 생성과 가격 데이터의 설정은 완전히 별개의 시스템이다. 둘 사이의 매칭은 필드 연결에 의존하지, 하드코딩된 검증에 의존하지 않는다. 이 설계 자체는 잘못이 없다 — AWS에게는 가격 책정 시스템을 고치지 않고도 가격을 조정할 수 있는 엄청난 유연성을 준다. 하지만 그 대가는 이렇다. “내 이 작업이 결국 얼마나 들 것인가”를 완전히 이해하는 사람은 아무도 없다.

사실 AWS 청구서는 복잡해서, AWS 청구서를 대신 해독해 주는 직업까지 생겨났다 — 클라우드 비용 최적화 컨설턴트. 연 매출 1,000억 달러가 넘는 사업 위에서, 고객이 진짜 얼마를 썼는지 알려주는 전담 “통역사”가 필요하다는 사실 자체가 뭔가를 시사한다.

심지어 AWS 자체 엔지니어들도 HN 토론에서 불안한 사실 몇 가지를 솔직히 털어놓았다. 전 AWS 직원이라 밝힌 한 사람은 이렇게 썼다. “회사 전체가 마치 루브 골드버그 머신(일부러 지나치게 복잡하게 설계한 기계 장치) 같다. 자기가 맡은 그 작은 한 조각 바깥에서 무슨 일이 벌어지는지 신경 쓰는 사람은 드물다 — 그럴 동기가 없기 때문이다.”

또 다른 전 직원이 덧붙였다. “나는 ‘기여가 경영진에게 보이지 않는다’는 이유로 성과 개선 계획(Focus)에 넣어졌다. 이런 환경에서 동료 코드의 잠재적 위험을 보고, 내가 나서서 지적하고 고칠 동기는 전혀 없다 — 내가 고쳐도 연말 성과 평가에서는 일정 비율의 사람이 ‘비효율’ 등급으로 분류돼야 하니, 그 사람이 버그를 남긴 동료가 되지 말란 법이 어디 있나?”

물론 다른 목소리도 있다. 전 AWS 매니저급 직원은 반박했다. “이 정도 고객 영향은 무조건 COE(오류 교정) 보고서를 트리거한다. 즉, 필수적인 개선 조치 항목을 한 bunch 써야 하고, 최소 한 사람 한 달치 작업량을 잡아먹는다는 뜻이다. COE는 팀 전체에게 엄청난 귀찮음이라, 그 자체로 문제 예방에 대한 강한 동기가 된다.”

필자는 어느 쪽도 편들지 않는다. 이 두 주장은 동시에 참일 수 있다 — 부서마다, 관리 계층마다 문화적 차이가 너무 크기 때문이다. 하지만 그게 바로 이걸 보여준다. 수만 명의 엔지니어를 둔 조직에서, 모두가 제대로 하려 해도 시스템적 구멍은 그래도 줄줄 새어 나갈 수 있다.

5. AWS는 어떻게 대응했나?

AWS 상태 대시보드(Health Dashboard)의 공개 타임라인을 보면:

• 7월 17일 새벽 3:52 PDT: AWS가 근본 원인이 “예상 청구서 계산 하위 시스템의 단위 가격 책정 문제”라고 확인하고, 청구서 예상 계산을 중단했다.
• 새벽 4:58: 두 갈래의 복구 경로를 동시에 시도 — 최근 변경 사항을 롤백하거나, 마지막 정확한 데이터로 복구한다.
• 오전 5:54: 내부 모니터링이 과금 하위 시스템이 올바른 예상을 생성할 수 있음을 보여주었고, 추가 검증 중이다.
• 오전 7:53: 나쁜 소식 — 롤백이 문제를 해결하지 못했다. 두 복구 경로 모두 여전히 진행 중이다. 예상 청구서 업데이트는 계속 중단된다.
• 오전 9:59: 근본 원인을 찾아 수정했고, 모든 고객을 위해 청구서 데이터를 다시 계산하기 시작했다. 일부 고객은 3시간 내에 복구될 것으로 예상, 전 고객은 7월 18일 정오 전 복구.
• 정오 12:56: 진행이 예상보다 느리다. 전면 복구가 7월 19일 새벽으로 지연될 것으로 예상. 성명은 “표시된 청구서 예상은 실제 사용과 요금을 반영하지 않는다. 고객은 어떠한 조치도 취할 필요가 없다”고 강조했다.

단위를 빼먹은 버그 하나를 고치는 데 AWS는 24시간 넘게 걸렸다 — 게다가 첫 번째 복구 시도는 실패했다. 이는 역으로 말해 준다. AWS 자체 엔지니어라도 자기 시스템의 버그를 고치는 건 만만치 않은 일이라는 것을.

6. 이게 무슨 뜻인가?

이 사건은 결국 실제 경제적 손실을 전혀 낳지 않았다 — 아무도 더 청구되지 않았다. 하지만 드러난 문제는 “어떤 엔지니어가 부주의했다”보다 훨씬 깊다.

첫째, 클라우드 과금은 이미 “아무도 완전히 이해하지 못하는” 시스템이 됐다. AWS가 그중 가장 극단적인 예다. 하지만 구글 클라우드, 마이크로소프트 Azure도 같은 문제에 직면해 있다. 시스템의 복잡도가 어떤 개인의 이해력을 넘어서면, 그것은 더 이상 통제 가능한 도구가 아니라, “관찰하고, 추측하고, 틀리지 않길 빌기만” 하는 블랙박스가 된다.

둘째, AI 시대가 이 문제의 스테이크를 높이고 있다. 바로 지난주, AWS는 고객 대상 AI 엔지니어 팀에 10억 달러를 투자한다고 발표했다. 단일 AI 학습 작업 하나의 월 청구서가 수억 달러에 달할 수 있다. 실제 청구서 규모가 이토록 거대해지면, 과금 오류가 설령 “예상 표시”에 그치더라도 초래하는 사회적 공황과 신뢰 손실은 과거보다 훨씬 심각하다.

셋째, 이 버그는 처음이 아니었고, 마지막도 아닐 것이다. 전 AWS 엔지니어 donavanm 본인도 똑같은 오류를 겪었고, 새벽 2시에 불려 나가 긴급 수정했다. 이는 이 구멍이 AWS 시스템에 최소 수 년은 존재했고, 최소 두 번 발생했으며, 두 번 모두 대규모 사용자 공황을 일으켰음을 뜻한다. 하지만 줄곧 시스템적으로 막히지 않았다.

여기까지 쓰고 보니, 필자는 donavanm이 AWS 과금 아키텍처를 묘사한 그 문구가 떠오른다. “서비스의 계량 데이터는 가격에 직접 연결되지 않는다.” 이 말을 쉽게 풀면 — 당신의 사용량과 당신의 청구서 사이에는, 최소 두 겹의 수동 설정 매핑 관계가 끼어 있다는 뜻이다. 어느 한 겹이라도 잘못 쓰이면 결과는 이렇다. $5가 $17억이 된다.

참고 링크

• HN 토론 글: AWS 예상 청구서 데이터 부정확에 관한 Hacker News 토론. 원글 작성자 nprateem이 17억 달러 청구서 캡처를 올려, 992점, 618개 댓글의 뜨거운 논의를 불러일으켰다(item?id=48945241)
• 전 AWS 엔지니어 donavanm의 근본 원인 분석 댓글: 가격 단위 설정 오류(byte 대 GB)가 어떻게 청구서를 10억 배 부풀리는지, 그리고 AWS 과금 시스템에서 계량 데이터와 가격이 분리된 아키텍처 설계를 상세히 설명
• AWS Health Dashboard 공지: “Billing Console - 예상 청구서 데이터 부정확”에 관한 AWS 공식 상태 페이지의 전체 사건 타임라인. 근본 원인 확인부터 수정 완료까지의 모든 업데이트 기록
• The Next Web 보도: 이 사건의 영향 범위를 종합 보도했으며, Reddit 사용자 반응($0.19 월 요금이 $25억으로)과 AWS의 복구 일정표를 포함
• Cyber Kendra 보도: X 플랫폼 사용자 @Bharath_uwu가 올린 1.5조 달러 청구서 캡처와 AWS Support 공식 대응을 인용
• TechRadar 보도: 제목 “내 영혼이 몸에서 빠져나갔다”, 여러 사용자의 공황 반응을 인용했으며, 클라우드 리소스를 통째로 삭제해 버린 극단적 사례도 포함