HTTP 상태 코드는 왜 프런트개발에 중요한가
빠른 성장을 목표로 하는 스타트업 또는 대형 프로젝트라면지켜야 하는룰
HTTP 상태 코드란?
상태 코드는 HTTP 요청에 대한 응답(Response)을 숫자로 표현한 값입니다. 대표적인 응답인 200은 정상 결과, 404의 경우 찾을 수 없음(Not Found), 500의 경우 서버 오류(Server Error)를 뜻합니다. 그런데 이 당연한 코드가 왜 중요하고 왜 꼼꼼히 관리돼야 할까요?
일관된 상태 처리
먼저 최악의 케이스를 살펴봅시다. 모든 응답을 대충 200으로 처리한다면 어떨까요? 구체적인 내용에 대해서는 body에 파라미터와 데이터를 넣어 전달하는 경우를 많이 보셨을 겁니다. 이 경우에 프런트엔드 코드에서는 다음과 같은 형태로 데이터에 접근할 겁니다.
하지만 이 코드는 엉망입니다. 많은 웹 개발자가 위와 같이 처리하는 것을 봤는데 이렇게 코드를 짜게 되면 다음과 같은 문제가 발생할 수 있습니다.
서버 응답이 정상적으로 돌아오지 않는 경우 response.data.message에 접근하지 못합니다. 서버가 제대로 된 응답을 보내지 못했기 때문에 data에 접근하지 못하고, 당연히 message라는 값에도 다다르지 못해 에러가 발생합니다. 즉 상태 처리에 대해 엉망이 됩니다.
웹 개발을 잘못 배운 개발자들은 여기서 두 번째 실수를 합니다. 바로 위의 코드를 try-catch로 묶어 버립니다.
이러면 어떤 문제가 발생할까요? 서버 응답에 대한 상태별 처리는 물 건너갑니다. 또한 try-catch의 스코프에 따라 그 안에서 발생하는 모든 에러를 퉁쳐버리는 일이 생깁니다. 서버에 이상이 생겨서 그런 건지 프런트엔드 코드의 문제로 발생한 에러던지 catch로 빠져버리기 때문에 제대로 된 에러 캐치를 할 수가 없습니다.
진짜 문제는 이런 패턴으로 코드를 구성한 회사입니다. 위의 코드 패턴을 사용한 회사들의 모든 프런트엔드 HTTP 요청 관련 코드는 끔찍한 try-catch로 모든 요청을 둘러쌓은걸 볼 수 있고, 에러 캐칭을 해도 404나 500에 대한 처리다 보니 이외의 경우에 대해 대처하려면 코드 패턴을 깨야합니다. 즉 깨끗하게 리팩터링 하기 위해선 프런트엔드뿐 아니라 백엔드까지 다 갈아엎어야 하는 일이 생깁니다.
"작은 프로젝트에서 급하면 그렇게 할 수도 있지 않나요? 아니면 status를 판단할 때 앞의 숫자 정도만 일치하면 되지 않나요?"
물론 그럴 수 있습니다. 큰 프로젝트가 아니라면 굳이 상태 코드를 나누지 않아도 대부분 정상적으로 돌아가게 할 수 있습니다. 하지만 큰 서비스로 성장을 목표로 하는 스타트업이나 시작부터 큰 프로젝트라면 상태 코드를 반드시 지켜서 개발을 하는 걸 추천합니다.
개발을 시작할 때부터 상태 처리에 대한 전역 함수를 만들어 상태별 콜백 관리를 해주는 겁니다. 처음에 조금 귀찮을 수 있지만 서비스 전체에서 상태 관리가 통일되기 때문에 난잡한 try-catch 문을 볼 필요도 없고, 완성도 높은 코드를 작성할 수 있습니다.
상태 코드를 확인하는 건 무척 쉽습니다. 검색해보면 각 상태 코드에 대해 자세히 설명해둔 글이 한두 개가 아닐뿐더러 실제 서비스에서 어떤 식으로 사용해야 하는지 가이드도 찾기 쉽습니다. 외우기 어려울 수도 있는데 가장 많이 쓰이는 코드 위주로 사용해보시면 실제 서비스에 적용하는 건 금방 적응이 되리라 생각합니다.
