TOON for LLMs: 벤치마크 성능 분석

Source: Dev.to

번역을 진행하려면 전체 텍스트(코드 블록 및 URL을 제외한 본문)를 제공해 주시겠어요? 텍스트를 받는 대로 요청하신 대로 한국어로 번역해 드리겠습니다.

JSON으로 하는 모든 API 호출이 생각보다 더 많은 비용을 초래합니다

실제 환경에서 Gemini 2.5 Flash를 사용해 추출 작업을 수행했는데, 결과는 놀라웠습니다: JSON은 TOON 형식에 비해 30–40 % 더 많은 출력 토큰을 일관되게 사용했습니다. 한 테스트에서는 JSON이 471 출력 토큰을 소비한 반면, TOON은 단 227만 사용했으며, 이는 51 % 감소에 해당합니다.

하지만 여기서 흥미로운 점은: TOON이 처음에는 70 %의 실패율을 보였습니다.

최적화를 거친 후 100 % 파싱 성공률을 달성했으며, 직관에 반하는 사실을 발견했습니다 – 신뢰할 수 있는 파싱이 필요할 때 TOON은 프롬프트 토큰을 더 적게 사용하므로 전체적으로 비용을 절감합니다. 구조화된 출력을 Pydantic 모델로 테스트했을 때, JSON은 389 출력 토큰을 필요로 했지만 TOON은 더 간단한 인코딩으로 이를 대체했습니다.

숨겨진 금광? 툴/함수 호출

TOON의 컴팩트한 형식이 가장 빛을 발하는 부분은 바로 여기이며, 응답이 다음 프롬프트가 되는 에이전시 워크플로우에서 토큰 비용을 크게 절감합니다.

이것은 이론이 아닙니다. 아래에는 실제 프롬프트, 파싱 오류, 토큰 수, 그리고 TOON을 70 % 실패율에서 프로덕션 수준으로 끌어올린 코드가 포함되어 있습니다. TOON이 JSON을 능가하는지는 사용 사례에 따라 다르며, 언제 어떤 경우에 유리한지 정확히 입증할 데이터가 있습니다.

숫자를 살펴보자

실험 #1 – 초기 TOON 실패 (성공률 70 %)

나는 간단한 테스트를 시작했다: JSON 대신 TOON을 사용해 구조화된 직무 설명 데이터를 추출하는 것이었다.

설정

프롬프트는 간단했다 — Gemini 2.5 Flash에게 역할, 기술, 경험, 위치, 그리고 책임을 직무 게시물에서 추출하도록 요청했다. 출력 형식은 논리적으로 보이는 대로 선택했으며, 실제 출력 형식을 사용해 TOON의 인코딩 구조를 보여주었다(본질적으로 대체 가능한 접근법).

프롬프트

Extract Role, Primary Skills, Secondary Skills,
Minimum Experience, Maximum Experience,
Location, Employment Type, Summary, and Responsibilities

Job Description:

Output in TOON format:

Role: ""
"Primary Skills"[2]: Python,JavaScript
"Secondary Skills"[2]: Responsibility,Communication
"Minimum Experience": ""
"Maximum Experience": ""
Location: ""
"Employment Type": ""
Summary: ""
Responsibilities[2]: Task A,Task B

예상 결과: 빈 문자열과 일반적인 자리표시자를 사용해 인코딩된 형식을 보여주면 모델이 구조를 이해할 것이라고 생각했다.

현실 점검 – 70 % 실패율

오류는 다음과 같이 나타났다:

• Error parsing TOON format for JD#2: Expected 10 values, but got 16
• Error parsing TOON format for JD#5: Missing colon after key

모델은 배열에 대해 혼란스러워했다. 때때로 Skills: Python, JavaScript, React와 같이 평평한 문자열로 출력했으며, 다른 경우에는 괄호를 시도했지만 구문이 잘못되었다.

가설: 빈 예시만 보여준 것이 문제였다. 모델은 특히 배열에 대해 실제 데이터 패턴을 볼 필요가 있었다.

토큰 사용량 (실패 시도, 성공률 70 %)

JSON 토큰 사용량 (동일 테스트)

핵심 인사이트

TOON의 압축된 구문은 관대하지 않다. JSON의 중복성({"key":"value"})은 모델이 스스로 교정하도록 돕는다. TOON의 Key: value 형식은 그런 안전망을 제공하지 않으므로, 모델은 추상적인 템플릿이 아니라 구체적인 예시를 필요로 한다.

하지만 70 %는 프로덕션에 충분하지 않았다. 이제 제대로 고쳐야 할 때다.

---

실험 #2 – 100 % 파싱 성공 달성 (그리고 토큰 트레이드‑오프)

70 % 성공률을 개선해야 했다. 해결책? 예시를 최소화하지 않기.

수정된 프롬프트

Extract Role, Primary Skills, Secondary Skills,
Minimum Experience, Maximum Experience,
Location, Employment Type, Summary, and Responsibilities

Job Description:

Output in TOON format. Example structure:

Role: "Senior Data Scientist"
Primary_Skills:
  [1]: "Machine Learning"
  [2]: "Statistical Analysis"
Secondary_Skills:
  [0]: "Big Data"
  [1]: "Cloud Platforms"
Minimum_Experience: "5 years"
Maximum_Experience: "10 years"
Location: "New York, NY or Remote"
Employment_Type: "Full-time"
Summary: "Lead data science initiatives"
Responsibilities:
  [0]: "Design ML models"
  [1]: "Analyze datasets"

Now provide the extraction in TOON format. Keep the format exactly as shown above.

결과: 100 % 파싱 성공. 더 이상 배열이 잘못 형성되지 않았고, 콜론이 누락되는 일도 없었다.

단점: 프롬프트가 무거워졌다.

토큰 비교 – TOON vs JSON (동일 10개 직무 설명)

불편한 진실

For basic extraction tasks, optimized TOON costs MORE than JSON.

• Output is slightly more compact (455 vs 471 tokens).
• The verbose prompting needed for 100 % reliability erases any savings.
• In fact, you’re paying ~5 % more per request.

---

왜 TOON 테스트를 계속해야 할까?

이유는 기본 비교가 오해를 불러일으키기 때문입니다. 실제 LLM 애플리케이션은 데이터를 한 번만 추출하지 않고 구조화된 출력을 다음과 같이 사용합니다:

• Pydantic 모델 검증 (네이티브 SDK 지원)
• 도구/함수 호출 (출력이 입력이 되는 경우)
• 다중 턴 에이전트 워크플로

이러한 시나리오에서는 압축된 출력 형식으로 인한 토큰 절감 효과가 크게 나타날 수 있으며, 특히 동일한 구조화 데이터를 반복적으로 전달할 때 더욱 그렇습니다.

---

요약

• JSON은 관대하고 최소한의 프롬프트로도 올바르게 만들기 쉽지만, 더 많은 출력 토큰을 사용합니다.
• TOON은 출력 토큰을 크게 줄일 수 있지만, 신뢰할 수 있는 파싱을 위해서는 더 풍부한 프롬프트(실제 예시, 명시적인 배열 구문)에 투자해야 합니다.
• 구조화된 데이터가 재사용될 때(예: 도구 호출, 에이전트 루프), TOON의 압축 형식으로 인한 토큰 절감이 추가 프롬프트 비용보다 클 수 있습니다.

사용한 코드 스니펫과 토큰 카운트 스크립트를 자유롭게 살펴보세요; 아래 링크된 저장소에 포함되어 있습니다. 토큰 최적화 즐기세요!

실험 #3: Pydantic 모델 — SDK가 무거운 작업을 담당

여기서부터가 흥미로워집니다. 최신 LLM SDK는 Pydantic 모델을 사용한 구조화된 출력에 대한 일등급 지원을 제공합니다. 프롬프트 엔지니어링 대신 스키마를 정의하고 SDK가 포맷팅을 처리하도록 하면 됩니다.

핵심 차이점: 프롬프트에 출력 형식을 설명할 필요가 없습니다 — SDK가 Pydantic 모델에서 자동으로 추출합니다.

설정: Google의 GenAI SDK

같은 작업‑추출 과제를 사용했지만 이번에는 Pydantic 모델을 사용했습니다:

response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents=prompt,
    config={
        "response_mime_type": "application/json",
        "response_schema": JobModel,
    },
)

보이는 것에 주목하세요: 출력 형식 지시문, 예시, “이 정확한 키들로 JSON 출력” 같은 것이 없습니다.

SDK가 배경에서 스키마를 주입합니다.

회원이 되세요 – SDK가 배경에서 스키마를 주입합니다.

토큰 비교: Pydantic JSON vs. 수동 TOON

잔인한 결론

강력한 SDK 지원이 있는 구조화된 추출에서는 Pydantic이 빛을 발합니다. 네이티브 Pydantic 통합은 다음을 제공합니다:

• ✅ 더 깔끔한 프롬프트 (~155개의 프롬프트 토큰 감소)
• ✅ 더 작은 출력 (~66개의 출력 토큰 감소)
• ✅ 커스텀 파싱 로직 불필요
• ✅ 내장 타입 검증
• ✅ 파싱된 객체가 바로 반환되어 바로 사용 가능
• ✅ 훨씬 부드러운 개발자 경험

이 때문에 구조화된 추출에서는 점점 더 Pydantic과 네이티브 파싱 지원에 의존할 것입니다. 이는 파싱과 검증을 수동으로 처리하는 것보다 훨씬 신뢰성 있고 유지보수가 용이합니다.

참고: JSON의 장황함이 실제 위험이 되는 경우가 하나 있습니다: 에이전트 워크플로우에서의 툴 호출. 바로 그때 TOON이 가치를 발휘합니다.

Experiment #4: Tool Calling — Where TOON Finally Wins

에이전트 기반 워크플로우에서는 LLM이 데이터를 한 번만 추출하지 않습니다 — 도구를 호출하고, 결과를 받아서 그 결과를 가지고 추가로 추론합니다. 도구의 응답이 다음 프롬프트의 일부가 됩니다. 만약 그 응답이 JSON 구문으로 부풀려져 있다면, 출력으로 한 번, 입력으로 또 한 번 비용을 지불하게 되는 것입니다.

Insight: 도구 결과는 순수 토큰 낭비입니다. 모델은 {"key": "value"} 같은 형식이 필요하지 않고, 효율적으로 인코딩된 데이터만 필요합니다.

The Setup: Weather Agent with Function Calling

get_current_weather 함수를 호출하는 간단한 에이전트를 만들었습니다. 사용자가 날씨를 물어보면 모델이 도구를 호출하고, 함수가 데이터를 반환하며, 모델이 그 응답을 종합해 답변을 생성합니다.

Version A: JSON Tool Response

data = {
    "location": location,
    "current": {
        "temperature": "72 F",
        "condition": "sunny",
    },
    "forecast": forecast,
}

return json.dumps(data)   # Returns JSON string

Version B: TOON Tool Response

data = {
    "location": location,
    "current": {
        "temperature": "72 F",
        "condition": "sunny",
    },
    "forecast": forecast,
}

return encode(data)        # Returns TOON‑encoded string

Main code

response = client.models.generate_content(
    model="gemini-2.5-flash",
    contents="What is the weather like in New York? Share next 15 days forecast as well.",
    config=types.GenerateContentConfig(
        tools=[get_current_weather],
    ),
)

Result Token Usage

• Initial prompt tokens: 152 (user message + tool definition)
• Tool‑response tokens (becomes input): 480 ✅ (24 % reduction)
• Model’s final output: 384 (slightly longer, but reasonable)
• Total tokens: 1,016 ✅ (11.5 % reduction overall)

Why TOON Wins in Agentic Workflows

Single Tool Call

Multi‑Turn Agent (5 tool calls)

• JSON: 632 × 5 = 3,160 tokens
• TOON: 480 × 5 = 2,400 tokens

Savings: 760 tokens (24 %)

The Compounding Effect

• Tool results are pure input tokens — you pay for them every time.
• Verbosity multiplies — JSON의 {} , : , , 구문이 중첩 데이터에 20‑30 % 정도의 오버헤드를 추가합니다.
• No parsing penalty — 모델이 TOON을 동일하게 쉽게 소비합니다 (후속 테스트에서 검증됨).
• Scales with agent complexity — 도구가 많을수록 절감 효과가 커집니다.

결론

네 가지 시나리오를 테스트한 결과, 데이터가 말해줍니다:

• TOON은 단일 추출에서 손해입니다. 수동 프롬프트를 사용하든 Pydantic 모델을 사용하든, SDK 지원이 포함된 JSON이 더 깔끔하고, 비용이 적게 들며, 신뢰성이 높습니다. 네이티브 스키마 통합을 통한 17.6 % 토큰 절감이 TOON의 수동 방식보다 매번 우위에 있습니다.

• TOON은 에이전트에 중요한 툴‑콜 워크플로에서 승리합니다. LLM의 출력이 다음 프롬프트가 될 때—데이터가 모델과 함수 사이를 반복적으로 순환할 때—툴 호출당 약 24 % 감소는 호기심 수준을 넘어 실질적인 비용 절감 이점으로 바뀝니다.

요약하면: Pydantic/JSON을 사용해 간단한 구조화된 추출을 수행하고, 모델이 자체 툴 출력을 반복적으로 소비하는 에이전시·툴‑콜 파이프라인에서는 TOON으로 전환하세요.

# king 20 tool calls saves 3,040 tokens per session

**The decision matrix is simple:**

- **Building a chatbot that extracts structured data?**  
  Use **JSON + Pydantic**.

- **Building an agent that calls tools 10+ times per session?**  
  Test **TOON**.

- **Building anything else?**  
  Profile first, optimize later.

직접 해보기

저는 모든 실험, 프롬프트, 그리고 토큰 측정치를 오픈소스했습니다:
View complete code and results on GitHub Gist

리포지토리에는 다음이 포함됩니다:

• ✅ 실제 프롬프트가 포함된 네 가지 실험 설정 모두
• ✅ 모든 테스트 케이스에 대한 토큰 사용 로그
• ✅ 나란히 비교할 수 있는 스크립트
• ✅ 테스트에 사용한 직무 설명

TOON은 마법이 아니라 수학입니다. 이 수학은 토큰 효율성이 실제로 중요한 경우에만 효과가 있습니다. 대부분의 애플리케이션에서는 JSON 생태계의 장점이 절감 효과보다 큽니다. 하지만 토큰을 많이 사용하는 에이전시 워크플로우에서는 TOON이 비용을 상쇄할 수도 있습니다.