LLM을 위한 자바스크립트 디버깅 ①: 크롬 개발자 도구로 AI 가시성 점검하기

AI 검색이 새로운 유입 경로로 자리 잡으면서, 검색 최적화 실무자의 질문도 달라지고 있습니다. “구글이 우리 페이지를 잘 읽는가”를 넘어 “챗GPT나 클로드 같은 AI는 우리 페이지에서 무엇을 가져가는가”를 따져야 하는 때가 된 것이죠. 지난 9월 3일과 4일 서울 마포에서 열린 ‘Search SEOul(서치 서울) 2026’은 이런 고민을 국내외 SEO·GEO 실무자가 함께 나눈 자리였습니다. 올해 2회째를 맞은 서치 서울은 해외에서 주로 열리던 글로벌 SEO 컨퍼런스를 한국에서 열고, 한국 검색 환경과 해외 SEO·GEO 흐름을 잇겠다는 취지로 시작된 행사입니다.

요즘IT는 서치 서울 2026의 공식 미디어 파트너로서, 행사 발표 가운데 요즘IT 독자에게 도움이 될 만한 내용을 골라 전문을 소개하고 있습니다. 이번 글은 행사 첫날 오후, 테크니컬 SEO·애널리틱스 컨설턴트 조너선 무어(Jonathan Moore)가 ‘Seoul Searching: Debugging JavaScript for LLMs’라는 제목으로 발표한 내용입니다. 사용자가 보는 페이지와 LLM이 받아 가는 페이지 사이의 간극을 크롬 개발자 도구로 직접 찾아내는 방법을 다룹니다. 발표 분량이 많아 두 편으로 나눠 싣습니다. 이번 1회에는 문제의 배경과 디버깅 원칙, 크롬 개발자 도구 세팅과 텍스트 검색까지 담았습니다. 영어로 진행된 발표를 한국어로 옮겼고, 발표에 쓰인 코드 예시는 발표자가 공개한 저장소(글 말미 링크)에서 받아 볼 수 있습니다.

참고로 발표는 9월 초에 진행됐고, 이 글은 10월에 공개합니다. AI 서비스는 업데이트가 잦은 만큼, 글에 나오는 각 AI 시스템의 자바스크립트 렌더링 여부는 지금 시점과 다를 수 있습니다.

안녕하세요. 저는 테크니컬 SEO·애널리틱스 컨설턴트 조너선 무어입니다. 오늘은 디버깅 이야기를 하려고 합니다. 시작하기 전에 먼저 사과부터 드려야겠네요. 제가 영국인이라서요. 썰렁한 농담이 나오더라도 통역을 거치면서 조금이나마 살아나길 바랍니다. 커피 브레이크 직전 마지막 발표이기도 하니, 최대한 요점 위주로 가 보겠습니다.

구글은 괜찮다던 자바스크립트, AI는 다릅니다

이야기의 틀부터 잡아 볼게요. 저는 유럽에서 일하고 있어서 주로 구글을 상대로 일합니다. 그런데 꽤 오랫동안 구글에 “자바스크립트 신경 써야 하나요?” 하고 물으면, 구글 담당자들은 대체로 이렇게 답했습니다. “아니요, 괜찮습니다. 저희가 처리할 수 있어요. 크롤링도 잘하고, 색인도 잘하고, 렌더링도 잘하니까 크게 걱정하지 않으셔도 됩니다.” 그래서 우리는 이런 문제를 어느새 신경 쓰지 않게 됐죠.

문제는 여기서부터입니다. 구글은 자바스크립트를 정말 잘 처리합니다. 하지만 LLM은 그렇지 않을 수 있어요. 이게 지금 우리가 마주한 과제입니다.

구글이 몇 년 동안 소개해 온 렌더링 파이프라인은 다들 익숙하실 거예요. 구글 시스템이 어떻게 작동하는지 보여 주는 좋은 예시지만, 대규모 언어 모델(LLM)에 맞춰 최적화하는 지금의 상황에 그대로 들어맞는 건 아닙니다. 그래서 어떤 AI 시스템이 자바스크립트를 렌더링하고 어떤 시스템은 하지 않는지를 알아야 합니다. AI가 페이지에서 정보를 뽑아 답변을 합성하는 방식에 큰 문제가 될 수 있기 때문이에요.

다행히 누군가 이미 이 부분을 조사해 줘서 제가 직접 할 필요는 없었습니다. 안드레 알파(Andre Alpar)가 AI 어시스턴트가 답변 근거를 찾을 때 실제로 자바스크립트를 렌더링하는지 테스트한 결과입니다.

결과를 보면 서구권 모델들은 대체로 지금 자바스크립트를 렌더링하지 않는 것으로 보입니다. 이런 모델을 쓰고 있다면 꽤 곤란한 일이죠. 위쪽에는 자바스크립트를 렌더링하는 모델이 있습니다. 딥시크(DeepSeek), 큐원(Qwen), 키미(Kimi), 미스트랄(Mistral)은 모두 자바스크립트를 렌더링해요. 아래쪽의 챗GPT, 클로드, 제미나이 등은 렌더링하지 않습니다. 문제가 될 수 있으니 좀 더 자세히 들여다봐야 합니다.

문제는 자바스크립트가 아니라 ‘실패 지점’입니다

제 생각에 문제가 꼭 자바스크립트 자체에 있는 건 아닙니다. 자바스크립트는 인터넷의 큰 부분을 차지하고 있고, 앞으로도 그랬으면 좋겠어요. 웹사이트에 상호작용을 더해 주는 훌륭한 도구니까요. 다만 자바스크립트가 실패 지점(point of failure)이 된다는 게 문제입니다. 젠가 탑을 떠올려 보세요. 블록 하나를 잘못 빼면 탑 전체가 무너집니다.

제 디버깅의 핵심 개념은 두 가지입니다. 먼저 소스 보기(View Source)입니다. 다들 아실 텐데, 서버가 처음 브라우저로 보내는 코드, 즉 원본 HTML(raw HTML)을 말합니다.

다음은 DOM입니다. 브라우저에서 자바스크립트가 실행된 뒤의 HTML, 그러니까 브라우저가 지금 이 페이지를 어떻게 표현하고 있는지를 나타냅니다. 우리가 이해하려는 기본 개념이 바로 이 둘이에요.

렌더링 방식에는 여러 가지가 있고, 정답도 오답도 없습니다. 페이지가 얼마나 자주 바뀌는지, 어떤 콘텐츠를 담는지 등에 따라 렌더링 전략은 달라져야 해요. 어느 쪽도 틀리지 않지만, 각 방식이 어떻게 작동하는지 알아야 맞는 방식을 고를 수 있습니다.

가장 기본은 서버 사이드 렌더링(SSR)입니다. 모든 것이 서버에서 완전히 렌더링된 채로 넘어오고, 소스 코드에 들어 있습니다. 페이지 제목, 메타 디스크립션, H1 같은 요소가 서버에서 바로 받아집니다.

문제가 생기기 쉬운 쪽은 클라이언트 사이드 렌더링(CSR)입니다. 서버는 HTML 뼈대(shell)만 보내고, 브라우저가 자바스크립트를 실행해야 합니다. 자바스크립트가 실행되면서 페이지를 하이드레이션(hydration)하고 콘텐츠를 채워 넣는 방식이죠.

기초 수준에서 정리하면, 이 두 방식의 차이가 우리가 주의해야 할 부분입니다. 우리가 길러야 할 기술은 어디까지가 서버에서 렌더링되고 어디부터 그렇지 않은지, 즉 실패 지점을 찾아내는 능력입니다.

원인부터 찾는다: 제 디버깅 원칙과 흐름

제가 일하는 방식, 일종의 철학부터 말씀드릴게요. 첫째, 근본 원인을 찾습니다. 어떤 이슈든 근본 원인을 파악하는 게 가장 중요하다고 생각해요. 문제에서 거꾸로 거슬러 올라가 해결책을 찾는 겁니다. 둘째, 이슈를 쏟아 내듯 나열하지 않습니다. 발견한 문제를 잔뜩 늘어놓는 대신 뿌리를 찾는 것, 저는 이게 핵심이라고 봅니다.

제가 주로 쓰는 방법은 직접 눈으로 보는 겁니다. 브라우저에 들어가서 하나하나 확인하죠. 제 디버깅 흐름은 이렇습니다.

• 서버가 무엇을 보내는지 확인한다
• 브라우저가 무엇을 만드는지 비교한다
• 의존 관계를 분리한다
• 콘텐츠가 어디서 오는지 추적한다
• 여러 사용자 에이전트로 테스트한다

지금부터 브라우저 안에서 이 각각을 어떻게 확인하는지 보여 드리겠습니다. 그리고 두 번째 사과를 드립니다. 저는 윈도우를 씁니다. 맥을 쓰신다면 단축키는 알아서 바꿔 생각해 주세요.

크롬 개발자 도구부터 디버깅용으로 세팅하세요

디버깅이나 SEO 작업에 관심 있는 분께 제가 가장 먼저 권하는 건 디버깅 전용 크롬 프로필을 만드는 것입니다. 크롬에서는 이메일마다 프로필을 따로 둘 수 있고, 꼭 이메일이 없어도 프로필을 만들 수 있어요. 프로필마다 확장 프로그램과 설정을 다르게 둘 수 있으니, 프로필만 바꾸면 바로 디버깅할 준비가 됩니다. 제 최고의 조언이 바로 이겁니다.

프로필에 들어가면 저는 네트워크 탭부터 설정합니다. 맞춤 설정할 수 있는 항목이 많거든요. 작은 톱니바퀴 아이콘을 누르면 요청 행을 크게 보는 옵션(Big request rows), 스크린샷 옵션 등을 켤 수 있습니다. 페이지를 오가며 볼 때는 로그 유지(Preserve log)도 켜고, 캐시 비활성화(Disable cache)도 기본으로 켜 두는 편인데, 이건 다른 종류의 디버깅에 더 쓰입니다. 옵션이 정말 많으니 한번 살펴보세요.

다음으로 네트워크 탭의 열(헤더)을 맞춤 설정합니다. 켜고 끄기도 쉬워서 아주 유용해요. 저는 기본으로 URL, 도메인, 메서드를 추가하고, 성능 최적화 작업을 할 때는 우선순위(Priority)도 추가합니다. 원치 않는 열을 켰다가 되돌리고 싶을 때는 마우스 오른쪽 버튼으로 열 설정을 다시 바꾸면 됩니다.

세팅을 마쳤으면 요소(Elements) 패널을 엽니다. 단축키는 Ctrl + Shift + C입니다. DOM으로 바로 들어가는 길이죠.

소스 보기는 Ctrl + U로 열 수 있는데, 저는 분석이나 디버깅에 소스 보기를 잘 쓰지 않습니다. 큰 페이지에서는 브라우저가 그냥 죽어 버리거든요. 적어도 제 컴퓨터에서는 그렇습니다. 오래된 컴퓨터인데 바꿀 형편이 안 돼서요.

그래서 저는 소스(Sources) 패널에서 원본 HTML을 봅니다. 서버에서 받아 온 실제 HTML을 보려면 여기가 제 출발점이에요. 정리하면 DOM은 요소 패널에서, 원본 HTML은 소스 패널에서 봅니다.

크롬 개발자 도구에는 명령어 메뉴도 있습니다. 개발자 도구를 연 상태에서 Ctrl + Shift + P를 누르면 명령어 서랍이 열립니다. 쓸 수 있는 명령이 아주 많은데, 자주 쓰는 것 중 하나가 스크린샷이에요. 크롬 안에서 뷰포트 크기를 정해 전체 페이지 스크린샷을 찍을 수 있습니다. 디버깅에 특화된 기능도 여럿 있으니 전체 명령어 목록을 한번 확인해 보세요.

오늘 주제가 자바스크립트이니, 먼저 자바스크립트를 끄고 켜는 방법부터 보겠습니다. 명령어 메뉴에 ‘Disable JavaScript’를 입력하고 새로고침하면 브라우저에서 자바스크립트가 꺼집니다. 자바스크립트 없이도 페이지가 돌아가는지 확인하는 가장 단순한 방법이에요. 단점은 다시 켜는 걸 기억해야 한다는 겁니다. ‘Enable’을 입력해 다시 켜야 해서 조금 번거롭지만, 확장 프로그램을 따로 쓸 필요 없이 명령어로 바로 처리할 수 있어 시간을 아낄 수 있습니다.

텍스트 검색으로 서버 응답과 DOM 비교하기

이제 텍스트를 검색해 보겠습니다. 텍스트 문자열 검색은 우리가 하는 가장 기본적인 작업일 거예요. 요소 패널에서 Ctrl + F를 누르면 원하는 텍스트를 찾을 수 있습니다. DOM에서 보이는 텍스트가 소스 패널에도 있는지 확인하는 것, 이게 변화를 찾아내는 가장 기본적인 방법입니다.

요소 패널의 좋은 점은 페이지에서 텍스트를 드래그한 뒤 마우스 오른쪽 버튼을 눌러 ‘검사’를 선택하면 해당 DOM 노드로 바로 이동한다는 겁니다. 하이라이트까지 해 줘서 편리하죠.

요소 패널에서 정말 강력한 기능은 XPath 표현식을 쓸 수 있다는 점입니다. AND, OR 조건을 걸 수 있고, 부정(negation) 조건도 쓸 수 있어요. 예를 들어 페이지를 하이드레이션하는 데 쓰이는 JSON 텍스트 덩어리를 XPath로 찾을 수 있습니다. LLM이 관심을 가질 만한 정보를 바로 찾아낸 뒤, 그게 소스 보기에도 있는지 확인하는 거죠. XPath로 할 수 있는 영리한 작업은 정말 많습니다.

선택한 노드는 $0으로 참조할 수 있습니다. Esc를 눌러 콘솔 서랍을 열고 아래 코드를 넣으면, 선택한 JSON 덩어리를 보기 좋게 정리해 줍니다.

console.log(JSON.stringify(JSON.parse($0.textContent), null, 2))

이걸 복사해서 원하는 LLM에 넣고 추가로 분석할 수 있습니다. 필요한 부분만 떼어 내 클립보드나 텍스트 파일로 저장하기에도 좋은 방법이에요.

제가 즐겨 쓰는 또 하나는 로드된 모든 텍스트를 검색하는 Ctrl + Shift + F입니다. XPath 검색과 달리 여기서는 정규표현식 검색을 쓸 수 있어요. 특정 자바스크립트 라이브러리를 불러오는 데 쓰일 법한 자바스크립트 구문을 정규표현식으로 검색하면, 페이지를 빠르게 훑으면서 차단 요인이나 근본 원인 후보를 찾아낼 수 있습니다.

마지막으로 개별 네트워크 요청 안을 검색할 수 있습니다. 서버에서 바로 받아 온 것을 골라내는 데 유용해요. 네트워크 탭에서 Ctrl + F를 누르면 네트워크 요청 안에서 텍스트를 바로 찾을 수 있고, DOM에 있는 것과 소스에 있는 것, 그리고 그 텍스트가 어느 파일에서 왔는지를 비교할 수 있습니다.

정리하면, 용도에 따라 검색 위치가 다르고 매칭 방식도 다릅니다. 일반 텍스트 검색, XPath, 정규표현식이 그것이죠. 이 검색들을 이것저것 써 보다 보면 건초 더미에서 바늘을 찾는 데 꽤 가까워질 겁니다.

지금까지 LLM이 자바스크립트를 렌더링하지 않을 때 무엇이 문제가 되는지, 그리고 크롬 개발자 도구를 디버깅용으로 세팅해 서버가 보낸 원본 HTML과 브라우저가 만든 DOM을 텍스트 검색으로 비교하는 방법을 살펴봤습니다. 조너선 무어가 소개한 디버깅 흐름 다섯 단계 가운데 앞의 두 단계, ‘서버가 무엇을 보내는지 확인하고 브라우저가 무엇을 만드는지 비교하기’에 해당합니다.

이어지는 2회에서는 나머지 세 단계를 다룹니다. 네트워크 요청을 걸러내고 차단해 페이지를 무너뜨리는 ‘범인 파일’을 찾는 법, 사용자 에이전트를 바꿔 AI처럼 접속해 보는 법, 반복 확인을 스니펫과 AI 어시스턴스 기능에 맡기는 법을 소개합니다. 이어서 이 도구들을 엮어 사이트를 감사하는 순서와 크롤러로 점검 규모를 키우는 방법까지 정리합니다.

▶ 발표 코드 예시 저장소(깃허브) 보기

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.