비싼 JSON 너머: LLM 파이프라인에서 TOON의 실무와 트레이드오프

XML에서 JSON으로, 이제는 LLM 중심의 표현으로 이어지면서 직렬화는 사람이 읽기 쉬움과 모델·런타임 비용 사이에서 계속 움직입니다. TOON(Token-Oriented Object Notation)은 LLM 프롬프트용 컴팩트 표현으로 주목받지만, 이 글에서는 엔지니어링 관점에서 토큰 절감, 중첩·모델 간 견고함, 변환·파싱 CPU를 나눕니다.

참고: 아래 비율·지연·토큰 수는 대표 샘플을 기준으로 한 시범적 규모입니다. 자사 데이터와 tokenizer로 재측정하세요.

요약

TOON은 JSON의 구분 기호를 줄이고 헤더 + 행 레이아웃으로 동질 컬렉션을 압축하기 쉽게 만듭니다. LLM 입력용 투영으로는 유효하지만, 공개 REST API나 정본 저장소의 JSON을 통째로 대체하는 것은 아닙니다.

---

1. 간과하기 쉬운 정보 비용

깊은 중첩과 주의 예산

JSON의 {}, 따옴표, :는 tokenizer와 컨텍스트에 그대로 탑재됩니다. 깊은 중첩이나 AST 조각에서는 구문이 구조적 노이즈가 되고 괄호 정렬 부담도 커질 수 있습니다.

TOON은 반복 구조에서 필드명을 행 간에 나누어 쓰지만, 층마다 형태가 다르면 선언 비용이 이득을 잡아먹습니다.

tokenizer 차이

동일 바이트열도 모델마다 토큰 수가 다릅니다. 보편적인 절감률은 없습니다—목표 모델과 데이터 분포로 측정해야 합니다.

---

2. JSON / YAML / TOON 비교

---

3. 세 가지 날카로운 지점

1. 깊은 이종 중첩은 이득을 줄인다

2. 모델 간 TOON 견고성

OSS/로컬에서 헤더·행 정렬이 불안정하면 JSON 우선.

3. 파싱·변환 CPU

---

4. 예시: 전자상거래 주문 목록

{
  "order_id": "992831",
  "items": [
    {"sku": "A12-B", "price": 99.0, "qty": 1},
    {"sku": "C34-D", "price": 45.5, "qty": 2},
    {"sku": "E56-F", "price": 12.0, "qty": 5}
  ],
  "customer": "John Doe"
}

order_id: 992831
items[3]{sku, price, qty}:
  A12-B, 99.0, 1
  C34-D, 45.5, 2
  E56-F, 12.0, 5
customer: John Doe

브라우저는 TOON을 네이티브 파싱하지 않으므로 게이트웨이/BFF에서 JSON↔TOON과 캐시·폴백을 설계합니다.

---

5. FAQ

Q1: TOON을 쓰면 환각(hallucination)이 늘까요?

헤더(열 정의)가 분명하고 열 개수·타입이 맞을 때는 JSON과 비슷한 수준의 필드 일치도를 기대할 수 있습니다. 반면 헤더를 최소화한 표기는 스키마가 코드와 프롬프트 양쪽에서 고정된 경우에만 쓰는 것이 안전합니다.

Q2: 지연은 어디서 생기나요?

대개 JSON→TOON 변환과 파서 구현에 집중됩니다. 큰 페이로드는 매 요청마다 변환하지 말고, 정적 코퍼스는 오프라인 변환, 동적 응답은 캐시 계층에서 TOON화하세요.

Q3: 행마다 필드 집합이 다른 다형 리스트는?

TOON의 이점이 빠르게 줄어듭니다. JSON으로 되돌리거나 스키마별로 테이블을 나누세요.

---

6. 선택 기준

• • JSON: 공개 API, JSON Schema 기반 계약 테스트, 깊은 이종 중첩, 검증 리소스가 제한적이거나, Llama 계열 등에서 TOON을 충분히 검증하지 않은 경우.

• • TOON: 토큰 비용과 컨텍스트 한도가 병목이고 데이터가 동질 테이블형에 가깝으며, 모델별 정확도 게이트를 통과한 경우.

---

관련 도구

• • JSON ⇄ TOON 변환기

• • JSON 뷰티파이어

• • JSON 검증기

• • JSON 미니파이어

맺음말: TOON은 JSON의 후계가 아니라 LLM 컨텍스트용 압축 투영입니다. 단일 절감률보다 토큰 인지 표현 설계가 중요합니다.