TOON | Ayden's journal

최근 대규모 언어 모델을 활용한 애플리케이션 개발이 일반화되면서, 프롬프트에 구조화된 데이터를 어떻게 전달할 것인지가 점점 더 중요한 문제로 떠오르고 있다. 기존의 JSON은 웹 API의 표준으로서 널리 사용되고 있지만, LLM에 데이터를 전달하는 데에는 JSON이 불필요한 토큰 사용을 유발하거나 반복 구조를 지나치게 장황하게 만드는 경우가 많다.

이러한 문제를 해결하기 위해 등장한 형식이 TOON(Token-Oriented Object Notation)이다. TOON은 JSON 데이터 모델을 기반으로 설계되었지만, 프롬프트 맥락에서 효율성과 가독성을 극대화하기 위해 문법과 구조를 재구성한 포맷이다. 특히 반복되는 객체 배열과 같은 구조적 데이터를 압축적으로 표현하면서도 사람이 읽기 쉽게 유지하는 것을 핵심 목표로 한다.

TOON은 JSON과 동일하게 객체, 배열, 문자열, 숫자, Boolean, null과 같은 데이터 타입을 모두 표현할 수 있으며, 중요한 점은 이러한 데이터가 JSON ↔ TOON 간 변환되더라도 손실 없이 동일하게 유지된다는 점이다.

즉, TOON은 고유한 데이터 모델을 도입하지 않고 오직 표현 방식을 개선하는 데에 집중하며, 결과적으로 인공지능 프롬프트 환경에서 “데이터 표시 최적화 방식”이라는 역할을 갖는다. JSON이 웹 표준 데이터 포맷이라면, TOON은 LLM 프롬프트용 데이터 포맷에 더 가깝다고 볼 수 있다.

TOON의 가장 큰 특징은 들여쓰기 기반의 중첩 구조와 반복 객체 배열을 간결하게 줄여내는 배열 문법이다. 일반적인 JSON 객체는 {}와 []로 감싸야 하고 모든 속성명을 매번 반복해야 한다. 예를 들어 사용자 객체 배열을 JSON으로 표현하면 각 객체마다 모든 필드를 반복해야 한다.

반면 TOON에서는 배열을 정의할 때 필드명을 한 번만 선언하고, 이후 각 객체는 CSV와 유사한 형태로 이어서 나열하면 된다. 이 방식은 특히 JSON에서 가장 많은 토큰을 소비하는 패턴인 “objects inside arrays”를 압축하는 데에 효과적이다.

JSON에서 다음과 같은 구조가 있다고 가정하자.

1{
2  "users": [
3    { "id": 1, "name": "Alice", "role": "admin" },
4    { "id": 2, "name": "Bob", "role": "editor" }
5  ]
6}

이를 TOON으로 표현하면 다음과 같이 단 한 번의 선언으로 필드를 정의할 수 있다.

1users[2]{id,name,role}:
2  1,Alice,admin
3  2,Bob,editor

여기서 배열의 길이와 필드명이 그 자체로 하나의 스키마처럼 동작하여 LLM이나 사람 모두에게 구조를 한눈에 보여준다. JSON은 기호와 반복된 필드명으로 인해 데이터보다 “구조를 표현하기 위한 텍스트”가 훨씬 많이 등장하는 반면, TOON은 실제 데이터 비중이 훨씬 높아진다.

그 결과 LLM 프롬프트에서는 평균적으로 30%에서 60% 정도의 토큰을 절감할 수 있다는 분석도 있다. 이러한 절감은 곧바로 비용과 성능에 영향을 미치며, 특히 긴 문맥을 요구하는 프롬프트에서는 더 큰 차이를 만든다.

TOON은 배열뿐 아니라 일반적인 중첩 객체도 들여쓰기 기반으로 표현한다. 예를 들어 JSON에서 다음과 같이 작성하던 구조가 있다고 하면,

1{
2  "user": {
3    "name": "Alice",
4    "isActive": true,
5    "languages": ["Korean", "English"]
6  }
7}

TOON에서는 다음과 같은 형태로 변환된다.

1user:
2  name: Alice
3  isActive: true
4  languages[2]: Korean,English

TOON과 JSON의 차이를 문맥 중심으로 비교하면 몇 가지 중요한 관점이 드러난다. JSON은 여전히 API 통신, 웹 개발, 서버 간 데이터 교환을 위한 사실상의 표준 포맷이다. 모든 언어와 플랫폼이 JSON을 지원하며, 그 생태계는 이미 충분히 성숙해 있다. 반면 TOON은 “LLM에게 데이터 구조를 설명하기 위한 포맷”이라는 명확한 목적을 가지고 있다.

즉, JSON이 기계 친화적인 형식이라면 TOON은 LLM 친화적이며, 프롬프트에 삽입되는 데이터에 최적화된 표현식이라고 할 수 있다. 반복 구조를 가진 데이터를 프롬프트에 넣어야 하거나, 데이터 가독성을 유지하면서 토큰 비용을 줄여야 하는 시나리오라면 TOON은 JSON보다 훨씬 실용적인 대안으로 작동한다.

TOON은 실제 업무에서도 몇 가지 구체적인 사용 시나리오를 가진다. 우선 LLM을 통해 데이터 분석, 요약, 패턴 추출 등을 수행할 때 대량의 JSON 데이터를 그대로 넘기면 토큰 비용이 매우 커진다. 이때 JSON을 TOON으로 변환한 뒤 프롬프트에 삽입하면 같은 데이터를 훨씬 적은 토큰으로 전달할 수 있다. 또한 기능 명세서나 요구사항 문서처럼 개발자와 기획자, 디자이너가 함께 읽는 문서에서는 JSON보다 TOON이 훨씬 읽기 쉽고 자연스럽기 때문에 문서 가독성을 크게 향상시킬 수 있다. 마지막으로 LLM 기반 서비스에서 내부 데이터 포맷을 JSON으로 유지하되, LLM에게 전달되는 모든 데이터만 TOON으로 변환해 사용하는 전략은 데이터 구조의 일관성과 프롬프트 효율성을 동시에 확보할 수 있는 효과적인 접근 방식이다.

결론적으로 TOON과 JSON은 서로 경쟁하는 포맷이라기보다, 서로 다른 목적을 가진 두 가지 표현 방식이다. JSON은 웹과 서버 간 데이터 교환의 절대적인 표준으로 계속 사용될 것이며, TOON은 LLM 환경에서 구조화된 데이터를 더 효율적으로 전달하기 위한 전문적인 표현 방식으로 활용될 것이다.