드디어, SSR이 SPA처럼 느껴지는 시대
SSR과 SPA 사이의 오래된 갈등을 기억하는가. 서버 컴포넌트는 SEO와 초기 로드를 챙기고, SPA는 클릭 이후의 반응성을 챙겼다. 우리는 늘 어느 한쪽을 포기하거나, 복잡한 하이브리드 구조를 구축하며 그 간극을 메워왔다. Next.js 16.3 Preview가 소개한 Instant Navigations는 바로 그 트레이드오프를 정면으로 공략한다.
핵심 문제는 단순하다. React Server Components(RSC) 기반 앱에서 링크를 클릭하면, 서버가 데이터를 가져와 컴포넌트를 렌더링하는 동안 클라이언트 화면은 아무 변화도 보여주지 않는다. 1~2초가 채 되지 않는 시간이지만, 사용자는 앱이 '얼어붙었다'고 느낀다. 반면 SPA는 코드가 이미 클라이언트에 있으니 클릭 즉시 셸(shell)을 그리고 스켈레톤을 띄운다. 데이터는 뒤에서 조용히 채워진다. 이 체감 속도 차이가 RSC 아키텍처가 오랫동안 받아온 가장 날카로운 비판이었다.
세 가지 전략: Stream, Cache, Block
Instant Navigations는 cacheComponents: true 플래그 하나를 next.config.ts에 추가하는 것으로 시작된다. 활성화되면 개발자는 각 라우트의 네비게이션 동작을 세 가지 전략으로 명시적으로 제어할 수 있다. 이 설계 철학이 흥미로운 이유는, '모든 것을 자동으로'가 아니라 의도를 코드로 선언하게 한다는 점이다.
Stream 전략은 <Suspense>로 데이터 패치를 감싸는 것이다. 링크 클릭 즉시 fallback에 정의한 스켈레톤이 나타나고, 서버에서 데이터가 준비되는 대로 실제 컴포넌트가 스트리밍된다. 사용자 입장에선 SPA와 구분하기 어렵다. Cache 전략은 'use cache' 디렉티브를 활용해 이전에 캐시된 UI를 즉시 보여주고, 필요하면 백그라운드 revalidation을 트리거한다. 대기 시간이 사실상 제로가 된다. Block 전략은 export const instant = false를 선언해 서버 렌더링이 완료될 때까지 전환을 의도적으로 지연시킨다. 뉴스 기사나 금융 데이터처럼 '절반만 로딩된 화면'이 더 해로운 컨텍스트에서 유효한 선택이다.
이 세 전략의 공통점은 '기본값으로 숨기지 않는다'는 것이다. 기존 Next.js 캐싱은 암묵적이고 예측하기 어렵다는 비판을 꾸준히 받아왔다. 16.3의 접근은 그 반성 위에 서 있다—개발자가 각 라우트의 네비게이션 의도를 명시적으로 선언하게 함으로써, 코드베이스가 곧 설계 문서가 되는 구조다.
회귀를 막는 도구: Instant Insights와 Playwright
흥미로운 건 기능 자체만큼이나 개발자 경험(DX) 레이어다. 개발 서버에 통합된 Instant Insights 패널은, 즉각 응답이 기대되는 라우트에서 블로킹이 감지되면 자동으로 경고를 띄우고 문제 코드 라인으로 안내한다. async/await 하나를 잘못 배치하는 것만으로 전체 라우트의 즉시 전환 특성이 깨질 수 있는데, 이를 개발 단계에서 실시간으로 포착한다. @next/playwright 패키지의 instant() 헬퍼는 테스트 코드에서 네트워크 지연 없이 페이지 전환이 즉각 발생했는지 검증할 수 있게 해준다. 성능 회귀(regression)를 CI 파이프라인에서 잡겠다는 의지다.
접근성은 에이전트가 읽는 언어이기도 하다
완전히 다른 맥락에서, 같은 원칙을 확인하게 해주는 사례가 있다. dev.to에 연재 중인 프로젝트 로그 시리즈의 12번째 글에서, 한 개발자가 AI 에이전트로 모바일 앱을 자동화하는 실험을 공유했다. 결과는 단순하고도 충격적이었다. WhatsApp은 완벽하게 제어됐고, 로컬 뱅킹 앱들은 에이전트에게 '보이지 않는' 앱이었다.
차이의 원인은 단 하나—접근성 레이블이었다. WhatsApp의 모든 버튼에는 content-desc 값이 붙어 있다. 전송 버튼은 "Send message", 뒤로가기는 "Back". 이 값들은 원래 시각장애 사용자를 위한 스크린 리더용이다. 그런데 AI 에이전트도 정확히 같은 UI 트리를 읽는다. 레이블이 없으면 에이전트는 OCR과 템플릿 매칭 같은 느리고 불안정한 폴백으로 후퇴했다. 그 개발자의 표현이 인상적이다: "접근성을 건너뛴 개발자들은 시각장애 사용자와 AI 에이전트를 동시에 배제했다."
이 발견은 기존에 써온 '에이전트가 읽는 UI'라는 주제를 다른 각도로 검증해준다. 그동안 에이전트 친화적 UI 설계를 논할 때 주로 웹 컴포넌트의 시맨틱 구조나 ARIA 속성을 중심으로 이야기했다면, 이 사례는 네이티브 모바일 앱에서도 동일한 원칙이 적용됨을 보여준다. 글로벌 대기업 앱들은 접근성을 투자했고, 그 투자가 우연히 에이전트 자동화 가능성을 열었다. 접근성 미투자 앱들은 사람과 기계 모두에게 닫혀 있다.
서버 렌더링 시대가 요구하는 설계 원칙
Instant Navigations와 접근성 레이블 이슈는 표면적으로 전혀 다른 이야기처럼 보이지만, 같은 질문에 답하고 있다: 이 구조가 사람과 기계 모두에게 충분히 명확하게 읽히는가?
Next.js 16.3이 제시하는 방향은 '암묵적 최적화'에서 '명시적 선언'으로의 이동이다. 어떤 라우트가 즉시 전환되어야 하는지, 어떤 라우트가 데이터를 기다려야 하는지를 코드로 선언한다. 마찬가지로, 어떤 UI 요소가 어떤 역할을 하는지를 접근성 레이블로 선언하는 행위도 같은 철학의 연장이다. 둘 다 '구조적 가독성'의 문제다.
전망은 명확하다. cacheComponents는 다음 메이저 버전에서 기본값이 될 예정이다. 즉, Instant Navigations의 세 전략 중 하나를 의식적으로 선택하는 것이 Next.js 개발의 새로운 디폴트 워크플로우가 된다는 뜻이다. 동시에, AI 에이전트가 앱을 직접 조작하는 시나리오가 늘어날수록 접근성 레이블의 존재 여부는 단순한 포용성 체크리스트를 넘어 앱의 자동화 가능성을 결정짓는 인프라 요소가 된다. 성능과 구조적 가독성—이 두 축을 함께 설계하는 팀이 다음 단계에서 유리한 위치에 있을 것이다.