JSON Schema 검증기

예: 회원 가입 데이터의 NFD 한글

macOS의 HFS+ 파일 시스템은 파일 이름을 분해된 형태(NFD)로 저장합니다(Apple Technical Q&A QA1173). 그런 텍스트가 섞여 들어오면 화면에는 ‘홍길동’으로 보여도 길이 검사에서 걸립니다. 아래 데이터의 name은 JSON 이스케이프로 쓴 NFD ‘홍길동’입니다.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["name", "bizNo"],
  "properties": {
    "name": { "type": "string", "minLength": 2, "maxLength": 5 },
    "bizNo": { "type": "string", "pattern": "^[0-9]{3}-[0-9]{2}-[0-9]{5}$" },
    "phone": { "type": "string", "pattern": "^01[016789]-[0-9]{3,4}-[0-9]{4}$" }
  }
}

{
  "name": "\u1112\u1169\u11bc\u1100\u1175\u11af\u1103\u1169\u11bc",
  "bizNo": "123-45-6789",
  "phone": "010-1234-5678"
}

오류 2개, 위치 2곳(Draft 2020-12).
/name (2행 11열): 5자 이하여야 합니다. 9자입니다  스키마 #/properties/name/maxLength
/bizNo (3행 12열): 패턴 ^[0-9]{3}-[0-9]{2}-[0-9]{5}$과(와) 맞지 않습니다  스키마 #/properties/bizNo/pattern

maxLength는 유니코드 문자(코드 포인트) 수를 셉니다. NFC ‘홍길동’은 3자라 통과하고, NFD는 초성·중성·종성이 각각 1자라 9자가 됩니다. 사업자등록번호는 마지막 묶음이 다섯 자리여야 하는데 네 자리라서 pattern에 걸렸습니다.

예: $schema 없이 붙여넣은 draft-07 스키마

$schema가 없으면 2020-12로 검증합니다. draft-07 스타일로 items를 배열로 쓴 스키마는 2020-12에서는 스키마 자체가 잘못된 것이 됩니다.

{
  "type": "array",
  "items": [{ "type": "string" }, { "type": "integer" }],
  "additionalItems": false
}

["서울", 3, "추가"]

스키마 자체가 규격에 맞지 않습니다(Draft 2020-12):
#/items: object | boolean여야 하는데 array입니다 — Draft 2020-12의 "items"는 스키마 하나만 받습니다. 배열 형식은 draft-07 문법입니다. 위치별 스키마는 "prefixItems"를 쓰세요.
* $schema가 없어 Draft 2020-12로 검증했습니다. "$schema"를 쓰거나 메뉴에서 드래프트를 고르세요.
* Draft 2020-12에서는 #의 "additionalItems"가 무시됩니다. "prefixItems"와 "items"를 쓰세요.
* 스키마에 draft-07 문법 "items" (array), "additionalItems"가 있습니다. Draft 7을 고르거나 "$schema"를 쓰세요.

메뉴에서 Draft 7을 고르면 같은 스키마가 draft-07 규칙으로 검증되고, 세 번째 항목이 additionalItems에 걸립니다.

오류 1개(Draft 7).
(루트) (1행 1열): 항목은 2개까지입니다. 3개 있습니다  스키마 #/additionalItems

예: JSON Lines로 내보낸 로그

한 줄에 JSON 하나씩 붙여넣으면 줄마다 따로 검증하고, 오류가 있는 줄을 알려 줍니다.

{ "type": "object", "required": ["userId", "action"], "properties": { "userId": { "type": "integer" }, "action": { "enum": ["로그인", "로그아웃", "결제"] } } }

{"userId": 101, "action": "로그인"}
{"userId": "102", "action": "결제"}
{"userId": 103, "action": "환불"}

문서 3개 중 2개에 오류가 있습니다(Draft 2020-12).
문서 1(1행): 유효
문서 2(2행)
  /userId (2행 12열): integer여야 하는데 string입니다  스키마 #/properties/userId/type
문서 3(3행)
  /action (3행 27열): "로그인", "로그아웃", "결제" 중 하나여야 합니다  스키마 #/properties/action/enum
* 데이터를 JSON Lines로 읽었습니다. 3줄을 한 줄씩 검증합니다.
* $schema가 없어 Draft 2020-12로 검증했습니다. "$schema"를 쓰거나 메뉴에서 드래프트를 고르세요.

”판정할 수 없음”이 표시되는 경우

Ajv가 틀린 결과를 내는 것으로 알려진 입력에서는 유효·무효를 표시하지 않고 “판정할 수 없음”과 이유를 표시합니다. 복사한 텍스트와 JSON도 같습니다("state": "unknown", "valid": null). 회원 유형에 따라 필드를 받는 스키마에서 else를 빠뜨리면 이 경우에 해당합니다:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": { "memberType": { "enum": ["개인", "법인"] } },
  "if": { "properties": { "memberType": { "const": "법인" } } },
  "then": { "properties": { "bizRegNo": { "type": "string", "pattern": "^[0-9]{3}-[0-9]{2}-[0-9]{5}$" } } },
  "unevaluatedProperties": false
}

{ "memberType": "법인", "bizRegNo": "123-45-67890" }

판정할 수 없습니다(Draft 2020-12): 검증기가 정확히 검사할 수 없는 경우에 해당해 유효·무효 결과를 내지 않습니다. 이유는 아래에 있습니다.
판정할 수 없음. 이유:
- #/unevaluatedProperties의 "unevaluatedProperties"가 #/if의 "then"이나 "else"가 없는 "if"와 함께 쓰였습니다. Ajv는 이 조합을 잘못 판정합니다.

unevaluatedProperties와 then이나 else가 없는 if를 함께 쓰면 Ajv가 공식 테스트에서 틀립니다. 아무 제약이 없는 "else": true를 더하면 의미는 같고 검증할 수 있습니다:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": { "memberType": { "enum": ["개인", "법인"] } },
  "if": { "properties": { "memberType": { "const": "법인" } } },
  "then": { "properties": { "bizRegNo": { "type": "string", "pattern": "^[0-9]{3}-[0-9]{2}-[0-9]{5}$" } } },
  "else": true,
  "unevaluatedProperties": false
}

{ "memberType": "법인", "bizRegNo": "123-45-67890" }

유효: 데이터가 스키마에 맞습니다(Draft 2020-12).

이 밖에 $dynamicRef, unevaluatedItems와 contains 또는 anyOf / oneOf 안의 items 조합, 상대 참조와 중첩된 $id(Ajv의 스택이 넘침), $vocabulary를 바꾼 메타 스키마, 데이터에도 있는 __proto__ 속성, JavaScript가 정확히 담을 수 없는 숫자(9007199254740993 등)도 같은 방식으로 처리합니다.

오류를 묶는 방식

Ajv는 oneOf / anyOf에서 실패한 모든 분기의 오류를 나열합니다. “카드”와 “계좌” 두 가지 결제 수단 중 카드 번호 자릿수가 틀리면 Ajv는 오류 5개를 내고, 그중 3개는 상관없는 계좌 분기에서 나옵니다. 이 도구는 /payment에 오류 1개만 보여 주고 가장 가까운 분기(오류가 가장 적은 분기, const 판별 필드가 맞지 않는 분기는 뒤로)를 펼치며 나머지는 접어 둡니다. 분기가 $ref여도 같습니다. if / then 조건에서 실패하면 then에서 나온 오류를 바로 보여 주고 “then” 경유라고 표시하므로, 어떤 조건 때문에 필수가 되었는지 알 수 있습니다.

다른 온라인 도구와 비교

2026-10-02에 Bing(한국)에서 “JSON Schema 검증” 결과에 나온 LiteDevTools의 JSON Schema 검증기로 같은 입력을 시험했습니다.

두 도구 모두 브라우저 안에서 동작하며, 시험 중에 데이터를 담은 요청은 없었습니다.

제한

• 검증 엔진은 Ajv 8.18(ajv-formats 3.0.1, ajv-draft-04 1.0.0)입니다. 공식 JSON Schema Test Suite의 필수 테스트에서 draft-07은 929개 중 927개, 2020-12는 1,301개 중 1,210개가 기대한 결과이고, 나머지(2개, 91개)는 “판정할 수 없음”입니다. 틀린 결과를 내는 테스트는 없습니다. 판정은 스키마와 데이터의 구조만 보고 정하므로 $dynamicRef가 있는 스키마는 모두 “판정할 수 없음”이 되며, Ajv가 맞게 처리하던 테스트도 일부 포함됩니다.
• $ref의 URL은 내려받지 않습니다.
• JavaScript가 정확히 담을 수 없는 숫자(9007199254740993, 1.0000000000000001, 1e400 등)는 행 번호와 함께 안내하고, 스키마가 숫자를 비교하면 그 문서를 “판정할 수 없음”으로 표시합니다. 스키마나 YAML 데이터에 있으면 항상 “판정할 수 없음”입니다. multipleOf는 십진수 값으로 판정하므로 19.99는 0.01의 배수, 0.3은 0.1의 배수입니다(Ajv처럼 부동소수점 수로 나누면 배수가 아니라고 판정합니다). 중복된 키는 마지막 값만 남고 안내를 표시합니다.
• YAML 오류는 경로만 표시하고 행 번호는 표시하지 않습니다.
• 1 MB를 넘는 입력은 “검증” 버튼으로 실행하고, 20 MB를 넘는 파일은 읽지 않습니다.

샘플 데이터에서 스키마를 만들려면 JSON → JSON Schema, YAML 문법만 확인하려면 YAML 유효성 검사기, API 명세 전체를 검증하려면 OpenAPI 유효성 검사기를 쓰세요.