같은 데이터를 여러 곳에서 확인하는 이유는 중복이 아니라 역할 분담입니다. 프론트엔드와 서버는 먼저 설명하고, DB 제약 조건은 끝에서 저장 자체를 거부합니다.
애플리케이션 검증은 필요하지만 대체재가 아닙니다.
무결성은 결국 DB 안에서 강제되어야 모든 경로의 쓰기가 같은 기준을 따릅니다.
| 검증 위치 | 무엇을 먼저 잡나 | 이것만으로 부족한 이유 | 맡겨야 할 책임 |
|---|---|---|---|
|
입력 직후
프론트엔드
|
잘하는 검증
필수값 누락, 형식 오류, 즉시 수정 가능한 입력 실수를 빠르게 보여 줍니다. |
남는 틈
요청 변조, 다른 클라이언트, 자동화 스크립트로 쉽게 우회될 수 있습니다. |
적절한 역할
사용자 경험 개선과 빠른 1차 피드백을 맡깁니다. |
|
요청 처리 중
애플리케이션 서버
|
잘하는 검증
업무 규칙, 컬럼 간 조합 조건, 친절한 오류 메시지를 도메인 문맥으로 설명합니다. |
남는 틈
배치 작업, 다른 서비스, 직접 DB 접근처럼 서버를 거치지 않는 경로는 막지 못합니다. |
적절한 역할
비즈니스 규칙 해석과 일관된 응답 정책을 맡깁니다. |
|
저장 직전
DB 제약 조건
|
잘하는 검증
PRIMARY KEY, FOREIGN KEY, CHECK 같은 규칙으로 잘못된 상태의 저장을 직접 거부합니다. |
주의할 점
오류 설명은 서버보다 거칠 수 있으므로, 사용자 안내는 위 계층에서 보완하는 편이 좋습니다. |
필수 책임
최종 무결성 보장. 어떤 경로의 쓰기라도 같은 제약을 통과해야만 저장됩니다. |
애플리케이션은 먼저 걸러 주고 설명하고, 데이터베이스는 마지막에 반드시 막습니다. 둘 다 필요하지만, 무결성의 최종 책임은 DB에 둬야 합니다.