핵심 정리

{
  "name": "RefDock",
  "public": true,
  "version": 1,
  "tags": ["docs", "json"],
  "meta": null
}

문법

텍스트로 주고받는다는 선택이 이식성을 만든다

JSON은 구조화된 데이터를 순수 텍스트로 표현하는 데이터 교환 형식입니다. 바이너리 포맷과 달리 텍스트이기 때문에 언어, 플랫폼, 운영체제가 서로 달라도 동일한 바이트 열을 그대로 읽을 수 있습니다. RFC 8259가 JSON을 "언어 독립적인 이식 가능한 형식"으로 정의하는 이유가 여기에 있습니다. 이진 직렬화 포맷인 Protocol Buffers나 MessagePack과 비교할 때 크기나 파싱 속도에서는 불리하지만, 디버깅과 로깅에서 사람이 직접 읽을 수 있다는 점이 운영 환경에서 실질적인 이점을 만듭니다.

여섯 가지 값 타입만으로 대부분의 데이터 구조를 표현할 수 있다

JSON은 string, number, boolean(true/false), null, object, array 여섯 가지 값 타입만을 허용합니다. 타입 수를 최소화한 것은 단순함이 목적입니다. 날짜, UUID, 화폐 같은 도메인 타입은 JSON이 직접 지원하지 않아 모두 string이나 number로 인코딩해야 합니다. 이 제약은 파싱 쪽이 추가 규칙을 알고 있어야 한다는 트레이드오프를 만들지만, 역으로 어떤 JSON 파서도 별도 라이브러리 없이 기본 타입을 읽을 수 있다는 범용성을 보장합니다.

예를 들어 "createdAt": "2026-04-07T12:00:00Z" 는 JSON 차원에서는 그저 string입니다. "이 값이 실제로는 UTC 시각"이라는 의미는 JSON 바깥 계약에서 정해 줘야 합니다.

JavaScript에서 출발했지만 특정 언어에 종속되지 않는다

JSON은 JavaScript object literal 문법에서 유래했지만, 오늘날은 Python의 json 모듈, Java의 Jackson, Go의 encoding/json 등 사실상 모든 언어에 표준 파서가 있습니다. 다만 이 역사적 배경 때문에 JavaScript object literal과 혼동하기 쉬운 함정이 있습니다. key에 따옴표가 필수이고, undefined나 함수는 JSON 값이 아니며, 주석과 trailing comma를 허용하지 않는 점이 대표적입니다.

용도에 따라 더 나은 대안이 존재할 수 있다

JSON은 범용 교환 형식으로 최적화되어 있어, 특정 시나리오에서는 다른 형식이 더 적합할 수 있습니다. 대용량 실시간 스트리밍에는 Protocol Buffers나 Avro가 낫고, 사람이 직접 편집하는 설정 파일에는 TOML이나 YAML이 주석과 다중 행 문자열 면에서 유리합니다. JSON을 선택하는 이유는 "어디서나 파서가 있고 디버깅이 쉽다"는 실용적 기준 때문입니다.

{
  "user": {
    "id": 1,
    "name": "Kim"
  },
  "roles": ["editor", "admin"]
}

실무에서 볼 점

주의할 점

const payload = {
  name: "Kim",
  active: true,
};

이 객체는 JavaScript에서는 유효하지만 표준 JSON 텍스트는 아닙니다. "객체처럼 보인다"와 "JSON으로 바로 보낼 수 있다"를 같은 뜻으로 보면 복사 후 파싱 오류가 자주 생깁니다.

또한 JSON 안의 string이 날짜처럼 보여도 파서는 그 의미를 모릅니다. "형식이 맞는 텍스트"와 "의미까지 검증된 데이터"를 같은 층위로 보면 API 계약이 빠르게 흐려집니다.