JSON만 있는 게 아니다 — YAML, CSV, XML, TOML은 각각 다른 필요에서 태어난 형식이며, 특히 XML 기반의 전자정부 시스템이나 금융권 레거시 API를 현대적인 JSON API와 연동해야 할 때 서로 변환하는 작업은 실무에서 흔히 발생한다.
각 형식의 용도
- YAML — 중괄호 대신 들여쓰기를 사용하며, CI/CD 파이프라인, Kubernetes, Docker Compose 설정 파일의 표준이다.
- CSV — 평면적인 표 형식으로, 스프레드시트와 데이터 분석 도구에서 가장 널리 쓰이는 최소공통 형식이다.
- XML — 더 오래된 형식으로 속성(attribute)과 네임스페이스를 지원하며, SOAP 서비스와 과거 공공기관·금융권 시스템에서 여전히 많이 쓰인다.
- TOML — 모호함이 없고 손으로 편집하기 쉽게 설계되었으며, Rust의
Cargo.toml로 잘 알려져 있다.
CSV 파일이 한글 옛 인코딩과 부딪히는 지점
과거 한국의 많은 시스템은 유니코드 대신 EUC-KR 인코딩으로 텍스트를 저장했다. 이 도구가 내보내는 CSV는 UTF-8 인코딩이므로, 엑셀에서 바로 더블클릭으로 열면 한글이 깨져 보일 수 있다 — 이럴 때는 파일을 직접 열지 말고 "데이터 가져오기" 기능으로 UTF-8 인코딩을 지정해 불러오면 한글이 올바르게 표시된다.
변환 과정에서 잃을 수 있는 것
모든 변환이 똑같이 안전한 건 아니다. JSON → CSV는 중첩 구조를 잃는다 — 깊은 객체나 길이가 다른 배열은 직사각형 표에 그대로 들어맞지 않으므로 먼저 평탄화(flatten)하거나 단순화해야 한다. 반면 JSON ↔ YAML과 JSON ↔ TOML은 거의 항상 손실 없이 변환된다. 둘 다 JSON과 같은 방식으로 중첩 구조를 지원하기 때문이다.
YAML의 자동 타입 추론 함정
YAML 파서는 따옴표 없는 값의 타입을 추측하려 한다: version: 1.20은 끝의 0을 잃고 숫자 1.2가 될 수 있고, NO라는 문자열은 YAML 1.1 규칙에 따라 불리언 false가 될 수 있다 — yes/no를 불리언 리터럴로 취급했기 때문이다. 문자열로 남아야 하는 값은 JSON으로 변환하기 전에 명시적으로 따옴표로 감싸는 게 안전하다.
실무에서 쓰이는 이유
- YAML을 기대하는 도구와 JSON을 기대하는 도구 사이에서 설정을 옮기는 경우.
- API에서 받은 데이터를 CSV로 내보내 스프레드시트에서 빠르게 확인하는 경우.
- XML/SOAP 기반의 레거시 시스템을 현대적인 JSON API와 연동하는 경우.