JSON이란?
JSON(JavaScript Object Notation)은 사람이 읽을 수 있고 기계가 파싱하기 쉬운 경량 데이터 교환 포맷입니다. 2001년 Douglas Crockford가 JavaScript의 객체 리터럴 문법에서 영감을 받아 정의했으며, 현재는 ECMA-404와 RFC 8259로 표준화되어 있습니다. 원래 JavaScript에서 파생되었지만, 언어 독립적인 포맷으로 Python, Java, Go, C# 등 거의 모든 프로그래밍 언어에서 기본 지원합니다.
JSON은 REST API의 사실상 표준 데이터 포맷이며, 설정 파일(package.json, tsconfig.json), NoSQL 데이터베이스(MongoDB, CouchDB), 로그 시스템, 메시지 큐 등 현대 소프트웨어 인프라 전반에서 사용됩니다.
JSON 기본 문법
JSON은 두 가지 기본 구조로 이루어집니다. 객체(Object)는 {} 안에 키-값 쌍의 순서 없는 집합을 담고, 배열(Array)은 [] 안에 순서가 있는 값의 목록을 담습니다.
지원하는 데이터 타입
JSON이 지원하는 값 타입은 총 6가지입니다. 문자열은 큰따옴표(")로 감싸야 하며, 작은따옴표는 허용되지 않습니다. 숫자는 정수와 부동소수점을 포함하되, NaN이나 Infinity는 유효하지 않습니다. 불리언은 true 또는 false만 허용됩니다. null은 값 없음을 나타냅니다. 그리고 객체와 배열이 중첩 가능한 복합 타입으로 존재합니다.
주의할 점으로, JSON에서는 undefined, 함수, 정규표현식, Date 객체를 직접 표현할 수 없습니다. JavaScript에서 JSON.stringify()를 사용할 때 undefined 값을 가진 키는 자동으로 제거되며, Date 객체는 ISO 8601 문자열로 변환됩니다.
문법 규칙 요약
모든 키는 큰따옴표로 감싸야 합니다. 마지막 항목 뒤에 쉼표(trailing comma)를 넣으면 파싱 오류가 발생합니다. 주석은 지원되지 않습니다. 문자열 안에서 특수 문자는 백슬래시(\)로 이스케이프해야 합니다. 예를 들어, 줄바꿈은 \n, 탭은 \t, 큰따옴표는 \"로 표현합니다.
자주 발생하는 JSON 파싱 오류
1. Trailing Comma (후행 쉼표)
JavaScript에서는 객체나 배열의 마지막 항목 뒤에 쉼표가 허용되지만, JSON에서는 문법 오류입니다. 이는 가장 흔한 JSON 오류 중 하나로, 코드에서 JSON을 수동으로 작성할 때 특히 자주 발생합니다. 대부분의 IDE에서 JSON 파일에 대해 후행 쉼표 경고를 표시하지만, 동적으로 생성한 JSON 문자열에서는 놓치기 쉽습니다.
2. 작은따옴표 사용
Python의 딕셔너리를 str()로 변환하면 작은따옴표가 사용되어 유효한 JSON이 아닌 문자열이 생성됩니다. 반드시 json.dumps()를 사용해야 합니다. JavaScript에서도 객체 리터럴의 키에 따옴표 없이 작성하는 것은 유효하지만, JSON으로 직렬화할 때는 JSON.stringify()가 자동으로 큰따옴표를 적용합니다.
3. 주석 포함
JSON 표준은 주석을 허용하지 않습니다. 설정 파일에서 주석이 필요한 경우 JSON5, JSONC(VS Code 사용), YAML 등의 대안을 고려하세요. TypeScript의 tsconfig.json은 JSONC 형식을 사용하여 // 주석을 허용합니다.
4. 숫자 정밀도 문제
JSON 숫자는 IEEE 754 부동소수점으로 처리되므로, JavaScript에서 9007199254740993과 같은 큰 정수는 정밀도가 손실될 수 있습니다. 이를 해결하려면 큰 숫자를 문자열로 전달하거나, JavaScript에서 BigInt를 사용하세요. 금융 데이터나 ID 값을 다룰 때 특히 주의가 필요합니다.
JSON과 다른 포맷 비교
JSON vs XML
XML은 태그 기반의 마크업 언어로, JSON보다 구조적이고 스키마 검증(XSD)을 지원합니다. 하지만 동일한 데이터를 표현할 때 JSON보다 2~3배 큰 용량을 차지하며, 파싱 속도도 느립니다. REST API에서는 JSON이 사실상 표준이지만, SOAP 기반 엔터프라이즈 시스템이나 문서 마크업(XHTML, SVG)에서는 여전히 XML이 사용됩니다. 네임스페이스, DTD, XSLT 같은 기능이 필요한 경우에만 XML을 선택하는 것이 합리적입니다.
JSON vs YAML
YAML은 들여쓰기 기반의 포맷으로 사람이 읽기 쉽고 주석을 지원합니다. Docker Compose, Kubernetes, GitHub Actions 등의 설정 파일에서 널리 사용됩니다. 하지만 들여쓰기에 민감하여 복사/붙여넣기 시 오류가 발생하기 쉽고, 보안상 코드 실행 가능한 태그가 존재하여 신뢰하지 않는 입력에는 주의가 필요합니다. API 통신에서는 JSON, 설정 파일에서는 YAML이 일반적입니다.
JSON vs Protocol Buffers (Protobuf)
Protobuf는 Google이 개발한 바이너리 직렬화 포맷으로, JSON보다 데이터 크기가 작고 파싱 속도가 빠릅니다. gRPC의 기본 메시지 포맷으로 사용되며, 스키마(.proto 파일)를 사전에 정의하여 타입 안전성을 보장합니다. 하지만 사람이 직접 읽거나 편집할 수 없으므로, 디버깅이 어렵고 브라우저에서 직접 사용하기 번거롭습니다. 마이크로서비스 간 내부 통신에서는 Protobuf, 외부 API에서는 JSON이 적합합니다.
JSON 실무 활용 패턴
REST API 응답 설계
API 응답은 일관된 구조를 유지하는 것이 중요합니다. 성공 응답은 data 필드에 실제 데이터를, 오류 응답은 error 필드에 오류 코드와 메시지를 포함하는 패턴이 일반적입니다. 페이지네이션이 필요한 리스트 응답에서는 meta 필드에 총 개수, 현재 페이지, 페이지당 항목 수 등의 메타데이터를 포함합니다.
설정 파일 관리
package.json, tsconfig.json, .eslintrc.json 등 프로젝트 설정에서 JSON이 광범위하게 사용됩니다. 환경별로 다른 설정이 필요한 경우, 기본 설정 파일과 환경별 오버라이드 파일을 분리하고 병합하는 패턴을 사용합니다. 민감한 값(API 키, 데이터베이스 비밀번호)은 JSON 파일에 직접 넣지 않고, 환경 변수로 주입하는 것이 보안상 안전합니다.
JSON 데이터 검증
JSON Schema는 JSON 데이터의 구조를 정의하고 검증하는 표준입니다. 필수 필드, 타입 제약, 값 범위, 문자열 패턴 등을 선언적으로 정의할 수 있으며, API 입력 검증, 설정 파일 유효성 검사, 문서 자동 생성에 활용됩니다. Ajv(JavaScript), jsonschema(Python) 등의 라이브러리로 런타임 검증을 구현할 수 있습니다.
성능 고려사항
대용량 JSON을 다룰 때는 몇 가지 성능 문제를 인식해야 합니다. 브라우저에서 JSON.parse()는 전체 문자열을 메모리에 로드하므로, 수십 MB 이상의 JSON 파일은 메모리 부족이나 UI 프리징을 유발할 수 있습니다. 서버 측에서는 스트리밍 파서(예: Node.js의 JSONStream, Python의 ijson)를 사용하여 대용량 데이터를 점진적으로 처리할 수 있습니다.
네트워크 전송 시에는 gzip이나 Brotli 압축을 적용하면 JSON 응답 크기를 70~90% 줄일 수 있습니다. 대부분의 웹 서버와 CDN은 텍스트 기반 응답에 대해 자동으로 압축을 적용합니다.
JSON 도구 활용
개발 과정에서 JSON을 효율적으로 다루려면 적절한 도구를 활용하는 것이 중요합니다. JSON 포맷터를 사용하면 압축된 JSON을 읽기 쉬운 형태로 정리하거나, 문법 오류를 빠르게 찾을 수 있습니다. API 응답이나 로그에서 추출한 JSON을 검증할 때 브라우저 기반 도구가 유용합니다.
JSON 데이터를 Base64로 인코딩해야 하는 경우 Base64 인코더를, JWT 토큰의 페이로드를 확인하려면 Base64 디코더를 활용하세요. 두 JSON 파일의 차이를 확인하려면 텍스트 비교 도구가 효과적입니다.