Quick Reference

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

문법

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

JSON은 구조화된 데이터를 텍스트로 표현하는 데이터 교환 형식입니다. 언어와 플랫폼이 달라도 같은 문자 구조를 읽을 수 있어 이식성이 높습니다. 다만 JSON 문법과 전송 바이트는 별도 문제입니다. 개방형 시스템에서 JSON text는 UTF-8을 쓰는 것이 기본이며, HTTP 같은 transport의 encoding·압축·media type은 JSON 바깥 계약으로 정합니다. 이진 포맷과 비교할 때 크기나 파싱 속도에서는 불리할 수 있지만, 디버깅과 로깅에서 사람이 직접 읽을 수 있다는 점이 실질적인 장점입니다.

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

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은 범용 교환 형식으로 최적화되어 있어, 특정 시나리오에서는 다른 형식이 더 적합할 수 있습니다. 높은 처리량, 강한 schema 계약, 생성 코드가 중요한 시스템은 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 계약이 빠르게 흐려집니다.