오늘은 요새 채용 공고나 기술 면접에서 정말 자주 나오는 **React Server Components(RSC)**에 대해 이야기해볼게. 내가 9년 동안 프론트엔드 개발을 하면서 다양한 패러다임의 변화를 겪었지만, RSC의 등장은 정말 손에 꼽을 정도로 큰 변화거든. 단순히 '서버에서 렌더링한다'는 개념을 넘어, 우리 개발 방식 자체를 바꾸고 있어서 실무에서도 아주 중요하게 다루고 있어.
1. 서버 컴포넌트와 SSR은 완전히 다른 개념이야
많은 후배들이 SSR(Server-Side Rendering)과 RSC(React Server Components)를 동일한 개념으로 오해하더라고. SSR은 서버에서 HTML을 완성해서 브라우저로 보내고, 브라우저가 자바스크립트를 다운로드받아 실행하는 Hydration 과정을 거쳐. 반면 RSC는 컴포넌트 자체의 렌더링을 서버에서 수행하고 그 결과를 RSC Payload라는 특별한 직렬화 데이터 포맷으로 클라이언트에 전달해.
- SSR: 초기 로딩 속도(FCP)를 빠르게 하기 위한 페이지 단위의 렌더링 기법이야.
- RSC: 컴포넌트 단위로 서버에서 렌더링을 수행해서 클라이언트 번들 크기를 획기적으로 줄여주는 기술이지. 이 둘은 대체 관계가 아니라 상호보완적인 관계야. RSC를 사용하면서 동시에 SSR을 적용해 첫 페이지를 빠르게 보여주는 방식으로 시너지를 낼 수 있거든.
2. 실무에서 체감하는 서버 컴포넌트의 강력함
현업에서 RSC를 도입했을 때 가장 크게 와닿는 장점은 역시 번들 사이즈 감소야. 예를 들어 무거운 마크다운 파서 라이브러리를 사용해야 할 때, 기존에는 이 라이브러리가 사용자 브라우저까지 전부 다운로드되어야 했거든. 하지만 이걸 서버 컴포넌트 내부에서 처리하면 라이브러리가 클라이언트 번들에 포함되지 않아. 사용자는 완성된 결과물만 받게 되니까 페이지 로드 속도가 엄청나게 빨라지지. 또한, 서버 컴포넌트 내부에서는 데이터베이스에 직접 접근하거나 보안이 중요한 API 키를 노출 없이 바로 사용할 수 있어. 불필요한 API 엔드포인트를 중간에 만들지 않아도 되니까 개발 생산성도 정말 좋아지더라.
3. 'use client'와 경계선 잘 긋기
Next.js의 App Router에서는 기본적으로 모든 컴포넌트가 서버 컴포넌트로 동작해. 만약 상태 관리(useState, useEffect)나 브라우저 이벤트(클릭 리스너 등)를 사용해야 한다면 파일 최상단에 'use client' 지시어를 적어주어야 해.
이때 중요한 실무 팁은 서버 컴포넌트와 클라이언트 컴포넌트의 경계를 잘 나누는 것이야. 가능한 한 데이터 페칭이나 무거운 로직은 서버 컴포넌트에서 처리하고, 클라이언트 컴포넌트는 UI의 말단(Leaf Node)에 위치시키는 것이 좋아. 서버 컴포넌트의 자식으로 클라이언트 컴포넌트를 배치하는 구조를 유지해야 RSC의 이점을 극대화할 수 있거든.
💡 핵심 정리
- RSC는 클라이언트 번들 크기를 줄이고 초기 로딩 성능을 극대화하는 새로운 컴포넌트 모델이야.
- 데이터베이스 직접 접근이나 보안 키 사용이 가능해져서 백엔드와의 경계가 더 효율적으로 변해.
'use client'는 필요한 곳에만 최소한으로 사용하고, 컴포넌트 설계 시 경계를 명확히 나누는 연습을 해봐. 서버 컴포넌트는 처음 접하면 개념이 다소 낯설고 설계가 복잡하게 느껴질 수 있어. 하지만 한 번 익숙해지면 웹 성능을 극적으로 끌어올릴 수 있는 강력한 무기가 되거든. 포트폴리오에 Next.js App Router를 적용해보고 이 구조적 이점을 면접에서 당당하게 설명해봐. 분명 좋은 결과가 있을 거야.