온라인 JSON 유효성 검사 방법: 개발자를 위한 실용 가이드

JSON(JavaScript Object Notation)은 현대 웹 개발에서 가장 널리 사용되는 데이터 교환 형식입니다. 거의 모든 REST API가 JSON 형식으로 데이터를 반환하고, package.json이나 tsconfig.json 같은 도구 설정 파일이 이 형식을 사용하며, MongoDB 같은 데이터베이스도 JSON 형식으로 문서를 저장합니다.

문제는 단 하나의 잘못된 문자(여분의 쉼표, 빠진 따옴표, 닫히지 않은 괄호)가 전체 JSON을 무효로 만들고 애플리케이션에 오류를 일으킨다는 것입니다. API 응답의 잘못된 JSON은 프론트엔드를 망가뜨릴 수 있습니다. tsconfig.json의 구문 오류는 TypeScript 컴파일을 막습니다.

사용하기 전에 JSON을 검증하면 수 시간의 디버깅을 절약할 수 있습니다. NexTools JSON 검증기를 사용하면 어떤 JSON이든 붙여넣어 정확한 줄 번호의 오류를 확인하고 자동으로 포맷된 출력을 받을 수 있습니다.

JSON에는 엄격한 구문 규칙이 있습니다. 어느 하나라도 위반하면 유효하지 않은 JSON이 됩니다:

• 키는 큰따옴표로 감싸야 합니다: {"name": "Ana"}는 유효합니다. {name: "Ana"}는 유효하지 않습니다.
• 문자열은 큰따옴표를 사용하며, 작은따옴표는 안 됩니다: "value"는 유효합니다. 'value'는 유효하지 않습니다.
• 끝에 쉼표를 넣으면 안 됩니다: {"a": 1, "b": 2}는 유효합니다. {"a": 1, "b": 2,}는 유효하지 않습니다.
• 주석을 넣을 수 없습니다: JSON 내에서 //이나 /* */를 사용할 수 없습니다.
• 숫자에는 따옴표를 붙이지 않습니다: {"age": 25}는 유효합니다. {"age": "25"}는 작동하지만 값이 숫자가 아닌 문자열입니다.

JSON에서 허용되는 데이터 유형:

유형	예시	참고
String	"안녕하세요"	항상 큰따옴표
Number	42, 3.14, -7	정수 또는 소수, 따옴표 없이
Boolean	true, false	소문자, 따옴표 없이
Null	null	소문자, 따옴표 없이
Array	[1, 2, 3]	쉼표로 구분된 값
Object	{"key": "value"}	키-값 쌍

JSON 작업 시 가장 자주 만나는 오류들입니다:

1. 마지막 요소 뒤의 쉼표:
   {"items": [1, 2, 3,]} — 3 뒤의 쉼표가 무효.
2. 큰따옴표 대신 작은따옴표:
   {'name': '홍길동'} — {"name": "홍길동"}이어야 함.
3. 따옴표 없는 키:
   {age: 30} — {"age": 30}이어야 함.
4. 이스케이프되지 않은 제어 문자:
   문자열 내의 탭과 줄바꿈은 \t와 \n으로 작성해야 함.
5. 문자열 내 이스케이프되지 않은 따옴표:
   내부 따옴표는 이스케이프 필요.
6. 주석:
   JSON은 어떤 종류의 주석도 지원하지 않음.
7. NaN, Infinity 또는 undefined:
   이 JavaScript 값들은 JSON에서 유효하지 않음. 대신 null 사용.
8. 16진수 값:
   {"color": 0xFF0000}은 유효하지 않음. {"color": "#FF0000"} 사용.
9. 타입이 지정된 배열에서 혼합 타입:
   [1, "둘", true]은 유효한 JSON이지만 많은 API는 동종 배열을 기대함.
10. BOM(바이트 순서 표시):
    일부 편집기가 파일 시작 부분에 보이지 않는 바이트를 추가하여 JSON을 무효로 만듦. 항상 BOM 없는 UTF-8로 저장.

이 모든 오류는 JSON 검증기에서 자동으로 감지되며, 각 오류의 정확한 줄과 위치를 보여줍니다.

JSON은 두 가지 방식으로 표시할 수 있습니다: 사람이 읽기 위한 정돈된 형태(pretty-print)와 효율적 전송을 위한 압축된 형태입니다.

정돈된 JSON:

{
  "user": {
    "name": "민수",
    "age": 28,
    "active": true
  }
}

압축된 JSON(같은 데이터, 적은 바이트):

{"user":{"name":"민수","age":28,"active":true}}

압축된 버전은 공간을 적게 차지하며(API와 저장에 이상적), 정돈된 버전은 읽기와 디버깅이 훨씬 쉽습니다.

JavaScript에서:

JSON.stringify(data, null, 2)  // 2칸 들여쓰기로 정돈
JSON.stringify(data)           // 압축

큰 JSON 파일을 압축하려면 JSON, CSS, JavaScript를 처리하는 코드 압축기를 사용하세요.

JSON 이전에는 XML이 데이터 교환의 지배적 형식이었습니다. 둘 다 여전히 사용되지만 용도가 다릅니다:

특성	JSON	XML
가독성	더 간결	더 장황
크기	30-50% 작음	더 큼
데이터 유형	String, Number, Boolean, Null, Array, Object	모든 것이 텍스트
주석	지원 안 함	지원
스키마	JSON Schema	XSD, DTD
주 용도	REST API, 설정	SOAP, 문서, RSS
파싱	네이티브 JSON.parse()	XML 파서 필요

2026년 현재, JSON은 웹 개발, API, 모바일 애플리케이션에서 주류입니다. XML은 레거시 기업 시스템, RSS/Atom 피드, DOCX 같은 문서 형식에서 유지됩니다.

검증 외에도 이러한 보완 도구들이 작업을 수월하게 합니다:

• JSON 검증기: 구문 확인, 줄 번호가 있는 오류 표시, 자동 포맷팅.
• 코드 압축기: 공백과 줄바꿈을 제거하여 JSON 압축.
• Base64 인코더: URL이나 HTTP 헤더에서 전송하기 위해 JSON을 Base64로 인코딩.
• 텍스트 비교기: 두 JSON 버전을 비교하여 차이점 찾기.

브라우저에서:

• JSON.parse(jsonString) — JSON 문자열을 JavaScript 객체로 변환. JSON이 유효하지 않으면 에러 발생.
• JSON.stringify(obj, null, 2) — 객체를 포맷된 JSON으로 변환.

구문 검증은 JSON이 올바르게 구성되었는지만 확인합니다. 하지만 실제 애플리케이션에서는 데이터가 올바른 구조를 가지고 있는지도 검증해야 합니다.

이를 위한 것이 JSON Schema입니다 — JSON 문서의 구조를 기술하는 표준:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["name", "age", "email"],
  "properties": {
    "name": { "type": "string", "minLength": 1 },
    "age": { "type": "integer", "minimum": 0, "maximum": 150 },
    "email": { "type": "string", "format": "email" }
  }
}

이 스키마로 모든 사용자 JSON에 name(비어 있지 않은 문자열), age(0에서 150 사이의 정수), email(유효한 형식)이 있는지 자동으로 검증할 수 있습니다. Ajv(JavaScript), jsonschema(Python), Newtonsoft(.NET) 등의 라이브러리가 JSON Schema 검증을 구현합니다.

실제 프로젝트에서 흔한 문제를 피하는 데 도움이 되는 사례:

• 외부 소스의 JSON은 항상 검증: API, 사용자 업로드 파일, webhook에서 받은 모든 JSON은 처리하기 전에 try-catch 내의 JSON.parse()를 통과해야 합니다.
• 키에 camelCase 사용: JavaScript/TypeScript의 표준 규칙입니다. user_name 대신 userName.
• 3-4단계 이상의 중첩 피하기: 깊이 중첩된 JSON은 읽기, 순회, 유지보수가 어렵습니다.
• 암호화되지 않은 JSON에 민감한 데이터를 저장하지 않기: 토큰, 비밀번호, 개인 키는 로그나 API 응답의 평문 JSON에 절대 나타나서는 안 됩니다.
• 선택적 필드를 생략하는 대신 null 사용: {"middleName": null}이 필드를 생략하는 것보다 좋습니다.
• 파싱 오류를 우아하게 처리: 최종 사용자에게 JSON.parse의 원시 오류를 보여주지 마세요. 내부적으로 로깅하고 친절한 메시지를 표시하세요.