RSC(React Server Components): 그래서 뭐가 좋은 건데?

RSC를 도입하면 가장 먼저 듣는 질문이 있습니다. "결국 뭐가 빨라지는 건데?" 실제로 체감되는 가치는 단순 렌더링 속도보다 구조 단순화에서 나옵니다. 기존에는 클라이언트에서 데이터 요청, 상태 관리, 로딩 처리, 에러 처리가 뒤엉켜 있던 부분을 서버 컴포넌트로 옮기면서 화면 책임이 명확해집니다. 이 변화가 쌓이면 코드 복잡도와 회귀 버그가 같이 줄어듭니다.

중요한 건 RSC를 만능 해법으로 보지 않는 것입니다. 모든 컴포넌트를 서버로 보내는 접근은 현실적이지 않습니다. 사용자 입력, 로컬 상태, 애니메이션, 브라우저 API는 여전히 클라이언트 영역입니다. 따라서 도입 전략의 핵심은 "어디를 서버로 둘지"보다 "어디까지 클라이언트로 남겨야 하는지"를 명확히 정의하는 데 있습니다.

1. 경계를 잘라야 유지보수가 쉬워진다

실무에서 가장 효과적인 패턴은 화면을 두 층으로 나누는 것입니다. 서버 층은 데이터 조회와 기본 마크업 생성, 클라이언트 층은 상호작용과 로컬 상태 처리. 이 경계를 파일 단위로 명시하면 리뷰와 테스트가 쉬워집니다. 특히 페이지 최상단에 무심코 use client를 붙이는 습관을 줄이는 것만으로도 번들 크기와 복잡도가 크게 개선됩니다.

권장 방식은 말단 인터랙션 컴포넌트만 클라이언트로 분리하는 것입니다. 예를 들어 상세 페이지 본문은 서버 컴포넌트로 유지하고, 북마크 버튼이나 정렬 토글만 클라이언트 컴포넌트로 분리하면 됩니다. 이렇게 하면 화면 대부분은 서버 렌더링 이점을 유지하면서도 필요한 상호작용은 잃지 않습니다.

2. 데이터 페칭은 "가까운 곳"에서 처리하기

RSC의 장점 중 하나는 컴포넌트 가까운 곳에서 데이터를 바로 가져올 수 있다는 점입니다. 과거처럼 모든 데이터를 상위에서 몰아 가져오면 의존성이 다시 복잡해집니다. 도메인 컴포넌트가 자신의 데이터를 책임지는 구조가 확장성과 테스트 측면에서 유리합니다.

다만 데이터 호출이 늘어날수록 캐시 전략이 중요해집니다. 어떤 데이터는 주기 갱신, 어떤 데이터는 이벤트 기반 갱신이 필요한지 분리해야 합니다. 이 정책이 없으면 화면별로 제각각 구현되어 stale 데이터 이슈가 반복됩니다.

3. Server Actions는 폼 단순화 도구, 만능이 아니다

Server Actions를 쓰면 API 라우트 보일러플레이트를 줄일 수 있어 생산성이 좋아집니다. 하지만 운영에서 중요한 건 "어디에서 검증하는가"입니다. 클라이언트 검증만 믿으면 우회 요청에 취약해지고, 서버 검증만 두면 사용자 피드백이 늦어집니다. 둘을 역할 분담해서 설계해야 안정적입니다.

또한 실패 시 사용자 경험을 미리 정해야 합니다. 재시도 가능한 오류인지, 입력 수정이 필요한 오류인지, 일시 장애인지에 따라 메시지와 복구 동작이 달라야 합니다. 이 기준을 정하지 않으면 폼 제출 실패가 곧 이탈로 이어집니다.

4. 도입 체크리스트

• 현재 화면에서 상호작용이 실제로 필요한 영역이 어디인지 구분했는가
• use client가 페이지 루트에 과도하게 붙어 있지 않은가
• 서버/클라이언트 경계 기준이 팀 문서로 정리되어 있는가
• 데이터 캐시와 갱신 트리거 정책이 화면별로 일관적인가
• Server Actions 실패 시 사용자 복구 경로를 정의했는가

RSC는 신기한 신기술이 아니라 프론트엔드 구조를 정리하는 도구입니다. 경계 설계를 먼저 하고 단계적으로 적용하면, 성능 이득과 유지보수 이득을 동시에 가져갈 수 있습니다.

5. 팀 도입 운영 팁

도입 초기에는 신규 화면부터 적용하는 편이 리스크가 낮습니다. 기존 핵심 화면을 전면 전환하면 비교 기준이 사라져 성능·버그 회귀를 판단하기 어려워집니다. 또한 PR 템플릿에 "서버 컴포넌트로 둔 이유"와 "클라이언트로 분리한 이유"를 한 줄씩 기록하게 하면 리뷰 품질이 좋아집니다. 이 기록이 쌓이면 팀 내 경계 판단 기준이 자연스럽게 통일되고, 신규 인원 온보딩도 빨라집니다. 결국 RSC의 성패는 기술 난이도보다 팀이 경계를 얼마나 일관되게 유지하느냐에 달려 있습니다.