Ask GN: 1인 개발자, 평시에 만들어 둔 '관리 도구'가 비상 상황에서 큰 도움이 된 경험 있으신가요?

2 days ago 4

안녕하세요. 1인 개발자로 세이프클릭(SafeClick)이라는 어르신용 피싱 차단 앱을 운영하고 있습니다.

며칠 전 관리자 페이지에서 무의미한 자동화 로그인이 한 시간 만에 약 1,600건 들어오는 상황을 마주쳤습니다. DDoS급 트래픽은 아니고, 익명 가입 API를 표적으로 한 봇 작동이었습니다.

큰 소동 없이 정리할 수 있었던 이유를 돌아보니, 평시에 미리 만들어 둔 두 가지 도구 덕분이었습니다. 다른 1인 개발자분들도 비슷한 경험이 있으실 것 같아, 제 사례를 공유하면서 여러분의 이야기도 듣고 싶어 글을 올립니다.

세이프클릭 admin 페이지를 처음 설계할 때부터, 사용자 일괄 삭제(bulkDeleteUsersAction) 기능을 미리 만들어 두었습니다. 당시는 "혹시 모를 청소용"으로 만들어 둔 도구였는데, 이번에 그대로 활용했습니다.

선별 조건은 단순합니다:

조건을 만족하는 후보를 페이지에서 다중 선택해 한 번에 삭제하는 흐름이 이미 준비되어 있어, 새 코드를 작성하지 않고 정리할 수 있었습니다.

1인 개발자에게 비상 상황에서 새 도구를 짜는 일은 위험합니다. 평온할 때 청소·복구·관리 도구를 미리 만들어 두면, 정작 필요할 때 정리가 짧은 작업으로 끝납니다. 이게 이번 사건에서 얻은 가장 큰 깨달음이었습니다.

Cloudflare Workers의 Analytics 대시보드와 실시간 로그(wrangler tail)를 항상 가까이 둔 점도 결정적이었습니다.

WAF가 없는 무료 *.workers.dev 도메인 환경에서도, Cloudflare의 기본 모니터링만으로 봇 패턴을 빠르게 추적할 수 있었습니다. 별도의 외부 모니터링 서비스 없이 1인 운영 규모에서는 이 수준의 가시성이면 충분했습니다.

API 설계 단계에서 cost-sensitive endpoint와 abuse-prone endpoint 목록을 미리 정리해 두었던 것도 도움이 되었습니다. 봇이 그중 하나로 정확히 들어왔습니다.

위 두 도구로 상황을 빠르게 파악·정리한 다음, 같은 패턴이 다시 들어와도 자연 차단되도록 세 갈래 layer를 새로 만들었습니다:

Track D: self-register IP 기반 rate limit (KV) — 분당 5회 / 시간당 20회
Track C: Play Integrity verdict + 봇 UA hard 시그널 — verdict ≠ ok 시 403
Track A: cost endpoint per-IP layer — /api/v1/check 200/hour, AI 분석 50/hour 등

이 layer들은 후속으로 만들었지만, 발견·파악·정리는 위의 두 평시 도구가 다 했습니다. 봇 차단 layer 없이도 사건은 이미 끝난 상태였고, 다음 번을 위한 보강일 뿐이었습니다.

사전 설계가 비상 대응의 90%를 결정합니다. 평시 도구가 있으면 정작 위기에서는 침착하게 적용만 하면 됩니다.
Cloudflare Workers 기본 가시성만으로 1인 운영 규모는 충분합니다. 비싼 모니터링 서비스 없어도 봇 패턴 추적이 가능합니다.
abuse-prone endpoint를 처음부터 예상하고 설계합시다. "이 endpoint가 두드려질 것이다"라는 예상이 맞으면 대응이 훨씬 빨라집니다.
정상 사용자 영향 복구가 봇 차단보다 우선순위가 높습니다. 봇은 잠시 견뎌두고 정상 사용자 동선을 먼저 풀어야 합니다.
soft signal 차단은 1인 운영자에게 위험합니다. false positive를 처리할 인력이 없으니, hard signal에서만 차단합니다.