페이지 한 장 읽자고 브라우저를 통째로 띄울 건가 — OpenClaw가 web_fetch로 본문만 가볍게 긁는 방법

오픈소스 개인 AI 어시스턴트 OpenClaw를 집 서버에 올려 쓰면서 도구(tool) 목록을 들여다보다가, 웹을 다루는 도구가 둘로 나뉘어 있는 게 눈에 띄었다. 하나는 풀 브라우저를 띄우는 무거운 도구(browser), 다른 하나는 그냥 URL의 본문만 가볍게 가져오는 web_fetch다. AI 에이전트가 "이 기사 좀 읽어 줘" 같은 요청을 받을 때마다 매번 진짜 크롬을 띄운다면 어떨까? 이 글은 그 낭비를 피하려고 OpenClaw가 둔 경량 도구 web_fetch가 정확히 무엇을 풀고, 언제 쓰고, 어떤 안전장치를 끼고 있는지를 따라간다.

배경 — 에이전트는 "웹을 읽어야" 일을 한다

메신저로 말을 거는 AI 에이전트에게 사람들은 자주 URL을 던진다. "이 문서 요약해 줘", "이 릴리스 노트에서 바뀐 점만 뽑아 줘", "이 위키 페이지 내용 알려 줘" 같은 요청이다. 에이전트가 이걸 처리하려면 그 페이지의 글 내용을 손에 넣어야 한다. 그런데 "웹 페이지를 손에 넣는다"는 한 문장 안에는 무게가 전혀 다른 두 가지 길이 숨어 있다.

다이어그램 설명. 이 그림은 "URL을 읽어 줘"라는 똑같은 요청이 사실은 두 갈래로 나뉜다는 걸 보여준다. 판단 단계에서 "이 페이지를 가져오는 데 무엇이 필요한가?"를 물어, 본문 텍스트만 있으면 되는 경우는 가벼운 길(HTTP 요청 한 번)로, 자바스크립트를 실행하거나 로그인·클릭이 필요한 경우는 무거운 길(브라우저 엔진 구동)로 간다. 핵심은 두 길의 비용 차이가 수십 배라는 점이다 — 경량 fetch는 응답 한 번 받아 끝나지만, 브라우저는 크롬 프로세스를 띄우고 렌더링·스크립트 실행을 거친다. 놓치기 쉬운 함정은 "어차피 브라우저면 다 되니까 항상 브라우저를 쓰자"는 발상인데, 이러면 정적인 기사 한 장 읽자고 매번 무거운 엔진을 깨우는 셈이라 느리고 메모리도 많이 먹는다. 그래서 OpenClaw는 이 분기를 도구 자체로 갈라 두었다.

핵심 문제 — 풀 브라우저는 본문만 필요할 때 과하다

가장 단순한 설계는 "웹은 다 브라우저로 처리한다"이다. 브라우저는 자바스크립트도 돌리고 로그인도 하고 버튼도 누르니, 못 하는 게 없다. 하지만 "다 된다"가 "항상 맞다"는 아니다. 정적인 본문 한 장을 가져오는 데 풀 브라우저를 쓰면 다음이 한꺼번에 따라온다.

다이어그램 설명. 이 그림은 본문만 필요한 상황에서 풀 브라우저를 썼을 때 동시에 터지는 세 가지 손해를 펼쳐 보여준다. 크롬 프로세스를 깨우고 페이지를 그리고 스크립트까지 돌리느라 응답이 수 초씩 걸리는 속도 문제, 브라우저 엔진 하나가 수백 MB의 메모리를 잡아먹는 자원 문제, 그리고 페이지를 통째로 받다 보니 광고·사이드바·메뉴 같은 군더더기가 섞여 정작 읽어야 할 본문이 묻히는 잡음 문제다. 하나의 무거운 선택이 속도·메모리·품질 세 축에서 동시에 비용을 만든다. 이 패턴의 함정은 셋째다 — 속도·메모리는 눈에 띄지만, "본문에 잡음이 섞인다"는 건 결국 LLM이 읽을 텍스트의 품질을 떨어뜨려 요약·추출 결과까지 흐리게 만든다. 그래서 "본문만 필요한 일"에는 본문만 깔끔히 뽑는 전용 도구가 따로 있어야 한다는 게 이 섹션의 결론이다.

해결 방법 — JS 없는 경량 HTTP fetch + 본문 추출

OpenClaw의 web_fetch는 이 문제를 단순하게 푼다. 자바스크립트를 실행하지 않고, 평범한 HTTP GET 요청(웹 서버에 "이 주소 내용 주세요"라고 한 번 묻는 기본 요청)을 한 번 보낸 뒤, 받아 온 HTML에서 본문만 추출한다. 별도 설정 없이 기본으로 켜져 있어 에이전트가 바로 호출할 수 있다.

다이어그램 설명. 이 그림은 web_fetch 한 번의 호출이 거치는 네 단계를 보여준다. 먼저 평범한 HTTP GET을 보내되 크롬인 척하는 User-Agent(브라우저가 자기를 소개하는 식별 문자열)를 달아 "사람이 보는 브라우저처럼" 요청하고, 받아 온 HTML에서 Readability(웹 페이지에서 광고·메뉴를 걷어내고 본문 글만 골라내는 라이브러리 — 파이어폭스 "읽기 모드"의 그 기술)로 본문만 뽑는다. 추출에 성공하면 markdown이나 text로 돌려주고, 실패하면 선택적으로 Firecrawl(봇 차단을 우회하며 더 까다로운 페이지를 긁어 주는 외부 서비스)로 한 번 더 시도한다. 마지막으로 결과를 15분간 캐시(같은 주소를 또 물으면 네트워크를 안 타고 저장본을 주는 임시 저장)해 둔다. 이 패턴의 핵심은 "가벼운 길을 먼저 시도하고, 안 될 때만 무거운 길로 떨어진다"는 점진적 강화(graceful degradation) 구조다.

언제 fetch, 언제 browser — 갈림길의 기준

그래서 실제로 도구를 고를 때의 기준은 딱 하나다. 그 페이지가 자바스크립트 없이도 본문이 HTML에 들어 있나? 들어 있으면 web_fetch, 아니면 browser다. 이 갈림길을 두 그림으로 나눠 본다.

▲ web_fetch가 어울리는 일

다이어그램 설명. 위 그림은 가벼운 web_fetch로 충분한 상황을 모아 둔 것이다. 블로그·뉴스 기사처럼 글이 주인공인 페이지, 문서나 릴리스 노트 같은 정적 페이지, 그리고 서버가 이미 완성된 HTML을 바로 내려주는(브라우저에서 자바스크립트로 뒤늦게 채워 넣지 않는) 사이트가 모두 여기 해당한다. 공통점은 "받아 온 HTML 안에 본문이 이미 글자로 들어 있다"는 것 — 그러면 스크립트를 돌릴 이유가 없으니 HTTP 요청 한 번이면 끝난다. 이런 일에 브라우저를 쓰는 건 택배 상자 하나 받자고 5톤 트럭을 부르는 격이다.

▲ browser가 필요한 일

다이어그램 설명. 위 그림은 반대로 풀 브라우저가 꼭 필요한 상황이다. 첫째, 서버가 거의 빈 HTML만 내려주고 자바스크립트가 화면을 채우는 SPA(Single-Page Application, 한 페이지에서 스크립트로 내용을 갈아 끼우는 웹앱) — 이건 스크립트를 안 돌리면 본문이 아예 안 보인다. 둘째, 로그인해야 내용이 나오는 페이지. 셋째, 버튼을 누르거나 스크롤해야 다음 내용이 나오는 상호작용형 흐름이다. 앞 그림과 같은 축에서 비교하면 차이가 분명하다 — web_fetch는 "받은 HTML에 본문이 있다"를 전제하고, browser는 "본문을 보려면 페이지를 실제로 살아 움직이게 해야 한다"를 전제한다. 함정은 둘의 경계가 겉보기로는 똑같아 보인다는 점이다 — 둘 다 그냥 URL이다. 그래서 OpenClaw 문서는 web_fetch를 "best-effort(최선을 다하는 시도)"로 못 박는다. 가볍게 시도해 보고 본문이 안 잡히면 그때 브라우저로 넘기라는 뜻이다.

결과 — 무엇이 좋아졌나

웹을 다루는 도구를 무거운 브라우저 하나로 통일하지 않고 가벼운 web_fetch를 따로 둔 덕분에, 같은 "URL 읽기"가 상황에 맞게 갈라진다.

축	풀 브라우저만 쓸 때	web_fetch를 따로 둘 때
속도	크롬 기동·렌더링으로 수 초	HTTP 요청 한 번 + 15분 캐시로 빠름
자원	브라우저 엔진이 수백 MB 점유	요청·파싱만 — 가벼움
본문 품질	광고·메뉴까지 섞여 들어옴	Readability로 본문만 깔끔히
한계	JS·로그인·클릭까지 다 됨	안 되면 browser로 넘기는 best-effort

정리하면, web_fetch는 "대부분의 페이지 읽기는 사실 가볍게 끝낼 수 있다"는 관찰을 도구 설계로 옮긴 것이다. 에이전트는 본문만 필요한 흔한 일에는 가벼운 fetch로 빠르게 답하고, 진짜 브라우저가 필요한 까다로운 일에만 무거운 도구를 깨운다. 이건 사람에게는 더 빠른 응답으로, 시스템에는 더 적은 메모리와 더 깔끔한 입력으로 돌아온다 — 화려해 보이진 않지만, "필요한 만큼만 무거운 도구를 쓴다"는 이 절제가 늘 켜져 있는 자율 에이전트를 오래 잘 굴러가게 만드는 기반이다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.