Claude의 web_fetch vs MCP 브라우저 도구: 네이티브 fetch가 최신 문서에서 실패하는 이유
Claude web fetch vs MCP browser tools: why native fetch fails on modern docs
핵심 요약
Claude의 기본 web_fetch가 최신 웹 문서에서 제대로 작동하지 않는 이유와 이를 해결하기 위한 MCP 브라우저 도구 및 스크래퍼 API 활용법을 분석함.
- 네이티브 fetch 한계 — 브라우저 엔진 없이 단순 HTTP GET만 수행하여 JS 기반 사이트의 콘텐츠를 읽지 못함.
- 브라우저 도구 장점 — Playwright나 Puppeteer를 통해 JS 실행 및 DOM 상호작용이 가능하지만 로컬 RAM 소모가 큼.
- 스크래퍼 API 활용 — Firecrawl 같은 도구를 사용하면 인프라에서 브라우저 렌더링을 처리하여 효율적인 데이터 추출이 가능함.
- 상호작용의 중요성 — 단순 렌더링뿐만 아니라 쿠키 배너 처리나 탭 전환 같은 사용자 상호작용이 문서 읽기에 필수적임.
Claude API랑 Claude 데스크톱에 있는 기본 web_fetch 도구, 가끔 URL 긁어올 땐 편하긴 한데, 다들 이걸 무슨 풀 헤드리스 브라우저인 줄 알고 쓰다가 코딩 세션 다 말아먹고 왜 안 되냐고 징징대는 경우가 너무 많음.
Claude에 URL 던져줬는데 그게 요즘 나오는 프레임워크 문서나 SPA(단일 페이지 애플리케이션)면, 십중팔구 "페이지가 비어 있는 것 같다"고 하거나 2023년도 데이터로 헛소리하는 걸 볼 수 있을 거임.
그래서 내가 직접 기본 web_fetch랑 외부 브라우저 MCP 도구들을 비교 테스트해 봤는데, 구조적으로 어디서 차이가 나는지 딱 정리해 줌.
I) 기본 fetch는 그냥 단순한 HTTP GET임: Claude 서버 측 web_fetch는 브라우저 엔진을 돌리는 게 아님. 그냥 초기 응답값만 긁어오는 건데, 사이트가 React, Vue, Docusaurus, Next.js 같은 걸로 만들어져서 클라이언트 사이드 하이드레이션(hydration)을 쓰면, 서버에서 보내주는 HTML은 그냥 로더 껍데기랑 스크립트 태그밖에 없음.
실제 코드 예제나 API 표 같은 건 나중에 브라우저에서 렌더링되는데, 기본 fetch는 그걸 절대 못 봄.
II) 상호작용이나 인증 처리 불가: 문서에 탭으로 나뉜 코드 블록(예: TypeScript랑 Python 전환)이 있거나, 아코디언 메뉴가 있거나, 쿠키 배너 닫아야 하는 상황이면 기본 fetch는 클릭이나 스크롤을 못 함. 그냥 처음에 긁어온 스냅샷에 보이는 것만 읽을 뿐임.
III) 브라우저 MCP 도구는 DOM 실행은 되는데 RAM을 엄청 잡아먹음: 로컬에 Playwright나 Puppeteer MCP 서버 깔면 실제 Chromium 인스턴스가 돌아가니까 JS 문제는 해결됨.
근데 Claude Code나 Cursor를 로컬에서 돌리고 있다면, 백그라운드에서 헤드리스 브라우저까지 띄우는 순간 메모리 터지고 컴퓨터 엄청 느려짐.
IV) 절충안: 에이전트 워크플로우를 위해 스크래퍼 API를 거치는 방식임. Firecrawl 같은 걸 거치는 MCP나 도구를 쓰면 양쪽 다 잡을 수 있음.
걔네 인프라에서 헤드리스 브라우저 렌더링을 돌리고, Cloudflare나 봇 차단 같은 것도 알아서 처리해 줌. 그리고 코드 블록 깔끔하게 살린 마크다운으로 넘겨주는데, 에이전트가 탭을 클릭하거나 스크롤을 해야 할 때 쓸 수 있는 /interact 엔드포인트도 제공함.
그냥 정적인 블로그 글이나 PDF 읽는 거면 기본 web_fetch로도 충분함. 근데 요즘 나오는 클라이언트 렌더링 기반 개발 문서를 Claude한테 먹이려면 JS 실행해주고 HTML 깔끔하게 털어주는 MCP나 도구가 필수임. 실험하면서 찾은 자료들 몇 개 있는데, 여기 들어가서 확인해 봐: https://www.firecrawl.dev/blog/claude-web-fetch-vs-firecrawl
