이번 여름을 불태웠던 백호 웹 개발...🔥🔥
혼자서 계속 웹을 공부해왔지만 제대로 팀원들과 프론트엔드로 협업해본 적은 이번이 처음이다. 자세한 회고와 트러블슈팅 내용은 추후 따로 적어보기로 하고, 여기에는 에러 처리 관련 핸들링 내용만 모아봤다
1. 서버 500 에러 원인 파악하기
나는 이번 백호 웹 개발에서 상세페이지 작업을 주로 맡아서 했는데, 원인을 알 수 없는 서버 500 에러를 발견했다.
500 에러가 터지면 보통 서버 측의 문제로 생각할 수도 있는데 이번에는 아니었다. 백엔드 팀원 분과 같이 디버깅을 해보면서 원인 두 가지를 찾았다.
⚠️ 오류 1: 워크스페이스 전체 팀 목록 페이지에서 연결되는 상세페이지 경로 오류로 인한 500 에러
- 목록 페이지에서 개별 상세페이지로 navigate하는 경로에 (실제로는 없는)세그먼트가 포함되어있었다.
- 위 문제로 서버에서 500 에러를 반환한 것으로 보여, 경로를 제대로 수정했더니 오류가 사라졌다.
⚠️ 오류 2: 조회 시 호출하는 api 엔드포인트 오류
- 상세페이지의 헤더 컴포넌트에서 호출된 "헤더명 조회" API 함수에서 호출하는 api의 엔드포인트가 실제 개발용 스웨거 문서상의 엔드포인트와 다른 점을 찾았다.
- 엔드포인트를 스웨거와 동일하게 통일하니 오류가 해결 되었다.
그리고 개발 과정에서 발생하는 여러 에러들의 원인을 파악하고 해결하면서 깨달은 점: 생각보다 내 쪽의 처리로 해결 가능한 에러들이 많다... 에러가 뜨면 http 상태코드는 뭔지, 관련 에러가 코드 어디 부분에서 나는 건지 면밀히 뜯어보고 직접 생각해보는 습관을 가지자. ㅜㅜ
2. 에러페이지 상태코드 처리 수정
우리 팀은 서버 에러가 발생하는 경우를 대비해 서버 에러 페이지를 만들고 연결해뒀다. 그런데 문제는, 404, 400 에러 등 500 에러가 아닌 상황에서도 Server500Error.tsx가 화면에 나타나고, 에러 상태별 핸들링이 부족하다는 점이었다.
따라서 해당 에러 페이지에서 500 문구를 삭제하고, http 상태코드를 추출하여 화면에 에러메시지를 렌더링하는 방식으로 수정해보았다.
(1)isAxiosError 타입 가드를 통해 AxiosError인지 안전하게 확인하도록 코드 추가
// AxiosError인지 확인
const isAxiosError = (err: unknown): err is AxiosError => {
return (err as AxiosError)?.isAxiosError === true;
};(2) http 상태코드 추출하는 방식을 사용하여 각 경우별로 에러메시지를 다르게 렌더링하도록 수정
// 상태 코드 추출
const statusCode = isAxiosError(error) ? error.response?.status : null;
const getErrorMessage = () => {
switch (statusCode) {
case 400:
return '잘못된 요청입니다.';
case 401:
return '인증되지 않은 사용자입니다.';
case 403:
return '접근이 거부되었습니다.';
case 404:
return '요청한 리소스를 찾을 수 없습니다.';
case 500:
return '서버 오류가 발생했습니다.';
default:
return '알 수 없는 오류가 발생했습니다.';
}
};{/* 에러 문구 */}
<div className="flex flex-col gap-[3.2rem] text-center">
<h2 className="font-bigtitle-b text-gray-600">
{statusCode ? `${statusCode} Error` : 'Error'}
</h2>
<h3 className="font-title-sub-r text-gray-600">
{getErrorMessage()}
<br /> 잠시 후 다시 시도해 주세요!
</h3>
</div>해당 처리를 하니, 에러 상태별로 다르게 에러메시지가 출력되는 것을 볼 수 있다:
.
.
.
프로젝트를 진행하면서 느끼는 거지만, 개발하면서 어떤 에러가 나는지, 데이터가 어떻게 들어오고 있는지 console 찍어보고, 네트워크 탭을 확인하면서 수시로 체크하는 과정은 너무 중요한 것 같다.
그런 점에서 어떤 에러가 발생하는지 체크할 수 있도록 구체적인 클라이언트 처리를 해주는 것은 해당 웹사이트를 보게 될 사용자에게도, 에러 디버깅을 하며 개선해나가야 할 개발자 본인에게도 중요할 것이다!
