[ 김영한 스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 #4 ] 검증1 - Validation (1)

이번 섹션에서는 [검증1 - Validation]에 대해서 알아보자.

👉 목차는 다음과 같다.

1) 검증 요구사항
2) 프로젝트 설정 V1
3) 검증 직접 처리 - 소개
4) 검증 직접 처리 - 개발
5) 프로젝트 준비 V2
6) BindingResult1
7) BindingResult2
8) FieldError, ObjectError
9) 오류 코드와 메시지 처리1
10) 오류 코드와 메시지 처리2
11) 오류 코드와 메시지 처리3
12) 오류 코드와 메시지 처리4
13) 오류 코드와 메시지 처리5
14) 오류 코드와 메시지 처리6
15) Validator 분리1
16) Validator 분리2
17) 정리

네 번째 섹션은 내용이 많으므로, 1) ~ 4), 5) ~ 8), 9) ~ 14), 15) ~ 17) 로 나눠서 포스팅하고자 한다.

검증에서는 목차에 대한 설명은 큰 의미가 없다.
바로 하나씩 확인해보자.

---

1) 검증 요구사항

이전까지 했던 상품 관리 시스템에 기획자의 새로운 요구사항이 추가되었다.

신규 요구사항: 검증 로직 추가

• 타입 검증
  • 가격, 수량에 문자가 들어가면 검증 오류 처리를 해주세요.
• 필드 검증
  • 상품명: 필수값 이어야 합니다. (공백 X)
  • 가격: 1000원 이상, 1백만원 이하여야 합니다.
  • 수량: 최대 9999개 까지만 가능합니다.
• 특정 필드의 범위를 넘어서는 검증
  • (가격 * 수량)의 합은 10,000원 이상이어야 합니다.

지금까지 만든 웹 애플리케이션은 폼 입력시 숫자를 문자로 작성하거나해서 검증 오류가 발생하면 오류 화면으로 바로 이동한다.

• 참고)
  

이렇게 되면 지금 우리가 만든 웹 서비스의 구조상, 사용자는 처음부터 해당 폼으로 다시 이동해서 입력을 해야 한다. 아마도 이런 서비스라면 사용자는 금방 떠나버릴 것이다. 웹 서비스는 폼 입력시 오류가 발생하면, 고객이 입력한 데이터를 유지한 상태로 어떤 오류가 발생했는지 친절하게 알려주어야 한다.

컨트롤러의 중요한 역할 중 하나는 HTTP 요청이 정상인지 검증하는 것이다. (그리고 정상 로직보다 이런 검증 로직을 잘 개발하는 것이 어쩌면 더 어려울 수 있다.)

 

✔️ 참고

• 클라이언트 검증과 서버 검증
  (검증은 크게 클라이언트에서 하는 검증과 서버에서 하는 검증이 있다. 클라이언트에서 하는 검증은 주로 자바스크립트 기반의 검증을 말하고, 서버에서 하는 검증은 HTTP 요청 데이터에 대해 서버에서 이뤄지는 뒷단의 검증을 말한다.)
  • 클라이언트만으로 검증하면, 조작할 수 있으므로 보안에 취약하다.
  • 서버만으로 검증하면, 즉각적인 고객 사용성이 부족해진다.
    • 아무래도 클라이언트에서 하는 자바스크립트 검증같은 경우, 고객의 입력이 일어날 때 마다 실시간으로 반응해줄 수 있기 때문에, 고객이 빠른 피드백을 받을 수 있다. 반대로 서버에서는 서버에 데이터를 보내봐야 이게 정상적인지 아닌지 알 수 있기때문에 즉각적인 고객 사용성이 조금 부족할 수 있다.
  • 따라서 둘을 적절히 섞어서 사용하되, 최종적으로 서버 검증은 필수이다.
  • 만약, API 방식을 사용하면 API 스펙을 잘 정의해서 검증 오류를 API 응답 결과에 잘 남겨주어야 한다.

먼저 검증을 직접 구현해보고, 이후 뒤에서 스프링과 타임리프가 제공하는 검증 기능을 활용해보자.

---

2) 프로젝트 설정 V1

이전 프로젝트에 이어서 검증 (Validation) 기능을 학습해보자.
이전 프로젝트를 일부 수정해서 validation-start 라는 프로젝트에 넣어두었다. (패키지 구조, URL 등만 약간 수정하였다.)

프로젝트 설정 순서

• validation-start 의 폴더 이름을 validation 로 변경하자.

• 프로젝트 임포트
  • File -> Open -> 해당 프로젝트의 build.gradle 을 선택하자. 그 다음에 선택창이 뜨는데, Open as Project 를 선택하자.
• ItemServiceApplication.main() 을 실행해서 프로젝트가 정상 수행되는지 확인하자.
  

• 정상적으로 실행됨을 확인할 수 있다. (화면을 보면, 검증 v1 ~ v4까지 있는데, 점진적으로 검증을 개선해볼 것이다.)

---

3) 검증 직접 처리 - 소개

이제 검증을 한 번 직접 처리해보자.
먼저 상품 저장에 성공하는 시나리오와 실패하는 시나리오에 대해서 확인해보자.

• 상품 저장 성공
  
  • 사용자가 상품 등록 폼에서 정상 범위의 데이터를 입력하면, 서버에서는 검증 로직이 통과하고, 상품을 저장하고, 상품 상세 화면으로 redirect한다. ( PRG )

• 상품 저장 검증 실패
  
  • 고객이 상품 등록 폼에서 상품명을 입력하지 않거나, 가격, 수량등이 너무 작거나 커서 검증 범위를 넘어서면, 서버 검증 로직이 실패해야 한다. 이렇게 검증에 실패한 경우, 고객에게 다시 상품 등록 폼을 보여주고, 어떤 값을 잘못 입력했는지 친절하게 알려주어야 한다.

이제 요구사항에 맞추어 검증 로직을 직접 개발해보자.

---

4) 검증 직접 처리 - 개발

상품 등록 검증

먼저, 상품 등록시 검증 코드를 작성해보자.

👉 코드로 확인해보자.

• ValidationItemControllerV1 - addItem: (참고) 기존 로직은 다음과 같다.
  

• 위 로직에서 실제 상품을 저장하기 전에, 사용자의 입력 데이터가 정상적인지 검증 로직을 먼저 수행해야 한다.
  
  • 위 노란 영역에 검증로직이 추가되어야 한다.

• ValidationItemControllerV1 - addItem: 노란 영역에 검증 로직을 추가해보자.
  
  • (참고) 검증 오류 결과 정보를 화면에 전달하기 위해, 컨트롤러 파라미터에 Model model을 추가하였다.
  • (참고) 로그 출력을 위해 클래스에 @Slf4j 애노테이션을 추가하였다.
  • 위와 같이 검증로직을 작성 후 실행해보자.

• 실행해보자.
  
  • 위와 같이 작성 후 저장을 클릭하면, 검증로직에서 실패되어, 저장되지 않고 다시 해당 입력 폼으로 돌아오게 된다.
  • 위 입력 폼에서는 크게 2개의 검증에서 실패된다.
    • 상품명을 입력하지 않았다.
    • 가격 * 수량의 합이 5,000원으로, 10,000원 이상이 아니다.

• 로그를 확인해보자.
  • 정상적으로 errors에 검증 실패 정보가 담긴 것을 확인할 수 있다.

✔️ 추가한 검증 로직들을 하나씩 살펴보자.

• 검증 오류 보관
  
  • 만약 검증시 오류가 발생하면 어떤 검증에서 오류가 발생했는지 정보를 담아둔다.

• 검증 로직
  
  • (참고) import org.springframework.util.StringUtils; 추가 필요
  • 검증시 오류가 발생하면 errors 에 담아둔다. 이때 어떤 필드에서 오류가 발생했는지 구분하기 위해 오류가 발생한 필드명을 key 로 사용한다. 이후 뷰에서 이 데이터를 사용해서 고객에게 친절한 오류 메시지를 출력할 수 있다.

• 특정 필드의 범위를 넘어서는 검증 로직
  
  • 특정 필드를 넘어서는 오류를 처리해야 할 수도 있다. 이때는 필드 이름을 넣을 수 없으므로 globalError 라는 key 를 사용한다.

• 검증에 실패하면 다시 입력 폼으로
  
  • 만약 검증에서 오류 메시지가 하나라도 있으면 오류 메시지를 출력하기 위해 model 에 errors 를 담고, 입력 폼이 있는 뷰 템플릿으로 보낸다.

 

👉 이제 화면을 수정해보자.

addForm.html: 아래와 같이 수정하자.

• css 추가: 오류 메시지 노출 시 디자인 적용을 위해, 다음 코드를 추가하자.
  
  • 오류 메시지를 빨간색으로 강조하기 위해 추가하였다.

• 글로벌 오류 메시지 처리: 먼저, 특정 필드가 아닌 복합 룰 검증에 실패한 글로벌 오류(globalError) 메시지를 처리해보자.
  
  • 오류 메시지는 errors 에 내용이 있을 때만 출력하면 된다. 타임리프의 th:if 를 사용하면 조건에 만족할 때만 해당 HTML 태그를 출력할 수 있다.

• 실행해보자.
  
  • 다음과 같이 복합 룰 검증에 실패하여, 다시 입력 폼 페이지로 이동되었고, 검증 오류 메시지가 정상적으로 노출됨을 확인할 수 있다.

✔️ Safe Navigation Operator

• 만약 위에서 errors 자체가 null 이라면 어떻게 될까?
  • 생각해보면 상품 등록 폼에 최초 진입한 시점에는 errors 가 없다.
  • 따라서, errors.containsKey() 를 호출하는 순간 NullPointerException 이 발생한다.
  • errors?. 은 errors 가 null 일때 NullPointerException 이 발생하는 대신, null 을 반환하는 문법이다.
    • th:if 에서 null 은 실패로 처리되므로 오류 메시지가 출력되지 않는다.
    • 이것은 스프링의 SpringEL이 제공하는 문법이다. 자세한 내용은 다음을 참고하자.
      • https://docs.spring.io/spring-framework/reference/core/expressions/language-ref/operator-safe-navigation.html

 

👉 이제 필드 검증에 실패한 경우에 대해서 화면을 적용해보자.

• 필드 오류 메시지 처리 - 상품명: 아래와 같이 적용하자.
  
  • 상품명에 검증 오류가 있는 경우, 텍스트 박스에 스타일을 적용한다.
    • classappend 를 사용해서 해당 필드에 오류가 있으면 field-error 라는 클래스 정보를 더해서 폼의 색깔을 빨간색으로 강조한다. 만약 값이 없으면 _ (No-Operation)을 사용해서 아무것도 하지 않는다. (따라서 그 경우 th:classappend 부분은 무시된다.)
  • 상품명에 검증 오류가 있는 경우, 텍스트 박스 아래 오류 메시지를 적용한다.

• 필드 오류 메시지 처리 - 가격: 아래와 같이 적용하자.
  
  • 위 상품명에 적용했던 것과 동일하다.

• 필드 오류 메시지 처리 - 수량: 아래와 같이 적용하자.
  
  • 위 상품명에 적용했던 것과 동일하다.

• 실행해보자.
  
  • 정상적으로 검증 오류 메시지가 노출됨을 확인할 수 있다.
  • 정상적으로 값을 입력한 경우에도, 잘 저장됨을 확인할 수 있다.
    

 

✔️ 참고

• 이번 내용에서는 상품 등록시에만 검증을 추가해보았다. 상품 수정의 검증은 더 효율적인 검증 처리 방법을 학습한 다음에 진행한다.

✔️ 지금까지 했던 내용을 정리해보자.

• 만약 검증 오류가 발생하면 (입력 데이터를 유지한 상태로) 입력 폼을 다시 보여준다.
• 검증 오류들을 고객에게 친절하게 안내해서 다시 입력할 수 있게 한다.
• 검증 오류가 발생해도 고객이 입력한 데이터가 유지된다.

✔️ 그런데 아직 남은 문제점이 많다.

• 뷰 템플릿에서 중복 처리가 많다. 뭔가 비슷하다.
• 타입 오류 처리가 안된다. Item 의 price , quantity 같은 숫자 필드는 타입이 Integer 이므로 문자 타입으로 설정하는 것이 불가능하다. 숫자 타입에 문자가 들어오면 오류가 발생한다. 그런데 이러한 오류는 스프링 MVC에서 컨트롤러에 진입하기도 전에 예외가 발생하기 때문에, 컨트롤러가 호출되지도 않고, 400 예외가 발생하면서 오류 페이지를 띄워준다.
  
• Item 의 price 에 문자를 입력하는 것 처럼 타입 오류가 발생해도 고객이 입력한 문자를 화면에 남겨야 한다. 만약 컨트롤러가 호출된다고 가정해도 Item 의 price 는 Integer 이므로 문자를 보관할 수가 없다. 결국 문자는 바인딩이 불가능하므로 고객이 입력한 문자가 사라지게 되고, 고객은 본인이 어떤 내용을 입력해서 오류가 발생했는지 이해하기 어렵다. (문자를 저장할 수 있는 방법이 없기 때문에, 뭔가 다른 매커니즘이 필요하다..!)
• 결국 고객이 입력한 값도 어딘가에 별도로 관리가 되어야 한다.

지금부터 스프링이 제공하는 검증 방법을 하나씩 알아보자.

---

강의를 듣고 정리한 글입니다. 코드와 그림 등의 출처는 김영한 강사님께 있습니다.