AI가 받는 모든 ‘정상’ 웹 응답의 20%는 정상적이지 않다

최근 AI를 활용한 웹 스크래핑을 실험하면서 웹이 점점 더 ‘폐쇄적으로’ 변하고 있다는 사실을 실감했다. 물론 이런 변화의 계기가 된 것은 AI 웹 스크래핑의 급격한 증가다. 새로운 데이터를 가리지 않고 끊임없이 요구하는 AI 웹 스크래핑은 결국 웹사이트를 다운시킬 수도 있다.

이는 여러 도메인이 오래전부터 원했던 일을 실행할 좋은 명분이 된다. 사용자가 로그인한 경우에만 콘텐츠에 접근할 수 있도록 하는 것이다(물론 Googlebot은 대개 예외적으로 접근을 허용받는다). Facebook은 2023년에 이 정책을 단계적으로 도입하는 작업을 마쳤고, Twitter/X도 같은 해에 똑같이 했다. Reddit도 이달 말 이 정책을 도입할 예정이다.

이렇게 하면 사용자가 이미 등록되어 있으므로 도메인 운영자는 국가별 연령 제한 규정의 집행을 조금 더 쉽게 준수할 수 있다. 더 중요한 점은 사용자 데이터를 저장해 지역별 분석에 활용하고, 현지 법률이 허용하는 경우 데이터 중개업체와 AI 기업에 판매할 수도 있다는 것이다.

한편 사용자를 가입시키려는 것이 아니라 봇을 막는 데 초점을 맞춘 조치는 전년 대비 58% 넘게 증가했다. Cloudflare에 따르면 그렇다. 봇 활동이 계속 증가하면서 웹사이트는 자연히 VPN 및 프록시 주소를 면밀히 조사하게 되고, 그 결과 ‘악의적인’ 트래픽과 함께 정상적인 사용자도 접근을 차단당할 수 있다.

개인적으로는 차단 응답이나 확인 절차를 마주치는 일이 점점 잦아지는 것 같다. 그런 화면이 로딩되기 시작하면 사이트 이용을 아예 포기할 때도 있다. CAPTCHA 장벽은 사용자와 잠재 고객의 이용을 단념하게 하는 것으로 나타났으므로, 이런 단점에도 도메인 소유자들이 CAPTCHA를 도입하게 만드는 압박이 어느 정도일지 짐작할 수 있다.

과도한 자동화 요청(사람의 요청이 아닌)에 대응하기 위해 확인 절차를 도입한 여러 사이트 중 하나인 archive.is의 CAPTCHA 화면.

이처럼 새로 생기거나 강화된 여러 불편은 일부는 물량을 감당하지 못하는 도메인이 있기 때문이지만, 데이터에 목말라 하는 AI 기업들이 그동안 오랫동안 무료로 이용해 온 데이터를 대가로 단독 또는 공동 보상을 제공할지 알아보려는 협상 전략인 경우도 많다. 이제는 상황이 달라지고 있다.

AI 크롤러는 대규모로 작업해야 하므로 Playwright 프레임워크에서 Chrome의 ‘헤드리스’ 인스턴스를 사용하는 경우가 많다. 요즘은 점점 더 많은 도메인에서 이렇게 접속하면 403(‘접근 금지’) 오류가 발생한다(즉, 호스트가 자동화 트래픽임을 알아챘으니 이제 나가라는 뜻이다).

changedetection.io를 로컬에 설치해 한 사이트에 주기적으로 요청을 보내지만, 사이트가 프레임워크에서 사용하는 감지된 브라우저를 허용하지 않아 403(‘접근 금지’) 응답을 반환한다.

원하는 것은 ‘200’(‘정상’) 클라이언트 응답이다. 이를 받기 위해 다른 여러 비인간적이고 교묘한 수법과 함께 주거용 프록시를 대량으로 운영하는 업체에 거액을 지불해야 하더라도 말이다.

200 응답보다 더 나은 것은 없다. 다시 말해, 긍정적인 신호를 더 강하게 나타내는 클라이언트 응답 코드는 없다. 모호한 응답도 아니다. ‘거의 괜찮음’이나 ‘나중에는 괜찮아질 것’, ‘점점 더 괜찮아지는 중’이라는 뜻이 아니라 ‘괜찮다!’는 뜻이다. 괜찮지 않다면 200 응답이 아니다.

안녕하세요! 이제 가세요

하지만 새 논문에 따르면, 이러한 세분성의 부족은 AI 데이터 세트와 통계적 추정치를 크게 왜곡하고 실제와 다른데도 ‘정상’ 상태로 보고하게 만들 수 있다.

이 연구*는 200 범주 응답의 약 5분의 1이 사용할 수 있는 페이지 콘텐츠를 전혀 포함하지 않는다고 추산한다. 대신 비어 있는 웹사이트 뼈대, CAPTCHA 확인 절차, 접근 제한 또는 대체 페이지를 제공한다.

논문은 다음과 같이 밝힌다.

‘정적 클라이언트가 상태 코드 200으로 받은 페이지 중 20.9%에는 페이지의 주요 콘텐츠가 없다. 앱 셸, 봇 확인 절차, 차단 페이지, 오류 및 자리 표시자 페이지, 일부 콘텐츠만 포함된 페이지가 이에 해당한다.’

이런 점에서 성급한 자동화 시스템은 스스로의 단순한 판단 방식에 발목을 잡힌다. ‘200’ 응답을 성공적인 가져오기로 간주할 수 있기 때문이다. 실제로는 페이지를 가져온 결과가 CAPTCHA 장벽이나 유료 구독 장벽 또는 다른 장애물에 불과한 경우에도 그렇다.

논문은 200 응답을 자주 복잡하게 만드는 콘텐츠 유형 일곱 가지를 제시한다.

200 응답에서 ‘정상’과는 거리가 먼 콘텐츠 유형 일곱 가지. 출처

이번 연구에서는 3일 동안 기본 웹 가져오기 프로그램과 JavaScript를 불러올 수 있는 브라우저를 모두 사용해 웹 주소 10,307개를 테스트하고, HTTP 상태 코드가 아니라 가져온 콘텐츠를 기준으로 응답을 분류했다.

‘사용할 수 없는’ 202 응답 가운데 가장 큰 비중을 차지한 유형은 내용이 비어 있는 웹사이트 골격과 오류 페이지 또는 대체 페이지였으며, 이 두 유형이 전체 실패의 3분의 2 이상을 차지했다.

내용이 비어 있는 사이트 골격의 경우, 웹사이트에 메뉴와 탐색 기능은 표시되지만 요청한 기사나 제품 목록은 빈칸으로 남을 수 있다. 후자의 경우에는 요청한 콘텐츠 대신 무관한 페이지나 홈페이지가 표시될 수 있다. 하지만 두 경우 모두 사용 가능하고 유용한 콘텐츠를 성공적으로 가져온 응답과 동일한 HTTP 200 상태 코드를 받을 수 있다.

해결책으로 논문은 HTTP 상태 코드에 의존하는 대신 웹 가져오기 도구가 실제로 무엇을 가져왔는지 보고할 것을 권고한다. 지나치게 짧은 페이지, 의심스러운 리디렉션, 존재하지 않는 페이지와 유사한 콘텐츠를 간단히 점검하는 것만으로도 대부분의 실패를 찾아낼 수 있기 때문이다.

그런 다음 페이지가 제대로 로드되지 않은 것으로 보일 때만 리소스 소모가 큰 브라우저 도구를 사용할 수 있다. 또한 AI 평가에서는 HTTP 200 응답을 콘텐츠가 성공적으로 가져와졌다는 뜻으로 간주하지 말고, 인용된 출처에 실제로 예상한 정보가 들어 있는지 확인할 수 있다.

새 연구의 저자는 페이지 길이, 리디렉션, 존재하지 않는 페이지와의 유사성을 기본적으로 점검하는 ‘간단한 휴리스틱’만으로도 사용할 수 없는 응답의 약 86%를 손쉽게 찾아낼 수 있다고 덧붙였다.

웹 가져오기 전략 비교: 의심스러운 것으로 표시된 페이지만 렌더링하면 모든 페이지를 렌더링할 때(80.3%)보다 사용할 수 있는 콘텐츠를 약간 더 많이 확보할 수 있었다(81.4%). 페이지당 평균 가져오기 시간은 20.6초에서 5.8초로 줄었다. 

잘못된 200 응답은 왜 이렇게 많을까?

개발자 커뮤니티에서는 오랫동안 어느 정도 논쟁이 이어져 왔다. 202(‘수락됨’) 오류(‘요청을 수락했지만 아직 완료되지 않음’)가 이러한 ‘실패한’ 200 상태 요청을 구분해 줄 수 있다는 주장이었다. 하지만 실제로 202는 새 논문에서 제시한 모든 사례에 적용될 수 없으며, 이를 처리할 기존 코드도 없다.

논문은 이 문제를 깊이 다루지는 않지만, 도메인 소유자가 200 오류를 허용하는 이유는 향후 관련 연구에서 더 살펴볼 만하다.

한 가지 이유는 200이 아닌 응답은 사실상 어떤 형태로든 오류 페이지나 방해 요소를 뜻하기 때문일 수 있다. 여기에는 가장 흔한 404(‘찾을 수 없음’) 오류도 포함되며, 이 경우 대상 콘텐츠가 단순히 없는 것이다. 일부 사용자는 이런 오류가 지나치게 많으면 SEO(그리고 아마도 GEO)에서 불이익을 받을 것이라고 믿지만, Google은 이를 부인한다.

실제로 Google은 잘못된 200 응답을 ‘소프트’ 404로 간주한다. 이러한 응답은 의도적이든 아니든 사실상 ‘기만적인’ 결과이므로, 일반적인 404 오류보다 더 큰 문제로 취급될 가능성이 분명히 높다.

인용 출처의 변동

이 모든 것이 지나치게 꼼꼼한 문제 제기처럼 보인다면, AI 학습을 위해 일상적으로 수집하거나 수집하려고 시도하는 데이터가 페타바이트 규모라는 점을 고려해야 한다. 그 데이터의 5분의 1이 신뢰할 수 없거나 노골적으로 기만적이라면, 그로 인한 후속 결과를 일종의 ‘부수적 부정확성’이라며 대수롭지 않게 넘기기 어렵다. 오히려 이러한 잘못된 응답은 데이터 세트의 분포와 해당 데이터를 AI 모델에 학습시킨 결과에 중대한 악영향을 미칠 수 있다.

예를 들어 잘못된 200 응답과 관련한 주목할 만한 문제로 ‘인용 출처의 변동’이 있다. 이는 AI가 생성한 답변을 뒷받침하던 웹페이지가 더 이상 근거로 기능하지 않는 상황을 가리킨다. 즉, 페이지 내용이 바뀌었거나 관련 문구가 삭제되었거나 링크가 다른 곳으로 연결될 수 있다.

새 연구에 따르면, HTTP 200 응답에 어떤 콘텐츠가 담겼는지 관계없이 모두 성공적으로 가져온 것으로 처리했을 때, 인용 출처가 바뀐 것으로 보이는 비율은 5.8%에서 21.9%로 상승했다.

이는 원래 자료 대신 CAPTCHA, 빈 페이지 또는 다른 방해 요소를 가져왔다는 이유만으로 출처가 변경되거나 사라졌거나 AI가 생성한 주장을 더 이상 뒷받침하지 않는다고 잘못 판단할 수 있다는 뜻이다.

그냥 그렇다고 응답할 뿐!

의도적으로 존재하지 않는 웹 주소를 이용한 테스트에서도 이 문제가 드러났다. 웹사이트에 무작위로 만든 경로를 요청했을 때, 응답한 사이트 가운데 13.1%는 요청한 페이지가 존재하지 않는데도 200(‘OK’) 상태를 반환했다^†.

‘무작위 경로 탐색에 응답한 사이트 중 13.1%가 200을 반환했다(S1 10.5%, S2 13.3%, S3 17.3%, S4 13.7%, S5 13.1%). 이런 응답은 모두 구조상 소프트 404이지만, 모두가 이를 명시하는 것은 아니다.

‘소프트 404 응답 172건을 탐색적으로 분석한 결과, 분류 담당자는 98건을 오류 페이지 또는 대체 페이지, 32건을 껍데기 페이지, 28건을 콘텐츠로 분류했다. 임의 경로에 홈페이지나 목록 페이지가 제공되면 일반적인 페이지처럼 보인다.’

결론

문제가 더 높은 수준에서 인식된다면, IANA 가 새롭고 더 적절한 HTTP 상태 코드를 만들 수도 있다. 예를 들면 [X] (‘요청은 성공했지만 요청한 콘텐츠는 제공되지 않았습니다’). 이는 실제로 일어나는 일을 정확히 설명하겠지만, 호스트 측에서 트랜잭션을 상당히 깊이 파악해야 하므로 실현 가능성은 낮다.

비슷한 코드가 이미 있지만, 어느 것도 정확히 들어맞지는 않는다. 451(‘법적 사유로 이용할 수 없음’)은 의미가 모호하고 다소 위협적으로 들린다(!). 206(‘일부 콘텐츠’)은 기술적으로는 적절하지만, 불완전한 데이터(가져오기)에 사용하도록 만들어졌다. 그리고 존재한다는 사실이 놀라운 203(‘비권위적 정보’)은 1997년에 만들어졌으며, 현재 사용 사례와는 주변적으로만 관련이 있다.

어쩌면 가장 가까운 후보는 직관적이지 않은 이름의 103(‘초기 힌트’)일 수 있다. 이 코드는 URL의 리소스가 아직 모두 로드되지 않았음을 나타낸다(다만 이는 코드의 의도를 명백히 크게 오해하는 해석일 것이다).

* 제목은 ‘200 OK가 답이 아닐 때: 에이전트형 웹 콘텐츠 수집에서 발생하는 무응답 가져오기 실패’입니다.’ 이 논문은 아마도 AI가 질의할 수 있도록 주로 기계가 읽을 수 있는 형식으로 작성된 것으로 보이며, 논문 자체는 읽기 쉽지 않다는 점에 유의하시기 바랍니다.

^†기계적으로 들리는 인용문에 대해 양해를 구합니다. 위에서 언급했듯 논문 전체가 인간이 해석하기보다는 ‘기계가 읽을 수 있도록’ 이런 식으로 작성되어 있지만, JSON 형식으로 제시하는 데까지 이르지는 않습니다.

최초 게시일: 2026년 11월 4일 수요일