Zod vs Yup
어떤 검증 라이브러리를 쓸까?
기본
| Zod | Yup | |
|---|---|---|
| 주간 다운로드 | 25439만 | 1236만 |
| 최근 릴리스 | 98일 전 | 1278일 전 |
| 유지보수 | 둔화 | 정체 |
| 열린 이슈 | 354 | 249 |
유지보수 상태는 최근 릴리스 간격만으로 판정합니다 (90일 이내 활발 · 270일 이내 둔화 · 그 이상 정체).
쓰다 보면 만나는 것
Zod
- 거슬림
v3는 대형 스키마에서 TypeScript 컴파일과 에디터가 눈에 띄게 느려지고 번들도 크다
체이닝 API 구조 탓에 타입 인스턴스화가 폭발해 대형 스키마에서 tsc·언어 서버가 느려지고, 트리셰이킹도 잘 되지 않는다. v4 공식 발표문이 v3의 문제를 수치로 자인한다 — 같은 파일이 v3에서 25,000회 타입 인스턴스화, v4에서 175회; 불리언 스키마 번들 12.47kb → 5.36kb. v3를 쓰는 대형 프로젝트에는 여전히 해당한다.
2026-08 · 해결됨 (2025-07) · 3.x
해결 근거: zod@4.0.0(2025-07-09, npm 레지스트리 기준)에서 타입 인스턴스화와 번들 구조가 재설계됐다. 수치 출처는 공식 v4 발표문
- 거슬림
Zod 는 첫 오류에서 멈추는 abortEarly 옵션이 없어 모든 검증 규칙이 실행되며, .refine()/.superRefine() 안의 검사도 앞선 필드가 실패한 뒤에 그대로 실행된다.
min/max 같은 앞선 검증이 이미 실패해도 뒤따르는 refine 콜백이 전부 호출되므로, uniqueness 확인용 DB 쿼리나 외부 API 호출을 refine 안에 두면 잘못된 입력에도 그 I/O가 매번 실행된다(dev.to 글은 이를 인증 없이 유발 가능한 DoS 로 설명하고, GitHub 이슈들은 동일 증상에 대한 전역 abortEarly 옵션을 요청한다). 전역 조기중단 옵션이 없으므로, 값 자체 검증이 아닌 비싼 작업은 스키마 밖으로 빼서 parse/safeParse 성공 이후에 실행하는 것이 우회법이며, .refine 의 abort:true 나 .superRefine 로 바꾸는 것은 이 실행 동작을 바꾸지 못한다.
2026-05 · 미해결
Yup
아직 정리된 항목이 없습니다. 출처가 확보되는 대로 추가됩니다.
이럴 땐 이걸
- TypeScript 우선·타입 추론 중심 → Zod