JSON이 ‘문법 검사 통과’로 표시되어도 서비스에 넣을 준비가 끝난 것은 아닙니다. 괄호와 쉼표가 맞는지, 같은 키가 두 번 있는지, 서비스가 요구하는 값인지 차례로 확인해야 합니다. 문법 검사와 데이터 의미 검사는 서로 다른 단계입니다. 이 글은 2026년 9월 13일 Easynivo에서 직접 실행한 작은 주문 예시로 그 차이를 설명합니다.
오류가 나면 마지막으로 고친 한 곳부터 보세요
API 응답이나 설정 파일을 복사한 뒤 값 하나를 추가하다가 마지막 쉼표를 남기는 일이 있습니다. 다음은 실제 주문이 아닌 재현 예시입니다. order는 주문 번호, count는 수량을 뜻한다고 가정합니다.
{"order":"0102","count":2,}JSON 정리·검증 도구에서 실행하면 마지막 쉼표와 객체 키를 확인하라는 문법 오류가 나타났습니다. 쉼표 하나를 지운 아래 입력은 통과했고, 들여쓰기한 결과에서도 주문 번호 문자열과 수량이 유지됐습니다.
{"order":"0102","count":2}MDN의 JSON.parse 설명은 JSON 객체·배열의 마지막 쉼표와 작은따옴표 문자열을 허용하지 않는다고 설명합니다. 다만 오류 문구와 위치 표시는 도구마다 다를 수 있으므로, 오류에 표시된 위치 주변과 바로 앞 항목을 함께 확인하세요. 메시지가 가리키는 문자 하나만 무조건 지우는 방식은 다른 문제를 만들 수 있습니다.
중복 키는 문법 통과 뒤에도 확인해야 합니다
이번에는 수량을 바꾸면서 기존 count를 지우지 않았다고 가정해 보겠습니다.
{"order":"0102","count":2,"count":5}실제 실행 결과는 문법 검사 통과, 추가 중복 키 1개였습니다. 정리된 출력에는 두 count가 모두 남았고, 다른 프로그램이 일부 값을 버릴 수 있다는 경고도 보였습니다. 따라서 이 결과를 그대로 주문 시스템에 넣어 수량이 5가 될 것이라고 단정해서는 안 됩니다.
RFC 8259의 객체 규칙은 객체 안의 이름이 고유해야 상호 운용이 가능하다고 설명하고, 중복 이름을 받았을 때 프로그램마다 마지막 값만 남기거나 오류를 내는 등 동작이 달라질 수 있음을 안내합니다. 중복 경고는 단순한 보기 문제가 아니라 실제 값 해석이 달라질 수 있다는 신호입니다.
| 입력 상태 | 도구에서 확인한 결과 | 다음 행동 |
|---|---|---|
| 수량 뒤에 마지막 쉼표 | 문법 오류 | 불필요한 쉼표를 수정하고 재검사 |
| count가 한 번 등장 | 문법 통과 | 서비스가 요구하는 수량 형식 확인 |
| count가 두 번 등장 | 통과와 중복 키 경고 | 담당 규칙에 맞게 값 하나를 확정 |
도구가 어떤 값을 선택해 주지 않는 이유는 의도를 알 수 없기 때문입니다. 수량 변경이 맞는지 원본 요청이나 업무 기록을 확인한 다음, 사용할 값 하나를 남겨 다시 검사하세요.
숫자처럼 보이는 식별번호를 임의로 바꾸지 마세요
예시의 0102는 계산할 수량이 아니라 주문을 가리키는 표식이므로 문자열로 적었습니다. 반면 count는 이 예시의 가정에 따라 숫자로 적었습니다. 실제 서비스의 요구가 다르면 그 문서를 따라야 합니다. 문자열을 숫자로 바꾸면 앞자리 0 같은 표기가 사라질 수 있고, 반대로 모든 숫자를 문자열로 바꾸면 서비스의 형식 검사에 걸릴 수 있습니다.
Easynivo 정리기는 원문의 숫자 표기와 키 순서를 보존하도록 안내합니다. 이것은 정리 단계에서 원본을 바꾸지 않도록 돕는 기능입니다. 이후의 수신 프로그램이 값을 어떻게 처리하는지까지 보장하는 것은 아닙니다. 긴 식별번호를 다룰 때는 작은 샘플을 실제 연동 환경에서 확인하고, 반환된 값도 처음 값과 대조하세요.
서비스에 데이터를 보내기 전 네 칸을 확인하세요
첫째는 문법입니다. 따옴표, 쉼표, 괄호 오류를 없앱니다. 둘째는 구조입니다. 기대하는 객체인지 배열인지, 필수 키가 있는지 살핍니다. 셋째는 값입니다. 수량이 허용 범위인지, 날짜가 유효한지, 주문 번호가 실제 대상인지 확인합니다. 넷째는 수신 결과입니다. 처리 성공 여부와 저장된 값까지 확인합니다.
예를 들어 count를 -2로 바꾸더라도 JSON 숫자 문법 자체와 ‘주문 수량은 양수여야 한다’는 업무 규칙은 별개입니다. 이 문서에서는 특정 주문 서비스의 규칙을 대신 판정하지 않습니다. 연동 문서가 없다면 담당자에게 필수 키, 자료형, 허용 범위를 요청하고 그것을 체크리스트로 남기세요.
검사 기록에는 원본 파일명, 변경한 키, 변경 이유, 문법 검사 결과, 중복 키 확인, 실제 서비스 테스트 여부를 적으면 좋습니다. 인증 토큰이나 개인정보가 포함된 실제 요청은 예시로 공유하지 말고 값만 가상 자료로 바꿔 재현하세요.
자주 묻는 질문
들여쓰기를 하면 오류도 자동으로 고쳐지나요?
아닙니다. 이 도구는 잘못된 값을 추측해 고치지 않습니다. 오류를 직접 수정한 뒤 다시 실행해야 합니다.
중복 키는 뒤에 있는 값을 쓰면 되나요?
대상 프로그램의 동작이 다를 수 있습니다. 먼저 의도한 값이 무엇인지 확인하고 중복을 없앤 문서를 사용하세요.
통과한 JSON을 바로 운영 서비스에 보내도 되나요?
필수 키, 자료형, 값의 범위와 실제 처리 결과까지 확인해야 합니다. 정리기는 해당 서비스의 업무 규칙을 알지 못합니다.
파일이 너무 크면 일부만 붙여 넣어도 되나요?
부분 자료로 오류를 좁힐 수는 있지만 전체 문서가 유효하다는 증거는 아닙니다. 수정한 내용을 원본에 반영한 뒤 전체 파일을 처리할 수 있는 환경에서 다시 확인하세요.