JSON 포맷하고 검증하는 방법

JSON을 포맷하려면 들여쓰기와 줄바꿈을 추가해 구조를 읽기 쉽게 만들어 주는 포매터에 붙여 넣으면 됩니다. 검증하려면 구문을 확인하고 깨지는 정확한 지점을 짚어 주는 파서에 통과시키면 됩니다. 포맷(미화 또는 정렬 출력이라고도 함)과 검증은 보통 함께 일어납니다. 좋은 도구는 유효한 JSON을 다시 들여쓰고, 입력이 깨져 있으면 무엇이 잘못됐는지 정확히 알려 줍니다. 아래에서 각 동작이 실제로 무엇을 하는지, 언제 포맷하고 언제 압축할지, 그리고 파서가 던지는 오류를 어떻게 읽고 고칠지 살펴봅니다.

포맷, 압축, 검증 - 서로 다른 세 가지 작업

이 세 단어는 자주 같은 뜻처럼 쓰이지만, 데이터에 서로 다른 일을 합니다.

• 포맷(미화)은 중첩된 객체와 배열이 시각적으로 정렬되도록 들여쓰기와 줄바꿈을 추가합니다. 데이터를 바꾸지 않고 공백만 바꾸므로, 설정 파일이나 API 응답을 눈으로 훑어보기가 훨씬 쉬워집니다.
• 압축(minify)은 그 반대입니다. 필수가 아닌 모든 공백, 탭, 줄바꿈을 제거해 페이로드를 최대한 작게 만듭니다. 데이터는 동일하고, 사실상 한 줄로 빽빽하게 채워질 뿐입니다.
• 검증은 그 텍스트가 애초에 합법적인 JSON인지 확인합니다. 검증기는 입력을 파싱해 형식이 올바른지 확인해 주거나, 처음 마주친 구문 오류를 보고합니다.

실무에서는 읽고 디버깅하는 동안 포맷을 하고, 데이터를 네트워크로 보내거나 저장하기 직전에 압축을 합니다. 검증은 이 둘 모두의 토대입니다. 애초에 유효한 JSON이 아닌 텍스트는 안정적으로 포맷하거나 압축할 수 없기 때문입니다.

언제 포맷하고 언제 압축할까

사람이 데이터를 봐야 할 때면 언제든 포맷을 집으세요.

• 디버깅하며 API 응답을 살펴볼 때.
• package.json, tsconfig.json, 또는 어떤 설정 파일이든 검토하거나 편집할 때.
• 버전 관리에서 두 JSON 파일을 비교(diff)할 때. 일관된 들여쓰기는 diff를 작고 의미 있게 유지합니다.
• 로그에서 빽빽한 한 줄짜리 덩어리를 붙여 넣고 그 형태를 실제로 이해하고 싶을 때.

바이트가 중요하고 아무도 읽지 않을 때면 압축을 집으세요.

• HTTP 응답이나 요청 본문에 JSON을 실어 보낼 때. 더 작은 페이로드는 더 빠른 전송을 뜻합니다.
• 환경 변수나 URL에 설정을 끼워 넣을 때.
• 수천 개의 행에 걸쳐 공백이 쌓이는 많은 레코드를 저장할 때.

유용한 습관 하나. 소스 파일은 가독성을 위해 포맷된 상태로 유지하고, 빌드나 서버가 나갈 때 압축하도록 두세요. 저장소에서는 읽기 좋고 네트워크에서는 작은, 양쪽의 장점을 모두 얻게 됩니다.

가장 흔한 JSON 오류 (그리고 고치는 법)

JSON은 의도적으로 엄격하며, 그래서 모든 언어에 걸쳐 이식성이 있습니다. 바로 그 엄격함이 사람들을 걸려 넘어지게 하는데, 특히 JavaScript 객체 리터럴 작성에 익숙한 사람일수록 그렇습니다. 다음은 거듭 등장하는 오류들입니다.

• 후행 쉼표. 객체나 배열의 마지막 항목 뒤에 붙은 쉼표({"a": 1,})는 유효하지 않습니다. 제거하세요. 대부분의 프로그래밍 언어가 이를 허용하기 때문에, 단연 가장 흔한 실수입니다.
• 큰따옴표 대신 작은따옴표. JSON은 키와 문자열 값 모두에 큰따옴표를 요구합니다. {'name': 'Ada'}는 {"name": "Ada"}가 되어야 합니다.
• 따옴표 없는 키. 키는 항상 따옴표로 묶인 문자열입니다. {name: "Ada"}는 JavaScript 객체이지 JSON이 아닙니다. {"name": "Ada"}여야 합니다.
• 빠진 쉼표. 마지막을 제외한 모든 항목은 다음 항목과 구분하는 쉼표가 필요합니다. 사이에 아무것도 없이 값이 두 개 연달아 있으면 파싱에 실패합니다.
• 주석. JSON에는 주석 구문이 없습니다. //로 시작하거나 /* */로 감싼 줄은 허용되지 않으며, 텍스트가 검증되기 전에 제거해야 합니다.

몇 가지 더 주의할 점이 있습니다. 숫자는 앞에 0이 붙거나 끝에 소수점이 올 수 없고, 문자열은 \n이나 \" 같은 특수 문자를 이스케이프해야 하며, 숫자와 문자열 외에 허용되는 리터럴은 true, false, null(소문자, 따옴표 없음)뿐입니다.

파싱 오류 읽는 법

검증에 실패하면 파서는 보통 위치, 즉 줄과 열, 또는 문자 오프셋을 보고합니다. 그 위치를 문자 그대로 읽으세요. 오류는 파서가 이해하지 못한 첫 글자에서 보고되는데, 그곳은 흔히 실제 실수 바로 다음입니다. 예를 들어 빠진 쉼표는 쉼표가 있어야 할 빈자리가 아니라 다음 키의 시작 지점에서 자주 지적됩니다. 보고된 지점으로 건너뛴 다음, 바로 그 앞의 토큰을 보세요. 첫 오류를 고치고 나면 다시 검증하세요. 파서는 첫 문제에서 멈추므로 그 뒤에 더 있을 수 있기 때문입니다.

브라우저에서 비공개로 하세요

많은 온라인 JSON 도구는 붙여 넣은 것을 무엇이든 처리하려고 원격 서버로 보냅니다. JSON의 경우 이는 업로드할 수 있는 최악의 데이터인 경우가 많습니다. 바로 그곳이 API 키, 액세스 토큰, 내부 호스트명, 고객 레코드, 그 밖의 비밀이 흔히 자리하는 곳이기 때문입니다.

Andev의 JSON 포매터는 그것을 완전히 피합니다. 브라우저 자체의 네이티브 JSON.parse와 JSON.stringify를 사용하며, 그 말은 곧 다음과 같습니다.

• 데이터가 결코 업로드되지 않습니다. 모든 것이 사용자 기기에서 로컬로 실행되며, 아무것도 어디로도 전송되지 않습니다.
• 정확한 파싱 오류를 짚어 줍니다. 입력이 유효하지 않을 때 구체적인 메시지와 위치가 보이므로 문제로 곧장 갈 수 있습니다.
• 들여쓰기 크기를 직접 고릅니다. 프로젝트 스타일에 맞춰 공백 두 칸, 네 칸, 또는 탭으로 포맷하거나, 한 줄로 압축하세요.
• 즉각적입니다. 업로드하고 기다리는 왕복이 없습니다. 붙여 넣는 속도만큼 빠르게 결과가 나타납니다.

이 도구는 사용자의 애플리케이션이 이미 쓰는 것과 같은 JSON 엔진에 기대므로, 그것이 보고하는 검증은 같은 문자열을 파싱할 때 코드가 실제로 어떻게 동작할지와 일치합니다. 덕분에 민감한 설정과 API 페이로드에 안심하고 쓸 수 있고, 배포 전 빠른 점검용으로도 믿을 만합니다.

이웃한 작업으로, 같은 로컬, 업로드 없는 방식이 Andev의 Base64 인코더 및 디코더와 URL 인코더 및 디코더를 지탱합니다. 둘 다 JSON이 데이터 URI, 토큰, 쿼리 문자열에 끼워 넣어질 때 유용합니다.

핵심 요약

• 포맷은 가독성을 위해 들여쓰기를 추가하고, 압축은 더 작은 페이로드를 위해 공백을 제거하며, 검증은 구문을 확인합니다. 이들은 별개의 세 가지 작업입니다.
• 사람을 위해 포맷하고, 네트워크를 위해 압축하세요. 소스 파일은 읽기 좋게 유지하고 빌드가 출력을 압축하도록 두세요.
• 대부분의 오류는 엄격함의 함정입니다. 후행 쉼표, 작은따옴표, 따옴표 없는 키, 빠진 쉼표, 주석은 모두 유효하지 않은 JSON입니다.
• 파싱 오류를 보고된 위치에서 읽고, 바로 그 앞 토큰을 확인하세요. 하나를 고친 뒤 다시 검증하세요. 파서는 첫 문제에서 멈추기 때문입니다.
• 로컬에 두세요. 브라우저 네이티브 포매터는 데이터를 결코 업로드하지 않으며, 이는 설정과 API JSON 안에 사는 비밀에 가장 중요합니다.

지금 당장 JSON을 정리하거나 점검해야 하나요? 무료 비공개 JSON 포매터를 여세요. 업로드도, 가입도 없습니다. 아니면 전체 브라우저 개발자 도구 모음을 둘러보세요.