핵심 정리

흔한 오류 예시
- { "a": 1, }          trailing comma
- { a: 1 }             따옴표 없는 key
- { "a": 'x' }         작은따옴표 문자열
- { "a": 1 } // note   주석

문법

trailing comma는 JSON에 없다 — JavaScript 코드에서 복사할 때 특히 주의해야 한다

표준 JSON은 object와 array 마지막 항목 뒤에 쉼표를 허용하지 않습니다. {"a": 1, "b": 2,} 또는 [1, 2, 3,]은 모두 파싱 오류입니다. 이 오류가 자주 나오는 이유는 JavaScript, Python, Rust 등 많은 언어에서 trailing comma가 허용되거나 권장되기 때문입니다. 코드에서 JSON 문자열을 직접 만들거나, 편집기에서 JS object를 JSON 파일로 복사할 때 trailing comma가 그대로 따라오는 경우가 많습니다. JSON을 저장하거나 전송하기 전에 validator를 통과시키는 것이 가장 확실한 예방입니다.

주석은 JSON spec에 없다 — 설정 파일이라도 표준 JSON에는 주석을 쓸 수 없다

RFC 8259는 JSON에 주석 문법을 포함하지 않습니다. //나 /* */ 형태의 주석을 쓰면 파서는 SyntaxError를 냅니다. "설정 파일이니까 주석쯤은 되겠지"라는 기대로 주석을 추가하는 경우가 많지만, 표준 JSON 파서는 이를 읽지 못합니다. 주석이 필요한 설정 파일에는 JSONC(JSON with Comments), JSON5, TOML, YAML 같은 별도 형식을 선택하고 그에 맞는 파서를 써야 합니다. 표준 JSON이 주석을 지원하지 않는 이유는 주석 처리 방식이 언어마다 달라 상호운용성을 해친다는 판단 때문입니다.

비표준 확장 문법을 표준 JSON으로 오해하면 시스템 간 교환에서 깨진다

JSON5, HJSON, JSONC 같은 확장 형식은 trailing comma, 주석, 작은따옴표, 따옴표 없는 key를 허용합니다. 이 형식들은 특정 도구가 읽을 수 있도록 설계되었으나 표준 JSON이 아닙니다. 개발 환경의 설정 파일에서 이 형식을 쓰다가 같은 내용을 API 응답이나 메시지 큐 payload로 내보낼 때 표준 파서에서 오류가 나는 상황이 생깁니다. RFC 8259는 파서가 확장 문법을 허용할 수 있다고 말하지만, generator는 표준 문법만 생성해야 한다고 명시합니다.

JSON.parse("{'foo': 1}");  // SyntaxError — 작은따옴표 key
JSON.parse('{"foo": 1}');  // OK

오류 메시지가 발생 위치를 정확히 알려주지 않을 수 있다 — 검증 도구를 따로 사용하는 것이 빠르다

JSON.parse()가 던지는 SyntaxError는 오류 위치를 포함하지만 오류 원인을 항상 명확히 설명하지는 않습니다. 큰 JSON 파일에서 trailing comma나 따옴표 오류를 추적할 때는 jsonlint 같은 전용 validator나 편집기 플러그인을 사용하면 오류 줄을 즉시 확인할 수 있습니다. 프로그래밍 방식으로 JSON을 생성할 때는 문자열 조합보다 언어의 직렬화 라이브러리를 써서 표준 JSON 출력을 보장하는 편이 이런 종류의 오류를 원천 차단합니다.

특히 "문법이 맞는 것처럼 보이는데 왜 실패하지?"라는 경우는 주석, BOM, 작은따옴표, 따옴표 없는 key처럼 사람이 눈으로 대충 넘기기 쉬운 요소가 원인인 경우가 많습니다. 원인을 찾는 순서는 validator -> 오류 줄 확인 -> 비표준 문법 여부 확인이 가장 빠릅니다.

흔한 오류 예시
- { "a": 1, }          trailing comma
- { a: 1 }             따옴표 없는 key
- { "a": 'x' }         작은따옴표 문자열
- { "a": 1 } // note   주석

체크포인트

주의할 점

const text = '{ "a": 1, }';
JSON.parse(text);

이런 오류는 파서가 마지막 쉼표 하나 때문에 전체를 거부합니다. JSON을 손으로 조합할수록 이런 실수가 늘어나므로, 가능하면 직렬화 라이브러리로 만드는 편이 낫습니다.

실무에서는 오류 메시지만 보고 trailing comma인지 주석인지 바로 구분되지 않는 경우가 많습니다. 그래서 "문자열 조합보다 serializer"가 단순한 취향 문제가 아니라 실제 장애 예방책이 됩니다.