JSON 프롬프트 vs TOON(Tune): LLM 토큰 절감, 정말 효과 있을까?

LLM을 쓰다 보면 어느 순간 비슷한 고민에 부딪힙니다. 자연어로 프롬프트를 쓰면 말은 편한데, 모델이 애매하게 이해하거나, 토큰 비용이 폭증하는 상황이 자주 등장합니다. 이 틈을 파고든 것이 JSON 프롬프트이고, 여기에 더해 JSON을 대체하겠다고 등장한 포맷이 TOON(프로젝트 명 Tune, Token Oriented Object Notation)입니다.

표면적으로는 "JSON보다 최대 60% 적은 토큰으로 같은 데이터를 넣을 수 있다"라는 주장인데, 실제로 어느 상황에서 의미가 있고, 어디까지는 과장에 가깝고, 어떤 모델에서 잘 동작하는지를 차분히 정리해 보겠습니다.

아래에서는

• 왜 JSON 프롬프트가 유행했는지

• TOON이 어떤 구조인지, 토큰이 얼마나 줄어드는지

• 벤치마크에서 드러난 실제 성능과 한계

• LLM 활용 관점에서 어떤 선택을 해야 하는지

순서로 살펴보겠습니다.

JSON 프롬프트 열풍의 실체: 왜들 JSON에 집착할까

LLM에게 일을 시킬 때 보통 문장으로 지시를 전달합니다. 예를 들어 "월요일부터 금요일까지 일정을 요약해서 마크다운 리스트로 정리해줘" 같은 형태입니다.

문제는 이 방식이 모호하고 구조가 느슨하다는 점입니다. 모델이 대략 뜻은 이해하지만, 필드 이름을 틀리게 내보내거나, 형식이 살짝 어긋나서 후처리 코드가 망가지는 경우가 많습니다.

그래서 떠오른 아이디어가 "그럼 처음부터 JSON으로 시키면 더 잘 따르지 않을까?"입니다. 예를 들면 이런 식입니다.

• 자연어 지시 대신

• {"monday": "...", "tuesday": "..."} 같은 JSON 스키마를 보여주고, 그 구조에 맞춰 답을 쓰게 만드는 방식입니다.

겉으로는 그럴듯해 보입니다. JSON은 구조가 명확하고, 사람이 보기도 익숙하며, 코드로 파싱하기도 좋습니다. 그래서 블로그와 미디엄 글에서 "JSON prompting이 정밀한 AI 출력의 열쇠" 같은 제목이 쏟아졌습니다.

하지만 자연어 프롬프트를 JSON으로 감싸는 순간, 토큰 수가 급증한다는 문제가 등장합니다. 실제 예시에서:

• 문장형 지시문: 55 토큰

• 같은 내용을 YAML로 표현: 88 토큰

• 같은 내용을 JSON으로 표현: 115 토큰

즉, 자연어로 쓸 때보다 JSON 버전이 2배 이상 토큰을 더 쓰는 경우가 발생합니다. LLM이 "문장" 단위가 아니라 토큰 단위로 비용과 맥락을 관리한다는 점을 감안하면, 이 증가는 굉장히 부담스럽습니다.

이 지점에서 TOON이 등장합니다. JSON의 구조적 장점은 유지하되, 토큰 사용량을 줄이려는 시도입니다.

TOON(Token Oriented Object Notation)의 기본 개념과 구조

TOON(프로젝트 이름 Tune)은 이름 그대로 "토큰 친화적인 객체 표기법"을 목표로 설계된 포맷입니다. 목표는 단순합니다.

• JSON과 비슷한 역할을 하되

• LLM에게 넣을 때 토큰 수를 40~60% 줄여보자

• 기존 JSON을 완전히 버리는 것이 아니라, 입출력은 JSON, LLM에 넣을 때만 TOON으로 변환

예시부터 보는 편이 이해하기 쉽습니다.

어떤 JSON이 있다고 가정합니다.

• JSON 예제: 51 토큰

• 같은 내용을 TOON으로 표현: 24 토큰

실제로는 토큰이 절반 이하로 줄어든 셈입니다. 또 다른 예시에서는, 토큰 기반 비교에서:

• 예쁜 들여쓰기 JSON(pretty JSON): 77 토큰

• 공백·탭 제거한 compact JSON: 38 토큰

• YAML: 50 토큰

• TOON: 32 토큰

여기서 중요한 포인트는 두 가지입니다.

1. JSON을 "예쁘게" 포맷하면 토큰이 크게 늘어나고,

2. 공백을 제거한 JSON과 비교해도 TOON이 추가로 4~6 토큰 정도 더 줄어드는 경우가 나온다는 점입니다.

즉, TOON의 장점은 단순히 "JSON보다 줄어든다"가 아니라, 이미 최적화한 compact JSON보다도 더 줄어드는 상황이 꽤 있다는 데 있습니다.

다만, 이 숫자만 보고 판단하기에는 함정이 있습니다. 데이터 구조에 따라 TOON의 장점이 완전히 사라지거나, 오히려 JSON/YAML보다 손해를 보는 경우도 있기 때문입니다.

TOON이 잘 먹히는 패턴과 토큰 절감의 조건

TOON의 설계는 "균일한 구조의 배열"에 최적화되어 있습니다. 쉽게 말해:

• 하나의 배열 안에

• 같은 필드를 가진 객체가 여러 개 반복되는 구조

예를 들어 로그 레코드, 테이블 형태 데이터, 일부 벡터 검색 결과처럼, 각 행(row)이 동일한 필드 세트를 가지는 경우입니다.

이 경우 벤치마크에서 다음과 같은 결과가 나옵니다.

• 상위 배열이 있고, 각 원소가 동일한 구조를 가진 경우

  • pretty JSON: 796 토큰

  • compact JSON: 484 토큰

  • YAML: 612 토큰

  • TOON: 318 토큰

이 케이스에서는 TOON이 확실히 유리합니다. CSV 같은 압축성을 어느 정도 가져가면서도 구조 정보를 유지하기 때문입니다.

반대로, 깊게 중첩된 구조나 필드 구성이 제각각인 비정형 JSON에서는 상황이 달라집니다.

• 복잡하고 비균일한 JSON 데이터의 경우

  • pretty JSON → compact JSON: 371 → 199 토큰

  • YAML: 250 토큰

  • TOON: 257 토큰

이 구간에서는 TOON이 오히려 YAML보다 토큰을 더 쓰는 결과가 나오기도 합니다. 중첩 구조, 필드 이름의 다양성, 자료형 혼합이 심해질수록 TOON의 장점이 감소하거나 깨지는 양상입니다.

요약하면 TOON은:

• "한 레벨짜리, 균일한 객체 배열"에 매우 강하고

• 깊은 중첩/비정형 구조에서는 기대만큼의 이득을 보지 못하는 경향이 있습니다.

즉, TOON은 만능 데이터 포맷이 아니라, "LLM에 특정 유형의 데이터(표 형태, 균일 배열)를 넣을 때 쓰기 좋은 특수 포맷"에 가깝습니다.

JSON 프롬프트와 TOON: 정확도, 토큰, 그리고 모델별 차이

TOON 측에서 공개한 벤치마크는 토큰 수와 데이터 retrieval 정확도를 같이 보여줍니다. 여기서 확인할 수 있는 핵심 포인트는 다음과 같습니다.

1. 포맷에 따라 정확도가 꽤 크게 달라진다.

2. 모델 종류에 따라 유리한 포맷이 서로 다르다.

예를 들어, 어떤 데이터셋에서:

• compact JSON은 pretty JSON보다 토큰은 적으면서 정확도는 오히려 더 높게 나오는 경우가 있습니다.

• YAML은 토큰을 더 많이 쓰면서도 정확도가 떨어지는 케이스가 적지 않습니다.

• XML은 토큰 수가 압도적으로 많고(예: 122,000 토큰 vs TOON 72,000 토큰), 정확도도 좋지 않아 LLM 입력 포맷로는 사실상 비추천입니다.

모델별로 보면 흥미로운 차이가 드러납니다.

• Gemini 2.5 Flash: 큰 컨텍스트에서 데이터 retrieval 성능이 상당히 좋게 측정됩니다.

  • 일반 JSON 기반 파싱에서도 70%대 중후반 정확도를 안정적으로 유지합니다.

• GPT-5 Nano: 벤치마크 상에서는 Gemini 2.5 Flash보다도 데이터 retrieval에 강점을 보이는 구간이 있습니다.

• Claude Haiku 4.5: 동일 조건에서 TOON을 써도 60%를 넘기지 못하는 케이스가 나옵니다.

  • 특히 긴 컨텍스트에서 성능이 급격하게 떨어지는 양상이 관찰되어, 긴 JSON/TOON을 던져놓고 "코드를 이해해 달라"는 요청에 부정적인 결과가 나오기 쉽습니다.

이 결과는 포맷 선택만으로 모든 것이 해결되는 것은 아니다는 사실을 보여줍니다. 같은 TOON이라도 모델별로 활용 효율이 다르고, compact JSON이 pretty JSON보다 토큰을 줄이면서도 정확도를 높이는 기묘한 효과가 나오는 것도 확인됩니다.

즉, LLM에 구조화 데이터를 넣을 때 고려해야 할 변수는:

• 포맷(JSON / compact JSON / YAML / TOON / CSV 등)

• 데이터 구조(균일/비균일, 중첩 깊이, 필드 다양성)

• 사용하는 모델(Flash, Nano, Claude, Groq 등)

세 축이 동시에 영향을 미칩니다.

JSON 프롬프트의 문제점: 구조화가 아니라 자기만족인 경우

JSON 프롬프트 열풍에서 가장 큰 문제는 "형식만 JSON일 뿐, 실제로는 자연어 프롬프트를 JSON 틀에 억지로 끼워 넣는 경우"가 많다는 점입니다.

예를 들어, 이런 구조를 떠올릴 수 있습니다.

• {"instruction": "마크다운 리스트로 정리해줘", "constraints": "...", "notes": "..."}

즉, 지시 자체가 구조화 데이터가 아니라 텍스트 덩어리인데, 그냥 JSON 바깥에 있던 문장을 instruction 필드 안으로 옮겨놓았을 뿐입니다.

이렇게 되면:

• 토큰 수는 증가하고

• 모델 입장에서는 여전히 "긴 자연어 설명"을 해석해야 하며

• 구조화의 이점은 거의 없고

• 후처리 파이프라인만 복잡해집니다.

영상에서도 이런 패턴을 두고 "JSON 프롬프트는 못생기고, 비효율적이며, 똑똑해 보이려는 사람들의 자기만족에 가깝다"는 식의 비판이 나옵니다.

핵심은:

• JSON은 출력 결과를 기계가 파싱하기 좋게 만드는 용도로는 매우 유용하나

• 지시 자체를 JSON으로 감싸는 것이 모델 성능 향상이랑 직결되지는 않는다는 점입니다.

• 오히려 토큰 비용 증가, 프롬프트 유지보수 난이도 상승, 사람이 읽기 불편한 구조 등 부작용이 더 크기도 합니다.

TOON을 쓰더라도 이 함정은 그대로 남습니다. 지시가 자연어라면, JSON·TOON 밖에 있든 안에 있든 본질적으로 LLM이 하는 일은 같다는 것을 전제로 해야 합니다.

TOON을 실전에서 쓸 만한 구간: 언제 효과가 있을까

그렇다면 TOON은 어디에 쓰면 그나마 합리적일까요? 원본 내용과 벤치마크를 종합하면, 실용적인 활용 범위는 다음에 가깝습니다.

• 이미 시스템에서 JSON으로 데이터를 다루고 있다.

• 이 JSON 중 일부를 LLM에 넘겨서

  • 검색 결과 후처리

  • 수백~수천 개 row에 대한 요약

  • 필터링·분류·태깅 작업 등을 하려는 상황이다.

이 경우 프로세스는 다음처럼 그려볼 수 있습니다.

• 애플리케이션 내부에서는 JSON을 그대로 사용

• LLM에 넣기 직전에 TOON 인코더로 변환

• 프롬프트는 "이 입력은 TOON 포맷이며, 각 행은 ~를 의미한다" 정도로 간단히 안내

• LLM 출력은 다시 JSON 등 익숙한 포맷으로 변환해서 처리

이 구조의 장점은 다음과 같습니다.

• LLM 입력에서 토큰 30~60% 절감 가능(특히 균일한 배열 구조일 때)

• 같은 비용으로 더 많은 row를 전달해 retrieval 정확도 4% 정도의 개선이 관측된 사례가 있음

• 이미 JSON 기반 시스템이라면, 기존 코드를 대규모로 뜯어고칠 필요 없이 입력 직전 단 한 번의 변환만 추가하면 됨

또한 TOON 프로젝트는:

• 공식 토크나이저 패키지

• YAML/JSON ↔ TOON 변환 패키지

• CLI 기반 변환 도구

까지 제공하고 있어, 로컬 스크립트나 간단한 파이프라인에서 한 줄짜리 커맨드로 변환할 수 있습니다. 이 점은 실제 운용 측면에서 상당히 실용적인 요소입니다.

데이터 포맷 선택에 대한 제3자 관점 해석

원본 영상과 자료를 거리두고 바라보면, 몇 가지 냉정한 포인트가 보입니다.

첫째, TOON의 효용은 데이터 구조에 강하게 종속됩니다. 균일한 1단계 배열에서는 토큰 절감 효과가 크지만, 중첩이 깊거나 비정형 구조에서는 JSON/YAML 대비 우위가 희미해지거나 역전되기도 합니다. 따라서 "모든 JSON을 TOON으로 바꾸면 이득"이라는 식의 접근은 현실적 제약이 예상됩니다.

둘째, 모델별 최적 포맷이 다릅니다. Gemini 2.5 Flash, GPT-5 Nano는 큰 컨텍스트와 구조화 데이터 처리에 강점을 보이지만, Claude Haiku 4.5처럼 긴 입력에서 급격히 성능이 저하되는 모델도 존재합니다. 이 경우 포맷을 바꾸는 것보다, 애초에 모델 선택이 더 큰 영향을 줍니다.

셋째, JSON 프롬프트 자체는 과대평가된 측면이 큽니다. 형식을 JSON으로 바꾸는 것보다,

• 프롬프트를 명확하게 쪼개고

• 예시를 잘 제공하고

• 출력 포맷을 JSON으로 강제하는 것 이 훨씬 더 직접적인 성능 향상 요인입니다. 그럼에도 JSON 프롬프트가 과잉 소비되는 이유는, LLM의 비결정성 때문에 "특정 포맷이 기적을 만든다"는 서사를 믿고 싶은 심리와도 맞물려 있습니다.

넷째, TOON은 특수한 구간에서 의미 있는 공학적 선택으로 볼 수 있습니다. 수백·수천 행의 균일 데이터 배열을 반복적으로 LLM에 전달하는 워크로드라면,

• 토큰 비용 절감

• 입력 크기 확대

• retrieval 정확도 소폭 상승

을 동시에 기대할 수 있습니다. 특히 LLM API 비용이 민감한 서비스라면, 토큰 단위 절감이 누적되면서 비용 구조 최적화 도구로서 가치는 충분해 보입니다.

마지막으로, 도구의 가치는 "언제 쓰지 말아야 하는지"를 아는 데서도 결정됩니다. 영상에서도 TOON 제작자가 "모든 코드에 이 포맷을 쓰라"고 주장하지 않고, "JSON은 그대로 쓰되, LLM 입력에서만 TOON으로 감싸라"고 명확하게 선을 긋습니다. 이 점은 과장된 포맷 복음전도와는 거리가 있는, 비교적 현실적인 태도입니다.

정리하면,

• 자연어 지시 자체를 JSON/TOON으로 감싸는 JSON 프롬프트는 효율이 낮은 편에 가깝고,

• 실제 데이터(균일한 배열)를 LLM에 던지는 구간에서는 TOON이 유의미한 엔지니어링 선택지가 될 수 있습니다.

프롬프트 구조와 데이터 포맷을 어떻게 설계할지에 따라, 같은 모델·같은 비용으로 얻는 성능이 꽤 달라집니다. LLM을 기반으로 한 서비스를 설계할 때, JSON vs compact JSON vs TOON을 상황별로 시뮬레이션해 보는 과정이 앞으로 점점 더 중요해질 가능성이 커 보입니다.

출처 및 참고 :