1. 문제 인식 및 정의
현재 프로젝트에서는 예외 처리 클래스들이 명확하게 분리되어 있지 않거나, 일관된 구조로 관리되지 않고 있습니다. 이로 인해 다음과 같은 문제가 발생할 수 있습니다:
-
유지보수의 어려움: 예외 처리 로직이 분산되어 있어 수정이나 확장이 어렵습니다.
-
일관성 부족: 예외 응답 형식이 통일되지 않아 클라이언트에서 처리하기 어렵습니다.
-
가독성 저하: 예외 관련 코드가 흩어져 있어 전체적인 흐름을 파악하기 어렵습니다.
2. 해결 방안
2-1. 의사결정 과정
예외 처리를 일관되게 하기 위해 아래와 같은 기준으로 구조 개선을 결정했습니다:
-
모든 예외 처리는 @RestControllerAdvice를 활용하여 통합합니다.
-
예외 코드는 Enum 기반의 ErrorCode 로 관리합니다.
-
프로젝트 내 모든 예외는 커스텀 예외 클래스를 통해 표현합니다.
-
예외 관련 클래스는 exception 패키지로 명확히 분리합니다.
목표는 응집도 높고, 예측 가능한 에러 처리 구조입니다.
2-2. 해결 과정
예외 패키지 구조정리 (예시)
com.example.project
└── exception
├── ErrorCode.java # 에러 코드 Enum
├── CustomException.java # 공통 예외 클래스
├── GlobalExceptionHandler.java # 전역 예외 처리기
└── ErrorResponse.java # 에러 응답 DTO3. 해결 완료
3-1. 회고
이번 예외 처리 구조 개선을 통해 다음과 같은 개선 효과를 얻을 수 있었습니다:
-
에러 응답의 일관성 확보: 클라이언트는 모든 에러에 대해 예측 가능한 값으로 응답을 받을 수 있음
-
유지보수 용이성: 새로운 예외 추가 시 ErrorCode 및 CustomException만 정의하면 되므로 코드 변경 범위 최소화
-
가독성 향상: 예외 처리 로직이 한 곳에 모여 있어 흐름이 명확해짐
-
확장성 확보: 커스텀 예외 및 에러 코드의 Enum 확장을 통해 다양한 상황에 유연하게 대응 가능
3-2. 전후 비교
| 항목 | 개선 전 | 개선 후 |
|---|---|---|
| 예외 처리 위치 | 각 서비스/컨트롤러에 분산 | 전역 예외 처리기로 통합 |
| 응답 메시지 | 예외마다 다름 (혹은 없음) | ErrorResponse로 통일 |
| 예외 클래스 | 시스템 기본 예외 사용 | 커스텀 예외 정의 (CustomException) |
| 에러 코드 관리 | 하드코딩 | Enum(ErrorCode) 기반 |
| 테스트 가능성 | 낮음 | 예외 상황 테스트 용이 |
