가장 비싼 것은 버그가 아니라, 오류 메시지가 문제 해결 방향을 잘못 이끄는 경우입니다.
백엔드에서 이틀간 「서버 데이터를 읽을 수 없음」 경고가 발생했지만, 서비스 측 전체를 점검해도 로그에는 전부 200만 있었습니다. 진짜 원인은 브라우저에서 구 버전 스크립트가 실행 중이었고, 새 데이터를 렌더링할 때 충돌한 것입니다. 그러나 catch 모든 예외를 「서버 데이터를 읽을 수 없음」으로 통합 분류했습니다. 이 도구는 두 가지 작업을 수행합니다: 기존 catch 블록을 붙여넣어 장애 위장 여부를 검사하고, 명확히 구분된네트워크 실패 / 렌더링 충돌 / 인증 키 만료 / 타임아웃의 코드입니다.
—
| 실제 상황 | 보고해야 할 사항 | 오류 보고의 비용 |
|---|---|---|
| 네트워크/연결 실패 | 네트워크가 불안정합니다. N회 재시도했으며, 우선 로컬 캐시를 표시합니다. | 서버 오류로 보고 → 서버 측을 헛수고해서 확인합니다. |
| 데이터는 도착했지만 렌더링이 실패했습니다 | 스크립트 버전이 만료되었습니다. Ctrl+F5로 강제 새로 고침하세요. | 서버 장애로 오인됨 → 방향을 이틀간 잘못 잡았습니다 |
| 401 / 403 | 키가 만료되었습니다. 페이지를 새로 고쳐 다시 로그인하세요. | 사용자가 계속 재시도 버튼을 클릭해도 문제는 해결되지 않습니다. |
| 시간 초과(AbortError) | API 타임아웃입니다. 잠시 후 새로 고침하여 다시 시도하세요. | 「서버 다운」과 혼동합니다. |
| 데이터 형식이 빈 값 / 필드 누락 | 데이터는 도착했으나 필드 X가 누락되었습니다. | 오류 대신 0으로 조용히 렌더링하는 것이 오류 보고보다 더 위험합니다. |
1 · 하나의 catch 문으로 모든 오류를 보고합니다.렌더링 충돌, 네트워크 실패, 키 만료, 타임아웃 등이 모두 「서버 데이터를 읽을 수 없음」으로 분류되어, 이틀간 서버에서 존재하지 않는 문제를 찾았습니다.
2 · 수정 방식은 트래픽 분산이며, 로그 추가가 아닙니다.try 에서 데이터 조회만 수행하고, 렌더링은 별도 레이어로 감쌉니다. try두 문장을 별도로 보고하세요—문제 해결 방향은 한 문장으로 즉시 결정할 수 있습니다.
3 · 오류 보고보다 대체 처리가 더 중요합니다.완전한 실패 시 이전 정상 데이터를 localStorage에서 사용해 렌더링하고, 「캐시 데이터 · N 분 전」으로 표시합니다. 사용자는 오류 화면 대신 항상 콘텐츠를 볼 수 있습니다.
4 · 401/403 응답은 재시도하지 마세요.잘못된 키로 인해 재시도를 세 번 하더라도 사용자에게 불필요한 대기 시간만 늘릴 뿐이며, 바로 새로 고침 후 재로그인하라고 안내하세요.