[내일배움캠프 Spring 3기] CH3 숙련 Spring 일정 관리 앱 Develop - 도전 기능

Lv5 - 예외처리

이전 과제에서 기능은 동작했지만, 한 가지 큰 문제가 있었다.

예외가 발생하면 대부분 400 또는 500으로만 내려갔다.

• 로그인 안 해도 400
• 존재하지 않는 일정도 400
• 이메일 중복도 500
• Validation 실패도 기본 에러 페이지

이 상태는 동작은 하지만 API답지 않은 상태였다.

그래서 Lv5에서는 단순 기능 추가가 아니라 API를 실무스럽게 다듬는 작업을 진행했다.

---

목표

• Validation 강화
• 전역 예외 처리 도입
• HTTP 상태 코드 명확히 분리
• 에러 응답 구조 통일

---

Validation 강화 (@Valid + DTO 중심 설계)

왜 DTO에 Validation을 넣었는가?

Validation은 Controller가 아니라 DTO에 두는 게 맞다.

• 데이터의 규칙은 데이터 구조에 정의하는 게 자연스럽다.
• Entity에는 비즈니스 로직만 두는 것이 좋다.
• 유지보수성이 올라간다.

---

수정한 코드

UserRequest

@NotBlank(message = "username은 필수입니다.")
@Size(max = 4, message = "username은 4글자 이내여야 합니다.")
private String username;

@Email(message = "email 형식이 올바르지 않습니다.")
@NotBlank(message = "email은 필수입니다.")
private String email;

@NotBlank(message = "password는 필수입니다.")
@Size(min = 8, message = "password는 최소 8자 이상이어야 합니다.")
private String password;

---

ScheduleRequest

@NotBlank(message = "title은 필수입니다.")
@Size(max = 10, message = "title은 10글자 이내여야 합니다.")
private String title;

---

Controller에 @Valid 적용

@PostMapping
public ResponseEntity<ScheduleResponse> create(
        @Valid @RequestBody ScheduleRequest request,
        HttpSession session
)

여기서 중요한 건:

DTO에만 Validation을 붙이면 아무 일도 안 일어난다.
반드시 @Valid를 Controller에서 붙여야 동작한다.

---

전역 예외 처리 도입 (@RestControllerAdvice)

이전까지는 예외가 발생하면:

• 500 Internal Server Error
• 기본 에러 응답
• JSON 구조가 통일되지 않음

그래서 전역 예외 처리 클래스를 추가했다.

---

exception 패키지 추가

exception
 ┣ CustomException
 ┣ ErrorResponse
 ┗ GlobalExceptionHandler

---

ErrorResponse 구조 통일

@Getter
public class ErrorResponse {

    private final LocalDateTime timestamp = LocalDateTime.now();
    private final int status;
    private final String message;
    private final Map<String, String> fieldErrors;
}

모든 에러는 이 구조로 내려가게 만들었다.

---

GlobalExceptionHandler

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<ErrorResponse> handleValidation(...) { ... }

    @ExceptionHandler(CustomException.class)
    public ResponseEntity<ErrorResponse> handleCustomException(...) { ... }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<ErrorResponse> handleException(...) { ... }
}

이제 어디서 예외가 터져도 이 클래스가 전부 받아서 처리한다.

---

CustomException 도입 (상태 코드 분리)

이전에는:

throw new IllegalArgumentException("로그인이 필요합니다.");

-> 전부 400

이건 명확하지 않다.

그래서 상태 코드를 포함한 예외 클래스를 만들었다.

---

CustomException

public class CustomException extends RuntimeException {

    private final HttpStatus status;

    public CustomException(HttpStatus status, String message) {
        super(message);
        this.status = status;
    }
}

---

Service에서 이렇게 변경

로그인 필요

throw new CustomException(HttpStatus.UNAUTHORIZED, "로그인이 필요합니다.");

-> 401

---

존재하지 않는 일정

.orElseThrow(() -> new CustomException(
        HttpStatus.NOT_FOUND,
        "해당 일정이 존재하지 않습니다."
));

-> 404

---

이메일 중복

if (userRepository.existsByEmail(request.getEmail())) {
    throw new CustomException(HttpStatus.CONFLICT, "이미 존재하는 이메일입니다.");
}

-> 409

---

Postman 실습

유저 생성

Validation 실패 (400)

{
  "title": "12345678901",
  "content": "내용"
}

로그인 하지 않고 일정 생성 (400)

---

로그인 안 함 (401)

POST /api/schedules

-> 401 Unauthorized

로그인- 이메일, 비밀번호 틀림 (401)

---

존재하지 않는 일정 (404)

GET /api/schedules/99999

-> 404 Not Found

---

이메일 중복 (409)

POST /api/users

같은 이메일 2번 요청

-> 409 Conflict

Test 계정 생성

"이미 존재하는 이메일입니다" 409 처리

---

트러블슈팅

이메일 중복 시 500 에러 발생

처음에는 이메일 중복 시 500이 발생했다.

원인은:

DB에 UNIQUE 제약이 걸려 있어서
DataIntegrityViolationException이 터진 것

이걸 해결하기 위해:

• UserRepository에 existsByEmail() 추가
• 저장 전에 사전 차단

결과: 500 -> 409 Conflict로 정상 변경

400과 401의 차이 이해

처음에는 로그인 안 한 상태도 400으로 처리했다.

하지만

• 400 -> 요청 형식이 잘못됨
• 401 -> 인증되지 않음

전역 예외 처리가 왜 필요한지 깨달음

예외를 Controller마다 처리하면 코드가 지저분해진다.

전역으로 처리하니:

• 코드가 깔끔해짐
• 에러 응답 구조 통일
• 유지보수성 증가

---

Lv6 – 비밀번호 암호화 적용 (BCrypt)

Lv3에서 password 필드를 추가했지만, 사실 그때는 평문 그대로 저장하고 있었다.
기능은 동작했지만 보안 관점에서는 치명적인 구조였다.

이번 Lv6에서는 비밀번호를 암호화하여 저장하고,
로그인 시에는 암호화된 값과 비교하도록 수정했다.

---

왜 암호화가 필요한가?

지금까지의 구조:

new User(
    request.getUsername(),
    request.getEmail(),
    request.getPassword()
);

그리고 로그인 시에는

if (!user.getPassword().equals(request.getPassword())) {
    ...
}

이 방식의 문제점은

• DB가 털리면 비밀번호가 그대로 노출됨
• 운영 환경에서는 절대 허용되지 않는 구조
• equals 비교는 보안적으로 취약

그래서 단방향 암호화(해시) 방식으로 전환했다.

---

build.gradle에 BCrypt 추가

implementation 'at.favre.lib:bcrypt:0.10.2'

Gradle을 reload한 뒤, 암호화 클래스를 추가했다.

---

PasswordEncoder 직접 구현

Spring Security를 쓰지 않고,
과제 요구사항에 맞게 직접 PasswordEncoder를 구현했다.

@Component
public class PasswordEncoder {

    public String encode(String rawPassword) {
        return BCrypt.withDefaults()
                .hashToString(BCrypt.MIN_COST, rawPassword.toCharArray());
    }

    public boolean matches(String rawPassword, String encodedPassword) {
        BCrypt.Result result = BCrypt.verifyer()
                .verify(rawPassword.toCharArray(), encodedPassword);

        return result.verified;
    }
}

• encode() -> 회원가입 시 암호화
• matches() -> 로그인 시 비교

---

UserService 수정 (회원가입 시 암호화)

기존 코드:

request.getPassword()

수정 코드:

String encodedPassword = passwordEncoder.encode(request.getPassword());

User saved = userRepository.save(
        new User(
                request.getUsername(),
                request.getEmail(),
                encodedPassword
        )
);

이제 DB에 저장되는 값은 다음과 같은 형태가 된다.

$2a$10$g9dS9s8sK...

---

로그인 로직 수정

이전:

if (!user.getPassword().equals(request.getPassword())) {

수정:

if (!passwordEncoder.matches(request.getPassword(), user.getPassword())) {
    throw new CustomException(HttpStatus.UNAUTHORIZED,
            "이메일 또는 비밀번호가 올바르지 않습니다.");
}

이제는 raw password vs encoded password를 안전하게 비교한다.

---

Postman 실습

회원가입

{
  "username": "lee",
  "email": "lee@test.com",
  "password": "12345678"
}

DB 확인 -> 암호화된 문자열 저장됨

---

로그인 성공

{
  "email": "lee@test.com",
  "password": "12345678"
}

-> 200 OK

---

로그인 실패 (틀린 비밀번호)

{
  "email": "lee@test.com",
  "password": "11111111"
}

-> 401 Unauthorized

---

트러블슈팅

1) 기존 유저 로그인 실패

암호화 적용 후, 기존에 평문으로 저장된 유저는 로그인에 실패했다.

이유는 간단하다.

• DB에는 평문
• 로그인 로직은 암호화 비교

그래서 테스트를 위해 새로 회원가입을 진행했다.

-> 암호화 적용 이후 생성된 유저만 정상 로그인 가능

---

2) equals 비교의 위험성 체감

단순 equals 비교는 보안적으로 매우 취약하다.

BCrypt는:

• salt 자동 적용
• 무차별 대입 공격 방지
• 단방향 해시

실무에서 가장 널리 사용되는 방식이라는 점도 직접 체감했다.

---

이번 단계에서 느낀 점

Lv5에서 예외 처리를 정리했다면,
Lv6은 보안을 신경 쓰는 단계였다.

단순히 기능이 되는 API가 아니라, 운영 가능한 API로 발전하는 느낌이었다.

• 상태 코드 분리
• 전역 예외 처리
• 비밀번호 암호화

이제야 비로소 백엔드 API답다는 느낌이 들었다.