JSON 오류는 어디를 고치면 될까요?

사용할 도구

• 도구 열기: JSON 포맷·검증

닫는 괄호 바로 앞을 살펴보세요

JSON 정렬·검증 도구에 마지막 쉼표까지 포함한 다음 값을 입력하고 실행합니다. 먼저 실패를 재현한 뒤 한 곳만 바꿔 원인을 확인합니다.

{"name":"Ada","count":2,}

count 뒤의 쉼표는 다음 항목을 예고하지만 바로 객체를 닫습니다. 괄호 근처의 오류라고 해서 괄호가 잘못된 것은 아닙니다. 바로 앞의 구분자를 확인하세요.

{"name":"Ada","count":2}

다시 실행해 name이 Ada이고 count가 숫자 2인지 확인합니다. 성공 표시에서 멈추지 말고 보존해야 할 값이 남았는지까지 확인해야 수정이 끝납니다.

한 번에 한 곳만 고치는 편이 빠릅니다

긴 설정에 오류가 많으면 모든 따옴표나 쉼표를 바꾸고 싶어집니다. 하지만 닫히지 않은 따옴표 하나가 이후 전체 해석을 바꿀 수 있습니다. 가장 앞선 오류 주변부터 조금씩 확인하세요.

1. 원본의 작업용 사본을 직접 보관합니다.
2. 첫 오류와 그 앞의 따옴표·구분자·괄호를 확인합니다.
3. 의미를 유지하는 최소 수정 하나를 하고 다시 실행합니다.
4. 성공 후 값과 개수를 확인하고 필요하면 전후를 비교합니다.

비슷하게 보이는 따옴표도 다릅니다

{"name":"Ada"}
{'name':'Ada'}
{“name”:“Ada”}

첫 입력은 JSON의 큰따옴표, 둘째는 작은따옴표, 셋째는 문서용 곡선 따옴표입니다. 비슷해 보여도 서로 다른 문자입니다. 문서나 메시지를 거쳐 복사한 뒤 실패했다면 확인할 만합니다.

모든 아포스트로피를 큰따옴표로 바꾸지는 마세요. O'Reilly의 기호는 값의 일부입니다. 구분자와 문자열 내용의 역할을 구별해야 정상 데이터까지 손상하지 않습니다.

문법을 고치다 숫자를 문자열로 바꾸지 않았나요?

{"count":2,"enabled":false}
{"count":"2","enabled":"false"}

따옴표를 붙여 읽히더라도 대상 앱은 숫자나 불리언을 요구할 수 있습니다. 문자열 false는 불리언 false가 아닙니다. 정렬 성공만으로 앱의 자료형·업무 조건을 충족했다고 할 수 없습니다.

반대로 회원 번호 00123은 앞의 0을 보존하려고 문자열로 설계했을 수 있습니다. 계산할 양인지 식별자인지 확인하고 자료형을 바꾸기 전에 수신 규격을 살펴보세요.

정렬하면 구조가 보입니다

{"items":[{"name":"pen","quantity":2},{"name":"book","quantity":1}],"currency":"JPY"}

두 칸 들여쓰기로 정렬하면 items의 두 요소가 보입니다. name과 quantity는 각 상품의 쌍이고 currency는 배열 밖입니다. 들여쓰기는 필드를 추가하지 않고 원래 관계를 드러냅니다.

압축은 문자열 밖의 불필요한 공백·줄바꿈을 줄입니다. 이름 안의 공백은 데이터이므로 유지해야 합니다. 검토에는 정렬을, 작은 표현에는 압축을 쓰되 값 편집과 혼동하지 마세요.

긴 ID는 마지막 자리까지 확인하세요

{"id":9007199254740993}

이 예제는 눈으로 놓치기 쉬운 정밀도 문제를 찾습니다. SheepDev 정렬기는 정밀도를 보존하는 파서를 사용해 끝자리 3을 유지합니다. 다른 프로그램이나 스프레드시트로 옮긴 뒤에도 자릿수를 다시 확인하세요.

숫자가 이미 바뀐 뒤 정렬해도 원래 자릿수는 복구되지 않습니다. 원문을 보관해야 하는 이유입니다. 문자열로 바꾸는 방법이 적합할 수 있지만 수신 규격 변경은 별도로 판단해야 합니다.

값 안에 줄바꿈이나 따옴표가 필요할 때

{"message":"He said \"hello\".\nNext line."}

문장 안에 따옴표가 있으면 값의 경계가 헷갈립니다. 여기서 역슬래시는 다음 따옴표를 문자열 종료가 아닌 내용으로 만듭니다. 역슬래시와 n은 줄바꿈을 나타냅니다. 편집기의 두 문자와 읽은 값의 줄바꿈은 서로 다른 표현입니다.

이스케이프된 줄바꿈과 JSON 문자열 안에 실제 개행을 붙여 넣는 것은 다릅니다. 오류를 없애려 줄바꿈을 지우면 메시지가 달라질 수 있습니다. 정렬은 표현을 다듬는 것이지 문장 편집 허가는 아닙니다.

정말 JSON만 복사했나요?

로그 한 줄을 통째로 복사하면 시각이나 INFO 접두사도 포함될 수 있습니다. 개발자 콘솔은 응답 본문 대신 객체의 설명용 표현을 보여 주기도 합니다. 이것이 읽히지 않는다고 API가 고장 난 것은 아닙니다. 실제 JSON인지 표시용 표현인지 먼저 확인하세요.

채팅이나 글에서 복사한 예제에는 코드 블록 표시나 '입력 예제' 제목이 섞일 수 있습니다. 마지막 괄호를 빠뜨렸을 수도 있습니다. 내용 수정 전에 본문만 다시 선택하고 양 끝을 확인하면 복사 실수 때문에 생긴 불필요한 수정을 피합니다.

객체 두 개를 붙이면 배열이 될까요?

{"id":1}
{"id":2}

각 줄은 유효해도 합친 입력은 JSON 문서 하나가 아닐 수 있습니다. JSON Lines처럼 줄마다 값을 다루는 형식은 구별해야 합니다. SheepDev 정렬기는 여러 문서를 자동으로 새 구조로 합치지 않습니다.

[{"id":1},{"id":2}]

배열에는 대괄호와 요소 사이 쉼표가 필요합니다. 하지만 오류가 없어져서가 아니라 수신 측이 배열을 요구해서 바꿔야 합니다. 줄 단위 로그는 원래 형식을 유지하는 것이 맞을 수 있습니다. 문법 수정과 구조 변경을 구별하세요.

정렬 성공 다음에는 무엇을 확인하나요?

읽을 수 있는 JSON이라고 설정이 올바른 것은 아닙니다. 음수 quantity나 quantitiy라는 오타도 문법상 유효할 수 있습니다. 필수 필드와 범위는 수신 시스템 규격과 대조하세요.

수정 전달 시 '마지막 쉼표를 제거했고 name과 count는 그대로입니다'처럼 변경점과 확인 범위를 말하세요. '정렬됩니다'보다 원인과 검증 한계가 분명해 다음 사람이 같은 조사를 반복하지 않아도 됩니다.

참고 자료

• RFC 8259 — JSON (새 탭에서 열립니다)
• MDN — JSON.parse() (새 탭에서 열립니다)

사용할 도구

• JSON 포맷·검증