토리의 기록실

레벨2 소프트 스킬 강의 후기 - 회복 탄력성 : 흔들려도 무너지지 않는 힘

토리8 — Sun, 31 May 2026 16:32:29 +0900

자아존중감 - 나는 나에게 얼마나 관대했나?

강의에서 자아존중감을 이렇게 정의했다.

"자신이 사랑받을 만한 가치가 있는 존재임을 인정하고 존중하는 마음"

이 정의를 듣고 나서 돌아봤다. 지금까지 우테코를 다니면서 미션이 끝난 후, 혹은 레벨이 끝난 후에 나 자신에게 "잘했다"고 말한 적이 단 한 번이라도 있었나?

없었다.

항상 다른 크루들과 비교하면서 내가 부족한 부분만 눈에 들어왔다. 그 부족함을 채워야 한다는 열망으로 스스로를 채찍질했다. 그게 성장 의지라고 생각했는데, 돌아보면 나 자신을 한 번도 인정해준 적 없이 몰아붙이기만 했던 것 같다.

감정을 무시하는 것이 습관이 되어 있었다

강의에서 이런 말이 나왔다.

"감정을 무시하고 밝게 지내는 것은 회복이 아닌 회피입니다. 감정을 인식하고 흘려보내는 것이 회복의 첫걸음입니다."

최근에 나는 감정을 인식하고 있었나? 솔직히 모르겠다. 무시하는 게 습관이 되어서인지, 어떤 감정이 드는지 생각조차 잘 안 했던 것 같다.

열등감도 그랬다. 다른 크루들 대화에서 소외감을 느낄 때, 페어 프로그래밍에서 내 의견을 숨길 때, 그 감정들을 그냥 흘려보내거나 억누르는 게 익숙했다. 인식하는 것 자체를 하지 않았으니 흘려보낼 수도 없었던 거다.

회복탄력성은 실패 직후에 측정된다

강의에서 가장 인상 깊었던 말이다.

"회복탄력성은 평소에 측정하면 측정이 안된다. 실패 경험 직후에 측정했을 때 측정이 잘된다."

"얼마나 빨리 일어나는가가 아니라, 어떻게 일어서는지를 아는 사람이 되는 것이다."

이 말이 레벨2 미션을 진행하면서 와닿았다. 한 미션에서는 페어와 함께 결정 사유를 문서로 남기고, 방향이 달라도 끝까지 짚고 넘어가면서 진행했다. 미션이 끝났을 때 처음으로 "이번엔 진심으로 임했다"는 느낌이 들었다.

반대로 어떤 미션에서는 빠른 PR을 위해 대충 협의하고 넘어갔다. 결과물은 비슷했을지 몰라도, 미션이 끝난 후 찜찜함이 남았다. 결과가 아니라 과정에서 내가 어떻게 임했느냐가 나한테는 중요한 것 같다.

대인관계 - 나를 숨기지 않는 것

회복탄력성의 핵심 요소 중 대인관계가 있었다. 공감력, 소통력, 자아확장력.

솔직히 페어 프로그래밍에서 나는 나를 많이 숨겼다. 모르는 게 있어도 대충 넘어가고, 내 의견이 틀릴까봐 확신이 없으면 말을 아꼈다. 상대방이 나를 "부족한 사람"으로 볼까봐 두려웠던 거다.

근데 돌아보면, 페어가 "나도 잘 모른다"고 먼저 말해줬을 때 오히려 내가 주도적으로 할 수 있었고, 그게 제일 좋은 협업이었다. 내가 먼저 그 역할을 할 수도 있다는 걸 이제는 알것 같다.

마치며

이 강의를 듣기 전까지 나는 자아존중감을 제대로 들여다본 적이 없었다. 그냥 나는 열등감이 많은 사람이라고 치부하고 넘겼다.

근데 강의를 들으면서, 그리고 스스로를 돌아보면서 조금 달리 보이기 시작했다. 자존감이 없는 게 아니라, 나 자신한테만 유독 가혹한 기준을 들이대고 있었던 것 같다. 남이 모른다고 하면 괜찮은데, 내가 모른다고 하면 안 된다고 느끼는 것처럼.

흔들려도 무너지지 않는 힘은 빠르게 일어나는 게 아니라고 했다. 어떻게 일어서는지 아는 것이라고. 나는 아직 배워가는 중이지만, 적어도 지금은 내가 어떨 때 잘 되는지는 알 것 같다.

그걸로 충분한 시작이라고 생각한다. 이제부터는 결과보다 과정에 집중하고, 진심으로 임한 나 자신을 칭찬하는 것부터 시작해보려 한다.

MethodArgumentNotValidException 발생 조건부터 핸들링까지

토리8 — Sat, 30 May 2026 20:16:54 +0900

방탈출 사용자 예약 미션에서 요청 DTO 검증과 전역 예외 처리를 구현하며 MethodArgumentNotValidException을 @ExceptionHandler로 처리한 경험이 있다. 당시에는 이 예외가 왜 발생하는지, 내부적으로 어떻게 동작하는지 제대로 이해하지 못한 채 구현에 임했다. 미션이 끝난 지금, 동작 원리를 제대로 정리해두고자 한다.

`MethodArgumentNotValidException`이란 무엇인가?

BindException to be thrown when validation on an argument annotated with @Valid fails. Spring Docs - MethodArgumentNotValidException

@Valid가 붙은 파라미터의 Bean Validation 검증이 실패했을 때 Spring이 던지는 예외다. BindException을 상속하기 때문에, 검증에 실패한 모든 오류 정보를 BindingResult를 통해 꺼낼 수 있다.

BindingResult에는 두 종류의 에러가 담긴다.

FieldError: 특정 필드에서 발생한 검증 실패 (예: name이 비어있음)
ObjectError: 객체 전체 수준의 검증 실패 (Cross-field validation)

즉, MethodArgumentNotValidException은 @Valid 검증 실패 시 발생하며, 어떤 필드가 왜 실패했는지 상세 정보를 담고 있는 예외다.

`MethodArgumentNotValidException` 예외는 언제 발생할까?

MethodArgumentNotValidException은 @RequestBody 파라미터에 @Valid가 선언된 상태에서 Bean Validation 검증이 실패했을 때 발생한다.

내부적으로는 RequestResponseBodyMethodProcessor의 resolveArgument()에서 다음 순서로 동작한다.

Object arg = readWithMessageConverters(...)             // 1. JSON → Java 객체 변환
WebDataBinder binder = binderFactory.createBinder(...) // 2. DataBinder 생성
validateIfApplicable(binder, parameter)                // 3. Validator에게 검증 위임

if (binder.getBindingResult().hasErrors()
        && isBindExceptionRequired(binder, parameter)) {
    throw new MethodArgumentNotValidException(...)     // 4. 에러 있으면 예외 던짐
}

HttpMessageConverter를 통해 JSON을 Java 객체로 변환
DataBinder를 생성하고 validateIfApplicable()로 Validator에게 검증 위임
검증 완료 후 아래 두 조건을 동시에 확인
- binder.getBindingResult().hasErrors() → 검증 실패 에러가 존재하는가
- isBindExceptionRequired() → 컨트롤러 메서드 파라미터에 BindingResult가 없는가
두 조건이 모두 참이면 MethodArgumentNotValidException을 던짐
- 둘 중 하나라도 거짓이면 예외를 던지지 않음

주목할 조건은 isBindExceptionRequired()다. 컨트롤러 메서드 파라미터 목록에 Errors 또는 BindingResult가 함께 선언되어 있으면 false를 반환한다. 이 경우 예외를 던지지 않고, 검증 실패 정보를 메서드가 직접 받아 처리할 수 있도록 넘긴다.

즉, MethodArgumentNotValidException은 검증 실패 결과를 메서드가 직접 받지 않는 경우에만 발생하며, 예외를 던지는 주체는 Spring MVC의 RequestResponseBodyMethodProcessor다.

`MethodArgumentNotValidException` 발생했을 때 어떻게 적절한 에러 응답을 반환하는가?

MethodArgumentNotValidException은 두 가지 방식으로 처리할 수 있다.

1. 전역 처리 — @RestControllerAdvice

애플리케이션 전체에서 발생하는 MethodArgumentNotValidException을 한 곳에서 처리한다.

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<ErrorResponse> handle(MethodArgumentNotValidException e,
                                                HttpServletRequest request) {
        List<FieldErrorResponse> fieldErrors = e.getBindingResult().getFieldErrors().stream()
                .map(fe -> new FieldErrorResponse(fe.getField(), fe.getDefaultMessage()))
                .toList();
        ErrorResponse errorResponse = new ErrorResponse(
                "INVALID_CONSTRAINT", request.getRequestURI(), "요청 값이 유효하지 않습니다.", fieldErrors
        );
        return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(errorResponse);
    }
}

getFieldErrors()로 꺼낸 FieldError에서 getField()(실패한 필드명)와 getDefaultMessage()(제약 조건에 선언한 메시지)를 사용해 에러 응답을 구성한다.

위 핸들러가 반환하는 에러 응답은 다음과 같다.

{
  "code": "INVALID_CONSTRAINT",
  "path": "/reservations",
  "message": "요청 값이 유효하지 않습니다.",
  "fieldErrors": [
    {
      "field": "name",
      "message": "이름은 필수입니다."
    },
    {
      "field": "date",
      "message": "날짜는 필수입니다."
    }
  ]
}

2. 로컬 처리 — 컨트롤러 내 @ExceptionHandler

특정 컨트롤러에서만 다르게 처리하고 싶을 때 사용한다.

@RestController
public class ReservationController {

    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<ErrorResponse> handle(MethodArgumentNotValidException e) {
        // 이 컨트롤러에서만 적용되는 처리
    }
}

즉, MethodArgumentNotValidException 처리의 핵심은 e.getBindingResult().getFieldErrors()로 실패한 필드 목록을 꺼내 클라이언트에게 어떤 필드가 왜 잘못됐는지 구체적으로 전달하는 것이라고 생각한다.

`ResponseEntityExceptionHandler`를 통해서 핸들링하는 방식

`ResponseEntityExceptionHandler`란?

A class with an @ExceptionHandler method that handles all Spring MVC raised exceptions by returning a ResponseEntity with RFC 9457 formatted error details in the body.

Spring MVC가 기본으로 제공하는 추상 클래스로, MethodArgumentNotValidException을 포함한 스프링 내부 표준 예외들을 처리하는 @ExceptionHandler 메서드들이 미리 구현되어 있다.

왜 쓰는가? 직접 `@ExceptionHandler` 작성 방식과의 차이

직접 작성 방식은 @ExceptionHandler(MethodArgumentNotValidException.class)를 선언하고 처리 로직을 처음부터 구현해야 한다. 반면 ResponseEntityExceptionHandler를 상속하면, 이미 등록된 핸들러 메서드를 오버라이드하는 방식으로 응답 형식만 바꿀 수 있다.

또한 MethodArgumentNotValidException 하나만이 아니라 Spring이 내부적으로 발생시키는 수십 개의 표준 예외들을 일관된 구조로 처리할 수 있다는 장점이 있다.

어떻게 쓰는가 (상속 + 오버라이드)

@RestControllerAdvice
public class GlobalExceptionHandler extends ResponseEntityExceptionHandler {

    @Override
    protected ResponseEntity<Object> handleMethodArgumentNotValid(
            MethodArgumentNotValidException ex,
            HttpHeaders headers,
            HttpStatusCode status,
            WebRequest request) {

        List<FieldErrorResponse> fieldErrors = ex.getBindingResult().getFieldErrors().stream()
                .map(fe -> new FieldErrorResponse(fe.getField(), fe.getDefaultMessage()))
                .toList();

        ErrorResponse errorResponse = new ErrorResponse(
                "INVALID_CONSTRAINT", "요청 값이 유효하지 않습니다.", fieldErrors
        );

        return ResponseEntity.status(status).body(errorResponse);
    }
}

직접 작성 방식과 비교했을 때 두 가지 차이가 눈에 띈다.

HttpStatus.BAD_REQUEST를 하드코딩하지 않고, 파라미터로 넘어온 status를 그대로 사용한다.
HttpServletRequest 대신 WebRequest를 사용한다.

즉, ResponseEntityExceptionHandler는 응답 형식만 커스터마이징하고 예외 등록은 Spring에 위임하는 방식으로, 표준 예외를 일관되게 처리할 때 유리하다.

자료 조사하면서 더 알아볼 키워드

BindingResult
FieldError
HttpMessageConverter
MappingJackson2HttpMessageConverter

@Valid vs @Validate 차이는 무엇인가?

토리8 — Sun, 24 May 2026 21:28:13 +0900

우테코 미션을 진행하면서 Spring Validation에 대해서 학습하면서 @Valid와 @Validated에 대해서 알게 되었는데 이를 상황에 맞게 선택하기 위해, 두 애노테이션이 동작하는 메커니즘의 차이를 정리하고자 한다.

@Valid이란 무엇인가?

@Valid는 JSR 표준 애노테이션으로, @Constraint 애노테이션이 선언된 DTO를 검증할 때 사용한다. ArgumentResolver가 객체를 바인딩한 뒤, Validator가 @Valid를 트리거로 삼아 객체 내부의 제약 조건들을 검증하는 방식이다.

@Validated이란 무엇인가?

@Validated는 Spring이 추가한 애노테이션으로, 클래스 위에 선언한다. @RequestParam, @PathVariable 같은 단순 파라미터에도 @NotNull 등의 제약 조건을 적용할 수 있다.

내부적으로 Spring AOP를 활용한다. 프록시 객체가 해당 메서드를 가로채어, 메서드가 실행되기 전에 파라미터를 검증하는 방식이다.

@Valid 하나만으로도 문제없는 거 아냐? / 왜 굳이 @Validated를 쓰는 걸까?

요청 DTO 검증 — @Valid로 충분하다

@PostMapping  
public ResponseEntity<ReservationResponse> register(@Valid @RequestBody ReservationRequest reservationRequest) {  
    ReservationResponse reservationResponse = reservationService.register(reservationRequest);  
    return ResponseEntity.created(URI.create("/reservations/" + reservationResponse.id()))  
            .body(reservationResponse);  
}

DTO처럼 객체가 매개변수로 들어오는 경우에는 @Valid만으로 충분하다. ArgumentResolver가 객체를 바인딩한 직후 Validator가 내부 필드를 검증하기 때문이다.

단순 파라미터 검증 — @Valid로는 불가능하다

@DeleteMapping(value = "/{id}")  
public ResponseEntity<Void> cancelByIdAndName(@Positive @PathVariable Long id, @NotBlank @RequestParam String username) {  
    reservationService.cancelByIdAndName(id, username);  
    return ResponseEntity.noContent().build();  
}

@PathVariable, @RequestParam처럼 단순 타입이 매개변수로 들어오는 경우는 다르다. 이들은 ArgumentResolver가 객체로 바인딩하는 대상이 아니기 때문에, @Valid의 검증 트리거가 동작하지 않는다.

이 경우 클래스 레벨에 @Validated를 선언하면 해결된다. Spring AOP의 프록시가 메서드 실행 전에 파라미터를 가로채 검증을 수행하기 때문이다.

@Validated  // 클래스 레벨에 선언
@RestController
public class ReservationController {

    @DeleteMapping(value = "/{id}")  
    public ResponseEntity<Void> cancelByIdAndName(@Positive @PathVariable Long id,  
                                                  @NotBlank @RequestParam String username) {  
        reservationService.cancelByIdAndName(id, username);  
        return ResponseEntity.noContent().build();  
    }
}

@Valid는 객체 바인딩 이후 검증 / @Validated는 메서드 실행 이전 검증

두 방식의 차이점은?

① 발생 예외 타입이 다르다

@Valid와 @Validated는 검증 실패 시 던지는 예외가 다르기 때문에, @ExceptionHandler에서 각각 처리해야 한다.

	`@Valid`	`@Validated`
발생 예외	`MethodArgumentNotValidException`	`ConstraintViolationException`

② 적용 가능한 위치(@Target)가 다르다

	`@Valid`	`@Validated`
@Target	`FIELD`, `METHOD`, `PARAMETER` 등	`TYPE`, `METHOD`, `PARAMETER`

@Valid는 클래스 레벨(TYPE)에 선언할 수 없다. 반면 @Validated는 클래스 레벨에 선언할 수 있기 때문에 AOP 포인트컷 역할이 가능하다.

호기심 많은 개발자라면 궁금할 점

다만 흥미로운 점은, 실제로는 @Validated 없이 @Constraint 애노테이션만으로도 단순 파라미터 검증이 가능한 경우가 있다. 이 부분은 HandlerMethodValidationException을 정리하면서 따로 다룰 예정이다.

자료 조사하면서 더 알아볼 키워드

HandlerMethodArgumentResolver
Spring AOP 프록시 메커니즘 (JDK Dynamic Proxy vs CGLIB)
Bean Validation Group 검증
MethodArgumentNotValidException

Bean Validation으로 요청 DTO 검증하기

토리8 — Sat, 23 May 2026 19:51:56 +0900

레벨2 방탈출 미션에서 요청 DTO 검증을 도메인 검증과 동일하게 validate() 메서드로 직접 처리했다. 리뷰어분이 Spring Validation을 키워드로 제시해줬고, 이를 계기로 Bean Validation을 도입하게 됐다.

아래는 Bean Validation을 적용하면서 겪은 시행착오와 오해를 솔직하게 정리한 내용이다.

Bean Validation이란 무엇인가?

Bean Validation은 JavaBean 유효성 검증을 위한 메타데이터 모델과 API에 대한 정의이며 여기서 언급하고 있는 JavaBean은 직렬화 가능하고 매개변수가 없는 생성자를 가지며, Getter 와 Setter Method를 사용하여 프로퍼티에 접근이 가능한 객체를 의미합니다

자바에서 객체의 필드 값이나 상태에 대해서 제약 조건(Constraint)를 애노테이션 통해서 간편하게 검증할 수 있도록 지원하는 기술이다.

Bean Validation 없이도 문제없는 거 아냐?

미션을 진행하면서 느낀 기존 방식의 불편함

Bean Validation 없이도 필드마다 검증 메서드를 직접 작성해 호출하는 방식으로 충분히 구현할 수 있다. 지금은 필드가 4개뿐이라 괜찮아 보이지만, 필드가 늘어나거나 요구사항이 바뀐다면 어떨까? 검증 메서드가 그만큼 늘어나고, 변경할 곳도 많아진다. 결국 코드의 가독성과 유지보수성이 눈에 띄게 떨어진다.

public record ReservationRequest(
        String name,
        LocalDate date,
        Long timeId,
        Long themeId) {

    public ReservationRequest {
        validateName(name);
        validateDate(date);
        validateTimeId(timeId);
        validateThemeId(themeId);
    }

    private static void validateName(String name) {
        if (name == null || name.isBlank()) {
            throw new IllegalArgumentException("예약자 이름은 빈값일 수 없습니다.");
        }
        if (name.length() > 20) {
            throw new IllegalArgumentException("예약자 이름은 20자 이하여야 합니다.");
        }
    }

    private static void validateDate(LocalDate date) {
        if (date == null) {
            throw new IllegalArgumentException("예약 날짜는 필수입니다.");
        }
    }

    private static void validateTimeId(Long timeId) {
        if (timeId == null) {
            throw new IllegalArgumentException("예약 시간은 필수입니다.");
        }
    }

    private static void validateThemeId(Long themeId) {
        if (themeId == null) {
            throw new IllegalArgumentException("예약 테마는 필수입니다.");
        }
    }
}

Bean Validation을 적용함으로서 간편해진 코드

public record ReservationRequest(  
        @NotBlank(message = "예약자 이름은 빈값일 수 없습니다.")  
        @Size(max = 20, message = "예약자 이름은 20자 이하여야 합니다.")  
        String name,  
  
        @NotNull(message = "예약 날짜는 필수입니다.")  
        @JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd")  
        LocalDate date,  
  
        @NotNull(message = "예약 시간은 필수입니다.")  
        Long timeId,  
  
        @NotNull(message = "예약 테마는 필수입니다.")  
        Long themeId) {  
}

제약 선언과 검증 실행은 다르다

미션을 진행하면서 @NotNull, @Size 등의 애노테이션을 추가하면 Spring이 알아서 검증을 수행해줄 것이라고 생각했다. 하지만 실제 테스트에서는 검증이 동작하지 않았고, Controller 파라미터에 @Valid를 추가해야만 검증이 수행됐다.

@PostMapping  
public ResponseEntity<ReservationResponse> register(@Valid @RequestBody ReservationRequest reservationRequest) {  
    ReservationResponse reservationResponse = reservationService.register(reservationRequest);  
    return ResponseEntity.created(URI.create("/reservations/" + reservationResponse.id()))  
            .body(reservationResponse);  
}

@NotNull, @Size 같은 애노테이션은 "이 필드는 이런 제약이 있다"고 선언만 할 뿐, 실제로 검증을 실행하지는 않는다.

@Valid를 컨트롤러 파라미터에 선언해야 Spring이 "아, 이 객체는 검증이 필요하구나" 를 인식하고, 선언된 제약 조건들을 실제로 실행시킨다.

즉, 제약 조건 애노테이션은 규칙서이고, @Valid는 "이 규칙서를 실제로 검사해라"는 명령인 셈이다.

(i+1) 그렇다면 @Valid는 어떤식으로 검증이 진행되는가?`

@RequestBody JSON 역직렬화
   ↓
ReservationRequest 객체 생성 (DTO 생성 완료)
   ↓
@Valid 감지 (ArgumentResolver)
   ↓
검증 위임 (LocalValidatorFactoryBean)
   ↓
@Constraint 애노테이션 탐색 (Validator)
   ↓
실제 검증 수행 (ConstraintValidator)
   ↓
실패 시 MethodArgumentNotValidException 발생

@RequestBody에 의해 JSON이 역직렬화되어 DTO 객체가 먼저 생성된다.

이후 컨트롤러 파라미터에 @Valid가 선언되면, Spring MVC의 ArgumentResolver가 이를 감지해 LocalValidatorFactoryBean에게 검증을 위임한다.

Validator는 생성된 DTO 객체의 필드에 선언된 @Constraint 애노테이션들을 탐색하고, 각 애노테이션에 연결된 ConstraintValidator가 실제 검증 로직을 수행한다.

검증에 실패하면 MethodArgumentNotValidException이 발생한다.

(i+1) 호기심 많은 개발자라면 궁금할 점

DTO가 아닌 서비스 레이어에서도 Bean Validation을 적용할 수 있을까?

지금은 컨트롤러에서 @Valid로 DTO를 검증했는데, 서비스 메서드 파라미터에도 동일하게 적용할 수 있는지 궁금했다.

결론부터 말하면, @Valid는 기본적으로 컨트롤러 계층에서만 동작한다.

모든 요청은 프론트 컨트롤러인 DispatcherServlet을 통해 컨트롤러로 전달된다. 이 과정에서 ArgumentResolver가 컨트롤러 메서드의 객체를 만들어주는데, @Valid 역시 ArgumentResolver에 의해 처리된다.

@RequestBody의 경우 ArgumentResolver의 구현체인 RequestResponseBodyMethodProcessor가 JSON을 객체로 변환하며, 이 내부에서 @Valid로 시작하는 애노테이션이 있을 경우 유효성 검사를 진행한다.

— MangKyu's Diary

즉, @Valid는 ArgumentResolver가 동작하는 컨트롤러 계층에 종속되어 있기 때문에, 서비스나 레포지토리 같은 다른 계층에서는 기본적으로 검증이 수행되지 않는다.

더 알아볼 수 있는 키워드

ArgumentResolver
LocalValidatorFactoryBean
ConstraintValidator