설치 검증은 시험 요청 기록, 항목 완전성, 봇 신원, 응답 코드 분포, 기록 연속성을 차례로 확인하는 일입니다. 먼저 사용자 에이전트(요청 프로그램이 스스로 밝히는 이름)에 고유 문자열을 넣은 시험 요청을 정한 시각에 한 번 보냅니다. 그 한 줄을 서버 기록과 측정 결과에서 찾고, 없거나 값이 어긋나면 수치 해석보다 원인 수정을 먼저 합니다.
설치 직후 확인 순서는 무엇인가요?
확인은 기록 생성, 항목 완전성, 봇 신원, 응답 분포, 기록 연속성 순서로 합니다. 앞 단계가 틀리면 뒤 단계의 판단도 함께 틀리기 때문입니다. 예를 들어 서버 시간대 설정이 틀리면 시험 요청이 다른 시간 칸에 집계되고, 5단계의 날짜 경계 판정도 흔들립니다.
| 단계 | 확인 내용 | 통과 기준 |
|---|---|---|
| 1. 기록 생성 | 시험 요청이 서버 기록(보낸 직후 검색)과 측정 결과(갱신 주기 1회 경과 뒤 대조)에 남는지 | 두 곳에서 같은 페이지·시각의 요청을 찾을 수 있음 |
| 2. 항목 완전성 | 접속 IP·시각·요청 경로·상태 코드·사용자 에이전트 | 시험 요청 때 메모한 값과 일치 |
| 3. 봇 신원 | 봇 이름을 단 요청이 실제로 해당 서비스에서 왔는지 | 표본 대부분이 공식 확인 수단을 통과하고, 실패가 일부 IP에 한정됨 |
| 4. 응답 분포 | 봇 이름별 상태 코드 구성 | 다른 봇과 비교해 특정 봇만 4xx·5xx 비율이 높지 않음(판정선은 내부에서 정함) |
| 5. 기록 연속성 | 날짜 경계·기록 파일 교체 시점 전후 | 시간대별 기록에 빈 구간이 없음 |
시험 요청은 어떻게 보내고 어디서 찾나요?
시험 요청은 두 가지를 준비합니다. 내부에서 직접 보내는 요청과 외부 크롤러가 보내는 요청입니다.
직접 보내는 시험 요청
서버 담당자나 웹 담당자가 명령줄 도구로 사용자 에이전트를 고유한 문자열로 지정해 요청을 한 번 보냅니다.
curl -A install-check-1020 측정 대상 주소
「측정 대상 주소」는 실제 페이지 주소로 바꿉니다. 보낸 시각(분 단위)과 사무실 공인 IP를 메모합니다. 사무실 공인 IP는 네트워크 담당자에게 묻거나, 서버 담당자가 시험 요청 기록 줄에서 함께 확인합니다. 이어서 접속 기록 파일에서 시험 문자열을 검색합니다.
grep install-check-1020 접속 기록 파일 경로
기록 파일 경로는 서버마다 다르므로 서버 담당자에게 확인합니다. 한 줄이 나오면 서버 기록 쪽은 통과입니다. 이어서 측정 결과의 같은 페이지·시각에 한 건이 집계되었는지 대조합니다. 측정 결과가 봇 요청만 집계하는 방식이면 직접 보낸 요청은 보이지 않을 수 있습니다. 그때는 아래 Google 시험 요청으로 대조합니다.
Google 시험 도구로 보내는 요청
Search Console 도움말에 따르면 URL 검사의 실시간 테스트는 해당 URL을 실시간으로 가져와 검사합니다. Google 크롤러 문서는 Google-InspectionTool을 리치 결과 테스트·URL 검사 같은 검색 테스트 도구의 크롤러로 소개합니다.
실시간 테스트를 한 번 실행한 뒤 서버 기록에서 Google-InspectionTool 문자열을 찾습니다. 페이지를 그리는 데 필요한 리소스 요청도 같은 이름으로 남을 수 있습니다. 따라서 검사한 페이지 경로의 요청을 기준으로 봅니다. 그 요청이 서버 기록과 측정 결과 두 곳에서 보이면 외부 크롤러 요청이 집계까지 반영된 것으로 판정합니다.
도움말은 실시간 테스트가 페이지의 리디렉션을 먼저 따라간 뒤 검사한다고 설명합니다. 리디렉션을 따라갔다는 사실과 실제로 검사한 최종 URL은 표시하지 않는다고도 적고 있습니다. 속성별 일일 실시간 검사 한도도 있으므로 리디렉션이 없는 최종 주소로 한 번만 시험합니다.
기록 한 줄에 남아야 할 항목은 무엇인가요?
nginx 문서의 combined 형식은 기록 항목 8개를 정의합니다. 접속 주소·원격 사용자·현지 시각·요청 줄·상태 코드·전송 바이트·참조 주소·사용자 에이전트입니다. Apache 문서는 Combined 형식을 Common 형식에 참조 주소와 사용자 에이전트를 더한 것으로 정의합니다. 시험 요청 한 줄을 아래 기준과 비교합니다.
| 항목 | 통과 기준 | 나타나는 현상 | 원인 후보 |
|---|---|---|---|
| 접속 IP | 메모한 사무실 IP와 같음 | 모든 줄이 소수의 같은 주소로 기록됨 | CDN(사이트 앞단에서 콘텐츠를 대신 전달하는 중계망)이나 프록시(요청을 대신 전달하는 중간 서버)의 주소가 기록됨 |
| 시각 | 보낸 시각과 분 단위로 일치하고 시간대 표기가 있음 | 정확히 몇 시간씩 어긋남 | 서버 시간대 설정 차이 |
| 요청 경로·상태 코드 | 요청한 경로와 실제 응답 코드가 남음 | 정상 페이지가 3xx·4xx로 기록됨 | 리디렉션 규칙, 보안 규칙의 차단 |
| 사용자 에이전트(칸) | 줄 끝에 사용자 에이전트 칸이 있음 | 칸 자체가 없음 | 사용자 에이전트가 빠진 Common 형식 사용 |
| 사용자 에이전트(값) | 시험 문자열이 그대로 남음 | 칸은 있으나 하이픈(-)만 남음 | 요청에 사용자 에이전트 값이 없음(시험 명령의 지정 누락 등) |
접속 IP는 가장 놓치기 쉬운 항목입니다. Apache 문서에 따르면 클라이언트와 서버 사이에 프록시가 있으면 프록시의 주소가 기록됩니다. Cloudflare를 쓰면 원본 서버에는 Cloudflare의 IP가 남습니다. 실제 방문자 주소는 CF-Connecting-IP라는 별도 헤더로 전달됩니다.
Cloudflare 문서의 nginx·Apache 설정 예시는 Cloudflare IP 대역을 신뢰할 프록시로 지정하도록 안내합니다. 현장에서는 신뢰 범위를 이 대역으로만 좁힙니다. 범위를 넓게 열면 다른 곳에서 꾸민 헤더 값도 실제 주소처럼 기록될 수 있습니다.
Apache 기록의 시각에는 시간대 표기가 붙습니다. 표기가 +0000이면 한국 시각보다 9시간 이르게 보이므로 집계 기준 시간대를 하나로 정합니다.
봇 이름이 진짜인지 어떻게 확인하나요?
Apache 문서는 사용자 에이전트를 클라이언트가 스스로 밝힌 식별 정보로 설명합니다. 이름만으로는 출처를 확정할 수 없습니다. 설치 직후에는 봇 이름별로 몇 건씩 표본을 골라 공식 확인 수단과 대조합니다.
| 서비스 | 공식 확인 수단 | 통과 기준 |
|---|---|---|
| 역방향 DNS 조회(IP 주소로 도메인 이름을 찾는 조회) 후 정방향 조회, 또는 크롤러 유형별 공개 IP 대역 목록 | 크롤러 유형별 역방향 도메인과 일치하고 정방향 결과가 원래 IP와 같음, 또는 유형별 목록 안의 IP | |
| Bing | Bingbot 확인 도구(IP 입력), 또는 Bing 공개 IP 대역 목록 | 확인 도구가 Bingbot으로 판정하거나 목록 범위 안의 IP임 |
| OpenAI | 봇별 공개 IP 대역 목록 | OAI-SearchBot·GPTBot·ChatGPT-User 등 이름에 맞는 목록 안의 IP |
| Perplexity | 봇별 공개 IP 대역 목록 | PerplexityBot·Perplexity-User 목록 안의 IP |
Google 문서는 크롤러를 일반·특수·사용자 요청형으로 나누고, 역방향 도메인을 유형마다 다르게 안내합니다. 일반 크롤러는 googlebot.com 계열, 특수 크롤러는 google.com 계열입니다. 사용자 요청형 가져오기는 googleusercontent.com 또는 google.com 계열입니다.
따라서 Googlebot이라고 밝힌 요청의 역방향 결과가 googlebot.com 계열이 아니면 사칭 후보로 분리합니다. 반면 AdsBot처럼 특수 크롤러 이름을 단 요청은 google.com 계열로 확인되어도 정상입니다.
Google 문서는 사용자 요청형 가져오기도 역방향·정방향 조회나 공개 IP 대역 목록으로 확인할 수 있다고 설명합니다. 실무 기준으로는 IP 대역 목록 대조를 기본으로 씁니다. 목록 파일 하나로 여러 IP를 한꺼번에 판정할 수 있기 때문입니다. 목록은 대체로 CIDR(주소 범위를 묶어 적는 방식) 형식이므로 개별 IP가 범위 안에 드는지로 판정합니다. 판정 규칙은 아래 두 가지로 정합니다.
- 실패가 일부 IP에 한정되면 설치는 정상으로 보고, 실패한 요청만 사칭 후보로 분리합니다.
- 모든 서비스의 표본이 한꺼번에 실패하면 봇 사칭보다 앞 절의 접속 IP 기록 문제를 먼저 의심합니다.
며칠 쌓인 기록에서 응답 분포와 연속성은 어떻게 보나요?
응답 분포는 행에 봇 이름, 열에 2xx·3xx·4xx·5xx 묶음을 둔 표로 셉니다. 공식 판정선은 없으므로 봇별 4xx·5xx 비율을 다른 봇들의 평균과 비교합니다. 예를 들어 가상의 내부 기준으로 다른 봇 평균의 두 배를 넘는 봇은 방화벽·보안 규칙부터 확인한다고 정할 수 있습니다. 모든 봇에서 오류가 비슷하게 높으면 서버 자체 응답 문제로 보고 운영 담당과 원인을 좁힙니다.
첫 주에는 아래 현상이 있는지 매일 점검합니다.
| 나타나는 현상 | 원인 후보 | 확인 방법 |
|---|---|---|
| 날짜가 바뀐 뒤 새 기록 파일이 비어 있음 | 파일 교체 뒤에도 서버가 옛 파일에 계속 기록 | 교체 설정에 서버가 기록 파일을 다시 여는 단계가 있는지 확인 |
| 서버 기록의 Google 크롤러 요청 수가 크롤링 통계와 크게 다름 | 기록 누락, 또는 비교 범위(크롤러 유형·호스트·기간) 불일치 | 보고서의 크롤러 유형 구분에 맞춰 서버 기록도 같은 범위·호스트·기간으로 세어 비교 |
| 같은 서비스의 봇이 여러 이름으로 흩어지거나, 차단 뒤에도 일부 요청이 계속 남음 | robots.txt 요청 표식, 사용자 요청형 봇 | 봇 이름 토큰 기준으로 묶고, 수집형과 사용자 요청형을 나눠 집계 |
| 시험 요청은 남는데 외부 방문 기록이 매우 적음 | CDN이 캐시로 응답해 원본까지 오지 않는 요청 | CDN 쪽 기록 제공 여부와 보존 기간 확인 |
첫 행은 Apache 문서에 근거합니다. 문서는 외부 도구로 기록 파일을 옮긴 뒤 graceful 재시작으로 서버가 기록 파일을 다시 열게 해야 한다고 설명합니다. 그 전까지 서버는 옛 파일 핸들에 계속 기록합니다. 실무에서는 nginx 등 다른 웹서버도 교체 설정에 같은 다시 열기 단계가 있는지 확인하는 방법을 권합니다. CDN 캐시 행은 공식 문서의 설명이 아니라 현장에서 먼저 점검하는 원인 후보입니다.
셋째 행은 각 서비스 문서에 근거합니다. OpenAI 문서에 따르면 OAI-SearchBot과 GPTBot은 robots.txt를 가져올 때 표식을 덧붙일 수 있습니다. 이 표식은 사용자 에이전트 문자열에 추가됩니다. 같은 문서는 ChatGPT-User가 사용자가 시작한 동작이라 robots.txt 규칙이 적용되지 않을 수 있다고 적습니다. Perplexity 문서도 Perplexity-User가 일반적으로 robots.txt 규칙을 따르지 않는다고 안내합니다. 따라서 봇 이름 토큰으로 묶어 세고, 사용자 요청형 요청이 남는 것은 설치 오류로 보지 않습니다.
크롤링 통계 도움말은 보고서 수치가 사이트의 요청 기록과 약간 다를 수 있다고 설명합니다. 또 루트 수준 속성에서만 제공되고 http와 https 요청을 함께 센다고 적습니다. 따라서 작은 차이는 정상으로 봅니다.
첫 주 점검 결과는 어떻게 기록하나요?
기대값과 실제값을 나란히 적어야 나중에 원인을 좁힐 수 있습니다. 판정은 통과·보류·실패 세 가지로 적고, 조치가 있으면 판정 뒤에 함께 적습니다. 보류는 원인을 찾아 조치를 요청한 상태입니다. 조치 뒤에는 같은 방식으로 재시험해 통과나 실패로 바꿉니다. 실패는 재시험에서도 기대값과 어긋난 경우입니다. 예를 들어 가상의 ○○ 기업이라면 아래처럼 적습니다.
| 점검일 | 항목 | 기대값 | 실제값 | 판정·조치 |
|---|---|---|---|---|
| 1일차 | 직접 시험 요청 | 사무실 IP, 10:05 | CDN 주소, 10:05 | 보류: 실제 주소 헤더 기록 요청 |
| 2일차 | 직접 시험 재시험 | 사무실 IP | 사무실 IP | 통과 |
| 2일차 | URL 검사 실시간 테스트 | 페이지 경로 요청 1건 이상 | 페이지 1건, 리소스 여러 건 | 통과 |
| 3일차 | 봇 신원 표본 | 실패가 일부 IP에 한정 | 10건 중 9건 통과 | 통과: 실패 1건 사칭 후보로 분리 |
| 4일차 | 봇별 응답 분포 | 판정선 초과 봇 없음 | 한 봇만 403 비율 초과 | 보류: 보안 규칙 예외 확인 요청 |
통과하지 못한 항목은 시각과 문자열을 밝혀 서버 담당자에게 구체적으로 요청합니다. 아래는 1일차 결과를 전달하는 문안입니다.
「○월 ○일 10시 5분에 사용자 에이전트 install-check-1020으로 보낸 요청의 접속 IP가 CDN 주소로 기록되었습니다. 실제 방문자 주소가 담긴 헤더를 기록 형식에 추가해 주시기 바랍니다. 그 헤더는 CDN 공개 IP 대역에서 온 요청에서만 신뢰하도록 설정해 주십시오. 적용 시각을 알려 주시면 같은 방식으로 다시 시험하겠습니다.」
정리
- 고유한 사용자 에이전트로 시험 요청을 보내고, 시각과 IP를 메모한 뒤 서버 기록과 측정 결과 두 곳에서 찾습니다.
- 리디렉션이 없는 최종 주소로 URL 검사 실시간 테스트를 한 번 실행하고, 페이지 경로 요청이 기록·집계되는지 대조합니다.
- 접속 IP·시각·상태 코드·사용자 에이전트를 메모한 값과 비교하고, 어긋난 항목은 문안을 써서 수정을 요청합니다.
- 봇 이름별 표본을 크롤러 유형별 역방향 도메인, 확인 도구, 공개 IP 대역 목록으로 판정하고 실패한 요청은 사칭 후보로 분리합니다.
- 첫 주 동안 봇별 상태 코드 분포와 날짜 경계의 기록 공백을 살피고, 결과를 통과·보류·실패로 기록 양식에 적습니다.
참고 자료
- Verifying Googlebot and other Google crawlers (Google Search Central, 확인일 2026-10-22)
- Google's common crawlers (Google Search Central, 확인일 2026-10-22)
- URL Inspection tool (Search Console 고객센터, 확인일 2026-10-22)
- Crawl Stats report (Search Console 고객센터, 확인일 2026-10-22)
- Verify Bingbot (Bing Webmaster Tools, 확인일 2026-10-22)
- Bingbot IP 대역 목록 bingbot.json (Microsoft Bing, 확인일 2026-10-20)
- Overview of OpenAI Crawlers (OpenAI, 확인일 2026-10-22)
- Perplexity Crawlers (Perplexity, 확인일 2026-10-22)
- Module ngx_http_log_module (nginx, 확인일 2026-10-20)
- Log Files (Apache HTTP Server 2.4 Documentation, 확인일 2026-10-22)
- Restoring original visitor IPs (Cloudflare Docs, 확인일 2026-10-22)