📐 JSON Schema 검증
JSON Schema를 사용하여 JSON을 검증합니다. 타입 불일치, 필수 프로퍼티 누락, enum 범위 초과, 정규식 위반 등의 오류를 위치 정보와 함께 표시합니다. Draft 7, 2019-09, 2020-12 지원합니다.
결과가 여기 표시됩니다.
🔗 관련 도구
📖 자주 걸리는 지점
Ajv 8 로 JSON Schema(Draft 7 / 2019-09 / 2020-12)를 실행해 타입 불일치 · 필수 누락 · enum 밖 등을 필드 경로와 함께 표시합니다. 처리는 브라우저 안에서 끝납니다. 에러 0 건은 데이터가 옳다는 뜻이 아닙니다 — 스키마가 느슨하면 무엇이든 통과하기 때문입니다. JSON Schema 에서 걸리는 지점의 대부분은 썼다고 생각한 제약이 실제로는 듣고 있지 않다는 것에 집중되어 있습니다.
| 사례 | 무슨 일이 일어나는가 | 어떻게 하면 되는가 |
|---|---|---|
| format: email 이라고 썼는데 잘못된 메일이 통과한다 | format 은 기본적으로 주석이며 검증하지 않습니다. 이는 구현의 손 뺌이 아니라 JSON Schema 사양대로의 동작이며 format 의 검증은 필수가 아닌 어휘로 정의되어 있습니다 — 구현이 대응하지 않아도 준수를 표방할 수 있습니다. Ajv 도 마찬가지여서 ajv-formats 를 따로 읽어들이지 않는 한 email · date-time · uri · uuid 는 모두 그냥 통과합니다. 스키마를 쓴 사람은 검증하고 있다고 생각하고 실행 쪽은 그냥 통과시키는 어긋남이 프로덕션까지 발견되지 않는 것이 까다로운 점입니다. |
서버 쪽에서는 반드시 ajv-formats 를 넣으세요 — const addFormats = require("ajv-formats"); addFormats(ajv); 두 줄입니다. 이식성을 우선한다면 pattern 으로 정규식을 쓰는 편이 확실하며 어느 구현에서도 같은 결과가 됩니다(다만 메일 주소의 완전한 정규식은 현실적이지 않으므로 ^[^@\s]+@[^@\s]+\.[^@\s]+$ 정도로 그치고 실재 확인은 확인 메일로 하는 것이 정석입니다). 스키마를 공유할 상대가 있다면 format 을 검증하는 전제인지 여부를 명기하세요 — 여기가 암묵이 되면 받는 쪽 구현에 따라 검증의 강도가 달라집니다. |
| required 를 썼는데 프로퍼티가 빠져도 통과한다 | 둘 곳을 잘못 잡은 경우가 대부분입니다. required 는 오브젝트 스키마 바로 아래에 키 이름의 배열로 씁니다 — {"type":"object","properties":{...},"required":["id","name"]} 형태입니다. properties 안에 "required": true 라고 쓰는 것은 Draft 3 의 작성법이며 현재의 Draft 에서는 단순히 알 수 없는 키워드로 무시됩니다 — 에러조차 나지 않으므로 알아챌 수 없습니다. 같은 이유로 철자를 틀린 requred 나 minLenght 도 조용히 무시됩니다. |
Ajv 를 strict: true 로 돌리세요 — 알 수 없는 키워드나 모순되는 타입 지정을 에러로 보고하게 되어 이런 종류의 조용히 듣지 않는 제약을 전부 드러낼 수 있습니다. 아울러 스키마 자체에 테스트를 쓰세요 — 통과해야 할 데이터뿐 아니라 통과해서는 안 될 데이터를 반드시 한 건 이상 넣는 것이 요점입니다. 전자만의 테스트는 스키마가 비어 있어도 통과합니다. 중첩된 오브젝트의 필수는 그 오브젝트의 스키마 안에 씁니다 — 부모의 required 는 자식의 키에는 닿지 않습니다. |
| additionalProperties: false 를 썼는데 여분의 키가 통과한다 | allOf 나 $ref 와 조합한 순간 듣지 않게 됩니다. 이유는 additionalProperties 가 같은 스키마 오브젝트 안에 쓰인 properties 밖에 보지 않기 때문입니다. 기저 스키마를 allOf 로 상속해 자식 쪽에서 additionalProperties: false 라고 쓰면 기저에서 정의한 프로퍼티조차 추가 프로퍼티로 간주되어 올바른 데이터가 전부 떨어집니다. 반대로 기저 쪽에 쓰면 자식에서 더한 프로퍼티가 튕깁니다. JSON Schema 에서 가장 많은 시간이 녹는 곳이며 스키마 상속을 쓴 시점에 거의 반드시 밟습니다. |
2019-09 이후라면 unevaluatedProperties: false 를 쓰세요 — 이쪽은 allOf 나 $ref 로 평가가 끝난 프로퍼티를 뺀 뒤 판정하므로 상속과 함께 쓸 수 있습니다. 이것이 바로 이 문제를 해결하기 위해 추가된 키워드입니다. Draft 7 에 머물러야 한다면 상속을 그만두고 스키마를 한 장으로 펼치는(번들 시에 평탄화하는) 편이 빠릅니다. 덧붙여 API 의 입력 검증에서 알 수 없는 키를 튕겨야 하는지는 설계 판단입니다 — 튕기면 클라이언트의 전방 호환성이 사라져 필드를 하나 더하는 것만으로 기존 클라이언트가 깨집니다. 입력은 튕기고 출력은 허용한다(포스텔의 원칙)가 무난합니다. |
$schema 를 제대로 쓰세요 — 생략하면 구현이 기본 드래프트를 마음대로 고르므로 같은 스키마가 환경에 따라 다른 의미가 됩니다. 특히 Draft 7 과 2020-12 에서는 배열의 키워드가 바뀌었습니다: 튜플(위치마다 타입이 다른 배열)의 지정은 items 의 배열 형식에서 prefixItems 로 옮겨졌고 2020-12 구현에 Draft 7 의 튜플 표기를 읽히면 배열의 모든 요소에 첫 번째 타입이 적용됩니다 — 에러가 나지 않고 의미만 조용히 바뀝니다. 한 가지 더, 검증을 통과한 데이터를 그대로 믿지 마세요. JSON Schema 가 보장하는 것은 형태이며 그 ID 가 실재하는가, 금액과 명세의 합계가 일치하는가 같은 업무상의 정합성은 대상 밖입니다. 스키마 검증은 입구의 필터이지 도메인 검증의 대체가 아닙니다.
📖 사용법
-
1
JSON Schema 입력왼쪽에 JSON Schema를 붙여넣습니다. 샘플 버튼으로 예제를 불러올 수 있습니다.
-
2
검증할 JSON 데이터 입력오른쪽에 검증할 JSON 데이터를 붙여넣습니다.
-
3
검증 결과 확인 후 수정오류가 있으면 필드 경로, 메시지, 파라미터가 표시됩니다.
❓ 자주 묻는 질문
어떤 Draft 버전을 지원하나요?
format 검증(email, date 등)이 작동하나요?
JSON Schema란 무엇인가요?
🐛 이 도구에서 문제가 발생했나요?
무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.
보고 감사합니다!
운영자에게 전달되었습니다. 개선에 사용됩니다.