2P by GN⁺ | ★ favorite | 댓글 1개
  • 사용량 기반 과금이 편리함 뒤에 숨긴 비용 폭주 위험을 실제 사례별로 모아 보여주는 사이트임
  • Cloudflare, Vercel, AWS, Firebase, Netlify, BigQuery 등에서 발생한 예상 밖 청구를 서비스와 원인별로 비교할 수 있음
  • $36,000 Cloudflare, $46,485.99 Vercel, $100,000 Firebase 하루 청구처럼 작은 프로젝트나 개인 서비스도 순식간에 고액 청구로 이어질 수 있음
  • 반복 원인은 대역폭, DDoS/DoS, 스토리지, 잘못된 구현, 재귀, 큐 루프, 이벤트·이미지·문서화·AI 관련 사용량 증가임
  • 서버리스와 종량제 서비스를 쓸 때는 과금 한도, 캐시, 요청 패턴, 자동화 루프를 배포 전후로 확인해야 함

사이트 성격과 제보 방식

  • ServerlessHorrors는 서버리스 사용 중 발생한 과금·장애성 사례를 모아 읽을 수 있는 간단한 블로그임
  • 제작자는 Andras이며, Coolify, Jean 등 여러 오픈소스 프로젝트와 coolLabs 관련 작업을 하고 있음
  • 사례 제보는 두 경로로 받음

고액 청구로 이어진 대표 사례

  • $36,000: RetainDB 사이드 프로젝트가 사용자 81명 상태에서 Cloudflare 청구 $36k를 받음
    • 원인은 16B Durable Object writes, runaway queue loop, 배치되지 않은 Durable Object writes, 매 요청마다 실행된 KV list scan임
    • 태그: cloudflare, workers, durable-objects, kv, queues
  • $46,485.99: Jmail이 450M pageviews를 넘었고, 많은 캐시 완화 이후에도 Vercel 청구액이 $46k로 늘어남
    • 태그: vercel, bandwidth
  • $100,000.420: 어느 정도 인기 있는 WebGL 게임 업로드 사이트가 DoS를 맞아 하루 Firebase 청구액이 $100k가 됨
    • 태그: google, storage, firebase
  • $120,000.420: Cloudflare가 24시간 안에 $120k를 내도록 요구하려 한 뒤 웹사이트를 내린 사례임
    • 태그: cloudflare, bandwidth
  • $104,500.123: Netlify에서 $104,500.00 연체 청구 이메일을 받은 사례임
    • 태그: netlify, bandwidth, ddos
  • $96,280.69: Vercel bandwidth 관련 고액 청구 사례임
    • 태그: vercel, bandwidth, new
  • $72,000.999: Firebase + Cloud Run 테스트로 $72K를 태우고 거의 파산할 뻔한 사례임
    • 태그: google, firebase, cloudrun, wrong-implementation, recursion
  • $70,000.69: 월 $50를 내던 프로젝트에서 어느 날 $70,000 청구서가 나옴
    • 태그: google, storage, firebase, gcs

서비스별로 수록된 추가 사례

  • $23,000.420: EchoFox가 스팸을 받아 Vercel 청구액이 $23k로 치솟고 56k+ accounts and trials가 발생함
    • 태그: vercel, bandwidth, ddos
  • $22.639,69: BigQuery playground에서 공개 데이터셋을 사용했을 뿐인데 22k USD 청구를 받음
    • 태그: google, bigquery, sql
  • $11,000.69: DoS 공격 중 $11k 상당의 이메일이 발송되고 데이터베이스를 잃음
    • 태그: ddos, mailgun
  • $4,241.69: 서비스를 일시 중지했지만 AWS가 차단하고 비용을 지불해야 했다는 사례임
    • 태그: aws
  • $3,000.69: Vercel에서 테스트하거나 배포할 때 주의하라는 사례임
    • 태그: vercel, bandwidth, wrong-implementation
  • $1,300.69: 원하는 리전에 비어 있고 비공개인 AWS S3 bucket을 만든 뒤 비용이 발생함
    • 태그: aws, s3, security, ddos
  • $1273.69: Devin AI에게 코드베이스 변경을 요청한 뒤 PostHog 비용이 발생함
    • 태그: posthog, devin, ai, cognition-labs, new
  • ~$1189.420/month: $69/month 플랜에서 단일 월에 Webflow가 $1189.420을 청구함
    • 태그: webflow, bandwidth, image
  • $738.420: Vercel Pro를 월 $20에 구독하고 $120 spending limit도 추가했지만 청구가 발생함
    • 태그: vercel, bandwidth, vercels-mistake, spending-limit
  • $620.123: sitemap.txt가 수백 GB/hours를 사용한 Vercel 사례임
    • 태그: vercel, bandwidth
  • $530.19: 비용을 낸 적이 없다가 갑자기 $530가 청구된 PostHog 사례임
    • 태그: posthog, events, new
  • $400.69: Cloudflare Images가 예상 $110 대신 월 $400을 청구했고, 혼란스러운 선불 과금과 8개월 이상 지원 부재가 포함됨
    • 태그: cloudflare, images, billing
  • $383.69: 문서 사이트에서 거의 $400 청구를 받은 Mintlify 사례임
    • 태그: mintlify, ai, documentation
  • $250/month: 9,000 page visits에 대해 월 $250, 연 $3,000 비용이 필요해짐
    • 태그: framer, bandwidth, images and videos
  • $103.26: free tier 사용 상황에서 $103이 공포 사례가 된 AWS 사례임
    • 태그: aws, dark-pattern, free-tier

댓글과 토론

Hacker News 의견들
  • 정말 안타깝고, 오히려 뒤로 가는 느낌임. 3.44MB 파일이 문제가 되어서는 안 되고, 문제가 된다 해도 “다른 곳에 올려라”가 답이어서는 안 됨
    여기서 배울 점이 하나라면 무료란 없다는 것이고, 이런 큰 손실은 어떤 형태로든 한도를 둬서 막을 수 있어야 함. VPS는 매우 저렴하고 관리도 쉽고, 자동 한도도 있음: https://lowendbox.com/blog/1-vps-1-usd-vps-per-month/

    • 사람들이 왜 이제 웹사이트가 몇 개밖에 안 남고 롱테일이 사라졌는지 궁금해하는데, Facebook이나 Twitter에는 3.44MB 오디오를 올려도 절대 요금 청구를 걱정하지 않아도 되기 때문임
    • VPS가 “관리하기 쉽다”는 건 여러 전제를 깔고 있는 꽤 강한 선택지임
  • Netlify 사례가 서버리스 아키텍처 때문에 생겼다고 보지는 않음. 서버리스에는 기술적 문제가 많지만, 들어오는 트래픽 때문에 큰 청구서를 받는 문제는 서버리스와 독립적임
    자기 장비를 코로케이션에 넣고 트래픽 비용을 내도, 데이터센터가 DDoS를 막아주지 않고 TB 단위로 청구하면 같은 일이 벌어질 수 있음. 물론 코로케이션은 TB당 단가가 Netlify보다 훨씬 싸서 10만 달러 청구서가 나올 가능성은 낮지만, 그렇다면 핵심은 “서버리스 공포”가 아니라 터무니없이 비싼 트래픽 비용과 DDoS 완화 부재여야 함

    • 서비스가 무한히 확장되면 돈이 타는 속도도 무한히 확장됨. 코로케이션의 단일 서버는 포화되면 지갑에 줄 수 있는 피해도 제한됨
  • 이 블로그를 만든 Andres는 Heroku/Netlify의 셀프호스팅 대안인 coolify도 만들고 있음. 몇 달째 써보니 changedetector, jdownloader, vaultwarden 같은 것들을 셀프호스팅하기 쉽게 해준 비밀 소스 같은 존재였음
    커뮤니티도 꽤 잘 커지고 있어서 사람들이 새 템플릿을 기여하고, 서로 디버깅을 도와줌. Syncthing 템플릿도 추가해 봄. 다만 10GB 저장공간 인스턴스에서 디스크가 꽉 차자 이것저것 무너졌고, 이 부분은 알림이나 예방이 더 좋아지면 좋겠음. 그 외에는 꽤 안정적임
    https://github.com/coollabsio/coolify

  • 과민반응일 수도 있지만, 개인 사이트를 Netlify에 두었다가 옮기기로 함. HTML을 던져두는 곳 이상은 필요 없었고 Netlify가 “충분히 좋다”고 생각했는데, 이런 문제가 있는 줄은 몰랐음
    최근 피해 사이트가 하루 방문자 수나 인지도, 틈새 성격 등에서 내 사이트와 비슷해서 더 현실적으로 다가왔음. HTML은 로컬에서 빌드해 어딘가에 올리는 방식을 선호해서 이전 자체는 DNS 업데이트 정도면 충분함. 이상했던 건 Netlify, Vercel, Cloudflare 같은 인기 선택지 대부분이 지출 한도를 실제로 제공하지 않는다는 점임. 너무 기본적인 기능처럼 보임

    • Cloudflare Pages는 무료 대역폭이 무제한이라 트래픽이 무료이고, 그래서 한도가 필요 없음
    • Vercel에서 일하고 있는데, Vercel에는 DDoS 보호와 지출 한도가 있음. 둘 다 곧 추가 개선을 공개하려고 작업 중임
      https://vercel.com/blog/introducing-spend-management-realtime...
    • Cloudflare에는 DDoS 보호가 있고, 거의 편집증 수준으로 설정할 수 있음. DDoS가 시작되면 모두에게 CAPTCHA가 뜨게 할 수 있어서 지출을 꽤 효과적으로 제한함
  • Reddit 글 중 하나에 링크된 Netlify 댓글 스레드도 볼 만함: https://answers.netlify.com/t/limit-bandwidth-to-avoid-high-...
    Netlify 담당자가 무료 티어라도 DDoS를 당하면 말도 안 되는 대역폭 청구서를 막기 위해 아무것도 하지 않겠다고 명시적으로 말하고 있음

    • 이런 서비스들에서 제일 마음에 안 드는 점이 손절매에 해당하는 기능이 없다는 것임. 알림을 설정하면 알려주기는 하지만 그게 전부고, 많은 경우 피해가 난 뒤 한참 지나서야 알림이 옴
      일부 과금 지표는 보고나 알림이 몇 시간씩 늦기도 함. 기본값은 안전해야 하고, 한도 상향은 쉽게 할 수 있어야 함
    • 예전에는 서버를 내려버렸는데, 이제는 서버리스 웹사이트에 DDoS를 맞고 10만 달러 청구서를 받는 구조가 됨
      이런 사업 모델이 지속 가능한지 모르겠음. 서버를 소유하던 시절에는 플러그를 뽑을 수 있었지만, 이제는 누가 /api를 분당 백만 번 호출할지 알 방법이 없음
    • 무료 티어를 가짜 이름으로 써서 터무니없는 청구서를 버릴 수는 없나? 고객 검증을 어떻게 하는지 궁금함
    • Netlify가 자금난을 겪고 있어서 이런 일이 생기는 건 아닐까 싶음. 예전 Netlify는 아주 좋고 독특한 서비스였지만, 이제 GitHub, GitLab, Cloudflare Pages가 거의 같은 서비스를 더 싸게 제공함
    • 무료 티어에서 이런 일이 생기면 어떻게 해야 하나? 그냥 청구서를 안 내고 떠나면 되는 건가? 정말 추심하러 올까?
  • 클라우드 업체가 청구할 권리가 있는 항목을 과도하게 청구하는 건, 자동차 정비사가 routine 점검 중 작은 부품이 고장 났고, 같은 이유로 교체품도 계속 망가져서 무한 반복으로 갈아 끼우다가 2주 동안 아무 정보도 안 주고, 결국 내가 차고에 가서 멈추라고 하자 망가진 부품 999,999,999개 비용을 청구하는 것과 비슷하게 느껴짐
    대형 조직이 아닌 작은 사용자로서는 모든 구석구석의 조절 문서를 다 읽을 수 없음. 정해진 지출 한도에 도달하면 전체를 죽이고, 필요하면 데이터까지 잃어도 되는 고정 한도를 원함. 하지만 사용자가 예산을 조심하면 매출에 해가 되고, 청구액을 미리 계산하기 어려운 경우도 있어서 그렇게 안 해주는 것 같음

    • 차이는 있음. 예시의 정비사는 상황을 직접 만들었지만 Netlify는 그렇지 않았고, 원치 않는 트래픽과 하룻밤 사이 성공한 SaaS를 구분하기 어려울 수도 있음
      더 정확한 비유는 번호판을 아는 사람이 무엇을 요청하든 정비사에게 다 해달라고 말했고, 정비사가 그대로 수행한 경우에 가까움
  • 최근 OpenAI API 키를 만들었는데, 기본적으로 할당량을 강제하고 한도에 도달하면 키를 비활성화함. 더 많은 요청을 처리할 준비가 되면 사용자가 수동으로 할당량을 올리는 방식임
    이런 깜짝 청구서를 막기 위해 더 많은 회사가 기본값으로 이렇게 하지 않는다는 게 놀라움. 생각해보면 결국 사용자가 그냥 돈을 내는 경우가 많아서 그럴지도 모름

    • 차이는 OpenAI는 추론 비용이 실제로 들어가므로 이해관계가 걸려 있다는 점임. Netlify가 대역폭에 1000배를 과금할 때는 서비스 제공 비용이 거의 없으니, 사용자가 안 내도 실제로 크게 신경 쓰지 않을 수 있음
  • 가장 큰 클라우드 공포는 서버리스가 아닐 수도 있고, 클라우드 업체가 실패할 경우에 대비한다는 이유로 가용 영역 간 트래픽 비용을 내는 걸 우리가 받아들였다는 점이라고 봄
    다시 말해, 업체가 가질 수 있는 문제를 완화하기 위한 비용을 업체가 상당히 많이 청구하고 있음

  • 이 스레드에서는 다들 이게 서버리스 문제가 아니라 클라우드 문제라고 말하는데, 맞는 말이지만 핵심은 여전히 남아 있음. 대역폭은 거의 순마진이고, 대역폭에 이렇게 비싸게 과금하면서 고객 통제 밖의 공격에 대응할 도구를 제공하지 않는 건 꽤 지저분해 보임
    이 스레드에 따르면 Netlify는 DDoS 공격 중에도 사이트를 잠시 내릴 수 있는 선택지조차 없음: https://answers.netlify.com/t/limiting-bandwidth-traffic-to-...
    Netlify는 청구 제어, 요청 제한, 대역폭 한도, 진짜 DDoS라면 초과분 면제 등 여러 해결책을 가질 수 있지만, 황금알을 낳는 거위를 죽이는 꼴이라 관심이 없어 보임. bunny.net CDN이 제공하는 기능만 봐도 비교됨: https://support.bunny.net/hc/en-us/articles/360014190440-Und...
    클라우드 업체의 설명을 탐욕 말고는 설명하기 어려운데도 우리가 너무 쉽게 받아들이는 게 실망스러움

  • 지출 한도가 없는 게 왜 서버리스 문제인가? 그건 클라우드 문제
    다만 작은 클라우드 서버라면 공격을 받으면 내려갈 수 있고, AWS처럼 나가는 트래픽만 과금한다면 그건 사용자에게 유리함

    • 서버리스는 전통적인 모델보다 사용량 기반 과금을 더 자주 쓰고, 대규모 사용량까지 더 잘 확장되기 때문임
      내 월 5달러짜리 DigitalOcean VPS를 DDoS해도 컴퓨팅 비용은 늘어나지 않고, 전송 비용이 크게 쌓이기 전에 부하를 못 견디고 무너질 가능성이 큼. DigitalOcean 전송량도 사용량 기반이긴 하지만 그 전에 한계에 닿을 것임
    • 이건 클라우드 문제가 아님. 클라우드는 결국 남의 컴퓨터일 뿐임
      이건 청구 문제이거나 아키텍처 문제임. 과청구를 막기 위해 요청을 제한하게 해주거나, 특정 금액에 도달하면 끊어줘야 함
    • 이건 아키텍처 실패임. 최대치를 설정하는 건 중요함. 그런 기능을 지원하지 않는 플랫폼을 고르면 본인 책임도 있음
      전통적인 환경에서는 회로 차단기를 두기가 암묵적으로 더 쉽지만, 그래도 반드시 고려해야 함. 성공과 실패 양쪽 모두에 대해 부하 테스트를 해야 함
    • 지출 한도가 없는 게 서버리스 문제인 이유는, 클라우드를 쓰면 완화할 수 있지만 서버리스에서는 완화할 수 없기 때문임
      클라우드 인스턴스를 쓰는 나는 이 문제가 없고 앞으로도 없을 것임. 서버리스였다면 이 문제를 겪었을 것임