JSON Schema 검증기

사용법

왼쪽에 JSON Schema, 오른쪽에 검증할 JSON 문서를 붙여 넣으세요. 검증기는 Ajv(Another JSON Validator, JS에서 가장 많이 쓰이는 라이브러리)를 `allErrors: true`로 실행해 첫 번째 오류만이 아니라 실패 지점을 모두 보고합니다. 각 에러에는 실패 필드로 가는 JSON Pointer, 거부한 스키마 키워드(`required`·`type`·`minLength`·`format` 등), 사람이 읽을 수 있는 메시지가 포함됩니다. 검증은 입력에 따라 실시간으로 실행되므로 붙여 넣고 편집하면서 에러가 사라지고 나타나는 모습을 볼 수 있습니다.

API 계약 설계, 공개된 스키마에 대한 샘플 페이로드 검증, 웹훅 수신 측이 본문을 계속 거부하는 원인 추적에 사용하세요. 이 도구는 `ajv-formats`를 포함해 표준 포맷 체크(`email`·`date-time`·`uri`·`uuid`·`ipv4`·`regex`)가 즉시 동작합니다. 스키마와 데이터는 브라우저 밖으로 나가지 않습니다. 사내 필드명이나 개인정보가 들어간 페이로드에도 안심하고 쓸 수 있습니다. 런타임에 자체 코드에서 쓸 때도 같은 Ajv 라이브러리가 다수의 서버 측·CLI 검증기(`ajv-cli`·NestJS의 validation pipe·Fastify의 스키마 등)를 구동합니다.

예제

schema:
{
  "type": "object",
  "required": ["id", "email"],
  "properties": {
    "id":    { "type": "integer", "minimum": 1 },
    "email": { "type": "string", "format": "email" },
    "tags":  { "type": "array", "items": { "type": "string" }, "uniqueItems": true }
  }
}

data:
{ "id": 1, "email": "[email protected]", "tags": ["admin", "founder"] }

✓ valid

schema: (same as above)

data:
{ "id": -3, "email": "not-an-email", "tags": ["a", "a"] }

✗ 3 errors
/id     minimum  must be >= 1
/email  format   must match format "email"
/tags   uniqueItems  must NOT have duplicate items (items ## 1 and 0 are identical)

schema:
{
  "$defs": {
    "Address": {
      "type": "object",
      "required": ["city"],
      "properties": { "city": { "type": "string" }, "zip": { "type": "string", "pattern": "^[0-9]{5}$" } }
    }
  },
  "type": "object",
  "properties": {
    "home":   { "$ref": "#/$defs/Address" },
    "office": { "$ref": "#/$defs/Address" }
  }
}

data:
{ "home": { "city": "Seoul" }, "office": { "city": "Tokyo", "zip": "100-0001" } }

✗ 1 error
/office/zip  pattern  must match pattern "^[0-9]{5}$"

자주 묻는 질문

관련 개념

JSON Schema는 JSON 데이터의 "모양"을 기술하기 위한 어휘입니다. 어떤 필드가 필요한지, 어떤 타입을 가질 수 있는지, 어떤 값이 허용되는지, 배열은 어떻게 생겨야 하는지 같은 것들입니다. 사양 드래프트는 2026년 기준 Draft 2020-12에서 *멈춰* 있고, 2022년에 표준화 트랙이 IETF로 옮겨졌지만 현재까지 공식 RFC는 나오지 않았습니다. 그럼에도 주요 생태계(Ajv·Python의 jsonschema·Swagger·OpenAPI 3.1·AWS API Gateway·JSON Forms 등)는 2020-12나 그 전임인 2019-09를 구현합니다. 옛 코드는 여전히 2018년의 준 LTS 체크포인트였던 Draft 07을 참조하기도 합니다.

어휘는 크게 4 영역을 다룹니다. **구조**: `type`·`properties`·`required`·`items`·`additionalProperties`·`patternProperties`. **제약**: `minimum`·`maximum`·`minLength`·`maxLength`·`pattern`·`uniqueItems`·`enum`·`const`. **합성**: `allOf`(모두 만족)·`anyOf`(최소 1개)·`oneOf`(정확히 1개)·`not`·`if·then·else`. **재사용**: 명명 서브 스키마용 `$defs`, JSON Pointer나 절대 URI로 참조하는 `$ref`, 안정된 명명 대상을 만드는 `$anchor`. 실운영 스키마에서 쓰이는 키워드는 총 5~10개 정도이며, 롱테일은 주로 명세 자체의 자기 기술과 엣지 케이스를 위해 존재합니다.

인접한 3가지 개념이 있습니다. **OpenAPI**(이전 명칭 Swagger)는 JSON Schema를 HTTP API 기술 형식으로 감싼 것이며 3.1이 완전 일치, 3.0은 분기된 부분 집합입니다. **TypeScript 타입**은 컴파일 시점에 비슷한 영역을 다루지만 런타임 측은 브리지(`zod`·`io-ts`·`runtypes`·`valibot`·`typia` 등)가 필요합니다. TypeScript는 컴파일 시점에 소거되기 때문입니다. **Protocol Buffers**와 **GraphQL SDL**은 같은 문제를 다른 구문으로 풉니다. protobuf는 스키마 + 바이너리 와이어 포맷, GraphQL은 스키마 + 쿼리 언어 접근입니다. JSON Schema가 이기는 자리는 이미 JSON을 다루고 있어 전송 계층을 다시 쓰지 않고 검증을 얹고 싶을 때입니다.