TOON vs JSON: 현실 점검 — 토큰을 절약할 때와 절약하지 못할 때

Source: Dev.to

Introduction

최근 TOON(Token‑Oriented Object Notation)에 관한 기사들이 많이 나오고 있으며, 많은 글이 “50 % 토큰 절감”이라고 주장하거나 LLM 애플리케이션에 JSON이 “구식”이라고 말합니다. 실제 수치를 분석해 보면 결론은 명확합니다:

• TOON은 실제로 유용하지만, 마케팅에서는 현실을 과도하게 단순화합니다.
• “50 % 절감” 수치는 보통 포맷된(예쁘게 출력된) JSON을 기준으로 측정한 것이며, 실제 LLM에 전달되는 압축(minified) JSON과는 다릅니다.

압축된 JSON—실제 사용되는 기준—과 비교하면 상황이 크게 달라집니다.

Token‑Savings Overview

핵심 요약: 데이터 구조에 따라 TOON은 토큰 사용량을 15‑20 % 증가시킬 수 있습니다.

How TOON Saves Tokens

TOON은 헤더에 필드 이름을 한 번 선언하고, 균일 배열에 대해 CSV‑와 같은 행으로 값을 스트리밍합니다.

users[3]{id,name,role}:
1,Alice,admin
2,Bob,user
3,Carol,user

동등한 압축 JSON

{"users":[{"id":1,"name":"Alice","role":"admin"},{"id":2,"name":"Bob","role":"user"},{"id":3,"name":"Carol","role":"user"}]}

절감은 각 레코드마다 "id":, "name":, "role": 를 반복하지 않음으로써 발생합니다. 레코드가 100개가 되면 토큰 감소 효과가 크게 나타납니다.

When TOON Becomes Less Efficient

표 형식이 아닌 데이터에 대해서는 TOON이 YAML‑스타일 들여쓰기로 전환되는데, 이는 압축 JSON보다 토큰이 더 많이 소모될 수 있습니다. 이유는 다음과 같습니다:

• 들여쓰기와 같은 공백이 토큰을 차지합니다.
• 키가 각 중첩 객체마다 반복됩니다.
• 작은 객체는 JSON의 간결한 중괄호보다 오버헤드가 더 큽니다.

Example: Configuration Object

압축 JSON

{"debug":true,"maxRetries":3,"timeout":5000,"features":{"darkMode":true,"beta":false}}

TOON 표현

debug: true
maxRetries: 3
timeout: 5000
features:
  darkMode: true
  beta: false

압축 JSON이 토큰 효율이 더 높은 이유는 줄바꿈이나 들여쓰기가 없고, 구두점 토큰이 이미 최소화되어 있기 때문입니다.

Practical Guidance: When to Use Which Format

TOON을 사용해야 할 경우

• 균일한 객체 배열이 대량인 경우(≈ 100개 이상의 레코드, 필드가 일관된 경우).
• 데이터가 주로 표 형식인 경우(사용자 목록, 제품 카탈로그, 로그 항목, 분석 데이터).
• 배열의 모든 객체가 동일한 필드를 공유할 때.

압축 JSON을 사용해야 할 경우

• 페이지네이션된 API 결과와 같이 배열 외에 메타데이터가 포함된 경우.
• 깊은 중첩이 있는 경우(조직도, 재귀 트리).
• 설정 객체나 기능 플래그를 전송할 때.
• 객체마다 필드가 다르게 구성된 경우(희소 데이터).
• 혼합 구조(일부 배열, 일부 중첩 객체)가 존재할 때.
• 단일 평면 객체인 경우.

순수 CSV를 고려해야 할 경우

• 데이터가 계층 구조 없이 순수히 표 형식일 때.
• 최대 토큰 효율이 필요할 때(CSV가 평면 테이블에서 TOON보다 약 30 % 더 절감).

YAML vs. JSON vs. TOON

• YAML은 토큰 효율성 측면에서 가장 안 좋은 선택이며, 압축 JSON보다 약 21 % 더 많은 토큰을 사용합니다. 이는 공백이 의미를 갖고, 키가 배열 항목마다 반복되기 때문입니다.
• JSON은 대부분의 중첩 혹은 혼합 구조에서 가장 압축적입니다.
• TOON은 표 형식 최적화를 제공하지만, 데이터가 그 패턴에 맞을 때만 JSON보다 유리합니다.

LLM Compatibility Considerations

• 대부분의 LLM은 JSON을 중심으로 학습되었습니다.
• TOON을 사용할 경우 프롬프트에 포맷 설명을 추가해야 하는 경우가 많아, 토큰 절감 효과가 일부 상쇄됩니다.
• 작은 모델(예: gpt‑3.5‑turbo)은 TOON 입력을 이해하더라도 유효한 TOON 출력을 생성하는 데 어려움을 겪을 수 있습니다.
• TOON은 RFC 수준의 표준이 없으며 구현마다 차이가 있어 디버깅이 JSON보다 어려움이 있습니다.
• 기존 도구, 로거, 검증기 등이 JSON을 기대하므로 TOON을 도입하면 마찰이 발생할 수 있습니다.

Real‑World API Response Example

{"total":150,"page":1,"users":[...]}

users 배열만 TOON 최적화의 혜택을 받으며, 주변 메타데이터(total, page)는 그렇지 않습니다. 작은 메타데이터 객체에 대한 TOON 선언 오버헤드가 전체 토큰 수를 증가시킬 수 있습니다.

Recommendations

1. 실제 데이터로 테스트 – 프로덕션 페이로드를 변환기(예: json2toon.de)에 붙여넣고 토큰 수를 비교하세요.
2. 항상 압축 JSON과 비교하고, 예쁘게 출력된 JSON과는 비교하지 마세요.
3. 구조를 프로파일링 – 균일 배열은 토큰을 절감하지만 설정 객체는 절감되지 않음을 확인하세요.
4. 포맷 설명 프롬프트도 토큰 계산에 포함시키세요.
5. LLM 이해도 검증 – 대상 모델이 TOON을 안정적으로 파싱하고 생성할 수 있는지 확인하세요.

Conclusion

• 균일 배열 → TOON (20‑35 % 토큰 절감).
• 평면 표 형식 데이터 → CSV (최대 ~30 % 절감).
• 그 외 모든 경우 → 압축 JSON (가장 토큰 효율적이며 광범위하게 지원).

과대광고에 휘둘리지 말고, 자신의 사용 사례를 측정하고, 트레이드‑오프를 이해한 뒤, 워크로드에 진정으로 토큰 사용을 최소화하는 포맷을 선택하세요.

개발자들이 데이터 기반 포맷 결정을 내릴 수 있도록 json2toon.de를 만들었습니다. 실제 페이로드로 시도해 보고 실제 수치를 확인해 보세요.