Durable Object 알람 루프: 8일 만에 $34k, 사용자 0명, 플랫폼 경고 없음

Cloudflare Durable Objects와 alarm을 함께 사용하는 분들께 경고로 공유합니다. 근본 원인: 제 DO 에이전트의 onStart() 핸들러가 매번 깨어날 때마다 alarm이 이미 예약되어 있는지 확인하지 않고 this.ctx.storage.setAlarm()을 호출했습니다. 여기에 60개 이상의 preview Worker 배포가 각각 독립적인 DO 인스턴스를 생성하면서, 통제 불능의 자기 상태 점검 루프가 만들어졌습니다. 타임라인: - 4월 3일: 루프 시작 (이 날짜 이전에는 DO 사용량 0) - 4월 4-5일: 하루 약 9,300억 건의 row read로 정점 - 4월 11일: 발견 및 수정 - 4월 15일: $34,895 청구서 도래, 아직 청구 관련 응답 없음 수정 방법: // Before (dangerous) async onStart() { await this.ctx.storage.setAlarm(Date.now() + 60_000) } // After (safe) async onStart() { const existing = await this.ctx.storage.getAlarm() if (!existing) { await this.ctx.storage.setAlarm(Date.now() + 60_000) } } 그 외에 해볼 만한 것들: - preview 환경에서 DO 바인딩을 완전히 제거 - 예산 모니터 kill switch Worker 배포 - 스케줄링 전에 alarm 상태를 확인하는 circuit breaker 추가 경고를 못 받은 이유: Cloudflare의 Workers Usage Notifications는 CPU 시간만 모니터링합니다. Durable Object row read나 write는 모니터링하지 않습니다. 또한 대시보드나 Wrangler 설정에서 DO 작업에 대한 하드 지출 한도도 제공되지 않습니다. 이번 폭주 동안 아무 알림도 발생하지 않았을 것입니다. 청구서가 날아왔을 때 알게 됐습니다. DO alarm을 사용 중이라면 알아둘 만합니다. 플랫폼은 DO row read/write가 기하급수적으로 늘어날 때 알려주지 않습니다. 직접 kill switch를 만들어야 합니다. 제가 생각하기에 지금보다 더 주목받아야 할 점 하나: 지금이 Agents Week입니다. Cloudflare는 현재 개인 개발자들이 Durable Objects 위에서 AI 에이전트를 만들도록 유도하는 전용 마케팅을 진행 중입니다. 블로그 글, 발표, 전부 다요. 이는 솔로 개발자와 인디 창업자들을, 플랫폼 경고 하나 없이 다섯 자리 수 청구서를 조용히 만들어낼 수 있는 제품으로 끌어들이려는 의도적인 시도입니다. DO 작업에 대한 지출 한도는 없습니다. 사용량 알림 시스템은 DO read/write를 커버하지 않습니다. Cloudflare는 이 사실을 알고 있습니다. 이런 공백이 존재하는 상태에서 Agents Week를 진행하는 것은 중립적인 결정이 아닙니다. Case 02067725를 접수했습니다. 저는 런칭 전 1인 사업자이고, 이 스타트업에 개인 저축 전부를 넣었습니다. 이 청구서는 비즈니스 가치를 전혀 만들어내지 않은 사용량 때문에 저를 재정적으로 파탄시킬 것입니다. 기술적 경고로서, 그리고 결정을 내릴 수 있는 Cloudflare 관계자에게 이 문제를 전달하는 데 도움을 받고자 여기에 공유합니다. Cloudflare와의 청구 분쟁을 성공적으로 에스컬레이션하신 분이 있나요?