세 가지 형식이 기획 회의에 들어옵니다. JSON은 모든 것을 처리할 수 있다고 말합니다. CSV는 빠르고 간결하다고 말합니다. TOON은 AI와 이야기하러 왔다고 말합니다. 그들 모두 맞습니다 — 다른 작업에 대해. 불편한 부분은 이러한 형식들이 존재한다는 것이 아니라, 사용 사례에 잘못된 형식을 선택하면 실제적이고 구체적인 비용이 발생한다는 것입니다: 장황한 페이로드, 깨진 가져오기, 비싼 LLM 청구서, 또는 파싱 두통. 이 가이드는 선택에 대한 명확한 프레임워크를 제공합니다.

각 형식의 빠른 초상화

JSON (JavaScript Object Notation)은 2000년대 초 JavaScript에서 등장하여 단순성과 표현력 덕분에 웹 API의 지배적인 형식이 되었습니다. 중첩 구조를 기본적으로 처리하고, 추가적인 의식 없이 문자열, 숫자, 불리언, null을 구분하며, RFC 8259에 의해 명시되어 있습니다. 모든 현대 언어는 일급 JSON 라이브러리를 갖추고 있습니다.

CSV (Comma-Separated Values)는 웹보다 오래된 형식입니다. RFC 4180에 의해 정의되며 사실상 평면 표 형식 데이터의 공용어입니다. Excel, Google Sheets 또는 Numbers에서 CSV를 열면 그냥 작동합니다. 순수한 평면 테이블의 경우 존재하는 가장 압축적이고 보편적으로 가져올 수 있는 형식입니다.

TOON은 LLM 워크플로우를 위해 특별히 구축된 새로운 형식입니다. CSV처럼 표 형식 데이터에 헤더-한번-그다음-행 구조를 사용하지만, JSON처럼 중첩 객체와 배열을 인코딩할 수도 있습니다. 전체 설계는 대형 언어 모델로 데이터를 주고받을 때 토큰 수를 최소화하는 데 집중되어 있습니다.

세 가지 형식 모두의 동일한 데이터

이것을 구체적으로 만들기 위해 중첩된 specs 객체가 포함된 제품 카탈로그를 사용해 보겠습니다 — 세 가지 형식 모두를 의미 있게 활용하는 실제 세계 형태. 다음은 전자 상점의 네 가지 제품입니다:

JSON — 표현력이 있고 중첩을 자연스럽게 처리하지만, 반복적인 행 데이터에는 장황합니다:

json
[
  {
    "id": "P001",
    "name": "Wireless Headphones",
    "category": "Audio",
    "price": 79.99,
    "inStock": true,
    "specs": { "weight": "250g", "connectivity": "Bluetooth 5.2", "battery": "30h" }
  },
  {
    "id": "P002",
    "name": "USB-C Docking Station",
    "category": "Peripherals",
    "price": 129.99,
    "inStock": true,
    "specs": { "ports": 11, "maxPower": "100W", "display": "4K@60Hz" }
  },
  {
    "id": "P003",
    "name": "Mechanical Keyboard",
    "category": "Input",
    "price": 94.99,
    "inStock": false,
    "specs": { "layout": "TKL", "switches": "Cherry MX Red", "backlight": "RGB" }
  },
  {
    "id": "P004",
    "name": "27" IPS Monitor",
    "category": "Display",
    "price": 299.99,
    "inStock": true,
    "specs": { "resolution": "2560x1440", "refreshRate": "165Hz", "panel": "IPS" }
  }
]

CSV — 압축적이고 Excel 친화적이지만 중첩된 specs 객체를 평탄화해야 합니다. 표현하는 표준 방법이 없어서 중첩을 잃거나 문자열로 변환해야 합니다:

text
id,name,category,price,inStock,specs_weight,specs_ports,specs_layout,specs_resolution
P001,Wireless Headphones,Audio,79.99,true,250g,,,
P002,USB-C Docking Station,Peripherals,129.99,true,,11,,
P003,Mechanical Keyboard,Input,94.99,false,,,TKL,
P004,27" IPS Monitor,Display,299.99,true,,,,2560x1440
CSV에서 희박한 열을 주목하세요. 각 제품이 다른 spec 키를 가지고 있기 때문에, 가능한 모든 spec 필드에 대한 열을 만들어야 했고 — 대부분의 행은 대부분 비어 있습니다. 이것이 균일하지 않은 중첩 데이터에 CSV를 사용할 때의 근본적인 문제입니다.

TOON — 헤더는 한 번 선언되고, 행은 압축적이며, 중첩 객체는 인라인으로 인코딩됩니다:

text
products[4]{id,name,category,price,inStock,specs}:
  P001,Wireless Headphones,Audio,79.99,true,{weight:250g,connectivity:Bluetooth 5.2,battery:30h}
  P002,USB-C Docking Station,Peripherals,129.99,true,{ports:11,maxPower:100W,display:4K@60Hz}
  P003,Mechanical Keyboard,Input,94.99,false,{layout:TKL,switches:Cherry MX Red,backlight:RGB}
  P004,27" IPS Monitor,Display,299.99,true,{resolution:2560x1440,refreshRate:165Hz,panel:IPS}

각 형식이 무너지는 곳

실패 모드를 이해하는 것은 강점을 아는 것만큼 중요합니다.

  • JSON은 테이블에서 무너집니다. 모든 행에 모든 키 이름을 반복하는 것은 진짜 낭비입니다. 각 행이 8개의 키를 가진 1000행 데이터셋은 "id", "name", "price" 등을 각각 1000번 씩 작성해야 합니다. LLM 입력의 경우 이것은 직접적으로 토큰 비용으로 이어지고; 사람 검사의 경우 그냥 노이즈입니다.
  • CSV는 중첩 데이터에서 무너집니다. 형식에 중첩 개념이 없습니다. 중첩 객체를 셀에 문자열로 만들 수 있지만, 그러면 소비자가 그 셀을 파싱하는 것을 알아야 합니다 — 문제를 다른 곳으로 옮긴 것입니다. CSV에는 기본 타입 시스템도 없습니다: true는 문자열이고, 42는 문자열이며, null은 모호합니다. 도구들이 이것을 일관성 없이 처리합니다.
  • TOON은 LLM 컨텍스트 외부에서 무너집니다. 좁은 에코시스템을 가진 틈새 형식입니다. PostgreSQL, REST 프레임워크, Excel에서는 기본 TOON 지원을 찾을 수 없습니다. npm 패키지는 JavaScript/TypeScript 워크플로우를 잘 커버하지만, AI와 전혀 관련 없는 컨텍스트에서 TOON을 사용한다면 과도한 엔지니어링입니다.
  • CSV는 쉼표나 줄 바꿈이 포함된 값에서 무너집니다. RFC 4180 인용 규칙이 처리하지만, 많은 CSV 생산자와 소비자가 이를 일관성 없이 구현합니다. 27" IPS Monitor, Black과 같은 제품 이름이나 줄 바꿈이 있는 설명은 신뢰성 위험이 됩니다.

결정 매트릭스

실용적인 가이드입니다. 상황을 적절한 형식에 맞추세요:

  • 데이터가 LLM 프롬프트에 들어가는 경우 → TOON. 특히 표 형식인 경우. API 호출 전에 변환하려면 JSON to TOON을 사용하세요.
  • 데이터가 LLM에서 나오고 처리가 필요한 경우 → TOON (출력용), 그 다음 다운스트림 사용을 위해 TOON to JSON으로 JSON이나 기본 객체로 디코딩.
  • 데이터가 순수하게 평면 표 형식(모든 행에 동일한 키)이고 스프레드시트로/에서 가는 경우 → CSV. 가장 작은 표현이며 보편적으로 가져올 수 있습니다.
  • 데이터가 평면 표 형식이지만 코드(스프레드시트가 아닌)로 변환되는 경우 → CSV 또는 JSON 중 하나. 타입이 중요한 경우 JSON이 더 안전합니다(true 대신 "true"를 원하지 않습니다).
  • 데이터에 중첩 객체나 배열이 있는 경우 → JSON. CSV의 평면 전용 제한과 싸우지 마세요. 중첩이 LLM으로 가는 경우, 구조를 구축한 후 TOON으로 인코딩하세요.
  • 데이터가 REST API로 가거나 데이터베이스에 저장되는 경우 → JSON. 항상.
  • 데이터가 설정 파일인 경우 → JSON 또는 YAML. CSV도 TOON도 여기에 속하지 않습니다.
  • 최대 이식성과 의존성 없는 파서가 필요한 경우 → JSON 또는 CSV. 둘 다 어디서나 기본 또는 거의 기본 지원을 갖추고 있습니다.

하나의 파이프라인에서 세 가지 모두 사용

현실적인 파이프라인은 세 가지 모두를 사용할 수 있습니다. AI 생성 설명으로 제품 데이터를 풍부하게 하는 e-커머스 워크플로우를 상상해보세요:

ts
import { encode, decode } from '@toon-format/toon';

// Step 1: Products arrive as JSON from your REST API
const products = await fetch('/api/products').then(r => r.json());

// Step 2: Encode to TOON to minimise tokens before the LLM call
const toonInput = encode(products);

const response = await openai.chat.completions.create({
  model: 'gpt-4o',
  messages: [
    {
      role: 'user',
      content: `Here is our product catalogue in TOON format:\n\n${toonInput}\n\n
                For each product, write a one-sentence marketing description.
                Return results as TOON with fields: id, description`
    }
  ]
});

// Step 3: Decode the LLM's TOON response back to objects
const enriched = decode(response.choices[0].message.content);

// Step 4: Export to CSV for the marketing team's spreadsheet
const csvRows = enriched.map(row => `${row.id},"${row.description}"`);
const csv = ['id,description', ...csvRows].join('\n');

API 레이어에는 JSON, LLM 레이어를 통해서는 TOON, 사람이 사용할 수 있는 출력에는 CSV. 각 형식은 설계된 정확한 작업을 수행하고 있습니다.

빠른 도구 참조

이러한 형식들 사이를 이동하는 경우 이 도구들이 일반적인 변환을 처리합니다. TOON Formatter는 TOON 문자열을 검증하고 정리하는 가장 빠른 방법입니다. JSON to TOON 변환기는 LLM 준비 단계를 처리합니다. LLM이 TOON을 반환한 후 반대 방향으로 가려면, TOON to CSV가 스프레드시트 준비 내보내기를 직접 생성할 수 있고, CSV to JSON은 Excel이나 타사 데이터 제공업체에서 가져오기를 정규화하는 데 사용됩니다. TOON별 세부 정보는 공식 패키지가 npm에 있습니다.

마무리

JSON, CSV, TOON은 각각 명확한 영역을 가지고 있습니다. JSON은 중첩 또는 평면, API, 설정, 저장소 — 구조화된 데이터 교환을 위한 범용 형식입니다. CSV는 시스템과 사람 간에 이동해야 하는 평면 표 형식 데이터를 위한 범용 형식입니다 — 스프레드시트, 가져오기, 내보내기. TOON은 모든 토큰이 중요한 AI 시스템을 통해 구조화된 데이터를 효율적으로 전달하는 형식입니다. 대부분의 개발자가 저지르는 실수는 LLM 프롬프트를 포함한 모든 것에 JSON을 기본으로 사용하거나, CSV를 기본으로 사용하다가 프로젝트 중간에 중첩 요구사항을 발견하는 것입니다. 데이터의 형태를 알고, 어디로 가는지 알면, 올바른 형식은 보통 스스로 선택됩니다.

JSON vs TOON 트레이드오프에 대한 더 깊은 탐구를 위해 TOON vs JSON 비교를 확인하세요. CSV 명세와 그 특이점에 대한 배경을 위해 CSV에 대한 Wikipedia 문서가 역사와 형식 변형을 잘 다루고 있습니다.

← All TOON articles Browse all categories →