Suspense는 개별 컴포넌트의 로딩 상태를 우아하게 처리해주었지만, React Core Team의 야망은 거기서 멈추지 않았다. 그들의 다음 목표는 제3화에서 팀을 절망에 빠뜨렸던 바로 그 문제, ‘네트워크 폭포수(Network Waterfall)’를 근본적으로 해결하는 것이었다.
과거의 클라이언트 렌더링 방식에서는, 부모 컴포넌트가 렌더링되고 데이터를 가져와야만 자식 컴포넌트의 렌더링이 시작될 수 있었다. 모든 데이터 요청이 릴레이 경주처럼 순차적으로 일어났다.
// 부모 컴포넌트
function Parent() {
const { data: parentData } = useFetch('/api/parent'); // 1. 첫 번째 요청
if (!parentData) return <Spinner />;
return <Child id={parentData.childId} />;
}
// 자식 컴포넌트
function Child({ id }) {
const { data: childData } = useFetch(`/api/child/${id}`); // 2. 두 번째 요청
if (!childData) return <Spinner />;
return <div>{childData.name}</div>;
}
이 구조에서 Child 컴포넌트의 데이터 요청은 Parent의 요청이 완전히 끝난 뒤에야 시작될 수 있었다. 전체 로딩 시간은 두 요청 시간을 합한 것과 같았다.
“이건 말이 안 돼.”
앤드류 클라크는 회의실 화이트보드에 이 순차적인 흐름을 그리며 말했다.
“Parent를 렌더링하는 시점에, 우리는 곧 Child도 렌더링해야 한다는 사실을 이미 알고 있어. 그런데 왜 Child에게 필요한 데이터를 미리 가져오지 못하는 거지?”
문제의 원인은 명확했다. 렌더링과 데이터 페칭이 너무 강하게 묶여 있었기 때문이다.
하지만 서버 컴포넌트와 Suspense의 조합은 이 족쇄를 끊을 힘을 가지고 있었다. 서버 컴포넌트는 서버에서 실행되므로, 렌더링을 시작하기 전에 애플리케이션 전체에 필요한 데이터를 미리 파악하고 병렬적으로 요청하는 것이 가능했다.
React 팀은 이 개념을 실현하기 위해 렌더링 엔진의 동작 방식을 수정했다.
새로운 렌더러는 컴포넌트 트리를 훑어 내려가다가, 데이터가 필요한 컴포넌트를 만나면 일단 렌더링을 멈추지 않았다. 대신 ‘이 컴포넌트는 이 데이터가 필요하다’는 사실을 기록하고, 데이터 요청을 즉시 시작시킨 뒤 다음 컴포넌트로 넘어갔다.
Parent 컴포넌트를 렌더링하면서 /api/parent 요청을 시작하고, 곧바로 Child 컴포넌트를 만나 /api/child/... 요청을 시작하는 것이다. 두 개의 fetch 요청이 거의 동시에, 병렬적으로 네트워크를 향해 출발했다.
“우리는 렌더링과 데이터 요청의 시작점을 분리한 거야.”
세바스찬이 설명했다. “렌더링은 데이터가 모두 도착한 뒤에 시작해도 늦지 않아. 중요한 건, 필요한 데이터가 무엇인지 최대한 빨리 파악해서, 모든 요청을 가능한 한 동시에 시작하는 거지.”
그 결과는 극적이었다.
이전에는 폭포수처럼 순차적으로 떨어지던 네트워크 요청 막대그래프가, 이제는 출발선에 나란히 선 단거리 주자들처럼 동시에 시작되었다. 전체 데이터 로딩 시간은 더 이상 모든 요청 시간의 합이 아니었다. 가장 오래 걸리는 요청 하나가 끝나는 시간으로 단축되었다.
이것은 사용자 경험에 엄청난 차이를 만들었다. 페이지 로딩 시간은 눈에 띄게 줄었고, Suspense와 스트리밍 덕분에 사용자는 그 짧아진 시간 동안에도 유용한 콘텐츠를 먼저 볼 수 있었다.
개발자는 더 이상 데이터 의존성 순서를 최적화하기 위해 컴포넌트 구조를 비트는 고통스러운 작업을 할 필요가 없었다. 그저 필요한 데이터를 선언적으로 요청하기만 하면, React와 서버 컴포넌트 아키텍처가 알아서 가장 효율적인 방식으로 모든 요청을 병렬 처리해 주었다.
절망의 폭포수는 희망의 병렬 파이프라인으로 바뀌었다. React는 마침내 웹 개발의 가장 오래된 숙제 중 하나였던 네트워크 병목 현상을 정복할 강력한 해법을 손에 넣은 것이다.
