JSON Schema ⇄ Zod 변환

입력이 다릅니다. JSON to Zod는 API 응답 같은 "값 샘플"에서 타입을 추론하므로 어떤 필드가 필수인지, 문자열 format이 무엇인지는 알 수 없습니다. 이 도구는 JSON Schema 자체를 입력으로 받기 때문에 required, enum, minLength, format:email 같은 제약이 그대로 Zod 체인(.optional() / .enum() / .min() / .email())에 반영됩니다. OpenAPI나 JSON Schema 정의가 이미 있다면 이쪽이 정확합니다.

기본값이 서로 반대입니다. JSON Schema는 required 배열에 나열되어야 필수이고, Zod는 .optional()이 없으면 필수입니다. 변환기는 이 차이를 흡수해, JSON Schema→Zod에서는 required에 없는 프로퍼티에 .optional()을 붙이고, 반대 방향에서는 .optional()이 없는 프로퍼티를 required 배열로 모읍니다.

참조는 전개하지 않습니다. $ref는 z.any()가 되고 경고가 표시됩니다. 공통 정의를 $defs로 빼둔 스키마라면 붙여 넣기 전에 전개하거나, 생성된 결과에서 그 부분만 직접 고쳐 주세요. allOf도 교차 타입으로 표현할 수 없어 첫 번째 서브스키마만 변환하고 경고를 냅니다.

뼈대로는 쓸 수 있지만, 원래 JSON Schema에 없던 업무 규칙(허용 이메일 도메인, 필드 간 정합성 등)은 생성되지 않습니다. 또한 pattern은 z.string().regex()로 변환되는데, 원래 정규식이 ECMAScript 호환이 아니면 동작이 달라질 수 있습니다. 생성 후 반드시 내용을 확인하세요.

OpenAPI의 components.schemas는 JSON Schema이므로 그대로 붙여 넣으면 Zod 스키마와 z.infer 타입을 한 번에 얻을 수 있습니다. 서버 정의와 프런트 검증이 어긋나는 것을 막아 줍니다.

코드에서 Zod 스키마를 먼저 작성했다면 반대 방향 변환으로 JSON Schema를 만들어 OpenAPI의 components나 문서에 붙여 넣을 수 있습니다.

if 문으로 흩어진 검증을 교체할 때, JSON Schema가 있으면 출발점이 되는 Zod 스키마를 한 번에 생성할 수 있어 required나 enum을 빠뜨릴 일이 줄어듭니다.

LLM에 작성시킨 JSON Schema를 그대로 붙여 넣어 TypeScript에서 동작하는 Zod 스키마로 바꾸고, 타입과 런타임 검증을 동시에 얻을 수 있습니다.

$ref는 참조를 해결하지 않고 z.any()가 되며, allOf는 첫 번째 서브스키마만 변환합니다. if/then/else와 not은 지원하지 않습니다. 모두 결과 아래에 경고로 표시되므로 해당 부분은 직접 보완해 주세요.

브라우저 안에서 처리하기 위해 코드를 실행하지 않고 텍스트로 파싱합니다. z.object / z.array / z.union / z.enum / z.literal / z.record와 주요 메서드 체인은 지원하지만, 변수로 분리한 스키마 참조나 .refine() 같은 임의 함수는 JSON Schema로 표현할 수 없어 무시됩니다.

JSON Schema의 pattern은 z.string().regex()가 되고, 반대 방향에서는 그 내용이 pattern에 들어갑니다. JSON Schema는 ECMAScript 호환이 아닌 정규식도 허용하므로 그대로 옮기면 동작이 달라질 수 있습니다.

이 도구는 마이그레이션의 출발점을 만들기 위한 것입니다. 업무 규칙이나 필드 간 정합성 검사는 원래 스키마에 없으면 생성되지 않으므로, 운영에 쓰기 전에 내용을 확인해 주세요.