# AWS 예상 청구액이 17억 달러로 표시됨, 평소 사용료는 5달러 미만 > Clean Markdown view of GeekNews topic #31535. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31535](https://news.hada.io/topic?id=31535) - GeekNews Markdown: [https://news.hada.io/topic/31535.md](https://news.hada.io/topic/31535.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-18T09:46:21+09:00 - Updated: 2026-07-18T09:46:21+09:00 - Original source: [news.ycombinator.com](https://news.ycombinator.com/item?id=48945241) - Points: 1 - Comments: 1 ## Topic Body - 평소 사용료가 **5달러 미만**인 AWS 계정에 이번 달 예상 청구액이 **17억 달러**로 표시됨 - 실제 사용량과 청구액의 차이가 지나치게 커 **예상 청구 데이터가 부정확한 상황**으로 보고 있음 - 게시자는 문제를 확인하고 대응하기 위해 **긴급 AWS 지원 티켓**을 생성함 - AWS 서비스 상태는 **AWS Health Dashboard**에서 확인할 수 있음 - 같은 현상을 겪는 사용자가 있는지 확인을 요청했으며, 이후 관련 **Reddit 게시물**도 추가함 --- ### 비정상적인 예상 청구액 - 이번 달 AWS 예상 청구액은 **17억 달러**로 표시됐지만, 해당 계정의 평소 사용료는 **5달러 미만**임 - 게시자는 이처럼 큰 차이가 실제 사용량이 아닌 부정확한 예상 청구 데이터에서 비롯된 것으로 보고 있음 ### 확인 및 대응 - 문제 확인을 위해 **긴급 AWS 지원 티켓**을 생성함 - 서비스 상태는 [AWS Health Dashboard](https://health.aws.amazon.com/health/status)에서 확인할 수 있음 - 다른 사용자에게도 같은 현상이 발생했는지 질문했으며, 이후 관련 [Reddit 게시물](https://www.reddit.com/r/aws/comments/1uyuaw7/help_my_bill_skyrocketed_from_around_5_cents_per/)을 공유함 ## Comments ### Comment 61972 - Author: neo - Created: 2026-07-18T09:46:22+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48945241) - AWS에서 같은 오류를 처리한 적이 있는데, 원인은 **단위 설정 오류**였음. GB당 약 5센트를 청구하려 했지만 요금제에서 GB를 빠뜨리자 시스템이 기본 단위인 바이트로 처리했고, 바이트당 5센트가 되어 몇 시간 만에 일부 고객에게 수백만 달러짜리 청구서가 표시됨 새벽 2시쯤 지원팀 호출을 받아 3~4시까지 수정과 청구 정정을 마쳤고 곧바로 사과 메일도 보냈음. 서비스가 내보내는 사용량 값은 가격과 직접 연결되지 않으며, 각 SKU나 청구 항목은 단위 유형·리전·단위당 가격을 포함한 **요금제**로 정의됨. 계정 ID·리전·SKU 등을 기준으로 사용량 기록과 요금제를 결합하므로, 단위 유형을 잘못 지정하면 변환이 깨져 터무니없는 청구액이 나옴 - 테스트가 없었던 건가? 평범해 보이는 세부 사항 하나를 잘못 설정하면 수십만 명의 관리자에게 **새벽 호출과 심장마비**를 안길 수 있다는 건가? 물론 “이건 평범한 세부 사항이 아니야, Michael!”이라고 하겠지만: [https://www.youtube.com/watch?v=3fGHaVn5rGo]() - AWS 청구 시스템이 아직도 데이터 전달에 **CSV 파일**을 쓰는지 궁금함. 10여 년 전 AWS에서 첫 당직을 맡았을 때, 어느 “똑똑한” 엔지니어가 운영 데이터의 설명 필드에 “이 필드에, 쉼표를 넣으면 어떻게 될까” 같은 실험용 레코드를 넣어 청구 처리가 깨졌음 그 레코드가 퍼지면서 리전들이 차례로 같은 방식으로 실패하는 모습을 지켜봤고, 한 사람이 수많은 이의 저녁을 망쳐 놓았음. 테스트 엔드포인트를 쓸 수 있었지만 굳이 **운영 환경에서 시험**한 셈임 - 농담으로 넘길 일이 아님. 심혈관 질환 같은 기저 질환이 있는 사람이 갑자기 이런 청구액을 보면 불안·충격·무력감 때문에 실제로 사망할 가능성도 있음 - 어리석은 기본값을 택하기보다 항상 **크게 실패하도록(fail loud)** 만드는 이유가 이것임 - 혹시 **gp3 EBS 볼륨**이 출시된 날 벌어진 일이었는지 궁금함 - 예산이 18달러 한도를 넘었다는 경고 메일을 연달아 세 통 받고 확인했더니 비용이 **7,800만 달러**였음. 피싱인 줄 알고 실제 계정으로 직접 로그인했지만 여전히 7,800만 달러여서 정신적 충격이 상당했음 - 오늘 안에 이 채용 공고의 설명이 수정될지 내기하고 싶음: “Software Development Engineer II, AWS Invoicing” [https://www.amazon.jobs/de/jobs/10428480/software-developmen...]() 생성형 AI·대규모 언어 모델·지식 그래프·에이전트형 아키텍처로 출시 준비, 클라우드 네이티브 서비스 조정, 지속적 검증을 자동화한다는 **화려한 직무 설명**이 붙어 있음 - 내 청구액은 **10억 달러 이상**이었음. 처음에는 피싱이라 생각해 버릴 뻔했지만 너무 진짜 같아 AWS에 직접 로그인했고, 예상 청구액을 보고 심장마비가 올 뻔했음 나중에 지원 페이지에서 장애 배너를 찾았지만, 정작 “당신이 10억 달러를 빚졌다”고 표시하는 청구 페이지에는 왜 안내 배너가 없었는지 의문임 - 나도 `awstrack.me` URL이 몹시 수상했고 이런 경고를 처음 받아 피싱이라고 확신했음. 링크를 누르지 않고 콘솔에 들어가 보니 청구액이 잘못 표시되는 장애가 있었지만 이메일 경고 이야기는 없었고, 오히려 공격자가 장애를 틈타 탐지를 피한 건 아닌지 걱정됨 로그를 확인한 뒤 장애 안내가 영향 범위를 빠짐없이 적지 않았을 뿐임을 깨닫고 다시 커피를 마시러 갔음. 다음부터는 **여기부터 확인**해야겠음 - 오래된 농담을 바꾸면, AWS 청구서가 7만8천 달러라면 내 문제지만 **7,800만 달러라면 Amazon의 문제**임 - 기업 계정에는 **3조 달러가 넘는 청구액**이 표시됐음 - 이번 오류는 너무 터무니없어 곧 수정되겠지만, 2010년대 초에는 실제 청구서에 숨어 있던 오류를 발견한 적이 있음. 일부 서버의 **EC2 예약 할인**을 잘못 계산하고 있었고, 18개 탭짜리 스프레드시트로 세부 사용량을 정기 분석해도 금액이 맞지 않아 몇 달간 차이를 추적했음 원인을 찾은 뒤에도 AWS 시스템이 틀렸다고 설득하는 데 상당한 시간이 들었고 그동안 차액은 계속 쌓였음. 14개월 후 **7,000달러 환불**을 받았으며 AWS 책임자의 승인이 필요했다고 들었고, 이후 AWS 측 계산 오류는 다시 보지 못했음 - 7,000달러 크레딧 자체는 당시 가까운 제품 관리자나 디렉터도 큰 감독 없이 발급할 수 있었음. 문제는 **14개월이라는 기간**으로, 같은 청구 주기의 수정은 쉽고 직전 주기도 번거롭지만 흔한 반면, 이전 회계연도들까지 정정하려면 재무 부서를 거쳐야 해서 훨씬 고통스러움 - 동료들은 내가 Cost Explorer를 지나치게 자세히 본다고 여기지만, 이상한 비용을 찾아내는 시간은 대체로 충분히 본전을 뽑고도 남았음. 이 오류를 추적하는 데 7,000달러어치 시간을 쓰지는 않았을 것이고, 그 과정에서 더 큰 **비용 최적화 기회**도 찾았을 가능성이 큼 돈을 낭비해 Jeff Bezos의 요트를 더 크게 만들어 주는 것도 싫음 - “곧 수정될 것”이라기엔 이미 **12시간째**임. 사람이 에이전트가 작성해 반영한 코드를 이해하지 못하는 모양임 - 원래 `GB of storage consumed`여야 할 단위가 `Bytes of storage consumed`와 뒤섞여 **2^30배 오류**가 난 듯함 “계산을 의심할 만합니다. 필드 정의를 조회하려 했지만 MCP 서버 연결에 실패했고, 검증 대신 추측했습니다. 제 잘못입니다. 하지만 늘어난 매출을 보세요!” - 고객에게 청구할 금액을 계산해 달라며 0.45, 1.67, 2.50을 줬으니 합은 4.62지만 다른 숫자일 수도 있음. 이어 붙여야 할 수도 있고, 점이 곱셈을 뜻한다면 `0 . 45 . 1 . 67 . 2 . 50`은 3,015,000이 됨 0을 곱하면 0이어야 하지만 아무것도 청구하지 않을 수는 없으니 **3,015,000천 달러**가 정답임 - “계산을 의심할 만합니다”가 패러디인지 실제 응답인지 이제는 구분조차 어려움. LLM이 절대로 내놓지 못할 만큼 어리석은 문장을 써 보라고 해도 그런 **어리석음의 한계**는 없을 듯함 - 오늘 로컬 에이전트에 사람이 읽을 수 있는 크기 단위가 담긴 CSV를 주고 GB 구간별 행 수를 세게 했는데, 이상하게 MB를 GB로 해석해 완전히 틀렸음. 돌이켜 보면 **Excel로 직접 계산**하는 편이 더 빨랐을 것임 - `2*30`이면 60이므로 2,830만 달러만 내면 되지만, 의도한 것은 아마 **`2^30`** 이고 그러면 1.5달러가 됨 - 청구 시스템을 **바이브 코딩**해 매출을 9,000% 올렸으니 승진 자료로는 훌륭함 - 아침에 청구 경고 메일을 보고 AWS 키를 실수로 유출해 **4,370억 달러**를 쓴 줄 알았음. 다행히 내게는 그만한 돈이 없으며, 커피 없이도 전에 없던 아드레날린이 분출됐으니 AWS에 감사함 - AWS에 43만7천 달러를 빚졌다면 내 큰 문제지만, **4,370억 달러**를 빚졌다면 AWS의 큰 문제임 - 이 일로 실제 심근경색을 겪거나 사망한 사람이 있을지도 모름. Amazon이 이런 값을 사용자에게 그대로 표시한 것은 **무책임한 처리**임 - 잠들려던 중 경고를 받았는데, 내가 설정한 **16달러 한도**를 확실히 넘긴 금액이었음 - 탈취된 계정 때문에 AWS와 두 달간 싸웠음. 이전 3년 동안 월 사용료가 약 20달러였는데도 2만 달러를 잃고 수만 달러짜리 청구서가 더 들어왔으며, AWS는 내가 직접 침해를 막기 전까지 돕지 않았음 퇴근 후 밤을 새워 AWS 인프라 스크립팅을 배워 침해를 통제했지만 계정 폐쇄도 거부당했고, 사례를 검토하려면 **공동 책임 합의서**에 서명하라는 요구도 거절했음. 결국 주 법무장관실에 연락하자 그곳에서 AWS에 직접 이메일을 보냈고, 24시간도 안 돼 AWS 관리자가 전화해 계정을 정리하고 2만 달러를 환불해 줬음. 그런데도 계정 폐쇄는 끝내 거부해 AWS에서 완전히 빠져나갈 방법이 없는 듯하며, 최악의 사업 방식으로 느껴짐 - 내 경우는 **5억 달러**였고 손이 너무 떨려 비밀번호조차 입력하기 어려웠음 - 계정 담당자에게 예산 사정을 알리고, 다시 형편이 나아질 때까지 매달 **수십억 달러씩 성의 있게 상환**할 수 있는지 관대하게 봐 달라고 요청하면 됨 - 약한 모습을 보여서는 안 됨. 정면으로 해결하고 **한도가 더 큰 신용카드**를 발급받아야 함 - 은행에 100달러를 빚지면 내 문제지만, **17억 달러를 빚지면 은행의 문제**임 - 아내가 이전 직장에서 중견 기업 행사를 맡았을 때 행사 후 법인 Amex 잔액이 보통 30만 달러를 넘었음. 출산 휴가 중 대체 담당자가 청구서를 내지 않아 복귀했을 때는 미납액이 **50만 달러 이상**이었고 Amex의 이메일과 음성 메시지가 잔뜩 쌓여 있었음 메시지는 처음엔 정중했다가 점차 다급해졌지만, 한 번도 위협적이거나 적대적으로 변하지 않았음 - 이 농담은 실제로 AWS에 17억 달러의 비용을 안겼을 때만 성립함. 이유 없이 청구서만 발행한 것이라면 여전히 **사용자의 문제**임 - 그렇다면 은행에 **1조7천억 달러**를 빚지면 어떻게 되는지가 다음 질문임 - Elon Musk라면 해당되지 않을 수 있음 - AWS가 Anthropic이 사용량 0인 사람에게 **1,600만 달러**를 청구한 것을 보고 수백만 달러에서 멈출 이유가 없다고 생각한 모양임 [https://www.techtimes.com/articles/320266/20260712/anthropic...]() - AI 청구 감사 스타트업 Vaudit가 기업 고객 60곳의 청구서 3,400만 달러어치를 검토해 약 **170만 달러의 과다 청구**, 즉 약 5%의 오류율을 발견했다면 상당히 심각함 - 최근 Whole Foods에서 결제할 때 **Chase Amazon Prime 카드**를 더는 자동으로 안정적으로 인식하지 않아 할인가가 자동 적용되지 않는다는 사실을 알았음. 수년간 잘 작동하던 방식대로 결제하면서 정가를 내는 고객이 얼마나 될지 궁금함 매장 고객 서비스 직원에 따르면 지난 1년 사이 바뀌었으며, 손바닥 결제 기능을 없앤 데 따른 의도치 않은 부작용으로 추측함. 직접 관련된 일은 아니지만 Amazon이 또 무엇을 제대로 계산하지 못하고 있을지 떠오름 - 이제 **집단소송**이나 수천 건의 소액재판을 진행할 차례임. 중재 조항이 있더라도 이를 처리하는 부담은 막대하므로, 누군가 옳은 결정을 내려 자동 환불하기를 바람 - 예전에는 단순하고 안정적이던 시스템에서 이런 작은 문제가 수없이 생기고 있음. 모두가 바이브 코딩 때문은 아니겠지만, 그중 얼마나 많은 문제가 **바이브 코딩의 결과**인지 궁금해짐 - 한 번은 **2만 달러 청구액이 은행 계좌에서 실제 인출**됐고, 해결해 돈을 돌려받기까지 몇 달과 주 법무장관실의 개입이 필요했음. 이후 AWS 제품은 전혀 쓰지 않고 작은 작업도 Azure로 옮겼음 AWS 청구 문제는 수년째 이어졌으며, 탈취된 계정에서 암호화폐 채굴 서버가 몇 달 동안 돌아가 학생에게 6만 달러가 청구됐는데도 AWS가 탐지하거나 차단하지 못한 일들을 온라인에서 쉽게 찾을 수 있음 - AWS는 사실상 **공공 서비스 사업자**에 가까우므로, 청구를 부주의하게 다루다 보면 결국 그에 준하는 규제를 받게 될 수밖에 없음 - 변동 비용 서비스에는 항상 **지출 한도 카드**를 사용해야 함 - 탈취 계정 탐지가 100% 정확할 수는 없다고 봄. 사람이 직접 보면 명백해도 모든 계정의 사용량을 사람이 선제적으로 검토할 수는 없음 - 서비스 제공자 이용의 첫 번째 교훈은 **자동 결제를 절대 활성화하지 않는 것**임. 편리함이나 할인보다 업체가 자율적으로 계좌의 돈을 모두 빼 갈 위험이 훨씬 큼 - 한동안 홈랩 일부를 AWS에 두었음. 학생들이 클라우드를 배우는 교실의 교육자였고 강사가 실습용 환경을 만들도록 권해 나도 무료 등급 EC2에 LAMP 스택 MediaWiki를 설치했는데, 초기 구성은 어렵지 않았지만 두 가지 이유로 영원히 떠나게 됐음 첫째, 오늘날에도 인터넷에 노출된 평범한 Linux 시스템을 충분히 보호하기가 불가능하거나 지나치게 노동집약적이었음. fail2ban을 설치하고 많은 포트를 막아도 스팸 공격은 응용 계층으로 들어왔음. 둘째, 청구 주기마다 **클라우드 지출 상한을 강제하는 것이 실제로 불가능**했음. 대부분 무료 한도 안에 들어와도 설정 하나가 틀리거나 자원이 폭주하면 이의를 제기하기 어려운 큰 청구서가 생기며, 특히 외부 사용자가 VPC 자원과 외부 전송 트래픽을 소비하는 등 통제 밖의 원인으로도 발생할 수 있었음. 그래서 계정을 닫았고, 자체 설비 대신 클라우드를 강제로 쓰면서도 비용을 통제할 수 없는 기업들에 깊이 공감하게 됐음