brunch

You can make anything
by writing

C.S.Lewis

by 채은 Jun 02. 2024

가장 흔한 서비스 오류/예외케이스

PM의 별책부록 005

하나의 서비스에는 여러가지 유즈케이스에 대한 시나리오가 필요하다.

회원일 때, 비회원일 때, 이력이 있을 때, 없을 때 등… 동시에 발생 가능한 오류의 가짓수도 늘어난다.

지금 수강하고 있는 PM EXPORT 수업의 멘토님께 이런 다양한 유즈케이스들을 빼먹지 않으려면 어떻게 해야하냐고 여쭤보았는데, 역시나 센스와 경험이 필요하다고 말씀하셨다.


아직 경험이 부족한 나로서는 내 감각에 기대기보다는 나만의 리스트를 만들어두는 게 좋을 것 같아서

오늘은 미리 알고 대응해두면 좋은 가장 흔한 오류와 예외케이스들을 알아보려고 한다.


404 밈


HTTP 오류 케이스

(참조 : 도서 [파이썬 웹 프로그래밍, 기초편])


우선 HTTP는 웹 서버와 웹 클라이언트 사이에서 데이터를 주고받기 위해 사용하는 통신 방식이며, TCP/IP 프로토콜 위에서 동작한다.

웹 클라이언트가 웹 서버에 HTTP 요청 메시지를 보내면, 웹 서버는 요청에 따른 처리를 진행한 후에 그 결과를 웹 클라이언트에 HTTP 응답 메시지로 보낸다.

이 때 처리 결과를 세자릿수의 상태 코드(status code)로 나타내는데, 오류에 대한 상태도 동일하게 나타난다.


따라서 상태 코드의 패턴을 알면 쉽게 오류가 일어난 지점을 파악할 수 있다.

물론 상태코드가 상세하게 ‘어떤 지점’에서 오류가 일어났는지 노티해주지만, 우리가 모든 코드 케이스를 다 외울 수는 없으니 더 자세히 알고 싶을 때는 그럴 때면 gpt나 검색을 사용하자 :)   



1XX: Informational(정보 제공)

오류가 아닌 임시 응답 상태. 현재 클라이언트의 요청까지 처리된 상태이며 계속 진행 가능함


2XX: Success(성공)     

오류 아님. 클라이언트의 요청이 서버에서 성공적으로 처리되었다는 의미.  


3XX: Redirection(리다이렉션)   

완전한 처리를 위해서 추가 동작이 필요한 경우.

주로 서버의 주소 또는 요청한 URI의 웹 문서가 이동되었으니 이동된 주소로 다시 시도하라는 의미.  


4XX: Client Error(클라이언트 에러)

없는 페이지를 요청하는 등 클라이언트의 요청 메시지 내용이 잘못된 경우를 의미.

흔히 접하는 404 오류 케이스에 여기에 해당.  


5XX: Server Error(서버 에러)

서버 사정으로 메시지 처리에 문제가 발생한 경우.

서버의 부하, DB 처리 과정 오류 등이 주요 이슈.  




APP내 오류 및 예외 케이스

( 출처 : 패스트캠퍼스 ‘PMPO EXPORT’ )


오류 케이스를 예측할 수 있다면, 일어나지 않도록 예방하고 일어났을 때를 위한 대응책도 함께 마련하면 좋다.

흔한 사례들을 바탕으로 예방과 대응책을 미리 리스팅해보자!

내친 김에 다른 서비스들은 어떻게 대응하고 있는지 레퍼런스도 찾아보았다.



1. Empty 케이스 - 조회하려는 값이 0 혹은 null일 때

신규 진입자가 주로 겪게 되는 케이스이기에, 미리 Place Holder 준비하여 사용자에게 넛지를 줄 수 있음

image가 없을 때는 더미 이미지 노출  


좌측부터 필라이즈 / 사람인 / Flo의 Place Holder. 빈 화면을 노출하지 않고, 다음 행동을 유도하는 은근한 넛징



2. 서버 혹은 API 호출 실패

실패 경험으로 인한 이탈이 없도록, 사용자에게 케이스별로 ‘정확한 액션’를 지시해주어야 함  

좌측부터 호갱노노 / 배민 / 토스뱅크의 에러메세지. 정확한 오류의 원인을 알려주어 다음 액션에서 오류가 일어날 가능성을 줄여준다



3. Url 직접 입력으로 진입

회원로그인 상태, 비로그인 상태, 비회원 진입 등의 유즈케이스별 플로우를 미리 설계해 놓아야 오류로 연결되지 않고 이탈율도 줄일 수 있음

회원 로그인 → 페이지 정상 노출 
회원 비로그인 → 로그인 프로세스로 링크
비회원 → 회원가입 프로세스로 링크
직접 그려본 간단한 Flow... 접속만 해도 상당히 복잡하다



4. OS 별 대응

iOS와 안드로이드의 알림 표시, 권한 허용, API호출 등의 방식을 미리 이해한 상태로 기획해야 함  



5. PC/Mobile 반응형 대응

PC와 Mobile에서 가능/불가능한 피쳐들에 대한 분류 필요

반응형 대응 별 레이아웃이 깨지거나 정상 작동되지 않는 부분이 있는지 QA단계에서 꼼꼼히 확인해야 함  




마무리 >

이밖에도 상상을 초월한 다양한 오류와 예외들이 나타나는게 서비스기획의 세계인 것 같다!

계속 나만의 리스트를 늘려가며 내가 예방하고 대응할 수 있는 저변도 넓혀나가야지 :)


투비컨티뉴!

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari