지난 글에서는 @Valid와 @Validated를 비교하고 ResponseEntityExceptionHandler를 활용해 요청 값의 형식을 검증하는 방법을 다뤘습니다.하지만 실무 개발은 여기서 끝나지 않습니다.입력 값의 형식은 맞지만, 비즈니스 규칙 때문에 거절해야 하는 상황이 훨씬 더 많기 때문이죠."사용자 ID 형식은 맞는데(400 아님), 이미 탈퇴한 회원이라 로그인이 안 돼." "결제 요청 양식은 완벽한데(400 아님), 잔액이 부족해서 결제할 수 없어." 이걸 단순히 400으로 퉁치자니 모호하고, 그렇다고 500을 뱉으면 모니터링 알람이 빗발칩니다.오늘은 비즈니스 예외를 422(Unprocessable Entity)로 명확히 분리하고, 시스템 장애(500)와 공존하며 유연하게 관리하는 실무 패..