유저에게 보이는 에러메시지 워싱은 어디서 하는게 좋을까? 서버 vs 프론트
서버에서 예외(에러)가 나면 보통 이런 응답이 내려간다.
이 에러메시지 그대로 유저에게 보여주는 건 바람직하지 못하다.
그래서 보통 에러메시지를 유저편의적으로 가공하는데, 이를 '에러메시지 워싱'이라고 표현한다.
# 얼마나 구체적인 에러 메시지를 보여줄까?
워싱 주체에 대해 논하기 전, 먼저 유저에게 어떤 에러메시지를 보여주는 게 적합할지 생각을 해보자.
정답은 아닐 수도 있지만, 필자는 이렇게 생각한다.
1. 유저 스스로가 다른 액션을 통해 해당 에러를 해소할 수 있는 경우는 최대한 구체적으로 알려준다.
ex) 회원가입 시 비밀번호 규칙 중, 특수기호가 포함되어야 하는데 빠진 경우
추상적인 경우: 비밀번호 규칙에 올바르지 않습니다.
구체적인 경우: 특수기호가 빠졌어요. 비밀번호에는 적어도 1개 이상의 특수문자가 필요해요.
유저는 에러메시지를 확인하고 해당 에러를 스스로 해소할 수 있어진다.
2. 반대로, 유저가 어떤 액션을 해도 해당 에러를 해소할 수 없는 경우는 최대한 추상적으로 알려준다.
ex) 회원가입 시 다른 서버 호출을 하는데 해당 서버가 죽은 경우
추상적인 경우: 요청을 처리하지 못하였어요. 잠시 후 다시 시도하거나 고객센터에 문의하세요.
구체적인 경우: XX 서버 호출이 실패하였습니다. 사유: xxxx 에러
이런 경우는 아무리 유저에게 구체적인 정보를 알려줘도 해소할 수 없다. 따라서 최대한 추상적으로 알려준다.
이는 좀 더 포괄적으로 개발자가 비즈니스 로직상으로 의도한 flow가 아닌 경우 발생한 예외의 경우 최대한 자세히 알려주고, 그 외 예상치 못한 에러나 테크니컬 적인 에러는 추상적으로 포장하는 것이 좋다고 생각해도 무방할 것이다.
이제 이 워싱은 프론트에서 하는 게 적합할까? 서버에서 하는게 적합할까? 에 대해서 고민해 보자
# 다른 개발자들 의견
필자 회사는 보통 서버에서 다 워싱해서 내려주는데, 다른 사람들은(조직) 어떻게 하는지, 생각하는지 궁금했다.
서버다, 프론트다 좁혀지지 않고 다양한 의견이 나왔다. 정리하자면,
서버에서 하는 게 맞다
- 프론트에서까지 해버리면 관리포인트가 늘어난다
프론트에서 하는게 맞다
- 여럿 플랫폼 지원을 (확장성) 고려했을 때 더 유연하다
- 정의된 에러에 대한 더 유저친화적인 에러 메시지
# 필자의 결론
여러 개발자들의 의견을 들어보면서 내린 결론은 다음과 같다.
1. API가 UI에서만 사용되는 경우(다른 플랫폼 지원 가능성이 없는 경우)는 서버에서 에러메시지를 워싱해서 내려준다.
이는 서버, 프론트 둘 다 메시지를 워싱하면 관리포인트가 2개가 생기기 때문에 비효율적이라고 판단했다.
2. 여럿 플랫폼을 지원하는 경우 프론트에서 워싱한다.
이 경우 서버-프론트간 에러 케이스와 규칙을 명확하게 확립해야 할 필요가 있다.
# 좀 더 고민해 보기
- 역할과 관심사의 분리의 관점에서 보면 프론트에서 워싱하는 게 더 맞지 않을까?
다른 분들의 의견은 어떠신가요?