"에러는 막는 것이 아니라 관리하는 것" 백엔드 예외 처리 전략

"서버가 죽지는 않았는데, 클라이언트는 왜 500 에러를 받을까요?"
사용자에게 친절하고 개발자에게는 명확한 디버깅 정보를 주는 견고한 예외 처리 시스템 구축법을 정리합니다.

1. Checked Exception vs Unchecked Exception

자바와 같은 언어에서는 예외를 두 가지로 나눕니다. 반드시 처리해야 하는 Checked Exception과 런타임에 발생하는 Unchecked Exception입니다. 현대적인 프로그래밍에서는 로직의 가독성을 위해 대부분의 예외를 런타임 예외로 감싸서(Wrapping) 던지는 추세입니다.

2. 전역 예외 처리기(Global Exception Handler) 도입

컨트롤러마다 try-catch를 도배하고 있지는 않으신가요? 이는 코드 중복을 초래하고 유지보수를 어렵게 만듭니다. 스프링의 @RestControllerAdvice나 익스프레스의 에러 핸들링 미들웨어를 사용하여 한 곳에서 예외를 공통적으로 처리해야 합니다.

💡 실무 노트

실무에서 가장 나쁜 습관은 예외를 잡고 나서 로그만 찍고 아무것도 안 하거나, 로그조차 남기지 않는 것입니다. 에러가 발생했다면 반드시 의미 있는 정보를 남겨야 합니다.

팁: 클라이언트에게는 Internal Server Error 같은 모호한 메시지 대신, 비즈니스 에러 코드(예: USER_NOT_FOUND)를 정의해서 응답해 보세요. 그리고 서버 로그에는 에러 발생 위치(StackTrace)와 당시의 입력값을 남겨야 합니다. 에러 발생 시각, 사용자의 요청 ID(Trace ID)를 함께 기록하면 수천 개의 로그 사이에서 범인을 찾는 시간이 획기적으로 줄어듭니다.

"좋은 개발자는 코드가 잘 돌아갈 때가 아니라, 코드가 터졌을 때 진가를 발휘합니다."