LLM을 위한 자바스크립트 디버깅 ②: 페이지를 무너뜨리는 파일 찾기부터 AI처럼 접속해 보기까지

이 글은 ‘Search SEOul(서치 서울) 2026’에서 테크니컬 SEO·애널리틱스 컨설턴트 조너선 무어(Jonathan Moore)가 ‘Seoul Searching: Debugging JavaScript for LLMs’라는 제목으로 발표한 내용을 두 편으로 나눠 소개하는 글의 두 번째 편으로, 1회에서 이어집니다. 요즘IT는 서치 서울 2026의 공식 미디어 파트너로서 행사 발표 가운데 요즘IT 독자에게 도움이 될 만한 내용을 골라 전문을 소개하고 있습니다.

1회에서 조너선 무어는 챗GPT·클로드·제미나이 같은 AI 어시스턴트가 답변 근거를 찾을 때 자바스크립트를 렌더링하지 않을 수 있다는 테스트 결과에서 출발했습니다. 그래서 서버가 처음 보내는 원본 HTML(소스 보기)과 자바스크립트가 실행된 뒤의 DOM 사이에서 ‘실패 지점’을 찾아야 한다고 짚었죠. 이어 자신의 디버깅 흐름 다섯 단계(서버가 보내는 것 확인 → 브라우저가 만드는 것과 비교 → 의존 관계 분리 → 콘텐츠 출처 추적 → 여러 사용자 에이전트로 테스트) 가운데 앞의 두 단계를 크롬 개발자 도구 세팅과 텍스트 검색으로 보여 줬습니다.

이번 2회는 나머지 세 단계입니다. 네트워크 요청을 걸러내고 막아 문제의 파일을 찾는 법부터 AI처럼 접속해 보기, 스니펫 활용, 감사 원칙, 크롤러를 이용한 확장까지 이어집니다. 영어로 진행된 발표를 한국어로 옮겼고, 코드 예시는 글 말미의 저장소 링크에서 받아 볼 수 있습니다.

➡️1화 보기:LLM을 위한 자바스크립트 디버깅 ①: 사람에게 보이는 페이지, AI에게도 보일까

요청을 걸러내고 막아서 범인 파일 찾기

그럼 문제를 어떻게 분리할까요? 네트워크 탭에는 아주 유용한 필터 단축 문법이 있습니다. 구글 검색에서 쓰는 site: 명령과 비슷해요. domain: 뒤에 와일드카드를 붙이면 원하는 도메인의 요청만 걸러 낼 수 있습니다. 예를 들어 wolves.co.uk 사이트라면 그 호스트로 필터링해서, 어떤 리소스가 자사 도메인에 있는지 서드파티에 있는지 확인할 수 있죠. 오른쪽 위의 반전(Invert) 체크박스를 켜면 필터 조건의 반대로 걸러 줍니다. 이것도 아주 유용한 팁입니다.

MIME 유형으로 필터링하는 것도 좋아합니다. Ctrl을 누른 채 클릭하면 여러 유형을 함께 고를 수 있어요. 저는 Fetch/XHR, 문서(Doc), 자바스크립트(JS)를 함께 걸러 봅니다. 찾는 걸 더 쉽게 찾게 해 주는 방법이죠.

다음은 요청 차단입니다. 네트워크 탭의 어떤 요청이든 마우스 오른쪽 버튼을 눌러 그 URL만 막을 수도 있고, 아예 도메인 전체를 막을 수도 있습니다.

명령어 메뉴로 요청 조건(Request conditions) 서랍을 열어 직접 입력해 막는 방법도 있어요.

예를 들어 저는 GraphQL 파일로 필터링했습니다. 이 파일이 페이지를 하이드레이션하는 데 쓰인다는 걸 알고 있었거든요. 이 요청을 막고 새로고침하면 페이지가 처참하게 무너집니다.

파일 하나가 페이지 전체를 하이드레이션하고 있었던 겁니다. 클로드나 챗GPT가 이 페이지를 가져가면 위 화면처럼 콘텐츠가 빠진 페이지를 보게 될 거라고 저는 꽤 확신합니다. 좋은 상황은 아니죠.

요청 이니시에이터 체인도 볼 수 있습니다. 맨 위에 HTML 파일이 있고, 그 파일이 연쇄적으로 불러오는 다른 파일들이 아래로 이어집니다. CSS, 폰트, 이미지, 그리고 엄청난 양의 자바스크립트까지요. 파일들이 서로 어떻게 연결돼 있는지 보여 주니, 사슬의 고리를 따라가며 어느 파일이 문제인지 짚어 낼 수 있습니다.

Shift를 누른 채 요청 위에 마우스를 올리면 요청 의존성 트리가 하이라이트되기도 해요. 다만 요청이 수백 개면 아주 큰 모니터가 아닌 이상 한 화면에 다 보이지 않습니다. 쓸 만하지만 약간 보여 주기용 기능이긴 한데, 소개할 가치는 있다고 생각했습니다.

AI처럼 접속해 보고, 반복 확인은 스니펫에 맡기기

이제 네트워크 조건을 보겠습니다. 이건 정말 중요해요.

네트워크 조건 서랍에서는 사용자 에이전트를 바꿀 수 있습니다. 서버가 접속하는 쪽에 따라 다른 응답을 주도록 설정돼 있을 수 있기 때문이죠. 제가 정리한 AI 사용자 에이전트 목록에서 원하는 것을 복사해 붙여 넣으면, 그 사용자 에이전트가 어떻게 동작하는지 어느 정도 흉내 낼 수 있습니다. 서버가 특정 LLM 도구를 막도록 잘못 설정돼 있는지 가늠해 볼 수 있죠. 사용자 에이전트 전환은 정말 유용하니 꼭 써 보세요.

다음은 아주 흥미로운 기능입니다. 크롬에서는 스니펫(Snippets)을 실행할 수 있는데, 이걸 아는 분이 많지 않은 것 같아요. 정말 영리한 기능입니다. 대규모 언어 모델 덕분에 저 같은 바보도 자바스크립트를 짤 수 있게 됐거든요. 보시다시피 이 코드에는 이모지가 들어 있으니 제가 짠 게 아닌 건 확실합니다.

이 스니펫은 선택한 텍스트가 원본 HTML과 렌더링된 DOM에 각각 들어 있는지 확인합니다. 만드는 데 30초쯤 걸렸어요. 챗GPT에 “이런 걸 하는 표현식을 짜 주고, 결과를 표로 정리해 주고, 이모지도 넣어 줘”라고 했더니 이걸 줬습니다. 실행할 때는 명령어 메뉴를 열고 느낌표(!)를 입력하면 저장해 둔 스니펫 목록이 나옵니다. 여기서 원하는 스니펫을 고르면 콘솔에 결과가 뜹니다.

결과를 보면 이 Q&A 텍스트는 요소 패널(DOM)에는 있지만 소스 보기에는 없습니다. “항암 치료 중에 이 제품을 써도 안전한가요?”처럼 LLM에게 중요한 텍스트가 거기 있다면, 그 내용은 LLM에게 전달되지 않는다는 뜻입니다. 좋지 않죠.

여기서부터는 정말 창의적으로 쓸 수 있습니다. 다음 스니펫에는 좀 더 영리한 일을 시켰어요. 세 가지를 확인합니다. 제목, 메타 디스크립션, 캐노니컬 같은 핵심 태그, 탐색(discovery)에 중요한 페이지에 삽입된 링크, 그리고 구조화 데이터입니다.

예시로 든 사이트는 좀 엉망이었습니다. 구조화 데이터는 전부 소스에는 있는데 DOM에는 없었어요. 제목은 DOM에는 있는데 소스에는 없었고요. 메타 디스크립션은 소스에는 있는데 DOM에는 없었는데, 이건 저도 예상하지 못한 결과였습니다. 믿으셔도 됩니다. 제가 직접 다시 확인했거든요. 이렇게 빠르게 비교할 수 있다는 점이 아주 유용합니다. 결과를 그대로 개발자에게 공유하면 이해하기 쉬워서, 이슈를 보여 주고 강조하기에도 좋습니다.

마지막으로 소개할 건 새로운 AI 어시스턴스 기능입니다. 크롬의 실험 기능이라 설정(Preferences)에서 직접 켜야 합니다. 켜고 나면 ‘Debug with AI’ 옵션이 생기는데, 네트워크 요청에서 마우스 오른쪽 버튼을 눌러 “이 요청은 무슨 일을 하나요?”라고 물으면 제미나이가 그 요청이 무엇인지 맥락과 함께 알려 줍니다. 기술을 잘 모르거나 그 웹사이트를 전혀 모르는 사람도 제미나이에 물어보면 요청의 정체를 알 수 있어요. 그러고 나서 개발자와 회의하면 꽤 아는 사람처럼 보일 수 있죠.

감사는 템플릿·전역 요소·기술 스택·서드파티 순서로

기술적인 이야기를 아주 자세히 했으니, 이제 한 걸음 물러나 이것들을 어떻게 엮을지 감사(auditing) 원칙으로 마무리하겠습니다. 저는 페이지 템플릿, 전역 요소, 기술 스택, 서드파티 연동 순으로 감사합니다. 아주 단순하죠.

페이지 템플릿은 하나씩 검토합니다. 자바스크립트를 감사하는 일은 자바스크립트를 크롤링하는 일과 마찬가지로 시간이 걸리고, 페이지를 하나하나 눈으로 보는 편이 더 쉽기 때문입니다. 시간을 아끼려고 저는 템플릿 유형별 상위 페이지를 뽑아 주는 스크립트도 씁니다. 구글 애널리틱스 등에서 데이터를 가져와 상위 카테고리, 상위 목록, 상위 상품 등을 알려 주죠. 카테고리 페이지는 모두 같은 방식으로 만들어지고 목록 페이지도 마찬가지일 테니, 이 상위 페이지부터 감사를 시작합니다.

다음으로 전역 요소를 봅니다. 모든 페이지 템플릿에 들어가는 요소라서, 이걸 고치면 웹사이트의 모든 페이지가 좋아지는 효과가 있습니다. 내비게이션, 사이트 검색, 브레드크럼이 대표적인데, 대체로 처리가 꽤 엉성한 편입니다. 리뷰 띠(review strip)도 있습니다. 들어가 있을 때도 있고 아닐 때도 있죠. 배송 정보 같은 요소와 푸터도 있습니다. 상식적으로 모든 페이지에 무엇이 있는지 파악하면 됩니다.

그다음은 기술 스택입니다. 어떤 CDN, 플랫폼, 프레임워크, 데이터, API 호출을 쓰는지가 서로 어떻게 맞물리는지 봅니다. 다만 저는 이걸 마지막 즈음에 봅니다. 앞의 두 가지가 훨씬 중요하다고 느끼거든요. 앞에서 사이트가 어떻게 돌아가는지 감을 잘 잡았다면 기술 스택을 크게 걱정할 필요는 없습니다. 내부 작동을 속속들이 이해하기보다는 눈에 보이는 차이를 설명할 수 있으면 됩니다.

마지막으로 서드파티입니다. 저는 서드파티 연동이 정말 흥미로운 부분이라고 생각합니다. 특히 이커머스에서는 외부 소스에서 불러오는 요소가 많은데, 서드파티 스크립트는 거의 확실히 서버 사이드에서 렌더링되지 않습니다.

리뷰가 대표적이죠. 리뷰가 좋든 나쁘든, 유용한 맥락을 주는 것이라면 제대로 전달되는지 꼭 확인해야 합니다. Q&A와 FAQ도 마찬가지예요. 정보의 금광이니까요. 상품 추천 같은 요소는 그보다는 덜하지만 전체가 어떻게 맞물리는지 보는 데 도움이 됩니다. 주문 처리·배송 정보는 아주 중요합니다. UGC와 소셜 프루프도 있는데, 성능 측면에서는 이미지와 서드파티 폰트 라이브러리 등을 잔뜩 불러와 페이지를 느리게 만드는 경향이 있습니다.

이렇게 나눠서 본 뒤 하나로 합치면, 전체가 어떻게 맞물리는지 큰 그림이 보입니다. 앞서 말씀드렸듯 이슈를 발견하는 족족 고치고 싶은 유혹이 들지만, 그보다 큰 그림을 보고 “이렇게 맞물려 있으니 이걸 고쳐야 효과가 난다”고 판단하는 게 중요합니다.

이를테면 이런 고전적인 ‘영향도 대 페이지 범위’ 지표로 정리할 수 있습니다. 무엇을 어떤 순서로 고쳐야 하고 그 결과 무엇을 얻을지 설명하는 거죠. 전역 요소는 더 많은 페이지에 영향을 주니 효과도 클 테고, 서드파티는 그보다 작을 수 있습니다. 이 그림은 챗GPT로 만든 거라 수치는 지어낸 것이지만, 대체로 맞는 이야기입니다.

규모를 키울 때는 크롤러로

이제 확인 작업을 규모 있게 하는 법입니다. 이런 작업에 브라우저 확장 프로그램도 나쁘지 않습니다. ‘View Rendered Source’는 나온 지 꽤 됐고 3년째 업데이트가 없는데, 저도 가끔 씁니다. 하지만 Ctrl + U를 쓸 때처럼 제 브라우저가 멈춰 버려서 자주 쓰지는 않아요.

대신 저는 크롤러를 좋아합니다. 무엇을 크롤링하고 무엇을 하지 않을지, 어떻게 렌더링할지 직접 정할 수 있어서 규모를 키우기에 좋습니다. 한국에서 얼마나 쓰이는지는 모르겠지만, 사이트벌브(Sitebulb)는 아주 강력합니다. 좋은 기능 중 하나는 클라우드에서 돌릴 수 있다는 점이에요. 설정해 두고 주 1회든 월 1회든 필요한 주기로 예약해 두면, 다시 돌아왔을 때 무엇이 바뀌었고 무엇이 그대로인지, 무엇이 크롤링됐고 무엇이 삭제됐는지 알려 줍니다.

써 보신 적이 없다면 무료 체험판도 있습니다. 돈 받고 하는 말은 아니에요. 사이트를 대규모로 크롤링하고, 요즘 하기 싫은 지루한 일들을 대신 맡기기에 가성비가 정말 좋은 방법입니다.

LLM이 받는 페이지를 보세요

마무리하겠습니다. 우리는 LLM이 무엇을 받아 가는지 알아야 합니다. 여러분이 보고 있는 페이지가 LLM이 받는 페이지와 같지 않을 수 있기 때문입니다. 가져가지 못한 콘텐츠는 보이지 않습니다.

오늘 보여 드린 코드 예시는 모두 깃허브 저장소에 올려 두었습니다. 스크린샷이 작아서 제가 무엇을 가리켰는지 잘 안 보였을 테니, 특히 뒷자리에 계셨던 분들을 위해 발표 자료도 스피커덱(Speaker Deck)에 올려 두었습니다. 깃허브 저장소에 스피커덱 링크도 함께 넣어 두겠습니다.

발표 뒤 질의응답에서는 서버 비용 부담을 고려할 때 동적 렌더링 같은 방식이 더 나은 선택이 될 수 있는지에 관한 질문이 나왔습니다. 제 답은 이렇습니다.

결국 목표에 따라 가장 좋은 렌더링 방식을 정해야 합니다. 저는 늘 비즈니스 사례와 연결해 보려고 합니다. 렌더링 전략을 바꾸는 건 꽤 큰 변화니까요. 어떤 LLM에 맞춰 최적화할지부터 정해야 합니다. 그 LLM이 자바스크립트를 렌더링할 수도 있고, 렌더링하지 않을 수도 있죠. 그렇게 결정한 다음, 렌더링 전략을 바꿨을 때 얻을 이점이 무엇인지 따져 보세요. 모든 걸 한 가지 방식으로 렌더링하면 좋겠지만, 거기에는 연산 비용이 따릅니다.

다른 우회책도 있습니다. 이미 이야기가 나왔듯, llms.txt 같은 방식을 지지하는 사람들이 있습니다. 특정 상황에서는 페이지의 마크다운 버전을 제공해서, LLM이 정보를 뽑느라 토큰을 다 쓰지 않아도 되게 하는 거죠. 클라우드플레어(Cloudflare)처럼 에이전트용 마크다운(Markdown for Agents)을 내놓은 곳도 있습니다. 엣지에서 에이전트에게 페이지의 마크다운 버전을 보여 주는 방식이에요. 렌더링 방식을 바꾸는 대신, 텍스트가 더 풍부한 다른 버전을 에이전트에게 보여 주는 또 다른 우회책입니다.

이 둘 중 어느 쪽을 권하는 건 아닙니다. 다만 각자의 기술적 과제에 맞춰 사람들이 여러 해법을 찾고 있다는 점은 흥미롭다고 생각해요. 결국 여러분의 비즈니스와 조직, 기술 스택과 예산에 무엇이 맞는지로 돌아가게 됩니다.

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

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