JSON vs YAML: 왜 데이터 교환의 왕좌는 JSON이 차지했을까?

"사람이 읽기엔 YAML이 훨씬 편한데, 왜 API 통신은 죄다 JSON만 쓸까?"
"YAML은 어디에 강점이 있고, JSON은 어떤 이유로 표준이 되었을까?"

JSON vs YAML Medieval Battle

1. 데이터 포맷 전쟁의 서막

과거에 개발자들은 시스템끼리 데이터를 주고받을 '공통의 규격'이 필요했습니다. 초창기에는 XML이 그 자리를 꿰차고 있었죠.

<person>
    <name>Alice</name>
    <age>25</age>
    <skills>
        <skill>Python</skill>
        <skill>Django</skill>
    </skills>
</person>

하지만 XML은 태그를 일일이 닫아줘야 하는 만큼 너무 장황하고 무거웠습니다. 읽기도 피곤했죠. 이때 등장한 대안이 바로 JSON과 YAML입니다.

2. JSON: 웹 데이터 교환의 표준이 되다

2001년, 더글러스 크락포드가 자바스크립트의 객체 표현법에서 아이디어를 얻어 만든 것이 JSON입니다. "최대한 가볍게, 기계가 읽기 좋게"가 핵심이었죠.

JSON의 성공 비결은 명확했습니다. * 압도적인 가벼움: 불필요한 장식 없이 데이터만 전달합니다. * 웹과의 찰떡궁합: 브라우저(JavaScript)에서 별도 라이브러리 없이 바로 객체로 변환할 수 있었습니다. * 직관적인 매핑: Python의 Dict, JS의 Object 등 현대 언어의 자료구조와 구조가 거의 일치합니다.

특히 REST API가 웹의 대세가 되면서, JSON은 사실상 전 세계 공용어가 되었습니다.

3. YAML: 사람이 읽기 위해 태어난 포맷

JSON보다 "사람이 읽는 즐거움"에 더 집중한 진영도 있었습니다. "중괄호나 따옴표 없이 더 깔끔하게 쓸 수 없을까?"라는 고민에서 탄생한 게 바로 YAML입니다.

name: Alice
age: 25
skills:
  - Python
  - Django

YAML의 특징은 확실합니다. * 극강의 가독성: 들여쓰기(Indentation) 기반이라 텍스트가 매우 깨끗합니다. * 주석(#) 지원: JSON에는 없는 '설명'을 적을 수 있다는 게 큰 장점입니다. * 설정 파일의 강자: 이 가독성 덕분에 Kubernetes, Docker, GitHub Actions 등 인프라 설정 포맷을 완전히 장악했습니다.

그런데 왜 데이터 교환(API)에서는 JSON을 넘어서지 못했을까요?

4. YAML이 데이터 교환에서 밀린 현실적인 이유

첫째, 들여쓰기의 엄격함(Space vs Tab) JSON은 괄호가 구조를 잡아주지만, YAML은 보이지 않는 공백 하나가 구조를 결정합니다. 복잡한 데이터를 주고받을 때 공백 하나 잘못 들어가면 디버깅 지옥이 펼쳐집니다.

둘째, 파싱 속도와 리소스 JSON은 문법이 단순해서 해석기가 아주 가볍고 빠릅니다. 반면 YAML은 문법이 워낙 방대하고 복잡해서(코드 실행 기능까지 포함), 이를 해석하는 데 더 많은 메모리와 CPU를 소모합니다. 대량의 데이터를 주고받는 API 환경에선 치명적이죠.

셋째, 보안 문제 YAML은 단순 데이터를 넘어 특정 언어의 객체를 직접 호출하는 기능을 포함할 수 있습니다. 이는 자칫 원격 코드 실행(RCE) 같은 보안 취약점으로 이어질 위험이 있어, 불특정 다수와 데이터를 주고받는 API용으로는 부적합합니다.