최근 FE Conf 2025에서 발표된 '쿼리를 라우트까지 전파시키기(RPQ)' 패턴에 대한 내용을 공유합니다. 해당 발표는 RSC 환경에서의 데이터 패칭 문제(워터폴, 래핑 헬)를 해결하기 위해 쿼리를 컴포넌트 레벨에서 라우트 레벨로 승격시키는 아키텍처를 제안했습니다.

그러나, 이 제안은 '좋아 보이는 것'들(Toss의 데이터 패칭 전략 + 기존 라이브러리 패턴)을 나열하고 섞는 데 그쳐, 근본적인 문제 해결에 대한 깊은 고민이나 철학적 일관성이 부족하다는 한계를 보였습니다. '왜' 이런 패턴이 필요한지에 대한 명확한 논리적 근거보다는 '이렇게 하면 좋아 보일 것'이라는 피상적인 접근이 주를 이루었습니다.

우리는 이 발표의 핵심 비판점을 분석하고, 실제 프로덕트 아키텍처에 적용할 때 어떤 점을 주의해야 하는지 논의해야 합니다.

뭐가 아쉬웠는가?

발표의 핵심적인 문제는 **'설계의 방향성 부재'**입니다. 발표자가 언급했듯, Toss와 다른 라이브러리에서 좋아 보이는 패턴을 단순히 조합했습니다. 이는 다음과 같은 의문을 남깁니다.

1. 철학의 부재: RPQ는 "쿼리를 라우트의 계약으로 승격"시킨다고 주장하지만, 이는 이미 Next.js의 generateStaticParams, fetch 함수나 SvelteKit의 load 함수 등에서 구현하고 있는 기본 철학입니다. 새로운 개념을 제시하기보다는 기존 패턴에 TanStack Query를 덧붙인 것에 불과했습니다.
2. 과도한 추상화의 위험: 모든 쿼리를 '매니페스트'라는 라우트 계약으로 강제하는 것은 유연성을 크게 해칠 수 있습니다. Ad-hoc 쿼리가 필요한 동적이고 복잡한 컴포넌트의 경우, 오히려 생산성을 저해하는 걸림돌이 될 수 있습니다.
3. 병렬성의 오해: 발표는 '병렬성'을 강조하지만, 이는 RSC의 스트리밍 HTML과 Suspense가 기본적으로 제공하는 이점입니다. RPQ가 추가적으로 해결하는 병렬성 문제가 무엇인지, 그리고 그로 인해 얻는 실제적인 이점이 무엇인지 명확하게 설명하지 못했습니다.

💡 발표 내용에 대한 비판적 분석

1. Route-Propagated Query (RPQ) 패턴

• 주장: 쿼리를 라우트 계약으로 승격하고 병렬로 처리하여 직렬 의존성을 해결.
• 비판: 이 방식은 Next.js 13+ App Router의 데이터 패칭 방식(layout.js와 page.js에서 동시에 fetch를 수행하여 워터폴을 방지)과 매우 유사합니다. 발표는 이것이 '새로운 패턴'인 것처럼 포장했지만, 이는 App Router의 근본적인 설계 철학을 그대로 답습한 것입니다.

2. Query Manifest (라우트 계약)

• 주장: 라우트별로 쿼리 목록, 종속성, 보안 레벨 등을 선언적으로 관리.
• 비판: 이 개념 자체는 유효할 수 있지만, '모든' 쿼리를 여기에 넣는 것은 비현실적입니다. 특히 무한 스크롤, 검색 필터링 등 클라이언트 주도 상호작용이 많은 페이지에서는 유연한 useQuery 호출이 훨씬 효과적입니다. 매니페스트를 유지보수하는 오버헤드 또한 무시할 수 없습니다.

3. 서버/클라이언트 구현 청사진