JSON이란? 초보자를 위한 완벽 가이드

웹사이트를 만들거나 API를 호출하거나 package.json 파일을 열어본 적이 있다면, 이미 JSON을 만나본 겁니다. JavaScript Object Notation의 약자로, 앱들이 서로 대화하는 데 사용하는 보편적인 언어입니다. "JavaScript"라는 이름에 속지 마세요 — JSON은 거의 모든 프로그래밍 언어에서 작동합니다.

쉬운 말로, 풍부한 예시와 함께 하나하나 살펴봅시다.

간단한 역사 이야기

JSON은 2000년대 초 Douglas Crockford에 의해 만들어졌습니다. 브라우저와 서버 간 데이터 전송에 XML보다 간단한 것이 필요했죠. 이 아이디어는 빠르게 퍼졌고, 2013년 ECMA-404로 공식 표준화되었으며, 이후 2017년 RFC 8259로도 표준화되었습니다.

현재 웹 API의 90% 이상이 JSON을 사용합니다. JSON은 어디에도 가지 않습니다.

JSON은 어떻게 생겼을까?

간단한 예시를 보겠습니다 — 사람을 나타내는 JSON 객체입니다:

꽤 읽기 쉽죠? 그게 바로 핵심입니다. 이것을 가능하게 하는 규칙들을 살펴봅시다.

구문 규칙 (간단합니다, 약속해요)

데이터 타입: JSON에는 6가지 구성 요소가 있습니다: 문자열(항상 큰따옴표로 감싸기), 숫자, 불리언(true/false), null, 객체, 배열. 그게 전부입니다 — 날짜도, 함수도, 특별한 타입도 없습니다.

객체: 중괄호 {}로 감싼 키-값 쌍입니다. 키는 반드시 큰따옴표로 감싼 문자열이어야 합니다. 중첩 객체의 예시를 보겠습니다:

배열: 대괄호 []로 감싼 순서가 있는 목록입니다. 어떤 타입이든 혼합해서 넣을 수 있습니다:

주의할 점: JSON은 후행 쉼표를 허용하지 않습니다. {"name": "Sam",}는 파서를 망가뜨립니다. JavaScript에서 후행 쉼표가 완전히 괜찮기 때문에, JavaScript에서 넘어온 많은 분들이 이 부분에서 실수합니다.

개발자들이 JSON을 사랑하는 이유

JSON이 데이터 형식 전쟁에서 승리한 이유는 몇 가지가 있습니다:

• 정말 간단합니다. {"name": "Jo"}를 XML의 Jo과 비교해 보세요. 타이핑이 적고, 노이즈도 적습니다.
• 모든 언어가 지원합니다. Python에는 json.loads(), JavaScript에는 JSON.parse(), Go에는 encoding/json이 있습니다 — 감이 오시죠. JavaScript 쪽은 MDN JSON 문서를 참고하세요.
• 가볍습니다. JSON 페이로드는 일반적으로 동등한 XML보다 30-50% 작습니다. 하루에 수백만 건의 API 응답을 보낼 때 이건 중요합니다.
• 코드에 자연스럽게 매핑됩니다. JSON 객체는 Python 딕셔너리, JavaScript 객체, Ruby 해시와 거의 동일하게 생겼습니다. 변환 레이어가 필요 없습니다.

실전에서 JSON을 만나는 곳

• 웹 API: 거의 모든 REST API를 호출하면 JSON을 돌려받습니다. 직접 해보세요 — 브라우저를 열고 https://api.github.com/users/octocat에 접속해 보세요. 그게 JSON입니다.
• 설정 파일: Node.js의 package.json, TypeScript의 tsconfig.json, VS Code의 settings.json — JSON은 개발 도구 곳곳에 있습니다.
• 데이터베이스: MongoDB는 BSON(바이너리 JSON)으로 데이터를 저장합니다. PostgreSQL은 네이티브 JSON 컬럼 타입을 지원합니다. MySQL조차 JSON 지원을 추가했습니다.
• 데이터 교환: 마이크로서비스는 거의 항상 HTTP를 통해 JSON으로 서로 통신합니다.

JSON vs XML — 짧은 버전

XML은 여전히 자리가 있지만(자세한 내용은 XML 기사에서), 대부분의 웹 개발 작업에서 JSON은 가독성, 파일 크기, 파싱 속도에서 승리합니다. XML이 빛나는 유일한 영역은? 혼합 콘텐츠, 스키마, 변환이 있는 문서 중심 데이터입니다.

JSON 유효성 검사

아주 작은 실수 하나 — 쉼표 누락, 따옴표 추가, 후행 쉼표 — 만으로도 JSON 파싱이 완전히 실패합니다. JSON에는 "부분 파싱"이 없습니다; 되거나 안 되거나 둘 중 하나입니다. 그래서 JSON Formatter와 JSON Validator 같은 도구가 유용한 겁니다. JSON을 붙여넣으면 문제가 있는지 즉시 확인할 수 있습니다.

흔한 JSON 실수 (그리고 해결 방법)

수년간 JSON을 다루면서, 개발자들이 반복적으로 하는 실수를 정리했습니다:

1. 큰따옴표 대신 작은따옴표 사용. 이것은 유효한 JavaScript이지만, 유효한 JSON은 아닙니다:

2. 후행 쉼표. JavaScript는 허용하지만, JSON은 허용하지 않습니다:

3. 주석. JSON에는 주석 문법이 없습니다. 설정 파일에 주석이 필요하다면 JSONC(JSON with Comments, VS Code에서 지원)를 고려하거나 YAML로 전환하세요.

4. 따옴표 없는 키. JavaScript에서는 {name: "Sarah"}로 쓸 수 있지만, JSON에서는 모든 키가 따옴표로 감싼 문자열이어야 합니다: {"name": "Sarah"}.

5. undefined 사용. JavaScript의 undefined는 JSON에 존재하지 않습니다. 대신 null을 사용하세요.

다양한 언어에서 JSON 다루기

JSON의 가장 큰 강점 중 하나는 모든 언어에서의 지원입니다. 인기 있는 언어에서 파싱과 직렬화가 어떻게 보이는지 확인하세요:

API가 얼마나 비슷한지 눈치채셨나요? 읽기는 parse/loads, 쓰기는 stringify/dumps. 대부분의 언어가 이 같은 패턴을 따릅니다.

JSON 성능 팁

큰 JSON 페이로드를 다룰 때는 성능이 중요해집니다. 몇 가지 실용적인 팁을 소개합니다:

• 프로덕션에서는 압축하세요. JSON에서 공백을 제거하면 파일 크기를 10-30% 줄일 수 있습니다. JSON Minifier로 원클릭으로 할 수 있습니다.
• 큰 파일에는 스트리밍 파서를 사용하세요. JSON 파일이 수백 메가바이트라면, 전체를 메모리에 로드하지 마세요. JSONStream(Node.js)이나 ijson(Python) 같은 라이브러리가 점진적으로 파싱합니다.
• 깊이 중첩된 구조는 피하세요. 각 중첩 레벨은 파싱 오버헤드를 추가합니다. 4-5레벨 이상 중첩하고 있다면 데이터 모델을 평탄화하는 것을 고려하세요.
• 극단적인 경우에는 바이너리 대안을 고려하세요. 매우 높은 처리량의 시스템에서는 MessagePack, BSON, Protocol Buffers 같은 형식이 2-5배 작은 페이로드와 더 빠른 파싱을 제공할 수 있습니다. 하지만 사람이 읽을 수 없게 되므로 트레이드오프입니다.

실제 API 설계에서의 JSON

실제 API가 JSON 응답을 어떻게 구조화하는지 살펴봅시다. 페이지네이션이 있는 API 응답의 일반적인 패턴입니다:

그리고 일반적인 오류 응답 패턴입니다:

이런 패턴은 너무 흔해서 잘 설계된 거의 모든 REST API에서 볼 수 있습니다. 이런 관례를 따르면 다른 개발자들이 여러분의 API를 더 쉽게 이해할 수 있습니다.

JSON 빠른 참조

JSON 문서에 넣을 수 있는 모든 것의 치트시트입니다:

직접 해보세요

이 지식을 실전에 활용할 준비가 되셨나요? 북마크해 두고 싶은 도구들입니다:

• JSON Formatter — 정리되지 않은 JSON을 붙여넣으면 올바른 들여쓰기로 깔끔하게 포맷해 줍니다.
• JSON Validator — JSON이 구문적으로 올바른지 빠르게 확인하고, 문제가 있으면 명확한 오류 메시지를 받을 수 있습니다.
• JSON Minifier — 프로덕션 페이로드를 위해 JSON에서 공백을 제거합니다.

JSON은 겉보기에는 간단해 보일 수 있지만, 그 특이점과 모범 사례를 마스터하면 디버깅에 드는 수많은 시간을 절약할 수 있습니다. 이제 가서 멋진 것을 만들어 보세요!