쌓아 두기만 한 로그를 처음 열어 보니 전제가 틀려 있었다
한눈에 답변
방문자 기록을 몇 주째 쌓아 두기만 했을 뿐 실제로 집계해서 열어 본 적이 없었다. 처음으로 집계해 보니 전체 요청의 4분의 1가량이 404 오류였고, 그 상위 원인은 콘텐츠에 대한 수요가 아니라 서버 설정 파일이나 자격 증명 파일을 노리는 스캔 시도였다. 정상적으로 검증되는 크롤러는 이런 요청을 만들지 않는 반면, UA 표시만으로 판별되는 크롤러 계열에서 이런 요청 비율이 훨씬 높게 나타났다.
무엇을 처음으로 열어 봤나
이 사이트에 방문하는 각종 크롤러의 요청 기록을 데이터베이스에 계속 쌓아 오고 있었다. 그런데 그 데이터를 실제로 집계해서 살펴본 적은 없었다. 처음으로 열어서 요청 약 1,700건을 들여다봤다.
무엇을 발견했나
전체 요청의 4분의 1 가까이가 존재하지 않는 경로에 대한 404 오류였다. 그 오류를 일으킨 요청 상위를 뽑아 보니, 실제 콘텐츠 경로가 아니라 서버 설정 파일이나 인증 정보가 저장될 법한 경로를 노리는 요청들이었다. 그리고 이 요청들은 전부 잘 알려진 AI 크롤러 이름을 자기 신원으로 내세우고 있었다.
왜 이게 의심스러운가
정상적인 크롤러는 사이트에 실제로 존재하는 링크를 따라간다. 없는 인증 정보 파일이나 시스템 설정 파일 경로를 스스로 만들어서 요청하지 않는다. 게다가, 인프라 제공사가 신원을 별도로 검증해 주는 크롤러 계열에서는 이런 이상 요청 비율이 매우 낮았던 반면, 자기 신원 표시(UA)만으로 판별되는 계열에서는 그 비율이 훨씬 높았다. 이 대비가 스캔 의심의 근거가 됐다.
그럼 지금까지 기록한 방문 수치는 못 쓰는 것인가
전부 못 쓰는 것은 아니지만, 이 사실을 밝히지 않고 방문 수치를 그대로 인용하면 오해를 만든다. 스캔으로 의심되는 요청 경로를 걸러내는 규칙을 별도로 만들어서, 집계할 때 이 경로들을 제외하고 그 사실 자체를 근거 문장에 함께 적기로 했다.
검증된 신원 구분은 왜 따로 만들었나
지금까지는 신원 확인이 UA 문자열 하나로만 이루어지고 있었다. 인프라 제공사가 실제로 검증한 값을 별도 항목으로 함께 기록하도록 db 구조를 바꿨다. 다만 이 값이 실제로 쌓이는 데는 시간이 걸리므로, 새 항목이 충분히 쌓이기 전까지는 “검증됨”과 “검증 안 됨”을 섣불리 비교하지 않기로 했다.