JSON 오류를 쉼표·따옴표·끝 쉼표별로 재현하고 고치는 법
JSON.parse 오류를 끝 쉼표, 작은따옴표, 주석별로 재현하고 문법 정리와 스키마 검증의 차이를 구분합니다.
마지막 검토: 2026년 8월 25일 · 로직 버전 20260724-1 · 검증 벡터 object/array/invalid JSON
PROBLEM
왜 이 구분이 필요한가
JSON은 JavaScript 객체 표기처럼 보이지만 주석, 작은따옴표, 끝 쉼표를 허용하지 않습니다. 문법을 통과해도 필수 필드, 값 범위, 이메일 형식 같은 업무 규칙이 맞는지는 알 수 없습니다. 또 중복 키는 별도 경고 없이 표준 파서 동작에 따라 처리될 수 있어 보기 좋게 정리됐다는 사실을 데이터 품질 보증으로 오해하면 안 됩니다.
PROCEDURE
실무 적용 순서
원문에서 토큰과 개인정보를 제거한 뒤 문법 검사를 실행합니다. 오류 위치 근처에서 따옴표 쌍, 콜론, 항목 사이 쉼표, 마지막 항목 뒤 쉼표를 순서대로 확인합니다. 통과하면 2칸 또는 4칸 정리로 중첩 구조를 읽고, 전송 크기가 중요하면 한 줄 압축 결과를 사용합니다. 마지막 단계에서 API 문서나 JSON Schema로 필드 의미를 별도 검증합니다. 중복 키는 원문 단계에서 직접 검사해야 합니다.
BASIS
계산과 검증 근거
도구는 JSON.parse로 표준 JSON 문법을 읽고 JSON.stringify(value, null, 2 또는 4)로 정리하며 공백 인수 없이 압축합니다. 요약은 재직렬화한 값의 루트 유형, 재귀 키 수, 배열 항목 수, 최대 깊이, UTF-8 byte를 셉니다. 정리와 압축은 파싱된 값은 유지하고 공백 표현만 바꿉니다.
LIMITS
지원 범위와 한계
표준 JSON만 허용하며 JSON5, 주석, 작은따옴표, trailing comma를 지원하지 않습니다. 스키마 검증 도구가 아니고 파일 업로드와 명시적 파일 크기 제한도 없습니다. 큰 구조는 브라우저 메모리와 재귀 깊이에 의존합니다. 중복 키에 별도 경고를 제공하지 않고 요약 byte는 원본이 아니라 압축 재직렬화 결과 기준입니다.
WORKED EXAMPLES
직접 재현할 예제
정상 샘플 요약
- 입력
- 검증 샘플 object
- 결과
- 루트 object / 키 5 / 배열 항목 3 / 최대 깊이 2 / UTF-8 88바이트
byte는 압축 재직렬화 결과를 기준으로 합니다.
끝 쉼표
- 입력
- {"a":1,}
- 결과
- JSON.parse 문법 오류
마지막 속성 뒤 쉼표를 제거합니다.
작은따옴표와 주석
- 입력
- {'a': 1} 또는 {"a":1 /* note */}
- 결과
- 표준 JSON 문법 오류
키와 문자열은 큰따옴표를 쓰고 주석은 제거합니다.
표현 방식 비교
- 입력
- 유효한 같은 값
- 결과
- 2칸/4칸 정리와 한 줄 압축
파싱된 값은 같고 공백과 줄바꿈만 달라집니다.
FAQ
자주 묻는 질문
문법 검사와 스키마 검증은 무엇이 다른가요?
문법 검사는 JSON으로 읽을 수 있는지만 확인하고 스키마는 필드 이름, 유형, 필수 여부 같은 의미 규칙을 확인합니다.
요약 byte가 원본과 다른 이유는 무엇인가요?
원본 공백이 아니라 파싱 후 한 줄로 재직렬화한 UTF-8 결과를 세기 때문입니다.
중복 키는 오류인가요?
도구는 별도 경고하지 않고 JSON.parse 동작에 따릅니다. 중복 키가 중요한 데이터라면 파싱 전 전용 검사가 필요합니다.
JSON 파일을 직접 업로드할 수 있나요?
아니요. 현재는 텍스트를 붙여넣어 검사합니다.
SOURCES