에러 방어: 무한 재요청 방지, 빈 목록 처리

목차

1. 렌더링 전략 최종 선택: Streaming
2. 이미지 최적화: 이미지 용량 97% 감소
3. 무한 스크롤 구현 및 리렌더링 최적화
4. 에러 방어: 무한 재요청 방지, 빈 목록 처리 ← 현재 문서

이 단계의 목표

앞선 3단계에서 렌더링 전략, 이미지 최적화, 무한 스크롤 구현까지 마쳤지만, 네트워크 오류나 서버 장애 같은 예외 상황은 아직 대비되지 않았습니다.

오류가 발생했을 때 서비스가 안전하게 동작하고, 사용자에게 현재 상황을 명확히 안내하는 것이 이 단계의 목표입니다.

이 단계의 구현 코드는 GitHub에서 확인할 수 있습니다.

1. 다음 페이지 로딩 실패 시 무한 재요청 방지

문제 정의

스크롤 이벤트든 IntersectionObserver든, 무한 스크롤은 조건이 충족되면 자동으로 다음 페이지를 요청합니다. 다음 페이지 API가 실패하면 이 조건이 즉시 다시 충족되어, 짧은 시간 안에 fetchNextPage가 수십~수백 회 반복 호출될 수 있습니다. 무한 스크롤을 구현한다면 반드시 대비해야 하는 부분입니다.

fetchNextPage() → 500 실패
→ isFetchingNextPage: false (복귀)
→ hasNextPage: true (다음 페이지를 못 받았으니 여전히 true)
→ fetchNextPage() → 500 실패
→ (무한 반복)

왜 위험한가

이 무한 반복은 두 가지 측면에서 위험합니다.

1. 서버 부하 가중: 이미 장애가 발생한 서버에 수백 건의 요청이 추가로 몰리면, 장애가 더 악화될 수 있습니다. 단일 사용자의 브라우저가 서버에 DDoS와 유사한 효과를 만들어내는 셈입니다.
2. 사용자 경험 파괴: 사용자는 오류가 발생했다는 사실조차 인지하지 못한 채, 화면이 멈추거나 브라우저가 느려지는 현상만 겪게 됩니다.

해결

API 오류가 발생하면 두 가지를 처리합니다.

1. 추가 API 호출을 중단합니다. 모든 페이지를 다 불러왔을 때 더 이상 호출하지 않는 것처럼, 에러 발생 시에도 동일하게 중단합니다.
2. 사용자에게 게시글 목록을 더 불러오지 못했다는 안내를 표시합니다.

// useInfiniteScroll 훅 내부
const enabled = hasNextPage && !isFetchingNextPage && !isError;

에러 처리에 대한 보다 체계적인 접근 방식은 별도 문서에서 정리했습니다 — 에러 처리는 왜 필요한가?

2. 빈 게시글 목록

문제 정의

게시글이 0건일 때 빈 그리드만 보이면 사용자는 로딩이 덜 된 건지, 진짜 없는 건지 구분할 수 없습니다.

해결

"게시글이 없습니다." 메시지를 표시하여 현재 상태를 명확히 안내합니다.

이는 단순해 보이지만, 사용자가 시스템의 현재 상태를 정확히 인지할 수 있도록 돕는 중요한 처리입니다. 빈 화면은 "오류인지, 로딩 중인지, 정말 비어있는지" 세 가지 해석이 모두 가능하기 때문입니다.

결과 요약