JSON/YAML/TOML 설정 비교: 개발자용 선택 가이드

JavaScript에서 유래한 JSON은 경량의 크로스플랫폼 데이터 교환 형식으로 설계되었습니다. 문법 규칙은 ECMAScript 표준을 기반으로 하며 기계 파싱의 신뢰성을 우선시합니다. RFC 8259는 구조화된 데이터의 크로스 시스템 전송을 핵심 목적으로 명시적으로 정의합니다.

YAML Ain't Markup Language의 약자인 YAML은 사람이 읽을 수 있는 설정 데이터로 포지셔닝됩니다. 수동 편집의 장벽을 낮추는 것을 우선시하며 들여쓰기 기반 구조를 통해 계층적 작성을 단순화하고 비기술 인력이 설정을 편집해야 하는 시나리오에 적합합니다.

Tom's Obvious, Minimal Language의 약자인 TOML은 의미가 명확한 설정 형식으로 설계되었습니다. 설정 의미는 모호하지 않게 파싱될 수 있어야 한다고 주장하며 명시적인 섹션화와 키-값 구조를 통해 모호한 해석을 피합니다.

세 형식 간의 공통 기능 차이는 설정 작성 경험에 직접적인 영향을 미칩니다. JSON은 주석을 위한 공간을 예약하지 않았으며 대부분의 파서가 주석 문법을 지원하지 않습니다. YAML과 TOML은 모두 네이티브로 단일행 및 다중행 주석을 지원하므로 설정 설명을 편리하게 작성할 수 있습니다.

다중행 문자열과 날짜 타입의 차이는 다른 시나리오의 요구 사항에 대응됩니다: YAML은 다중행 설명이나 템플릿 내용을 작성하기에 적합한 반면 JSON은 개행문자에 이스케이프 처리를 요구하며 호환성은 일관되지만 작성이 번거롭습니다.

JSON의 가장 잘 알려진 문제는 공식적인 주석 지원이 부족하다는 점입니다. 일부 개발자가 JSON에 주석을 추가하면 표준 파서로 전환했을 때 직접 파싱 오류가 발생하여 설정을 로드할 수 없게 됩니다. JSONC와 같은 일부 파생 솔루션은 주석 지원을 추가했지만 공식 표준에 포함되지 않았습니다.

YAML에는 잘 알려진 노르웨이 문제가 있습니다: 문자열이 20:03 형식일 때 일부 파서는 이를 자동으로 Base60 시간 타입으로 변환하여 값이 1203이 되어 예상된 문자열 값과 일치하지 않게 됩니다. 이 문제는 YAML의 암시적 타입 변환 규칙에서 기인합니다.

TOML에는 암시적 타입 변환이 없습니다. 모든 값 타입은 문법으로 명시적으로 표시되며 자동으로 타입이 추론되지 않습니다. 따라서 유사한 모호성 문제가 없으며 타입 결과는 작성자의 기대와 일치합니다.

세 형식의 채택 수준은 다른 기술 스택에서 명확하게 계층화되어 있습니다. 다음은 응용 시나리오별 각 형식의 주류 상태와 해당 생태계에서의 파서 성숙도를 요약한 것입니다.

다른 형식 간 변환 시 정보 손실에 대한 고정된 경계가 존재합니다. OKfmt 형식 변환 도구는 문법 지원을 기준으로 유효 정보를 보존하고 호환되지 않는 내용을 폐기합니다. JSON을 YAML 또는 TOML로 변환할 때 네이티브 정보가 손실되지 않으며 모든 구조를 완전히 매핑할 수 있습니다.

YAML을 JSON으로 변환하면 YAML의 주석과 네이티브 날짜 타입 정보가 손실됩니다. JSON이 이 두 기능을 지원하지 않기 때문입니다. TOML을 JSON으로 변환하면 주석만 손실되고 모든 구조 타입은 완전히 매핑할 수 있습니다. YAML을 TOML로 변환하면 네이티브 날짜 타입은 해당 형식의 문자열로 변환되고 주석은 완전히 보존됩니다.