브라우저 화면에는 제품 설명, FAQ, 고객 질문, 리뷰가 모두 보이는데 페이지 소스에는 제목과 빈 컨테이너만 남는 경우가 있습니다. 이때 팀이 먼저 답해야 할 질문은 “어떤 AI가 자바스크립트를 실행하는가”가 아닙니다. 서버가 처음 반환한 HTML만으로도 이 페이지의 핵심 내용이 전달되는가입니다.
LLM이나 다른 수집 주체가 브라우저에서 보이는 최종 화면과 다른 형태의 페이지를 받을 가능성은 점검 대상입니다. 따라서 특정 사용자 에이전트를 흉내 내는 테스트만으로 접근성을 판단하기보다, 초기 HTML과 자바스크립트 실행 뒤 DOM을 비교하고 콘텐츠가 사라지는 의존 지점을 찾아야 합니다.
이 글의 목적은 모든 페이지를 같은 렌더링 방식으로 바꾸자는 제안이 아닙니다. 공개 페이지에서 무엇을 초기 HTML에 남길지 정하고, 그 결과를 바탕으로 SSR, 프리렌더링, 클라이언트 렌더링 중 어느 영역을 보완할지 결정하는 데 있습니다.
실패는 화면이 아니라 전달 경로의 빈칸에서 드러난다
사용자는 브라우저가 자바스크립트를 실행한 뒤 완성한 화면을 봅니다. 개발자 도구의 요소 패널도 보통 그 상태를 보여 줍니다. 반면 페이지 소스 보기나 문서 응답은 서버가 처음 보낸 HTML에 가까운 내용을 확인하는 수단입니다.
두 결과가 다르다고 해서 곧바로 오류라고 볼 수는 없습니다. 상호작용을 위해 브라우저에서 만들어지는 요소도 있기 때문입니다. 다만 다음 정보가 렌더링 뒤에만 나타난다면 우선순위를 높여 조사할 이유가 생깁니다.
- 페이지가 무엇을 설명하는지 보여 주는 본문 문장
- 제품·서비스의 조건, 사양, 가격 등 판단에 필요한 정보
- FAQ, Q&A, 리뷰처럼 사용자의 신뢰 판단을 돕는 내용
- 다른 페이지를 발견하는 데 필요한 본문 링크와 탐색 요소
- 제목, 설명, 정규 URL, 구조화 데이터 등 문서 의미를 보완하는 항목
여기서 확인하려는 것은 태그 개수가 아닙니다. 초기 HTML에 페이지의 주장과 근거가 어느 정도 남아 있는지를 보는 일입니다. 제목만 있고 설명·조건·관련 링크가 모두 렌더링 이후에 나타난다면, 문서의 주제는 전달돼도 내용은 충분히 전달되지 않을 수 있습니다.
조기 신호는 비교적 구체적입니다. 화면에서 선택한 핵심 문장을 원본 HTML에서 찾을 수 없는 경우, 렌더링 전후 링크 구성이 달라지는 경우, 구조화 데이터나 메타 태그가 한쪽에만 존재하는 경우가 여기에 해당합니다. 이 결과는 즉시 해결책을 정하는 답이 아니라, 자바스크립트 성공 여부에 묶인 콘텐츠를 찾는 출발점입니다.
요청 하나를 막아 보면 콘텐츠의 의존 관계가 보인다
화면과 원본 HTML의 차이를 확인했다면, 다음 단계는 어느 요청이 콘텐츠를 만들거나 불러오는지 좁히는 일입니다. 개발자 도구 네트워크 탭에서 문서 요청, Fetch/XHR 요청, 자바스크립트 파일을 구분하면 조사 범위를 줄일 수 있습니다. 자사 도메인 요청과 외부 도메인 요청을 나눠 보는 것도 도움이 됩니다.
이후 핵심 데이터와 관련 있어 보이는 요청이나 파일을 제한하고 새로고침했을 때, 어느 영역이 사라지는지 관찰합니다. 발표 자료에서는 GraphQL 요청을 막았을 때 페이지의 콘텐츠가 무너지는 사례가 제시됐습니다. 이런 방식의 테스트는 파일 하나가 페이지 하이드레이션이나 콘텐츠 구성에 얼마나 큰 역할을 하는지 확인하는 데 쓸 수 있습니다.
관찰 결과는 보완 대상을 나누는 근거가 됩니다.
-
특정 요청이 실패해도 제목, 주요 본문, 핵심 링크가 남는 경우
해당 요청은 페이지의 핵심 전달보다 부가 기능이나 보조 요소와 연결됐을 수 있습니다. -
데이터 요청 하나가 실패했을 때 제품 설명, 서비스 소개, FAQ까지 함께 사라지는 경우
핵심 콘텐츠가 브라우저 측 요청과 렌더링에 강하게 묶여 있는지 조사해야 합니다. -
외부 서비스 요청이 실패했을 때 리뷰, Q&A, 배송 관련 정보 등만 사라지는 경우
외부 연동이 담당하는 정보가 사용자 판단에 어느 정도 중요한지 제품·콘텐츠 책임자와 먼저 정할 필요가 있습니다. -
전역 스크립트나 공통 요청을 막았을 때 여러 템플릿에서 탐색 요소가 동시에 사라지는 경우
개별 페이지 문제가 아니라 전역 레이아웃 또는 공통 컴포넌트 문제일 수 있습니다.
요청의 이니시에이터 체인도 함께 봐야 합니다. HTML이 어떤 파일을 불러왔고, 그 파일이 어떤 요청을 이어서 발생시켰는지 추적하면 수정 책임을 좁힐 수 있습니다. 콘텐츠 API 호출이 특정 상세 페이지 템플릿에만 있는지, 전역 레이아웃에서 시작되는지, 외부 스크립트가 출발점인지에 따라 배포 범위가 달라집니다.
SSR·프리렌더링·클라이언트 렌더링은 기능 이름보다 콘텐츠 책임으로 고른다
SSR, 프리렌더링, 클라이언트 렌더링은 하나를 전면 채택하거나 폐기하는 선택지로 다루기 쉽습니다. 그러나 운영 중인 서비스에서는 “어떤 렌더링 기술이 최고인가”보다 “어떤 콘텐츠를 초기 HTML에서 보장할 것인가”가 먼저입니다.
아래 질문으로 보완 범위를 나눠 볼 수 있습니다.
| 확인 질문 | 검토 방향 |
|---|---|
| 이 문장이 없으면 비로그인 방문자가 페이지 목적을 이해하기 어려운가 | 초기 HTML 제공 후보로 분류 |
| 이 링크가 없으면 관련 페이지를 발견하기 어려운가 | 초기 HTML 또는 공통 탐색 구조에서 확인 |
| FAQ, Q&A, 리뷰가 구매·신청·문의 판단에 중요한가 | 외부 요청 실패 시 공백이 생기는지 점검 |
| 화면 조작 뒤에만 의미가 생기는 정보인가 | 초기 HTML 제공 우선순위를 별도로 판단 |
| 데이터 요청 실패 때 페이지의 핵심 설명까지 사라지는가 | SSR 또는 프리렌더링을 포함한 구현 보완 검토 |
이 표는 각 기술의 작동 방식이나 비용을 일반화하지 않습니다. 프레임워크와 배포 구조에 따라 SSR과 프리렌더링의 구현 조건은 달라질 수 있기 때문입니다. 다만 초기 HTML에 남겨야 할 콘텐츠를 먼저 합의하면, 기술팀은 전체 전환이 필요한지, 특정 템플릿만 보완하면 되는지, 핵심 본문과 상호작용 영역을 분리할 수 있는지를 더 정확히 검토할 수 있습니다.
결정 문서에는 “SSR 적용”처럼 기술 이름만 적지 않는 편이 좋습니다. 대신 “상세 페이지의 제품 설명과 주요 링크는 최초 문서 응답에서 확인 가능해야 한다”처럼 검증 가능한 결과를 적어야 합니다. 그래야 배포 후에도 같은 기준으로 확인할 수 있습니다.
사용자 에이전트 변경은 차단 규칙을 찾는 보조 테스트다
개발자 도구에서 사용자 에이전트를 바꾸면, 서버가 요청 주체에 따라 다른 응답을 주는지 확인할 수 있습니다. 이 테스트는 특정 요청이 차단되는지, 리디렉션이 달라지는지, 응답 내용이 달라지는지를 조사하는 데 유용합니다.
하지만 사용자 에이전트 문자열을 바꿨다고 특정 AI 서비스의 수집 과정 전체를 재현했다고 보기는 어렵습니다. 사용자 에이전트 테스트만으로 특정 AI가 페이지를 읽거나 읽지 못한다고 단정하면, 서버 분기 문제와 렌더링 의존 문제를 혼동할 수 있습니다.
운영 기록에서는 두 결과를 분리하는 편이 낫습니다.
- 일반 요청에서 받은 최초 HTML에 핵심 콘텐츠가 포함되는가
- 특정 사용자 에이전트나 요청 조건에서 상태 코드, 리디렉션, 응답 콘텐츠가 달라지는가
첫 번째는 콘텐츠 전달 구조에 관한 문제입니다. 두 번째는 접근 정책이나 서버의 조건부 응답에 관한 문제일 수 있습니다. 담당 팀과 수정 방법이 다를 수 있으므로, 하나의 “AI 크롤러 대응” 작업으로 합치지 않는 편이 좋습니다.
템플릿, 전역 요소, 외부 연동 순서로 점검 범위를 넓힌다
운영 단계에서는 URL을 하나씩 확인하기보다 대표 템플릿을 먼저 고르는 편이 효율적입니다. 공개 랜딩 페이지, 목록 페이지, 상세 페이지, 도움말·문서 페이지처럼 렌더링 방식이 다를 수 있는 유형을 골라 초기 HTML과 최종 DOM을 비교합니다.
그다음 여러 페이지에 공통으로 들어가는 내비게이션, 브레드크럼, 사이트 검색 진입점, 푸터를 봅니다. 전역 요소는 한 번의 수정으로 넓은 범위에 영향을 줄 수 있는 반면, 공통 스크립트나 요청이 실패하면 많은 페이지에서 같은 문제가 반복될 수 있습니다.
마지막으로 리뷰, Q&A, 평가 위젯처럼 외부 서비스가 공급하는 요소를 따로 점검합니다. 여기서의 질문은 외부 스크립트를 제거할지 여부가 아닙니다. 외부 요청이 실패하거나 렌더링되지 않을 때도 페이지가 제공해야 하는 핵심 설명이 남는지, 그리고 그 외부 정보가 사업상 중요한 판단 근거인지입니다.
다음 배포 전에는 대표 템플릿 하나를 골라 제품, 개발, 콘텐츠 책임자가 함께 표시해 볼 만합니다. “초기 HTML에 반드시 남아야 하는 문장·링크·태그는 무엇인가”를 먼저 적으면, 기술 선택은 추측보다 검증 결과에 가까워집니다.
