Spring 애플리케이션에서 예외 처리를 구조화하다 보면 반드시 한 번은 고민하게 되는 지점이 있다. ExceptionHandler를 하나로 통합할 것인가, 아니면 도메인별로 분리할 것인가 하는 문제다.
둘 다 정답이 될 수 있다. 중요한 것은 “어느 쪽이 더 좋다”가 아니라 현재 시스템의 규모와 도메인 복잡도에 어느 방식이 더 적합한지를 판단하는 것이다.
이 글에서는 ExceptionHandler 통합 방식과 도메인별 분리 방식의 차이를 정리하고, 실무에서 어떤 기준으로 선택하면 좋은지 살펴본다.
ExceptionHandler 통합 전역 예외 처리
ExceptionHandler 통합 방식은 하나의 @RestControllerAdvice에서 모든 예외를 처리하는 구조다. 가장 단순하고 빠르게 적용할 수 있는 방식이며, 소규모 프로젝트에서 특히 많이 사용된다.
AppException을 최상위로 두고, 모든 커스텀 예외를 이 타입으로 묶은 뒤 하나의 핸들러에서 처리하면 에러 응답 포맷을 쉽게 통일할 수 있다. 로그 포맷, 응답 구조, 상태 코드 정책을 한 곳에서 관리할 수 있다는 점이 장점이다.
또한 신규 개발자가 프로젝트에 합류했을 때 예외 처리 흐름을 이해하기 쉽다. “예외는 여기로 온다”라는 규칙이 명확하기 때문이다. 운영 초기 단계나 MVP 성격의 서비스라면 이 방식이 충분히 합리적이다.
하지만 도메인이 늘어나기 시작하면 문제가 서서히 드러난다. 하나의 핸들러 클래스에 User, Post, Order, Payment 예외가 모두 모이게 되고, 메서드 수가 급격히 증가한다. 결국 예외 처리 클래스가 또 하나의 거대한 컨트롤러처럼 변한다.
ExceptionHandler 도메인별 분리 전략
도메인별 분리 방식은 각 도메인마다 전용 ExceptionHandler를 두는 구조다. PostExceptionHandler, UserExceptionHandler처럼 도메인 단위로 예외 책임을 나눈다.
이 방식의 가장 큰 장점은 응집도다. 게시글 도메인의 예외는 게시글 핸들러에서만 처리되고, 유저 도메인의 규칙은 유저 핸들러에만 존재한다. 도메인 경계가 코드 구조에 그대로 드러난다.
또한 도메인별로 응답 메시지 정책이나 로깅 전략을 다르게 가져갈 수 있다. 보안과 민감한 도메인은 로그를 최소화하고, 운영 편의가 중요한 도메인은 상세 로그를 남기는 식의 선택도 가능하다.
단점도 분명하다. 프로젝트 초반부터 분리를 과도하게 적용하면 구조가 복잡해지고, 오히려 관리 포인트가 늘어난다. 공통 예외와 도메인 예외의 경계를 명확히 정의하지 않으면 어디서 처리해야 할지 혼란이 생길 수 있다.
ExceptionHandler 통합과 분리 선택 기준
결론부터 말하면 처음부터 완벽한 구조를 만들 필요는 없다. 대부분의 프로젝트는 통합에서 시작해 분리로 진화한다.
도메인이 1~2개 수준이고 에러 정책이 단순하다면 통합 ExceptionHandler가 훨씬 효율적이다. 빠르게 개발하고, 구조에 대한 학습 비용도 적다.
반대로 도메인이 명확히 분리되고 팀 규모가 커지거나 도메인별 책임이 중요해지는 시점이라면 분리 전략이 자연스럽다. 이때도 공통 예외는 전역 핸들러로 두고, 도메인 특화 예외만 분리하는 하이브리드 구조가 가장 많이 사용된다.
ExceptionHandler는 기술적인 선택이 아니라 설계 선택이다. 현재의 복잡도, 앞으로의 확장 가능성, 팀의 이해도를 기준으로 가장 덜 부담스러운 방향을 선택하는 것이 가장 좋은 정답이다.