같은 주소, 사람에겐 HTML 에이전트에겐 마크다운

같은 주소에 사람이 접속하면 HTML을, AI 에이전트가 접속하면 마크다운을 돌려주자는 제안이 공개됐다. 개발자 벤 워드(Ben Word)가 만든 안내 사이트 '억셉트 마크다운(acceptmarkdown.com)'은 새 표준을 만들자는 게 아니라, 이미 웹 표준에 있는 콘텐츠 협상(content negotiation) 기능을 AI 시대 용도로 다시 쓰자고 말한다.

무슨 일인가 / 배경

콘텐츠 협상은 새로 나온 기술이 아니다. 웹 표준 문서 RFC 9110에 규정된 방식으로, 클라이언트가 요청 헤더에 원하는 형식을 적어 보내면 서버가 그에 맞는 표현을 골라 응답한다. 언어별 페이지를 나눌 때 쓰던 그 구조를 마크다운 미디어 타입(RFC 7763)에 적용하자는 것이 이번 제안의 골자다. 새 주소를 파거나 별도 사이트를 만들 필요가 없다는 점이 핵심이다.

배경에는 에이전트의 웹 접근 방식이 있다. 요즘 AI 도구는 사람 대신 페이지를 열어 읽는데, 정작 필요한 건 본문뿐인데도 내비게이션·광고·스크립트·레이아웃 껍데기까지 전부 컨텍스트에 밀어 넣는다.

핵심 짚어보기

제안이 내세우는 이득은 세 가지다. 첫째 토큰이다. 마크다운으로 내주면 껍데기가 사라져 모델이 문서 구조가 아니라 문장에 컨텍스트를 쓴다. 둘째 검색 품질이다. 광고·관련글 목록·팝업이 섞이지 않으니 검색 색인이나 RAG 파이프라인이 임베딩할 텍스트의 신호대잡음비가 올라간다. 셋째 속도다. 가져올 것도 파싱할 것도 줄어 첫 토큰이 빨리 나온다.

사이트는 진단 도구도 함께 제공한다. 주소를 넣으면 엣지에서 실제 요청을 보내 네 가지를 판정한다 — 마크다운을 실제로 돌려주는지, Vary: Accept 헤더를 설정했는지, 지원하지 않는 형식에는 406으로 거절하는지, 우선순위를 뜻하는 q값을 존중하는지다. 직접 확인하려면 터미널에서 curl -sI -H "Accept: text/markdown" <주소> 한 줄이면 된다. 엔진엑스(Nginx)·캐디(Caddy)·워드프레스(WordPress)·라라벨(Laravel)·레일스(Rails)·클라우드플레어 워커스(Cloudflare Workers)·넥스트(Next.js)·아스트로(Astro)·장고(Django) 등 주요 환경별 설정 예시도 정리돼 있다.

눈에 띄는 건 '지원 매트릭스' 페이지다. 어떤 AI 에이전트가 실제로 이 헤더를 보내는지 정리해 둔 표인데, 뒤집어 말하면 아직 보내지 않는 도구가 적지 않다는 뜻이기도 하다.

1인기업 실전 적용 포인트

• 정적 사이트를 운영한다면 글의 마크다운 원본을 함께 배포하고 헤더 규칙만 얹으면 사실상 끝이다. 클라우드플레어 사용자는 별도 설정 없이 켜는 지름길이 안내돼 있다.
• Vary: Accept를 빠뜨리면 CDN이 브라우저에 마크다운을, 에이전트에 HTML을 캐시해 돌려주는 사고가 난다. 도입 과정에서 가장 위험한 한 줄이니 반드시 함께 넣어라.
• 내 사이트가 아니라 남의 사이트를 수집할 때도 쓸모가 있다. 뉴스·문서 크롤러의 요청 헤더에 Accept: text/markdown을 한 줄 추가하면, 지원하는 사이트에 한해 본문만 받아 토큰과 후처리 시간을 함께 줄인다.
• 이미 llms.txt를 두고 있다면 병행하라. llms.txt가 '무엇을 읽어야 하는지' 알려주는 안내판이라면, 이쪽은 '읽을 때 무엇을 받을지' 정하는 규칙이다.

전망 / 주의점

표준 위에 얹은 규약이라 도입 비용이 낮은 게 가장 큰 장점이다. 다만 두 가지는 짚어야 한다. 하나, 에이전트 쪽이 헤더를 보내지 않으면 서버가 아무리 준비해도 아무 일도 일어나지 않는다. 둘, 본문을 통째로 깔끔하게 내주는 일은 방문자 수와 광고 노출로 먹고사는 사이트에는 명백한 손해가 될 수 있다. 콘텐츠로 트래픽을 파는 구조라면 전문 대신 요약본만 마크다운으로 내주는 절충도 가능하다. 어느 쪽이든, 내 사이트가 지금 에이전트에게 무엇을 보여주고 있는지부터 한 번 확인해 볼 값어치는 있다.

출처: 해커뉴스 (https://acceptmarkdown.com/)