2000년대 초반만 해도 데이터 교환의 왕은 XML이었다. SOAP 웹서비스, 설정 파일, 심지어 마이크로소프트 오피스 문서까지 전부 XML이었다. 그런데 어느 순간 세상이 바뀌었다. API 응답, 설정 파일, 데이터베이스까지 전부 JSON이다.

XML은 엄격했다. 스키마 검증, 네임스페이스, DTD 같은 것들이 있었다. 엔터프라이즈 환경에서는 이런 엄격함이 장점이었다. 하지만 개발자들에게는 고통이었다. 닫는 태그를 일일이 써야 하고, 속성과 요소 중 뭘 써야 할지 고민해야 하고, 파싱하려면 무거운 라이브러리가 필요했다.

JSON은 JavaScript Object Notation의 약자다. Douglas Crockford가 2001년경 이걸 데이터 교환 포맷으로 쓰자고 제안했다.

JSON이 이긴 이유는 단순하다. 첫째, JavaScript와 찰떡이다. 웹이 세상을 지배하면서 JavaScript가 어디에나 있게 됐다. 브라우저에서 JSON.parse 한 줄이면 바로 객체가 된다. 둘째, 사람이 읽기 쉽다. XML보다 훨씬 간결하다. 닫는 태그도 없고, 불필요한 문법도 없다. 셋째, 가볍다. 같은 데이터를 표현할 때 XML보다 용량이 작다.

이제 JSON은 원래 목적이었던 데이터 교환을 넘어서 모든 곳에 있다. 설정 파일에는 package.json, tsconfig.json이 있다. MongoDB는 아예 JSON 기반이고, PostgreSQL도 JSON 타입을 지원한다. REST API의 사실상 표준 포맷이다.

물론 JSON이 만능은 아니다. 주석을 쓸 수 없다. 날짜 타입이 없다. 큰 숫자를 다루기 어렵다. 그래서 YAML, Protocol Buffers, TOML 같은 대안들이 각자의 영역에서 쓰인다.

XML이 JSON에게 진 건 기술적 우열의 문제가 아니다. 웹과 JavaScript가 세상을 지배하면서, 그 생태계에 가장 잘 맞는 포맷이 표준이 된 것이다. 마치 VHS가 베타맥스를 이긴 것처럼, 기술적으로 더 나은 게 항상 이기는 건 아니다. 더 많은 사람이 쓰고, 더 많은 도구가 지원하는 쪽이 이긴다.