좋은 포인트 감사합니다. 사실 댓글 보고 다시 돌아보니, 저희가 놓친 부분이 더 있었습니다. 이번 사건에서 배운 점을 종합해서 공유드립니다.
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로 정상 사용자가 차단된 사례 보신 적 있으셨나요? 어느 정도 비율인지 궁금합니다.
yt-dlp가 간단해보이지만 사실 영상 다운로드를 막으려는 구글의 차단이 꾸준히 있고, 그런 차단이 있을 때마다 어떻게 해서든 뚫고 있죠.
AI에 의존하기 힘든 해커의 성향이 더 짙을 수 밖에 없는 집단이라고 생각해서 이런 결정을 한 것도 이상하지 않습니다.
솔직히 큰 프로젝트가 이렇게 보이콧 해주니까 고맙다는 생각이 들 정도네요.
사실 저도 bun 개발자들이 처음엔 그냥 실험으로 포팅 해보는 거라고 말한 거랑 다르게 너무 빠르게 메인스트림에 병합이 되길래 그 속도로 모든 코드 리뷰를 했을 수가 없는데 저래도 되는 건지 의심이 들었습니다.
사용자 입장에선 구글을 탈피해야 하고, 웹사이트 운영자 입장에선 AI위주로 바뀐 구글에 대응해야 하는 상황이네요.
지난 위클리 주제가 검색창이 직접 답하는 시대, 우리는 무엇을 준비해야 할까 였는데, 연결되네요.
{l:10,50,30,80,20}
좋은 포인트 감사합니다. 사실 댓글 보고 다시 돌아보니, 저희가 놓친 부분이 더 있었습니다. 이번 사건에서 배운 점을 종합해서 공유드립니다.
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 대시보드 설정 둘 다 필요한데 후자를 놓쳤습니다.
정리하면
같은 모바일 1인 운영자분들 중 Play Console 대시보드 영역을 놓치기 쉬운 부분인 것 같아 catch 공유드립니다.
혹시 Play Integrity API 운영하시면서 false positive로 정상 사용자가 차단된 사례 보신 적 있으셨나요? 어느 정도 비율인지 궁금합니다.
사례 위주로 작성해주셔서 참고할게 많네요!
대부분의 가입, 로그인 자동화 공격은 클라우드플레어 캡챠등 사설 bot 감지 도구를 통해 막은것같네요
참고할만한 내용이 정말 많네요.
Kimi 2.6을 사용합니다
ChatGPT를 사용합니다.
아직은 우리가 연봉을 받아야하는 이유를 열심히 적어줬군요
잘하는 일이 하고 싶은 일이 아니라서 불행한 것 같아요...ㅠ
업무에 쓰기에는 모델 성능이나 보안 등이 이슈가 있을 것 같지만, 이정도 가성비라면 개인 프로젝트 사용하는데는 좋을 것 같네요.
기여에 감사드립니다.
녹음 중에 좌측 옵션을 꾹 눌러보시면, 컨텍스트는 전달되지만 붙여넣기는 해제할 수 있어요!
혹시 이 기능 말씀하신게 맞을까요??
저는 개인적으로 학습에서 적극 활용 중에 있습니다! 특히 쓰면 쓸수록 제 약점이 누적되는 만큼 사용이 길어질수록 맞춤화되어가는 것에 체감이 큰 것 같습니다.
의견 감사합니다! codex는 현재 별도 레포로 지원하고 있습니다! (https://github.com/TaewoooPark/PAIDEIA-codex) Gemini CLI도 제작 검토해보겠습니다.
2번의 경우 플로우는 좋아보이는데 실제 출력물이 어느정도로 나올지가 기대되네요.
codex나 gemini도 지원해주시면 좋을거 같습니다~ ㅎㅎ
게시자입니다! README가 조금 긴 만큼 빠르게 이해할 수 있는 30초 데모 GIF와 sample-course 결과물을 추가하려고 합니다.
그 전에 많은 분들께 조언을 구하고 싶습니다!
의견 주시면 바로 검토해보겠습니다! 감사합니다
저도 대충은 알고 있긴 했는데, 다시 찾아보니.
그나저나 아래 문단이 뭔가 했는데요.
"정직함을 지킬 것 (중략)"라고 했지만, 내용은 “고객이 속고 있다고 느끼면 떠난다”에 가깝네요. 좀 더 돌려 말하면 속이고 있다고 안 느끼건 과정 정도는 괜찮다??
yt-dlp가 간단해보이지만 사실 영상 다운로드를 막으려는 구글의 차단이 꾸준히 있고, 그런 차단이 있을 때마다 어떻게 해서든 뚫고 있죠.
AI에 의존하기 힘든 해커의 성향이 더 짙을 수 밖에 없는 집단이라고 생각해서 이런 결정을 한 것도 이상하지 않습니다.
솔직히 큰 프로젝트가 이렇게 보이콧 해주니까 고맙다는 생각이 들 정도네요.
사실 저도 bun 개발자들이 처음엔 그냥 실험으로 포팅 해보는 거라고 말한 거랑 다르게 너무 빠르게 메인스트림에 병합이 되길래 그 속도로 모든 코드 리뷰를 했을 수가 없는데 저래도 되는 건지 의심이 들었습니다.