Token-Oriented Object Notation vs JSON: A Benchmark of Plain and Constrained Decoding Generation

이 논문은 TOON 이 인-도메인 생성 작업에서 토큰 효율성과 정확도 면에서 유망한 결과를 보이지만, 짧은 컨텍스트에서는 프롬프트 오버헤드로 인해 이점이 감소하며, 특히 단순 구조에서는 제약 디코딩을 통한 JSON 생성이 TOON 보다 더 낮은 토큰 사용량을 보여 TOON 의 효율성은 특정 임계점을 넘어 누적된 구문 절감 효과가 프롬프트 오버헤드를 상쇄할 때 비로소 실현된다는 것을 밝혔습니다.

핵심

🍽️ 상황 설정: 레스토랑의 주문 방식

우리는 AI(셰프) 에게 복잡한 주문 내역 (데이터) 을 적어달라고 요청합니다. 이때 세 가지 다른 주문 방식을 비교해 봤습니다.

1. 기존 방식 (JSON): "우리가 항상 쓰는 표준 메뉴판"입니다. AI 는 이걸 이미 다 알고 있어서 설명이 거의 필요 없습니다. 하지만 글자가 좀 길고 반복되는 부분이 많습니다.
2. 규칙 준수 방식 (JSON-SO): "표준 메뉴판이지만, 실수하지 않도록 AI 의 손에 가위와 풀을 붙여둔 상태"입니다. AI 가 틀린 글자를 쓸 수 없게 강제로 제한합니다.
3. 새로운 방식 (TOON): "새로 발명된 초간단 주문 카드"입니다. 글자 수를 획기적으로 줄였지만, AI 가 이걸 처음 보는 것이므로 처음에 사용법을 자세히 가르쳐야 (프롬프트) 합니다.

---

🔍 실험 결과: 어떤 방식이 이길까요?

1. 간단한 주문 (단순한 데이터)

• 상황: "아메리카노 2 잔, 에이드 1 잔"처럼 단순한 리스트입니다.
• 결과:
  • TOON: 설명을 해주는 데 시간이 걸려서, 오히려 전체 비용 (토큰 사용량) 이 더 비싸게 나왔습니다. (새로운 규칙을 배우는 '입문 비용'이 너무 큽니다.)
  • 규칙 준수 방식 (JSON-SO): AI 가 실수할 틈이 없게 막아주니, 가장 빠르고 저렴하게 주문이 완료되었습니다.
  • 기존 방식 (JSON): TOON 보다 조금 비싸지만, 설명 없이 바로 시작해서 나쁘지 않았습니다.

2. 복잡한 주문 (중첩된 데이터)

• 상황: "회사 조직도"처럼 계층이 깊고 복잡한 구조입니다.
• 결과:
  • TOON: 처음에 완전히 실패했습니다. (0% 성공률) 하지만 몇 번 다시 시도해 보니, 최종적으로는 가장 적은 비용으로 성공했습니다. 복잡한 구조일수록 TOON 의 '간결함'이 빛을 발하기 때문입니다.
  • 기존 방식 (JSON): AI 가 실수해서 다시 고치는 과정에서 비용이 많이 들었습니다.

---

💡 핵심 교훈 (이론의 결론)

1. "입문 비용"의 함정 (Prompt Tax)

TOON 은 글자를 아껴주지만, 처음에 "이건 TOON 이야, 이렇게 써"라고 가르쳐주는 설명서 (프롬프트) 가 너무 깁니다.

• 비유: 작은 우편물을 보낼 때, 우표 대신 "이 우편물은 TOON 형식입니다"라고 큰 박스에 적어 넣는 것과 같습니다. 우편물 자체는 작아졌지만, 박스 크기가 더 커져서 전체 비용이 더 비싼 경우가 많습니다.
• 결론: 데이터가 매우 작을 때는 TOON 이 손해입니다.

2. "대량 생산"의 기회

하지만 데이터가 엄청나게 크고 복잡해지면 이야기가 달라집니다.

• 비유: 우편물이 100 개, 1,000 개로 불어나면, TOON 의 간결함이 설명서 비용을 상쇄하고도 남습니다. 마치 "대량 생산 공장"처럼, 한 번 설정만 하면 그 이후로 엄청난 자원을 아낄 수 있습니다.
• 결론: **단순한 리스트나 거래 내역 (주문서, 영수증)**처럼 규칙적인 데이터가 대량으로 쌓일 때 TOON 이 가장 빛을 발합니다.

3. 규칙의 양면성 (JSON-SO)

AI 가 실수하지 못하게 강제로 막는 방식 (JSON-SO) 은 작고 간단한 작업에서는 최고의 효율을 냅니다. 하지만 AI 가 너무 자유롭게 생각해야 하는 복잡한 추론 작업에서는 오히려 AI 의 능력을 제한해서 실수를 유발하기도 합니다.

---

🚀 요약 및 제언

이 논문은 **"TOON 이 무조건 최고는 아니다"**라고 말합니다.

• ❌ TOON 을 쓰지 말아야 할 때:

  • 데이터가 작고 단순할 때.
  • 구조가 너무 복잡하고 꼬여 있을 때 (AI 가 혼란스러워함).
  • 실시간으로 즉석에서 한두 번만 처리할 때.

• ✅ TOON 을 써야 할 때:

  • 수천, 수만 건의 데이터를 한 번에 처리할 때 (예: 은행 거래 내역, 로그 파일).
  • 데이터 구조가 규칙적이고 단순할 때.
  • 비용 절감이 최우선이고, 한 번 설정해두면 반복해서 사용할 때.

한 줄 요약:

"TOON 은 대량 생산용의 초간단 포장재입니다. 작은 선물 하나를 보낼 때는 비싸지만, 컨테이너 하나를 가득 채워 보낼 때는 최고의 효율을 냅니다."

기술 요약

1. 문제 제기 (Problem)

대규모 언어 모델 (LLM) 에 구조화된 데이터를 전달할 때, 기존 표준인 JSON은 토큰 사용량이 많아 비용과 지연 시간의 원인이 됩니다. 이를 해결하기 위해 최근 TOON (Token-Oriented Object Notation) 이 제안되었습니다. TOON 은 JSON 을 대체하여 토큰 사용을 획기적으로 줄이도록 설계된 직렬화 형식입니다.

• 현재의 한계: TOON 은 LLM 의 이해도 (Comprehension) 측면에서 좋은 성능을 보였으나, 생성 (Generation) 측면에서의 성능, 특히 JSON 대비 효율성과 정확성에 대한 체계적인 벤치마크가 부족했습니다.
• 가설: TOON 은 훈련 데이터에 존재하지 않더라도 간단한 문법 덕분에 One-shot In-context Learning을 통해 정확한 생성이 가능할 것이며, 출력 토큰의 절감이 프롬프트 오버헤드를 상쇄할 수 있을 것이라는 가설을 검증하고자 합니다.

2. 방법론 (Methodology)

저자는 다양한 LLM 모델을 대상으로 세 가지 출력 형식을 비교하는 벤치마크를 수행했습니다.

• 비교 대상 (3 가지 트랙):

  1. Plain JSON (J): 일반적인 JSON 생성 (Pydantic 검증).
  2. JSON-SO (JSO): 구조화된 출력 (Constrained Decoding) 을 적용한 JSON. 문법 제약을 통해 유효한 JSON 만 생성되도록 유도 (예: xgrammar 기반).
  3. TOON (T): TOON 형식 생성 (One-shot 프롬프트를 통한 문맥 학습).

• 벤치마크 설계:

  • 데이터셋: 4 가지 테스트 케이스 (사용자 목록, 주문 내역, 회사 계층 구조, 송장) 를 사용. 구조적 복잡도 (단순 테이블, 중첩 배열, 깊은 계층 구조) 를 다양하게 구성.
  • 모델: 21 개의 다양한 LLM 모델 (Hermes, Qwen, Llama, DeepSeek, GPT 등) 을 Nebius API 를 통해 평가.
  • 평가 지표:
    • One-shot Accuracy: 첫 시도에서의 정확도.
    • Final Accuracy: 최대 3 회 복구 (Repair) 사이클 후 최종 정확도.
    • Token Budget: 성공적인 결과를 얻기 위해 소모된 총 토큰 수 (프롬프트 + 완성).
  • 프로세스: 모델 생성 → Pydantic 검증 → 실패 시 복구 루프 (이전 출력 + 오류 메시지 재투입) → 표준 JSON 과 비교.

3. 주요 기여 및 결과 (Key Contributions & Results)

A. 정확도 및 토큰 효율성 분석

• Plain JSON 의 우위: 대부분의 모델에서 Plain JSON이 One-shot 및 최종 정확도 면에서 가장 우수했습니다. 특히 강력한 모델들은 제약 없는 생성이 더 자연스러운 확률 분포를 따릅니다.
• JSON-SO (제약 디코딩) 의 양면성:
  • 약한 모델: 작은 모델 (예: Qwen2.5-Coder-7B) 의 경우, 제약 디코딩이 '안전장치' 역할을 하여 정확도를 0% 에서 75% 로 높이고 토큰 소모를 대폭 줄였습니다.
  • 강한 모델: 대형 모델 (예: Hermes-4-405B) 의 경우, 엄격한 문법 제약이 초기 성능을 저하시켰습니다 (92.5% → 35.0%). 복구 사이클을 거치면 회복되지만, 초기 토큰 비효율이 발생했습니다.
• TOON 의 성능:
  • 데이터 토폴로지 의존성: TOON 은 정렬된 (Aligned) 데이터 (단순 테이블, 중첩 + 균일한 배열) 에서는 좋은 성능을 보였으나, 비정렬 (Non-aligned) 데이터 (깊은 중첩, 비균일 배열) 에서는 성능이 급격히 떨어졌습니다.
  • Company Case (깊은 계층): TOON 은 One-shot 정확도 0% 를 기록했으나, 복구 사이클을 거친 후 최종 정확도 (48.6%) 는 JSON(43.8%) 보다 약간 높았습니다. 이는 TOON 의 문법적 간결함이 깊은 구조에서도 토큰 절감 효과를 발휘했기 때문입니다.

B. 토큰 경제학: "프롬프트 세금 (Prompt Tax)"과 복구 비용

• 프롬프트 세금: TOON 은 훈련 데이터에 없으므로 설명이 포함된 무거운 프롬프트가 필요합니다. 짧은 컨텍스트나 작은 출력의 경우, 이 프롬프트 오버헤드가 출력 토큰 절감분을 상쇄하여 전체 토큰 사용량이 JSON 보다 많아지는 역효과가 발생했습니다.
• 복구 루프 비용: TOON 생성 실패 시, 큰 프롬프트를 다시 컨텍스트에 넣어야 하므로 토큰 사용량이 급증합니다 (예: 송장 케이스에서 JSON 대비 2 배 이상 소모).
• 간단한 데이터에서의 JSON-SO 승리: 단순한 테이블 데이터 (Users) 의 경우, JSON-SO(제약 디코딩) 가 TOON 보다도 더 적은 토큰 (556 vs 840) 으로 높은 정확도를 달성했습니다.

C. 스케일링 가설 (Scaling Hypothesis)

TOON 의 진정한 효율성은 비선형 곡선을 따릅니다.

• 작은 데이터셋에서는 프롬프트 오버헤드가 절감분을 압도합니다.
• 하지만 대규모 데이터셋이나 긴 컨텍스트에서는 TOON 의 문법적 절감 효과가 누적되어 프롬프트 오버헤드를 상쇄하고 우위를 점할 가능성이 있습니다.

4. 결론 및 의의 (Significance & Recommendations)

이 연구는 TOON 이 만능 해결책이 아님을 명확히 보여주며, 다음과 같은 실용적인 통찰을 제공합니다:

1. 적용 영역의 명확화:

   • TOON 추천: 대량의 정형 데이터 (SQL 쿼리 결과, 주문/송장 같은 트랜잭션 문서, 로그 스트림) 등 단순하고 균일한 구조를 가진 도메인.
   • TOON 비추천: 깊은 중첩 구조, DOM 같은 복잡한 상태 트리, 비정형 데이터. 이 경우 기존 JSON 또는 JSON-SO 를 사용하는 것이 낫습니다.

2. 생산성 전략:

   • 대규모 ETL 파이프라인이나 비용 민감한 배치 처리 작업에서 TOON 은 유효한 선택지가 될 수 있으나, 스케일링 테스트를 통해 프롬프트 오버헤드가 절감 효과를 상쇄하는 임계점을 확인해야 합니다.
   • 긴 컨텍스트에서 TOON 의 들여쓰기 (Indentation) 의존성은 오류 (Drift) 위험을 높일 수 있으므로 주의가 필요합니다.

3. 기술적 시사점:

   • 제약 디코딩 (Constrained Decoding) 은 약한 모델에게는 강력한 도구이나, 강력한 모델에게는 초기 성능 저하를 유발할 수 있습니다.
   • TOON 과 같은 새로운 포맷의 효율성을 검증할 때는 출력 크기와 프롬프트 비용의 균형을 고려한 장기적인 벤치마크가 필수적입니다.

요약하자면, TOON 은 특정 도메인 (정형/거래 데이터) 과 대규모 스케일에서 JSON 을 대체할 잠재력을 가지지만, 현재로서는 프롬프트 오버헤드와 복잡한 구조에 대한 취약성으로 인해 범용적인 JSON 대체재로 즉시 도입하기에는 제한적입니다.