JSON vs YAML vs XML: 어떤 데이터 포맷을 써야 할까?

몇 달마다 팀에서 데이터 포맷 논쟁이 벌어져. "여기서 왜 JSON을 써? YAML이 훨씬 깔끔한데." 아니면, "XML은 스키마가 있으니까 그걸 쓰자."

사실 모든 상황에 최고인 포맷은 없어. 각각 특정 문제를 정말 잘 해결하기 때문에 존재하는 거야. 언제 어떤 포맷이 맞는지 정리해볼게.

빠른 결정 매트릭스

| 특성 | JSON | YAML | XML | |------|------|------|-----| | 사람이 읽기 쉬움 | 좋음 | 매우 좋음 | 나쁨 | | 기계 파싱 속도 | 빠름 | 보통 | 느림 | | 주석 지원 | 없음 | 있음 | 있음 | | 스키마 검증 | JSON Schema | 제한적 | XSD (강력) | | 데이터 타입 | 기본 | 풍부 | 문자열 기반 | | 공백 민감도 | 없음 | 있음 (주의!) | 없음 | | 파일 크기 | 작음 | 가장 작음 | 큼 | | 브라우저 기본 지원 | 있음 | 없음 | 부분적 | | 최적 용도 | API, 설정 | 설정, DevOps | 문서, 엔터프라이즈 |

JSON: 웹의 공용어

JSON은 웹에서 이겼어. 모든 API가 JSON을 쓰고, 모든 브라우저가 네이티브로 파싱하고, 모든 언어가 기본 지원을 해. REST API를 만들고 있다면 이미 결정된 거야.

JSON이 빛나는 곳:

• API 응답과 요청
• 패키지 매니페스트 (package.json, composer.json)
• 서비스 간 데이터 교환
• 빠른 파싱이 필요한 곳

아쉬운 점: 주석을 못 써. JSON 설정 파일에 왜 그 값이 그렇게 설정됐는지 설명을 달 수 없어. "_comment" 키로 우회하는 사람들이 있지만 그건 꼼수야.

YAML: 사람 친화적인 선택

YAML은 사람이 먼저 읽을 수 있게 설계됐어. 중괄호 없고, 대부분의 문자열에 따옴표 없고, 어디서든 주석을 달 수 있어. DevOps 팀이 좋아해 — Kubernetes, Docker Compose, GitHub Actions, Ansible — 전부 YAML을 선택했어.

하지만 YAML에는 함정이 있어: 공백이 중요해. 들여쓰기 하나 잘못하면 전체 설정이 깨져. 에러 메시지는? 종종 도움이 안 돼. "Mapping values are not allowed here"라는 메시지가 200줄짜리 설정에서 별로 알려주는 게 없어.

또한 YAML의 타입 변환이 놀랄 수 있어. yes가 true가 되고, 3.10이 3.1이 되고, 노르웨이 국가 코드 NO가 false가 돼. 버그가 아니야 — 예상치 못할 때 물어뜯는 기능이야.

XML: 엔터프라이즈의 주력

요즘 XML이 욕을 많이 먹고 있고, 일부는 당연해. 장황하거든. JSON에서 한 줄인 간단한 키-값 쌍이 XML에서는 세 줄이야.

하지만 XML은 다른 포맷이 못하는 걸 해. XSD 스키마가 강력한 검증을 제공해 — 데이터 타입, 패턴, 필수 필드, 심지어 값 범위까지 강제할 수 있어. XSLT로 문서를 변환할 수 있어. 네임스페이스가 다른 소스의 문서를 결합할 때 이름 충돌을 방지해.

의료(HL7), 금융(FIXML), 출판(DocBook) 분야에 있다면 XML은 안 사라져. 이 산업들은 엄격함 때문에 XML을 선택했고, 그 엄격함이 바로 필요한 거야.

언제 뭘 써야 할까

JSON을 선택할 때:

• 웹 API 구축
• 간단한 설정 저장
• 프론트엔드와 백엔드 사이 데이터 교환
• 빠른 파싱과 넓은 언어 지원이 필요할 때

YAML을 선택할 때:

• CI/CD 파이프라인 작성
• Kubernetes나 Docker 설정
• 주석이 도움되는 사람이 편집하는 설정 파일
• 이스케이프 문자 없는 여러 줄 문자열이 필요할 때

XML을 선택할 때:

• XML이 필요한 엔터프라이즈 시스템 작업
• 강력한 스키마 검증이 필요할 때
• 혼합 콘텐츠 문서 (데이터가 포함된 텍스트)
• 문서 타입을 결합하기 위한 네임스페이스가 필요할 때

포맷 간 변환

실용적인 현실: 포맷 간 변환이 자주 필요해. 오래된 XML 설정을 YAML로 마이그레이션하거나, API를 위해 YAML을 JSON으로 변환해야 할 수도 있어.

구조는 세 포맷 간에 꽤 깔끔하게 매핑돼. 객체가 맵이 되고 엘리먼트가 돼. 배열이 시퀀스가 되고 반복 엘리먼트가 돼. 까다로운 부분은 XML의 속성(JSON이나 YAML에 직접적인 대응이 없음)과 주석(JSON으로 변환하면 사라짐)이야.

XML과 JSON 변환이나 표 데이터 작업할 때 CSV와 JSON 변환도 할 수 있어.

진짜 답

생태계가 기대하는 걸 써. Kubernetes 설정을 쓰고 있으면 YAML을 써. 웹 API를 만들고 있으면 JSON을 써. 엔터프라이즈 의료 분야면 XML을 써.

도구와 팀의 관례에 맞서 싸우지 마. 최고의 데이터 포맷은 프로젝트의 모두가 이미 이해하는 거야.

---

데이터 포맷 논쟁은 재밌지만 우리가 생각하는 것만큼 중요한 경우는 드물어. 용도에 맞는 걸 고르고 일관성을 유지하고 진짜 문제 해결로 넘어가. 사용자는 설정 파일이 중괄호를 쓰는지 들여쓰기를 쓰는지 신경 안 써.