장애허용성

재시도(Retry)는 일시적(transient) 오류에만 해야 한다. 영구적 오류를 재시도하면 서버 부하만 늘리고 사용자 대기 시간도 길어진다.

function isRetryable(err: AxiosError) {
  if (!err.response) return true; // network error
  const s = err.response.status;
  return s >= 500 || s === 408 || s === 429;
}

고정 간격 재시도는 서버가 다시 살아나는 순간 모든 클라이언트가 동시에 몰려 장애를 재발시킨다(thundering herd). 지수적으로 간격을 늘리고(Backoff) 난수 지연(Jitter)을 섞어야 한다.

async function retry<T>(fn: () => Promise<T>, max = 3) {
  for (let i = 0; i < max; i++) {
    try { return await fn(); }
    catch (e) {
      if (i === max - 1 || !isRetryable(e)) throw e;
      const base = 2 ** i * 1000;
      const jitter = Math.random() * base;
      await new Promise(r => setTimeout(r, base + jitter));
    }
  }
  throw new Error('unreachable');
}

서버가 내려간 것을 감지했는데도 계속 요청하면 사용자 대기 + 서버 회복 지연이라는 이중 손해를 본다. Circuit Breaker 는 일정 실패가 쌓이면 회로를 열어(Open) 일정 시간 동안 요청 자체를 보내지 않고 즉시 폴백으로 전환한다.

class Breaker {
  private failures = 0;
  private openedAt = 0;
  constructor(private threshold = 5, private cooldown = 10_000) {}
  async call<T>(fn: () => Promise<T>, fallback: () => T) {
    if (this.state() === 'OPEN') return fallback();
    try {
      const r = await fn();
      this.failures = 0;
      return r;
    } catch (e) {
      if (++this.failures >= this.threshold) this.openedAt = Date.now();
      return fallback();
    }
  }
  private state() {
    if (!this.openedAt) return 'CLOSED';
    return Date.now() - this.openedAt > this.cooldown ? 'HALF_OPEN' : 'OPEN';
  }
}

렌더 중 던져진 예외는 React 16+ 부터 가장 가까운 ErrorBoundary 에서만 잡힌다. 페이지 루트에만 두면 한 컴포넌트 오류로 전체 화면이 흰 페이지가 된다. 위젯 단위로 경계를 쪼개야 부분 실패가 가능하다.

<Page>
  <ErrorBoundary fallback={<HeroSkeleton />}>
    <Hero />
  </ErrorBoundary>
  <ErrorBoundary fallback={<p>추천을 불러오지 못했어요.</p>}>
    <Recommendations />
  </ErrorBoundary>
</Page>

주의: ErrorBoundary 는 렌더·lifecycle·생성자의 동기 오류만 잡는다. 다음은 스스로 처리해야 한다:

• 이벤트 핸들러 (onClick 내부 throw)
• 비동기 코드 (setTimeout, fetch().then)
• SSR 중 서버 측 오류 → Next.js error.tsx
• Promise rejection → react-error-boundary 의 useErrorBoundary().showBoundary(e)

페이지 이탈·타이핑 중인 자동완성처럼 결과가 이미 쓸모없어진 요청은 취소해야 좀비 응답으로 setState 경고와 UI 깜빡임이 안 생긴다. fetch 와 axios 모두 AbortController 를 지원한다.

useEffect(() => {
  const ac = new AbortController();
  fetch('/api/search?q=' + q, { signal: ac.signal })
    .then(r => r.json())
    .then(setResult)
    .catch(e => { if (e.name !== 'AbortError') setError(e); });
  return () => ac.abort();
}, [q]);

타임아웃도 같은 방식으로: setTimeout(() => ac.abort(), 3000). 사용자에게 무한 로딩 대신 빠른 실패 + Retry 버튼을 주는 것이 장애허용 UX다.

[감점 답변] "try/catch 로 감싸고 토스트 띄워요" 수준. 실패 종류를 구분하지 않음. [좋은 답변] 네 가지 층으로 나눠 답변: (1) 네트워크/전송 층 — AbortController 타임아웃, (2) 요청 단위 — Retry with Exponential Backoff + Jitter (5xx·timeout 만, GET/멱등 요청만), (3) 엔드포인트 단위 — Circuit Breaker 로 연속 실패 시 빠른 포기, (4) 렌더 층 — ErrorBoundary + 위젯별 Fallback UI. 트레이드오프로 Retry 는 서버 부하 증폭 위험, Circuit Breaker 는 오탐 시 정상 사용자 차단을 함께 언급.

[감점 답변] "비동기는 못 잡는다"까지만 말하고 끝. [좋은 답변] 못 잡는 것 4가지를 구체화: 이벤트 핸들러, setTimeout 등 비동기 콜백, Promise rejection, SSR 서버 오류, ErrorBoundary 자기 자신의 렌더 오류. 대응: 이벤트는 try/catch, 비동기는 React Query 같은 데이터 라이브러리의 onError 나 useErrorBoundary().showBoundary(e) 로 렌더 경계로 끌어올리기, Next 13+ 는 error.tsx. 또한 ErrorBoundary 는 클래스 컴포넌트만 가능하다는 점도 언급.

[감점 답변] "3번까지 재시도하면 돼요"로 끝. [좋은 답변] 세 가지 함정을 지적: (1) 비멱등 요청 (POST /orders) 재시도는 중복 처리 — Idempotency-Key 헤더로 방어, (2) 영구 오류(400·404) 재시도는 서버 부하만 증폭 — 5xx·네트워크 오류만 재시도, (3) 동기화된 재시도 는 thundering herd 유발 — Exponential Backoff + Jitter 필요. 추가로 429 는 Retry-After 헤더 존중, 최대 총 지연 시간을 설정해 UX 보호.

[감점 답변] 세 상태 이름만 나열. [좋은 답변] Closed/Open/Half-Open 을 전환 조건과 함께 설명: 실패 임계치 초과 시 Open, 쿨다운 경과 후 Half-Open 에서 샘플 요청으로 복구 테스트. 프런트 특유 고려 사항도 덧붙이기: 엔드포인트별 인스턴스(전역 1개면 다른 API까지 막힘), 메모리에만 저장(탭 새로고침 시 초기화), 서버리스/CDN 이 앞단에 있으면 같은 장애가 재현 안 될 수 있어 서버 사이드 Circuit Breaker 와 역할 분리.