JSON Validator, JSON Linter, JSON Schema의 차이점은 무엇인가요?

JSON이 정상적으로 파싱되어도 API가 거부할 수 있고, Validator가 유효하다고 해도 Linter가 경고할 수 있습니다. 세 도구가 서로 다른 질문에 답하기 때문입니다.

JSON Validator는 텍스트가 올바른 JSON인지, JSON Linter는 품질과 일관성 규칙을 지키는지, JSON Schema는 데이터가 따라야 할 구조와 제약을 정의합니다.

> 권장 순서: 구문 검증 → Lint → Schema 검증.

Validator라는 용어의 두 가지 의미

JSON Validator는 두 종류를 가리킬 수 있습니다. 구문 Validator는 JSON.parse 같은 파서로 JSON 문법을 확인합니다. JSON Schema Validator는 Schema와 JSON Instance를 입력받아 Instance가 계약을 충족하는지 확인합니다.

Json Work의 JSON Validator는 주로 첫 번째 유형입니다. JSON Schema 공식 문서에서 Validator는 보통 두 번째 유형입니다. 문서에서는 syntax validator와 schema validator를 구분해 쓰는 것이 안전합니다.

JSON Validator: 텍스트를 파싱할 수 있는가

RFC 8259는 객체, 배열, 문자열, 숫자, 불리언과 null을 포함한 JSON 문법을 정의합니다. 아래 예시는 쉼표가 없어 유효하지 않습니다.

{
  "id": 101
  "name": "Alice"
}

구문 Validator는 쉼표 누락, 닫히지 않은 따옴표나 괄호, 잘못된 이스케이프, 따옴표 없는 키, undefined나 NaN 같은 허용되지 않는 값을 찾습니다.

그러나 다음 데이터는 구문상 완전히 유효합니다.

{
  "id": "one hundred",
  "email": "not-an-email",
  "active": "yes"
}

Validator는 id가 정수여야 하는지, active가 불리언이어야 하는지 모릅니다. “올바른 JSON 텍스트인가”만 답합니다. JSON Validator로 오류 위치를 찾고, JSON과 비슷한 손상된 입력은 JSON Repair로 후보를 만든 뒤 의미를 검토하세요.

JSON Linter: 품질과 일관성은 괜찮은가

Lint는 규칙 기반 정적 분석입니다. JSON 문법과 달리 모든 Linter가 공유하는 단일 규칙 표준은 없습니다. 도구나 팀이 유지보수성과 위험에 맞춰 규칙을 정합니다.

{
  "user_id": 101,
  "userName": "Alice",
  "isActive": "true"
}

이 JSON은 유효하지만 Linter는 snake_case와 camelCase 혼용, 불리언처럼 보이는 문자열, 같은 필드의 타입 불일치, 과도한 중첩을 지적할 수 있습니다.

경고가 곧 데이터 오류라는 뜻은 아닙니다. 상위 계약이 문자열 "true"를 요구할 수도 있습니다. JSON Linter는 암묵적인 규칙을 드러내지만 계약 없이 비즈니스 의도를 증명하지는 못합니다.

JSON Schema: 데이터 계약을 정의한다

JSON Schema는 타입, 필수 속성, 배열 항목, 길이, 숫자 범위, enum과 조합 조건을 표현하는 표준화된 어휘입니다. 공식 사이트는 검증, 상호운용과 문서화를 주요 용도로 설명합니다.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "id": { "type": "integer" },
    "name": { "type": "string", "minLength": 1 },
    "email": { "type": "string", "format": "email" },
    "active": { "type": "boolean" }
  },
  "required": ["id", "name", "email"],
  "additionalProperties": false
}

Schema는 규칙 문서이지 실행 프로그램이 아닙니다. Ajv나 Python jsonschema 같은 Schema Validator가 이를 실제 Instance에 적용합니다. 공식 단계별 가이드도 Schema와 Instance를 구분합니다.

구현 설정도 중요합니다. format은 Validator와 옵션에 따라 강제 조건이 아니라 주석으로 동작할 수 있습니다. 공식 format 설명을 확인하고 Draft, Validator와 옵션을 고정하세요.

JSON Schema 생성기로 대표 샘플에서 초안을 만든 다음 범위, 길이, 패턴, enum과 추가 속성 정책을 사람이 보완해야 합니다.

같은 API 데이터에 대한 세 가지 답

{
  "id": "101",
  "name": "Alice",
  "email": "alice@example.com",
  "active": "true"
}

• • Validator: 통과. 모든 토큰이 JSON 문법에 맞습니다.

• • Linter: 경고 가능. id와 active의 타입이 의심스럽지만 의도를 단정할 수 없습니다.

• • Schema Validator: 실패. 위 Schema에서는 id가 integer, active가 boolean이어야 합니다.

유효한 구문 ≠ 일관된 스타일 ≠ 유효한 데이터 계약

비교표

권장 검증 파이프라인

1. Syntax gate: 원시 텍스트를 파싱할 수 있는지 확인합니다.

1. Lint gate: 이름, 일관성과 팀 규칙을 검사합니다.

1. Schema gate: 명시한 Draft의 계약에 따라 검증합니다.

1. Business gate: 권한, 상태와 필드 간 비즈니스 규칙을 적용합니다.

“종료 시간이 시작 시간보다 늦어야 한다”거나 접근 권한을 확인하는 규칙은 Schema만으로 충분하지 않을 수 있습니다. Schema 통과를 비즈니스 작업의 안전성과 동일시하면 안 됩니다.

Ajv로 Schema 검증하기

import Ajv from "ajv";

const schema = {
  type: "object",
  properties: {
    id: { type: "integer" },
    name: { type: "string" },
    active: { type: "boolean" }
  },
  required: ["id", "name"],
  additionalProperties: false
};

const data = { id: "101", name: "Alice", active: true };
const ajv = new Ajv({ allErrors: true });
const validate = ajv.compile(schema);
if (!validate(data)) console.log(validate.errors);

Ajv는 id가 integer가 아니라고 보고합니다. 공식 가이드는 Schema를 한 번 컴파일하고 검증 함수를 재사용할 것을 권장합니다. 입력이 네트워크 원문이라면 Schema 검증 전에 JSON 파싱이 필요합니다.

흔한 오해

• • Validator 통과는 전체 데이터의 정확성을 보장하지 않습니다.

• • 모든 Lint 경고를 기계적으로 수정할 필요는 없습니다.

• • 하나의 샘플에서 생성한 Schema는 최종 계약이 아닙니다.

• • JSON Schema는 쉼표나 따옴표를 복구하지 않습니다.

정리

Validator는 올바른 구문, Linter는 품질과 일관성, JSON Schema는 구조와 데이터 계약을 지킵니다. 하나만 고르는 대신 순서대로 조합하는 것이 가장 신뢰할 수 있습니다.

JSON Validator로 구문을 확인하고 JSON Linter로 품질을 점검한 뒤 JSON Schema 생성기로 유지 가능한 계약을 만들 수 있습니다. 모든 처리는 브라우저에서 로컬로 실행됩니다.