코드 품질 개선 - 67회: 오류 표현이 너무 많아도 문제다

queryUserModel이 null, ApiResult.Failure, ApiResult.Success(null), 중첩된 UserListQueryResponse.Failure, UserListQueryResponse.Success(userModel = null)까지 여러 방식으로 오류와 예외 상황을 표현하고 있었다. 이렇게 되면 호출자는 각 값의 의미를 일일이 해석해야 하고, 실제 처리도 비슷한데 분기만 늘어나 코드 복잡도가 커진다.

해결책은 호출자가 필요로 하는 형태로 오류를 변환하고 통일하는 것이다. 예시처럼 반환형을 UserModelApiResult로 바꾸고, 성공은 Success(UserModel), 실패는 Failure(UserRequestErrorType)처럼 한 가지 기준으로 정리하면 호출부는 그 두 가지만 알면 된다.

세부 에러 정보가 꼭 필요하지 않다면 null처럼 더 단순한 표현으로 줄여도 된다. 특히 data layer처럼 모듈이나 계층의 경계에서는 DB나 network의 내부 오류를 그대로 위로 올리지 말고, 상위 계층이 다루기 쉬운 형태로 추상화하거나 필요한 정보만 남겨야 한다.