당신의 AI 에이전트는 읽지도 않는 HTML에 비용을 지불하고 있습니다 — 7배의 토큰 세금을 측정해 보았습니다

저는 에이전트에게 fetch_page 도구를 주고 Wikipedia 문서 하나를 읽으라고 요청했습니다. 그리고 모델이 단 한 단어를 생성하기도 전에 그 페이지 하나가 48,703 토큰의 비용을 발생시키는 것을 지켜보았습니다. 해당 페이지에서 읽을 수 있는 텍스트는 약 7,300 토큰입니다. 저는 모델이 답변하는 데 전혀 도움이 되지 않는 <div>, 인라인 CSS, 그리고 분석 스크립트 등 약 41,000 토큰 분량의 데이터에 비용을 지불하고 있었던 것입니다.

이것이 에이전트의 웹 접속에 따르는 토큰 세금(token tax)이며, 거의 아무도 이를 측정하지 않습니다. 여기 그 수치와 40줄짜리 해결책, 그리고 솔직한 부분인 — 이것이 중요하지 않은 지점에 대해 알려드립니다.

요약 버전

에이전트가 "페이지를 읽을" 때, 보통 가공되지 않은 HTML이 프롬프트에 그대로 붙여넣어집니다. 제가 테스트한 세 개의 페이지에서, 해당 토큰의 85~86%는 모델이 의미를 파악하기 위해 읽을 필요가 없는 마크업(markup)이었습니다. 페이지를 먼저 텍스트로 변환하면 토큰 청구액이 약 7배 감소합니다. 해결 방법은 표준 라이브러리와 토크나이저(tokenizer)를 사용하는 것입니다. API나 유료 서비스는 필요하지 않습니다.

측정

o200k_base(GPT-4o가 사용하는 토크나이저)를 사용하여, 서로 다른 크기의 실제 페이지 3개를 대상으로 가공되지 않은 HTML과 텍스트 전용을 비교 측정했습니다. 2026-06-09에 측정되었습니다 — 이는 실제 페이지이므로 귀하의 정확한 수치는 다를 수 있습니다:

페이지	가공되지 않은 HTML (Raw HTML)	에이전트용 텍스트 (Text for the agent)	감소율
Wikipedia: Web scraping (165 KB)	48,703 tok	7,280 tok	6.7× (85% 감소)
...

세 개의 페이지는 작은 표본이며 벤치마크는 아닙니다. 하지만 528바이트 페이지와 686KB 페이지 사이에서도 비율은 거의 변하지 않았는데, 이 점이 흥미롭습니다. 즉, 마크업 오버헤드(markup overhead)는 대략적으로 비례하므로, 제가 테스트한 페이지들에서는 큰 페이지뿐만 아니라 모든 페이지에서 세금이 나타납니다.

GPT-4o 입력 가격($1M 토큰당 $2.50, OpenAI, 2026년 6월 확인 기준)을 기준으로 하면, LLM 페이지 읽기 비용은 가공되지 않은 상태에서 $0.55인 반면, 정제된 상태에서는 $0.078입니다. 단 한 번의 읽기 비용입니다. 루프를 돌며 200개의 페이지를 크롤링하는 에이전트는 이를 실제 돈으로 바꾸게 되며, 더 나쁜 것은 모델이 실제로 추론하기를 원하는 토큰을 밀어내는 노이즈로 컨텍스트 윈도우(context window)를 채운다는 점입니다.

해결책 (stdlib + tiktoken)

import sys, ssl, urllib.request
from html.parser import HTMLParser
import tiktoken
...

이것은 runnable local(로컬 실행 가능) 발췌본입니다. pip install -U tiktoken을 실행하세요 (o200k_base를 사용하려면 최신 버전이 필요합니다). 그 다음 python clean.py https://en.wikipedia.org/wiki/Web_scraping을 실행합니다. 제 컴퓨터에서의 출력 결과는 다음과 같습니다:

48,703 -> 7,280 tokens  (6.7배 감소)

전체 스크립트(아래의 TLS 처리 및 무결성 검사 포함)는 리포지토리(repo)에 있습니다. HTMLParser가 설계된 목적대로 표준 라이브러리(standard library)가 작업을 수행하며, 여기에 tiktoken을 더해 문자가 아닌 모델의 단위(units)로 계산합니다. requests나 readability 라이브러리, 별도의 서비스는 사용하지 않았습니다.

무결성 출력(sanity print)에서 발견된 한 가지 솔직한 디테일은, 추출된 텍스트가 Jump to content Main menu Main menu ... Navigation으로 시작한다는 점입니다. 이것은 콘텐츠 정제기(sanitizer)이지 메인 콘텐츠 리더(main-content reader)가 아닙니다. 즉, 내비게이션(nav)과 푸터(footer) 텍스트를 그대로 유지합니다(이에 대한 자세한 내용은 아래에서 다룹니다).

저를 10분 동안 고생시킨 주의사항 하나

저는 VPN 뒤에서 실행 중인데, 첫 번째 페치(fetch)가 CERTIFICATE_VERIFY_FAILED와 함께 실패했습니다. VPN이 TLS를 가로채고 있어서 시스템이 신뢰할 수 있는 루트(root)로 체이닝(chain)할 수 없었기 때문입니다. urllib는 이를 숨깁니다. ssl.SSLError를 urllib.error.URLError로 감싸기 때문에, 단순한 except ssl.SSLError 구문은 절대 실행되지 않습니다. URLError를 잡은 뒤 e.reason을 확인해야 합니다:

except urllib.error.URLError as e:
    if not isinstance(e.reason, ssl.SSLError):
        raise
...

스크립트는 실패 시 차단(fails closed) 방식으로 동작합니다. 즉, 검증을 조용히 비활성화하지 않습니다. 신뢰할 수 없는 MITM(Man-In-The-Middle) 프록시를 통해 페이지를 측정하는 것은 의미가 없기 때문입니다(프록시가 주입한 내용을 토큰화하게 될 것입니다). 따라서 TLS를 끄는 것은 조용한 폴백(fallback)이 아니라, 명시적인 --insecure 플래그를 사용해야만 가능합니다.

이것이 가치가 없는 경우

"항상 HTML을 제거하라"고 말한다면 거짓말일 것입니다. 이것은 공짜가 아닙니다:

• 구조를 잃게 됩니다. 표(Tables), 링크 대상(link targets), alt/title, 그리고 <code> 경계가 일반 텍스트로 평탄화(flatten)됩니다. 만약 에이전트의 작업이 "이 표의 모든 행을 추출하라" 또는 "이 링크들을 따라가라"라면, 텍스트 전용 방식은 중요한 신호(signal)를 버리는 셈입니다. 이러한 작업에는 Markdown을 전달하십시오.
• html.parser는 브라우저가 아닙니다. JS로 렌더링되는 페이지는 거의 비어 있는 껍데기만을 반환합니다. 이는 브라우저가 그려내는(paints) 내용이 아니라 서버가 보낸 내용을 제거하는 것입니다. SPA(Single Page Application) 대상은 여전히 먼저 헤드리스 브라우저(headless browser)를 사용해야 합니다.
• 이것은 판독기(reader)가 아니라 정화기(sanitizer)입니다. 메뉴와 푸터(footer) 텍스트(위의 Jump to content / Main menu 같은 것들)를 그대로 유지합니다. 가독성 처리(readability pass)를 거치면 더 많이 깎아낼 수 있지만, 의존성(dependency)이 추가되고 때로는 실제 콘텐츠를 먹어버리는 비용이 발생합니다. 에이전트에게 "텍스트가 너무 많은 것"은 저렴하지만, "답변을 조용히 누락하는 것"은 매우 비쌉니다. 그래서 저는 정보를 과하게 유지하는 편입니다.
• 7배라는 수치는 가공되지 않은 HTML(raw HTML), 즉 아무 설정 없는 기본값과 비교했을 때의 수치입니다. 토큰을 줄여주는 Markdown이나 가독성 처리 방식과 비교한 것이 아닙니다. 이미 Markdown을 입력으로 사용하고 있다면, 얻을 수 있는 이득은 더 작을 것입니다.
• 수치는 실제 페이지, 사용자의 User-Agent, 그리고 로케일(locale)에 따라 달라집니다. 본인의 대상 페이지에서 직접 다시 측정해 보십시오.

따라서 솔직한 규칙은 다음과 같습니다: 에이전트가 의미를 읽어야 할 때(RAG 인제스션(ingestion), 요약, Q&A)는 텍스트로 변환하십시오. 특정 필드를 추출해야 할 때는 구조를 유지하십시오.

내가 왜 이 수고를 했는가

저는 프로덕션 스크래퍼(production scrapers)를 운영하고 있으며, 에이전트에 적용되는 교훈은 데이터 파이프라인에서 저를 괴롭혔던 교훈과 동일합니다. 비용은 요청(request) 자체에 있는 것이 아니라, 당신이 앞으로 계속 들고 가는 것(carry forward)에 있습니다. 모든 단계에서 가공되지 않은 HTML을 붙여넣는 에이전트는 매 단계마다 세금을 지불하며, 컨텍스트 팽창(context bloat)은 당신이 두 번이나 비용을 지불하고 있는 추론(reasoning) 능력을 조용히 저하시킵니다.

단 40줄의 코드. 단 한 번의 pip install. 제가 테스트한 페이지들에서 토큰 사용량이 약 7배 감소했습니다.

현재 에이전트에 페이지를 어떻게 전달하고 계신가요 — 가공되지 않은 HTML, Markdown, 아니면 가독성 처리 방식인가요? 그리고 본인의 대상 페이지에서 토큰 차이를 직접 측정해 보신 분이 계신가요? 여러분의 수치를 공유해 주세요 👇