6개월 동안 에러를 삼켜버렸다
내 에러 핸들링은 훌륭하다고 생각했다.
try/catch 블록을 사용했고, 콘솔에 로그를 남겼으며, Sentry 대시보드도 활용했다.
하지만 사용자들은 여전히 끊긴 흐름을 마주했다. 파일은 사라졌고, 결제는 확인 없이 진행되었으며, 양식은 아무런 알림 없이 실패했다.
문제는 에러를 잡지 못한 것이 아니었다. 에러를 잡고 나서 아무것도 하지 않은 것이 문제였다.
코드에는 이런 주석이 있었다: // TODO: 이 부분을 더 잘 처리할 것
그 주석은 6개월 동안 그 자리에 머물러 있었다.
업로드가 실패했을 때, 사용자는 멈추지 않는 로딩 스피너만 보게 되었다. 무엇이 잘못되었는지 전혀 알 수 없었다. 사용자는 계속해서 재시도했고, 결국 포기했다.
고객의 불만이 접수된 후 분석 데이터를 확인했다. 다음과 같은 수치를 발견했다:
• 파일 업로드의 23%가 아무런 알림 없이 실패했다. • 사용자는 평균 2.7회 재시도를 시도했다. • 모든 에러를 잡아냈기 때문에 우리의 대시보드는 '정상(healthy)' 상태를 나타내고 있었다.
우리는 조용한 재앙을 운영하고 있었다. 대시보드는 초록불이었지만, 사용자들은 좌절하고 있었다.
나는 모든 'silent catch'를 새로운 패턴으로 교체했다. 이제 에러를 유형별로 분류한다:
• 네트워크 에러는 재시도 대화 상자를 띄운다. • 권한 에러는 가이드를 보여준다. • 알 수 없는 에러는 명확한 메시지를 보여주고 컨텍스트를 로그로 남긴다.
결과는 모든 것을 바꾸어 놓았다:
• 알림 없는 업로드 실패율이 23%에서 0.4%로 급감했다. • 사용자가 보고하는 업로드 문제는 89% 감소했다. • 파일 누락에 관한 고객 지원 티켓이 주당 15건에서 1건으로 줄었다.
가장 큰 수확은 가시성(visibility)이었다. 우리 팀은 이제 실패를 즉시 알 수 있다. 화가 난 이메일을 기다릴 필요가 없다.
에러 핸들링은 크래시(crash)를 방지하는 것이 아니다. 실패를 사용자 및 팀에게 가시화하는 것이다.
크래시는 정직하다. 조용한 실패는 거짓말이다.
catch 블록을 작성할 때, 스스로에게 두 가지 질문을 던져라:
- 이것이 실패했을 때 누가 알아야 하는가?
- 그들은 다음에 무엇을 해야 하는가?
만약 답이 "아무도 없다"라면, 당신은 문제를 안고 있는 것이다.
Optional learning community: https://t.me/GyaanSetuAi