어쩌다보니 유효성 검사에 대해 고민하게 되었다. 그 내용을 간략하게나마 정리해보고자 한다.
Validation check(유효성 검사)
프로그래밍을 하다보면 validation에 대해 고민하게 된다. 또한, 누가 혹은 어느 계층에서 이를 담당할 것인지 논의(싸움)하게 된다.
그만큼 중요한 작업이면서 동시에 귀찮고 머리아픈 일이다.
Web에서 유효성 검사
Web에서의 유효성은 Front-end와 Back-end 그리고 DB 입장에서 생각해볼 수 있을 것 같지만, 간략히 front-end와 back-end만 나누어 생각해보자
Front-end
사실 front-end 개발하는 입장에서 유효성 검사는 back-end가 해야하는 것 아닌가 싶을 수 있다. DB에서 unique해야 하는 부분들은 client에서 알 수 없으며, 중복 체크와 같은 API를 호출 해도 실제 create를 위한 post 요청을 보냈을 때 그 값이 유일함을 보장할 수도 없기에 front-end가 아닌 back-end가 담당해야 하는 일이라고 생각할 수 있다.
개인적인 생각으로는 front-end에서 생각해야 하는 유효성은 초점이 back-end와 다르다고 생각한다. POST 요청 후 그 결과를 사용자에게 보여줘도 되지만, 사용자 입장에서는 그리 친절한 응대가 아니라고 느껴진다. 회원 가입을 위해 많은 내용을 작성하고 확인 버튼을 눌렀을 때 email이 중복되어 있다던가, 비밀번호가 짧다는 등의 메세지를 받으면 기분 나쁘지 않겠나.
Front-end에서 유효성 검사를 신경써야 하는 이유는 사용자 경험 때문이다.
Back-end
Back-end 그리고 DB를 함께 생각해보면, back-end 개발자가 생각하는 것은 입력받은 데이터가 우리의 database에 insert 되어도 되는가? 일것이다. 하지만 잘못된 데이터는 DB 설계에서 제약조건을 잘 걸어두면 DBMS가 알아서 처리해주지 않냐고 생각할 수 있을 것 같다. 그럴 듯 하다 Back-end는 DB 뿐 아니라 보안 등 여러 문제를 생각해야 하기도 하지만, DBMS에게 유효성 검사를 위임하기에는 DBMS의 부담을 늘리고, 불필요한 DB connection이 늘어나는 문제도 있다고 생각한다.
DBMS의 제약조건이 필요없는 것은 아니지만, 직접 DB를 확인해야 하는 조건이 아니라면 서버의 성능을 고려하여 back-end에서 유효성 검사를 해야한다.
Back-end에서 유효성 검사를 수행하는 계층
사실 front, back 모두 유효성 검사를 해야한다는 것은 다들 아는 내용이겠지만 아는거랑 하는거랑은 다르다 사실 유효성 검사에 대한 글을 작성하게 된 이유는 Spring을 공부하던 중 validation check를 어느 계층에서 수행해야 하는지에 대한 고민으로 부터 시작됐다.
Spring을 하다보면 @Valid annotation을 통해서 request의 유효성을 검사하게 되는데, 이를 사용하지 않고 controller에서 유효성 검사를 위한 수많은 if 문을 작성하다가 고민이 시작되었다.
@RequestBody에 사용될 DTO에 @NotNull 등 annotation을 붙여 Spring Validator(이름 맞나..?)를 통한 유효성 검사를 수행한다고 했을 때.
1. @RequsetBody에 데이터를 binding할 때 유효성을 검사하고 controller 이전 단계에서 예외 처리
2. DTO 자체에 validate를 위한 메소드를 작성하고 이를 controller에서 호출
정도 생각을 하다가 DTO가 유효성 검사를 위한 로직을 갖는게 맞는걸까 생각이 들었고, 그 생각이 service인가 controller인가 repository(dao)인가 무튼 그렇게 길어지게 된 것이다.
결론부터 말하자면(내가 뭐라고 결론을 내는가 싶다)
각 계층 모두 유효성 검사는 수행해야 한다. 담당하는 영역이 다른 뿐이다.
Controller
Controller에서 검사해야 하는 부분은 not null, not empty, length 등 client의 request가 올바른 형태인지에 대한 부분이다.
회원 가입을 수행하는데 id가 없으면 안되지 않을까.
Service
Service에서 검사해야 하는 부분은 정보가 비즈니스 로직에 적합한지, 개념에 대한 부분이다.
동일하게 회원 가입을 예로 들었을 때, 시스템에서 사용자에게 부여되는 role이 admin, user 뿐인데 super user와 같은 값이 있으면 안되지 않을까
DAO? Repository? DB
뭐라고 불러야 할 지도 모르겠고, 어떻게 구분해야 할 지도 모르겠다. 우선 모두 엮어서 domain?이라고 부르겠다. Domain 계층에서 검사해야 하는 부분은 Data의 정합성이다. 동일한 id를 가진 user가 두 개 생성되면 안되지 않을까.
요약
멍청했다 유효성 검사를 back-end(Spring)에서 한번만 해야할 일으로 인식했다. Controller냐 DTO가 유효성 검사를 위한 로직을 가져도 되는가에 대한 답은 얻지 못했지만, 바보같은 생각을 하고 있었다는 것은 배울수 있었다. 아직도 공부할게 너무 많다
