JSON에서 자주 발생하는 오류: 원인, 예제 및 해결 방법

JSON은 단순해 보이지만 따옴표, 쉼표 또는 백슬래시 하나만 잘못되어도 문서 전체를 파싱하지 못할 수 있습니다. 파서가 알려 주는 위치는 처리를 더 이상 계속할 수 없는 지점이며, 실제 오류가 시작된 위치와 다를 수 있습니다.

이 가이드에서는 API 응답, 설정 파일과 로그에서 자주 만나는 JSON 문제를 정리합니다. 먼저 JSON Validator로 첫 번째 오류를 찾으세요. 입력이 JSON과 비슷한 형식이라면 JSON Repair Tool로 수정 후보를 만든 뒤 변경 내용을 검토할 수 있습니다. 모든 처리는 브라우저 안에서 이루어집니다.

기본 원칙: 원본 입력을 보관하고, 첫 번째 오류부터 하나씩 수정한 뒤 매번 다시 검증하세요.

1. 입력이 표준 JSON인지 먼저 확인하기

JSON은 객체, 배열, 문자열, 숫자, 불리언과 null을 지원합니다. 객체 키와 문자열은 큰따옴표로 감싸야 합니다. 주석, undefined, NaN, 함수와 날짜 객체는 JSON에 포함되지 않습니다.

2. 키나 문자열에 잘못된 따옴표 사용

JavaScript 객체는 작은따옴표와 따옴표 없는 키를 허용하지만, 표준 JSON은 허용하지 않습니다.

{ name: 'Alice', 'role': 'admin' }

올바른 JSON은 다음과 같습니다.

{ "name": "Alice", "role": "admin" }

문서의 작은따옴표를 모두 큰따옴표로 일괄 치환하지 마세요. 문자열 안의 아포스트로피나 이스케이프된 문자까지 손상될 수 있습니다.

3. 값 사이에 쉼표가 빠짐

{
  "name": "Alice"
  "active": true
}

이전 값 뒤에 쉼표를 추가해야 합니다.

{
  "name": "Alice",
  "active": true
}

Expected ','가 표시되면 강조된 문자만 보지 말고 바로 앞의 완전한 값을 확인하세요. 배열 요소에도 같은 규칙이 적용됩니다.

4. 마지막 값 뒤에 쉼표가 남음

표준 JSON에서는 마지막 속성이나 배열 요소 뒤에 쉼표를 둘 수 없습니다.

{
  "name": "Alice",
  "active": true,
}

true 뒤의 쉼표를 제거한 다음 JSON Beautifier로 다시 파싱하면 구문과 들여쓰기를 함께 확인할 수 있습니다.

5. 닫는 괄호나 끝 따옴표가 누락됨

Unexpected end of JSON input은 객체, 배열 또는 문자열이 닫히기 전에 입력이 끝났다는 뜻입니다. 네트워크 응답이나 복사한 로그가 잘렸을 때도 발생합니다.

{
  "user": {
    "name": "Alice",
    "tags": ["admin", "editor"]
}

이 예제에는 바깥쪽 }가 하나 부족합니다. 그러나 API 데이터라면 바로 괄호를 추가하지 말고 응답이 완전히 도착했는지 먼저 확인하세요. 도구는 구문을 닫을 수 있지만 사라진 필드는 복원할 수 없습니다.

6. 문자열에 잘못된 이스케이프가 있음

JSON에서 따옴표, 백슬래시, 줄바꿈과 탭은 각각 \", \\, \n, \t로 작성합니다. Windows 경로나 정규식에서 자주 발생합니다.

잘못된 예제:

{
  "path": "C:\new\reports",
  "message": "He said "hello""
}

수정된 예제:

{
  "path": "C:\\new\\reports",
  "message": "He said \"hello\""
}

문자열 안에 실제 줄바꿈을 직접 넣을 수도 없습니다. 줄바꿈이 필요하면 \n을 사용하세요.

7. 주석이 포함됨

표준 JSON은 // 또는 /* ... */ 주석을 지원하지 않습니다. 주석을 제거하거나 꼭 필요한 설명을 명시적인 필드로 옮기세요. 단순한 정규식으로 // 뒤를 모두 지우면 https:// URL까지 손상될 수 있습니다.

8. JSON에서 지원하지 않는 값을 사용함

불리언과 null은 소문자 true, false, null만 사용할 수 있습니다. Python의 True, False, None, JavaScript의 undefined, NaN, Infinity는 유효하지 않습니다.

{ "active": True, "nickname": None, "score": NaN }

가능한 수정 후보:

{ "active": true, "nickname": null, "score": null }

하지만 NaN을 null, 문자열 또는 누락된 필드 중 무엇으로 바꿀지는 비즈니스 규칙에 따라 결정해야 합니다.

9. 여러 객체가 이어 붙어 있음

로그는 종종 한 줄에 객체 하나를 저장하는 NDJSON 또는 JSON Lines 형식을 사용합니다. 각 줄이 유효해도 전체 텍스트가 하나의 JSON 문서는 아닙니다.

{"id": 1, "status": "ok"}
{"id": 2, "status": "failed"}

표준 JSON이 필요하다면 객체 사이에 쉼표를 넣고 배열로 변환합니다.

[
  {"id": 1, "status": "ok"},
  {"id": 2, "status": "failed"}
]

10. JSON이 이중 인코딩됨

파싱 결과가 백슬래시로 가득한 긴 문자열이라면 데이터가 두 번 직렬화되었을 가능성이 큽니다.

"{\"name\":\"Alice\",\"active\":true}"

첫 번째 파싱은 문자열을, 두 번째 파싱은 객체를 반환합니다. 보통 생성 측에서 직렬화를 한 번만 하도록 수정하는 것이 좋지만, API 계약에서 JSON 텍스트를 의도적으로 저장하는지도 확인해야 합니다.

11. 중복 키는 파싱되어도 안전하지 않음

{
  "role": "user",
  "role": "admin"
}

많은 파서는 마지막 값을 남기지만 언어나 보안 계층에 따라 동작이 다를 수 있습니다. 입력 단계에서 중복 키를 거부하고 데이터 생성 측을 수정하세요. 일반적인 JSON.parse가 끝난 뒤에는 덮어쓴 값이 이미 사라집니다.

12. 큰 정수의 정밀도가 손실됨

JavaScript Number는 9007199254740991보다 큰 모든 정수를 정확히 표현할 수 없습니다. 데이터베이스 ID나 스노플레이크 ID가 파싱 중 바뀔 수 있습니다.

{ "userId": 9007199254740993 }

식별자는 문자열로 전달하는 편이 안전합니다.

{ "userId": "9007199254740993" }

이미 반올림된 숫자를 나중에 문자열로 바꿔도 원래 자릿수는 복구되지 않습니다.

13. 신뢰할 수 있는 문제 해결 순서

1. 원본 텍스트를 보관합니다.

1. 복사, 로그 또는 전송 과정에서 내용이 잘리지 않았는지 확인합니다.

1. JSON Validator로 첫 번째 오류를 찾습니다.

1. 해당 위치 앞의 따옴표, 쉼표와 괄호를 확인합니다.

1. 한 가지를 수정할 때마다 다시 검증합니다.

1. JSON Diff로 원본과 수정 후보를 비교합니다.

1. JSON Tree Viewer로 중첩 구조와 자료형을 확인합니다.

1. 구문이 통과한 뒤 필수 필드와 비즈니스 규칙을 검증합니다.

결제, 권한, 의료, 감사 또는 마이그레이션 데이터를 사람의 확인 없이 자동 수정하지 마세요. 도구는 명확한 구문 오류를 고칠 수 있지만 누락된 값이나 비즈니스 의미를 추측할 수 없습니다.

정리

대부분의 JSON 오류는 따옴표, 쉼표, 괄호, 이스케이프와 비표준 값 때문에 발생합니다. 원본을 보존하고 첫 번째 오류부터 하나씩 수정한 뒤 다시 검증하세요. 파싱에 성공한 뒤에도 중복 키, 큰 정수, 자료형과 의미를 확인해야 합니다. JSON과 비슷한 입력은 JSON Repair Tool로 후보를 만든 뒤 JSON Validator와 JSON Diff로 독립 검증할 수 있습니다.