빌드가 "Unexpected token in JSON at position 4,821."라는 오류로 실패합니다. 아주 훌륭하네요, 고맙습니다. 이제 4천 자짜리 설정 파일을 스크롤하며 머릿속으로 괄호를 세면서 어느 것이 짝을 이루지 않았는지 알아내야 합니다. 이는 소프트웨어 개발에서 가장 피할 수 있는 시간 낭비 중 하나이며, JSON이 사소한 실수에 전혀 관대하지 않기 때문에 끊임없이 발생합니다.
배열의 마지막 항목 뒤에 남은 쉼표. 키를 감싸는 인용부호 누락. 다른 곳에서 복사해온 여분의 닫는 중괄호. 이런 것들 중 무엇이든 파싱을 완전히 망가뜨리며, 오류 메시지는 실제 문제가 있는 곳이 아니라 파서가 포기한 지점을 가리키는 경우가 많습니다 — 실제 실수와는 몇 줄이나 떨어져 있는 경우가 대부분입니다.
위치 번호가 도움이 되지 않는 이유
대부분의 JSON 파서는 오류를 에디터에서 바로 이동할 수 있는 줄과 열이 아니라 문자 오프셋으로 보고합니다. 4,821번째 위치를 "세 번째 객체 근처, 112번째 줄"로 바꾸려면 직접 세거나 일회성 스크립트를 작성해야 합니다. 둘 다 오후 시간을 잘 쓰는 방법은 아닙니다.
일부 에디터는 JSON 구문 오류를 인라인으로 강조 표시해 주는데, 이는 직접 작성 중인 파일에는 도움이 됩니다. 하지만 API에서 받았거나 동료가 보냈거나 물려받은 레거시 설정 파일의 JSON이라면, 원시 텍스트를 받아 정확히 무엇이 어디서 잘못되었는지 알려주는 도구가 필요합니다.
맥을 벗어나지 않고 JSON 검증하기
검증까지 함께 하는 JSON 포맷터는 추측을 없애줍니다. JSON을 붙여넣으면, 형식이 잘못되었을 경우 원시 바이트 오프셋 대신 특정 줄과 문자를 가리키는 명확한 오류를 얻습니다. 유효하다면 적절한 들여쓰기로 깔끔하게 렌더링되어 구조를 시각적으로 훑어볼 수 있습니다. Bellows는 하나의 도구에서 두 경우를 모두 처리합니다 — JSON이 깨졌는지 미리 알 필요가 없습니다.
배포 전에 실수 잡아내기
설정 파일, API 요청 본문, 픽스처 데이터는 모두 유효한 JSON에 생사가 걸려 있습니다. 설정 변경을 커밋하거나 테스트 요청을 보내기 전에 빠르게 검증을 거치면, 그렇지 않았을 경우 파이프라인 훨씬 뒤쪽에서 혼란스러운 런타임 오류로 나타났을 오타를 미리 잡아낼 수 있습니다.
신뢰할 수 없는 입력값 다루기
동료가 Slack에 JSON 데이터를 붙여넣거나, 완전히 신뢰하지 않는 제3자 API에서 하나를 가져올 때, 로컬에서 검증하면 파싱이 되는지 확인하려고 외부 웹사이트로 데이터를 보낼 필요가 없어집니다.