JSON vs YAML: 차이점과 각각의 적합한 상황

JSON 과 YAML 은 같은 문제 —— 구조화된 데이터를 텍스트로 표현하기 —— 를 풀지만, 정반대의 trade-off 를 합니다. JSON 은 기계의 모호하지 않은 파싱에 최적화되고, YAML 은 사람이 작성하기에 최적화됩니다. YAML 1.2 부터는 모든 유효한 JSON 문서가 또한 유효한 YAML 입니다. 이 가이드는 두 형식의 구문, 타입, 기능을 비교하고 언제 어느 쪽을 쓸지 설명합니다.

짧은 답

프로그램 간 교환되는 데이터에는 JSON —— API 응답, 메시지 payload, 기계가 만들어 내는 것 모두. 사람이 손으로 쓰고 편집하는 파일에는 YAML —— CI 파이프라인, Kubernetes manifest, 애플리케이션 설정 —— 주석과 가독성이 중요한 곳에.

구문 비교

같은 데이터를 두 형식으로:

# YAML
service: api
replicas: 3
ports:
  - 8080
  - 8443
env:
  LOG_LEVEL: info
  DEBUG: false

// JSON
{
  "service": "api",
  "replicas": 3,
  "ports": [8080, 8443],
  "env": {
    "LOG_LEVEL": "info",
    "DEBUG": false
  }
}

YAML 은 중괄호와 대괄호 대신 들여쓰기를 쓰고, 대부분의 따옴표를 생략하고, 주석을 허용합니다. JSON 은 더 장황하지만 의미 있는 공백이 없어 안정적으로 파싱하고 생성하기 훨씬 쉽습니다.

YAML 은 JSON 의 상위집합

YAML 1.2(2009) 이후로 YAML 은 JSON 의 엄격한 상위집합입니다 —— 어떤 유효한 JSON 문서도 유효한 YAML 입니다. YAML 이 JSON 의 "flow" 구문을 그대로 채택했기 때문입니다. 그래서 YAML 파일에 JSON 을 그대로 붙여 넣어도 동작합니다. 배경은 YAML 1.2 와 JSON 호환성 참고.

# 이것은 유효한 YAML —— 동시에 유효한 JSON
{"service": "api", "replicas": 3}

기능 비교

타입 처리: YAML 의 날카로운 모서리

YAML 은 타입 추론에 적극적이어서, JSON 의 명시적 따옴표가 피해 가는 놀라움을 일으킵니다:

# "Norway problem" —— YAML 1.1 파서에선 이것들이 boolean 이 됨
countries:
  - NO   # → false (!)
  - SE
  - true # → boolean, 문자열 "true" 가 아님

version: 1.20   # → 숫자 1.2, 끝의 0 이 사라짐
zip: 01234      # → 668 (일부 파서에서 8진수로 파싱)

JSON 에는 이런 모호함이 전혀 없습니다: "NO" 는 항상 문자열 NO 이고, "01234" 는 항상 그 문자열입니다. YAML 값이 반드시 문자열이어야 한다면 명시적으로 따옴표로 감싸세요.

TOML 과 JSON5 의 자리

같은 대화에 등장하는 다른 두 "사람 친화적" 설정 형식:

• TOML —— section/key 스타일, 손으로 편집하는 앱 설정용(Cargo, Poetry, Hugo). YAML 보다 엄격하고, 의미 있는 들여쓰기 없고, 네이티브 타입 값(datetime, integer, float, array, inline table). 데이터가 대체로 평평한 테이블일 때 최적.
• JSON5 —— 개발자 친화적 완화를 더한 JSON: 주석, 후행 쉼표, 따옴표 없는 key, 작은따옴표, 여러 줄 문자열. 표준 JSON 파서가 받아들이는 게 아니라, JSON5 라이브러리로 옵트인합니다 (또는 "주석 + 후행 쉼표" 부분집합용 JSONC 파서, 예: tsconfig.json).

대략적인 자리매김: 기계 간 교환은 JSON, 깊게 중첩되고 사람이 편집하는 설정은 YAML, 평평한 앱/도구 설정은 TOML, YAML 의 공백 규칙을 받아들이지 않고 에디터 설정에 "주석 있는 JSON" 을 원하면 JSON5/JSONC.

언제 무엇을 쓸까

• JSON 을 쓰자: REST/GraphQL API, 메시지 큐, 브라우저 localStorage, package.json, 코드로 만들거나 소비하는 모든 것.
• YAML 을 쓰자: GitHub Actions / GitLab CI, Kubernetes 와 Docker Compose, Ansible playbook, 사람이 편집하고 주석을 달고 싶은 앱 설정.

흔한 패턴: 가독성을 위해 YAML 로 설정을 작성하고, 빌드 또는 로드 시점에 JSON 으로 변환해서 애플리케이션은 항상 JSON 만 파싱하게 합니다.

JSON 과 YAML 사이 변환

# Python —— YAML 을 JSON 으로
import yaml, json
data = yaml.safe_load(open('config.yaml'))
print(json.dumps(data, indent=2))

# yq 를 이용한 커맨드라인
yq -o=json '.' config.yaml      # YAML → JSON
yq -P '.' config.json           # JSON → YAML

또는 fixjson 의 YAML ⇄ JSON 변환기 로 브라우저에서 즉시 변환 —— YAML 을 붙여서 JSON 을 얻거나 그 반대, 데이터는 어떤 서버에도 전송되지 않습니다.

자주 묻는 질문

YAML 이 JSON 보다 나은가요?

어느 쪽도 "더 낫다" 가 아닙니다 —— 다른 일에 맞게 조율된 것입니다. 사람이 편집하는 설정은 YAML 이 낫고(주석, 가독성), 기계 간 데이터 교환은 JSON 이 낫습니다(단순, 빠름, 모호하지 않은 파싱).

JSON 은 유효한 YAML 인가요?

네. YAML 1.2 이후 YAML 은 JSON 의 엄격한 상위집합이므로, 어떤 유효한 JSON 문서도 유효한 YAML 입니다. 역은 성립하지 않습니다 —— 대부분의 YAML 은 유효한 JSON 이 아닙니다.

왜 YAML 은 "NO" 를 false 로 바꾸나요?

YAML 은 따옴표 없는 스칼라에서 타입을 추론하는데, 일부 파서는 NO, yes, on, off 를 boolean 으로 읽습니다("Norway problem"). 값을 따옴표로 감싸면("NO") 문자열로 강제할 수 있습니다. JSON 은 필수 따옴표로 이를 완전히 피해 갑니다.

설정 파일엔 YAML 과 JSON 중 무엇을 써야 할까요?

사람이 편집하고 주석과 여러 줄 문자열의 이점이 있으면 YAML, 도구가 만들거나 소비하면 JSON. 많은 팀이 YAML 로 쓰고 로드 시점에 JSON 으로 변환합니다.

브라우저에서 변환과 검증

• YAML ⇄ JSON 변환기 —— 양방향 변환, 클라이언트 사이드
• YAML 포매터 —— YAML 포매팅, 재들여쓰기, 검증
• JSON 이란? —— YAML 이 상위집합인 그 형식
• JSON 포매팅 방법 —— 변환된 결과를 예쁘게 출력
• YAML 1.2 와 JSON 호환성 —— YAML 이 어떻게 JSON 의 상위집합이 되었나