JSON Schema 검증기

JSON Schema 도구란?#

JSON 값 자체는 데이터가 무엇인지 알려줍니다. 여기는 문자열, 저기는 숫자. 하지만 데이터가 무엇이어야하는지는 알려주지 않습니다. age가 음이 아닌 정수여야 하는지, email이 필수인지, tags가 비어도 되는지. JSON Schema는 이런 것을 말하기 위한 어휘입니다. 모양을 기술하는 작은 JSON 문서인 스키마를 쓰면, 검증기가 데이터 한 조각이 그 모양에 들어맞는지 필드별로 검사합니다.

이 페이지는 하나의 스키마 엔진으로 두 가지 일을 합니다. 검증 은 스키마와 데이터 문서를 받아 어느 필드가 어느 규칙을 위반했는지 정확히 알려주며, 각각은 문서 안의 경로에 고정됩니다. 추론 은 반대 방향입니다. 샘플 JSON 값을 주면 구조를 따라가며 모든 필드의 타입을 기록하여 Draft-07 스타일 스키마를 대신 써 줍니다. 둘은 자연스럽게 연결됩니다. 대표 샘플에서 스키마를 추론한 뒤, 이후의 모든 문서를 그것으로 검증하세요.

검증은 프로덕션 코드가 쓰는 것과 같은 Ajv 엔진에서 실행되며, 세 가지 초안(Draft-07, 2019-09, 2020-12)을 선택할 수 있고 strict-mode 가드를 느슨하게 풀어, 약간 비표준인 스키마도 곧바로 거부되는 대신 허용됩니다.

사용 방법#

1. 도구 모음 토글에서 모드 를 고르세요.
   • 검증 (기본값): 왼쪽에 스키마, 오른쪽에 데이터를 붙여넣으세요.
   • 추론: 왼쪽에 샘플 JSON 값을 붙여넣고 오른쪽에 생성된 스키마를 읽으세요.
2. 검증 모드에서 스키마가 쓰인 Draft 를 고르세요. Draft-07이 야생의 대다수 스키마를 덮습니다. 그 초안들이 도입한 기능을 스키마가 쓸 때만 2019-09나 2020-12를 고르세요.
3. 출력의 들여쓰기 를 고르세요. 공백 2칸 또는 4칸. 추론 모드에서는 생성된 스키마의 포매팅을 결정합니다.
4. 오른쪽 패널 은 데이터 문서(검증) 또는 추론된 스키마(추론)를 보여줍니다. 패널 레이블은 모드에 맞게 바뀝니다.
5. 검증 모드에서 패널 아래 위반 목록 패널이 모든 위반을 경로 — 사유로 나열합니다. 문서 루트는 (root)로 표시되고, 중첩 필드는 /age처럼 JSON Pointer로 나타납니다.
6. 오른쪽 패널의 복사 로 추론된 스키마나 데이터를 가져가거나, 예제 / 지우기 로 불러오거나 초기화하세요.

결과는 두 입력이 모두 파싱되는 즉시 계산됩니다. 스키마나 데이터 구문 오류는 정확한 행과 열과 함께 보고되며, 스키마·데이터·컴파일 문제로 태그가 붙어 어디를 봐야 할지 알 수 있습니다.

주요 기능#

• 두 모드, 한 엔진. 같은 신뢰할 수 있는 검증기로 문서를 검증하거나 샘플에서 스키마를 생성합니다.
• 세 가지 초안. Draft-07, 2019-09, 2020-12가 각각 자기 초안의 컴파일된 검증기만 로드하여, 실제로 겨냥하는 초안에 대해 항상 검증합니다.
• 첫 번째가 아니라 모든 오류. 모든 위반이 수집되어, 다섯 개 문제가 있는 문서는 다섯 번의 왕복을 강요하는 대신 다섯 개 문제를 보여줍니다.
• 경로가 고정된 위반. 각 위반은 문서 안의 위치를 가리킵니다. 문서 전체 문제는 (root), 정확한 포인터는 /user/address/zip처럼.
• strict mode 완화. 알 수 없는 키워드나 누락된 최상위 타입을 가진 스키마도 컴파일 시 거부되는 대신 허용되어 실행됩니다. 검사가 아니라 훈계가 일인 도구에 알맞은 동작입니다.
• 로컬 전용. 스키마와 데이터는 브라우저에서 처리됩니다. 아무것도 업로드되지 않습니다.

실전 예시#

user 객체는 name을 가져야 하고, age는 음이 아닌 정수여야 합니다. 검증 모드에서 왼쪽에 이 스키마를 붙여넣으세요.

{
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "age": { "type": "integer", "minimum": 0 }
  },
  "required": ["name"]
}

이제 두 규칙을 모두 깨는 문서를 테스트해 보세요. name이 빠지고 age가 음수입니다.

{
  "age": -3
}

위반 목록 패널은 두 위반을 보고하며, 각은 일어난 자리에 고정됩니다.

(root) — must have required property 'name'
/age   — must be >= 0

(root) 경로는 빠진 필수 속성이 문서 수준의 문제임을 알려줍니다. /age는 범인 필드를 곧장 가리킵니다. 데이터를 {"name":"ada","age":36}으로 고치면 상태가 유효로 바뀌고 위반 목록이 비워집니다. 사유 텍스트는 Ajv 자신의 키워드 표현을 그대로 쓴 것으로, 프로덕션 로그가 말할 것과 일치합니다.

FAQ#

Draft-07, 2019-09, 2020-12 중 어느 것을 골라야 하나요?#

Draft-07이 실용적인 기본값입니다. 튜토리얼·라이브러리·OpenAPI 사양의 압도적 다수가 이를 겨냥하고, 사용자가 필요로 할 만한 것(type, properties, required, minimum, format, $ref)이 모두 동작합니다. 그 초안들이 추가한 기능(unevaluatedProperties나 수정된 $ref 동작 등)을 스키마가 명시적으로 쓸 때만 2019-09나 2020-12로 옮기세요. 잘못된 초안을 골라도 보통 동작하지만, 안전한 선택은 스키마 작성자가 의도한 초안입니다.

왜 위반 메시지가 영어인가요?#

각 키워드에 대한 Ajv 자신의 사유 텍스트(must have required property, must be >= 0 등)를 바꾸지 않고 그대로 전달합니다. 요점은 일관성입니다. 서버 측 검증이 로그에 남길 정확한 문자열이어서, 여기서 맞춰두면 프로덕션에서 불일치를 grep하기 쉽습니다.

”strict mode relaxed”는 무슨 뜻인가요?#

Ajv의 strict mode는 지저분하다고 여기는 스키마(알 수 없는 키워드, 해결할 수 없는 $ref, 빠진 type)를 거부합니다. 빌드 파이프라인에는 유용하지만 검증 도구에는 틀립니다. 검증 도구의 일은 주어진 스키마에 대해 데이터를 검사하는 것입니다. 이 페이지는 strict mode를 꺼서, 비표준 스키마가 예외를 던지는 대신 컴파일되어 실행됩니다.

스키마를 추론한 뒤 그것으로 검증할 수 있나요?#

네, 그것이 의도된 왕복입니다. 추론 모드에서 대표 샘플을 붙여넣고, 생성된 스키마를 복사해 검증 으로 전환한 뒤, 스키마를 왼쪽에 다시 붙여넣으세요. 추론된 스키마는 원래 샘플을 깨끗이 재검증하며, 그 이후로는 모든 새 문서를 그것으로 검사할 수 있습니다.