Cloudflare Markdown for Agents, 토큰 절감률보다 먼저 볼 지표

Cloudflare에서 Markdown for Agents를 쓰고 있다면, 대시보드의 토큰 절감률을 보기 전에 대표 페이지가 온전히 읽히는지 확인해 보세요. 같은 주소에서 Markdown 응답이 나오더라도 입력이 잘렸거나, 비교에 필요한 구조 정보가 빠지거나, 전송 도중 연결이 끝났을 수 있습니다. 글 끝에 있는 주의사항과 다운로드 링크가 남아 있는지는 변환 건수 하나로 알기 어렵습니다.

Cloudflare는 2026년 11월 9일 변경 기록에서 Markdown for Agents의 일반 제공과 함께 변환 분석, 샘플 로그, Playground, 추적 기능을 안내했습니다. 11월 10일 공개 문서를 확인한 내용을 바탕으로, 공개 문서 사이트를 운영하는 사람이 어떤 순서로 화면을 읽으면 좋을지 정리했습니다. 이 글을 위해 운영 계정에서 기능을 켜거나 실제 절감량을 측정하지는 않았습니다. 아래 문서 사이트와 기록표는 검토할 때 쓰는 가상 사례입니다.

새 대시보드에서 무엇을 볼 수 있나요?

Markdown for Agents는 적용되는 Cloudflare 사이트에서 클라이언트가 Markdown 형식을 요청하면 원본 HTML을 변환해 주는 기능입니다. 원본 글을 다시 작성하거나 사람이 사용하는 웹페이지 전체를 Markdown 화면으로 바꾼다는 뜻은 아닙니다. 클라이언트가 보내는 HTTP 요청의 Accept 헤더가 어떤 형식을 받을지 알려 줍니다. 변환을 요청하는 쪽과 화면에서 HTML을 보는 쪽을 구분하면, 브라우저에서 페이지가 정상인데 에이전트에는 내용이 다르게 보이는 상황을 이해하기 쉽습니다.

공식 문서의 대시보드 경로는 사이트를 선택한 뒤 Agent Readiness의 Markdown for Agents입니다. Analytics는 변환 결과와 경향을 보는 화면입니다. Logs는 샘플 변환 이벤트를 실패 이유나 콘텐츠 제한으로 좁히는 화면입니다. Playground는 선택한 호스트의 한 경로를 Markdown으로 요청하고 HTML과 나란히 살펴보는 자리입니다. 화면 이름이 비슷해도, 전체 경향과 특정 요청을 다루는 범위가 달라요.

예를 들어 팀에서 제품의 공개 설치 안내와 업데이트 기록을 운영한다고 가정해 볼게요. 글 도입과 제목만 읽은 에이전트가 구버전 설치 단계를 최신 절차처럼 요약하면 독자는 엉뚱한 파일을 받을 수 있습니다. 이때 첫 질문은 변환이 몇 건 일어났는지가 아니라, 모델이 참고해야 할 버전 표와 예외 조건이 응답에서 확인되는지입니다. 특히 변경 이력이 긴 문서는 문서의 마지막이 사라져도 앞부분만으로 읽기 쉬워 보일 수 있습니다.

완료, 일부 완료, 미완료는 다른 상태입니다

공식 분석 문서가 말하는 전체 변환은 알려진 콘텐츠 제한 표시가 모두 걸리지 않은 상태에서 변환을 마쳤다는 뜻입니다. HTML의 글꼴이나 스크립트까지 복제하거나, 모든 의미가 그대로 전달됐다는 뜻으로 확대하면 안 됩니다. 변환에 성공한 뒤에도 각 문서의 핵심 문장, 표 항목과 연결 주소가 남았는지 따로 확인할 이유입니다.

화면에서 본 결과	가장 먼저 확인할 것
전체 변환	제목과 표, 마지막 주의사항의 내용이 응답에 남았나요?
일부 변환	입력 잘림, 문서 앞부분의 메타데이터 또는 JSON-LD 생략 중 어떤 표시가 있나요?
완료했지만 전체 여부 미확인	이 상태를 전체 변환 건에 합치지 않고 구분해 보았나요?
오류 또는 미완료	오류 코드를 확인할 수 있나요? 최종 결과가 없는 스트림이면 원인은 따로 남겼나요?

JSON-LD는 페이지의 제목이나 작성 정보처럼 기계가 읽도록 구조화한 데이터를 넣는 형식입니다. 문서 맨 앞에 붙는 메타데이터 역시 본문과 구분되는 정보예요. 이런 정보가 필요한 소비자도 있지만, 특정 독자에게는 글 마지막의 적용 예외가 더 중요할 수 있습니다. 먼저 내가 지켜야 할 내용을 정하면 표시된 제한을 우선순위로 바꾸기 쉽습니다.

공식 제한은 압축을 푼 HTML 기준 6MiB입니다. 다운로드 파일이 작게 보인다는 이유만으로 압축을 푼 원본도 작다고 가정하면 안 됩니다. HTML이 길어진 이유가 반복되는 탐색 메뉴인지, 한 페이지에 누적한 문서 본문인지도 따로 보세요. 전체를 여러 페이지로 나눌 때는 요약에서 상세 페이지로 이어지는 링크와 개별 페이지의 버전 조건이 남아야 원래 안내를 찾아갈 수 있습니다.

절감률보다 먼저 표본과 비교 범위를 읽어 보세요

대시보드와 로그의 건수는 샘플을 바탕으로 가중해 추정한 값입니다. 공식 문서는 변환을 건너뛴 요청과 일부 조기 취소가 집계에서 빠질 수 있다고 설명합니다. 따라서 목록의 한 줄을 실제 요청 딱 한 번으로 세거나, 수치를 사이트 전체 방문 수와 나란히 놓아 비율을 만들면 범위가 뒤섞입니다. 같은 시간대와 호스트를 맞춘 뒤 어떤 페이지에서 문제 표시가 늘었는지 살피는 편이 읽기 쉽습니다.

절감량도 모델이 실제로 센 토큰이 아닙니다. 문서는 바이트 수를 4로 나눈 뒤 내림한 추정치를 사용하며, 입력 추정치가 양수인 전체 변환만 절감 계산에 넣는다고 안내합니다. Markdown이 오히려 길어진 경우에는 추정 절감값이 음수일 수 있습니다. 일부·실패·미완료 결과가 계산에서 제외된다는 조건을 함께 적어야 숫자가 가리키는 범위를 팀에서 놓치지 않아요.

이를테면 짧은 도움말이 많이 처리되고 긴 안내서의 일부 변환이 늘어난 가상의 상황을 생각해 보세요. 전체 절감률만 보면 변화가 없어도, 가입 전에 확인해야 하는 긴 안내서는 여전히 점검 대상입니다. 반대로 한 페이지의 출력이 더 길어졌더라도 꼭 필요한 경고가 남고 다른 페이지의 문제와 무관할 수 있습니다. 개선 목표를 정할 때는 작은 숫자 하나를 만들기보다, 어떤 종류의 문서에서 어떤 정보가 빠졌는지 먼저 묶어 보세요.

사용자 에이전트 값도 요청자가 보내는 문자열입니다. 대시보드에서 이름 하나가 많이 보인다고 특정 회사가 그만큼 접근했다고 단정하기는 어렵습니다. 공식 문서에 따르면 분석의 페이지 URL에는 쿼리 문자열과 조각 식별자 등이 들어가지 않습니다. 같은 경로에서 언어와 버전이 매개변수로 달라지는 사이트라면, 화면의 한 행으로 각각의 응답을 확인했다고 보지 말고 필요한 변형을 승인된 범위에서 나누어 확인하는 게 좋습니다.

대표 페이지 한 장부터 대조해 보세요

업무를 맡은 운영자라면 먼저 공개 도움말에서 중요도가 높은 짧은 페이지와 긴 페이지를 하나씩 고를 수 있습니다. 공개 범위와 대상 호스트를 확인한 뒤 대시보드에서 호스트와 조회 기간을 기록해 두세요. 운영 설정을 바꾸지 않고 먼저 현재 상태에서 볼 수 있는 값을 확인하면, 이후 변화가 설정 때문인지 원래 문서 구조 때문인지 살피기 편합니다.

Playground에서 선택한 경로를 열면 응답 헤더, 렌더링 미리보기, Markdown과 HTML을 확인할 수 있습니다. 헤더는 어느 형식으로 도착했는지를 보는 단서이고, 실제 글의 완전성은 본문을 읽어서 확인해야 합니다. 헤더의 성공 응답이나 변환 완료 표시만 보고 기록표에 통과를 쓰기보다, 원본과 변환 응답에서 같은 구간을 짝지어 두세요. 가령 설치 문서에서는 운영체제 조건, 버전 표의 각 행, 내려받기 주소, 맨 끝의 복구 설명을 순서대로 찾을 수 있습니다.

기록할 항목	한 페이지를 볼 때 남길 내용
대상과 비교 기준	실제 호스트와 경로, 확인 시각, 기준으로 삼은 원본 버전
확인한 형태	응답이 Markdown인지, 미리보기와 원문에서 볼 수 있는 부분
빠지면 곤란한 내용	제목, 버전 표, 예외 문구, 다음 안내로 가는 링크
결과와 다음 확인	전체·일부·미확인 상태와 부족한 내용, 다시 볼 담당자

Playground에서 아무 응답도 읽지 못한 상황도 따로 분류하세요. 공식 문서는 브라우저가 다른 출처의 응답을 읽는 제한이나 네트워크 오류가 있을 수 있다고 안내합니다. 이때 변환 실패와 화면에서 응답을 읽지 못한 일을 같은 것으로 기록하면 수정 방향이 달라질 수 있습니다. 조직에서 허용한 별도의 읽기 전용 점검 방법이 있으면 같은 주소·형식·시각 조건으로 실제 응답을 대조하고, 확인이 어려우면 미확인으로 남겨 두세요.

로그와 추적은 어디에서 도움이 될까요?

같은 페이지에서 일부 변환이 반복해 보이면 Logs에서 결과와 콘텐츠 제한을 좁혀 볼 수 있습니다. 먼저 해당 경로에 표시된 이유가 입력 잘림인지 구조화된 정보 생략인지 구분하세요. 그러고 나서 문제를 재현할 수 있는 공개 문서의 응답을 다시 읽습니다. 이 순서는 한 건의 미확인 상태를 전체 사이트 장애처럼 해석하는 일을 줄이는 데 도움이 됩니다.

추적을 이미 사용 중인 도메인에서는 샘플에 들어온 스트리밍 변환을 더 자세히 볼 수 있습니다. 공식 문서는 요청 흐름에서 변환 구간을 펼치면 결과, 입력·출력 바이트와 처리 시간을 확인할 수 있다고 설명합니다. 변환 구간의 전체 경과 시간에는 원본 응답을 기다리거나 뒤쪽 처리 속도에 맞춰 대기한 시간이 포함될 수 있습니다. 변환기 자체가 사용한 CPU 시간은 별도 항목이에요. 응답을 받는 쪽이 끝까지 읽었는지는 출력 바이트만으로 확인할 수 없습니다.

팀에서 GraphQL 분석을 이미 사용한다면 이 자료를 별도로 집계할 수도 있습니다. 공식 설명의 조회 범위는 최대 최근 7일이며, 조회하려는 사이트나 계정에 대한 분석 읽기 권한이 필요합니다. 집계 화면을 볼 수 있다는 사실과 사이트에서 변환을 사용할 수 있는 조건은 서로 다릅니다. 토큰이나 관리자 접근이 필요한 경우는 기존 승인과 최소 권한을 기준으로 삼고, 실습만을 위해 운영 설정을 새로 열 필요는 없습니다.

적용 범위를 정할 때 놓치기 쉬운 점

실제 운영에서는 문서의 내용이 공개된 범위인지 먼저 확인하세요. 변환 결과를 다른 시스템에 보내거나 별도 데이터로 저장한다면, 그 시스템의 권한과 공유 조건도 확인해야 합니다. 기능을 이미 켠 사이트라도 모든 경로를 하나의 판단으로 묶기 어렵습니다. 긴 변경 이력은 결과의 끝을 읽고, 여러 언어가 있는 문서는 실제로 선택한 언어 응답을 보고, 연결 링크가 중요한 문서는 도착 주소까지 확인하는 식으로 기준을 맞추세요.

설정 변경이 필요하다면 담당자와 기존 규칙·범위를 기록하고, 승인된 좁은 호스트나 경로에서 비교하는 계획부터 정하는 게 좋습니다. 예전 응답으로 돌아갈 판단 기준을 정하지 않은 채 범위를 크게 바꾸면 기존 HTML 전달까지 어느 부분이 달라졌는지 파악하기 어려워집니다. CloudFront와 Cloudflare의 캐시·원본 비교는 CDN의 기본 선택 기준을 다룹니다. 이번 확인표는 그중 변환 응답과 원래 페이지 내용을 대조하는 데 초점을 둡니다.

자주 나오는 질문

전체 변환이 많으면 검색 노출도 좋아졌나요? 화면의 수치는 변환 과정의 관찰값입니다. 검색 결과의 노출이나 인용은 별도의 자료가 필요합니다. 변환 경향만으로 순위나 클릭이 늘었다고 판단하지 않습니다.

짧게 변환되면 원본보다 나은 응답인가요? 불필요한 꾸밈이 줄어든 것인지, 필요한 표나 끝 문장이 빠진 것인지 읽어서 확인하세요. 글에 쓰일 판단 근거가 남아 있는지가 기준입니다.

지금 무엇을 확인하면 좋을까요? 한 번의 조회에서는 대표 경로의 제목, 표, 마지막 문단, 연결 링크를 원본과 맞춰 보세요. 전체 변환 비율과 추정 절감은 그 결과를 이해하는 보조 지표로 붙이면 됩니다.

확인한 공식 자료

2026년 11월 10일 Cloudflare 11월 9일 변경 기록과 Markdown for Agents 공식 문서에서 분석 화면, 결과 분류, 추정치, 제한과 추적 조건을 확인했습니다. 기능 제공 범위와 관리 메뉴는 실제 사이트의 권한과 설정에서 확인할 부분입니다.

대표 페이지의 변환 결과와 빠진 내용을 본 뒤 절감 추정치를 읽는 순서입니다.