Executive Summary

주요 수치

네 숫자를 규격 전문과 발표 보도에서 뽑았다. 앞의 셋은 1.0판이 아직 무엇을 못 하는지를 말하고, 마지막 하나는 문서가 어느 수준까지 다듬어졌는지를 말한다.

출처: Content Telemetry Specification v1.0, SPUR Content Telemetry Profile, Digiday (2026-10-02).

지금 발행사가 손에 쥔 기록은 웹 서버에 찍힌 요청 로그뿐이다. 어느 크롤러가 언제 무슨 주소를 받아 갔는지까지는 보인다. 그 뒤는 보이지 않는다. 가져간 글이 실제로 답을 만드는 데 들어갔는지, 출처로 적혔는지, 그 출처가 사용자 화면까지 닿았는지, 누가 눌렀는지는 쓰는 쪽만 안다. 규격의 문제 진술이 바로 그 자리에서 시작한다. 플랫폼이 사용량을 스스로 발표하더라도 발행사에는 맞대 볼 기록이 없고, 플랫폼끼리 숫자를 견주는 방법도 없다는 것이다.

그래서 규격은 사용자와 에이전트 사이의 한 번의 주고받음을 세션으로 묶고, 그 안에서 콘텐츠가 넘는 경계를 다섯으로 나눈다. 가져가기(content_retrieved), 근거로 넣기(content_grounded), 인용(content_cited), 보여 주기(content_presented), 반응(content_engaged)이다. 모든 이벤트가 같은 세션 번호를 달고 다니기 때문에, 한 질문에 어떤 글이 들어가 어떤 답이 나왔는지를 뒤에서 이어 붙일 수 있다.

경계를 어디에 긋느냐가 이 규격의 핵심이다. 근거로 넣기는 생성 모델의 맥락에 콘텐츠가 들어간 바로 그 지점이다. 검색해서 고르는 데만 쓰이고 맥락에는 들어가지 않은 글은 근거가 아니다. 예가 분명하다. 백 건을 가져와 전부 임베딩하고 열 건으로 추린 뒤 다섯 건을 프롬프트에 넣었다면 근거는 다섯이다. 나머지 아흔다섯은 가져간 것일 뿐이다. 이렇게 그으면 RAG든 추론 모델이든 다단계 에이전트든 같은 자리에서 같은 이벤트가 찍힌다.

캐시가 이 구분을 실감 나게 만든다. 에이전트가 기사 하나를 한 번 받아다 며칠씩 쥐고 쓰면 가져가기는 한 번만 찍히고 근거로 넣기는 그 글이 들어간 세션마다 찍힌다. 발행사 서버에 남는 요청은 하나인데 실제 사용은 그 뒤로도 이어진다는 뜻이고, 오늘 발행사가 보는 숫자와 실제 사용량 사이의 간격이 여기서 벌어진다.

단계 사이의 간격에도 이름이 붙어 있다. 가져갔는데 근거로 쓰이지 않았다면 쓸모없는 글을 받아 간 것이고, 근거로 썼는데 인용하지 않았다면 답에 영향을 주고도 이름이 안 나간 것이다. 인용했는데 보여 주지 않았다면 출처 표시가 사람에게 닿지 않은 것이고, 보여 줬는데 반응이 없었다면 링크가 떴지만 아무도 누르지 않은 것이다. 순서가 늘 지켜지지도 않는다. 출처 사이드바처럼 인용 없이 노출만 되는 경우가 있고, 가져간 적도 없는 글을 출처라고 적는 환각 인용은 근거 없이 인용만 찍힌다. 이런 어긋남을 오류로 보지 말고 실제로 일어난 대로 적으라고 규격은 말한다.

▲ 페블러스 원본 도식. Source: SPUR Content Telemetry Specification v1.0 §4.3·§4.4.

이름 하나는 정식판에서 바뀌었다. 초안의 content_displayed가 content_presented로 바뀌었는데, 규격은 그 까닭을 이름만 고치면 눈에 보였다는 뜻으로만 읽혀 무엇이 경계를 넘었는지를 말하지 못하기 때문이라고 적는다. 그래서 presentation_kind 항목을 새로 두어 본문 발췌가 나간 것인지 링크나 출처 표시만 나간 것인지를 가르게 했다. 소리로 읽어 주는 답변이나 에이전트 브라우저가 띄운 페이지까지 포함하려면 화면이라는 말로는 모자란다는 판단이다.

근거로 넣기 이벤트에는 얼마나 들어갔는지를 적는 칸이 둘 있다. chars_ingested는 맥락에 들어간 문자 수이고 tokens_ingested는 같은 내용의 토큰 수다. 정식판은 앞의 것을 1급으로, 뒤의 것을 보조로 못 박았다. 인용 발췌의 길이를 적는 excerpt_chars도 같은 규칙으로 센다.

그 이유는 토크나이저에 있다. 토큰 수는 모델마다 다르고 벤더가 토크나이저를 고치면 값이 달라지며 발신자끼리 비교할 수 없다. 그래서 받는 쪽은 서로 다른 발신자의 토큰 수를 합산해서는 안 되고, 두 값의 차이를 사용량의 차이로 읽어서도 안 된다. 문자 수는 그렇지 않다. 맥락에 들어간 바로 그 문자열의 유니코드 코드 포인트를 세되, 세기 위해 정규화를 적용하는 것은 금지된다. 같은 코드 포인트 열을 넣은 두 발신자는 같은 수를 낸다. 발행사가 어느 모델이 그 수를 냈는지 몰라도 회사를 가로질러, 그리고 시간을 가로질러 양을 견줄 수 있다는 뜻이다.

단위를 고정한 것과 양을 고정한 것은 다르다. 경계는 생성 맥락에 그었지만 그 경계를 넘는 건수까지 고정하지는 않았다. 쉰 건을 긴 맥락에 통째로 밀어 넣는 에이전트와 세 토막으로 추려 넣는 에이전트는 같은 답을 내고도 근거 건수가 크게 달라진다. 경계는 한결같은데 세어 나온 수는 그렇지 않다는 것이고, 그래서 세는 모형은 형식이 정하지 않고 상업적 합의에 맡긴다고 밝혀 두었다.

문서가 든 예가 그 선을 분명히 보여 준다. 글 하나가 세션 범위의 근거로 들어가고 사용자가 열 번 묻고 그 글이 세 번 인용됐다면, 기록에는 근거 1건과 주고받은 차례 10건과 인용 3건이 남는다. 이것을 한 건으로 셀지 세 건으로 셀지 열 건으로 셀지는 계약이 정한다. 규격이 하는 일은 세 가지 모형을 나란히 늘어놓는 데까지다. 세션마다 맥락에 들어간 글을 하나씩 세면 접근 기반이나 정액 계약에 맞고, 응답에 이름이 적힌 횟수를 세면 성과 기반 계약에 맞으며, 그 글이 맥락에 있던 차례를 세면 사용량 기반 계약에 맞는다. 공을 나누는 방식도 골라 주지 않는다. 마지막 접점이든 첫 접점이든 균등 배분이든 위치 가중이든 게임이론식 기여도든 자료만 대고 선택은 넘긴다. 근거와 인용과 노출 가운데 어느 층에서 셀지도 상업적인 선택이지 기술적인 선택이 아니라는 문장이 그 자리에 붙어 있다.

단위 말고도 선언을 강제하는 칸이 둘 더 있다. 하나는 무엇을 하려고 가져갔는지를 적는 purpose다. 초안의 bot_category를 대체한 칸인데, 규격은 이것이 조직이 아니라 접근을 분류하는 칸이라고 선을 긋는다. 봇은 이름을 바꿀 수 있지만 목적은 적어 내야 하는 선언이다. 다른 하나는 얼마나 빠짐없이 보고했는지를 적는 coverage다. 적합 등급을 받았다는 사실은 모든 사건을 다 보고했다는 뜻이 아니라고 규격은 따로 못 박는다. 완전 보고가 아닌 한, 이벤트가 없다는 것을 사건이 없었다는 뜻으로 읽어서는 안 된다는 조항도 함께 들어갔다.

표본이나 묶음을 고르더라도 그 규칙은 보내는 시점에 객관적으로 판정할 수 있어야 하고 발신자의 그때그때 재량에 달려서는 안 된다는 단서가 붙는다. 다만 학습 목적의 가져가기는 적어도 귀속이 되지 않는다. 세션도 근거도 인용도 뒤따르지 않기 때문이다. 범위를 적은 절이 이 점을 더 분명히 한다. 학습 말뭉치를 모으는 일, 모델을 학습하거나 미세조정하는 일, 임베딩을 계산하고 검색 색인을 만드는 일은 모두 이 규격 밖이고, 이를 지키는 구현이라 해도 어떤 모델이 어떤 글로 학습했는지는 한마디도 말해 주지 않는다.

접근을 다루는 규격도 아니다. 에이전트가 콘텐츠를 어떻게 찾아내고 어떤 허락을 받아 가져가는지는 다른 규격들의 자리다. 이름이 올라 있는 것만 해도 미리보기를 먼저 주고 값을 받는 peek-then-pay, 업계 단체 IAB의 콘텐츠 묶음 협상 규격 CoMP, 당사자끼리 맺는 API 계약이 있고, 저장소는 발행사가 이용 조건을 내거는 RSL도 같은 층으로 꼽는다. 콘텐츠 텔레메트리는 그 맞은편에서 보고를 맡는다. 허락을 받았든 받지 않았든 접근이 끝난 뒤에 실제로 무슨 일이 있었는지를 적는 쪽이다. 이벤트에는 어느 허락에 기댔는지를 적는 license_ref 칸이 있어 둘을 이어 붙일 수 있지만, 두 스키마는 서로 독립이고 접근 규격이 무엇이든 아예 없든 텔레메트리는 돌아간다.

빠진 칸도 있다. 초안이 엣지와 원서버 기록에 두었던 ip_hash를 정식판은 거둬들였다. 작은 공간에서 나온 값은 해시해도 익명이 되지 않기 때문이다. IPv4 주소 공간 전체를 해시해 후보와 맞대 보는 일이 보통 장비로 가능하니, 해시된 IP는 익명값이 아니라 가명값이고 개인정보로 다뤄야 한다. 스키마는 추가 항목을 원래 허용하기 때문에 이 금지를 문법으로 막을 수 없고, 그래서 적합 시험이 이 조항만 따로 응용 계층에서 검사한다.

문서가 다듬어진 정도는 저장소에 숫자로 남아 있다. 시험 자료 171건, 검증된 예제 15개, 변형 검사 59개가 변경 요청마다 돌아간다. 의견 수렴은 6월 12일부터 7월 24일까지 열렸고 규격 관련 29건과 프로필 관련 3건의 논의, 5건의 변경 요청이 쌓였으며 모든 논의에 처리 결과가 기록으로 남았다. 깃허브 릴리스에 찍힌 날짜는 9월 2일이고 연합의 공개 발표는 10월 2일이다.

단계마다 누가 적을 수 있는지도 정해져 있다. 가져가기는 관측자가 넷이다. 발행사의 원서버, 그 앞의 CDN이나 엣지, 중간에서 콘텐츠를 건넨 색인, 그리고 에이전트 자신이다. 앞의 둘은 AI 기업의 협조가 필요 없다. 발행사가 자기 엣지에서 돌아가는 코드만으로 바로 찍을 수 있다고 규격은 적는다. 같은 가져가기를 여럿이 적었을 때는 요청 헤더에 실린 번호로 이어 붙이고, 그렇게 서로 맞아떨어진 기록은 한쪽만 있는 기록보다 센 증거가 된다.

나머지는 사정이 다르다. 근거로 넣기와 인용, 보여 주기는 에이전트나 그 운영자만 적을 수 있다고 규격이 못 박는다. 에이전트 안에서 일어난 일, 출력을 만드는 동안 일어난 일, 사람 쪽 화면에서 일어난 일은 발행사 설비에서 보이지 않기 때문이다. 제3자가 나온 답에서 원문을 찾아냈다면 그것은 발신자의 주장을 뒷받침하거나 반박하는 일이지 구성 과정을 관측한 것은 아니다. 반응 단계에는 좁은 틈이 하나 있다. 클릭이 발행사 페이지로 떨어지는 경우에 한해, 도착지가 함께 실려 온 표를 들고 같은 반응을 맞대 줄 수 있다.

이벤트에 붙는 허락 표시도 증거가 아니라 주장이다. license_ref에 적힌 값은 어느 허락이 적용됐다고 발신자가 말하는지를 기록할 뿐이고, 규격 본체는 그 값을 풀지도 검증하지도 해석하지도 않는다. 그 허락이 실제로 있었는지, 이 콘텐츠를 덮었는지, 그때 유효했는지, 그 사용이 허락된 것이었는지는 아무것도 증명하지 않는다는 문장이 조항에 그대로 들어 있다. 확인이 필요하면 허락을 내준 쪽의 기록을 따로 들추거나 규격 밖에서 정한 증거를 써야 한다. 초안을 읽고 이 칸을 권리 확인으로 받아들인 구현이 있다면 정식판에서는 발신자의 주장으로 다시 읽으라는 안내까지 붙어 있다.

중간에 낀 자가 기록을 내지 않으면 경로 자체가 기술되지 않는다. 에이전트가 텔레메트리에 참여하지 않는 중개자에게서 글을 받아 갔다면 남는 기록은 에이전트의 것뿐이고, 거기 실린 주소나 식별자도 그 중개자가 알려 준 값이다. 중개자가 콘텐츠를 적법하게 쥐고 있었는지, 발행사가 그 글을 내준 적이 있기는 한지는 텔레메트리만으로 세울 수 없다. 이럴 때는 발행사로 이어지는 경로를 확인된 것으로 치지 말고 미확인으로 두라는 것이 조항의 지시다. 정직하게 보고하는 에이전트라도 자기가 보지 않은 당사자에 관한 증거는 댈 수 없으니 관측 모형의 한계이지 발신자의 잘못이 아니라는 단서도 함께 붙었다. 반대로 발행사 쪽에만 기록이 남고 맞대 줄 에이전트 기록이 없는 경우도 그냥 빈칸은 아니다. 이 프로토콜을 아예 쓰지 않는 수집기이거나, 번호를 실은 헤더가 중간에서 끊긴 경우다.

저장소가 이 구조를 미해결 문제로 솔직히 적어 둔 대목이 있다. 근거와 인용 이벤트는 에이전트가 보고하는데, 그 에이전트는 라이선스에 따라 대가를 치러야 할 수도 있는 바로 그 당사자다. 1.0에서 매니페스트 서명은 정보성에 머물러 받는 쪽이 검증할 의무가 없고, 이벤트를 발신자에게 묶는 증명도 규격이 요구하지 않는다. 설령 서명을 의무로 만들어도 그것은 누가 보고했는지를 증명할 뿐 그 보고가 참인지, 빠짐없는지는 증명하지 못한다고 문서는 덧붙인다. 그래서 표본 감사나 발행사가 심어 둔 미끼 콘텐츠처럼 출처가 아니라 진실성과 완전성을 시험하는 장치에 관심이 있다고 적어 두었다.

지켰는지를 가리는 층은 아예 다른 문서에 있다. 적합 마크와 인증 등급은 규격 본체가 아니라 별도의 프로필 저장소가 맡는다. 거기 적힌 유일한 등급 Compliant의 요건은 넷이다. 규격에 맞게 보낼 것, 이벤트를 묶지 말고 낱낱으로 보낼 것, 일어나는 대로 곧바로 보낼 것, 발행사가 지정한 주소로 보낼 것. 표본 추출은 발행사와 따로 합의한 경우에만 허용된다. 다만 이 프로필의 상태는 아직 0.2 프리뷰이고, 문서 스스로 1.0에 이르기 전에 요건이 바뀔 수 있다고 적는다. 재는 문서는 1.0에 이르렀는데 지키게 하는 문서는 아직 그 앞에 서 있다.

남은 것은 쓰는 쪽의 대답이다. SPUR는 발표와 함께 OpenAI와 앤트로픽, 구글, 메타, 마이크로소프트를 초청제 AI 라이선싱 자문 위원회에 불렀다. 스무 곳 안팎 규모를 목표로 하고 첫 회의는 10월 중으로 잡혔으며, 감사와 검증을 다룰 기술 위원회 첫 회의는 10월 15일로 예정됐다. 공동 창립자 데이비드 버틀은 이 위원회를 두고 양쪽 모두 자리에 앉아 함께 일할 수 있게 하는 장치라고 말했다. 그런데 발표문 어디에도 채택을 약속한 AI 기업은 없다. 구글은 SPUR를 비롯한 여러 단체와 자주 교류한다는 말만 했고 나머지는 답하지 않았다. 기술 책임자 알렉스 스프링어의 말은 더 짧다. "OpenAI가 우리 규격에 와서 의견을 준 적은 결코 없다. 알고는 있다."

이 규격이 다루는 것은 기사지만, 같은 구조가 데이터를 사고파는 자리에도 그대로 있다. 학습용 말뭉치, 라벨링 작업물, 평가용 정답지, 도메인 특화 문서 묶음은 모두 얼마나 쓰였는지에 따라 값이 달라질 수 있는 물건이다. 그런데 사용량을 어떻게 셀지가 계약서에 적히는 경우는 드물다. 적히더라도 숫자를 내는 쪽은 대개 쓰는 쪽이다. 값은 먼저 정하고 단위는 나중에 다투는 순서가 굳어 있다.

SPUR의 제안이 눈에 띄는 까닭은 그 순서를 뒤집었기 때문이다. 가격표나 계약 조항이 아니라 단위와 기록 형식부터 합의하자고 내놓았다. 문자로 셀지 토큰으로 셀지, 맥락에 들어간 순간을 셀지 출처로 적힌 순간을 셀지, 빠짐없이 적을지 표본만 적을지. 데이터 거래에서 늘 먼저 무너지는 지점이 바로 이 세 가지이고, 규격은 그것을 조항으로 끌어냈다.

다만 끌어낸 것은 단위까지다. 몇 건으로 세어 얼마를 매길지는 계약의 몫으로 남겨 두었다. 기술과 상업을 가르는 이 선은 데이터 거래에도 그대로 옮겨 온다. 같은 기록을 놓고도 데이터를 넘긴 횟수를 셀지 그 데이터가 영향을 준 결과를 하나씩 셀지에 따라 청구서의 자릿수가 달라지고, 앞에서 본 예에서 1과 3과 10이 동시에 나오는 것도 그 때문이다. 단위를 먼저 맞추는 일은 이 다툼을 없애지 않는다. 다툼이 말이 아니라 숫자 위에서 벌어지게 만들 뿐이다.

한계는 하나 더 있다. 단위를 아무리 정교하게 깎아도 기록을 내줄 의무가 없으면 칸은 비어 있는다. 그래서 데이터를 사고파는 쪽이 계약 전에 물어야 할 것이 세 가지로 정리된다. 빈칸이 드러난 자리가 그대로 질문이 된다.

• 사용량의 단위를 누가 정의하는가. 상대의 집계 도구가 정의하는 단위라면 같은 데이터가 상대에 따라 다른 양으로 계산된다.
• 보고가 전수인가 표본인가. 전수가 아니라면 기록이 없다는 사실을 사용이 없었다는 뜻으로 읽을 수 없고, 표본 규칙은 보내는 시점에 판정할 수 있는 형태여야 한다.
• 그 숫자를 적는 쪽과 돈을 낼 쪽이 같은가. 같다면 숫자를 맞대 볼 두 번째 관측자를 계약에 넣어 두어야 한다. 심어 둔 미끼 데이터든 양쪽이 따로 남기는 접근 기록이든, 사후에 만들 수는 없는 장치다.

세 질문 모두 데이터를 넘긴 뒤에는 답하기 어렵다. 어떤 기록을 어느 형식으로 남길지는 데이터가 오가기 전에 정해지는 문제이기 때문이다. SPUR가 값 이야기를 잠시 미루고 기록 형식부터 공개한 것도 같은 판단으로 보인다.

여기까지 읽어 주셔서 감사하다. 이 글의 조항 인용은 콘텐츠 텔레메트리 규격 전문과 적합 프로필 저장소에서 직접 확인했고, 채택 현황과 발언은 디지데이와 미디어코파일럿의 보도에서 가져왔다. 여러분의 팀은 데이터 사용량을 무엇으로 세고 있는지, 그 숫자를 누가 적는지 나눠 주시면 좋겠다.

1차 출처

• 1.SPUR Coalition. (2026). "Updates."
• 2.SPUR Coalition. (2026). "Content Telemetry Specification v1.0." GitHub.
• 3.SPUR Coalition. "SPUR Content Telemetry Profile." GitHub.

업계·보도

• 4.Press Gazette. (2026). "SPUR publishes common language for tracking AI use of publisher content."
• 5.ITBrief. (2026). "Publishers launch standard to track AI use of content."
• 6.Digiday. (2026). "SPUR publishes AI content tracking standard, pitches OpenAI and Google to join advisory board."
• 7.FourWeekMBA. (2026). "SPUR, AI, Content Telemetry 1.0: Characters Over Tokens."
• 8.Media Copilot. (2026). "SPUR AI Content Tracking Standard."
• 9.Media Copilot. (2026). "AP Joins SPUR AI Content Licensing Standards."
• 10.ExchangeWire. (2026). "Digest: SPUR unveils AI content tracking standard, Singapore digital economy reaches $113bn."