11. 청구서가 서비스를 죽인다

사고 시나리오

종량제 플랫폼에 올려놓고 잊고 있었는데, 코드의 무한 재귀 하나가, 혹은 어느 봇의 집요한 크롤링이 한 달 치 예산을 하루에 태운다. 청구서를 보고서야 안다. 개인 카드가 물려 있는 솔로 개발자에게 이것은 서비스 장애가 아니라 생활 장애다.

원칙

종량제 과금은 성능 문제가 아니라 안전 문제로 취급한다. 지출 알림과 상한(또는 자동 중지)은 기능이 아니라 보험이며, 출시 전에 걸어야 효력이 있다.

실무 처방

• 플랫폼의 지출 관리(spend management) 기능을 찾아서 켠다: 사용량 임계 알림 + 가능하면 상한 도달 시 자동 중지. “알림만”인지 “차단까지”인지 확인한다.
• 함수 실행 시간·메모리의 상한을 필요 이상으로 크게 두지 않는다. 상한은 폭주 코드의 피해 반경이다.
• 이미지 최적화, 대역폭, DB 읽기·쓰기처럼 과금 단위가 되는 것들의 이번 달 기준선을 한 번 본다. 기준선을 알아야 알림 임계값을 정할 수 있다.
• 대용량 미디어(영상·GIF)는 함수/앱 서버가 아니라 정적 스토리지·CDN으로 뺀다.
• 10번(봇 차단)과 세트다 — 과금 폭탄의 절반은 봇 트래픽이 만든다.

체크리스트

• 지출 알림이 켜져 있고 임계값이 기준선 기반이다
• 상한 도달 시 동작(알림뿐인지 차단인지)을 안다
• 함수 실행 시간·메모리 상한이 필요 수준으로 조여져 있다
• 대용량 미디어가 종량 과금 경로 밖(정적 스토리지)에 있다