왜 포맷이 이렇게 많은가?
컴퓨터는 데이터를 주고받아야 합니다. 파일은 설정을 저장해야 합니다. API는 구조화된 응답을 보내야 합니다. 수십 년에 걸쳐 이런 작업을 처리하는 텍스트 기반 직렬화 포맷이 여럿 등장했고, 각각 고유한 철학과 장단점을 가집니다.
JSON: 웹의 기본 언어
JSON(JavaScript Object Notation)은 2000년대 초 웹 API를 위한 XML의 경량 대안으로 설계됐습니다. JavaScript 데이터 타입과 직접 매핑되기 때문에 AJAX 기반 웹 애플리케이션이 주류가 되면서 기본 선택지가 됐습니다.
여섯 가지 타입을 지원합니다: 객체(키-값 쌍), 배열, 문자열, 숫자, 불리언, null. 중괄호는 객체, 대괄호는 배열, 큰따옴표는 문자열입니다.
**장점:** 모든 언어에서 지원. 파싱이 매우 빠름. JavaScript와 브라우저 환경에 네이티브. 단순 구조에서 읽기 쉬움.
**단점:** 주석 미지원으로 설정 파일로는 어색함. 후행 쉼표 불허. 깊은 중첩에서 장황해짐. 날짜나 이진 데이터 네이티브 타입 없음.
REST API, 브라우저 스토리지, 언어·플랫폼 경계를 넘는 데이터에 최적입니다.
YAML: 사람을 위한 설정 포맷
YAML(YAML Ain't Markup Language)은 사람이 최대한 읽기 쉽도록 설계됐습니다. JSON이 중괄호와 대괄호를 쓰는 반면, YAML은 들여쓰기와 최소한의 구두점을 사용합니다.
**장점:** 가독성 최고. `#` 주석 지원. 여러 줄 문자열 처리 편리. 앵커·별칭으로 값 재사용 가능.
**단점:** 들여쓰기 민감성으로 공백 하나가 파싱 오류를 유발. 암묵적 타입 변환이 악명 높습니다. '노르웨이 문제': 국가 코드 `NO`가 일부 파서에서 불리언 false로 파싱됐습니다. `yes`도 문자열이 아닌 `true`로 파싱됩니다.
CI/CD 파이프라인, Kubernetes 매니페스트, Ansible 플레이북처럼 사람이 직접 작성하는 설정 파일에 적합합니다.
TOML: 제대로 된 설정 포맷
TOML(Tom's Obvious Minimal Language)은 GitHub 공동 창업자 톰 프레스턴-베르너가 더 예측 가능한 YAML 대안으로 만들었습니다. 설계 목표: 읽히는 대로 동작하도록 명확하게.
INI 파일처럼 `[섹션]` 문법으로 테이블을 표현하고, `=`로 값을 할당하며, 타입을 명시합니다. 날짜와 시간이 일급 타입입니다.
**장점:** 암묵적 타입 변환 없음 — 노르웨이 문제 없음. 섹션 헤더로 대형 설정 파일 탐색 편리. 날짜·시간 네이티브 타입.
**단점:** 깊은 중첩에서 장황해짐. JSON이나 YAML보다 지원이 적음(최근 많이 개선됨).
Rust의 `Cargo.toml`, Python의 `pyproject.toml` 같은 패키지 메타데이터와 예측 가능성이 중요한 설정 파일에 최적입니다.
XML: 엔터프라이즈의 베테랑
XML(Extensible Markup Language)은 1998년 W3C에 의해 표준화됐습니다. 모든 값이 여닫는 태그로 감싸이고, 속성으로 추가 메타데이터를 인라인으로 붙입니다.
이 장황함 덕분에 스키마(XSD), 변환(XSLT), 쿼리(XPath), 네임스페이스, 혼합 콘텐츠를 지원합니다. 엔터프라이즈 통합, SOAP 웹 서비스, DOCX·SVG 같은 문서 포맷의 근간입니다.
**장점:** 강력한 에코시스템(스키마, 검증, 변환). 텍스트·마크업 혼용 콘텐츠 지원. 엔터프라이즈 환경에서 광범위하게 지원.
**단점:** 장황함 — 단순 키-값에도 여닫는 태그 필요. JSON보다 파싱 느림. 신규 API 개발에서는 JSON으로 대체됨.
선택 기준
웹 API 통신이나 코드가 처리할 데이터 저장에는 **JSON**. 사람이 자주 편집하는 DevOps 설정에는 **YAML**. 예측 가능성이 중요한 프로젝트·패키지 설정에는 **TOML**. 엔터프라이즈 시스템이나 스키마 검증이 필요한 문서 포맷에는 **XML**.
포맷 간 변환이 필요할 때는 ToolPop의 JSON-YAML, JSON-XML, JSON-CSV, JSON-TOML 변환기를 활용하면 즉시 처리할 수 있습니다.