에러 메세지를 상세하게 던져야 하는 이유

에러 메세지를 굉장히 자세하게 적을 필요가 없다고 생각했다. 자칫 잘못 적으면 사용자에게 내부 구조를 노출 시킬 수도 있을거 같고, 굳이 단서를 제공해주지 않아도 에러의 네임만으로도 충분히 문제를 찾을 수 있을 것이라 생각했다.

그런데 이번 팀프로젝트를 진행하면서 AWS CloudWatch를 이용해 에러를 로깅했을 때 문제가 보이기 시작했다.

에러 메세지를 간단하게 던질 때

throw new BabbleNotFoundException("해당 방을 찾을 수 없습니다.");

에러가 발생했다. 방을 못 찾았다고 한다. 그렇구나. 근데 왜?

에러(What)가 발생한 건 알수 있었지만, 왜(Why)가 발생했는 진 알 방법이 없었다. 해당 방을 찾을 수 없다는 친절한 표현은 아무짝에 쓸모 없었다. 차라리 not found room (15) 라고 대충 던져주는 것이 “15번 방이 없다는거구나!” 하고 유추하기 더 쉬워 보였다.

그래서 에러 메세지를 전반적으로 리팩토링했다.

에러 메세지를 상세하게 던질 때

throw new BabbleNotFoundException(String.format("존재하지 않는 게임 Id(%d) 입니다.", gameId));

에러가 발생했다. 게임을 못 찾았다고 한다. ID가 1000인 게임을 찾으려고 했구나.

ID가 1000인 게임을 찾으려 했고, 마침 1000인 게임이 없기 때문에 에러가 발생했음을 예상 가능하다. 더불어 로그를 살펴볼 때도 사용자들이 무얼 요구하는지 통계를 확인하기도 쉬워졌다.

결론

에러 메세지는 ‘친절함’이 중요한게 아니라, ‘단서’가 중요하다. 그 단서는 바로 데이터의 값이다. 에러 메세지가 아무리 불친절해도 단서만 있다면, 에러의 이유를 추측하기 쉬워진다.

그리고 백엔드 개발자가 던지는 에러는 대부분의 경우 백엔드 개발자나 프론트 개발자가 본다. 사용자가 볼 에러 메세지는 프론트 개발자가 어련히 잘 관리할테니, 친절함 보다 단서에 더 집중한 에러 메세지를 작성하자.