Spring 기반 애플리케이션을 개발하다 보면 예외 처리는 반드시 마주치게 되는 주제다. 처음에는 try~catch로 빠르게 해결할 수 있어 보이지만, 규모가 커질수록 잘못된 예외 처리 방식은 유지보수성과 안정성을 급격히 떨어뜨린다.
특히 Spring에서는 트랜잭션, AOP, 컨트롤러 레이어가 분리되어 있기 때문에 예외를 어디서 던지고 어디서 잡을지에 대한 기준이 없다면 코드는 빠르게 복잡해진다.
이 글에서는 Spring 예외 처리에서 실무에서 자주 발생하는 대표적인 실수들을 정리하고, 왜 문제가 되는지 차분히 살펴본다.
Spring 예외 처리 try catch 남용
가장 흔한 실수는 모든 로직을 try~catch로 감싸는 것이다. 서비스 메서드마다 try~catch가 등장하고, 예외가 발생하면 로그를 찍고 null을 반환하거나 임의의 값을 리턴하는 패턴을 종종 볼 수 있다.
이 방식은 당장은 에러를 숨겨준다. 하지만 문제는 실패가 성공처럼 보인다는 점이다. 컨트롤러까지 예외가 전달되지 않으므로 클라이언트는 정상 응답을 받았다고 인식한다. 결과적으로 실제 오류 원인은 조용히 묻힌다.
또 다른 문제는 가독성이다. 비즈니스 로직보다 예외 처리 코드가 더 길어지고, 핵심 흐름을 파악하기가 어려워진다. 예외 처리 책임이 분산되면서 중복 코드도 급격히 늘어난다.
Spring에서는 예외를 던지는 것 자체가 잘못이 아니다. 오히려 예외를 명확히 던지고, 한 곳에서 처리하는 구조가 코드를 훨씬 단순하고 예측 가능하게 만든다.
Spring 예외 처리 RuntimeException 오용
두 번째로 흔한 실수는 모든 예외를 RuntimeException 하나로 퉁치는 것이다. 메시지만 다른 RuntimeException을 던지고 구체적인 의미는 문자열로만 표현하는 경우다.
이렇게 되면 예외의 의도가 코드 레벨에서 드러나지 않는다. 게시글이 없는 상황인지, 권한이 없는 상황인지, 데이터 무결성 오류인지 타입만 보고는 구분할 수 없다.
결국 ExceptionHandler에서는 메시지 문자열을 비교하거나 상황별 분기 처리를 해야 한다. 이는 컴파일 타임에 잡을 수 없는 매우 취약한 구조다.
Spring에서 권장되는 방식은 도메인 의미가 드러나는 커스텀 예외를 정의하는 것이다. PostNotFoundException, UnauthorizedPostException처럼 이름 자체가 문서가 되도록 만드는 것이 장기적으로 훨씬 안전하다.
Spring 예외 처리 ExceptionHandler 실수
마지막으로 많이 발생하는 실수는 ExceptionHandler를 잘못 사용하는 것이다. 대표적으로 @ExceptionHandler(Exception.class) 하나로 모든 예외를 처리하는 경우다.
이렇게 되면 모든 예외가 동일한 응답과 상태 코드로 반환된다. 클라이언트 입장에서는 잘못된 요청인지 서버 오류인지 구분할 수 없고, API 신뢰도는 떨어진다.
또한 도메인 예외와 시스템 예외가 섞이면서 로깅 전략도 흐려진다. 모든 예외를 error 로그로 남기면 실제 장애와 비즈니스 예외를 구분하기 어렵다.
ExceptionHandler는 “잡기 위한 도구”가 아니라 “의도를 표현하는 도구”다. 예외 타입별로 책임을 나누고, 필요하다면 도메인별로 분리하는 것이 Spring 예외 처리의 핵심이다.
정리하자면 Spring 예외 처리의 실수는 기술 부족이 아니라 설계 부재에서 나온다. 예외는 숨길 대상이 아니라 시스템의 상태를 설명하는 수단이다.
던질 곳에서는 명확히 던지고, 잡을 곳에서는 일관되게 처리하는 구조가 가장 유지보수하기 쉬운 Spring 애플리케이션을 만든다.