Spring 숙련 Chapter 1 - 요청 데이터 검증

About this offer

14 · Validation 💡 한 줄 요약 : DTO에 데이터 조건을 선언하고 @Valid 로 요청값을 검증합니다. 왜 입력값을 검증할까? 필요한 값이 누락된 요청을 처리 전에 발견합니다. 잘못된 길이·형식·수치 범위의 데이터를 막습니다. 여러 곳에서 반복하는 단순 검증을 DTO 조건으로 표현합니다. 클라이언트 검증만으로 서버 데이터의 정확성을 보장할 수 없으므로 서버에서도 확인합니다. 주요 애너테이션 애너테이션 검증하는 조건 @NotNull null이 아님 @NotEmpty null이 아니며 비어 있지 않음 @NotBlank 문자열이 null·빈 문자열·공백 문자열이 아님 @Size 문자열·컬렉션 등의 크기 범위 @Min , @Max 수치의 최소·최대 범위 @Positive , @Negative 양수·음수 @Email 이메일 형식 @Pattern 정규 표현식 일치 NotNull·NotEmpty·NotBlank 비교 입력 @NotNull @NotEmpty @NotBlank null 실패 실패 실패 "" 통과 실패 실패 " " 통과 통과 실패 "hello" 통과 통과 통과 DTO에 조건 선언 @Getter @Setter public class SignupRequestDto { @NotBlank(message = "아이디는 필수입니다.") private String username; @NotBlank(message = "비밀번호는 필수입니다.") private String password; @NotBlank(message = "이메일은 필수입니다.") @Email(message = "이메일 형식이 올바르지 않습니다.") private String email; } @Email , @Pattern , @Size 같은 조건만으로 필수 입력까지 항상 보장되는 것은 아닙니다. 값의 필수 여부는 적절한 조건과 조합합니다. 검증 실행 implementation 'org.springframework.boot:spring-boot-starter-validation' @PostMapping("/api/users") public ResponseEntity<Void> signup(@RequestBody @Valid SignupRequestDto dto) { userService.signup(dto); return ResponseEntity.status(201).build(); } Bean Validation과 서비스 검증 구분 검증할 내용 위치 입력 형식 공백·길이·이메일 형식 DTO 제약조건 비즈니스 규칙 이메일 중복·가입 가능 여부 Service 데이터 무결성 Unique·Not Null 등 DB 제약조건 DTO에서 이메일 형식이 정상이어도 이미 가입된 이메일인지는 DB 조회로 확인해야 합니다. 복습 체크 공백 문자열을 차단할 조건을 선택할 수 있습니다. DTO에 조건을 선언한 뒤 @Valid 로 검증을 실행할 수 있습니다. 입력 형식 검증·비즈니스 검증·DB 제약조건을 구분할 수 있습니다. 15 · Validation 예외처리 💡 한 줄 요약 : 검증 결과를 확인해 잘못된 요청에서는 가입 처리를 중단하고 오류를 안내합니다. 검증 실패 후 처리 흐름 요청 데이터를 DTO로 받습니다. @Valid 가 제약조건을 검사합니다. 오류가 있으면 필드별 오류 정보를 확인합니다. 정상 데이터일 때만 Service를 호출합니다. 오류가 있으면 회원가입 화면 또는 오류 응답을 반환합니다. BindingResult로 결과 받기 @PostMapping("/api/user/signup") public String signup(@Valid @ModelAttribute SignupRequestDto dto, BindingResult bindingResult) { if (bindingResult.hasErrors()) { return "signup"; } userService.signup(dto); return "redirect:/api/user/login-page"; } BindingResult 는 검증 대상 바로 다음 매개변수에 둡니다. hasErrors() 로 오류 여부를 확인합니다. 오류가 있을 때 Service를 실행하지 않도록 분기합니다. 정상 가입일 때만 로그인 화면으로 이동합니다. 필드별 오류 확인 for (FieldError error : bindingResult.getFieldErrors()) { String field = error.getField(); String message = error.getDefaultMessage(); log.info("검증 실패: {} - {}", field, message); } 비밀번호 등 입력한 원문을 로그에 남기지 않고, 필드명·오류 메시지 중심으로 확인합니다. 화면 반환과 redirect 차이 처리 의미 검증 오류와의 관계 return "signup" 현재 요청에서 템플릿 렌더링 현재 바인딩·검증 정보를 활용 가능 return "redirect:/..." 브라우저가 새 요청 전송 오류·입력값 전달을 별도로 구성해야 함 검증 실패 후 화면으로 돌아갔다고 해서 오류 문구가 자동으로 눈에 보이는 것은 아닙니다. 템플릿에서 해당 필드의 오류를 표시하도록 연결합니다. JSON API라면? 화면 이동 대신 클라이언트가 해석할 수 있는 오류 상태·필드별 메시지를 반환합니다. @RequestBody @Valid 검증 실패는 예외 처리 흐름으로 연결할 수 있으며, 폼의 화면 반환 방식과 구분합니다. { "message": "입력값을 확인해 주세요.", "errors": { "email": "이메일 형식이 올바르지 않습니다." } } 복습 체크 BindingResult의 위치와 역할을 설명할 수 있습니다. 오류가 있으면 회원 저장을 실행하지 않도록 처리할 수 있습니다. 템플릿 반환과 redirect의 차이를 설명할 수 있습니다. 화면용 오류 처리와 JSON API용 오류 처리를 구분할 수 있습니다.