웹은 사람을 위해 만들어졌다. HTML, CSS, JavaScript로 구성된 웹 페이지는 브라우저라는 도구를 통해 시각적으로 렌더링되고, 사람의 눈이 그것을 읽는다. 그런데 이제 웹을 읽는 주체가 하나 더 생겼다. AI 에이전트다. 문제는, AI 에이전트에게 HTML은 극도로 비효율적인 형식이라는 점이다.
HTML은 AI에게 낭비다
간단한 블로그 글 하나를 생각해보자. 본문은 500단어인데, HTML로 감싸면 <div>, <nav>, <header>, <footer>, <script>, 인라인 스타일, 광고 스크립트, 트래킹 픽셀까지 합쳐서 수만 토큰이 된다. AI 에이전트가 이 페이지에서 필요한 정보는 본문 500단어뿐인데, 나머지 수만 토큰은 전부 노이즈다.
이건 돈 문제이기도 하다. LLM API 호출은 토큰 단위로 과금된다. 불필요한 HTML 태그에 토큰을 쓰는 것은 빈 박스를 택배로 보내면서 배송비를 내는 것과 같다.
NOTE 잠깐! 이 용어는?
토큰: LLM이 텍스트를 처리하는 기본 단위다. 대략 영어 4글자, 한국어 1-2글자가 1토큰이다. HTML 태그는 콘텐츠 대비 많은 토큰을 소비한다.
Cloudflare의 해결책: 네트워크 레벨 변환
Cloudflare는 이 문제를 네트워크 레벨에서 해결한다. 웹사이트 운영자가 별도의 코드를 작성할 필요 없이, Cloudflare CDN을 통과하는 HTML 응답을 자동으로 마크다운으로 변환해주는 것이다.
핵심 동작 원리는 HTTP Content Negotiation이다. AI 에이전트가 HTTP 요청을 보낼 때 Accept 헤더에 text/markdown을 포함하면, Cloudflare가 이를 감지하고 HTML 대신 마크다운으로 변환된 콘텐츠를 응답한다.
AI 에이전트의 HTTP 요청
GET /blog/post-1 HTTP/2
Host: example.com
Accept: text/markdown, text/html;q=0.9
User-Agent: AI-Agent/1.0
Cloudflare의 마크다운 응답
HTTP/2 200 OK
Content-Type: text/markdown; charset=utf-8
# 블로그 포스트 제목
본문 내용이 깔끔한 마크다운으로 전달된다.
네비게이션, 푸터, 스크립트 등은 모두 제거되었다.
NOTE 잠깐! 이 용어는?
Content Negotiation: HTTP 프로토콜의 메커니즘으로, 클라이언트가Accept헤더를 통해 선호하는 콘텐츠 형식을 서버에 알리는 것이다. 같은 URL에서 JSON, HTML, XML 등 다양한 형식으로 응답할 수 있다.
토큰 절감 효과
Cloudflare의 자체 측정에 따르면, HTML을 마크다운으로 변환했을 때 토큰 소비가 약 80% 감소한다. 이건 단순한 최적화가 아니라 게임 체인저다.
| 형식 | 일반적인 토큰 수 (블로그 글 1개) | 유용한 콘텐츠 비율 |
|---|---|---|
| Raw HTML | ~15,000 토큰 | ~20% |
| Markdown | ~3,000 토큰 | ~95% |
| 절감률 | ~80% | - |
AI 에이전트가 하루에 수천 개의 웹 페이지를 크롤링한다면, 이 절감은 곧바로 수백 달러의 비용 차이로 이어진다.
사용 방법
Cloudflare CDN 뒤에 있는 사이트라면 대시보드에서 기능을 활성화하는 것만으로 적용된다. 웹사이트 코드를 한 줄도 수정할 필요가 없다.
Cloudflare 대시보드 설정 경로
Cloudflare Dashboard
→ 도메인 선택
→ Scrape Shield (또는 AI)
→ Markdown for Agents: ON
개발자가 직접 테스트하고 싶다면:
curl로 마크다운 응답 테스트
curl -H "Accept: text/markdown" https://example.com/blog/post-1
기존 HTML 응답이 필요한 일반 브라우저 요청에는 전혀 영향을 주지 않는다. Accept 헤더에 text/markdown이 포함된 요청에만 마크다운으로 응답한다. 기존 트래픽과 완벽히 공존하는 구조다.
llms.txt, robots.txt와의 관계
Cloudflare Markdown for Agents가 등장한 맥락을 이해하려면, 웹에서 AI 에이전트와의 상호작용을 정의하려는 다른 시도들도 알아야 한다.
robots.txt는 1990년대부터 있던 표준으로, 크롤러에게 "이 경로는 크롤링하지 마라"고 지시한다. 하지만 이건 접근 제어이지, 콘텐츠 형식에 대한 것이 아니다.
llms.txt는 비교적 최근 제안된 표준으로, 사이트의 핵심 콘텐츠를 LLM이 소비하기 쉬운 형태로 요약해 제공하는 파일이다. 사이트 소유자가 수동으로 작성해야 한다.
llms.txt 예시
# Example.com
## 소개
이 사이트는 기술 블로그다.
## 주요 콘텐츠
- /blog: 기술 블로그 포스트
- /docs: API 문서
## API
- Base URL: https://api.example.com
- 인증: Bearer 토큰 필요
Cloudflare의 접근은 이 둘과 성격이 다르다. robots.txt처럼 접근을 제어하는 것도 아니고, llms.txt처럼 별도 파일을 만드는 것도 아니다. 기존 웹 콘텐츠를 그대로 두고, 요청자에 따라 형식만 바꾸는 것이다. Content Negotiation이라는 오래된 HTTP 표준 위에 구현되었기 때문에, 기술적으로도 자연스럽다.
웹의 진화: "사람+에이전트" 시대
이 기능이 의미하는 바는 기술적 편의를 넘어선다. 웹이 "사람만을 위한 공간"에서 "사람과 AI 에이전트가 공존하는 공간"으로 진화하고 있다는 신호다.
이전까지 AI 에이전트가 웹을 소비하는 방식은 다소 거칠었다. HTML을 통째로 파싱하거나, Playwright 같은 브라우저 자동화 도구로 렌더링 후 텍스트를 추출하거나, BeautifulSoup으로 태그를 벗기는 식이었다. 모두 "사람용으로 만들어진 웹"을 억지로 기계가 읽는 방식이다.
Cloudflare의 접근은 이를 인프라 레벨에서 해결한다. 웹사이트 운영자는 평소대로 HTML 사이트를 만들면 되고, CDN이 자동으로 AI 친화적 형식을 제공한다. 이건 마치 도서관이 시각장애인을 위해 점자 도서를 별도로 만드는 대신, 자동 점역 기계를 설치하는 것과 같다. 원본을 건드리지 않으면서 새로운 소비자에게 적합한 형식을 제공한다.
AI 에이전트 개발자 관점
AI 에이전트를 개발하고 있다면, 이 기능을 활용하는 방법은 간단하다.
Python에서 마크다운 응답 요청
import httpx
response = httpx.get(
"https://example.com/blog/post-1",
headers={"Accept": "text/markdown"}
)
if response.headers.get("content-type", "").startswith("text/markdown"):
markdown_content = response.text
# 토큰 효율적인 마크다운을 LLM에 바로 전달
else:
# 폴백: HTML 파싱 필요
pass
모든 사이트가 Cloudflare를 쓰는 것은 아니므로, text/markdown 응답이 올 수도 있고 안 올 수도 있다. 폴백 로직은 항상 필요하다. 하지만 Cloudflare를 사용하는 사이트가 전체 웹 트래픽의 상당 부분을 차지한다는 점을 고려하면, 이 기능의 커버리지는 무시할 수 없는 수준이다.
마무리
Cloudflare Markdown for Agents는 작은 기능처럼 보이지만, 웹의 콘텐츠 협상이 AI 시대에 맞게 확장되는 첫 번째 대규모 사례라는 점에서 의미가 크다. HTTP Content Negotiation은 원래 언어(ko, en)나 형식(json, xml)을 협상하기 위한 것이었다. 여기에 "AI 에이전트를 위한 형식"이 추가된 것이다.
앞으로 Accept: text/markdown이 Accept: application/json만큼 자연스러운 세상이 올 수 있다. 웹은 더 이상 브라우저만을 위한 공간이 아니다.
'노트 > 끄적끄적' 카테고리의 다른 글
| CSS @scope는 BEM의 대안이 될 수 있는가 (0) | 2026.02.15 |
|---|---|
| CSS contrast-color()가 없어도 괜찮다 — 3가지 대안으로 흉내내기 (0) | 2026.02.15 |
| 무한의 덧셈 — “정답”보다 “정의”를 먼저 맞추는 습관 (0) | 2026.02.15 |
| BigQuery vs Redshift — 팀에서 안 싸우고 고르는 기준 (HTML) (0) | 2026.02.14 |