1P by krisakma | ★ favorite | 댓글 20개

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

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

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

평시에 만들어 둔 도구 1 — 관리자 페이지의 사용자 일괄 삭제 기능

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

선별 조건은 단순합니다:

  • 가입 후 앱 실행(heartbeat) 0건
  • 봇 시그널이 있는 User-Agent
  • 의심 locale 분포

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

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

평시에 만들어 둔 도구 2 — Cloudflare Workers 가시성

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

  • 예상 경로(self-register endpoint)가 표적이 되고 있는지 즉시 확인
  • 분당 요청 빈도 측정
  • 시간 윈도우를 늘려 공격 패턴(분포·간격·source IP) 파악

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

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

부가 — 사후 layer 추가

위 두 도구로 상황을 빠르게 파악·정리한 다음, 같은 패턴이 다시 들어와도 자연 차단되도록 세 갈래 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 없이도 사건은 이미 끝난 상태였고, 다음 번을 위한 보강일 뿐이었습니다.

제가 배운 점

  1. 사전 설계가 비상 대응의 90%를 결정합니다. 평시 도구가 있으면 정작 위기에서는 침착하게 적용만 하면 됩니다.

  2. Cloudflare Workers 기본 가시성만으로 1인 운영 규모는 충분합니다. 비싼 모니터링 서비스 없어도 봇 패턴 추적이 가능합니다.

  3. abuse-prone endpoint를 처음부터 예상하고 설계합시다. "이 endpoint가 두드려질 것이다"라는 예상이 맞으면 대응이 훨씬 빨라집니다.

  4. 정상 사용자 영향 복구가 봇 차단보다 우선순위가 높습니다. 봇은 잠시 견뎌두고 정상 사용자 동선을 먼저 풀어야 합니다.

  5. soft signal 차단은 1인 운영자에게 위험합니다. false positive를 처리할 인력이 없으니, hard signal에서만 차단합니다.

여러분의 경험은?

위는 어디까지나 제 한 사례일 뿐입니다.

1인 개발자 / 사이드 프로젝트 운영자 분들, 평시에 만들어 두신 관리·청소·모니터링 도구 중 비상 상황에서 가장 큰 도움이 된 것은 무엇인가요?

  • 운영 중 abuse·봇·트래픽 폭주를 겪으셨을 때 어떤 도구가 살려줬는지
  • 처음 만들 때는 "굳이 만들 필요 있나" 싶었는데 결정적인 순간에 빛난 기능
  • 다음 프로젝트 운영 때 꼭 미리 만들어 둘 만한 도구 추천

작은 경험이라도 댓글에서 공유 부탁드립니다. 함께 정리해보고 싶습니다.


세이프클릭 — https://getsafeclick.com
이전 소개글 — https://news.hada.io/topic?id=29563

댓글과 토론

ai slop

봇/악의적 트래픽에 공격 받은 게 비상이 아니라,

  • B2C 공개 앱이면서 익명 가입 API를 속도 제한도, 봇 차단 설계도 없이 표면에 노출한 게
  • 그리고 이런 글 AI로 작성해서 올리는 게
    진짜 비상이네요...

글/댓글 이런 식으로 작성돼 있는 서비스는 구경도 사용도 하고 싶지 않습니다
개인정보 취급, 데이터 관리, 운영 모두 gemini한테 아부 받으면서 개판으로 해 놨을 거 같아요

'보이스피싱 방어', '사회적 신뢰'에 다루는 프로덕트를 운영하시면서, 아이러니하게 날림 글 LLM으로 작성해서 포스팅하는 게 얼마나 신뢰성 떨어트리는 지는 생각 안 해보셨을까요

글 서두에 앱을 만들어보는 사람이라는걸 빼먹었습니다.

저는 아이디어로 앱 만들어본 수준의 초보자이고, 보안 위험성을 잘 몰라서 겪은 일이었습니다
글의 내용 자체는 제가 직접 겪은 일을 제 표현으로 쓴 부분이 대부분입니다.

다만 AI에게 정리와 표현을 맡기다 보니 결과물이 AI 어투처럼 된 것이 사실입니다. 깜짝 놀라서 지금은 구글플레이에 Play Integrity API 7개 항목을 모두 채웠습니다. 다행히 그 시간 이후로는 동일 현상이 발생하지 않았습니다.

클로드코드로 만들었고 보안 리뷰를 4차례 풀로 했는데
정작 등록 과정에서 이 부분은 빼먹고 다시 화면으로 붙여가면서 체크 요청을 해도 빼먹더군요.

시간 내서 길게 충고 해주셔서 감사합니다!

허점은 없는지 시간내서 꼼꼼히 더 찾아 보겠습니다.

감사합니다!

LLM 특유의 경험 부풀리기 + 인사이트 과장하기가 너무 눈에 밟혔습니다

  • 본질인 경험과 궁금증이 아닌, '미리 만들어둔 도구로 잘 해냈어요!'라는 식의 인사이트 과장 글/제목이 되어, 읽다보면 다른 댓글처럼 '오데이터 클리닝은 SQL 한 줄이면 되는데, 무슨 소리 하고 있는 거야' 하게 되더라고여

경험을 공유하시는 건 좋으나, '실수를 노린 악의적인 공격이 있었고, 오데이터 클리닝했다. 클레이드플레어 기본 로그가 꽤 많은 정보를 줘서 로그 분석해서 패턴 식별하여 막아보고 있는데, 다른 분들은 이런 악의적 봇 공격에 대한 경험 있으시냐, 어떻게 대응하는지 궁금하다' 정도였으면 좋았을 거 같아요

그렇다 하더라도 필요 이상으로 어그레시브하게 댓글 단 것 같습니다
최근 LLM 어투에 피로감이 높아져서 괜히 시니컬해졌네요
단정 짓고 공격적으로 댓글 써서 죄송합니다

괜찮습니다!
이런거 좋아요!
제가 듣고 싶은 말들이었습니다!
어디가서 물어볼 곳도 솔직히 없어서...

강한소상공인에 아이디어로 들어가는 앱입니다.
지원을 받으면 제대로 만들어보고 싶은 마음입니다.

실제로 어머니가 태극기를 좀 좋아하셔서
단톡방에 무지막지하게 올라오는 유튜브 링크와 이상한 링크들 때문에
누나와 제가 엄청난 스트레스를 받고 있어서...

그래서 만들었습니다.
혹시나 AI가 먼저 읽고 해석해서
알림이라도 뜨고 바이러스를 이중 삼중으로 검사해주면 도움이 되지 않을까

큰 도움 되었습니다~! 감사합니다!! :)

그대가 긱뉴스에 ai slop공격을 하고있소

sql한줄에서 끝날거를 기능이니 사전설계니....

시간에 200번 들어오는걸 보고 어디를 만지면 더 들어오겠구나 확인 후 일부러 허용치를 높여서 분당 시간당 횟수를 세어봤습니다.
관리자 페이지에서 일괄 삭제를 따로 만들어놔서 눈으로 보면서 지웠고
AI를 통해서 제어할 수 있는 방법을 찾아서 처리했습니다.
막상 끝나고 보니
구글플레이에 기본 보안 항목이 있었는데
한가지가 통으로 빠져있었습니다.
조언 감사합니다

이젠 질문도 그리고 대댓글 마져도 AI로.. 대체 이렇게해서 얻는게 무엇인가요.
아무래도 저는 많이 늙어버린것 같습니다.

제 글에 검토를 맡겼더니 클로드가 살을 붙이고
더 어색한 글이 되었습니다.
제목도 이상했어요 솔직히
죄송합니다!
얻는건 없습니다.
초보라는 전제를 안쓰는 바람에
오해하게 만든것 같아 죄송합니다

저도 처음에 AI 접했을땐 글을 모두 다 AI에게 맡겼었어요 글을 저보다 잘 쓰는거 같다고 느꼈거든요, 근데 Redditd에서도 그렇고 기가 막히게 AI인걸 알아 차리더군요, 사람 냄새나는게 중요해지는 시대가 되어가는거 같아서 무섭네요

레딧은 글 쓸 수 있는 권한도 카르마 때문에 안되서 여기저기 뒤지다가
긱뉴스를 찾았습니다.
비전문가에 앱을 만들어보는 사람이고 전문용어는 AI 도움을 받았다고 써놨어야 하는데
바보 같이 제 글에 첨언한걸 그대로 붙여 버려서 ㅠㅜ
중간 중간 실패 하는걸 보여주고 조언 받을 수 있을 공간이 필요했는데
시작부터 실패했습니다.
역시 사람 냄새가 제일입니다!

개인적으로 자랑(은 맞지만)은 아니지만 레딧에 글을 올려서 그 서브레딧 게시판에 핫으로 올라간적이 있었습니다

그동안 ai로 자 내 썰을 이렇게이렇게 번역해줘 라고 해서는 절대 읽어보지도 않구요.

그냥 제 생각 영어로 블라블라 써놓고 문법적으로 틀린것만 고치고 무조건 내 냄새는 그대로 나게 해줘라고 해야만 읽더라구요

아무튼 즐거운 하루 되십시오!

이렇게 봇으로 글 올리고 봇으로 댓글 달면 모를 거라고 생각하나요 정말로?

글은 거의 제글에
제목과 본문 내용에 클로드가 살을 붙였는데
지금 봐도 어색합니다.
댓글은
제가 급해서 보자마자(다른일 중이라서...)
클로드에 댓글 요청했더니
이렇게 써주더군요.
제가 물어본건
기본적인 구조와 CAPCHA를 사용 하지 못한 이유 등등을 물었는데
이런 대댓글이 나왔습니다.
조언 감사합니다

ai 작성까지는 알았는데 대댓글마저도 ai로 작성할줄은 몰랐네요

CAPTCHA 내용을 묻고 이유를 확인하고
self-register API 도 제가 확인한 내용인데
구글플레이 속 통째로 빼먹은 보안항목도 제가 찾은건데
클로드한테 내용 줬더니
써준 글을 그대로 등록하는 바람에...
댓글 감사했는데
대댓글 클로드가 준걸로 바로 넣었다가 크게 혼나고 있습니다.
전문가도 아닌데
글 서두에 비전문가, 앱을 만들어보는 사람
제일 중요한 타이틀을 빼먹어서 더 일이 꼬인 것 같습니다.
시간내어 조언해주셔서 감사합니다!

대부분의 가입, 로그인 자동화 공격은 클라우드플레어 캡챠등 사설 bot 감지 도구를 통해 막은것같네요

좋은 포인트 감사합니다. 사실 댓글 보고 다시 돌아보니, 저희가 놓친 부분이 더 있었습니다. 이번 사건에서 배운 점을 종합해서 공유드립니다.

CAPTCHA가 직접 적용되지 못한 이유

말씀하신 Cloudflare Turnstile 같은 사설 도구는 웹 form 기반 가입/로그인에서 산업 표준이고 가장 효과적인 길이 맞습니다. 다만 저희 케이스는 두 가지 제약이 있었습니다.

(1) 공격 표적이 모바일 앱의 self-register API였습니다. 브라우저 세션·렌더링 컨텍스트가 없는 endpoint라 Turnstile widget을 띄울 경로 자체가 존재하지 않았습니다. WebView로 끼워 넣는 방식은 가능하지만 정상 사용자 onboarding UX 마찰이 커서 1인 운영 규모에서는 trade-off가 맞지 않았습니다.

(2) 운영 도메인이 *.workers.dev 무료 도메인이라 Cloudflare WAF / Turnstile 자동 통합 자체를 사용할 수 없는 환경이었습니다. 커스텀 도메인 + Cloudflare 프록시가 전제라서요.

저희가 사실 놓친 영역 (인정합니다)

댓글 받고 다시 점검해보니, Play Console 측 무결성 검사 두 영역이 비활성 상태였던 사실을 발견했습니다.

(1) 스토어 등록정보 표시 (Store Listing Integrity) — "무결성 검사 없음" 상태였습니다. 이걸 "기기 무결성 검사(권장)"으로 활성하면 Play Store 노출·다운로드 단계 자체에서 에뮬레이터·VM·루팅 기기·Google 서비스 미지원 환경을 차단합니다. 즉 봇이 앱을 받을 수조차 없게 되는 layer입니다.

(2) Play Integrity API 분류 규칙 — 서비스 7개 중 0개 활성 상태였습니다. 앱 코드 측 SDK 통합은 정상 작동 중이었지만, Play Console 대시보드의 verdict 분류 규칙이 비활성이었던 catch입니다.

이번 사건의 봇 1,600건 attack 대부분이 사실 이 layer 활성화만으로 Play Store 단계에서 사전 차단 가능했을 것으로 추정됩니다. 모바일 앱 API attack에서 CAPTCHA의 대체 도구는 Play Integrity API이지만, 앱 코드 측 SDK 통합 + Play Console 대시보드 설정 둘 다 필요한데 후자를 놓쳤습니다.

정리하면

  • 모바일 앱 API → Play Console "기기 무결성 검사" + Play Integrity API verdict 검증 + 앱 코드 측 SDK 통합 = 3-layer 필요
  • 웹 form → Turnstile / Bot Management = 1 layer로 충분
  • 웹과 모바일이 동시에 있는 서비스는 두 갈래 운영이 정답

같은 모바일 1인 운영자분들 중 Play Console 대시보드 영역을 놓치기 쉬운 부분인 것 같아 catch 공유드립니다.

혹시 Play Integrity API 운영하시면서 false positive로 정상 사용자가 차단된 사례 보신 적 있으셨나요? 어느 정도 비율인지 궁금합니다.

AI slop 댓글 피로하네요

딱 맞는 말이십니다.
이런글 자주 보면 더 피로하실 듯
내용을 거의 다 제가 준건데
전문용어에 살 좀 붙이더니
제가 봐도 이상한 글이 되어버렸습니다.
죄송합니다