[스프링 MVC] 검증(2) - Bean Validation

스프링 MVC 2편의 강의 내용을 정리한 포스팅입니다.

---

Bean Validation이란

검증 애노테이션과 여러 인터페이스를 모은 기술 표준으로, 값의 비어있는 여부나 범위를 검증하는 것과 같이 일반적인 로직을 검증할 때 모든 프로젝트에 적용할 수 있게 공통화하고 표준화한 것이다.

해당 라이브러리를 사용하기 위해서는 build.gradle에 다음과 같이 의존관계를 추가해 주면 된다.

implementation 'org.springframework.boot:spring-boot-starter-validation'

검증 애노테이션은 다음과 같이 적용할 수 있다.
@NotBlank 빈 값인 경우 혹은 공백만 있는 경우를 허용하지 않는다.
@NotNull null을 허용하지 않는다.
@Range(min = 10, max = 100) 10에서 100 사이의 값만 허용한다.
@Max(100) 최대 100까지의 값만 허용한다.

스프링 적용

스프링 부트는 LocalValidatorFactoryBean을 글로벌 Validator로 등록하는데, 해당 검증기는 검증 애노테이션을 보고 검증을 수행한다. 글로벌 검증기가 적용되어 있기 때문에 검증 대상 객체에 @Valid 또는 @Validated만 적용하면 검증기가 실행된다.(@Valid는 자바 표준 검증 애노테이션, @Validated는 스프링 전용 검증 애노테이션으로 기능은 거의 일치하나 @Validated에는 group라는 기능이 있다.)
만약 검증 오류가 발생할 경우 FieldError, ObjectError를 생성해서 BindingResult에 담아준다.

이때 주의해야 할 점이 수동으로 글로벌 검증기를 등록할 경우 스프링 부트는 Bean Validator를 글로벌 검증기로 등록하지 않는다는 것이다. 이는 애노테이션 기반의 빈 검증기가 동작하지 않음을 의미한다. 따라서 수동으로 등록할 경우 이러한 점을 인지하고 있어야 한다.

검증 순서는 다음과 같다.
1. @ModelAttribute가 각각의 필드에 타입 변환(바인딩)을 시도하고, 성공 시 다음 단계로 넘어가지만 실패하면 typeMismatch로 FieldError를 추가한다.
2. Validator를 적용한다.
해당 과정에서 볼 수 있듯이 바인딩에 실패한 필드는 빈 검증기를 적용하지 않는데, 이는 적용의 의미가 없기 때문이다. 검증 조건을 비교하려면 우선 값이 정상적으로 할당되어야 하는데, 실패한 경우에는 검증의 의미가 없다.

에러 코드

Bean Validation을 적용하고 BindingResult에 등록된 검증 오류 코드는 MessageCodesResolver애 의해 생성된 것이기 때문에 해당 오류 코드를 기반으로 원하는 오류 메시지를 등록할 수 있다.

다음은 @NotBlank를 이용한 예시이다.

#오류 코드
NotBlank.item.itemName  
NotBlank.itemName  
NotBlank.java.lang.String  
NotBlank

#방법 1 - errors.properties에 Bean Validation 추가, {0}은 필드명
NotBlank={0} 공백은 입력할 수 없습니다.

//방법 2 - 애노테이션 내 message 속성 사용
@NotBlank(message = "공백은 입력할 수 없습니다.")
private String itemName;

정리하면 Bean Validation의 메시지를 찾는 순서는 다음과 같다.
1. 생성된 오류 코드 순서대로 messageSource에서 메시지 찾기
2. 애노테이션의 message 속성 사용
3. 라이브러리가 제공하는 기본 값 사용 (e.g. 공백일 수 없습니다.)

오브젝트 오류

Bean Validation에서 특정 필드(FieldError)가 아닌 오브젝트 관련 오류(ObjectError)를 처리하기 위한 애노테이션으로 @ScriptAssert()를 이용할 수 있지만, 제약이 많고 복잡하다는 단점이 존재한다.
따라서 오브젝트 오류의 경우 해당 부분만 직접 자바 코드로 작성하는 것이 권장된다.

@PostMapping("/add")
public String addItem(@Validated @ModelAttribute Item item, BindingResult bindingResult, RedirectAttributes redirectAttributes) {
     if (item.getPrice() != null && item.getQuantity() != null) {
         int resultPrice = item.getPrice() * item.getQuantity();
         if (resultPrice < 10000) { //특정 필드 예외가 아닌 전체 예외
             bindingResult.reject("totalPriceMin", new Object[]{10000, resultPrice}, null);
         }
     }
}

 

한계

같은 객체에 대해 다른 검증 조건을 적용할 경우 충돌이 발생한다.
예를 들어 Item 객체를 이용하여 상품을 등록할 때는 수량을 9999개까지만 허용하지만, 수정할 때는 수량을 무제한으로 받을 수 있도록 조건을 변경하고 싶다면? 또한 등록 시점에는 id 값이 존재하지 않지만 수정 시점에는 id 값이 필수인 점을 고려하면 충돌이 존재한다는 것을 알 수 있다.

@Data
public class Item {
    @NotBlank
    private String itemName;

    @NotNull
    @Range(min = 1000, max = 1000000)
    private Integer price;

    @NotNull
    @Max(value = 9999)
    private Integer quantity;
}

이러한 문제를 해결할 수 있는 방법은 크게 두 가지가 있다.

대안 1 - groups

Bean Validation은 groups라는 기능을 제공하는데, 해당 기능을 이용하면 등록 시 검증할 기능과 수정 시 검증할 기능을 각각 그룹으로 나누어 적용할 수 있다.

@Data
public class Item {
    @NotNull(groups = UpdateCheck.class)
    private Long id;

    @NotBlank(groups = {SaveCheck.class, UpdateCheck.class})
    private String itemName;

    @NotNull(groups = {SaveCheck.class, UpdateCheck.class})
    @Range(min = 1000, max = 1000000, groups = {SaveCheck.class, UpdateCheck.class})
    private Integer price;

    @NotNull(groups = {SaveCheck.class, UpdateCheck.class})
    @Max(value = 9999, groups = SaveCheck.class)
    private Integer quantity;
}

@PostMapping("/add")
public String addItem(
  @Validated(SaveCheck.class) @ModelAttribute Item item,
  BindingResult bindingResult,
  RedirectAttributes redirectAttributes) {
   //등록 로직 구현
}

 

대안 2 - Form 전송 객체 분리

두 번째 방법은 등록용 폼 객체와 수정용 폼 객체를 분리해서 사용하는 것이다.
첫 번째 방법을 잘 사용하지 않는 것은 객체의 불일치성 때문인데, 예를 들어 회원 등록 시에는 회원과 관련된 데이터뿐만 아니라 약관 정보 등 Item 객체와 관련 없는 수많은 부가 데이터가 넘어온다.
따라서 등록과 수정을 각각 처리하는 전용 객체를 @ModelAttribute로 사용해 컨트롤러에서 데이터를 전달받고, 필요한 데이터를 사용해 Item 객체를 생성하는 방법을 이용한다.

@Data
public class Item {
    private Long id;
    private String itemName;
    private Integer price;
    private Integer quantity;
}

@Data
public class ItemSaveForm {
    @NotBlank
    private String itemName;

    @NotNull
    @Range(min = 1000, max = 1000000)
    private Integer price;

    @NotNull
    @Max(value = 9999)
    private Integer quantity;
}

@Data
public class ItemUpdateForm {
    @NotNull
    private Long id;

    @NotBlank
    private String itemName;

    @NotNull
    @Range(min = 1000, max = 1000000)
    private Integer price;

    //수정에서는 수량 자유 변경 가능.
    private Integer quantity;
}

@PostMapping("/add")
public String addItem(@Validated @ModelAttribute("item") ItemSaveForm form, BindingResult bindingResult, RedirectAttributes redirectAttributes) {
    
    /**
    검증 로직
    **/
    
    Item item = new Item(); //검증 로직 통과 후 객체 생성
    item.setItemName(form.getItemName());
    item.setPrice(form.getPrice());
    item.setQuantity(form.getQuantity());
}

참고로 @ModelAttribute에서 "item"을 넣어주지 않으면 네이밍 규칙에 의해 itemSaveForm이라는 이름으로 MVC 모델에 담기게 된다.

HTTP 메시지 컨버터

@Valid, @Validated는 HttpMessageConverter(@RequestBody)에도 적용할 수 있다.
다만 @ModelAttribute와 차이점이 있다면 @ModelAttribute는 각각의 필드 단위로 세밀하게 적용되는 반면, @RequestBody는 전체 객체 단위로 적용된다는 것이다. 따라서 메시지 컨버터의 작동이 성공한 뒤 객체가 생성되어야 @Valid, @Validated가 적용될 수 있다.

API 요청 시 발생할 수 있는 경우의 수를 생각해 보자.
1. 성공 요청 - 성공
2. 실패 요청 - JSON을 객체로 변환하는 것 자체가 실패
3. 검증 오류 요청 - JSON을 객체로 변환하는 것은 성공했으나 검증에서 실패

3번의 경우 BeanValidation 단계에서 예외가 발생하지만, 2번의 경우 HttpMessageConverter 단계에서 예외가 발생하게 된다.
@ModelAttribute는 특정 필드가 바인딩되지 않아도 나머지 필드는 정상 바인딩 되고, 검증기를 이용해 검증 작업도 수행할 수 있지만 @RequestBody는 HttpMessageConverter 단계에서 JSON을 객체로 변환하지 못하면 이후 단계가 진행되지 않는다. 따라서 컨트롤러도, 검증기도 호출되지 않는다.