JSON 주석을 못 단다는 걸 다시 확인한 순간
JSON 파일은 오래 봤다. API 응답 볼 때도 열고, 설정 파일 비슷한 걸 볼 때도 열고, 큰 파일을 정리할 때도 자주 만난다.
그런데 JSON에 주석이 안 된다는 건 꽤 최근에야 제대로 알았다.
어떤 프로그램 설정 파일을 바꾸다가 기존 값을 그냥 지우기는 좀 불안해서, 일단 주석 처리해 두고 새 값을 넣으려고 했다. 그런데 //도 안 되고 /* ... */도 안 된다. 너무 흔히 쓰는 형식인데 왜 이 정도도 안 되나 싶어서 이유를 다시 찾아봤다.
찾아보면 일단 규격 자체가 아주 단순하다. RFC 8259 (영어 주의) 기준으로 JSON 값은 객체, 배열, 숫자, 문자열, true, false, null 정도만 있고, 공백도 제한된 문자만 허용한다. 그러니까 주석이 들어갈 자리가 애초에 없다.
이유 설명도 남아 있다. JSON을 만든 Douglas Crockford는 나중에 JSON에서 주석을 뺀 이유를 두고, 사람들이 주석에 파싱 지시문 같은 걸 넣기 시작해서 호환성이 깨질까 봐 그랬다고 설명했다. 그 이야기는 Stack Overflow에 인용된 Crockford 발언 정리 (영어 주의)에서 다시 볼 수 있고, Crockford 본인도 JSMin 페이지 (영어 주의)에서 JSON 원래 용도에는 주석이 없어도 큰 문제가 없었다고 적어 두었다.
결국 JSON은 사람 메모를 달기 좋은 형식이라기보다, 기계끼리 가볍게 주고받기 좋게 아주 단순하게 잘라 놓은 형식에 가깝다.
이름은 익숙한데 막상 차이는 헷갈리는 파일들
이 김에 일반인이 한 번쯤은 들어봤을 데이터 파일 규격들만 추려서 같이 정리해 봤다.
| 형식 | 대략 이런 모양 | 주로 쓰는 곳 | 장점 | 아쉬운 점 |
|---|---|---|---|---|
| JSON | {}와 [] 중심 | 웹 API, 설정값, 앱 데이터 | 가볍고 읽기 쉬움 | 주석이 없고 표 데이터엔 애매할 때가 있음 |
| XML | <tag>...</tag> 중심 | 문서 교환, 오래된 시스템 연동, 일부 공공/기업 데이터 | 구조 설명이 자세하고 주석/검증 체계가 있음 | 길고 무거워 보이기 쉬움 |
| CSV | ,로 나뉜 줄 단위 | 엑셀, 데이터 내려받기, 업로드 | 열어 보기 쉽고 거의 어디서나 됨 | 타입, 문자셋, 줄바꿈 문제에 약함 |
| XLSX | 엑셀 파일 | 보고서, 정리표, 서식 있는 데이터 | 시트, 서식, 수식, 타입을 같이 보존함 | 사람이 텍스트로 바로 읽거나 비교하기는 어려움 |
JSON
JSON은 중괄호와 대괄호로 구조를 표현하는 텍스트 형식이다.
{
"name": "AAA",
"services": ["CleanCSV", "Large JSON Browser"],
"active": true
}
요즘은 웹 API 응답이라고 하면 가장 먼저 떠오르는 형식에 가깝다. 앱 설정, 브라우저와 서버 사이 데이터 교환, 로그 비슷한 구조화 데이터에도 많이 붙는다.
좋은 점은 확실하다. 비교적 짧고, 키와 값 구조가 분명하고, 언어를 가리지 않고 잘 읽힌다.
대신 사람 손으로 길게 설명을 달면서 관리하기엔 불편하다. 주석이 없고, 표처럼 생긴 데이터를 다루기에도 썩 예쁘지 않다. 큰 배열이 길게 붙기 시작하면 금방 읽기 피곤해진다.
XML
XML은 태그로 구조를 감싸는 형식이다.
<service>
<name>AAA</name>
<active>true</active>
</service>
W3C의 XML 소개 (영어 주의)를 보면 XML은 꽤 오래전부터 다양한 데이터 교환과 문서 구조 표현에 쓰여 왔다. 실제로 공공 데이터, 기업 시스템 연동, 전자문서, RSS 같은 쪽에서는 아직도 자주 만난다.
JSON보다 길고 무겁게 보이지만, 대신 “이 값이 무엇인지”를 문서 안에서 더 자세히 표현하기 좋다. 주석도 달 수 있고, 스키마나 검증 같은 쪽도 오래 쌓여 있다.
단점도 분명하다. 짧은 데이터를 주고받기엔 장황하고, 처음 보는 사람 눈에는 닫는 태그까지 계속 붙는 모양이 꽤 부담스럽다.
CSV
CSV는 줄마다 한 행을 두고, 쉼표로 칸을 나누는 가장 단순한 표 데이터 형식에 가깝다.
name,price,count
apple,1200,2
banana,800,5
RFC 4180 (영어 주의)는 CSV를 아주 흔한 형식이라고 설명하면서도 해석이 제각각일 수 있다고 적고 있다. 실제로 써 보면 그 말이 맞다.
CSV의 장점은 명확하다. 엑셀로 열기 쉽고, 다운로드나 업로드 버튼 뒤에서 가장 많이 만나는 형식 중 하나다. 단순한 표를 내보내기엔 정말 편하다.
문제는 단순한 만큼 정보가 적다는 점이다. 이 열이 날짜인지 코드인지, 어떤 문자셋인지, 줄바꿈이 셀 안에 있는지 같은 걸 따로 잘 설명해 주지 못한다. 그래서 한글 깨짐, 선행 0 손실, 열 타입 오인식 같은 문제가 자주 난다.
XLSX
XLSX는 지금 가장 흔한 엑셀 기본 파일 형식이다.
겉으로는 그냥 엑셀 파일이지만, Microsoft 설명을 보면 .xlsx는 XML 기반의 Office Open XML 형식이다. Open XML 형식과 확장자 안내 (영어 주의), Excel 지원 형식 안내 (영어 주의)를 보면 기본 엑셀 워크북 형식으로 다뤄진다.
일반 사용자 입장에서는 CSV보다 이쪽이 덜 피곤할 때가 많다. 시트가 여러 개 있어도 되고, 열 너비나 서식도 남고, 날짜나 숫자 타입도 같이 유지되기 때문이다.
반대로 시스템끼리 가볍게 주고받는 포맷으로는 조금 무겁다. 텍스트 편집기로 열어 바로 훑어보는 느낌도 아니고, Git으로 차이를 보기에도 좋지 않다.
그래서 언제 뭘 쓰는 편이 낫나
- 브라우저나 API 응답처럼 구조화된 데이터를 가볍게 주고받을 때는
JSON - 문서 구조나 태그가 중요한 오래된 연동, 공공/기업 시스템 쪽이면
XML - 표를 빨리 내려받고 올리고, 엑셀에서 가볍게 볼 거면
CSV - 서식, 수식, 여러 시트, 타입 보존까지 필요하면
XLSX
실제로는 “무조건 더 좋은 포맷”보다 “어디에 쓰이느냐” 쪽이 더 크다.
막상 써 보면 느껴지는 차이
JSON은 기계가 읽기 좋게 아주 단순하게 잘라 놓은 느낌이고, XML은 설명을 더 많이 품고 가는 쪽에 가깝다.
CSV는 제일 단순해서 제일 자주 쓰이지만, 대신 제일 많은 오해를 부르기도 한다. XLSX는 사람이 보기엔 편한데 시스템끼리 다루기엔 조금 무거운 쪽이다.
결국 파일 형식 이름보다 더 중요한 건, 그 파일이 사람 눈으로 먼저 읽힐 건지, 프로그램이 바로 처리할 건지, 아니면 엑셀에서 열었을 때 덜 깨져야 하는지인 것 같다.
관련 글
같은 맥락에서 이어서 읽기 좋은 글들입니다.