피드로 돌아가기
Dev.toFrontend
원문 읽기
RSC의 복잡성과 CVE 10.0 취약점을 극복한 SPA 및 분리된 Backend 회귀
Why I Walked Back from Next.js and RSC to a Plain SPA and a Separate Backend
AI 요약
Context
Next.js App Router와 React Server Components(RSC) 도입으로 인한 Server/Client 경계 모호함과 런타임 예측 불가능성 증가. 프레임워크 내부 캐싱 레이어의 복잡성으로 인해 데이터 신선도 보장 및 로컬-운영 환경 간 일관성 확보에 한계 직면.
Technical Solution
- Client-side Rendering 기반의 SPA 구조로 회귀하여 Frontend 공격 표면 최소화
- Static files의 CDN 배포를 통한 서버리스 정적 자산 서빙 체계 구축
- HTTP Boundary를 통한 Frontend와 Backend의 물리적 분리로 인터페이스 명확화
- Auth, CORS, Rate Limiting 등 보안 로직을 전용 Backend 서비스에 집중시켜 책임 분리
- Hono, Go, Python 등 비즈니스 요구사항에 따라 교체 가능한 독립적 Backend 스택 채택
- RSC의 복잡한 Serialization 및 Hydration 과정 제거를 통한 시스템 예측 가능성 확보
실천 포인트
- SEO가 필수적인 콘텐츠 중심 사이트가 아니라면 굳이 RSC/SSR의 복잡성을 감수하고 있는지 검토 - Server/Client 경계에서 발생하는 Serialization 에러나 Hydration mismatch 빈도 측정 - 프레임워크 내부의 자동 캐싱 메커니즘이 비즈니스 데이터의 정합성을 해치지 않는지 확인 - 보안 핵심 로직이 프레임워크의 Plumbing(내부 구조)에 의존하고 있는지, 독립적인 Backend에서 제어되는지 점검