[🏟️ 2월 콜로세움] React Server Components(RSC)를 실무에서 얼마나 적극적으로 사용해야 할까? #163
Replies: 5 comments 4 replies
-
[RSC 사용의 찬성]RSC는 클라이언트 측 번들에서 서버 전용 로직을 완전히 분리할 수 있어요.
자바스크립트 번들 감소현재 프론트엔드 개발자들이 최적화의 가장 큰 요소로 번들 크기를 줄이기 위해 애쓰고 있다고 생각해요. 무거운 자바스크립트를 로딩하느라 TTI(Time to Interactive)가 오래 걸리고, UI 로딩에도 좋지 않은 영향을 주는 것 같아요. 통신 속도 향상토스테크에서 다뤘듯 서버의 물리적 근접성(데이터센터 위치)과 네트워크 홉 감소를 통한 성능 향상도 기대해볼 수 있어요. 개발 생산성 및 코드 간소화RSC를 사용하면 기존에 클라이언트 컴포넌트에서 fetch를 처리하기 위해 useEffect, 로딩 상태 관리, 에러 핸들링 등 번거로운 보일러플레이트 코드들을 줄일 수 있어요. // react-query 사용
import { useQuery } from 'react-query';
function ClientComponent() {
const { data, isLoading, error } = useQuery('data', () =>
fetch('/api/data').then((res) => res.json())
);
if (isLoading) return <div>Loading...</div>;
if (error) return <div>Error occurred</div>;
return <div>{data.someValue}</div>;
}반면, RSC를 사용하면 서버에서 바로 데이터를 페칭하고 렌더링할 수 있어요. // RSC 방식 (공식 문서 예제 참고)
export default async function Page() {
const res = await fetch('/api/data');
const data = await res.json();
return <div>{data.someValue}</div>;
}이렇게 단순해진 코드 구조는 개발 생산성을 높이고, 유지보수 비용을 줄여주는 효과가 있어요. 복잡성에 대한 우려, 오히려 RSC가 낫지 않을까?일반적으로 RSC를 도입하면 서버와 클라이언트 간의 역할 분리로 인해 코드 구조가 복잡해질 수 있다는 우려가 있어요. 또한, RSC는 Next.js, 공식 문서 예제 등에서 강조하듯이 복잡한 데이터 페칭 로직과 상태 관리에 대한 부담을 덜어주어, 오히려 전체적인 코드 품질과 유지보수성을 높여주는 효과가 있다는 점도 주목할 수 있을 것 같아요. 퍼포먼스 벤치마크 자료퍼포먼스 벤치마크 자료에 따르면, RSC 도입으로 인해 초기 번들 사이즈 감소와 TTI, FCP 개선 효과가 확인되었어요.
이런 수치는 이 자료에서도 자세히 확인할 수 있어요. CSS‑in‑JS 및 스타일 관리 고려프론트엔드 개발에서는 styled-components, Emotion 등 CSS‑in‑JS 라이브러리를 사용해 스타일을 컴포넌트와 함께 관리하는 경우가 많아요. RSC는 서버에서 렌더링되기 때문에, CSS‑in‑JS 라이브러리의 SSR 지원 여부를 확인해야 해요. 대부분의 라이브러리는 SSR을 지원하지만, 초기 렌더링 시 스타일이 누락되거나 flash of unstyled content(FOUC)이 발생하지 않도록 설정이 필요해요. 결론RSC는 클라이언트 번들을 경량화하고, 초기 렌더링 속도를 대폭 개선하며, 복잡한 클라이언트 fetch 로직을 서버 쪽으로 이전시켜 코드 간소화와 개발 생산성을 높이는 장점이 있어요. |
Beta Was this translation helpful? Give feedback.
-
|
@minai621 님, RSC 에 대해 개괄적으로 설명해주셔서 감사해요 :)
이 부분으로 인해... CSS in JS 라이브러리 고르다가 이틀이 날아갔던 경험이 있어요 ㅠ.ㅠ ㅋㅋ |
Beta Was this translation helpful? Give feedback.
-
[RSC 사용의 찬성]제 생각에는 RSC를 협업에 도입하기 위한 고민을 하기 위해서는 react, vercel팀이 결국 RSC를 통해서 뭘 해결하려했는지를 살펴보고, 기존에 무엇이 문제였나?흔히들 React같은 SPA에 대한 문제를 언급할때 단골처럼 나오는 몇가지 문제가 존재합니다.
그러면 우선 왜 SPA는 빈화면이 노출되는가리액트같은 SPA의 동작방식은 간단히 말하면
여기서 문제는 3 ~ 4번 과정입니다. 그러면 SSR을 이용할까?리액트를 SSR을 이용해서 렌더링하면 위의 모든 문제가 해결될까요?
이 과정만 보면 SSR을 도입하면 모든 문제가 해결되어보입니다.
이 말은 즉, 하이드레이션 이전까지는 일종의 먹통 현상으로 유저는 느낄수있게됩니다. 정리
여기까지 보면 문제의 근본적인 원인이 보입니다. => JS 번들입니다. 어떻게 고민했나?react, vercel팀도 이를 주요 문제로 본거같고, 이를 해결하는걸 과제로 잡은거같습니다. 또한 이들은 기존 전통적인 수화 방식에도 약간의 문제점을 말하며 이를 개선한다는(지금은 개선되었죠) 글도 작성한적이 있습니다. 참고 정리하면 "근복적인 문제인 JS번들 사이즈를 줄여 하이드레이션 부담을 낮추겠다"로 보입니다. 어떻게 해결했나?해결책은 간단하게 접근한거같습니다 (다만 직접 React + SSR 구현해보신분들은 아시겠지만,, 아래 내용을 직접 구현하려한다면(next.js 사용하지 않고) 매우 복잡한 과정이긴합니다,,)
그래서 현업에서 쓸꺼냐?지금까지의 문제 - 해결 - 성과를 현업에 똑같이 대입해서 예측해보면 사용할지 말지가 가늠이될거같습니다.
참고당연히 도입여부에 고려되어야할 부분은 훨씬 많지만 (비용, 학습곡선,,,,) 저는 이렇게 특정 주제만 잡아서 한번 작성해보았습니다. |
Beta Was this translation helpful? Give feedback.
-
@joseph0926 님 정말 깔끔한 정리예요 👍 |
Beta Was this translation helpful? Give feedback.
-
|
우리 서비스의 서버컴포넌트/클라이언트컴포넌트의 대략적인 비율을 조사해봐도 좋을 것 같아요. 대다수의 부분이 동적으로 움직여야 하는 Web app이라면 클라이언트 컴포넌트가 대다수일텐데, 그러면 서버컴포넌트/클라이언트컴포넌트를 구분하는 비용이 오히려 더 들 수도 있으니까요. 저는 토이프로젝트로 Jira와 같은 태스크 관리 웹앱을 만들었는데, 이 때 RSC로 만들 수 있는 컴포넌트가 너무 적어서(물론 제 RSC 짬이 0이었기도 하지만) 어려움을 겪기도 했었어요. |
Beta Was this translation helpful? Give feedback.
-
|
실무 케이스를 더 알고 싶어서 트위터에도 물어봤는데요, 이런 의견도 있네요. (답변해주신 해커님 다시금 감사합니당) |
Beta Was this translation helpful? Give feedback.
-
[준비되지 않은 RSC 도입에 반대하는 의견]1. 서론글을 전개하기에 앞서, 저는 RSC 자체에 반대하는 입장이 아님을 밝혀요. 저는 RSC라는 기술의 미래가 아주 유망하다고 생각하며, 점차 서비스에 도입하는 사례가 많아질 것이라고 봐요. 다만 아직 적극적으로 도입하기에는 충분히 무르익지 않은 단계의 기술이고, 이런 부분들을 준비하지 않은 채, 실무 서비스에 적극적으로 도입하는 것은 조금 위험할 수 있다는 생각이 있어 글을 작성해 봤어요. 2. 서버 부하 증가 및 비용 증가 💰RSC는 기존 클라이언트가 하는 일들을 서버로 가져가는 기술이기 때문에, 자바스크립트 번들 크기가 줄어드는 장점이 있어요. 다만, 그 대가로 서버의 부담이 늘어나고 트래픽이 늘어날수록 서버의 부담을 해소하기 위한 비용이 커질 거예요. 앞서 이런 비용은 성능 개선으로 상쇄하여 ROI로 상쇄할 수 있을 것이라는 의견이 있었지만, 그리고 늘어나는 서버와 인프라에 대한 비용은 눈으로 보이는 지표지만, 이런 점은 회사를 경영하는 입장에선 선뜻 투자하기 어려운 지점일 수 있다고 생각해요. 3. 개발 복잡성과 학습 곡선 📚RSC는 컴포넌트의 영역을 명확하게 서버와 클라이언트의 관점으로 나누고 있어요. 개발자 입장에서는 기존과는 다른 개발 방식에 대한 추가적인 학습과, 경험 축적이 필요할 거예요. 앞서 2번 단락에서 말씀드렸던 비용의 증가가 수치적이고 금액적인 부분에서의 비용이라면, 4. 생태계 성숙도와 안정성 🌱RSC는 아직 본격적으로 등장한 지 얼마 되지 않은 기술이에요. RSC에 지원하는 라이브러리도 아직은 많지 않아요. 만약 RSC에 지원하는 라이브러리라 해도, 5. 사용자 경험과 네트워크 의존성 📶RSC는 서버에서 렌더링한 결과물을 클라이언트로 스트리밍하는 기술이기 때문에 서버의 응답속도와 네트워크 상태에 크게 의존할 수밖에 없는 구조에요. 따라서, 서버나 네트워크에 문제가 발생한다면 페이지 전체의 렌더링이 지연되거나 예상치 못한 문제가 발생할 수 있어요. 이런 부분은 사용자 경험에도 부정적인 영향을 끼칠 수 있다고 생각해요. 6. 이미 존재하는 성숙한 대체기술 🔧프론트엔드 개발에는 이미 SSR, ISR 과 같은 렌더링 기법과 코드 스플리팅, 트리 쉐이킹 등 다양한 최적화 기술들이 존재해요. 그리고 이 기술들은 이미 개발자들에게 익숙하고, 방대한 자료들을 갖고 있으며 충분히 성숙해요. 저 기술들로도 충분히 RSC로 렌더링하는 페이지 못지않은 퍼포먼스를 낼 수 있고, 결론RSC는 높은 잠재력을 가진 기술이에요. 하지만, 아무리 뛰어난 기술도 안정성을 담보하지 못한다면 우아하고 멋진 신기술을 바로 서비스의 도입하고 싶은 것은 모든 개발자가 똑같은 마음일 거예요. 하지만, 제대로 무르익지 않은 기술을 서비스에 도입하는 것은 다른 차원의 이야기라고 생각해요. RSC가 좀 더 성숙해지고, 커뮤니티가 제대로 발전하고 관련 라이브러리들이 더 많아질 때까지 |
Beta Was this translation helpful? Give feedback.
-
이 부분도 좋네요 👍 |
Beta Was this translation helpful? Give feedback.
-
|
좋은 논의였다... 🔥 [🏟️ 2월 콜로세움] React Server Components(RSC) 실무 도입 논의 요약RSC 도입 찬성
RSC 도입 신중론
🎯 결론
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
React Server Components(RSC)는 점점 더 주목받고 있지만, 실무에서 적극적으로 도입하는 게 맞을까요? 아니면 여전히 제한적으로 활용해야 할까요?
토스 프론트엔드에서는 가까운 시일 내에는 도입 계획이 없지만, 만들고 있는 자체 프레임워크가 정착한 후 본격적으로 검토할 예정이에요.
✅ RSC를 적극 도입해야 한다면, 어떤 시나리오에서 효과적일까?
✅ 아직 제한적으로 써야 한다면, 어떤 리스크를 고려해야 할까?
✅ 실제 실무에서 적용해 본 경험이 있다면, 장점과 단점은?
등등, 실무에서의 다양한 의견을 나눠주세요 :)
🏆 가장 UpVote을 많이 받은 코멘트 작성자분께 작은 Frontend Fundamentals 굿즈를 보내드립니다!
토론을 시작해볼까요?
Beta Was this translation helpful? Give feedback.
All reactions