무료 AI 크레딧, 가입 화면보다 “지급 직전”을 지키세요
AI 에이전트가 실제 브라우저로 가입을 반복한다면, 이메일 주소를 바꾸거나 숨겨진 필드를 건너뛰는 것만으로 기존 필터를 피할 수 있습니다. 저희는 이런 브라우저 자동화를 탐지하는 오픈소스 CAPTCHA, FCaptcha를 만들고 있습니다. WebDecoy 팀의 별도 셀프호스팅 프로젝트입니다.
무료 체험을 운영하는 메이커에게 제안하는 흐름은 이렇습니다.
- 서버에서 입력과 요청 빈도를 확인합니다.
- CAPTCHA 토큰을 서버에서 검증합니다. 프런트엔드의 “성공” 상태만 믿지 않습니다.
- 무료 체험 자격을 확인하고, 업무용 지급 ID로 크레딧을 한 번만 지급합니다.
- 정상 사용자의 재시도에는 새 CAPTCHA 토큰을 받되, 같은 지급 요청은 중복 처리하지 않습니다.
출시 전에 “위젯을 거치지 않은 직접 요청”, “사용한 토큰 재전송”, “검증 서버 응답 없음”, “통신 오류 뒤 정상 사용자의 재시도”를 각각 확인해 보세요. 브라우저에 위젯이 보이는 것과 서버의 지급 경로가 보호되는 것은 다릅니다.
FCaptcha는 이미지 퍼즐 없이 AI 브라우저 에이전트의 자동화 신호를 평가합니다. MIT 라이선스이며 직접 호스팅할 수 있습니다. 다만 토큰 검사만으로 사람이 만든 여러 계정이나 크레딧 지급 중복까지 해결하지는 않습니다. 사용량 한도와 업무 로직은 별도로 필요합니다.
서버 검증 흐름을 볼 수 있는 Hono 예제:
https://github.com/WebDecoy/FCaptcha/tree/main/examples/hono
이 예제는 검증을 보여 주는 문의 폼 데모이고, 실제 크레딧 지급은 구현하지 않습니다.
소스와 설치 안내:
https://github.com/WebDecoy/FCaptcha
어떤 작업 직전에 봇 검사를 붙이고 싶으신가요? 무료 생성, 가입, 문의 발송처럼 실제로 비용이 발생하는 지점의 이야기를 듣고 싶습니다. 써 보시고 Issue나 피드백을 남겨 주세요. 유용하다면 GitHub Star도 도움이 됩니다.
한국어 작성에는 AI를 사용했습니다. 공개 저장소를 참고했으며 실제 사용자 탐지 정확도를 측정한 사례 발표는 아닙니다.
AI 크롤러와 자동화 봇의 활동을 확인하고 대응하는 개발자 도구
댓글
로그인 후 댓글을 남길 수 있습니다.
지급 직전에 막는다는 관점 맞는 것 같아요. 가입 단계에서 너무 빡세게 걸면 진짜 사용자도 같이 떨어지니까요. 셀프호스팅이면 오탐률은 어느 정도로 보고 계신가요? 무료 체험 운영하는 입장에선 그 숫자가 제일 궁금하네요.
중요한 질문입니다. 현재 이 환경의 실제 사용자에게 적용할 수 있는 운영 오탐률을 숫자로 제시할 근거는 없습니다. 공개 회귀 테스트 결과를 실제 서비스 전체의 오탐률로 바꿔 말하지 않겠습니다. 저장소의 HARDENING 문서도 현재 코퍼스가 인구집단 정확도 측정이 아니라고 명시합니다. 무료 체험에서는 먼저 테스트 환경이나 차단하지 않는 비교 단계에서 정상 가입 세션을 별도로 확인하고, 오탐률을 “정상임을 확인한 세션 중 잘못 거절된 세션의 비율”로 계산하는 것이 좋습니다. 모바일·키보드·보조기술·공유망을 나눠 보고, 검증 서버 장애로 인한 실패는 탐지 오탐과 분리해야 합니다. 재시도 성공률과 실제 첫 사용까지 함께 보면서, 의심 세션은 곧바로 탈락시키기보다 지급 보류·추가 확인 경로를 검토할 수 있습니다. 이 흐름은 제품 쪽에서 별도로 구현해야 합니다. 테스트 한계와 배포 주의점: https://github.com/WebDecoy/FCaptcha/blob/main/HARDENING.md 한국어 답변에는 AI 번역 도움을 받았습니다.
숫자 없이 솔직하게 답해 주셔서 오히려 믿음이 가요. 차단하지 않는 비교 단계부터 돌려 보라는 순서가 현실적이네요. 검증 서버 장애를 오탐과 따로 세는 건 저도 놓치기 쉬운 부분이라 메모해 둘게요.