-
데이터 검증(Vallidation)을 어디에서 해야하는가프로젝트 생각 기록 2025. 2. 26. 20:23
상황 : User, Channel, Message 도메인을 가진 디스코드를 구현하는 프로젝트를 진행하던 중에 Message 생성 API에서 Channel 또는 User을 찾을 수 없을 때 404 에러 처리를 해야하는데, 문득 검증 로직은 어느 레이어 수준에서 작성되어야 할까 고민되어 찾아본 자료들입니다.
프로젝트 환경 : Java, SpringBoot, Gradle
Validation 코드는 어디에 작성해야 할까? - The 3 types of validation logics 파이썬 기반의 설명
T.I.L #43 검증 로직 어디에?
[Java] 사용자 입력의 검증과 분석은 어떤 계층에서 수행해야 할까Validation(입력값 검증)의 최적의 장소는 어디일까? Model 객체에서 입력값 검증을 해보자는 의견, Model 객체를 저는 엔티티로 해석했습니다.
Validation 책임과 범위는 어떻게 가져가야할까?Update 할 때 조건검사(price >= 0) 는 어디서 하는게 좋은 방법일까요?
위 문서들을 읽고 공통적으로 보인 의견을 세 가지로 정리했습니다.
첫 번째, "정답은 없다" 입니다. 각 레이어에 존재할 확고한 이유가 없는 이상말입니다. 팀원과 상의하여 배치한 그곳이 최선의 방법일 수 있다는 겁니다.
두 번째, "이론적으로 가장 안전한 방법은 있으나, 단점이 있다" 입니다.
클라이언트와 서버까지 넓혀서 보면 동일한 데이터 검증을 클라이언트, 서버에서 한 번 씩 수행하는 것은 이론적으로 가장 안전한 방법이지만, 리소스 소모가 커지고, 네트워크 트래픽과 응답 시간이 증가할 수 있습니다. 또한, 중복된 로직이 유지되므로 관리가 복잡해질 수 있습니다.
서버 안에서 검증을 한다해도, 모든 레이어에 검증을 두는 건 유사한 이유로 피하게 됩니다.
세 번째, "서버에서 데이터를 검증한다고 한다면, 일반적으로는…." 입니다.
우선 클라이언트와 서버 둘 중 어느쪽에서 검증을 맡아야 하느냐라고 한다면 서버입니다. 클라이언트는 사용자가 직접 조작할 수 있으므로 악의적 데이터 변경의 가능성 때문입니다.
CRS 패턴을 적용한다 했을 때, 일반적으로 아래와 같이 정리할 수 있었습니다.
컨트롤러(Contorller) : 입력 유효성 검증(= HTTP 요청 파라미터 검증), DTO 검증
서비스(Service) : 내부 DB 조회할 때, 외부 호출이 필요할 때 등 비즈니스 로직과 관련된 검증엔티티(Entity) : 엔티티가 가지고 있는 데이터로만 검증할 수 있다면 검증을 고려한다.
그리고! Message 생성시 Channel 또는 User을 찾을 수 없을 때를 검증해야 한다는 건, 내부 DB 조회를 거친 후 검증해야 하므로 서비스 레이어에서 검증했습니다.'프로젝트 생각 기록' 카테고리의 다른 글
서비스에서 다른 도메인의 레포지토리를 의존해도 되는가, 그리고 서비스 레이어 간 의존이 가능한가 (0) 2025.02.26 도메인 간 책임 분리와 확장성을 고려한 도메인 간의 참조 방향 설계 (0) 2025.02.26