폼이나 데이터 변경에 대한 유효성 검증을 할 때, 클라이언트단 검증만 믿어서는 안 된다. 서버단의 유효성 검증은 단순한 클라이언트 입력 형식 검사보다는 더 넓고, 더 신뢰할 수 있는 서버 관점의 검증에 가깝다.
클라이언트단 검증은 보통 사용성 목적이다. 예를 들어, 이메일 형식이 맞는지, 비밀번호가 8자 이상인지, 필수 입력값이 비어 있지 않은지 같은 것들이다. 이런 검증은 사용자가 즉시 피드백을 받게 해주기 때문에 UX에는 좋지만, 직접 HTTP 요청을 보내는 방식으로 우회할 수 있다. 그래서 이는 보안이나 데이터 무결성의 최종 기준이 되면 안 된다.
서버단의 검증은 '이 요청이 정말 유효한가?'를 봐야한다. 예를 들어 제목이 비어 있지 않은지만 보는 게 아니라, 현재 로그인한 사용자가 이 글을 수정할 권한이 있는지, 이미 같은 이메일로 가입된 사용자가 있는지, 가격이 음수가 아닌지, 수량이 실제 재고보다 많은지, 사용자가 보낸 userId를 그대로 믿지 않고 세션의 사용자 정보와 일치하는지 같은 것을 확인하는 것이다. 이런 검증은 클라이언트에서는 제대로 할 수 없거나, 하더라도 신뢰할 수 없다.
서버단에서의 검증은 두 단계의 층위가 있다. 첫 번째로, zod 같은 라이브러리를 사용하여 문자열 길이와 형식을 검증하는 것도 서버 검증의 일부지만, 실무에서 더 중요한 건 비즈니스 규칙 검증 단계이다. 예를 들어
존재하지 않는 게시글에는 댓글을 달 수 없다.
삭제된 게시글에는 댓글을 달 수 없다.
이미 가입된 이메일은 가입할 수 없다.
결제 금액이 서버 계산값과 일치해야 한다.
Next.js의 서버 액션을 활용해서 서버단 검증을 추가할 수 있다. 만약, 만들어진 API가 비즈니스 규칙 검증이 되어 있다면, 서버 액션에는 도메인 규칙을 다시 구현하는 역할 보다는, UI와 백엔드 API 사이를 연결하는 얇은 서버 경계층 역할로 사용하면 된다.
즉, 핵심 비즈니스 규칙을 이미 API가 책임지고 있다면, 서버 액션은 요청을 받기 좋은 형태로 정리하고, UI가 기대하는 후처리를 담당하면 된다.