서버 컴포넌트 & 스트리밍 렌더링 — 렌더링이 다시 서버로 돌아온다

렌더링을 어디서 할 것인가. 웹 개발의 무게중심이 지난 몇 년간 브라우저 쪽으로 한껏 쏠렸다가, 다시 서버 쪽으로 돌아오고 있다. 그 흐름의 한복판에 서버 컴포넌트와 스트리밍 렌더링이 있다. 최신 프레임워크들이 기본 아키텍처로 삼기 시작하면서, 이제는 알아 두지 않으면 대화가 안 되는 개념이 됐다.

서버 컴포넌트는 브라우저로 자바스크립트를 내려보내지 않고 서버에서만 실행돼 결과 마크업을 만드는 컴포넌트다. 스트리밍은 그 결과를 한 번에 완성해 보내는 대신, 준비된 조각부터 순서대로 흘려보내는 방식이다. 둘이 합쳐지면 사용자는 페이지의 뼈대를 아주 빨리 보고, 무거운 부분은 채워지는 걸 지켜보게 된다.

왜 다시 서버인가

한동안의 정석은 "서버는 데이터만 주고, 화면은 브라우저가 그린다"였다. 이 방식은 풍부한 상호작용을 만들기에 좋았지만 대가가 따랐다. 화면을 그리는 데 필요한 코드와 라이브러리를 전부 브라우저로 내려보내야 했고, 그 양이 늘수록 첫 화면이 늦게 떴다. 사용자는 다운로드가 끝나고 실행이 완료될 때까지 빈 화면이나 로딩 스피너를 봐야 했다.

서버 컴포넌트는 여기에 질문을 던진다. "화면을 그리는 로직 전부가 정말 브라우저에 있어야 하나?" 상당수는 아니다. 데이터를 조회해 목록을 만들고 마크업으로 정리하는 일은 서버에서 끝내고 결과만 보내면 된다. 그 컴포넌트를 구성하던 라이브러리는 브라우저로 갈 이유가 없다. 클릭하고 입력받는 진짜 상호작용 부분만 클라이언트 몫으로 남긴다.

경계를 명시한다

이 모델의 핵심은 경계를 코드에 분명히 새긴다는 데 있다. 어떤 컴포넌트는 서버 전용, 어떤 컴포넌트는 클라이언트에서 상호작용을 담당. 이 구분이 명확해지면 번들에 무엇이 들어가고 무엇이 빠지는지가 예측 가능해진다. 나는 이 명시성이 성능만큼이나 중요한 이득이라고 본다. 그동안 "이 라이브러리가 왜 브라우저 번들에 들어왔지?"를 추적하느라 쓴 시간이 얼마였던가.

스트리밍이 더하는 것

서버에서 그린다고 해서 느린 데이터까지 기다렸다가 한 번에 보내면 의미가 없다. 스트리밍은 이 문제를 푼다. 페이지를 하나의 덩어리가 아니라 여러 조각으로 보고, 빨리 준비되는 뼈대와 헤더부터 먼저 흘려보낸다. 데이터가 오래 걸리는 영역은 자리만 잡아 두는 표시를 먼저 보내고, 준비되는 대로 그 자리를 채운다.

<Suspense fallback={<Skeleton />}>
  <SlowData />  {/* 준비되면 스트리밍으로 채워짐 */}
</Suspense>

사용자 입장에서는 페이지가 텅 빈 채 오래 멈춰 있다가 갑자기 나타나는 게 아니라, 위에서부터 점점 채워지며 살아나는 경험을 한다. 실제 총 로딩 시간이 같더라도 체감은 크게 다르다.

정리된 역할 분담

현실적 한계와 전망

새 모델인 만큼 배울 것도 많다. 서버와 클라이언트의 경계가 코드 곳곳에 생기면서, 어떤 값이 어디서 살아 있는지에 대한 감각을 새로 익혀야 한다. 서버 컴포넌트에서는 브라우저 전용 기능을 쓸 수 없고, 반대로 클라이언트 컴포넌트에 서버 자원을 직접 끌어오면 안 된다. 초기엔 이 경계를 헷갈려 실수하기 쉽다.

또 이 아키텍처는 서버 인프라를 전제한다. 완전 정적 배포만 하던 팀에게는 운영 부담이 새로 생긴다. 그럼에도 큰 방향은 분명하다. "전부 서버" 또는 "전부 클라이언트"라는 이분법에서 벗어나, 각 로직을 가장 알맞은 곳에서 실행하자는 실용주의로 업계가 움직이고 있다. 나는 이 균형점 찾기가 한동안 프런트엔드의 주된 이야깃거리가 될 거라 본다.

자주 묻는 질문

서버 컴포넌트는 예전의 서버 렌더링과 뭐가 다른가요?

전통적 서버 렌더링은 첫 화면 HTML을 서버에서 만든 뒤 브라우저에서 다시 활성화하며 같은 코드를 양쪽에 보냈다. 서버 컴포넌트는 아예 브라우저로 코드를 보내지 않고 서버에서만 실행돼 번들 자체를 줄인다는 점이 핵심 차이다.

모든 컴포넌트를 서버 컴포넌트로 만들면 되나요?

아니다. 클릭, 입력, 실시간 상태처럼 상호작용이 필요한 부분은 브라우저에서 실행돼야 한다. 데이터에 가까운 부분은 서버, 상호작용에 가까운 부분은 클라이언트로 나누는 균형이 핵심이다.

스트리밍이 전체 로딩 시간을 줄여 주나요?

총 처리 시간 자체를 줄이기보다 체감 속도를 개선하는 쪽에 가깝다. 준비된 부분부터 먼저 보여 주므로 사용자가 빈 화면을 응시하는 시간이 줄어든다.

정적 사이트만 배포하던 팀도 도입할 수 있나요?

이 모델은 요청 시점에 코드를 실행할 서버 환경을 전제하므로 완전 정적 배포와는 결이 다르다. 다만 많은 프레임워크가 정적 렌더링과 서버 렌더링을 섞어 쓰도록 지원하니 필요한 경로에만 점진적으로 적용할 수 있다.