Accept 헤더로 AI 에이전트에게 Markdown 제공하기

Roy Fielding의 의견에 동의합니다:

> 모든 요청에 사용자의 선호 가능한 모든 변형을 서버에 알리기 위해 많은 헤더 필드를 보내는 것은 나쁜 설계 절충입니다. 특히 해당 차원 중 어떤 것이 대상 리소스에 적용될 가능성이 매우 낮을 때 더욱 그렇습니다. 1993-94년의 아주 짧은 기간(사람들이 어떤 이미지 형식이 모든 UA에서 사용 가능한지 몰랐고 CSS나 자바스크립트가 없어 클라이언트 측 적응이 불가능했을 때) 이후로 줄곧 나쁜 설계 절충이었습니다.

> ...사전 협상의 캐싱 영향은 사이트당 한 번의 추가 왕복(사후 협상)보다 훨씬 나쁩니다. 그리고 클라이언트 측 적응을 지원하는 형식에서는 그 왕복조차 필요하지 않습니다.

캐싱 영향에 대해 Simon Willison은 다음과 같이 썼습니다:

> ...Accept 헤더를 통한 콘텐츠 협상을 사용하는 애플리케이션을 Cloudflare CDN 뒤에 배포할 수 없습니다. 예를 들어 들어오는 Accept 헤더에 따라 같은 URL에 대해 JSON이나 HTML을 제공하는 경우입니다. 그렇게 하면 Cloudflare가 HTML 클라이언트에게 캐시된 JSON을 제공하거나 그 반대가 될 수 있습니다.

참고: 저는 이 내용을 다른 댓글에 두 인용문에 대한 링크와 함께 게시했는데 지금은 쉽게 복사할 수 없어서 나중에 추가하겠습니다.

상위 4개 AI 챗봇 중 하나가 이 헤더로 요청을 보내겠다고 말하면 그렇게 하겠습니다. 그 전에는 채택이 없는 그저 그럴듯한 아이디어일 뿐입니다.

또한 상위 4개 챗봇 중 어떤 것도 이런 방식으로 웹사이트를 로드할 가능성은 극히 낮다고 생각합니다. 몇 년 후에도 0.01% 채택률을 위한 너무 많은 위험이 있습니다.

깨끗하고 의미론적인 HTML은 어떻습니까?

그것은 이미 봇과 검색 엔진(봇이기도 한)에 최적화되어 있으며 수십 년 동안 사용되어 왔습니다. 왜 지금 마크다운으로 제공해야 합니까?

또한 내비게이션과 같은 HTML의 많은 부분은 봇과 AI에게 유용하며 마크다운 버전에서는 제거될 수 있습니다.

이 스레드의 모든 질문을 보면서 에이전트 지원 문서에 관한 Dachary Carey의 게시물을 강력히 추천합니다: https://dacharycarey.com/2026/02/18/agent-friendly-docs/

제가 미치는 줄 알겠네요. 대체 누가 정신이 온전한 상태에서 LLM에게 원시 HTML을 먹이겠습니까??

HTML은 마크업 언어입니다. 사용자 에이전트는 사용자에게 의미 있는 방식으로 시각적으로 또는 보조 기술을 통해 제시합니다. LLM '사용자'를 추가한다고 해서 이것이 바뀌어서는 안 됩니다. 그들의 사용자 에이전트, 즉 하네스가 HTML을 마크다운으로 변환하여 그들이 원래 이해할 수 있는 방식으로 제시해야 합니다.

하네스 개발자가 npm에서 HTML을 마크다운으로 변환하는 패키지를 가져오기 너무 게으르거나 멍청해서 웹 전체를 다시 쓰는 일은 없을 것입니다. 어떤 사이트가 어쨌든 그렇게 하기를 원한다면 잘된 일입니다. 많은 경우 저도 CSS/JS를 건너뛰고 마크다운을 직접(또는 더 나은 형식으로) 읽고 싶습니다. 하지만 하네스가 토큰을 낭비하는 것을 웹사이트 작성자 탓으로 돌리지 마세요.

이것이 주류가 되기를 바랍니다. 그러면 광고, JS, 블로트 없이 페이지를 볼 수 있으니까요.

좋아요, 그런데 실제로 어떤 에이전트가 그것을 사용할까요? accept html 헤더를 사용하여 마크다운을 얻는 에이전트가 없다면 이것은 무의미합니다.