숫자가 먼저다
React Server Components(RSC)가 Next.js 14와 함께 정식 출시된 이후, '번들을 줄이고 서버에서 더 많이 렌더링하면 성능이 공짜로 따라온다'는 말이 많았습니다. 하지만 실제 프로덕션 대시보드를 Pages Router에서 App Router로 옮긴 Paradane의 사례(dev.to)는 조금 다른 이야기를 합니다. FCP 2.1s → 0.4s, TTI 3.2s → 1.1s, Lighthouse 점수 62 → 91. 수치는 인상적입니다. 그런데 이 숫자에 도달하기까지의 경로가 문서에는 없습니다.
마이그레이션이 실제로 어려운 이유
15개 페이지, PostgreSQL + tRPC 기반, Recharts·D3 차트가 가득한 멀티테넌트 분석 대시보드. 이런 구조를 RSC로 옮길 때 가장 많은 시간을 잡아먹은 건 컴포넌트 리팩토링이 아니라 서버/클라이언트 경계 설계였습니다. "use client"를 붙이는 건 쉽지만, 서버 컴포넌트가 임포트한 클라이언트 컴포넌트가 다시 서버 컴포넌트를 참조하는 순간 hydration mismatch가 터집니다. Paradane 팀이 이 문제의 80%를 해결한 방법은 단 하나의 규칙이었습니다. 서버 컴포넌트는 데이터를 가져와 props로 내리고, 클라이언트 컴포넌트는 데이터를 직접 fetch하지 않는다. 예외를 두지 않자 버그가 사라졌습니다.
AI 워크플로우가 만드는 진짜 시너지
여기서 두 번째 기사의 관점이 합류합니다. 비전통적인 경로로 소프트웨어 업계에 진입한 Marcus Kim의 회고(dev.to)는 AI 도구가 '검색→Stack Overflow→문서→유튜브→포럼 고고학'으로 이어지던 개발자의 비효율한 루프를 얼마나 압축했는지를 정직하게 보여줍니다. Cursor와 같은 AI 코딩 도구는 코드를 대신 써주는 도구가 아니라, 질문을 더 빠르게 다듬고 선택지를 비교하고 혼란에서 빠져나오는 시간을 단축시켜 줍니다.
RSC 마이그레이션에 이 관점을 대입하면 패턴이 보입니다. 경계 설계 규칙을 Cursor에 컨텍스트로 넣어두면, "use client" 위치가 잘못된 컴포넌트를 AI가 먼저 지적하고, tRPC에서 서버 사이드 함수로 전환하는 보일러플레이트는 반복 없이 생성됩니다. Paradane 팀이 수동으로 디버깅하며 찾아낸 패턴—차트 라이브러리는 전부 dynamic(() => import(...), { ssr: false })로 감싸라, Suspense 경계는 아키텍처의 일부로 미리 설계하라—을 AI에게 규칙으로 주면, 같은 실수를 반복하지 않을 수 있습니다.
프로토타이핑 → 검증 → 고도화 흐름으로 읽기
이 마이그레이션을 '프로토타이핑 → 검증 → 고도화' 세 단계로 분해하면 AI 도구가 어디서 가장 큰 레버리지를 만드는지가 명확해집니다.
프로토타이핑 단계: 데이터 흐름 맵을 먼저 그립니다. '어떤 데이터가 서버에서 fetch 가능하고, 어떤 상태가 클라이언트에만 존재해야 하는가'를 컴포넌트 트리 전에 정리합니다. Cursor에 이 맵을 컨텍스트로 주면 초기 구조 생성 속도가 달라집니다.
검증 단계: Suspense 경계를 하나씩 추가하며 스트리밍 효과를 측정합니다. Paradane 사례에서 TTI를 1.1s까지 끌어내린 건 RSC 자체가 아니라 스트리밍 아키텍처였습니다. 대시보드 쉘을 500ms 안에 보여주고 데이터가 순차적으로 채워지는 경험은 번들 크기 감소(400KB→280KB)보다 사용자가 훨씬 직접적으로 체감합니다.
고도화 단계: 번들 분석 결과를 보고 interactive 컴포넌트를 추가로 분리합니다. 차트·필터·폼은 여전히 클라이언트 번들을 씁니다. 여기서 AI는 어떤 라이브러리가 tree-shaking이 잘 되는지, 어떤 import 패턴이 번들을 불필요하게 키우는지를 빠르게 비교해 줍니다.
기대와 현실 사이의 갭을 먼저 알아야 한다
RSC가 약속한 '50% 번들 감소'는 콘텐츠 중심 페이지에서의 이야기입니다. interactive가 많은 대시보드에서는 30% 감소(398KB→281KB)가 현실적인 수치입니다. 빌드 시간도 45s → 68s로 늘었습니다. 이 트레이드오프를 먼저 팀과 공유하지 않으면, 마이그레이션 이후에 '기대보다 작은 효과'라는 실망이 옵니다.
AI 도구를 마이그레이션에 쓸 때도 같은 원칙이 적용됩니다. Marcus Kim이 지적한 것처럼, AI는 '앱을 만들어줘'라는 명령에서 좋은 결과를 내지 않습니다. 무엇을 위한 앱인지, 첫 번째 워크플로우가 무엇인지, v1에서 포함하지 않을 것이 무엇인지를 먼저 정의한 다음에야 AI의 출력이 방향을 갖습니다. RSC 마이그레이션도 마찬가지입니다. 경계 규칙과 Suspense 전략을 먼저 설계하고 AI에게 위임할 때, 절반의 시간이라는 결과가 따라옵니다.
지금 당장 적용할 수 있는 것
마이그레이션을 고민 중이라면 Paradane이 '다음엔 이렇게 할 것'이라고 정리한 순서가 실질적인 출발점입니다. 컴포넌트 트리가 아니라 데이터 흐름부터 시작하고, 서드파티 interactive 라이브러리는 예외 없이 ssr: false로 처리하고, Suspense 경계를 아키텍처 설계 단계에서 확정합니다. 이 세 규칙을 Cursor의 프로젝트 규칙이나 .cursorrules에 명시해두면, AI가 코드를 생성할 때마다 같은 원칙을 반영합니다.
RSC는 과장이 아닙니다. 하지만 '공짜 성능'도 아닙니다. 설계 판단을 먼저 개발자가 손에 쥐고, 반복 작업을 AI에게 위임할 때—그 조합이 마이그레이션 시간을 실제로 절반으로 만드는 방법입니다.