토스뱅크, App Router 도입 보류 결정…전환 비용이 이득보다 커

토스뱅크 프론트엔드 팀이 Next.js App Router와 RSC(React Server Components) 도입을 검토한 결과, 안정성 유지 비용 대비 이득이 부족해 도입을 보류하고 Pages Router를 유지하기로 결정했다. 2025년 가을 기술그룹을 구성해 실제 서비스 이관 실험을 진행했으며, 주요 이슈와 결론을 다음과 같이 정리했다.

점진적 렌더링과 레이아웃 안정성

Suspense 기반 점진적 렌더링을 검증한 결과, WebKit 환경에서 FCP(First Contentful Paint) 지연 문제가 발생했다. 초기 FCP는 5,065ms였으나, 보이지 않는 SVG 삽입으로 103ms까지 개선 가능했다. 하지만 스켈레톤과 실제 콘텐츠의 높이 차이로 인한 CLS(Cumulative Layout Shift) 문제가 발생했다. 스켈레톤 높이 최적화로 CLS를 0.138에서 0.036으로 줄일 수 있었으나, 섹션별 로딩 화면 관리 부담이 커져 점진적 렌더링의 이득보다 레이아웃 안정성 관리 비용이 더 큰 것으로 판단했다.

RSC 활용과 번들 최적화

RSC를 활용해 서버 컴포넌트 구현과 의존성 클라이언트 번들 제외로 번들 크기를 줄이고, headers() API를 통해 인증 로직을 통합하는 등 데이터 로딩 코드를 단순화할 수 있었다. package.json 조건부 export를 통해 RSC용과 클라이언트용 구현을 분리하여 개발 흐름을 개선했다. 그러나 브라우저 동작(버튼, 입력, 앱 브릿지 등)이 많아 Client Component 비중이 높았으며, 서버와 브라우저 코드 경계 구분 및 실행 환경별 공통 패키지 검증이 필수적이었다. 특히 앱 브릿지 호출 시 서버 컴포넌트에서는 에러 없이 무시되는 등 환경 적합성 확인이 필요했다.

마이그레이션 운영 이슈

Pages Router와 App Router 병행 시 특정 경로 구조에서 이동이 깨지는 문제가 발생했다. basePath 설정 상태에서 Pages Router 화면 간 이동 시 경로에 basePath가 중복 적용되어 404가 발생했다. 또한 클라이언트 라우터가 App Router 화면 여부를 판단하는 데 사용하는 Bloom Filter의 등록 방식 문제로 인해 /a/[id] 패턴이 /a로 등록되어 Pages Router의 /a/a 주소가 매번 매칭되는 오류가 있었다. 로깅용 경로 패턴 제공 부재와 router.events 제거 등 기존 기능 대체를 위한 별도 작업이 필요했으며, 이러한 전환 및 운영 비용이 이득보다 크다고 판단했다.