모든 LLM 와이어 포맷 (wire format)은 토큰 절약 효과를 주장합니다. 하지만 AI 모델이 대규모 환경에서 실제로 해당 포맷을 이해할 수 있는지, 혹은 그 포맷으로 유효한 출력을 생성할 수 있는지는 아무도 증명하지 못했습니다.

우리는 10개의 모델과 3개의 제공업체를 대상으로 23개의 이해도 평가 (comprehension evals)를 수행했습니다. 또한 11개의 모델을 대상으로 생성 평가 (generation evals)를 진행했습니다. 결정론적 정답 (Deterministic ground truth)을 사용했으며, LLM 판정관 (LLM judge)을 사용하지 않았습니다. 단 한 번의 명령으로 재현 가능합니다.

JSON은 500개의 레코드에서 깨집니다. GPT-5.5는 빈 문자열을 반환합니다. 답변을 시도조차 할 수 없습니다. Opus는 500을 356으로 잘못 세고는, 자신의 틀린 답을 검증하기 위해 143줄에 걸쳐 수동으로 기호를 나열합니다. "인간의 가독성"을 위해 설계된 포맷이 정작 이를 읽는 시스템에게는 이해 불가능한 상태입니다.

TOON은 유효한 출력을 생성하지 못합니다. 지구상에서 가장 유능한 모델인 Claude Opus조차 TOON 생성에서 0/5점을 기록했습니다. GPT-5.4: 0/5. GPT-5.4-mini: 0/5. Gemini 3.1 Flash Lite: 0/5. 오류는 항상 동일합니다: toon: cannot assign string to int. 모델이 거리(distance) 컬럼에 "target"이라고 작성합니다. TOON은 0을 기대합니다. 모든 모델이 동일한 방식으로 실패하는데, 이는 포맷의 설계가 모델이 프롬프트 없이 수행할 수 없는 부자연스러운 인코딩 (encoding) 단계를 강제하기 때문입니다.

GCF는 테스트된 모든 모델에서 두 가지 차원 모두 승리했습니다. Claude Sonnet, Gemini 2.5 Pro, Gemini 3.1 Pro, Gemini 3.5 Flash에서 100% 이해도를 보였습니다. 모든 프론티어 모델 (frontier model)에서 5/5의 유효한 생성을 기록했습니다. 사전 학습 (prior training)은 전혀 없었습니다. 이 포맷은 우리가 만들기 전까지 존재하지 않았음에도 불구하고, 모든 모델이 이를 네이티브하게 구사합니다.

이해도: 500개의 기호, 13개의 질문, 지시 사항 없음

500개의 기호와 200개의 엣지 (edge)로 구성된 코드 그래프입니다. GCF, TOON, JSON으로 인코딩되었습니다. 13개의 구조화된 추출 질문이 주어집니다. 모델은 페이로드 (payload)와 질문을 받습니다. 포맷에 대한 지시 사항도, 시스템 프롬프트 (system prompt)도, 힌트도 없습니다.

23회 실행. 22회 승리. 0회 패배.

동일한 페이로드(payload)에 대한 토큰 비용

JSON이 대규모 환경에서 실패하는 방식

8개의 심볼(symbols)에서는 JSON이 100점을 기록합니다. 모든 것이 완벽하게 작동합니다. 하지만 500개의 심볼에서는 무너집니다.

GPT-5.5는 빈 문자열(empty strings)을 반환합니다. 오답을 내는 것이 아닙니다. 아무것도 내놓지 못합니다. 모델은 {"qualifiedName": "...", "kind": "...", "score": ..., "provenance": "...", "distance": ...}가 500번 반복된 53,341개의 토큰을 전달받고는 어떤 응답도 생성하지 못합니다. "심볼이 몇 개인가요?"라고 물으면 ""를 반환합니다. 어텐션 메커니즘 (attention mechanism)이 2,500개의 동일한 필드 이름 토큰에 파묻혀 버리는 것입니다.

Claude Opus는 500을 356으로 잘못 계산합니다. 그러고는 심볼을 수동으로 나열하며 검증을 시도합니다. 143줄에 달하는 사고 사슬 (chain-of-thought) 열거가 이어집니다. 출력 토큰을 낭비합니다. 그럼에도 여전히 오답을 냅니다. 세계에서 가장 유능한 모델조차 구조적 노이즈 (structural noise)가 신호 (signal)를 압도하기 때문에 JSON 객체를 셀 수 없습니다.

모든 모델이 거리 필터링 (distance filtering)에서 실패합니다. "거리가 0인 심볼이 몇 개인가요?"라는 질문은 500개의 JSON 객체를 파싱하고, 각 객체의 distance 필드를 읽고, 일치하는 항목을 세어야 합니다. 정답은 166입니다. Opus는 200이라고 답합니다 (대신 가장자리 개수를 읽어버립니다). GPT-5.4는 300-404 사이로 답합니다. GPT-5.4-mini는 300이라고 답합니다.

JSON은 모든 레코드마다 "qualified_name":, "kind":, "score":, "provenance":, "distance":를 반복합니다. 이는 의미론적 내용 (semantic content)이 전혀 없는, 구조적으로 동일한 2,500개의 토큰입니다. 이들은 인간의 가독성을 위해 존재합니다. 하지만 소비자는 인간이 아닙니다.

TOON이 그룹화에서 실패하는 방식

TOON은 개수 세기(counting) 측면에서는 JSON보다 성능이 좋습니다. symbol_count=500은 정확히 맞춥니다. 하지만 열 값(column value)을 기준으로 필터링이 필요한 작업에서는 실패합니다.

거리 그룹화(Distance grouping)는 모든 모델에서 실패합니다. "타겟(거리 0)은 몇 개인가?"라는 질문은 500개의 TOON 행을 스캔하고 마지막 열을 기준으로 필터링해야 합니다. 정답은 166입니다.

• Opus: 107 (extended_count 기준)
• Haiku: 100, 200, 214
• GPT-5.4: 169, 229, 200
• GPT-5.4-mini: 26, 28

답변은 실행할 때마다 매우 일관성이 없습니다. 모델들이 체계적으로 틀리는 것이 아니라, 추측을 하고 있는 것입니다. TOON에는 거리 그룹을 위한 섹션 헤더(section headers)가 없습니다. "타겟이 몇 개인가?"에 답하는 유일한 방법은 모든 행을 스캔하여 세는 것뿐입니다. 500개의 행에 도달하면 모델들은 포기하고 반올림된 숫자를 추측합니다.

500번째 행에 도달하면 주의력(Attention)이 감퇴합니다. "마지막 심볼의 종류는 무엇인가?"는 매우 쉬운 질문이어야 합니다. 하지만 여러 모델에서 TOON은 "interface" 대신 "method"라고 답합니다. 모델이 평면 테이블(flat table)의 500번째 행에 도달할 때쯤이면, 주의력은 노이즈 수준으로 희석되어 버립니다.

GCF가 두 문제를 해결하는 방식

GCF의 답변은 계산(computational)이 아닌 구조적(structural)입니다.

"심볼이 몇 개인가?" 헤더를 읽습니다: symbols=500. 끝.

"엣지(edges)가 몇 개인가?" 섹션 헤더를 읽습니다: ## edges [200]. 끝.

"타겟이 몇 개인가?" ## targets의 라인 수를 셉니다. 섹션 경계가 그룹화 정보를 무료로 제공합니다. 열 필터링도 필요 없고, 500개의 행을 스캔할 필요도 없습니다.

"마지막 심볼의 종류는 무엇인가?" ## extended의 마지막 라인이 마지막 심볼입니다. 모델은 마지막 섹션의 마지막 라인을 읽기만 하면 됩니다. 500개의 평면 행을 가로지르는 주의력 감퇴가 발생하지 않습니다.

GCF 중앙값 오차 크기: 4 (토큰화(tokenization) 아티팩트로 인한 1 차이 오류).
TOON 중앙값 오차 크기: 53 (이해 실패).
JSON 중앙값 오차 크기: 56 (구조적 과부하).

이 격차를 만드는 하나의 설계 결정은 바로 계층적 섹션(hierarchical sections) 대 평면 테이블(flat tabular)의 차이입니다. GCF는 카테고리별로 데이터를 그룹화합니다. 반면 TOON과 JSON은 평면 리스트를 제시하며 모델이 원시 값(raw values)으로부터 그룹화를 직접 계산하도록 강제합니다. 규모가 커지면 그 계산은 실패합니다.

생성(Generation): TOON은 망가져 있다

우리는 모든 모델에게 각 포맷에 맞춰 구조화된 출력(structured output)을 생성하도록 요청했습니다. 프롬프트에는 3줄 분량의 입문 가이드(primer)를 포함했습니다. 출력값은 실제 디코더(decoder)를 통해 검증되었으며, 별도의 추가적인 도움(hand-holding)은 제공하지 않았습니다.

11개 모델. 3개 제공업체. GCF가 모든 곳에서 작동하는 유일한 포맷입니다.

어떤 모델도 GCF로 학습된 적이 없습니다. 우리가 GCF를 만들기 전에는 존재하지도 않았습니다. 그럼에도 불구하고 모든 프론티어 모델(Frontier model: Opus, Sonnet, GPT-5.5, Gemini 2.5 Pro, Gemini 3.1 Pro)은 3줄의 입문 가이드만으로 첫 노출 시 디코더가 파싱 가능한 유효한 출력을 생성해냈습니다.

TOON은 이미 몇 달 전부터 공개되었습니다. 문서, 예시, 플레이그라운드(playground), SDK 구현체까지 갖추고 있습니다. 하지만 Claude Opus는 0/5점을 기록했습니다. Gemini 3.1 Pro도 0/5점입니다. GPT-5.4도 0/5점입니다.

정확한 실패 원인

모든 TOON 생성 실패는 동일한 오류를 발생시킵니다:

INVALID: symbols: index 0: distance: toon: cannot assign string to int

모델은 다음과 같이 작성합니다:

symbols[5]{name,kind,score,provenance,distance}:
  pkg/api.HandleRequest,function,0.95,lsp_resolved,target

TOON이 기대하는 값은 다음과 같습니다:

symbols[5]{name,kind,score,provenance,distance}:
  pkg/api.HandleRequest,function,0.95,lsp_resolved,0

모델에게는 "이 심볼은 target이다"라고 알려줍니다. 그러면 모델은 target이라고 작성합니다. TOON의 디코더는 정수(integer) 0을 기대하기 때문에 이를 거부합니다. 모델은 별도의 프롬프트 없이도 "target"은 0에, "related"는 1에, "extended"는 2에 매핑된다는 사실을 스스로 알아야 합니다. 어떤 모델도 이렇게 수행하지 못합니다.

이것은 학습(training)의 문제가 아닙니다. 설계 결함(design flaw)입니다. TOON의 평면적인 테이블 형식(flat tabular format)은 의미론적 범주(semantic categories)를 정수로 인코딩합니다. 모델은 포맷 자체에 구조적 단서(structural cue)가 없는 매핑 단계를 수행해야만 합니다. 언제 열(column) 값이 정수여야 하는지, 언제 문자열(string)이 허용되는지 TOON은 아무런 신호를 주지 않습니다. 모델은 잘못된 추측을 하게 됩니다.

GCF는 이러한 문제가 전혀 없습니다

GCF는 섹션 배치(section placement)를 통해 거리를 표현합니다:

## targets
@0 fn pkg.HandleRequest 0.95 lsp_resolved
## related
...

모델에게 "이 심볼은 타겟입니다"라고 알려줍니다. 그러면 모델은 이를 ## targets에 작성합니다. 정수 매핑도, 인코딩 단계도 필요하지 않습니다. 이 형식은 모델이 그룹화된 데이터를 자연스럽게 표현하는 방식과 일치합니다. 섹션은 카테고리입니다. 이것이 마크다운 (Markdown)이 작동하는 방식입니다. 모든 모델이 이미 그렇게 생각하고 있습니다.

수동 지원(Hand-holding)이 있어도 GCF가 승리합니다

프롬프트에서 거리(distance)를 정수로 명시적으로 사전 인코딩할 때 ("target" 대신 "distance 0" 사용), TOON이 통과합니다. 하지만 이는 호출자가 TOON의 내부 인코딩을 알고 있어야 하며, 모델이 유효한 출력을 작성하기 전에 모든 필드를 사전 처리해야 함을 의미합니다.

GCF는 자연어와 함께 작동합니다. 반면 TOON은 전처리 단계가 필요합니다. 그리고 그 단계가 있더라도, GCF의 출력 크기가 28% 더 작습니다.

GCF는 학습 없이도 작동합니다

어떤 모델도 이전에 GCF를 본 적이 없습니다. 이 형식은 만들어진 지 며칠 되지 않았습니다. 그럼에도 불구하고:

• Claude Opus 4.6: 5/5 유효 (2회 실행 결과 편차 없음)
• Claude Sonnet 4.6: 5/5 유효 (2회 실행 결과 편차 없음)
• Claude Haiku 4.5: 5/5 유효 (2회 실행)
• GPT-5.5: 4-5/5 유효
• GPT-5.4: 5/5 유효
• GPT-5.4-mini: 5/5 유효 (2회 실행 결과 편차 없음)
• Gemini 2.5 Pro: 5/5 유효 (2회 실행 결과 편차 없음)
• Gemini 3.1 Pro: 5/5 유효
• Gemini 3.1 Flash Lite: 4-5/5 유효 (3회 실행 결과 편차 없음)

이는 GCF가 LLM이 이미 이해하고 있는 패턴과 일치하기 때문에 발생합니다:

• ## section_name은 마크다운 (Markdown) 헤더입니다. 모든 모델이 이를 알고 있습니다.
• @0 fn pkg.Auth 0.78 lsp_resolved는 위치 기반(Positional)입니다. 필드당 하나의 토큰(Token)을 사용하며 모호함이 없습니다.
• @1<@0 calls는 4개의 토큰입니다. 자기 완결적이며 중첩된 객체(Nested objects)가 없습니다.

이 형식은 기계의 고유한 표현 패턴에 맞게 설계되었습니다. TOON은 인간의 가독성을 위해 설계되었습니다. JSON은 인간의 가독성을 위해 설계되었습니다. 두 형식 모두 실제로 작업을 수행하는 독자(Reader)를 위해 설계되지 않았습니다.

TOON 자체 벤치마크: GCF가 6개 데이터셋 모두에서 승리

우리는 TOON의 벤치마크 저장소(repository)를 포크(fork)하여 GCF 포맷터를 추가하였고, TOON의 토크나이저(tokenizer)와 방법론(methodology)을 사용하여 그들의 데이터셋을 실행했습니다.

TOON이 말 그대로 설계된 데이터셋인 평면적인 표 형식의 직원 기록(flat tabular employee records)에서도 GCF가 더 작습니다. 격차는 작지만(2%) 분명히 존재합니다. 구조가 가변적인 Semi-uniform 데이터에서는 그 격차가 42%까지 벌어집니다.

세션 상태 유지 능력 (Session Statefulness): 복리 효과의 이점

GCF에는 다른 어떤 포맷도 지원하지 않는 기능이 있습니다. 바로 세션 상태 유지 능력(session statefulness)입니다. 이전 도구 호출(tool calls)에서 확인된 심볼(symbols)들은 다시 직렬화(re-serialized)되는 대신 ID로 참조됩니다.

첫 번째 호출: 전체 페이로드(full payload). 두 번째 호출: 새로운 심볼들만 포함하며, 이전에 확인된 심볼들은 @ref ID로 처리합니다. 대화 중 5번째 호출에 이르면: 92.7%의 토큰 절감 효과가 나타납니다.

TOON과 JSON은 매 호출마다 모든 것을 다시 직렬화합니다. 호출 간 중복 제거(cross-call deduplication)를 위한 메커니즘이 없습니다. 모든 도구 응답은 모델이 이미 알고 있는 내용과 상관없이 전체 비용을 지불해야 합니다.

이것이 바로 세션이 진행됨에 따라 GCF의 이점이 복리로 쌓이는 지점입니다. 호출당 절감액(TOON 대비 32-79%)은 전형적인 에이전트 상호작용에서의 5~10회 도구 호출에 걸쳐 배가됩니다.

모든 것을 재현 가능하게 (Reproduce Everything)

평가는 오픈 소스(open source)입니다. 모든 결과는 커밋(committed)되어 있습니다. 모든 로그 파일은 저장소(repository)에 있습니다.

# 이해도 (Comprehension) (모든 제공자 대상)
cd gcf-go/eval
GOWORK=off EVAL_BACKEND=openai OPENAI_API_KEY=... EVAL_MODEL=gpt-5.5 \
...

직접 실행해 보십시오. 수치는 변하지 않습니다.

• GCF Spec
• GCF Playground
• GCF Go (comprehension eval 포함)
• GCF Python
• GCF TypeScript
• GCF Proxy (drop-in MCP 프록시, 서버 변경 불필요)
• TOON benchmark fork
• knowing (GCF가 추출된 코드 인텔리전스 엔진)