상용 서비스 script, API 오류 처리 개선 작업 회고. 이렇게나 오류가 많았다고?

오류 모니터링을 위해

을 도입하고,

을 살펴봤을 때 깜짝 놀랐다.

심지어 setInterval에서 동작하는 스크립트에 오류가 나서 clear가 제대로 되지 않아 오류가 interval 시간마다 찍히는 부분도 있었다. API 오류 처리는 컴포넌트에서 제각각 처리하고 있어 관리가 되지 않는 상태였는데, 400대의 오류를 500 status로 보내는 API도 있었다.

Script Error + API Fallback + Server Error 의 총체적 난국 상황에서 데이터독 모니터링을 통해 오류를 수정하고 API 오류 처리를 개선한 경험에 대한 이야기다.

source map 설정이 가능하다면 이 부분의 수정은 쉽다. 어떤 코드에서 무슨 오류가 발생했는지 금방 파악할 수 있기 때문이다. 대개 수정은 방어 코드를 추가하거나 예외 처리를 추가하는 등으로 실제 작성할 코드의 양은 적은 편이다. 해당 오류가 야기되는 일반적인 상황을 정리해보면 다음과 같다.

try~catch는 기본이고, 특히

문법만 잘 적용해주어도 오류 발생을 많이 낮출 수 있는 코드들이 꽤 많았다.

서버와 API 통신을 하는 과정에서도 충분히 오류가 발생할 수 있다. 사용자의 네트워크 환경 때문일 수도, 서버의 로직 때문일 수도, 클라우드 서비스의 장애일 수도 있다. 해당 오류에 맞는 적절한

를 사용하여 오류를 구분하여 처리할 수 있다.

주로 사용자 단에서 잘못된 요청으로 발생한 오류, 즉 서버에서 예측이 가능한 오류의 경우에는 400번대 상태를 사용하며 예기치 못한 오류의 경우 500번대 상태를 사용한다.

자주 사용되는 상태값으로는 다음과 같다.

기존의 핸들링 방식은 API를 호출한 컴포넌트 단에서 포괄하여 처리하거나 필요 시 status를 확인한 후 처리를 하는데 모두 제각각이었다. 이를 개선하기 위한 구조를 고민해봤다. API 오류를 catch할 수 있는 곳은 크게 세 곳이었다.

이 세 곳에서 어떻게 오류 처리를 어떻게 분담할 지 고민하며 개발팀 내 의견도 요청한 결과 다음과 같이 정리되었다.

데이터독 로깅 라이브러리를 사용할 경우 별도의 로그 서비스를 통해 보다 편하게 모니터링 할 수 있다. 400대와 같이 예상 가능하고, 대비가 되어 있는 오류들에 대해서는

으로 처리했다.

status를 일반적으로 처리할 경우, API 기능에 따라 다른 메시지를 보여주는 등의 처리는 불가능하지만 개발팀과의 논의 결과 그렇게까지 처리하기보다는 각 모듈 별 기능을 온전히 위임하는 게 더 나은 방향인 것으로 이야기 되었다.

기존 서버 로직에서 오류가 발생할 경우 status 처리가 명확하지 않고 작업자에 따라 다르게 처리되고 있었다. 이에 대해 프론트에서 오류를 핸들링하는 구조를 설명드리며 오류 처리에 대한 얼라인을 함께 맞췄다.

레거시로 기존 400대 오류를 오류 문구와 함께 500으로 반환하는 API가 몇 개 확인되는데, 우선 이에 대응하기 위해 500 fallback 함수에서 서버에서 전달해준 문구가 있을 경우 이를 최우선으로 노출하도록 처리하였으며 서버 개발자 분들에게 수정 요청을 드렸다.

프론트에서 오류 처리를 개선할수록 서버 오류도 발견하기가 쉬워지는 것이다.

이게 최선이고 좋은 방향인가? 에 대한 질문에 아직 확신을 담아 대답할 수는 없다. 다만 확실한 것은 이 과정을 통해 나는 오류 전파와 핸들링에 대한 고민을 많이 하게 됐으며, 기존의 오류들을 많이 해결했고, 오류 처리를 동일하게 관리하는 걸 적용하고, 백엔드 개발자 분들과 오류 처리에 대한 논의를 나누었다는 점이다. VoC로 서비스 중 발생하는 오류로 인해 서비스의 신뢰가 떨어진다는 내용이 발생하고 있는데 계속 더 나아져서 예기치 못한 오류에도 사용자 경험을 크게 해치지 않는 서비스가 되어가면 좋겠다.