데이터 가져오기와 상태

학습 목표

요청은 했는데 화면이 기대와 다를 때를 줄이기 위해, 상태와 갱신 정책을 먼저 설계합니다.

API 연동을 상태 머신으로 보는 기본 패턴

API 요청은 “요청 흐름이 분기하는 상태계”로 모델링하면 가장 일관되게 설명됩니다.

핵심 상태의 의미는 다음과 같습니다.

• Idle: 아직 요청을 시작하지 않은 구간
• Loading: 요청 중이므로 데이터 기반 렌더를 확정할 수 없는 구간
• Success: 데이터가 존재해 렌더를 확정할 수 있는 구간
• Empty: 데이터가 비어 있으나 계약은 유효한 구간
• Error: 실패가 발생했고 화면 분기가 필요한 구간

이 다이어그램의 목적은 성공/실패를 “조건문 분기”가 아니라 “전이 규칙”으로 본다는 점입니다.

렌더링과 상태 전이의 정합성

렌더는 상태 기계의 어떤 상태에서 어떤 화면을 내보낼지에 대한 함축입니다.

• Idle/Loading: 초기 구조와 대기/로딩 표상을 준비
• Success: 실제 데이터 기반 렌더
• Empty: 데이터가 없는 합법적 화면
• Error: 재시도/복구 동선으로 분기

여기서 중요한 점은 같은 상태가 여러 경로에서 들어와도, 같은 렌더로 귀결된다는 점입니다. 즉, 요청 실패/캐시 miss/취소처럼 원인이 달라도 렌더가 같다면 UI는 일관됩니다.

API 상태 전이에서 자주 쓰는 확장 상태

기본 5상태를 시작점으로 두고 필요시 경계를 세분화합니다.

• revalidate: 기존 데이터를 보여주면서 배경에서 새로고침만 수행하는 상태
• invalidating: 무효화가 예약되어 캐시를 갱신해야 할 상태
• cancelled: 요청 자체가 취소된 상태

확장은 렌더 영향도를 기준으로 둡니다. 예를 들어 revalidate는 화면이 “지금 당장 빈 화면”이 되는지와 다르게, 현재 뷰를 유지한 채 최신성만 갱신한다는 차이가 생깁니다.

이 분리는 TanStack Query 같은 라이브러리 개념(캐시, stale, refetch)와 형태가 일치합니다.

요청 처리에서 데이터 계약을 고정하는 이유

상태 기계만으로는 화면이 일관돼도, 응답 모양이 달라지면 분기가 깨집니다. 요청 계약, 응답 계약이 동일한 상태 기계 위에서 해석되어야 합니다.

• Loading은 계약 유효성 검증 이전의 상태
• Success/Empty는 정상 계약이 파싱된 상태
• Error는 응답 계약 실패 또는 네트워크 실패로 분기된 상태

이 세 층을 분리하면, “렌더가 느린지”, “요청 정책이 안 맞는지”를 같은 구조로 추적할 수 있습니다.

최소 체크리스트

• idle/loading/success/error와 같이 핵심 상태가 실제 코드에서 구분되나요?
• 에러를 화면 동선으로 바로 번역하고 있나요?
• 중복 요청을 흡수/취소할 규칙이 상태 전이에 반영되나요?
• 캐시 키/무효화 규칙이 상태 전이와 결합돼 있나요?

다음 문서

렌더링 전략(CSR/SSR/SSG)