생성형 AI 검색 대응에 쓸 수 있는 비정형 데이터 가운데 가장 먼저 확보할 수 있는 것은 서버 접근 로그입니다. 서버 접근 로그를 봇 종류별·페이지별로 분류하면 접근성 문제와 문서의 빈틈이 드러나고, 그 결과를 문서 편집으로 연결할 수 있습니다. 다만 로그는 요청이 서버에 도달했다는 사실만 보여 줍니다. AI 답변 노출이나 인용을 증명하지는 않으므로 판단 근거와 결과 지표는 나누어 기록합니다.
이 글은 웹 분석 도구만 써 오다가 처음으로 로그 파일을 받은 소규모 서비스 사이트의 콘텐츠 담당자를 기준으로 씁니다. 로그를 들여다보는 데서 멈추지 않도록 단계마다 할 일과 다음 단계로 넘어가는 기준을 함께 제시합니다.
1단계: 로그를 확보하고 기록 범위를 정합니다
먼저 웹 서버나 CDN에서 접근 로그를 내려받아 요청 시각, 요청 URL, 응답 코드, 사용자 에이전트, IP 주소의 다섯 가지 필드가 남아 있는지 확인합니다. 자바스크립트 태그 방식의 분석 도구는 브라우저에서 스크립트가 실행되어야 기록을 남깁니다. 그래서 스크립트를 실행하지 않는 자동화 요청은 서버 쪽 기록에서 따로 확인해야 합니다. 호스팅 환경에 따라 로그 보관 기간이 짧게 설정된 경우가 있으므로, 분석을 시작하기 전에 보관 기간과 내려받는 방법을 운영 담당자와 정해 둡니다.
로그 일부를 직접 열어 사용자 에이전트 필드가 중간에 잘리지 않았는지, 시각이 어느 시간대를 기준으로 기록되었는지도 확인합니다. 시간대가 섞이면 편집 전후를 비교할 때 날짜 경계가 어긋납니다. CDN 캐시가 응답한 요청이 원본 서버 로그에 남지 않는 구성이라면 두 로그 가운데 어느 쪽을 기준으로 삼을지도 이 단계에서 정합니다.
IP 주소는 내부 개인정보 처리 기준에 따라 보관 범위와 열람 권한을 정합니다. 분석용 사본에서는 사람 방문 요청을 일부 가리는 방식도 고려할 수 있습니다. 다음 단계로 넘어가는 기준은 일정 기간의 로그를 하나의 표로 불러왔을 때 다섯 가지 필드가 빠짐없이 채워져 있고, 같은 형식으로 반복해서 추출할 수 있는 상태입니다.
2단계: 요청을 봇 종류별로 나눕니다
사용자 에이전트 문자열을 기준으로 요청을 몇 가지 범주로 묶습니다. 분류 방식의 한 예로 geoanalytics.ai.kr를 들 수 있습니다. 이 사이트는 ChatGPT·Perplexity·Claude·Google·Naver의 요청을 서버에 도달한 요청 기준으로 측정한다고 설명합니다. 해당 사이트 표시 기준으로는 GPTBot·ChatGPT-User, ClaudeBot·Claude-User, PerplexityBot, Googlebot·Google-Agent, Yeti 등을 엔진별로 묶습니다. 또 모델 학습·색인을 위한 정기 수집 크롤과 사용자 질문에 답하려고 그때그때 가져가는 실시간 참조를 구분합니다. 이 사이트도 수집·참조 기록이 AI 답변 화면 노출을 보장하지 않으며 선행 지표로만 해석해야 한다고 밝히고 있습니다.
담당자가 직접 분류할 때는 아래 네 범주로 시작하는 것이 좋습니다.
- 정기 수집 크롤: 일정 주기로 여러 페이지를 가져가는 요청입니다. 어떤 문서가 수집 대상에 들어 있는지 확인하는 데 씁니다.
- 사용자 요청형 실시간 참조: 사용자의 질문을 계기로 특정 페이지를 가져가는 요청입니다. 어떤 주제에 수요가 있는지 추정하는 데 씁니다.
- 검색 색인 크롤: 일반 검색 결과를 위한 수집 요청입니다. 기존 검색 접근성을 점검하는 기준이 됩니다.
- 사람 방문과 미분류 요청: 위 범주에 속하지 않는 요청입니다. 미분류 사용자 에이전트는 목록으로 따로 남겨 둡니다.
사용자 에이전트 문자열은 누구나 흉내 낼 수 있습니다. 그래서 주요 봇은 각 운영사가 공개한 봇 안내 문서의 사용자 에이전트와 IP 범위로 대조합니다. 예를 들어 운영사 이름이 사용자 에이전트에 들어 있지만 공개된 IP 범위와 맞지 않는 요청은 '미검증'으로 표시하고 집계에서 분리합니다. 범주 이름과 판정 규칙은 별도 문서로 남겨 두면 담당자가 바뀌어도 같은 분류를 재현할 수 있습니다. 다음 단계로 넘어가는 기준은 주요 봇 요청이 모두 하나의 범주에 배정되고, 대조하지 못한 요청이 별도 목록으로 정리된 상태입니다.
3단계: 페이지별로 묶어 접근성 문제를 찾습니다
분류한 요청을 URL별로 다시 모읍니다. 이때 추적용 파라미터, 끝의 슬래시, 대소문자 차이 때문에 같은 문서가 여러 줄로 갈라지지 않도록 URL을 정규화합니다. 그다음 봇 범주별로 요청 수와 응답 코드를 나란히 놓습니다. 같은 문서에서 404·5xx 오류, 여러 번 이어지는 리디렉션, 의도하지 않은 차단이 반복되면 콘텐츠를 고치기 전에 기술 문제부터 해결합니다.
접근성 점검 기준은 기존 검색 원칙에서 가져옵니다. Google 검색 센터 SEO 기본 가이드는 검색엔진이 링크를 따라 페이지를 발견하는 방식, 사이트맵, robots.txt 같은 기본 요소를 다룹니다. Google 검색 센터는 Google의 AI 검색 기능에 별도의 특별한 최적화가 필요한 것은 아니며 기존 검색 접근성과 유용한 콘텐츠 원칙을 따르면 된다고 안내합니다. 이 설명은 Google 검색에 한정되며, 다른 AI 서비스에 그대로 적용된다고 볼 근거는 없습니다. 네이버 검색 노출을 함께 관리한다면 네이버 서치어드바이저 가이드에서 사이트 등록, robots.txt, 사이트맵 제출 절차를 확인해 로그 결과와 대조합니다.
적용 예시로, 안내 문서가 리디렉션을 두 번 거쳐 최종 주소에 도달한다면 내부 링크를 최종 주소로 바로 연결하도록 고칩니다. robots.txt에서 특정 경로를 막아 두었다면 그 경로 아래에 공개해야 할 안내 문서가 섞여 있지 않은지 확인합니다. 다음 단계로 넘어가는 기준은 사이트의 핵심 문서 목록을 만든 뒤 각 문서가 정상 응답을 반환하는지, 그리고 차단된 문서가 모두 의도한 차단인지 확인을 마친 상태입니다.
4단계: 관측 패턴으로 문서의 빈틈을 찾습니다
접근성 문제를 정리했다면 이제 요청 분포를 문서 기획의 단서로 읽습니다. 아래 비교 목록은 관측 패턴과 해석, 실무 제안을 짝지은 것입니다. 해석은 모두 가설이므로 편집 후 다시 관측해 확인합니다.
- 핵심 문서에 수집 기록이 거의 없는 경우: 내부 링크나 사이트맵에서 빠졌을 가능성이 있습니다. 상위 메뉴와 관련 문서에서 링크를 추가하고 사이트맵 포함 여부를 확인합니다.
- 로그인·약관 같은 보조 페이지에 요청이 몰리는 경우: 핵심 안내 문서로 가는 경로가 약할 수 있습니다. 첫 화면과 안내 문서 사이의 링크 구조를 점검합니다.
- 수집 기록은 있으나 실시간 참조가 없는 경우: 문서가 실제 질문에 답하는 형태인지 알 수 없습니다. 질문 설계 단계로 넘겨 검토합니다.
- 실시간 참조가 특정 질문형 문서에 몰리는 경우: 그 주제에 수요가 있을 수 있습니다. 관련 문서의 정의, 조건, 절차 문단을 보강합니다.
질문 설계는 고객 문의, 상담 기록, 사이트 내부 검색어처럼 이미 가지고 있는 비정형 기록에서 실제 질문을 뽑아 목록으로 만드는 작업입니다. 질문마다 그 질문에 직접 답하는 문단이 어느 문서에 있는지 표시하면, 답이 없거나 여러 문서에 흩어진 질문이 드러납니다.
편집 순서는 접근성 문제를 해결한 문서 가운데 고객 문의에 자주 등장하는 질문과 연결된 문서부터 정합니다. 요청 수가 적다는 이유만으로 문서를 삭제하거나 통합하지는 않습니다. 관측 기간이 짧으면 표본이 적어 해석이 쉽게 흔들리기 때문입니다. 다음 단계로 넘어가는 기준은 편집 대상 문서와 각 문서에서 보강할 질문이 하나 이상 정해진 상태입니다.
5단계: 문서를 편집하고 관측 기록을 이어 갑니다
편집은 한 번에 한 가지 변경을 원칙으로 합니다. 질문에 대한 답을 문서 첫머리 가까이에 두고, 용어 정의와 적용 조건을 분명히 하며, 관련 문서 사이에 링크를 연결합니다. 편집 기록에는 날짜, URL, 변경 내용, 변경 전후의 봇 범주별 요청 수를 남깁니다. AI 답변 화면을 직접 확인했다면 확인 날짜와 질문 문장도 함께 적되, 답변은 질문과 시점에 따라 달라질 수 있다는 점을 메모로 남깁니다.
재관측할 때는 편집 전과 같은 길이의 관측 기간을 두고 2~3단계와 같은 분류 규칙으로 다시 집계합니다. 분류 규칙을 중간에 바꾸면 전후 비교가 성립하지 않습니다. 규칙을 바꿔야 할 때는 변경 날짜를 기록하고 그 시점을 새 기준선으로 삼아 다시 측정합니다.
이 과정을 거쳐도 특정 페이지의 색인, 순위, 인용은 보장되지 않습니다. 로그의 변화는 수집 대상과 접근 경로가 달라졌다는 사실을 보여 주는 근거로 보고하고, 유입이나 전환 같은 결과 지표는 기록이 충분히 쌓인 뒤에 따로 판단합니다. 한 사이클을 마치는 기준은 편집한 문서의 재관측 결과가 기록표에 반영된 상태이며, 그 후 1단계의 추출 절차로 돌아가 같은 방식으로 반복합니다.