JSON 파싱 에러 완전 분석 | 이스케이프·따옴표·개행 오류 해결 2026

JSON 파싱 에러는 개발자를 가장 많이 괴롭히는 오류 중 하나다. 코드는 멀쩡해 보이고, 데이터도 있는데 시스템은 조용히 전체를 거부한다. 에러 메시지조차 위치 번호와 영어 한 줄이 전부라 어디가 문제인지 파악하기 어렵다.

실제로 개발 커뮤니티에서 가장 많이 검색되는 에러 키워드 상위권에 JSON parse error가 꾸준히 이름을 올린다. AI가 JSON을 생성하는 사례가 늘어나면서 2025년 이후로는 개발자가 아닌 일반 사용자들도 이 에러를 자주 마주치게 됐다. 문제는 원인이 뻔한데도 해결하기 전까지는 전혀 보이지 않는다는 점이다.

이 글에서는 JSON이 무엇이고 파싱이 왜 그렇게 엄격하게 작동하는지 구조적으로 짚고, 이스케이프·따옴표·개행이 왜 오류를 만드는지 원리 수준에서 분석한다. 에러 메시지별 원인과 해결 코드, 사전에 막는 방법까지 실전 중심으로 정리했다.

1

JSON이란 무엇이고 파싱은 왜 이렇게 엄격한가

JSON은 JavaScript Object Notation의 줄임말로, 데이터를 텍스트 형태로 주고받기 위한 국제 표준 포맷이다. 서버와 클라이언트가 언어와 플랫폼을 가리지 않고 데이터를 교환할 수 있는 이유가 바로 이 포맷 덕분이다. 현재 대부분의 REST API, 설정 파일, AI 응답 등이 JSON을 사용한다.

JSON이 엄격한 이유는 구조가 완전히 규칙 기반이기 때문이다. JSON 파서는 문자열을 처음부터 끝까지 읽으면서 규칙을 검사한다. 규칙에서 단 한 글자라도 벗어나는 순간, 파서는 그 위치에서 즉시 실패를 선언하고 멈춘다. 에러 메시지에 position 4471처럼 숫자가 찍히는 이유가 바로 이것이다. 그 위치에서 파서가 멈췄다는 뜻이다.

JSON의 핵심 규칙은 다음과 같다. 키와 문자열 값은 반드시 큰따옴표로 감싸야 한다. 중괄호는 객체를, 대괄호는 배열을 의미한다. 키-값 쌍은 쉼표로 구분하며 마지막 항목 뒤에는 쉼표가 오면 안 된다. 그리고 문자열 내부에서 특수한 의미를 가진 문자는 반드시 이스케이프해야 한다.

2

에러 메시지 해부 — 유형별 원인과 발생 위치

JSON 파싱 에러 메시지는 생김새가 다르지만 원인은 몇 가지로 압축된다. 메시지를 읽을 줄 알면 소스코드 전체를 뒤지지 않아도 에러 지점을 바로 찾을 수 있다.

Unterminated string in JSON at position 7225 형태로 나타나는 이 에러는 JSON 문자열 값이 닫히지 않았다는 의미다. 가장 흔한 원인은 문자열 내부에 실제 Enter(개행문자)가 들어간 경우다. JSON 파서는 문자열이 한 줄로 이어져야 한다고 가정하기 때문에, 실제 줄바꿈을 만나는 순간 문자열이 비정상 종료됐다고 판단한다.

AI가 긴 본문을 JSON으로 생성할 때 이 에러가 자주 나는 이유가 바로 이것이다. AI가 content 필드에 값을 쓰면서 내부적으로 실제 Enter를 눌러 줄을 바꾸면, 그 위치에서 JSON 전체가 무너진다.

Expected comma or brace after property value in JSON at position 4471 이 에러는 파서가 키-값 쌍을 읽다가 예상치 못한 문자를 만났을 때 나온다. 원인의 80% 이상은 이스케이프되지 않은 큰따옴표다. 문자열 내부에 큰따옴표가 그대로 들어가면 파서는 거기서 문자열이 끝났다고 착각하고, 그 뒤에 오는 텍스트를 JSON 문법으로 해석하려다 실패한다.

예를 들어 answer 필드 안에 그는 안녕이라고 말했다 라는 값을 큰따옴표 이스케이프 없이 넣으면, 파서 입장에서는 안녕 앞의 큰따옴표에서 문자열이 끝나고 그 뒤부터 문법 오류가 발생한다.

3

이스케이프 시퀀스 완전 정리 — 무엇을 어떻게 처리하는가

이스케이프 시퀀스는 JSON 문자열 내부에서 특수한 의미를 가진 문자를 일반 문자 데이터로 표현하기 위한 방법이다. 역슬래시를 특정 문자 앞에 붙여서 파서에게 이것은 문법 기호가 아니라 문자 데이터라고 알려주는 방식이다.

역슬래시 처리에서 가장 많이 실수하는 경우는 Windows 파일 경로를 JSON에 넣을 때다. C:\Usersest 라는 경로를 JSON에 그대로 넣으면 역슬래시+U, 역슬래시+t 등이 이스케이프 시퀀스로 해석돼 전혀 다른 값이 된다. 반드시 역슬래시를 두 번씩 써서 C:Userstest 형태로 표기해야 한다.

작은따옴표는 JSON 문자열 내부에서 이스케이프 없이 그대로 사용해도 된다. JSON 표준에서 문자열 구분자는 오직 큰따옴표만 사용하기 때문에, 작은따옴표는 JSON 파서에게 특별한 의미가 없다. 단, 문자열 자체를 작은따옴표로 감싸는 것은 JSON 표준 위반이다.

4

실전 코드 — 언어별 이스케이프 자동 처리 방법

직접 이스케이프를 관리하는 것은 실수 가능성이 높다. 각 언어에서 제공하는 직렬화 함수를 활용하면 이스케이프를 자동으로 처리해준다.

JavaScript에서는 JSON.stringify()를 사용하면 모든 이스케이프 처리가 자동으로 이뤄진다. 문자열을 직접 이어붙여 JSON을 만드는 방식은 반드시 피해야 한다. JSON.parse()는 반드시 try-catch로 감싸서 파싱 실패 시 시스템이 멈추지 않도록 해야 한다.

Python에서는 json.dumps()가 직렬화를 담당한다. 한글 등 비ASCII 문자를 그대로 유지하려면 ensure_ascii=False 옵션을 반드시 넣어야 한다. 기본값인 ensure_ascii=True 상태에서는 한글이 역슬래시+u 유니코드 시퀀스로 변환된다. json.loads()로 역직렬화할 때도 예외 처리를 함께 구성하는 것이 안전하다.

JSON이 실제로 깨지는 상황을 사례 기준으로 정리하면 다음과 같다. 첫째, AI가 긴 글을 content 필드에 직접 작성할 때 개행을 이스케이프 시퀀스 대신 실제 Enter로 처리하는 경우다. 둘째, 사용자 입력값에 큰따옴표가 포함된 채로 JSON 문자열에 그대로 삽입되는 경우다. 셋째, Windows 파일 경로를 JSON에 넣을 때 역슬래시를 한 번만 쓰는 경우다. 넷째, 마크다운 코드블록 문법이 JSON 문자열 내부에 포함될 때 일부 파서가 오작동하는 경우다. 다섯째, JSON 마지막 항목 뒤에 쉼표가 남아있는 Trailing Comma로, JSON 표준에서는 엄격히 금지된다.

5

JSON 파싱 에러를 사전에 막는 구조적 방법

사후에 고치는 것보다 처음부터 에러가 나지 않는 구조를 만드는 것이 효율적이다. 사용자 입력을 받아 JSON에 삽입할 때는 반드시 직렬화 함수를 거쳐야 한다. 문자열을 수동으로 이어붙여 JSON을 만드는 방식은 이스케이프 누락 사고가 반드시 생긴다.

AI나 외부 시스템이 JSON을 생성할 때는 파싱 전에 try-catch 블록으로 감싸서 에러가 나도 시스템이 멈추지 않도록 해야 한다. 스키마 기반 검증 라이브러리인 Zod나 Ajv를 사용하면 JSON 문법 검사뿐 아니라 필드 타입과 필수 값 여부까지 자동으로 검증할 수 있다.

긴 문자열 데이터를 JSON으로 처리할 때는 Base64 인코딩을 고려할 수 있다. 특수문자가 많은 HTML, 마크다운, 코드 스니펫 등을 Base64로 인코딩하면 이스케이프 문제를 원천 차단할 수 있다. 다만 데이터 크기가 약 33% 증가하는 점은 감안해야 한다.

JSON 파싱 에러는 한 번 원리를 이해하고 나면 같은 실수를 반복하지 않는다. 이스케이프가 필요한 문자는 큰따옴표, 역슬래시, 개행문자 이 세 가지가 핵심이다. 이 세 가지만 기억하고 직렬화 함수를 습관적으로 쓰는 것만으로 JSON 관련 에러의 90% 이상을 막을 수 있다. 직접 JSON 문자열을 조립하는 방식은 이제 버리고, 언어가 제공하는 안전한 도구를 쓰는 습관을 들이자.