JSON을 정리하고 검증하는 방법: 실용 가이드

2026년 5월 7일

누군가가 당신에게 설정 파일, API 응답, 또는 로그 항목을 붙여넣어 주었는데, 모든 것이 한 줄에 다 나와 있습니다 — 중괄호와 쉼표로 이루어진 벽처럼 생긴 것이고, 전혀 공백이 없습니다. 실제로 읽어야 하거나, 더 심한 경우는 문제가 생겼고, 그 문제를 일으키는 한 글자를 찾아야 할 수도 있습니다. 눈으로 이걸 찾아내는 것은 느리고 실수하기 쉬운 일입니다. JSON을 실제로 작업할 수 있는 형태로 바꾸는 방법을 알아보겠습니다.

JSON이 무엇인지 간략히 설명하면

JSON (JavaScript Object Notation)은 구조화된 데이터를 위한 텍스트 형식입니다: 키-값 쌍, 배열, 문자열, 숫자, 불리언, null로 이루어진 객체입니다. 이는 API가 데이터를 주고받는 기본 방식이며, 설정 파일, 데이터 내보내기, 인간이 읽을 수 있고 기계가 파싱할 수 있는 모든 것에 사용됩니다. “인간이 읽을 수 있는” 부분은 잘 포맷팅되었을 때만 유지되며, 이 부분이 처음으로 깨지는 경우가 많습니다.

JSON이 읽기 어려워지는 이유

우리가 실제로 마주치는 대부분의 JSON은 압축되어 있습니다: 불필요한 공백, 개행, 들여쓰기 모두 제거됩니다. 서버는 이 작업을 의도적으로 수행합니다. 왜냐하면 더 작은 데이터 패킷은 전송이 더 빠르고 대역폭 비용도 적기 때문입니다. 기계가 데이터를 읽는 데는 적절한 선택이지만, 인간이 읽으려는 경우엔 나쁜 선택입니다.

결과적으로 중첩된 객체와 배열이 모두 하나의 밀집된 줄로 이어지게 됩니다. 계층 구조에 대한 인식을 잃게 되며, 어떤 키가 어떤 객체에 속하는지, 한 배열이 끝나고 다음 필드가 시작되는 지점이 어디인지 파악하기 어렵습니다. “예쁘게 출력”(pretty-printing)이 해결책입니다: 동일한 데이터를 일관된 들여쓰기와 줄 바꿈으로 다시 출력하여, 중첩 구조를 한눈에 볼 수 있게 하고, 큰 구조를 스캔하면서도 위치를 잃지 않도록 합니다.

일반적인 구문 오류

JSON의 구문은 자바스크립트의 객체 리터럴보다 엄격하며, 이 부분에서 문제가 발생하는 경우가 많습니다. 자주 나타나는 문제는 다음과 같습니다:

마지막 항목 뒤의 쉼표. {"a": 1, "b": 2,}은 일부 언어에서는 유효하지만 JSON에서는 유효하지 않음 — 마지막 값 뒤의 쉼표는 파싱에 실패하게 됩니다.
홑따옴표. JSON의 문자열과 키는 이중 따옴표를 사용해야 합니다. {'name': 'value'}은 사람이 보기에는 괜찮아 보이지만 JSON으로는 유효하지 않습니다.
따옴표 없는 키. {name: "value"}은 {"name": "value"}이어야 합니다 — 키는 따옴표가 필요합니다.
누락되거나 불일치한 괄호. 닫히지 않은 {, [, 또는 깊게 중첩된 데이터에서 눈에 띄지 않는 추가된 괄호는 파싱 실패의 가장 흔한 원인 중 하나입니다.
주석. JSON은 주석 구문을 전혀 지원하지 않습니다 — JS 파일에서 복사한 // 또는 /* */는 파싱을 방해합니다.

이러한 실수는 압축된 데이터 블록에서는 거의 눈에 띄지 않지만, 구조가 검증되고 제대로 정렬되면 명확하게 드러납니다.

검증 및 포맷팅

“검증”은 텍스트가 실제로 JSON의 문법에 부합하는지 확인하는 것을 의미합니다 — 모든 문자열이 올바르게 따옴표로 감싸졌고, 모든 괄호가 매칭되었으며, 마지막 쉼표가 없고, 불필요한 문자가 없습니다. 검증기는 데이터가 비즈니스적으로 올바른지 알려주지는 않지만, 파싱 가능한지 명확히 알려주며, 일반적으로 문제가 있는 위치를 지적합니다.

실무적으로 워크플로우는 간단합니다: JSON을 붙여넣고 도구가 검증하도록 하세요. 오류가 있다면 지정된 위치에서 수정하세요. 검증이 완료되면 보기 좋게 정렬하여 구조를 명확하게 해보세요 — 이는 데이터가 예상대로 보이는지, 올바른 필드가 올바른 위치에 중첩되어 있는지 확인하는 좋은 방법입니다.

Toolio의 JSON 포맷터는 브라우저에서 두 가지 모두 올바르게 수행합니다 — 텍스트는 업로드되지 않으며, 문법 문제를 표시하고, 유효한 JSON을 적절한 들여쓰기로 포맷팅합니다. 무료이며 설치할 필요가 없으며, 간단히 확인할 때 매우 유용합니다.

프로덕션을 위한 압축

편집을 마치고 JSON이 올바르다면, 가독성이 좋은 들여쓰기된 버전은 실제로 배포할 것이 아닙니다. API 응답, 패키징된 설정, 또는 네트워크를 통해 제공되는 모든 항목에서 압축은 추가된 공백을 제거하여 파일을 최소한의 형태로 줄입니다. 데이터는 변하지 않으며, 오직 포맷만 사라집니다. 페이로드가 커질수록 이 점이 더 중요합니다: 완전히 들여쓰기된 큰 설정 또는 데이터셋은 동일한 데이터를 압축한 것보다 훨씬 더 큽니다. 인간이 직접 읽지 않아도 되는 경우, 이는 불필요한 전송입니다.

그러므로 패턴은 읽을 수 있는 버전을 편집 및 디버깅을 위해 유지하고, 어디에 사용될지 바로 직전에 압축하는 것입니다 — 빌드 아티팩트, 배포된 설정, API 응답 등입니다.

요약

JSON의 포맷팅과 검증은 복잡하지 않지만, 압축된 문자열을 눈으로 직접 수행하는 것은 시간 낭비이며, 쉼표나 닫지 않은 괄호 같은 실수를 쉽게 할 수 있습니다. 그것을 붙여넣고 검증기를 통해 실제 문제를 찾아보세요. 작업 중에는 보기 좋게 정렬하고, 배포 전에는 다시 압축하세요. 이것이 바로 전체 워크플로우입니다.

다음 게임이 플레이 가능해지는 순간을 알고 싶으세요? 출시 소식 받기 →