JSON이 깨졌다고 나올 때 눈으로 찾기 어려운 원인 다섯 가지
오류 위치를 봐도 그 자리에는 아무 문제가 없어 보일 때가 있습니다. 실제 원인이 앞쪽에 있는 이유와 화면에서 잘 안 보이는 다섯 가지를 정리했습니다.
최종 수정일 읽는 데 약 5분
핵심 요약
- 오류가 가리키는 위치는 문제가 시작된 곳이 아니라 파서가 포기한 곳입니다.
- 쉼표 하나가 더 붙거나 빠진 것이 가장 흔한 원인입니다.
- 문서 편집기에서 붙여넣은 텍스트에는 모양이 다른 따옴표가 섞여 들어옵니다.
- JSON에는 주석이 없으므로 설명을 달아둔 줄이 있으면 그 자체가 오류입니다.
설정 파일을 고쳤더니 JSON을 읽을 수 없다는 오류가 납니다. 알려준 줄 번호로 가봤지만 그 자리에는 이상한 것이 없습니다. 몇 번을 훑어봐도 무엇이 문제인지 보이지 않습니다.
그 자리를 계속 봐서는 찾기 어렵습니다. 결론부터 말하면 오류가 가리키는 곳은 문제가 시작된 지점이 아니라 파서가 더 진행하지 못하고 멈춘 지점이고, 실제 원인은 대개 그 앞에 있습니다.
오류 위치가 실제 원인과 어긋나는 이유
JSON을 읽는 프로그램은 문서를 앞에서부터 한 글자씩 훑어 나갑니다. 여는 괄호가 나오면 짝이 되는 닫는 괄호를 기다리고, 쉼표가 나오면 다음 항목이 오기를 기다립니다.
문제는 기다리는 동안에는 오류라고 판단하지 않는다는 점입니다. 앞쪽에서 괄호를 하나 닫지 않았다면, 파서는 그 뒤의 내용을 전부 그 괄호 안의 내용으로 읽습니다. 그러다 문서가 끝나 버리면 그제야 "끝났는데 닫히지 않았다"고 알립니다.
그래서 표시되는 위치는 종종 파일의 끝이거나, 실제 원인에서 한참 뒤입니다.
이 특성 때문에 확인 순서가 정해집니다. 표시된 위치를 보되, 거기서 위로 거슬러 올라가며 짝이 맞지 않는 부분을 찾아야 합니다.
화면에서 잘 안 보이는 다섯 가지
첫째, 마지막 항목 뒤의 쉼표입니다. 자바스크립트 코드에서는 허용되지만 JSON에서는 오류입니다. 항목을 지우거나 순서를 바꾼 뒤에 남는 경우가 많습니다.
둘째, 모양이 다른 따옴표입니다. 워드나 메모 앱에서 작성한 내용을 붙여넣으면 곧은 따옴표 대신 좌우가 기울어진 따옴표가 들어옵니다. 화면에서는 거의 구분되지 않지만 JSON에서는 전혀 다른 문자입니다.
셋째, 주석입니다. JSON에는 주석 문법이 없습니다. 설명을 달아둔 줄이 있으면 그 줄 자체가 오류입니다.
넷째, 따옴표 없는 키입니다. JSON의 키는 반드시 큰따옴표로 감싸야 합니다. 자바스크립트 객체 표기와 헷갈려 생략하는 경우가 흔합니다.
다섯째, 문자열 안의 줄바꿈입니다. 값 안에서 그냥 줄을 바꾸면 오류가 납니다. 줄바꿈을 담으려면 이스케이프 표기를 써야 합니다.
| 증상 | 실제 원인 | 확인 방법 |
|---|---|---|
| 파일 끝에서 오류 | 괄호를 닫지 않음 | 여는 괄호와 닫는 괄호 개수 비교 |
| 항목 사이에서 오류 | 쉼표가 빠지거나 남음 | 각 항목 끝을 훑어보기 |
| 값 부근에서 오류 | 따옴표 모양이 다름 | 곧은 따옴표로 일괄 교체 |
| 줄 하나가 통째로 문제 | 주석을 넣음 | 설명 줄 삭제 |
| 키 부근에서 오류 | 따옴표 없는 키 | 모든 키를 큰따옴표로 |
| 문자열 중간에서 오류 | 줄바꿈이나 따옴표가 그대로 들어감 | 이스케이프 처리 |
| 첫 글자에서 오류 | 파일 앞에 보이지 않는 문자 | 다른 편집기로 열어 확인 |
마지막 줄은 드물지만 찾기 가장 어렵습니다. 파일 맨 앞에 눈에 보이지 않는 표식이 붙는 경우가 있어서, 첫 글자부터 오류가 나는데 화면에는 아무것도 없어 보입니다.
찾는 순서
- 먼저 자동으로 정렬해 봅니다. 코드 포맷터에서 JSON을 정렬하면 오류 위치가 표시되고, 통과하면 구조가 보기 좋게 정리됩니다.
- 정렬이 실패하면 표시된 위치의 앞을 봅니다. 그 줄이 아니라 그 위쪽입니다.
- 괄호 개수를 셉니다. 여는 것과 닫는 것의 수가 맞는지 확인합니다.
- 따옴표를 일괄 교체합니다. 기울어진 따옴표를 곧은 따옴표로 바꿉니다.
- 주석처럼 보이는 줄을 지웁니다.
- 그래도 안 되면 반으로 나눠 확인합니다. 앞쪽 절반만 남기고 검증해 어느 쪽에 문제가 있는지 좁혀 갑니다.
6번은 파일이 클 때 특히 효과적입니다. 몇 번만 반복하면 문제 구간이 빠르게 좁혀집니다.
통과했는데도 동작하지 않을 때
문법 검증을 통과한다고 값이 의도대로 쓰인다는 뜻은 아닙니다.
| 상황 | 문법 | 실제 문제 |
|---|---|---|
| 숫자를 따옴표로 감쌈 | 정상 | 받는 쪽에서 문자열로 읽힘 |
| 참·거짓을 문자열로 적음 | 정상 | 항상 참으로 해석될 수 있음 |
| 키 이름의 대소문자가 다름 | 정상 | 값을 찾지 못함 |
| 필요한 키가 빠짐 | 정상 | 기본값이나 오류로 이어짐 |
| 배열이어야 할 곳에 객체 | 정상 | 구조가 맞지 않아 실패 |
포맷터는 문법만 봅니다. 구조가 받는 쪽의 기대와 맞는지는 별개로 확인해야 합니다.
JSON을 고칠 때 시간을 버리는 방식
표시된 줄만 반복해서 봅니다. 그 자리에는 대개 문제가 없습니다. 위로 올라가야 합니다.
눈으로 따옴표를 구분하려 합니다. 곧은 따옴표와 기울어진 따옴표는 화면에서 거의 같아 보입니다. 일괄 교체가 확실합니다.
한 글자씩 훑습니다. 파일이 길면 끝이 없습니다. 반으로 나눠 좁히는 편이 훨씬 빠릅니다.
자바스크립트 문법을 그대로 씁니다. 마지막 쉼표, 따옴표 없는 키, 작은따옴표, 주석은 전부 JSON에서 오류입니다.
정렬을 먼저 해보지 않습니다. 자동 정렬은 문제 여부를 즉시 알려주고, 통과하면 구조가 보기 좋아져 이후 확인이 쉬워집니다.
오류 위치보다 그 앞을 보세요
JSON 오류는 원인과 발견 지점이 떨어져 있다는 특성 하나만 이해하면 찾는 속도가 크게 달라집니다.
정렬을 먼저 돌려보고, 실패하면 표시된 위치에서 위로 거슬러 올라가고, 그래도 안 보이면 반으로 나눠 좁히세요. 그리고 붙여넣은 텍스트라면 따옴표부터 의심하는 것이 좋습니다.
자주 묻는 질문
오류 위치가 왜 엉뚱한 곳을 가리키나요?
파서는 앞에서부터 순서대로 읽다가 더 이상 진행할 수 없는 지점에서 멈춥니다. 예를 들어 앞쪽에서 괄호를 닫지 않았다면 파일 끝에 가서야 문제가 드러납니다. 그래서 표시된 위치보다 그 앞을 살펴야 하는 경우가 많습니다.
주석을 쓸 방법이 없나요?
표준 JSON에는 주석이 없습니다. 설명이 필요하다면 설명용 키를 하나 만들어 값으로 넣는 방법이 흔히 쓰입니다. 일부 도구가 주석을 허용하는 확장 형식을 지원하지만, 그렇게 만든 파일은 표준 파서에서 오류가 납니다.
마지막 항목 뒤에 쉼표를 넣으면 안 되나요?
JSON에서는 안 됩니다. 자바스크립트 코드에서는 허용되기 때문에 습관적으로 넣는 경우가 많은데, JSON 파일에서는 오류가 됩니다. 항목을 지우거나 순서를 바꾼 뒤에 자주 생깁니다.
숫자를 따옴표로 감싸도 되나요?
문법상 오류는 아닙니다. 다만 그 값은 문자열이 되므로 받는 쪽에서 숫자로 다루려 할 때 문제가 생길 수 있습니다. 문법 오류와 의미 오류는 다르며, 검증을 통과했다고 값이 의도대로 쓰인다는 보장은 없습니다.