들어가는 말
사이트를 이용을 하며 어떠한 에러를 직면하는 상황은 많이 겪어보셨을 것이라고 생각합니다.
여기서 에러가 났을 때의 적절한 사이트의 대응에 따라 사용자 경험의 차이가 있을 것입니다. 또한 이것은 사이트의 완성도에도 영향을 미칠 것이라 생각합니다.
사용자가 해결을 할 수 있음과 없음, 의도가 된, 되지 않은 에러의 차이점에 대해 이야기해 보고 BCSD의 서비스에서는 어떠한 방향으로 사용해 볼 수 있을지 적어보려 합니다.
1) 어떤 에러가 발생할 수 있을까요? :
크게 나누어 환경, 사용자와의 에러로 나누고 세부적으로는 두 타입으로 나눌 수 있습니다.
[환경과 에러]
1) 의도가 된 에러(예상 가능한 에러)
2) 의도가 되지 않은 에러(예상하지 못한 에러)
[사용자와 에러]
3) 사용자가 해결할 수 있는 에러
4) 사용자가 해결하지 못하는 에러
예시를 들어 위 에러를 설명해보겠습니다.
-
의도가 된 에러(예상 가능한 에러):
로그인을 하지 않아 인증이 되지 않은 계정으로 로그인이 필요한 페이지에 접근을 할 때에는 서버에서 401 Error를 내곤 합니다.
또한 잘못된 접근을 시도했을 땐 403 Error를 내곤 합니다.
그 외에도 도메인 특성에 따라 사전에 조율이 되어있는 에러가 있을 수 있습니다.
-
의도 되지 않은 에러(예상하지 못한 에러):
서버에서 내는 500대의 error는 의도 되지 않은 에러라 판단할 수 있습니다.
언제 어디서 나타날지도 모르고 어느 부분에서 일지 예측 불가능하기 때문입니다.
그리고 사용자의 네트워크 환경에 따라 발생할 수 있는 에러, 사용자의 브라우저 환경에서 발생할 수 있는 에러는 예측하기 어렵기 때문에 의도 되지 않은(예측할 수 없는 에러)로 분리할 수 있습니다.
-
사용자가 해결할 수 있는 에러:
만약 로그인이 필요한 페이지에 로그인이 되지 않은 상태에서 접근을 하게 되었다면 사용자는 401 과 관련된 에러를 마주할 것입니다. 이때는 로그인을 함으로 해당 에러를 처리할 수 있을 것입니다.
또한 네트워크가 좋지 않은 것에 대한 이슈라면 네트워크 설정을 확인한다 등으로 사용자의 액션을 통해 에러가 해결 가능할 수 있습니다.
-
사용자가 해결할 수 없는 에러:
그러나 사용자에게 어떤한 에러 상황인지를 말해주어도 액션을 취할 수 없는 경우가 있습니다.
사용자가 사용하는 기기에서는 지원하지 않는 상황 혹은 더 이상 해당 기능을 제공하지 않는 경우 등이 있을 것입니다.
출처: https://www.jbee.io/articles/react/클라이언트의 사용자 중심 예외 처리
위의 사진이 앞서 설명한 에러의 경우에 대해서 보기 좋게 표현하고 있습니다.
2) 어떤 방식으로 사용자에게 친절한 에러를 표현할 수 있을까요?
-
예상할 수 없고, 해결 방법이 있는 에러
예시로 네트워크 에러의 경우를 들 수 있습니다.
이의 경우 네트워크 환경을 확인하라는 안내 문구를 제시하는 방향으로 사용자의 에러에 대한 원인과 액션을 제안할 수 있습니다.
-
예상할 수 없고, 해결 방법이 없는 에러
이 부분은 개발 단계에서 꼼꼼히 체크하여 사용자가 위와 같은 에러를 직면하지 않게 하는 것이 제일 좋은 대응법일 것입니다.
그럼에도 불구하고 위와 같은 에러를 사용자가 보았을 경우에는 고객 센터 및 문의 채널 진입로를 안내하는 액션을 취할 수 있을 것입니다.
-
예상할 수 있고, 해결 방법이 있는 에러
이는 기획 파트에서 설계된 부분일 것입니다.
위의 경우에는 에러의 경우에 맞게 설계된 로직을 따르면 될 것입니다.
-로그인 필요한 401 ⇒ 로그인 페이지로 이동
-잘못된 페이지 접근 404 ⇒ 메인 혹은 랜딩 페이지로 이동
-
예상할 수 있고, 해결 방법이 없는 에러
예상은 할 수 있지만 해결할 방법이 없다는 것은 기획 개발단에서 놓친 에러가 있다는 것이라 할 수 있습니다. 혹은 사용자가 고의적으로 비정상적인 접근을 한 경우로도 파악할 수 있습니다. 따라서 해당 에러는 보안상의 허점 및 에러 경우의 수를 보완해야 할 것입니다.
출처: https://www.jbee.io/articles/react/클라이언트의 사용자 중심 예외 처리
3) 우리 서비스에 어떤 식으로 녹여볼 수 있을까요?
Koin(코인)으로 예시를 들어보겠습니다.
- 버스/교통 PART 만약 버스/교통 부분에서 API의 500 ERROR가 오고 있는 경우에 어떤 식으로 위 방법을 활용할 수 있을까요? 제 생각에는 이는 예상하지 못한 그리고 사용자가 해결하지 못하는 에러일 것입니다. 따라서 서버 error가 오는 API를 활용하는 부분에 Error Boundaries 등을 활용하여 “서버에 에러가 발생하였다 빠르게 수정하겠다.”라는 내용을 담은 안내 문구를 띄우는 방식으로 보다 사용자에게 확실한 전달을 할 수 있을 것이라고 판단됩니다.
- 시간표 PART 만약 시간표에 새로운 기능이 추가되었다는 가정을 해봅시다. 그러나 해당 기능에서는 무조건 적인 회원만 접근 가능하다는 기획입니다. 이 경우에 로그인을 하지 않은 사용자가 해당 페이지 혹은 기능에 접근하려고 하였다면 이는 예상 가능한, 사용자가 해결 가능한 에러일 것입니다. 따라서 접근을 하였을 때 로그인이 필요한 기능이다. 로그인 혹은 회원가입을 해라. 와 같은 플로우로 사용자를 유도하는 액션이 필요할 것입니다.
요약
- 에러를 크게 분류하자면 아래와 같다. 1) 의도가 된 에러(예상 가능한 에러) 2) 의도가 되지 않은 에러(예상하지 못한 에러) 3) 사용자가 해결할 수 있는 에러 4) 사용자가 해결하지 못하는 에러
- 각각의 에러 상황에 맞게 적절한 사용자의 액션 유도가 필요하다.
참고 글 (아래 글을 참고하여 작성했습니다.)
