500페이지 사이트 AI 감사, 채팅 세션은 몇 번 필요할까

이 글의 모델에 따르면 500페이지 웹사이트를 AI 채팅으로 감사하려면 한 번 훑는 데만 약 21개 세션과 귀하의 시간 약 15시간이 필요합니다. 더 큰 비용은 21개의 결과를 합쳐도 하나의 감사가 되지 않는다는 점입니다. 각 세션은 다른 세션이 본 증거 없이 시작하고, 페이지마다 다른 항목을 살피며, 판정을 저마다의 표현으로 적습니다. 그래서 하나로 병합할 단일한 방법이 없고, 다음 달에 똑같이 반복할 방법도 없습니다. AI 세션은 문제를 설명하고 고치는 데 탁월하며, 완전한 발견 사항 목록에서 출발할 때 가장 좋은 결과를 냅니다.

ChatGPT로 감사하든 Claude나 다른 어시스턴트로 감사하든 아래의 계산은 같습니다. 특정 제품이 아니라 채팅 세션이 작동하는 방식에서 나오는 결과이기 때문입니다. 이 시리즈의 첫 글인 AI 세션 하나로 웹사이트 전체를 감사할 수 없는 이유에서는 세션 하나가 다룰 수 있는 범위를 살펴보고, 세션당 25페이지와 100페이지를 기준으로 사이트당 세션 수를 모델로 계산했습니다. 이번 글에서는 새 세션을 계속 열 때 쌓이는 것, 즉 귀하의 시간과 세션 간 편차를 합산합니다.

500페이지 사이트는 상위 4분의 1에 들지만 여전히 흔합니다

이 모델에서는 사이트 규모가 모든 것을 결정하므로 실제 규모부터 살펴봅니다. SEOReport가 2026년 5월부터 10월까지 감사한 외부 웹사이트 중 XML 사이트맵에 URL이 하나 이상 있었던 29개 사이트를 보면, 사이트맵에 나열된 URL 수의 중앙값은 약 90개였습니다. 4분의 1은 20개 이하, 4분의 1은 440개 초과였고, 가장 큰 10%는 3,000개를 넘었습니다.

이 사이트들은 SEOReport 감사를 위해 제출된 사이트이며, 웹 전체의 무작위 표본이 아닙니다. 500페이지 사이트는 이 중 상위 4분의 1에 막 들어가는 규모로, 대개 블로그와 서비스 또는 제품 페이지를 갖추고 몇 개 언어를 지원하기도 하는 자리 잡은 비즈니스입니다. 사이트맵은 사이트가 검색엔진에 찾아 달라고 요청하는 페이지의 목록입니다. 태그, 필터, 아카이브 URL은 사이트맵 밖에 있을 수 있으므로, 사이트맵의 URL 수는 감사가 고려해야 할 범위의 최솟값입니다.

모델: 세션당 페이지 수, 그리고 사이트당 세션 수

이것은 측정이 아니라 모델입니다. 모든 수치는 명시한 4가지 가정에서 나오며, 어느 가정이든 바꿀 수 있습니다.

1. 세션당 25페이지. 이 시리즈의 첫 글에서 사용한 두 가지 처리 용량 중 낮은 쪽입니다. 꼼꼼한 페이지 검토는 눈에 보이는 텍스트보다 훨씬 많은 것을 읽습니다. 상태 코드, 응답 헤더, head 태그, 구조화된 데이터, 그리고 페이지가 사이트맵 및 다른 페이지와 어떤 관계에 있는지까지 봅니다. SEOReport가 2026년 5월부터 10월까지 감사한 외부 웹사이트 45개에서 표시된 문제 506건 중 94%는 페이지를 읽는 사람이 결코 보지 못하는 곳에 있었고, 중앙값 사이트는 서로 다른 5곳의 증거 위치에서 문제가 표시되었습니다. 페이지마다 그만큼의 증거를 붙든 채 꼼꼼하게 답하려면 세션 용량은 높은 쪽이 아니라 낮은 쪽이 됩니다. 단순한 페이지라면 더 많이, 무거운 템플릿이라면 더 적게 처리할 수 있습니다.
2. 사이트 전체 파일을 위한 추가 세션 1개. robots.txt, XML 사이트맵, 그리고 HTTP와 HTTPS 사이, www 호스트 이름과 www 없는 호스트 이름 사이의 리디렉션입니다.
3. 세션당 귀하의 시간 20분. 방법을 다시 설명하고 페이지 목록을 넘기는 데 약 10분, 결과를 저장하고 마스터 목록에 병합하는 데 10분입니다.
4. 페이지당 귀하의 시간 1분. 페이지를 헤더와 함께 가져오거나 붙여넣고, 세션이 실제로 읽었는지 확인하는 시간입니다. 어시스턴트의 가져오기 도구는 페이지를 헤더 없이 텍스트로 변환해 돌려주는 경우가 많아 이 단계가 필요합니다. 그 차이는 AI 에이전트가 페이지를 확인할 때 보는 것에서 확인할 수 있습니다.

계산식은 다음과 같습니다. 세션 수 = 페이지 수 ÷ 25(올림) + 1. 귀하의 시간(분) = 20 × 세션 수 + 페이지 수.

시간은 세션 수보다 세션당 용량 가정에 덜 민감합니다. 세션이 커져도 페이지를 다루는 데 드는 시간은 줄지 않기 때문입니다. 세션당 10페이지라면 500페이지 사이트에는 51개 세션과 약 25시간이 필요합니다. 첫 글의 넉넉한 용량인 세션당 100페이지라면 6개 세션으로 충분하지만, 여전히 약 10시간이 걸립니다.

이 시간에는 3가지가 빠져 있습니다. 어시스턴트가 작업하는 시간, 수정 작업 자체, 그리고 첫 번째 결과를 검증하기 위한 두 번째 훑기입니다.

21개 세션을 합쳐도 하나의 감사가 되지 않는 이유

시간은 눈에 보이고 예산을 세울 수 있습니다. 편차는 보기 어렵고, 바로 이것이 합쳐진 결과를 믿을 수 없게 만듭니다.

각 세션은 다른 세션의 발견 사항 없이 시작합니다. 세션 14는 세션 3이 블로그 템플릿에서 같은 canonical 태그 누락을 이미 찾았다는 사실을 모릅니다. 그래서 새로운 문제처럼 다시 보고하거나, 180개 페이지에 걸친 템플릿 문제를 페이지 하나에 대한 메모로 처리합니다. 프로젝트 파일과 메모리 기능이 이전 메모를 이어 주어 도움이 되기는 하지만, 메모는 결론일 뿐입니다. 메모가 있다고 세션 14가 세션 3의 기준을 그대로 적용하지는 않습니다.

각 세션은 무엇을 볼지 스스로 정합니다. 여러 페이지를 검토하라고 하면 어시스턴트는 각 페이지에서 어떤 신호를 확인할지 직접 고릅니다. 어떤 세션은 구조화된 데이터를 읽고, 다른 세션은 페이지가 괜찮아 보인다며 건너뜁니다. 결국 어떤 페이지를 열었는지는 알 수 있어도, 어떤 페이지에서 어떤 검사가 실행되었는지는 알 수 없습니다.

각 세션은 판정을 다르게 표현합니다. "Missing canonical", "no rel=canonical link", "canonical tag absent"는 하나의 발견 사항을 3가지로 쓴 것입니다. 심각도도 흔들립니다. 같은 문제가 한 세션에서는 "critical", 다음 세션에서는 "minor"가 됩니다. 우선순위를 정하는 숫자, 즉 같은 문제를 공유하는 페이지 수는 모든 줄을 손으로 정규화한 뒤에야 나옵니다.

페이지 사이의 문제는 세션 사이로 빠져나갑니다. SEOReport가 2026년 5월부터 10월까지 감사한 같은 외부 웹사이트 45개 중 32개(71%)에는 어떤 단일 URL에서도 보이지 않는 문제가 하나 이상 있었습니다. 이런 문제는 사이트맵을 거기 나열된 페이지와 비교하거나, 페이지끼리 비교하거나, 글 라이브러리 전체를 함께 읽을 때만 드러납니다. 사이트를 25개씩 묶음으로 나누면 바로 그 비교가 끊깁니다. 거의 중복인 글 두 편이 세션 4와 세션 19에서 따로 검토되면 서로 만날 일이 없습니다. 사용자가 선택한 표준이 없는 중복 페이지의 원인이 되는 중복 페이지가 페이지 단위 검토를 빠져나가는 한 가지 경로가 이것입니다.

다음 달에 반복할 수 없습니다. 같은 질문을 두 번 해도 답이 다른 표현으로 돌아올 수 있고, 가끔은 판정 자체가 달라집니다. 12월에 21개 세션을 다시 실행해 문제가 더 적게 나왔다면, 사이트가 개선된 것인지 세션의 판단이 바뀐 것인지 구분할 수 없습니다. 고정된 방법이 없으면 비교할 기준선도 없습니다.

flowchart TD
    subgraph many["여러 채팅 세션"]
        A["다음 25페이지 선택"] --> B["새 세션: 방법을 다시 설명"]
        B --> C["세션이 스스로 고른 항목을 자기 표현으로 검사"]
        C --> D["발견 사항을 메모에 복사"]
        D --> E{"남은 페이지가 있는가?"}
        E -->|"예"| A
        E -->|"아니요"| F["메모 21세트를 손으로 병합"]
        F --> G["다음 달에 반복할 기록 없음"]
    end
    subgraph one["한 번의 감사, 그다음 발견 사항별 AI"]
        H["한 번의 감사: 매번 같은 방법"] --> I["증거가 포함된 발견 사항 목록"]
        I --> J["발견 사항마다 AI 세션 하나"]
        J --> K["같은 방법으로 후속 감사"]
        K -->|"아직 해결되지 않은 발견 사항"| J
    end

한 번의 감사가 바꾸는 것과 바꾸지 않는 것

감사도 표본을 사용합니다. SEOReport의 전체 진단은 홈페이지, 사이트맵에 나열된 페이지, 내부 링크가 가리키는 페이지를 검사합니다. 모든 페이지를 읽지는 않으며, 표본에서 나온 발견 사항에는 검사한 페이지 수가 명시되므로 모든 결과의 범위가 기록에 남습니다.

바뀌는 것은 방법입니다. 모든 진단은 정해진 같은 검사 항목을 같은 방식으로 실행하고 각 항목의 증거를 기록하므로, 같은 사이트에 대한 두 보고서를 발견 사항 단위로 비교할 수 있습니다. 채팅 세션 사이로 빠져나가던 비교는 한 번의 실행 안에서 이루어집니다. 사이트맵 항목과 그 항목이 가리키는 페이지 사이의 모순, 존재하지 않는 페이지로 가는 내부 링크, 거의 중복인 글, 서로 맞지 않는 글 날짜, 어디서도 링크되지 않는 페이지 등이 그렇습니다. 결과물은 하나의 목록입니다. 증거와 영향받는 URL이 포함된 발견 사항, 검증 단계가 포함된 우선순위별 수정 계획, 그리고 PDF, Markdown, JSON 내보내기입니다. 그 구조는 점수가 매겨진 SEO 보고서에 담긴 내용에서 자세히 설명합니다.

AI가 맡는 일의 크기도 바뀝니다. SEOReport가 2026년 8월 23일부터 10월 4일까지 감사한 외부 웹사이트 249개에서 보고서 중앙값은 서로 다른 문제(실패 또는 경고 발견 사항) 14건을 표시했고, 사이트의 4분의 1은 17건 이상이었습니다. 문제 하나가 여러 페이지에 영향을 줄 수 있지만, 여전히 명확하게 정의된 작업 하나입니다. 증거가 첨부된 약 14건의 작업 목록은 범위가 열려 있는 탐색 세션 21개와는 전혀 다른 과제입니다.

감사가 하지 않는 일은 판단을 대신하거나 수정 내용을 작성하는 것입니다. 바로 그 지점에서 AI 세션이 제 몫을 하며, 이는 AI 스팟 체크에 관한 이전 글이 반대 방향에서 짚은 내용이기도 합니다.

대규모 사이트에서 AI 세션을 잘 활용하는 방법

세션에 사이트가 아니라 발견 사항을 주십시오. 각 세션을 발견 사항 하나와 그 증거, 영향받는 URL로 시작하십시오. AI 에이전트용 페이지에서 설명하듯 에이전트가 REST API나 MCP 서버를 통해 직접 보고서를 생성하고 모든 발견 사항을 읽을 수도 있습니다. 그러면 에이전트는 사이트를 처음부터 다시 탐색하는 대신 진단에서 작업을 시작합니다.

세션 하나에 수정 하나를 맡기십시오. 범위가 좁은 작업은 세션의 주의를 원인 하나에 묶어 두고, 답변을 검토하기도 쉽게 만듭니다. 다음과 같은 형태의 프롬프트가 잘 작동합니다.

Finding: XML sitemap lists URLs that redirect.
Evidence: https://www.example.com/old-pricing -> 301 -> https://www.example.com/pricing
          https://www.example.com/team -> 301 -> https://www.example.com/about
Platform: [your CMS, sitemap generator and hosting]
Task: Explain the most likely reason the sitemap still lists these URLs on this
platform, and give the smallest change that makes it list only final URLs.
Address this finding only.

탐색에 채팅을 꼭 써야 한다면 방법부터 문서로 정하십시오. 모든 세션 시작 시 같은 체크리스트를 붙여넣고, 세션마다 고정된 페이지 목록을 배정하고, 출력 형식을 하나로 정하십시오. URL, 검사 항목, 관찰값, 판정으로 이루어진 표가 좋습니다. 그러면 병합은 기계적인 작업이 됩니다. 이렇게 하면 표현과 검사 범위의 편차는 줄어들지만, 페이지 사이에서만 드러나는 문제를 되찾지는 못합니다.

후속 감사와 Google로 검증하십시오. Search Console이 보고하는 문제라면 먼저 영향받는 URL을 모두 수정한 다음, 그중 하나에 URL 검사의 "라이브 URL 테스트"를 실행해 Google이 변경된 페이지를 가져올 수 있는지 확인하십시오. 라이브 테스트는 중복이나 canonical 결정은 확인하지 않으므로, 그런 문제에서는 접근 가능 여부만 확인됩니다. 그다음 해당 문제에서 "수정 결과 확인"을 클릭하십시오. Google의 페이지 색인 생성 보고서 문서(2026년 10월 확인)에 따르면 수정 결과 확인에는 일반적으로 최대 2주 정도가 걸리며, 경우에 따라 훨씬 더 오래 걸립니다. 후속 보고서나 지속적인 SEO 모니터링에서 설명하는 API를 통한 주간 모니터링을 사용하면, 발견 사항을 찾아낸 바로 그 방법으로 해당 사항이 해결되었는지 확인할 수 있습니다.

소규모 사이트라면 사정이 훨씬 낫습니다. 모델에서 20페이지 사이트는 2개 세션, 약 1시간이면 되고, 페이지 하나에 관한 질문이라면 감사가 전혀 필요 없습니다. 사이트가 커질수록 비용이 커지고, 반복 가능한 방법의 가치도 함께 커집니다.

자주 묻는 질문

웹 브라우징 기능이 있는 어시스턴트라면 혼자서 사이트 전체를 감사할 수 있습니까?

브라우징을 쓰면 붙여넣기가 사라지므로 모델의 페이지당 1분은 줄어듭니다. 하지만 어시스턴트는 여전히 페이지를 하나씩 열고, 어떤 페이지를 열지 스스로 고르며, 헤더가 포함된 전체 응답 대신 변환된 페이지 텍스트를 받는 경우가 많습니다. 도구의 동작은 어시스턴트마다 다르며, 어느 것도 다음 달에 똑같이 실행되는 고정된 방법을 제공하지 않습니다.

컨텍스트 창이 더 크면 문제가 사라집니까?

세션당 페이지 수가 늘어나므로 세션 수는 줄어듭니다. 모델에서 세션당 100페이지로 잡아도 500페이지 사이트에는 여전히 6개 세션과 약 10시간이 필요합니다. 페이지 하나를 다루는 데 드는 시간은 같기 때문입니다. 또한 실행 간 편차는 그대로 남습니다.

세션당 25페이지는 현실적인 수치입니까?

이는 텍스트뿐 아니라 헤더, head 태그, 구조화된 데이터까지 읽는 세션을 기준으로 정한 가정입니다. 귀하의 페이지에 맞게 바꾸어 다음 식을 사용하십시오. 세션 수 = 페이지 수 ÷ 세션당 페이지 수(올림) + 1. 편차에 관한 결론은 이 수치와 관계없이 성립합니다.

채팅 기록을 감사 기록으로 보관해야 합니까?

작업 메모로 보관하십시오. 채팅 기록에는 세션이 내린 결론이 남지만, 그 시점의 상태 코드와 헤더 값 같은 원본 증거는 대개 빠져 있습니다. 발견 사항마다 증거를 함께 저장하는 기록이 있어야 나중에 누군가 판정을 검증하고 다음 감사와 비교할 수 있습니다.