예외를 삼키고 지나가는 개발자에게

by 그릿 | GROWTH_ESSAY | 2026-10-27

코드를 리뷰하거나 멘토링을 하다 보면 유독 자주 마주치는 패턴이 있습니다. 메서드 전체를 try-catch로 감싸고, catch 블록 안에 e.printStackTrace() 한 줄만 적어둔 코드입니다. 심지어 아무것도 적지 않은 빈 catch 블록도 흔히 봅니다.

"에러가 터지면 서버가 죽을까 봐 일단 막았습니다."

2년 차 백엔드 멘티 한 분이 했던 말입니다. 요청이 실패했을 때 500 에러를 뱉는 대신, 200 OK와 빈 객체를 내려주면 안전하다고 믿었던 것입니다. 하지만 이건 방어가 아닙니다. 실패를 은폐한 것에 불과합니다.

빨간 줄을 지우는 게 예외 처리가 아닙니다

IDE에서 빨간 줄이 뜨면 마음이 조급해집니다. 컴파일러가 Checked Exception을 경고하면, 기계적으로 try-catch를 씌웁니다. 빨간 줄만 사라지면 문제가 해결되었다고 착각합니다.

문제는 그 다음입니다. 예외가 발생했을 때 시스템이 어떤 상태에 놓이는지 고민하지 않습니다. 멘토링 3주 차에 결제 모듈 코드를 가져온 멘티가 있었습니다. 외부 결제사 API 호출 구간에서 타임아웃 예외가 터지자, 이를 조용히 삼키고 null을 반환하도록 짰습니다.

결과는 치명적이었습니다. 주문 테이블에는 결제 완료로 기록되었는데, 실제 결제사에는 승인 요청조차 도달하지 않았습니다. 돈은 들어오지 않았는데 물건만 배송되는 사고였습니다. 에러 로그 한 줄 남지 않아서 문제를 역추적하는 데만 사흘이 걸렸습니다. 예외를 덤덤하게 삼켜버린 대가였습니다.

실패를 정확하게 드러내는 것이 실력입니다

예외 처리는 에러를 감추는 기술이 아닙니다. 오히려 실패를 시스템의 약속된 언어로 정확하게 드러내는 설계입니다.

클라이언트 요청 파라미터가 잘못되었는지, DB 커넥션 풀이 말랐는지, 외부 연동 서버가 죽었는지는 완전히 다른 사건입니다. 이 사건들을 구별하지 않고 삼키는 순간, 동료 개발자도 모니터링 시스템도 아무런 대응을 할 수 없게 됩니다.

저희가 멘토링에서 강조하는 원칙이 있습니다. 현재 작성 위치에서 책임지고 복구할 수 없는 예외라면 절대로 삼키지 마십시오. 차라리 의미 있는 커스텀 예외로 감싸서 상위 레이어로 던지거나, 정확한 에러 코드와 맥락을 담아 로그를 남겨야 합니다. 시스템이 정상적으로 실패하게 만드는 법을 모르면, 정상적인 복구도 불가능합니다.

예외 앞에서 멈추는 세 가지 기준

코드에서 catch 문을 열기 전에 세 가지만 스스로에게 물어보십시오.

첫째, 이 예외가 발생했을 때 데이터 정합성이 깨지지 않고 안전하게 롤백되는가.

둘째, 호출한 쪽에서 이 실패를 명확히 인지하고 재시도나 대체 처리를 할 수 있는가.

셋째, 장애가 터졌을 때 온콜 담당자가 이 로그만 보고도 10분 안에 원인을 특정할 수 있는가.

이 질문에 즉시 답할 수 없다면, 그 catch 블록은 시한폭탄입니다. 에러 메시지를 두려워하지 마십시오. 진짜 무서운 것은 아무런 소리도 내지 않고 서서히 망가져 가는 프로덕션 데이터베이스입니다.