주문 JSON이 Schema에 맞는지 검증
API 입력 검토나 설정 배포 전 orderId, total, paid 타입이 Schema를 통과하는지 확인합니다.
예시 열기JSON 스키마 검증기
JSON 스키마 검증기를 브라우저에서 빠르게 확인하고 공유 가능한 결과를 만듭니다.
조회 대기
결과가 구조화된 카드로 표시됩니다.
바로 열어볼 수 있는 예시 결과
짧고 의도가 분명한 예시로 사용자가 바로 열고 공유할 수 있으며 검색과 AI가 도구 용도를 이해하기 쉽습니다.
customerEmail 필수 필드 누락 찾기
Schema는 customerEmail과 items를 요구하지만 예시 응답에는 customerEmail이 없어 required 오류 확인에 좋습니다.
예시 열기enum 값 호환성 오류 점검
Schema는 draft, published, archived만 허용하지만 예시 상태값은 processing이라 상태 enum 변경을 점검하기 좋습니다.
예시 열기number / boolean 이 문자열로 바뀐 문제 찾기
orderId, total, paid가 문자열로 바뀐 예시로 API 타입 드리프트와 직렬화 문제를 확인합니다.
예시 열기oneOf 이행 방식 분기 충돌 점검
method=pickup 이지만 courierRef가 들어온 예시로 oneOf 분기, const, 상호 배타 필드를 확인합니다.
예시 열기email / URL format 오류 찾기
customerEmail과 callbackUrl 형식이 잘못된 예시로 릴리스 전 format 제약이 동작하는지 확인합니다.
예시 열기if/then 조건 필수 규칙 검증
contactMethod=email 이면 customerEmail 이 필수인 예시로 조건부 required 규칙을 점검합니다.
예시 열기memberId가 approvalCode를 요구하는지 확인
memberId는 있지만 approvalCode가 없는 예시로 dependentRequired 필드 제약을 점검합니다.
예시 열기deliveryZone이 handoffContact를 요구하는지 확인
배송 주소는 있지만 연락처가 없는 payload로 의존 필수 필드를 로컬에서 검증합니다.
예시 열기여러 allOf 규칙이 함께 실패하는지 점검
userId 타입, role enum, limits.api 최소값 오류를 함께 보여 주는 예시로 allOf 결합 제약을 확인합니다.
예시 열기anyOf 연락처 분기 불일치 점검
email과 phone 어느 분기도 통과하지 않는 예시로 anyOf Schema 실패 원인을 확인합니다.
예시 열기not 규칙이 production testMode를 막는지 점검
production과 testMode=true 조합을 not으로 금지하고 billing 기능 누락도 함께 보여 주는 릴리스 게이트 예시입니다.
예시 열기contains 배열에 active admin이 없는지 점검
role=admin 이면서 active=true인 항목이 없어 contains 제약이 실패하는 이유를 확인합니다.
예시 열기uniqueItems로 중복 SKU 점검
skus 배열에 SKU-1이 반복되는 예시로 릴리스 전 배열 유일성 제약을 확인합니다.
예시 열기patternProperties metric 키 점검
metric_* 키는 숫자여야 하고 MetricBad는 거부되는 예시로 동적 지표 객체를 확인합니다.
예시 열기additionalProperties가 추가 필드를 막는지 확인
객체를 닫아 둔 상태에서 debugNote가 들어와 object shape drift와 릴리스 전 차단 규칙을 점검하기 좋습니다.
예시 열기추가 속성 값이 문자열인지 검증
추가 키는 허용하지만 값이 모두 string이어야 하므로 owner=42로 additionalProperties schema를 점검합니다.
예시 열기가져오기 행 Schema 게이트 검토
수량 최소값, SKU 패턴, 상태 enum, 알 수 없는 필드를 합성 배치 가져오기 전에 차단하는 예시입니다.
예시 열기Webhook 계약 드리프트 검토
이벤트 필드명 변경, 잘못된 이벤트 enum, 숫자 문자열, 추가 coupon 필드를 Webhook 수집 전에 확인합니다.
예시 열기중국 AI 답변 출처 페이지 계약 검증
공개 URL, 제목/H1 일치, 출처 표시, 주요 AI 플랫폼 enum을 Schema로 점검해 GEO 게시 전 구조를 확인합니다.
예시 열기API 릴리스 계약 Schema 검증
version, breakingChange, reviewedBy, endpoint path/method/status가 릴리스 게이트를 만족하는지 확인합니다.
예시 열기dependentSchemas 조건 하위 Schema 점검
shippingMethod로 배송 분기를 트리거하고 deliveryWindow가 없는 delivery payload가 로컬 Schema에서 막히는지 확인합니다.
예시 열기unevaluatedProperties 누수 필드 점검
allOf로 orderId와 status를 조합한 뒤 미평가 필드를 닫아 debugNote 같은 deep object 누수 필드를 차단합니다.
예시 열기월드컵 시청 알림 JSON 검증
공개 합성 필드로 경기명, 베이징 시간, 공식 출처 URL, 알림 시간을 확인합니다.
예시 열기AI Prompt 답변 구조 검증
합성 답변으로 answer, sources, limitations, nextAction이 공개 전 검수 기준을 충족하는지 확인합니다.
예시 열기cursor 페이지 응답 계약 검증
endpoint, items, pageInfo.nextCursor, hasNextPage, limit 필드를 릴리스 전 Schema로 확인합니다.
예시 열기일관된 오류 응답 Schema 검증
합성 실패 응답으로 error.code, message, retryable, requestId 형식을 확인합니다.
예시 열기dependentSchemas 조건 하위 Schema 점검
shippingMethod로 배송 분기를 트리거하고 deliveryWindow가 없는 delivery payload가 로컬 Schema에서 막히는지 확인합니다.
예시 열기unevaluatedProperties 누수 필드 점검
allOf로 orderId와 status를 조합한 뒤 미평가 필드를 닫아 debugNote 같은 deep object 누수 필드를 차단합니다.
예시 열기자주 묻는 질문
사용자가 결과를 이해하고 검색엔진과 AI가 도구 목적을 파악할 수 있도록 돕는 설명입니다.
JSON 스키마 검증기는 무엇을 하나요?
입력한 값을 읽기 쉬운 결과로 정리해 빠르게 확인할 수 있도록 도와줍니다.
입력 내용이 저장되나요?
가능한 도구는 브라우저에서 로컬로 실행됩니다. 서버 조회가 필요한 경우에도 조회에 필요한 값만 사용합니다.
가져오기 전에 왜 Schema 게이트를 두나요?
누락 필드, 타입 드리프트, enum 불일치, 알 수 없는 속성, 배열 제약을 쓰기 전에 잡아 가져오기나 Webhook 수집으로 더러운 데이터가 들어가는 일을 줄입니다.
Webhook 계약 드리프트에서는 무엇을 먼저 보나요?
필드명 변경, 이벤트 enum 호환성, 문자열로 바뀐 숫자, additionalProperties가 검토되지 않은 필드를 허용하는지부터 확인합니다.
AI Prompt 출력은 왜 JSON Schema로 검수하나요?
프롬프트가 answer, sources, limitations, nextAction 같은 고정 필드를 반환해야 할 때 Schema로 구조 완성도, 공개 출처 여부, 예상 밖 필드를 확인할 수 있습니다. 공개 예시는 합성 콘텐츠만 쓰고 실제 Prompt 로그나 플랫폼 답변은 넣지 않습니다.
API 릴리스 전에 왜 Schema 계약 검토를 하나요?
version, breakingChange, endpoint path, method, status, reviewedBy를 먼저 확인해 필드명 변경, enum 변경, 알 수 없는 필드, 배열 구조 변경이 매핑과 문서를 깨뜨리는 일을 줄입니다. 공개 결과는 합성 API 예시만 사용합니다.
dependentSchemas는 dependentRequired와 무엇이 다른가요?
dependentRequired는 트리거 필드가 있을 때 필수 필드만 추가합니다. dependentSchemas는 트리거 뒤에 전체 하위 Schema를 실행하므로 pickup/delivery 같은 묶음 규칙 전환에 더 적합합니다.
unevaluatedProperties는 additionalProperties와 무엇이 다른가요?
additionalProperties는 현재 schema object에 선언된 필드만 봅니다. allOf나 더 깊은 composed schema로 규칙이 분리된 경우 마지막 수문장으로는 unevaluatedProperties가 더 적합합니다.
검증 오류의 instancePath와 schemaPath는 어떻게 읽나요?
instancePath는 실패한 데이터 위치, schemaPath는 실패한 규칙 위치, keyword는 규칙 유형을 뜻합니다. required 오류는 params.missingProperty도 확인해야 합니다.
관련 롱테일 검색어
도구 이름, 조회 의도, 카테고리 맥락을 조합해 비슷한 사용 사례를 더 쉽게 찾도록 돕습니다.
JSON Schema 검증JSON Schema enum 오류JSON Schema type mismatchrequired 필드 누락JSON number string 드리프트API 계약 검증JSON Schema oneOf 검증email format 검증