Accept: text/markdown으로 AI 에이전트에 본문만 보내자는 콘텐츠 협상 제안

광고, 자바스크립트, 쓸데없는 화면 요소 없이 페이지를 읽을 수 있다면 AI와 무관하게 좋겠음. 다만 그래서 오히려 널리 퍼지기 어려울 것 같음.

프롬프트 인젝션 통로가 하나 더 생기는 셈 아닌가 싶음. 지금도 에이전트가 검색 결과와 웹페이지를 읽는데, 그때와 뭐가 다른지 모르겠다는 반론도 가능함.

상위 AI 챗봇들이 이 헤더를 보내겠다고 하기 전에는 채택 없는 아이디어임. 몇 년 뒤에도 0.01% 수준일 수 있는데, 사이트가 그 위험을 감수할 이유가 약함.

클라이언트 쪽에서는 HTML을 받아 Markdown으로 바꾸는 처리 앞에 헤더 협상만 넣으면 됨. Claude Code는 적어도 1년 전부터 이 방식을 쓰고 있고, 수백만 사용자가 있으니 완전히 채택이 없는 건 아님.

깨끗한 시맨틱 HTML이면 원래 봇과 검색엔진이 읽기 좋았음. 에이전트가 불필요한 부분을 제거하고 Markdown으로 변환하면 되는데, 왜 서버가 별도 형식을 내야 하는지 모르겠음.

누가 원시 HTML을 그대로 LLM 컨텍스트에 넣는다는 건지 이해가 안 감. 사용자 에이전트가 HTML을 읽고 적절한 표현으로 바꾸는 게 맞고, 웹사이트 제작자에게 그 비용을 떠넘기면 안 됨.

HTML을 Markdown으로 바꾸는 단계에서 실제로 정보가 틀어짐. CommonMark와 GFM은 위첨자·아래첨자를 표현하지 못해서 ⁴₃이 43이 되고, H₂O 같은 표기가 잘못된 텍스트가 될 수 있음.

프런트엔드가 과하게 복잡하지 않은 깨끗한 HTML이라면 LLM도 처리 가능함. 애초에 임의의 LLM 크롤러에게 내 콘텐츠를 더 쉽게 줘야 할 동기도 잘 모르겠음.

Accept 헤더 기반 사전 콘텐츠 협상은 캐시 비용이 큼. Roy Fielding도 이런 설계를 비판했고, Simon Willison은 Cloudflare CDN에서 같은 URL의 JSON과 HTML이 뒤섞여 캐시될 수 있다고 지적했음.

클라이언트가 'Markdown이 있으면 받고 없으면 HTML도 받겠다'고 말하는 방식은 깔끔함. /foo는 자동 협상, /foo.html·/foo.json·/foo.md는 형식 고정으로 두면 쓰기 편하고, 캐시 문제만으로 이 편의성을 버릴 이유는 없다고 봄.