서버 컴포넌트의 개념이 구체화될수록, 팀 내외부에서 가장 많이 나오는 질문이 있었다. 그것은 마치 피할 수 없는 통과의례와도 같았다.
“그래서, 이게 기존의 서버 사이드 렌더링(SSR)과 뭐가 다른 거죠?”
메타 내부의 다른 팀 개발자와의 기술 공유 세션. 한 개발자가 손을 들고 정곡을 찌르는 질문을 던졌다. 그의 표정에는 순수한 궁금증과 함께, ‘이미 있는 걸 이름만 바꿔서 포장한 것 아니냐’는 약간의 의구심이 섞여 있었다.
회의실의 공기가 미묘하게 긴장됐다. 이 질문에 명확히 답하지 못하면, 서버 컴포넌트의 혁신성은 절반도 전달되지 못할 터였다.
마이크를 잡은 것은 앤드류 클라크였다. 그는 이 질문을 수없이 예상하고 답변을 갈고닦아 온 터였다.
“아주 좋은 질문입니다. 둘 다 서버에서 렌더링한다는 점 때문에 혼동하기 쉽죠. 하지만 둘의 목표와 동작 방식은 근본적으로 다릅니다.”
그는 화이트보드에 ‘SSR’과 ‘Server Components’라는 두 개의 컬럼을 만들었다.
“먼저 SSR을 보죠.”
그는 SSR 컬럼 아래에 설명을 적어 내려갔다. “SSR의 주된 목표는 ‘빠른 첫 화면 제공(Fast First Paint)’입니다. 사용자가 빈 화면을 보지 않도록, 서버에서 애플리케이션의 초기 상태에 대한 HTML ‘스냅샷’을 찍어서 보내주는 거죠.”
그는 잠시 말을 멈추고 중요한 다음 문장을 강조했다.
“하지만 그게 전부입니다. 일단 그 HTML 스냅샷과 관련 자바스크립트가 클라이언트에 도착하고 나면, 하이드레이션 과정을 거쳐 모든 컴포넌트는 ‘클라이언트 컴포넌트’가 됩니다. 그 이후의 모든 상호작용과 리렌더링은 전적으로 클라이언트의 몫이죠. 서버는 첫 페이지만 그려주고 퇴장하는 배우와 같습니다.”
팀원들은 고개를 끄덕였다. SSR의 본질을 정확히 짚은 설명이었다.
“이제 서버 컴포넌트를 봅시다.”
앤드류는 반대편 컬럼으로 시선을 옮겼다.
“서버 컴포넌트의 목표는 다릅니다. 단순히 첫 화면을 빨리 보여주는 게 아니라, ‘클라이언트의 자바스크립트 번들 사이즈 감소’와 ‘서버 자원에 대한 직접 접근’이 핵심입니다.”
그는 설명을 이어갔다. “가장 큰 차이점은 이것입니다. 서버 컴포넌트는 하이드레이션 이후에도 사라지지 않습니다. 그 정체성은 영원히 ‘서버’에 남아 있습니다. 사용자가 페이지를 이동하거나 어떤 액션을 취해서 새로운 UI가 필요할 때, React는 다시 서버에 요청해서 해당 서버 컴포넌트를 리렌더링하고 그 결과물만 가져옵니다.”
순간, 질문을 던졌던 개발자의 눈이 커졌다.
앤드류는 쐐기를 박았다.
“정리하자면, SSR은 ‘초기 로딩’을 위한 일회성 스냅샷 기술입니다. 반면 서버 컴포넌트는 애플리케이션의 생명주기 전체에 걸쳐, 필요할 때마다 서버에서 렌더링되는 ‘지속적인’ 아키텍처의 일부입니다. SSR의 컴포넌트는 결국 클라이언트로 오지만, 서버 컴포넌트는 결코 클라이언트로 오지 않습니다. 이것이 결정적인 차이입니다.”
명쾌한 설명에 회의실에 감돌던 미묘한 의구심이 감탄으로 바뀌었다. 이것은 기존 기술의 재포장이 아니었다. SSR이 해결하지 못했던, 아니 오히려 야기했던 문제(하이드레이션 병목, 거대한 번들)를 정면으로 돌파하기 위한 완전히 새로운 접근법이었다.
서버 컴포넌트는 SSR의 대체재가 아니라, SSR과 함께, 혹은 그 너머에서 동작하는 새로운 차원의 패러다임이었다. 그 차이를 이해하는 순간, React 19가 그리려는 거대한 그림의 윤곽이 비로소 선명하게 드러나기 시작했다.
