서버리스 공포 이야기

• 다양한 SaaS 및 서버리스 서비스에서 예상치 못한 대규모 요금 청구 사례가 빈번히 발생하는데, 이를 보기 좋게 정리한 페이지
• 정상적으로 월 구독료를 내던 사용자가 DoS 공격이나 무분별한 리소스 사용으로 인해 하루 만에 수만~수십만 달러의 요금을 청구받는 사례가 드러남
• 일부 서비스에서는 지출 한도를 설정했음에도 초과 요금이 부과되는 등, 시스템적인 한계가 부각됨
• 개발자 커뮤니티에서 이와 같은 경험을 공유하며, 비상식적인 과금 구조와 투명성 부족이 주요 이슈로 지적됨
• 서버리스 및 클라우드 환경에서는 사소한 실수나 공격 하나로 막대한 금전적 손실이 발생할 수 있어 주의 필요성 부각됨

---

서버리스 및 SaaS 서비스 과도한 청구 사례 모음

#1 Webflow에서 발생한 고액 과금

• 월 69달러 요금제를 사용하던 중, 아무 이유 없이 한 달 치 요금으로 $1,189.42가 청구됨

#2 WebGL 게임 사이트 DoS 공격 사례

• 중형 규모의 WebGL 게임 업로드 사이트 운영자가 DoS 공격 발생 이후, Google Firebase에서 하루 만에 $100,000이 넘는 요금 청구를 받음

#3 Vercel Pro 및 지출 한도 초과

• Vercel Pro 요금제를 월 $20에 사용하며, $120 지출 한도를 설정함에도 불구하고 예기치 못한 추가 요금이 나옴

#4 프로젝트 과금과 초고액 청구

• 한 달에 $50 지불하던 프로젝트에서, 어느 날 아침 $70,000에 이르는 과금 청구서를 받은 사례 등장

#5 BigQuery 사용 및 공공 데이터셋 과금 이슈

• Playgroud 환경에서 BigQuery를 사용하다가 $22,000이 넘는 엄청난 요금이 청구됨

#6 소규모 방문자 대비 과도한 호스팅 요금

• 월 방문자 9,000명임에도 월 $250의 요금이 청구되어, 1년이면 $3,000 지출 필요 상황임

#7 Devin(AI)이 코드베이스 변경 후 발생한 문제

• Devin이라는 AI가 코드 변경 작업을 수행했을 때의 예기치 못한 결과 경험

#8 무료 사용 후 갑작스런 과금

• 한 번도 결제한 적 없었으나 어느 날 갑자기 $530 청구가 발생함

#9 문서 사이트 및 기타 소규모 프로젝트 과금

• 단순한 문서화 사이트에 거의 $400가 청구되는 등, 사용량이 적은 서비스에서도 고액 청구 사례가 많음

#10 무료 티어의 공포

• $103 정도의 청구도 문제로 인식됨. 특히 무료 티어 이용 중 갑작스러운 계산서 발생이 불안요소임

#11 Cloudflare, AWS 및 기타 이슈

• Cloudflare에서 24시간 이내에 $120,000을 내라는 통보와 함께 서비스 중단 사례 있음
• AWS S3에서 빈, 프라이빗 버킷 생성 후에도 예기치 못한 과금이 발생
• Netlify에서 $104,500의 미결제 청구서 수신 등 다양한 공급자에서 유사 사례 반복

#12 DoS 공격 및 이메일, 데이터 손실

• DoS 공격 중 이메일 발송으로 $11,000 사용, 이후 데이터베이스도 손실됨

#13 Vercel 대량 과금 및 계정, 트라이얼 문제

• Vercel에서 스팸 공격으로 하루 만에 $23,000 청구, 56,000개 계정 및 트라이얼 활성화됨

#14 테스트/배포 과정에서 예상치 못한 요금 청구

• 테스트 목적으로 Vercel 등에 기능을 배포하다 예기치 못한 금액이 청구됨
• 사이트맵(sitemap.txt)이 수백 GB 단위로 대역폭을 사용하며 고액 과금 발생

#15 Firebase, Cloud Run 테스트 비용

• Firebase와 Cloud Run 테스트 단 두 번으로 $72,000 소진, 서비스가 파산 위기에 직면함

결론 및 시사점

• 서버리스와 클라우드 환경에서의 비용 구조가 불투명하거나 공격 및 실수에 매우 취약함
• 예상치 못한 과금 사례가 다수 보고되며, 서비스 운영 시 주의 깊은 모니터링과 사용량 관리, 허용 한도 설정이 꼭 필요함
• 자동화 및 모니터링 기능이 미흡할 경우, 단순한 테스트나 외부 공격 한 번으로 수만 달러의 예상치 못한 손실이 발생할 수 있음
• 개발자, 스타트업 등 SaaS 사용자들에게 비용 관리와 리스크 인식의 중요성이 커지고 있음

[ahwjdekf]

대기업 내부 dw를 위한 개발을 했었는데 aws로 기존 온프레미스 데이터를 옮기는 작업이었음. 그런데 수개월의 개발 및 테스트를 끝내놓고도 결국 무산됨. 돈이 생각보다 너무 많이 매달 청구될거 같다는 이유로. 대기업조차 클라우드 지출은 쉽지 않음

[regentag]

저도 AWS 공부할 목적으로 계정 만들었다가 소액이지만 금액을 청구당한적이 있었습니다.
계정이 뚫려서 누군가가 제 계정으로 인스턴스 생성해 돌렸더라구요... 금방 중지시켜서 소액으로 끝났지만요.
관리에 시간을 쏟을 수 없으니 그냥 계정을 없애버리는걸로 대응했네요.

[ifmkl]

클라우드로 시작하기 전 요즘 많이 나오는 n100, n150급으로 미니서버 환경 구축해서 테스트나 운영 경험을 좀 쌓아보라고 권장하고 싶네요.

[crawler]

아주 작은 프로젝트여도 일단 플랫폼에 올리면 취약점이 있을 때 금전적 손실로 이어지는 게 정말 무서운 거 같습니다

내 콘텐츠 앞단에 cloudflare를 뒀는데, 해커가 캐시되지 않은 객체를 찾아내서 1억 번 넘게 때림. 내가 막았더니 원본 버킷 주소까지 직접 찾고 공격함

이런 경우에도 비용을 환불해줄지 궁금하네요

[GN⁺]

Hacker News 의견

• 내가 부트캠프에서 프로그래밍을 배울 때, elastic beanstalk 인스턴스를 무료로 생성해봄. 신원 인증을 위해 신용카드가 필요했는데, 당시에 그게 문제가 될 거라고 생각하지 않았음. 그런데 이후 내 서버가 봇 스팸 공격을 받아서 Amazon에서 10만 달러를 청구함. 나는 결국 환불을 받았지만 그날 이후로 Amazon을 증오하게 되었고, 클라우드 컴퓨팅을 써야 한다면 다른 서비스를 쓰겠다고 다짐함. 복잡한 대시보드와 고객을 헷갈리게 해서 돈을 잃게 하려는 구조가 마음에 안 들었음. 신용카드를 인증 수단으로만 쓰고 봇을 막았으면 충분했을 텐데 아쉬움. 식료품 가게에서 신용카드로 간단하게 쿠키를 살 수 있는 것과 비교해 보면, 금융기술을 정말 쓸모 있게 사용할 수 있음에도 그러질 못했다고 생각함
  • 이것이 클라우드 호스팅이 무서운 이유 중 하나임. Amazon뿐만 아니라 Azure나 Google Cloud도 "보통은" 환불을 해줌. 하지만 만약 내 주간 방문자 5명짜리 데모 프로젝트가 갑자기 DDOS를 당해서 호스팅 회사가 이번에는 "보통"이 아닌 경우라며 송금을 요청한다면, 파산의 위기에 놓일 수 있음
  • 지금 2만5천 달러의 요금이 청구되어 있음. 예전에 SQS의 데이터플레인 감사를 켜두고 실제로는 실시간 감사 이벤트 피드를 연결해놨었음. 그 결과, 순수한 감사 이벤트마다 무한 루프처럼 기록 이벤트가 발생함. 10년 가까이 하루 평균 2달러 내던 계정이 어느 날 갑자기 하루에 3천 달러가 나오기 시작했고, AWS로부터는 아무런 경고나 개입도 없었음
  • Amazon이 10만 달러를 환불해줬는데 왜 싫어하는지 궁금함. 내 경우 AWS에서 완전히 내 실수였던 비싼 요금이 나와도 항상 환불을 해줬음. 만약 “예산을 넘기면 모두 종료”하는 정책이 있었다면, “DDOS를 당해서 AWS가 EC2를 전부 꺼버리고 내가 임시저장소에 쓴 데이터까지 날렸다”는 식의 또 다른 참극도 많이 나왔을 것임
  • “이것은 한 문장짜리 if 문으로 계정의 한도를 초과하면 인스턴스를 끄고 서비스를 스태틱 드라이브로 덤프하면 되는 아주 쉬운 일임. 그들은 그냥 원하지 않았음—고객을 상대로 수익을 극대화하려고 규모를 활용하려는 것임. 클라우드 컴퓨트로 모두를 곤란하게 만들었던 사람들이 이제 AI 비용도 시장 획득에 힘입어 경제적 이익을 취하려고 하고 있음. 요즘은 엣지 컴퓨트가 쉬워진 이유가 암호화폐로 인해 사람들이 하드 드라이브에 과투자를 했기 때문임. 결국 시장은 거품과 나쁜 행동에 동기를 부여하고, 신뢰를 쌓는 대신 힘으로 시장을 남용하는 사람들이 쉽게 판을 치게 되는 구조임. ‘넌 그냥 이걸 이해 못하는 거야! (아참 시장이 망하기 전에 돈 좀 더 줘)’라는 식의 교묘한 태도를 취하는 똑똑한 악당들이 업계의 최대 골칫거리임. 택시회사도 목적지에 안 간다고 천 달러씩 청구하지는 않음. 서버에 if 문을 못 넣겠다는 게 말이 되는지 의문임. Amazon이 택시회사보다도 못하냐는 셈인데, 어쩌면 맞을 수도 있다고 생각함. 이게 바로 ‘Waymo’가 시작된 계기임(농담일 수도 있음)
• 호스팅/개발/디버깅에서 서버리스의 고통을 이야기할 줄 알았는데, 가격 폭등 얘기였음. 아무래도 대역폭 비용이 심각하게 다가오진 않아서 대부분의 글을 대충 넘겼지만, 이 글은 좀 신기했음—빈 S3 버킷이 AWS 요금을 폭발시킬 수 있는 케이스에서, 남의 S3에 인증 없이 API 호출만 해도 상대방에게 과금을 떠넘길 수 있다는 이야기임. 나한테는 새로운 내용이었음
  • 이 현상에 대해 블로그 포스트가 화제가 된 이후 곧바로 조치가 취해졌다고 생각함: Amazon S3, 일부 에러 코드에 대해 과금 중지
  • 서버리스 환경의 진짜 문제점 중 하나는 플랫폼 자체가 블랙박스처럼 불투명하다는 점임(이게 서버리스의 가치 제안이기도 하지만). 우리는 대형 Lambda 백엔드를 물려받았는데, 비밀 확장기와 연결할 때 발생하는 간헐적인 소켓 끊김 문제 등 플랫폼의 내부 문제가 생길 때 추적하기 너무 고생함. 로컬 테스트 환경이 실제 배포 환경과 너무 달라서 더 괴로움. Google Cloud Functions로 집에서 장난감처럼 굴리는 건 잘 동작하지만, 진짜 프로젝트에서는 차라리 HTTP 서버/큐 컨슈머를 ECS 같은 컨테이너에 직접 올리고 싶음
  • ‘빈 프라이빗 S3 버킷을 내가 좋아하는 리전에 생성했다고 가정해보자. 우연히 유명한 오픈소스 도구 중 하나가 S3에 백업을 저장하는 기본 설정이 되어있고, 거기에 내가 만든 버킷과 동일한 이름을 프레이스홀더로 썼더라’는 내용인데, 이런 일이 진짜 얼마나 자주 일어나는지 궁금함—네이밍 충돌이 실제로 얼마나 빈번한지는 잘 모르겠음
  • 경쟁사를 제거하는 데 이런 방법을 쓸 수 있겠다는 생각이 들 정도임. 그렇기 때문에 AWS를 별로 좋아하지 않음. 깜짝 요금 폭탄에서 소규모 고객들을 지키려는 노력이 전혀 없음. Azure도 크게 나을 건 없지만 그나마 약간의 보호 조치가 있음
  • 나 또한 서버리스, Lambda, DynamoDB에 모든 걸 묶여서 사실상 $20짜리 VPS에 sqlite로 굴리면 되는 걸 거창하게 쓰도록 강제하는 클라우드 락인 사례를 기대했는데 그게 아니라서 아쉬움
• 서버리스에서 진정한 고통은 사건 한 번에 큰 요금이 청구되는 게 아니라, 매달 조금씩 불어나는 요금임. 리소스를 쉽게 만들고 방치할 수 있음. 한두 달에 몇천 달러씩 계속 오르다가 COO가 눈치채면 전 직원 비상사태로 요금을 $10,000 밑으로 줄임. 또 반복함. 몇 년 누적하면 한 번에 돈을 날리는 것보다 더 많은 낭비가 됨
  • 이게 사실상 AWS의 비즈니스 모델임. 혹시 “플래닛 피트니스” 모델이라고 불러본 적 있나? 가입이나 돈 쓰기는 엄청 쉬운데, 결제 해지는 엄청 번거롭게 만들어둠
  • 조직이 이런 값비싼 청구 기간에서 전혀 학습하지 않는 것 같음. 요금이 계속 늘어난 원인과 사전에 막을 수 있는 방법은 없었는지 궁금함
  • 이런 문제는 온프레미스에서도 종종 일어남. 사용하지 않는 앱이 계속 돌아가는 서버(보통은 VM)가 있게 됨. 물론 VM의 비용도 0은 아님
• 책임 소재가 불명확할 때가 많음. 고객들은 하드웨어 인프라를 클릭 한 번에 배포할 수 있는 마법 같은, 마찰 없는 도구를 원함. 경험이 없는 사용자가 잘못 설정해서 엄청난 요금이 나와도, 클라우드가이를 그대로 청구하면 평판이 나빠지고, 미리 사용자를 골라서 제한하면 스타트업에 도전하는 소규모 개발자에게도 닫힌 문이 됨. 이런 경우 갑작스런 $10,000 요금이 발생하면 누가 어디까지만 내야 하는지, 실수로 생긴 비용을 어디까지 책임져야 하는지 철학적으로 늘 궁금함. 내가 코드상에서 10배 더 비효율적으로 리소스를 써버려도, “잘못 설정하면 네 책임”이어야 하는지, 아니면 내가 사용한 클라우드가 AWS 등 대형사인지 작은 스타트업 API 서비스인지, 이 여부도 고객입장에선 신경 쓰지 말아야 하는지 고민임
  • 예산 초과/회로 차단기(지출 상한선) 같은 시스템을 두면 어떨까? 해결 불가능한 문제로 보이지 않음
  • 정답은 사실 간단함—예산 한도를 두는 것임
  • 그래서 실제 서버 대신 서버리스가 아닌 진짜 서버를 쓰는 이유이기도 함
• Hetzner에서 16TBx2 HDD, 1TBx2 SSD, 64GB RAM, 20TB 무료 트래픽을 월 $70에 쓸 수 있음. 반면 AWS micro 인스턴스에서 1TB 트래픽 사용했는데 150달러를 냈음(기억에 의하면). 굳이 이럴 필요가 없음
• "내 콘텐츠 앞단에 cloudflare를 뒀는데, 해커가 캐시되지 않은 객체를 찾아내서 1억 번 넘게 때림. 내가 막았더니 원본 버킷 주소까지 직접 찾고 공격함"이라는 사연에 대해, 이런 일은 누구에게나 일어날 수 있는 것 아닌가 궁금함. uncached 객체가 누출된 게 포트 22를 약한 비밀번호로 열어 둔 것만큼 심각한 실수인지도 모르겠고, S3 리소스(특히 이미지)는 누가 몇 번이든 접근할 수 있게 만드는 게 보통 아닌가?
  • 전혀 아님. S3 버킷은 반드시 프라이빗으로 하고 CDN에서만 접근할 수 있게 보안 규칙을 걸어야 함. 그래야 반드시 CDN을 통하도록 만들 수 있음
  • OWASP Top 10 취약점 놔둔다고 자랑하는 느낌 남. 접근 제어 설정이 생각만큼 어렵지 않은데, 기본적인 부분에서 이런 실수를 한다면 다른 데서도 대충 넘어갈 가능성이 높다고 봄. 이런 사람이 책임지는 시스템은 신뢰 못 하겠음
  • 기본 중의 기본이 S3 객체를 프라이빗으로 두고 최소한 cloudfront 프록시를 앞에 두는 것임. 이미지 같은 건 반드시 캐시를 거치도록 해야 함
• 서버리스라고 부르기엔 실제로는 여전히 클라우드 인프라에서 서버를 돌리는 구조임. 근본적으로 여전히 클라이언트-서버 모델에 따라 소프트웨어를 작성하고, 서버가 어딘가 돌고 있어야 유저가 쓸 수 있음. 내 생각에 진정한 ‘서버리스’란 사용자가 소프트웨어를 한 번 다운로드하면 이후 인터넷 없이도 쓸 수 있는 형태임. 혹은 서버에 데이터를 보내더라도, 개발자가 지정한 특정 장소에만 의존하지 않으면서 기능하는 게 서버리스라고 생각함
  • ‘서버리스’란 용어는 본질적으로 “로드에 따라 자동으로 리소스(서버)가 늘었다 줄었다 하는 관리 시스템”을 의미하는데, 이게 본질임. 로드가 늘면 서버가 늘고, 줄면 줄어듦. 이런 환경에 효율적으로 맞게 코드 전체 구조를 바꿀 수 있을 때에만 ‘서버리스’가 진가를 발휘함. 즉, 정말 그것이 필요할 때만 써야 할 아키텍처임
  • 일반적으로 그건 ‘로컬’ 소프트웨어라 부름. ‘서버리스’는 네이밍이 별로 좋지 않지만, 실제론 특정 백엔드의 배포 구조에 대한 얘기임. 백엔드 자체가 없는 앱은 아님
  • ‘서버리스’는 마치 “직원이 없는 회사” 같음. 실제로는 서비스를 제공하는 사람이 있지만, 모두 계약직으로만 일함
  • ‘서버’란 보통 특정 OS와 여러 계층의 소프트웨어(감시툴 포함)가 올라가 있고, 사용자가 비즈니스 로직에 접근할 수 있게 하는 단일 머신임. 직접 서버를 쓰려면 OS 선택, 지원 소프트웨어 설치/업데이트, 장애시 복구 등 모든 걸 신경 써야 함. 서버리스는 ‘함수로서의 서비스’ 모델이라, 비즈니스 로직(내 코드)만 신경 쓰면 됨. 서버에 OS를 깔 필요도 없고, http 서버 등 기본 소프트웨어도 신경 쓸 필요 없음. 업데이트나 유지보수도 안 해도 됨. 코드만 업로드하면 호출 시 실행됨. 서버 운영 스트레스에서 완전히 해방되는 개념임. 그래서 ‘서버리스’란 이름임—실제로 서버는 있지만, 운영을 직접 할 필요가 없으니까
• “서버리스”란 말은 실제로는 서버가 없는 게 아니라, 서버를 직접 관리하거나 어떤 서버에서 내 코드가 실행되는지 몰라도 된다는 뜻임. “코드 좀 줄 테니 한 시간마다 실행해줘. 어디서 돌리는지 나는 신경 안 씀” 같은 느낌임
  • 이 단어가 불편하게 느껴질 수도 있겠지만, 언어적으로 보면 오웰적(Orwellian) 문제는 아님. 1984에서의 ‘뉴스피크’는 표현의 다양성을 없애는 방향이었으나 ‘서버리스’는 오히려 새로운 카테고리를 지칭하기 위해 만드는 신단어임. 물론 서버의 존재 자체를 흐리게 만드는 용어일 수는 있지만, 정확히 오웰적이라고 부르면 안 맞는다는 의견임. “서블릿(servelet)”처럼 ‘가벼운 서버’라는 말도 가능할 듯함
  • “클라우드는 없다, 그냥 남의 컴퓨터일 뿐”이라는 식의 자조적 표현도 많이 사용됨
  • ‘서버리스’는 결국 과거의 ‘공유 호스팅’에서 ‘1만% 마진’과 ‘요청당 과금제’를 입힌 테크-브로 버전일 뿐이라는 느낌임
  • “노코드” 시스템도 사실상 코드로 돌아감. PaaS든 뭐든 결국 서버가 있다는 데 화내는 건 구실 찾기임
• AWS 서버리스 써봤는데, 로컬 테스트가 사실상 불가능했고 serverless run을 위해서는 AWS IAM role을 꼭 써야 해서 계정 전체에 광범위한 권한이 열려 있는 상태였음. 결국 실질적으로 매번 프로덕션에서 테스트하는 것과 다를 바 없는 큰 문제가 생김
  • 나도 몇 년간 서버리스 프로젝트 했는데, 로컬에서 거의 아무것도 못 돌려보는 점이 진짜 큰 비용이었음. 디버깅 시간도 처참하게 오래 걸렸음. 대체한다고 나온 툴들도 실제 프로젝트엔 거의 쓸모가 없음
  • ~/.aws/credentials 파일을 적절히 설정해두면 AWS 시큐리티 키로 로컬 테스트를 할 수 있음. makefile로 람다 배포를 자동화하고, 각 람다 별 커스텀 IAM role을 만들어 보안 요구사항을 JSON 파일로 관리함. AWS의 진짜 장점은 모든 게 동일한 API로 처리 가능하다는 점임. programmatically 모든 걸 만들고 관리할 수 있음
  • 1. 스택에 묶어서 개발자용 별도 계정에 배포(무료 스테이징 환경) 2) 공식 지원 도커 런타임으로 로컬 테스트 3) 평소처럼 단위 테스트 작성 4) localstack 같은 툴로 머신에서 스테이징 환경 그대로 에뮬레이션—이렇게 옵션이 워낙 많아서 그렇게 심하게 나쁜 경험을 할 수 있는 이유를 모르겠음
  • 사실과 거리가 먼 주장임
• ‘서버리스’는 어쨌거나 서버 기반 시스템을 오히려 포장하는, 오웰적 네이밍이라 생각함
• 이런 회사들이 1TB 대역폭에 $550씩이나 받는다는 게 믿기지 않음. 10Gb/s 보장 포트에 서버를 임대해도 TB당 $3 이상 나오면 사기라고 생각함. 서버리스가 어떻게 이 비용을 150배까지 정당화하는지 의문임. 이런 가격에 넘어가는 사람이 한둘일까? 그냥 $10짜리 VPS나 GitHub Pages에 올려도 독서위키/테크문서/블로그 정도는 아무 문제 없고, 적당히 셋업만 하면 동시접속 1만 명도 너끈함

[benjamin]

이제 처음 개발에 뛰어드는 사람들이 AI를 통해 뭔가를 만들 때 버셀, 수파베이스 같은 걸로 서비스 하는 사람들이 대부분 아닐까요?

하지만 서비스가 커지기 시작했을 때 이들에게 지불해야 하는 가격은 잘 계산해보지 않는 것 같습니다.
그건 그때가서 생각해보자는 마음으로.

버셀이나 수파베이스 창업자는 “맞아 맞아, 그때가서 생각해보면 돼!” 하고 함박웃음을 지으며 맞장구를 쳐줄 것 같네요.

물론 그때가서 생각해봐도 됩니다. 빨리 빠져나올 수 있는 실력이 있다면요.
하지만 컴퓨터공학에 대한 지식 없이는 쉽지 않을 겁니다.
겨우 벌기 시작한 돈을 그들에게 다 갖다 바치는 꼴이 될 수 있습니다.

사실 이게 지금 일어나고 있는 일들입니다.
그러니깐… 컴퓨터공학을 하나도 모르고 뛰어드는 뉴비들의 돈을 받아 먹는 커다란 비즈니스가 열리고 있습니다.

계속 컴퓨터 공학을 깊이 파고 들어야 하는 이유가 여기있습니다.
어떤 사람은 겨우 수익이 나기 시작한 서비스에 월 100만 원을 쓰는데, 어떤 사람은 돈을 전혀 내지 않고 서비스를 운영합니다.
운영 비용을 절감하는 것도 실력입니다. 엄청난 경쟁 우위 아닌가요?
AI로 코딩을 하면서 뭔가를 만들어 보고 즐거움을 느끼는 것은 좋지만, 더 깊숙한 곳으로 들어가려고 노력하지 않는다면 결국에는 차이를 만들어 낼 수 없습니다.

https://jeho.page/essay/2025/09/08/sucker-developer.html