에러 바운더리 범위

[sgoldenbird]

🐞 문제 상황 (Problem Description)

기존에는 React 앱 내 에러를 한 곳에서만 처리하거나 try-catch 또는 단일 ErrorBoundary로 감싸는 방식만 사용하고 있었다.
그러다 보니 API 통신 오류, 렌더링 오류, 예상치 못한 전역 오류가 모두 동일한 UI로 처리되어
사용자에게 불친절한 경험을 주거나, 디버깅이 어려운 문제가 있었다.

---

💻 환경 정보 (Environment)

• 브라우저: Chrome 123
• 프론트엔드 프레임워크: React 19, Vite 사용
• 배포 환경: 배포 전
• API 서버: fandom-k-api.vercel.app(외부 REST API, 수정 불가)

---

🔍 발생 원인 분석 (Investigation)

• 하나의 에러 처리 방식으로는 오류의 종류나 발생 위치에 따라 다른 대응이 어려움
• 예를 들어:
  • API 호출 실패 → 사용자에게 서버 오류 안내 필요
  • 컴포넌트 렌더 중 오류 → 해당 영역만 안전하게 fallback UI 제공
  • 라우터 경로 전반에 걸친 예외 → 앱 전체 수준에서 오류 처리 필요
• 이를 분리하지 않으면 에러 발생 위치에 상관없이 전역 fallback만 보여지는 문제 발생

---

🛠 시도해본 해결 방법 (Attempts)

시도 내용	결과
❌ 단일 ErrorBoundary로 전체 앱 감싸기	에러 발생 위치 구분 불가, 사용자에게 일관되지 않은 UX
✅ GlobalErrorBoundary 구성	라우터 루트 레벨에서 전체 앱 오류를 처리하도록 설정
✅ ApiErrorBoundary 구성	API 로딩/요청에 대한 오류만 분리해 안내 가능
✅ RenderErrorBoundary 구성	각 컴포넌트 렌더링 오류만 지역적으로 감지해 처리 가능

---

✅ 최종 해결 방법 (Final Solution)

#176 #177

1. GlobalErrorBoundary

• 라우터 최상단에서 사용 (errorElement)
• 예: 경로 없음, 시스템 오류, 라우팅 실패 등 앱 전체 오류 대응

 createBrowserRouter([
   {
     path: '/',
     errorElement: <GlobalErrorBoundary />,
     children: [...]
   }
 ])

2. ApiErrorBoundary

• API 요청 중 발생하는 네트워크 오류 감지
• 주로 useEffect나 loader 내 API 요청 실패에 대응
• 내부에 fallback UI 및 다시시도 버튼 구성
• 특정 라우터단에서 사용 (errorElement)

3. RenderErrorBoundary

• 각 UI 컴포넌트 단위에서 렌더링 오류 감지
• 예: 데이터가 잘못되어 map이 실패하는 경우 등
• 클래스로 구현

---

💡 알게 된 점 (Lessons Learned)

• 에러는 성격과 위치에 따라 구분해서 대응하는 것이 중요하다.
• Global / API / Render 단위로 나누면 사용자에게 더 정확한 안내를 제공할 수 있고,개발자 입장에서도 문제 발생 원인을 빠르게 좁혀갈 수 있다.
• 특히 React Router와 API 로딩 흐름을 함께 사용할 때는 loader → 실패 → GlobalErrorBoundary 로 바로 빠지는 구조보단,
  API 단위로 ApiErrorBoundary를 적용해 사용자에게 다시시도 기회나 안내를 주는 것이 UX 관점에서도 효과적이다.
• 앞으로도 에러 처리는 단순히 잡는 것이 아니라, "구분하고 전달하고 복구할 수 있도록 설계"하는 것이라는 점을 명확히 인식하게 되었다.

---

📚 래퍼런스

• https://github.com/bvaughn/react-error-boundary
• https://fe-developers.kakaoent.com/2022/221110-error-boundary/