Exception 처리에 대한 회고 (Exception vs Response)

보통 API를 만들면서 예외를 처리해야 할 때 throw Exception을 한다. 예를들어

public MemberResponse someMethod() {
	...
    if (!isValidPassword()) {
    	throw new IllegalArgumentException("패스워드가 올바르지 않습니다.");
    }
    ...
}

 

 

이런식으로 패스워드 값에 대한 검증을 하고, 결과에 따라 예외처리를 할 수 있다.

그런데 회사에서 선배 개발자 분께 이런 피드백을 들었다.

예측 가능한 상황에서는 Exception throw 하지 말고 정상 응답처리 해야된다.

선배 개발자 분의 의견은 Response 객체에 result 성격의 필드를 만들고 해당 값으로 프론트 단에서 정상 여부를 판단하게 하라는 것이었다.

하지만 내 생각은 달랐다. 예측 가능하냐 불가능하냐는 Checked Exception vs Unchecked Exception 의 문제이지 예외로 처리 할건지에 대한 여부는 전혀 다른 문제라고 생각했다.

물론 선배 말처럼 Response 객체에 결과를 담아서 처리하는게 불가능한 방식은 아니다. 하지만 이런 상황에서 예외로 처리해야 하는 이유를 정리하자면 다음과 같다.

 

1. 적절한 Status Code + Exception 처리로 더 명확한 API를 만들 수 있다

예를 들어 모든 응답을 200(OK)로 내려주고 result 필드의 값으로 성공 여부를 판단한다고 하자. 그렇다면 프론트 단에서 모든 응답에 대해 항상 해석을 해야만 한다. 예를 들어 비밀번호 불일치로 로그인이 실패했는데 응답은 정상적인 200(OK)를 내려준다? 이러면 사실 status code의 의미가 불명확해지게 된다.

물론 선배의 의도가 뭔지는 알겠다. 비즈니스 로직 상 일어나는 문제는 전부 200으로 처리하고 실제 서버에 Unchecked Exception이 일어났을 때만 status code를 다르게 보내 관리하고 싶었던 것이다. 하지만 status code는 500번 대 코드를 이미 서버 문제에 대한 코드로 정의하고 있으므로 굳이 그렇게 처리할 이유가 없다.

 

2. HTTP Status Code로 성공/실패를 표현하는 것이 표준적인 방식이다

사실 1번의 이유와 흡사하지만 '표준'이라는 것에 집중해서 설명하고 싶다. 사실 어떻게 개발하느냐는 개인마다 너무 다르고 정말 다양한 방식이 있다. 하지만 우리는 협업을 해야한다. 개인 혼자서의 개발이 아닌 누군가와 함께 말이다. 그렇기 때문에 우리는 읽히는 코드를 만들어야 한다. 그 이유 때문에 개발에서는 '표준'이 존재한다. 항상 거론되는 REST 규칙 또한 동일한 내용이다.

물론 프로젝트의 성격, 회사의 관례에 따라 모든 규칙을 다 지키지는 않는다. 하지만 그런 상황이 아니라면 우리는 최대한 '표준'을 지킬 필요가 있다. 새로운 누군가가 코드를 볼 때 굳이 해석해야 하는 리소스를 생성시킬 필요가 없지 않은가.

 

이 외에도 정말 많은 이유가 있지만 사실 예외 처리의 필요성에 대한 내용이라 다른 정리글을 참고하는게 더 도움 될 듯 하다. (https://jojoldu.tistory.com/734 인프런 CTO 이신 향로님의 글을 추천한다)

 

사실 개발을 하면서 서로 상충되는 의견이 있을 때 설득하는 과정이 쉽지 않다. 특히 상대방이 본인 의견에 대한 믿음이 너무 강할수록, 상대방의 의견을 들을 생각이 없을수록 더욱 그렇다. 하지만 이러한 논리적인 설득의 과정을 통해서 개발자는 더욱 성장할 수 있다고 생각한다. 이번에 선배 분을 설득하는 과정을 통해서 당연하다고만 생각했던 예외 처리에 대해서 다시끔 생각해보는 계기가 되었고, 상대방을 설득하는 커뮤니케이션 스킬 또한 성장했다고 생각한다.