JSON을 붙여 넣었는데 오류가 납니다. 이때 괄호만 계속 세면 오래 걸립니다. 반대로 오류 없이 읽혔다고 바로 다음 작업으로 넘기는 것도 위험합니다. 읽을 수 있는 데이터와 우리 작업에 맞는 데이터는 다른 조건이기 때문입니다.
가령 담당자가 없는 작업에 "null"이라는 글자가 들어 있다면 어떨까요. 문법상으로는 멀쩡한 문자열입니다. 하지만 “값이 없음”을 뜻하는 null과는 다릅니다. 오류를 찾는 순서를 나누면 이런 문제를 훨씬 덜 헤맵니다.
먼저, 두 종류의 오류를 구분합니다.
| 검사 | 묻는 질문 | 예 |
|---|---|---|
| 문법 | JSON.parse가 읽을 수 있는가? | 마지막 쉼표, 작은따옴표, 닫히지 않은 괄호 |
| 스키마·업무 규칙 | 읽은 값이 약속한 형태인가? | 문자열 ID, 실제 날짜, 상태 허용값 |
| 사실 확인 | 그 값이 원자료와 같은가? | 실제 기한·담당자·금액 대조 |
마지막 사실 확인은 파서가 대신하지 못합니다. 아래 도구가 통과했다고 담당자에게 작업을 배정해도 된다는 뜻은 아닙니다.
같은 “통과”라도 의미가 다릅니다.
{"status":"완료"}위 입력은 올바른 JSON입니다. 하지만 이 글의 예제 계약은 작업 여러 개를 담는 배열이고, 상태값은 pending, in_progress, done 중 하나입니다. 따라서 문법 통과·계약 실패가 동시에 맞는 판정입니다.
[{"id":"A-01","title":"자료 확인","owner":null,"due":"2026-09-01","status":"pending"}]이 예제는 문법과 다섯 필드 규칙을 모두 통과합니다. 키를 다른 순서로 적어도 같은 정보라면 통과합니다. JSON 객체의 키 순서를 정확도 점수로 세지 않도록 했습니다.
TRY IT HERE
붙여 넣은 JSON을 두 단계로 검사해 보세요.
입력값은 이 브라우저 안에서만 처리합니다. 아래 검사 기능은 서버에 저장하거나 전송하지 않습니다. 실제 개인정보 대신 예제를 사용하세요.
최대 20만 자 · 원본을 자동 수정하지 않습니다.
세부 데이터·판정 규칙 보기
오류 메시지를 보고 고치는 순서
- 원본을 복사해 별도로 보관합니다. 오류를 고치면서 원자료까지 바꾸지 않기 위해서입니다.
- 문법 실패라면 첫 오류 위치부터 봅니다. 코드 울타리나 설명 문장이 섞였는지, 마지막 쉼표가 있는지 확인합니다.
- 문법이 통과하면 필드별 규칙을 봅니다. 숫자처럼 보이는 ID를 숫자로 바꾸거나 없는 담당자를 채워 넣지 않습니다.
- 스키마가 통과한 뒤에 원자료와 행 수·ID·기한을 대조합니다. 같은 ID가 두 번 나오면 자동 저장을 멈춥니다.
날짜 정규식 하나로는 부족합니다.
2026-02-29는 YYYY-MM-DD 모양이지만 존재하지 않는 날짜입니다. 검사기는 월별 일수와 윤년을 확인합니다. 반면 “다음 주 금요일”은 틀린 날짜가 아니라 기준 시점이 빠진 입력입니다. 임의로 날짜를 만들지 말고 원자료를 확인해야 합니다.
직접 확인할 자료
입력과 판정 규칙을 함께 보면 결과를 다시 확인하기 쉽습니다. 자료의 숫자는 별도 표시가 없는 한 학습용 가상 값입니다.
검증 범위: 2026년 8월 31일, 이 사이트가 제공하는 JavaScript 검사 규칙과 가상 입력으로 실행한 결과입니다. 새로운 Gemini 응답 실험이나 특정 유료 제품의 성능 측정이 아닙니다.
더 확인하고 싶다면
기능과 형식 설명은 아래 공식 자료를 기준으로 확인했습니다. 이 글의 예제 결과와 공식 제품의 보장 범위는 구분해 읽어 주세요.
공식 자료 확인: 2026년 8월 31일. 제품 메뉴와 지원 범위는 버전·언어에 따라 달라질 수 있습니다.