JSON/YAML/XML Validator 사용법: 검증·정렬·압축을 헷갈리지 않는 법

“포맷 좀 정리해줘”라는 말은 생각보다 넓다. 어떤 사람은 깨진 JSON의 오류 위치를 찾고 싶어 한다. 어떤 사람은 리뷰하기 쉽게 들여쓰기를 맞추고 싶어 한다. 또 어떤 사람은 웹훅 테스트 화면에 붙여넣기 위해 공백을 줄이고 싶어 한다.

세 작업은 비슷해 보이지만 다르다. 검증은 맞고 틀림을 본다. 정렬은 사람이 읽기 좋게 만든다. 압축은 기계가 보내기 좋게 줄인다. 이 구분을 하지 않으면 도구는 버튼이 많아도 사용자를 돕지 못한다.

개발자용 포맷터를 만들 때 중요한 것은 예쁜 결과보다 안전한 순서다. 원본을 먼저 보존하고, 문법을 확인하고, 그 다음에 사람이 읽을 형태나 전송할 형태로 바꾸는 흐름이 좋다.

검증은 원본을 고치는 일이 아니다

JSON이나 YAML이 깨졌을 때 가장 먼저 해야 하는 일은 beautify가 아니라 validate다. 문법이 맞지 않는 입력을 예쁘게 정렬하려고 하면, 도구가 임의로 원본을 해석하거나 일부를 잃어버릴 수 있다. 특히 설정 파일이나 webhook payload처럼 실제 시스템에 들어갈 데이터라면 원본 보존이 더 중요하다.

검증 단계에서 사용자가 알고 싶은 것은 대개 세 가지다.

• 어느 줄과 어느 칸에서 문제가 생겼는가.
• 빠진 쉼표, 따옴표, 괄호처럼 흔한 오류인지.
• 파서가 어디까지 읽고 멈췄는지.

좋은 검증 도구는 “invalid”라고만 말하지 않는다. 사용자가 다음 행동을 할 수 있게 오류 위치와 이유를 보여준다. 가능하면 원본을 바로 덮어쓰지 않고, 수정된 후보를 별도로 보여주는 편이 안전하다.

Beautify는 리뷰를 위한 작업이다

Beautify는 데이터를 더 보기 좋게 만드는 일이다. JSON은 들여쓰기와 줄바꿈이 들어가고, XML은 태그의 계층이 드러나고, YAML은 중첩 구조가 읽기 쉬워진다. 이 작업은 사람이 리뷰하거나 diff를 볼 때 특히 유용하다.

하지만 beautify도 만능은 아니다. 데이터의 의미를 바꾸지 않아야 한다. 키 순서를 정렬할 때도 조심해야 한다. JSON 객체의 키 순서는 일반적으로 의미를 갖지 않는다고 말할 수 있지만, 사람이 읽는 설정 파일에서는 순서가 문서화의 일부처럼 쓰일 때가 있다. YAML은 더 민감하다. anchor, multiline string, 주석, indentation이 섞이면 단순 포맷팅이 원래 의도를 흐릴 수 있다.

그래서 포맷터는 “보기 좋게 바꾸기”와 “구조를 다시 쓰기”를 구분해야 한다. 가능하면 원본의 의미를 유지하고, 주석이나 특수 구문을 다루지 못할 때는 한계를 밝혀야 한다.

Minify는 전송을 위한 작업이다

Minify는 사람이 읽기 어렵게 만드는 대신 길이를 줄인다. API 요청 body, 환경변수 한 줄 입력, 작은 설정 필드, URL에 붙는 데이터처럼 공간 제약이 있을 때 유용하다. JSON에서는 공백과 줄바꿈을 제거하는 것만으로도 충분한 경우가 많다.

다만 압축된 결과는 디버깅에 불리하다. 오류가 나면 어느 부분이 잘못됐는지 찾기 어렵다. 그래서 minify는 최종 전송 직전에 쓰는 것이 좋다. 작업 순서는 보통 이렇다.

1. 원본을 붙여넣는다.
2. Validate로 문법을 확인한다.
3. Beautify로 사람이 읽을 수 있게 검토한다.
4. 필요할 때만 Minify로 줄인다.
5. 복사하기 전에 다시 한 번 결과 형식을 확인한다.

단순하지만 이 순서를 지키면 설정 실수를 줄일 수 있다.

JSON, YAML, XML은 서로 다른 습관을 가진다

세 형식은 모두 데이터를 표현하지만 읽는 방식이 다르다. JSON은 API와 JavaScript 생태계에 강하고, YAML은 설정 파일에 많이 쓰이고, XML은 오래된 시스템과 문서형 데이터에서 여전히 보인다.

JSON은 엄격하다. trailing comma, 작은따옴표, 주석이 허용되지 않는 경우가 많다. 그래서 오류가 빨리 드러난다. YAML은 사람이 쓰기 편하지만 indentation과 type 추론 때문에 예상과 다르게 해석될 수 있다. yes, on, 날짜처럼 보이는 값은 파서에 따라 다른 의미가 될 수 있다. XML은 태그가 길고 장황하지만, schema나 namespace가 필요한 환경에서는 아직 안정적인 선택이다.

도구가 이 차이를 무시하고 “모든 형식 포맷터”처럼만 행동하면 사용자는 작은 함정에 빠진다. 형식 자동 감지는 편하지만, 사용자가 명시적으로 JSON, YAML, XML을 고를 수 있는 옵션도 필요하다. 도구가 틀리게 감지했을 때 되돌릴 수 있어야 하기 때문이다.

브라우저 로컬 도구가 어울리는 이유

설정 파일과 payload에는 민감한 값이 섞이기 쉽다. API 키 전체가 들어가지 않더라도 endpoint, 내부 필드명, 테스트 사용자 정보, 조직 구조가 드러날 수 있다. 이런 데이터를 서버로 보내지 않고 브라우저 안에서 검증할 수 있다면 사용자는 훨씬 편하게 쓴다.

물론 브라우저 로컬이라는 말만 붙인다고 끝은 아니다. 실제로 네트워크 요청이 없어야 하고, 에러 로깅이나 분석 도구가 입력 내용을 가져가지 않아야 한다. 또한 큰 파일을 붙여넣었을 때 브라우저가 멈추지 않도록 적절한 제한과 안내가 필요하다.

이 지점에서 도구의 문체도 중요해진다. “안전합니다”라고 크게 말하는 것보다, “입력값은 이 브라우저 탭에서 처리되며 서버로 전송하지 않습니다. 단, 브라우저 메모리 한계 때문에 큰 파일은 느릴 수 있습니다”처럼 말하는 편이 더 믿을 만하다.

좋은 포맷터는 결과보다 실패를 잘 보여준다

포맷터는 성공할 때보다 실패할 때 품질이 드러난다. 정상 JSON을 넣으면 대부분의 도구가 예쁘게 정렬한다. 차이는 깨진 입력을 넣었을 때 나온다. 오류 위치가 보이는지, 원본이 유지되는지, 사용자가 다시 고칠 수 있는지, 복사 버튼이 잘못된 결과를 복사하지 않게 막는지 같은 부분이다.

특히 웹훅 payload를 다루는 경우에는 실패 메시지가 중요하다. “파싱 실패”보다 “12번째 줄 근처에서 닫는 중괄호가 필요합니다”가 훨씬 낫다. 사용자는 도구를 통해 문제를 해결하고 싶지, 파서의 차가운 예외 메시지를 보고 싶어 하는 것이 아니다.

마무리

JSON·YAML·XML 도구는 흔하지만, 흔하다는 이유로 대충 만들면 금방 얇아진다. 사용자는 단순히 보기 좋은 문자열을 얻으려는 것이 아니라, 설정이 왜 깨졌는지 알고 싶고, 안전하게 고치고 싶고, 필요한 형태로 복사하고 싶다.

검증, 정렬, 압축을 구분하는 것. 원본을 보존하는 것. 형식별 차이를 설명하는 것. 가능한 처리는 브라우저 안에서 끝내는 것. 이런 기준이 쌓이면 작은 포맷터도 실제 개발자의 작업 흐름에 맞는 도구가 된다.