숏컷 코드

{
  "id": 101,
  "title": "JSON Basics",
  "published": true
}

문법

key를 반드시 string으로 강제하는 이유 — 파서가 문법을 단순하게 유지할 수 있다

JSON object는 "name": value 형식의 member 집합입니다. key가 반드시 string이어야 하는 이유는 JSON grammar가 object member의 이름 부분을 string token 하나로 정의하기 때문입니다. JavaScript object literal처럼 따옴표 없는 식별자({name: "Kim"})나 숫자 key({1: "a"})는 JSON 파서가 이해하지 못합니다. 이 단순한 규칙 덕분에 어떤 언어의 JSON 파서도 key를 별도 처리 없이 string으로 읽을 수 있고, 언어 간 호환이 보장됩니다.

{ "user-id": 1, "created_at": "2026-01-01" }

중복 key는 spec이 금지하지 않지만, 구현마다 결과가 달라진다 — 의존하면 예측 불가능한 버그를 만든다

RFC 8259는 object 안의 이름이 unique해야 한다고 권고하지만 강제하지는 않습니다. 문제는 중복 key가 있을 때 파서마다 동작이 다르다는 점입니다. 마지막 값을 유지하는 파서, 첫 번째 값을 유지하는 파서, 오류를 내는 파서가 혼재합니다. 서로 다른 시스템이 같은 JSON을 읽을 때 각기 다른 값을 가져갈 수 있으므로, 중복 key는 어떤 환경에서도 생성하지 않는 것이 안전합니다.

비권장: { "name": "Lee", "name": "Kim" }
권장:   { "name": "Kim" }

member 순서에 의존하는 코드는 다른 파서에서 깨진다 — 순서가 중요하다면 array를 써야 한다

RFC 8259와 ECMA-404 모두 object member의 순서가 의미 없다고 명시합니다. JavaScript JSON.stringify()는 키 삽입 순서를 유지하는 경향이 있지만, 이것은 구현 세부사항이며 spec 보장이 아닙니다. Python의 json.dumps(), Go의 encoding/json, 일부 Java 라이브러리는 키를 정렬하거나 임의 순서로 출력합니다. 순서가 의미의 일부라면 object 대신 array를 써야 하며, "0번째 항목이 primary"같은 규칙은 array index로 표현해야 합니다.

trailing comma는 허용되지 않는다 — 자동화 생성 코드에서 자주 나오는 함정이다

JSON object에서 마지막 member 뒤에 쉼표를 붙이면 파싱 오류가 납니다. JavaScript나 Python에서는 trailing comma가 허용되거나 권장되기도 하는데, 코드에서 JSON을 문자열로 조합하거나 템플릿으로 생성할 때 이 차이를 놓치기 쉽습니다. 특히 배열이나 object를 동적으로 조합하는 코드에서 마지막 요소 뒤 쉼표가 남으면 JSON validator를 통과할 때까지 발견하기 어렵습니다.

선택 기준

주의할 점

{
  "name": "Lee",
  "name": "Kim"
}

이 구조는 어떤 파서는 마지막 값을 남기고, 어떤 파서는 오류를 낼 수 있습니다. object는 "같은 key가 하나만 나온다"는 전제를 지켜야 상호운용성이 유지됩니다.