신호등 칸 고르다가 문득 든 의문
웹사이트에 가입하다가 ‘소화전이 있는 이미지를 모두 선택하세요’ 같은 문제를 만나본 적 있으시죠? 이게 바로 CAPTCHA인데요. 영국의 개발자이자 블로거 테렌스 이든(Terence Eden)이 2017년에 쓴 글이 이 익숙한 경험을 전혀 다른 각도에서 보게 만들어요. 제목부터 도발적이거든요. CAPTCHA는 당신이 사람이라는 걸 증명하는 게 아니라, 미국인이라는 걸 증명한다.
몇 년 지난 글인데 지금 다시 읽어도 전혀 낡지 않았어요. 오히려 AI가 CAPTCHA를 사람보다 잘 푸는 시대가 되면서 ‘이 시험은 도대체 누구를 기준으로 만들어졌나’라는 질문이 더 중요해졌거든요.
CAPTCHA가 뭐고, 뭐가 문제냐면
CAPTCHA는 Completely Automated Public Turing test to tell Computers and Humans Apart의 약자예요. 쉽게 말하면 ‘컴퓨터와 사람을 구분하는 자동화된 시험’이에요. 초창기엔 찌그러진 글자를 읽게 했고, 요즘은 구글 reCAPTCHA처럼 사진 격자에서 특정 사물을 고르게 하는 방식이 흔하죠.
이든이 짚은 건 바로 그 ‘특정 사물’이에요. 문제에 자주 나오는 소화전(fire hydrant), 횡단보도(crosswalk), 스쿨버스, 택시, 상점 앞(storefront) 같은 것들이 전부 미국 거리 풍경 기준이라는 거예요. 예를 들어 영국에서는 소화전이 보통 땅 아래 묻혀 있고 작은 표지판으로 위치만 알려줘요. 빨갛고 뭉툭한 기둥 모양 소화전은 미국 영화에서나 보던 물건이죠. 영국 사람에게 ‘소화전을 고르세요’는 거의 본 적도 없는 물건을 찾으라는 문제가 되는 거예요.
단어도 문제예요. 미국 영어의 crosswalk를 영국에선 zebra crossing이라고 부르고, 미국의 노란 택시와 스쿨버스는 다른 나라 사람들에게 그렇게 뚜렷한 기준이 아니에요. 한국도 마찬가지예요. 우리 소화전은 모양도 색도 다르고, 노란 통학버스가 있긴 해도 미국식 대형 스쿨버스와는 생김새가 꽤 다르잖아요. 결국 이 시험은 ‘사람이면 누구나 아는 것’이 아니라 ‘미국 거리에 익숙한 사람이 아는 것’을 묻고 있는 셈이에요.
왜 하필 미국 풍경일까
여기엔 꽤 현실적인 배경이 있다는 해석이 많아요. reCAPTCHA는 오래전부터 ‘사람이 푼 답’을 데이터로 활용해 왔거든요. 글자형 시절엔 스캔된 책의 글자를 판독하는 데 쓰였고, 이미지형으로 넘어오면서는 거리 사진 속 사물을 라벨링한 데이터가 쌓이게 됐어요. 도로, 신호등, 횡단보도처럼 지도나 자율주행에 필요한 사물이 유독 많이 나오는 것도 그런 맥락에서 이해할 수 있죠. 데이터를 모으는 쪽의 관심사가 미국 도로에 있으니, 시험지도 미국 풍경으로 채워지는 거예요.
이게 왜 문제냐면, CAPTCHA는 문지기 역할을 하거든요. 틀리면 계속 새 문제가 나오고, 결국 사용자가 포기하게 돼요. 미국 밖 사용자, 영어가 모국어가 아닌 사용자, 시력이 좋지 않은 사용자는 똑같은 사람인데도 더 높은 문턱을 넘어야 하는 거죠. 보안 장치가 의도치 않게 차별 장치가 되는 셈이에요.
지금은 뭐가 달라졌을까
2017년 이후 업계도 가만히 있진 않았어요. 크게 세 가지 흐름이 있어요.
- 보이지 않는 CAPTCHA: reCAPTCHA v3처럼 문제를 내지 않고 마우스 움직임, 브라우저 정보, 접속 이력 같은 신호로 ‘사람 같음’ 점수를 매기는 방식이에요.
- 대체 서비스: Cloudflare Turnstile은 사용자에게 퍼즐을 거의 보여주지 않고 브라우저 측 검증으로 판단하고, hCaptcha는 개인정보 보호를 앞세워 경쟁하고 있어요.
- 토큰 기반 증명: Private Access Tokens처럼 ‘이 요청은 정상 기기에서 왔다’는 걸 암호학적으로 증명하는 방식도 등장했어요.
한국 개발자가 챙겨볼 포인트
서비스를 만드는 입장이라면 이 이야기는 꽤 실용적이에요.
첫째, CAPTCHA를 기본값처럼 붙이지 마세요. 회원가입이나 로그인에 무조건 넣기 전에 레이트 리밋(일정 시간 동안 요청 횟수 제한), 이메일·휴대폰 인증, 이상 행동 탐지로 먼저 막을 수 있는지 따져보세요. CAPTCHA는 전환율을 확실히 떨어뜨리거든요.
둘째, 꼭 필요하다면 사용자에게 문제를 덜 보여주는 방식을 고르세요. Turnstile 같은 비대화형 솔루션은 붙이기도 간단하고 사용자 경험 손실이 적어요.
셋째, 접근성을 꼭 테스트하세요. 음성 CAPTCHA가 영어로만 나오지는 않는지, 스크린 리더로 통과할 수 있는지 직접 확인해 보면 생각보다 막히는 곳이 많아요. 국내에서 한국 사용자에게 익숙한 맥락으로 CAPTCHA를 바꿔보려는 시도들이 있었던 것도, 결국 ‘우리 사용자가 자연스럽게 풀 수 있는 문제인가’를 고민한 결과예요.
마무리
한 줄로 정리하면, ‘누구나 아는 상식’을 기준으로 만든 시험은 사실 ‘누군가의 상식’일 뿐이라는 거예요. CAPTCHA뿐 아니라 우리가 만드는 온보딩 흐름, 본인 인증, 입력 폼 검증에도 똑같이 적용되는 이야기죠.
여러분 서비스에서는 봇을 어떻게 막고 계신가요? CAPTCHA 없이도 충분히 막을 수 있었던 경험이나, 반대로 CAPTCHA 때문에 사용자를 잃었던 경험이 있다면 공유해 주세요.
🔗 출처: Hacker News