Accept: text/markdown, 에이전트 웹의 작은 계약

HTML은 사람에게, Markdown은 에이전트에게

Accept Markdown은 매우 작은 아이디어를 밀고 있다. 브라우저가 요청하면 HTML을 주고, AI 에이전트나 RAG 파이프라인이 Accept: text/markdown을 보내면 같은 URL에서 Markdown을 주자는 것이다. 사이트는 이미 본문을 갖고 있다. 문제는 에이전트가 가져가는 내용에 내비게이션, 스크립트, 광고, 관련 글, 모달, 스타일 조각이 함께 섞인다는 점이다.

HTTP에는 이미 콘텐츠 협상이 있다. RFC 9110은 Accept 헤더와 Vary를 정의하고, RFC 7763은 text/markdown 미디어 타입을 등록했다. Accept Markdown은 새 표준을 만들기보다 이 두 조각을 에이전트 시대의 관례로 묶는다. 사이트가 Vary: Accept를 설정하고, q-value를 존중하고, 지원하지 않는 타입에는 406을 줄 수 있으면 기본 계약은 성립한다.

토큰 비용보다 중요한 것은 신호 대 잡음비

에이전트 브라우징에서 가장 비싼 것은 페이지 크기만이 아니다. 모델이 문서의 어느 부분이 본문이고 어느 부분이 UI인지 판단해야 하는 비용도 크다. Markdown 변형은 DOM 파싱과 본문 추출의 불확실성을 줄인다. 사이트 운영자 입장에서는 별도 API를 만들지 않고도 에이전트 친화적 읽기 경로를 제공할 수 있다.

ClaudeBot 사칭 스캔, 에이전트 웹의 신원 문제가 터졌다는 에이전트 웹에서 "누가 요청했는가"가 어려운 문제라고 봤다. Accept 헤더는 신원 문제를 풀지는 못한다. 대신 "무엇을 받고 싶은가"를 명시한다. 안티 AI 폰트, 웹을 지키기보다 접근성을 깬다가 보여준 방어적 난독화와 달리, 이 접근은 기계가 읽을 수 있는 깨끗한 경로를 공식적으로 열어둔다.

CDN과 캐시가 성패를 가른다

좋은 아이디어도 캐시가 틀리면 사고가 된다. 같은 URL에서 HTML과 Markdown을 모두 제공하려면 Vary: Accept가 빠지면 안 된다. CDN이 HTML 응답을 Markdown 요청에 재사용하거나 반대로 Markdown을 브라우저에 내보내면 사용자 경험과 검색 색인이 모두 흔들린다. MDN의 Accept 헤더 문서와 Vary 문서를 구현 체크리스트로 삼아야 하는 이유다.

Accept Markdown 사이트는 readiness 테스트에서 Accept: text/markdown, Vary: Accept, 406 처리, q-value 존중을 확인한다. 이 네 가지는 단순하지만 실제 운영에서는 빠지기 쉽다. Next.js, Astro, Rails, Django, Nginx, Caddy, Cloudflare Workers처럼 경로와 캐시 레이어가 여러 겹이면 더 그렇다. 에이전트 최적화는 프롬프트가 아니라 HTTP 헤더에서 시작할 수 있다.

한국 콘텐츠 사이트의 기회

한국어 콘텐츠는 영어보다 모델과 검색 생태계에서 구조화 손실에 더 민감하다. 본문 추출기가 조사, 표, 인용, 제목 계층을 깨뜨리면 요약 품질도 바로 떨어진다. 언론사, 기술 블로그, 공공 문서, 개발자 문서가 Markdown 변형을 제공하면 에이전트가 한국어 원문을 더 안정적으로 읽고 인용할 수 있다. 이는 검색 엔진 최적화와는 다른 층위의 "에이전트 최적화"다.

HTML의 귀환, 자바스크립트 피로가 만든 신호는 웹이 다시 단순한 문서성을 회복하려는 흐름을 다뤘다. HTML over WebSockets, 자바스크립트 피로가 만든 실시간 UI의 반격는 복잡한 클라이언트 렌더링을 줄이는 다른 방향이었다. Accept Markdown은 그 문서성의 에이전트 버전이다. 사람 화면은 그대로 두되, 기계가 읽는 본문은 의도적으로 정리한다.

신뢰 가능한 Markdown이 되어야 한다

주의할 점도 있다. Markdown 변형이 HTML과 다른 내용을 담으면 신뢰 문제가 생긴다. 에이전트에게만 광고성 문구를 넣거나, 브라우저 사용자에게 보이지 않는 주장을 끼워 넣는다면 이것은 새로운 클로킹이 된다. 검색 업계가 HTML 클로킹과 싸웠듯, 에이전트 웹도 "사람에게 보이는 내용과 기계에게 주는 내용이 실질적으로 같은가"를 따지게 될 가능성이 크다.

따라서 구현 원칙은 단순하다. 같은 원본 콘텐츠에서 HTML과 Markdown을 함께 생성하고, canonical URL과 alternate link를 명시하며, Markdown에는 본문 구조와 출처만 남긴다. AI 블라인드니스, 문서 신뢰의 피로 신호가 말한 문서 신뢰 피로는 에이전트 읽기 경로에서도 반복될 수 있다.

자주 묻는 질문

Q1: Accept: text/markdown은 공식 표준인가요?

A: 헤더와 미디어 타입은 기존 RFC에 있다. 다만 AI 에이전트가 이를 관례로 쓰자는 부분은 아직 생태계 합의가 진행 중인 제안에 가깝다.

Q2: llms.txt와 무엇이 다른가요?

A: llms.txt는 사이트 안내와 주요 링크를 알려주는 데 좋다. Accept: text/markdown은 개별 URL의 실제 본문을 같은 주소에서 제공한다.

Q3: SEO에 영향을 주나요?

A: 올바르게 구현하면 브라우저 HTML은 그대로 유지된다. 다만 Vary: Accept와 canonical 관리가 틀리면 캐시와 색인 문제가 생길 수 있다.

Q4: 한국어 사이트에도 유리한가요?

A: 유리하다. 한국어 문서 구조를 Markdown으로 명확히 주면 에이전트 요약과 인용 품질이 좋아질 가능성이 크다.

Q5: 가장 먼저 확인할 설정은 무엇인가요?

A: curl -I -H "Accept: text/markdown" URL로 Content-Type과 Vary: Accept를 확인하는 것이 출발점이다.