JSON vs YAML vs XML: 언제 무엇을 쓸까?

설정 파일을 만들 때, API 응답 포맷을 정할 때, "뭘로 하지?" 고민해본 적 있으시죠? JSON, YAML, XML—셋 다 데이터를 표현하는 포맷인데, 각각 언제 쓰는 게 좋을까요?

한눈에 비교

같은 데이터를 세 가지 포맷으로 표현해보겠습니다.

JSON

{
  "name": "홍길동",
  "age": 30,
  "skills": ["JavaScript", "Python"],
  "address": {
    "city": "서울",
    "zip": "12345"
  }
}

YAML

name: 홍길동
age: 30
skills:
  - JavaScript
  - Python
address:
  city: 서울
  zip: "12345"

XML

<person>
  <name>홍길동</name>
  <age>30</age>
  <skills>
    <skill>JavaScript</skill>
    <skill>Python</skill>
  </skills>
  <address>
    <city>서울</city>
    <zip>12345</zip>
  </address>
</person>

벌써 느낌이 오시죠? YAML이 가장 간결하고, XML이 가장 장황합니다.

JSON: 웹의 표준

장점:

• JavaScript에서 바로 사용 가능 (이름부터 JavaScript Object Notation)
• 거의 모든 언어에서 지원
• 파싱 속도 빠름
• 웹 API의 사실상 표준

단점:

• 주석 불가 (설정 파일로는 불편)
• 따옴표, 콤마 등 엄격한 문법
• 사람이 직접 수정하기엔 번거로움

언제 쓸까: API 응답, 웹 데이터 교환, 프로그래밍에서 데이터 저장

YAML: 사람 친화적

장점:

• 가독성 최고 (들여쓰기로 구조 표현)
• 주석 가능 (#으로)
• 따옴표 대부분 생략 가능
• 멀티라인 문자열 지원

단점:

• 들여쓰기 실수하면 에러 (탭/스페이스 혼용 주의)
• 파싱 속도 JSON보다 느림
• 복잡한 기능(앵커, 별칭)은 혼란스러울 수 있음

언제 쓸까: 설정 파일 (Docker Compose, Kubernetes, GitHub Actions), 사람이 자주 편집하는 파일

XML: 여전히 살아있다

장점:

• 스키마 검증 (XSD로 엄격한 타입 체크)
• 속성(attribute) 지원
• 네임스페이스로 충돌 방지
• XSLT로 변환 가능

단점:

• 장황함 (태그가 데이터보다 많을 때도...)
• 파싱 복잡하고 느림
• 요즘 웹에서는 거의 안 씀

언제 쓸까: 레거시 시스템, SOAP API, 엄격한 스키마가 필요할 때, 오피스 문서 포맷 (docx는 내부적으로 XML)

한 장 요약

실전 선택 가이드

• REST API 만든다 → JSON
• CI/CD 설정 파일 → YAML (GitHub Actions, GitLab CI)
• 컨테이너 오케스트레이션 → YAML (Docker Compose, Kubernetes)
• 사내 레거시 시스템 연동 → 아마 XML
• 브라우저 로컬 스토리지 → JSON

결론: 새 프로젝트라면 대부분 JSON이나 YAML입니다. XML은 특별한 이유가 있을 때만.

JSON 심화: 문법과 데이터 타입

JSON은 Douglas Crockford가 2001년에 제안한 경량 데이터 교환 형식입니다. JavaScript의 객체 표기법에서 파생되었지만, 언어에 독립적이어서 거의 모든 프로그래밍 언어에서 사용할 수 있습니다.

JSON이 지원하는 데이터 타입은 총 6가지입니다:

• 문자열(String): 반드시 큰따옴표로 감싸야 합니다. 작은따옴표는 허용되지 않습니다.
• 숫자(Number): 정수와 소수 모두 가능합니다. 단, NaN이나 Infinity는 허용되지 않습니다.
• 불리언(Boolean): true 또는 false. 대문자 True/False는 오류입니다.
• null: 값이 없음을 나타냅니다. undefined는 JSON에 존재하지 않습니다.
• 객체(Object): 중괄호 {}로 감싸고, 키-값 쌍으로 구성됩니다. 키는 반드시 문자열이어야 합니다.
• 배열(Array): 대괄호 []로 감싸고, 순서가 있는 값의 목록입니다.

JSON에서 가장 흔한 실수는 마지막 항목 뒤에 쉼표(trailing comma)를 넣는 것입니다. JavaScript에서는 괜찮지만 JSON에서는 문법 오류입니다.

// 잘못된 JSON (trailing comma)
{
  "name": "홍길동",
  "age": 30,    <-- 여기서 오류
}

// 올바른 JSON
{
  "name": "홍길동",
  "age": 30
}

YAML 심화: 들여쓰기와 고급 기능

YAML은 "YAML Ain't Markup Language"의 약자로, 2001년에 처음 발표되었습니다. 사람이 읽기 쉬운 데이터 직렬화 형식을 목표로 설계되었고, 실제로 그 목표를 잘 달성했습니다.

들여쓰기 규칙

YAML에서 가장 중요한 규칙은 들여쓰기입니다. 탭(Tab)은 절대 사용할 수 없고, 공백(Space)만 허용됩니다. 보통 2칸 공백을 사용하는 것이 관례이며, 같은 레벨의 항목은 반드시 같은 수의 공백으로 들여쓰기해야 합니다.

앵커와 별칭

YAML의 강력한 기능 중 하나는 앵커(&)와 별칭(*)입니다. 반복되는 값을 한 번만 정의하고 여러 곳에서 참조할 수 있습니다. Docker Compose에서 여러 서비스가 같은 환경 변수를 공유할 때 매우 유용합니다.

defaults: &defaults
  timeout: 30
  retries: 3

development:
  <<: *defaults
  debug: true

production:
  <<: *defaults
  debug: false

위 예시에서 development와 production 모두 timeout: 30, retries: 3을 상속받습니다.

멀티라인 문자열

YAML은 긴 문자열을 여러 줄에 걸쳐 작성하는 두 가지 방법을 제공합니다. 파이프(|)는 줄바꿈을 유지하고, 부등호(>)는 줄바꿈을 공백으로 변환합니다.

# | : 줄바꿈 유지 (Literal Block)
description: |
  첫 번째 줄
  두 번째 줄
  세 번째 줄

# > : 줄바꿈을 공백으로 (Folded Block)
description: >
  이 문장은 한 줄로
  합쳐져서 출력됩니다

XML 심화: 태그, 속성, 네임스페이스

XML(eXtensible Markup Language)은 1998년 W3C에서 표준으로 발표했습니다. HTML과 비슷한 태그 기반 구조를 사용하지만, 태그 이름을 자유롭게 정의할 수 있다는 점이 다릅니다.

속성(Attribute) vs 요소(Element)

XML에서는 데이터를 태그의 내용으로 넣을 수도 있고, 속성으로 넣을 수도 있습니다. 일반적으로 메타데이터는 속성에, 실제 데이터는 요소에 넣는 것이 관례입니다.

<!-- 속성으로 표현 -->
<person name="홍길동" age="30" />

<!-- 요소로 표현 -->
<person>
  <name>홍길동</name>
  <age>30</age>
</person>

네임스페이스

서로 다른 XML 문서를 합칠 때 태그 이름이 충돌할 수 있습니다. 네임스페이스는 이 문제를 해결합니다. 접두어(prefix)를 사용해서 어떤 문서의 태그인지 구분합니다.

<root xmlns:book="http://example.com/book"
      xmlns:author="http://example.com/author">
  <book:title>개발 가이드</book:title>
  <author:name>홍길동</author:name>
</root>

book과 author라는 접두어 덕분에 title과 name이 어디에 속하는지 명확히 알 수 있습니다.

상세 비교: 어떤 상황에 어떤 포맷?

실무에서 만나는 대표적인 사용 사례

각 포맷이 실제로 어디에 쓰이는지 구체적으로 살펴보겠습니다.

JSON이 표준인 곳

• REST API: 거의 모든 현대 웹 API가 JSON을 사용합니다. 브라우저의 fetch API나 axios 라이브러리에서 자연스럽게 처리됩니다.
• package.json: Node.js 프로젝트의 의존성과 설정을 관리합니다.
• tsconfig.json: TypeScript 컴파일러 설정입니다. 엄밀히는 JSONC(주석 허용)를 사용합니다.
• NoSQL 데이터베이스: MongoDB, CouchDB 등은 JSON과 유사한 문서 형태로 데이터를 저장합니다.
• 브라우저 localStorage: 키-값 쌍으로 저장할 때 JSON.stringify/parse를 많이 사용합니다.

YAML이 표준인 곳

• Docker Compose: 멀티 컨테이너 애플리케이션을 정의하는 docker-compose.yml 파일.
• Kubernetes: Pod, Service, Deployment 등 모든 리소스 정의에 YAML을 사용합니다.
• GitHub Actions: .github/workflows/ 디렉토리 아래의 CI/CD 워크플로우 파일.
• Ansible: 서버 프로비저닝과 설정 관리 도구로, 플레이북을 YAML로 작성합니다.
• Spring Boot: Java 진영에서 application.yml로 설정을 관리하는 것이 점점 보편화되고 있습니다.

XML이 여전히 쓰이는 곳

• Android 레이아웃: 화면 UI를 정의하는 activity_main.xml 같은 파일.
• Maven: Java 빌드 도구의 pom.xml 파일.
• SOAP 웹서비스: 엔터프라이즈 시스템 간 통신에서 아직도 널리 사용됩니다.
• SVG: 벡터 그래픽 포맷으로, 실제로 XML의 한 종류입니다.
• RSS/Atom 피드: 블로그나 뉴스의 구독 피드입니다.

포맷 간 변환

실무에서는 포맷 간 변환이 필요한 경우가 종종 있습니다. JSON에서 YAML로 변환하는 것은 대체로 간단하지만, XML에서 JSON으로 변환할 때는 주의할 점이 있습니다. XML의 속성(attribute)을 JSON에서 어떻게 표현할지, 텍스트 노드와 자식 요소가 섞여 있을 때 어떻게 처리할지 등의 문제가 생깁니다.

예를 들어 이런 XML을 JSON으로 변환한다고 생각해보세요:

<book id="1" lang="ko">
  <title>개발 가이드</title>
</book>

// JSON으로 변환하면?
{
  "book": {
    "@id": "1",
    "@lang": "ko",
    "title": "개발 가이드"
  }
}

속성을 @접두어로 구분하는 것은 하나의 관례일 뿐이고, 라이브러리마다 변환 방식이 다릅니다. 그래서 XML-JSON 변환 시에는 변환 규칙을 미리 확인하는 것이 중요합니다.

YAML의 주의할 점: 타입 자동 추론

YAML은 편리하지만 의외의 함정이 있습니다. 값의 타입을 자동으로 추론하기 때문에 예상치 못한 결과가 나올 수 있습니다.

# 이것은 불리언 true로 해석됩니다
country: NO    # 노르웨이가 아니라 false!
answer: yes    # 문자열이 아니라 true!

# 문자열로 유지하려면 따옴표 필수
country: "NO"
answer: "yes"

# 날짜도 자동 변환됩니다
version: 2024-01-15  # 문자열이 아니라 Date 객체!

노르웨이의 국가 코드 "NO"가 불리언 false로 해석되는 것은 YAML의 유명한 함정입니다. 이런 이유로 값이 모호할 때는 항상 따옴표를 사용하는 것이 안전합니다.

JSON의 대안: JSON5와 JSONC

표준 JSON의 엄격한 문법이 불편한 경우를 위해 확장 형식도 등장했습니다. JSON5는 주석, trailing comma, 작은따옴표, 16진수 숫자 등을 허용합니다. JSONC(JSON with Comments)는 VS Code와 TypeScript에서 사용하며, 주석만 추가로 허용합니다.

하지만 이런 확장 형식은 표준이 아니므로, 외부 시스템과 데이터를 주고받을 때는 반드시 표준 JSON을 사용해야 합니다. 프로젝트 내부 설정 파일에서만 사용하세요.

최종 정리

세 가지 포맷 중 어떤 것을 선택할지 아직 고민이라면, 간단한 질문 세 가지로 결정할 수 있습니다:

• 프로그램끼리 데이터를 주고받나요? JSON을 쓰세요. 파싱이 빠르고 모든 언어에서 지원합니다.
• 사람이 직접 편집해야 하나요? YAML을 쓰세요. 주석을 달 수 있고 가독성이 좋습니다.
• 엄격한 스키마 검증이 필요하거나 레거시 시스템과 연동하나요? XML을 쓰세요. XSD로 타입까지 검증할 수 있습니다.

기술 선택에 정답은 없습니다. 프로젝트의 요구사항과 팀의 익숙함을 고려해서 선택하면 됩니다. 다만 새 프로젝트를 시작한다면, JSON과 YAML 조합이 가장 무난한 선택이라는 점은 분명합니다.