Zod와 React Hook Form

이번 프로젝트에서 Zod와 React Hook Form을 처음으로 사용해봤다.

 

Zod

TypeScript 친화적인 런타임 스키마/검증 라이브러리
z.object({...})로 입력 스키마를 선언하고 safeParse로 실제 값 검증
스키마에서 타입을 추론해 컴파일 타임과 런타임 타입 안전성을 확보
클라이언트/서버 양측에서 같은 스키마를 재사용하지 좋다.

 

React Hook Form

언컨트롤 입력을 기본으로 하는 경량 폼 라이브러리

리렌더 최소화: 대형 폼에서도 탁월

다양한 UI 컴포넌트와 쉽게 결합되고, @hookform/resolvers/zod로 스키마 기반 검증을 적용할 수 있다.

 

Zod와 React Hook Form가 유용한 경우

복잡한 유효성 검사 규칙

많은 필드와 중첩된 객체

서버 응답 스키마 검증

폼 상태 관리가 복잡한 경우

 

회원가입/로그인에서 사용하는 경우

서버 API 연동시 스키마 검증 필요

이메일, 비밀번호 등 복잡한 유효성 검사

에러 핸들링이 중요

재사용 가능한 검증 로직

 

왜 회원가입/로그인에서 자주 쓰나?

1. 보안·정합성 요구가 높음

• 이메일 형식, 비밀번호 규칙(길이/문자조합), 비밀번호 확인 일치, 약관 체크 등 엄격한 검증이 필요합니다.
• Zod로 규칙을 단일 소스로 명시 → 클라/서버 동일 로직 사용 → 규칙 일탈 방지.

1. 실시간 피드백 + 오류 메시지 관리

• RHF는 필드 단위 validate와 에러 상태를 효율적으로 관리 → 즉각적인 UX 제공.
• Zod 스키마에서 메시지를 정의해 다국어/일관된 에러 문구 운용이 쉬워요.

1. 성능과 DX

• RHF는 입력 하나 바뀌었다고 폼 전체를 리렌더하지 않음 → 가벼움.
• Zod 타입 추론으로 서버 액션/라우트 핸들러까지 타입이 이어져 개발자 경험(DX) 향상.

1. 중복/취약점 방지

• 서버에서도 같은 Zod 스키마로 재검증(신뢰 경계 바깥의 입력이므로 필수) → 우회/조작 방지.
• 스키마가 명세 역할을 하므로 팀 내 커뮤니케이션 및 유지보수에도 유리.

 

회원가입/로그인에 대해서는 사용하는 것이 좋다고 하여 공부하여 적용하였다. 그렇다면 자연스럽게 이런 질문이 떠올랐다.

Q. form에서는 Zod와 React Hook Form를 사용하는 것이 항상 좋은가?

아니다.

1. 복잡한 유효성 검사나 중첩된 객체가 없음

2. 간단한 폼에 무거운 라이브러리 적용은 불필요

 

 

그럼, 간단한 폼엔 굳이 안 써도 되나?

예. 다음 같은 경우는 생략해도 괜찮습니다.

• 입력 필드가 1–2개이고 규칙이 아주 단순: 예) 검색창, 간단한 필터 숫자 입력
• 브라우저 네이티브 검증으로 충분: required, min, max, type="email", pattern
• 폼 상태를 거의 보존/재사용하지 않고, 제출만 하면 되는 일회성 폼

이럴 땐 순수 <form> + 네이티브 속성 또는 짧은 커스텀 유효성 함수로 끝내는 게 더 단순하고 의존성도 줄어듭니다.

반대로 아래에 해당하면 RHF + Zod 추천:

• 인증/결제/프로필 편집처럼 오류가 곧 실패로 이어지는 민감한 폼
• 규칙이 많은 폼(조건부 필드, 의존 관계, 비밀번호 정책 등)
• 클라·서버 공통 스키마가 필요한 경우
• 성능과 에러 메시지 일관성이 중요한 경우