20 min to read

현대 프론트엔드 환경을 다시 돌아보기

우리가 지금 쓰는 도구들이 정말 적절한 선택인지 되묻습니다.

Featured image

들어가며

‘프론트엔드 개발자’라는 말은 어느새 ‘React 개발자’, ‘Next.js 개발자’와 같은 의미로 통용되고 있습니다. 저 역시 두 용어를 명확히 구분하기 어렵다고 느낀 적이 많았고, 이 블로그의 글을 작성할 때도 React 카테고리와 frontend 중 어떤 것을 선택할지 망설인 경우가 많았습니다.

이 글은 최근 GeekNews 등에서 본 여러 기술 아티클과, 저 자신의 커리어를 점검하며 던졌던 질문에서 출발했습니다. 우리가 지금 사용하는 도구들이 과연 ‘적절한 선택’이었는지 되묻고, 그 고민을 글로 정리하고자 합니다.

왜 React는 등장했는가 - React가 해결하고자 했던 문제

일반적인 비유 - 고속열차는 무엇을 위함인가

당연한 이야기 하나를 해보겠습니다. 어떤 도구든 쓰임새가 있기 때문에 존재하고 통용됩니다. 예를 들어, 바퀴는 적은 힘으로 짐을 옮기기 위한 도구이며, 철도는 인구 밀집 지역 간 효율적인 이동을 위해 존재합니다.

하지만 아무리 좋은 도구라도 맥락 없이 도입하면 문제가 발생합니다. 예컨대, 100가구 남짓한 산골 마을에 20량짜리 고속열차를 투입하기 위해 대규모 토목공사를 벌인다면, 그 결과는 너무나도 뻔할 것입니다.

대한민국의 KTX 도입 사례를 보면, 서울-대전-대구-부산처럼 대도시를 연결하거나, 목포-광주-익산 등 호남권을 잇는 노선에 고속열차가 효율을 발휘하고 있습니다. 당연한 일입니다.

그렇다면 React의 원래 수요처는?

그렇다면 이제 다시 컴퓨터 프로그래밍의 세계로 돌아와 봅시다. 우리가 그렇게나 많이 사용하는, 프론트엔드 그 자체로 취급받게 된 React는 어떤 문제를 해결하기 위해 등장했을까요? 그런 점을 생각해보자는 것입니다. React는 현대 시대의 유명 SNS인 Instagram을 개발하기 위한 도구였습니다. 페이지 이동이 그렇게까지 잦지 않고, 한 화면에서 계속 스크롤 등으로 다음 콘텐츠들을 확인하는 그런 ‘앱’스러운 프로덕트를 만들기 위한 도구였고, 지금까지 여러 발전을 거듭해오면서 쭉 성장해 왔습니다.

소규모 산자락 마을에 KTX를 놓는 것은 여러모로 맞지 않듯, 블로그나 쇼핑몰, 그리고 기업 소개 랜딩 페이지 정도에 React를 쓰는 것은 어찌 보면 과투자일 수 있습니다. 소규모 산자락 마을에는 시내와 연결되는 미니버스 한 대만 있으면 충분하듯이, 그러한 콘텐츠를 보여주기 위한 웹 페이지에는 고전적인 MPA도 결코 나쁜 선택이 아닙니다.

이 길고 긴 서론이 있었으니, 이제 지금까지 웹 프론트엔드가 겪은 여정과, 무엇이 문제였는지, 그리고 많은 이들이 외면하는 사실은 충분한 표준 웹 기능들에 대해서 알아봅시다.

SSR MPA → SPA → SSR + SPA (e.g. Next.js) 까지의 역사

고전적 SSR MPA 에서 SPA로의 이동

과거 전통적인 웹 페이지들은 서버에서 내려주는 템플릿을 그대로 렌더링 하기만 하는 SSR 구조 위에서 동작했습니다. 사용자가 새로운 페이지로 이동하기 위해 서버에 요청을 보내고, 서버는 다시 HTML 내용을 채워서 다시 클라이언트에 전송하는 식이었죠.

이러한 고전적 SSR은 각 페이지에 고유 URL이 있고, 서버에 요청을 하면 온전한 콘텐츠를 한번에 보내주기 때문에 SEO 친화적이었고, 브라우저에서 처리할 작업이 상대적으로 적기 때문에 저사양 기기에서도 문제 없이 콘텐츠를 이용할 수 있었습니다.

다만 매 페이지 이동 시, 전체 페이지를 다시 불러오므로, 화면 깜빡임이 발생하고, 스크롤 위치의 초기화 등 UX의 불편함이 있었고, 클라이언트 상태를 유지하기 힘들다는 문제가 있었습니다.

SPA는 이러한 문제를 해결하기 위해 등장하였습니다. SPA는 초기 로딩 시 애플리케이션 전체가 번들된 자바스크립트를 내려받고, 그 이후에는 브라우저 내에서 페이지를 동적으로 갱신하는 방법론입니다. 2010년대 Angular와 React의 등장으로 SPA 개발이 용이해졌고, SPA는 ‘앱 같은’ UX를 구현하는 데 효과적인 도구로 각광받았습니다. Ajax를 통한 부분 업데이트, 클라이언트 사이드 라우팅 등의 도구를 사용해 화면이 번쩍이는 현상 없이 부드러운 전환을 보이며 UX적으로 많은 관심을 불러일으켰습니다.

SPA의 장단점

이러한 SPA의 장점을 정리해보면 다음과 같습니다.

반면 SPA의 단점도 분명하며, 다음과 같이 정리할 수 있습니다.

이러한 장단점을 고려할 때, 실시간 대시보드, 대화형 그래픽 편집기, SNS처럼 사용자 상호작용이 빈번한 애플리케이션에 사용되는 것을 전제로 만들어진 SPA였지만, 블로그나 쇼핑몰 등 콘텐츠 위주의 사이트까지 무분별하게 SPA로 전환하는 경향도 있었습니다. 이에 따라 SSR 기반 전통 MPA는 다소 시대에 뒤처진 기술처럼 여겨지기도 했고, 저 또한 그렇게 생각했던 적이 분명 있었습니다.

CSR SPA 에서 SSR 프레임워크로의 회귀

앞서 언급한 SPA의 폭발적 인기에도 불구하고, 시간이 지나면서 SPA의 한계와 부작용이 부각되기 시작했습니다. 첫째로 SEO 이슈와 초기 로딩 성능 문제가 지속적으로 제기되었고, 둘째로 모든 페이지에 대규모 자바스크립트를 배송하는 방식이 모바일 환경에서 비효율적이라는 지적이 있었습니다. 이에 따라 다시 SSR 개념을 재도입하되, SPA의 개발 편의와 UX 장점을 함께 취하고자 하는 노력이 이어졌습니다.

이러한 흐름에서 탄생한 것이 Next.js(React 기반)나 Nuxt.js(Vue 기반)처럼 SSR 지원 프레임워크들입니다. 이러한 도구들은 개발자가 서버와 클라이언트 코드를 한 프로젝트에서 관리하고, 빌드 시에 서버용 번들과 브라우저용 번들을 동시에 만들어주는 역할을 합니다. 예를 들어 Next.js는 Node.js 서버 위에서 초기 페이지를 SSR로 렌더링하여 HTML을 응답하고, 이후 필요한 자바스크립트 코드만 하이드레이션(hydration)을 통해 인터랙티브 기능을 부여하는 식으로 동작하지요.

SSR 프레임워크로의 회귀 배경

SSR 프레임워크의 한계점

안타깝게도 SSR 프레임워크가 모든 문제를 다 해결하지는 못하였습니다. 단점/한계점 이라고 할 수 있는 요소들을 정리하면 아래와 같습니다.

이러한 단점들에도 불구하고, SSR 지원 프레임워크의 도입은 2020년대 웹 개발의 대세로 자리잡았습니다. Next.js는 채용 공고만 봐도 느낄 수 있을 정도로 React 생태계에서 사실상 표준 도구가 되었고, Nuxt.js, SvelteKit, Remix 등 다른 프레임워크들도 SSR를 기본 지원합니다. 이는 SPA의 장점을 유지하면서도 초기 렌더링 성능과 SEO를 확보하려는 현실적인 타협이라 할 수 있습니다. 다만, 최근에는 SSR 프레임워크조차도 “필요한 곳에만 JS를 쓰자”는 방향으로 진화하고 있으며, 이는 다음 장에서 다룰 최신 웹 플랫폼 기능들과 맞물려 새로운 전환점을 맞이하고 있습니다.

그사이 성장한 표준 웹 - 최신 MPA 기반 UX 향상 기술

최근 들어 브라우저 자체가 MPA 환경의 UX를 개선하기 위한 강력한 기능들을 도입하면서, 전통적인 MPA도 SPA에 버금가는 부드러운 사용자 경험을 제공할 수 있게 되었습니다. 대표적인 기술이 View Transition API와 Speculation Rules API입니다. 한마디로, “브라우저 네이티브로 부드러운 페이지 전환과 사전 로딩을 지원”하는 기술들로, 추가 JS 프레임워크 없이도 MPA의 단점을 상당 부분 극복할 수 있게 해줍니다

View Transition API (뷰 전환 API)

기존에는 MPA에서 페이지 전환 시 화면이 순간 깜빡이는 현상을 피하려면, SPA처럼 화면 전환을 JavaScript로 제어하거나 CSS로 fade효과를 주는 트릭 등을 써야 했습니다.

View Transition API는 이러한 과정을 브라우저가 자동 처리해주도록 한 표준으로, 크로스 도큐먼트 전환을 지원합니다. Chromium 기반 브라우저(Chrome, Edge 등) 126 버전 이상과 Safari 18.2+에서 사용할 수 있으며(safari 출처, chrome 출처), CSS의 @view-transition 규칙으로 활성화합니다. 간단히 모든 페이지의 CSS에 다음 한 줄을 넣으면 됩니다

@view-transition {
  navigation: auto;
}

위와 같이 설정하면 동일 도메인 내의 일반 링크 클릭에 대해 브라우저가 자동으로 이전 페이지와 다음 페이지의 요소를 비교하여 스크린샷을 교차 페이드하는 기본 애니메이션을 수행합니다. 개발자는 별도 스크립트를 작성할 필요 없이, 실제 페이지를 완전히 새로 로드하면서도 SPA처럼 화면 전환을 부드럽게 만들 수 있습니다. 또한 이 API는 훨씬 더 강력한 기능들을 제공합니다

::view-transition-old(root) {
  animation: fade-out 0.3s ease-out;
}
::view-transition-new(root) {
  animation: fade-in 0.3s ease-out;
}
@keyframes fade-in {
  from {
    opacity: 0;
  }
  to {
    opacity: 1;
  }
}
@keyframes fade-out {
  from {
    opacity: 1;
  }
  to {
    opacity: 0;
  }
}

prefers-reduced-motion등의 옵션을 사용해서 커스텀 또한 할 수 있습니다

@media (prefers-reduced-motion: reduce) {
  ::view-transition-old(root),
  ::view-transition-new(root) {
    animation: none;
  }
}

<!-- 목록 페이지 -->
<a href="/product/red-shoes">
  <img src="red-shoes-thumb.jpg" style="view-transition-name: product-image;" />
</a>
<!-- 상세 페이지 -->
<img src="red-shoes-large.jpg" style="view-transition-name: product-image;" />

다만 Astro의 구현이 되어 있어, 실제 프로젝트에서 사용할 수 있습니다.

View Transition API는 이동 직전의 페이지와 다음 페이지를 동시에 다루어야 하므로 양쪽 페이지 모두 지원 코드가 있어야 합니다. 즉, 동일 출처(Same-origin)의 두 문서 모두 @view-transition { navigation: auto; }를 포함하고 있어야 전환 효과가 발동됩니다. 그리고 보안상의 이유로 교차 출처 간에는 동작하지 않으며, beforeunload 이벤트를 사용하거나 리디렉션 등이 개입되면 효과가 취소됩니다. 최신 브라우저에서 사용할 수 있지만, Firefox는 현재 미지원이므로 적용 시 폴백 전략(전환 효과 없이도 자연스럽게 동작하도록)을 고려해야 합니다.

Speculation Rules API (추론 규칙 API)

부드러운 화면 전환의 다른 축은 다음 페이지를 미리 로딩하여 실제 클릭 시 지연을 없애는 것입니다. Speculation Rules는 HTML 문서 내에 <script type="speculationrules"> 태그를 사용해 브라우저에 프리페치(prefetch)/프리렌더(prerender) 지침을 전달하는 새로운 표준입니다

간단히 말해, 과거 <link rel="prefetch">나 <link rel="prerender">의 업그레이드판으로, JSON으로 세밀한 규칙을 정의하여 사용자가 방문할 가능성이 높은 페이지를 앞서 불러오도록 브라우저에 명령할 수 있습니다. 예를 들어 쇼핑몰의 일부 링크를 미리 프리렌더하고 싶다면 다음처럼 작성합니다. 로그인/로그아웃 이나 미리 렌더링 하면 불리한 것은 제외해서 성능을 챙겨봅시다.

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": { "selector_matches": "a[data-prerender]" },
        "eagerness": "moderate",
        "not": { "href_matches": "/(login|logout|cart|checkout|admin)" }
      }
    ]
  }
</script>

위 JSON은 현재 페이지에 존재하는 data-prerender가 지정된 링크에 한해 프리렌더 지시합니다. 프리렌더는 단순히 HTML만 가져오는 프리페치와 달리, 대상 페이지를 백그라운드 탭에 보이지 않게 띄워서 모든 자원과 JS를 미리 실행해두는 것을 의미합니다. 그 결과 사용자가 해당 링크를 클릭하면, 이미 렌더링 완료된 페이지로 즉각적인 전환이 이뤄집니다. 0.1~0.2초 내에 새 페이지가 뜨는 체감을 만들 수 있어, 사용자는 로딩을 인지하기도 전에 콘텐츠를 확인할 수 있습니다.

Speculation Rules JSON은 prefetch와 prerender 키를 지원하며, 각각 언제 어떤 URL을 사전 로드할지 규칙을 지정합니다. 규칙에는 두 가지 방식이 있습니다.

또한 각 룰에는 "eagerness" 옵션으로 로딩 트리거의 적극성을 제어할 수 있습니다. "eager"로 설정하면 페이지가 로드되자마자 즉시 사전로딩을 시작하고, "conservative"로 하면 사용자 이벤트(마우스 오버 등)을 관찰해 어느 정도 가능성이 높아졌을 때 로딩합니다. 예를 들어 “eagerness”: “moderate”는 기본값으로, 링크에 마우스 커서를 올리거나 터치했을 때 프리렌더를 개시하는 식입니다.

Speculation Rules는 기존 <link rel="prefetch"> 등에 비해 한층 개선되었습니다. 과거 <link rel="prerender">는 NoState Prefetch로 대체되며 비표준으로 남았지만, 이제 표준화된 Speculation Rules로 풀 prerender 기능을 안전하게 활용할 수 있습니다.

또한 <link rel="prefetch">의 경우 브라우저 HTTP 캐시를 이용해 리소스를 당겨놓는 수준이었는데, Speculation Rules는 메모리 내에 프리로드된 페이지를 보관하여 곧바로 탭 전환이 가능하게 하고, Speculation Rules는 HTTP 캐시가 아닌 전용(메모리) 캐시를 사용해 사전로딩하므로, 일반 HTTP 캐시 규칙과 별개로 동작하고, 가능한 경우 HTTP 캐시도 채울 수 있습니다.

Chrome은 2025년 3–4월에 일부 no-store 페이지의 BFCache 허용을 완료했습니다. 즉, MPA가 유리한 경향은 유지되지만, SPA/하이브리드도 unload 회피 등 요건을 지키면 BFCache 혜택을 받을 수 있습니다. (출처)

요컨대 Speculation Rules API는 개발자가 다음 사용자의 이동 경로를 예측해 네트워크 지연을 숨길 수 있는 수단을 표준으로 획득했다는 의의가 있습니다.

주의사항: Speculation Rules의 남용은 오히려 성능 악화를 초래할 수 있습니다.

예를 들어 페이지가 매우 무겁거나 사용자가 방문하지 않을 링크까지 모조리 프리렌더한다면, 사용자의 CPU/메모리와 데이터 용량을 낭비하게 됩니다. 그러므로 가볍고 최적화된 사이트에서 중요한 경로에 한해 신중히 사용해야 하며, 불필요한 프리렌더는 지양해야 합니다. 또한 브라우저별 지원이 상이하므로(브라우저별 지원이 상이하다. Chromium 계열은 적극 도입, Safari/Firefox는 아직 미지원(실험적 상태), 따라서 Speculation Rules는 점진적 향상 관점에서 적용해야 한다.) 폴백 메커니즘도 고려해야 합니다. Speculation Rules를 이용하지 못하는 브라우저에서는 그냥 일반 링크 이동이 이뤄지는데, 이때도 사용자 경험이 나쁘지 않도록 기본 페이지 성능을 높여놓는 것이 중요합니다.

이 외의 최신 기술

브라우저의 Back/Forward Cache(BFCache) 개선도 MPA UX에 크게 기여하고 있습니다. BFCache는 사용자가 뒤로가기/앞으로가기를 할 때 이전 페이지를 메모리에 보존해 즉시 복원하는 기능인데, SPA에서는 히스토리를 가로채는 자체 라우팅 로직 때문에 BFCache를 활용하지 못하는 경우가 많습니다 (BFCache 관련 web.dev 아티클) 다만 unload 미사용, 차단 API 회피 등으로 BFCache 혜택을 받을 수도 있음이 위 아티클에 있으니 섣부른 단정은 지양하는 것이 좋습니다.

반면 전통적인 MPA 구조에서는 특별한 설정 없이도 브라우저가 BFCache를 활용해 뒤로/앞으로 탐색 시 순간이동같이 빠른 복귀를 제공합니다. 이 역시 MPA가 가진 자연스러운 이점으로, 현대 브라우저들은 건전한 (복잡한 JS로 교란되지 않은) 웹사이트에 더 많은 성능 혜택을 주고 있습니다

정리하면, View Transition API와 Speculation Rules의 조합은 MPA의 약점이었던 화면 전환 지연과 깜빡임을 효과적으로 해소합니다. 예를 들어 현대적 MPA에 이 두 가지 기술을 적용하면, Next.js로 구현된 SPA 못지않은 - 어쩌면 그 이상으로 - 즉각적이고 부드러운 페이지 전환을 이뤄낼 수 있습니다. 실제로 한 비교에서 Next.js 기반 SPA 사이트는 JS 번들 1–3MB, TTI 3.5–5초, 라우팅은 JS로 흉내낸 것인 반면, View Transition + Speculation Rules를 적용한 MPA는 추가 JS 없이 TTI 약 1초에 네이티브 전환으로 모든 것이 즉각 반응하는 것으로 나타났습니다. 이는 웹 플랫폼 자체의 발전이 SPA의 주요 이점이었던 UX를 네이티브 수준에서 구현했고, 이제는 과거에 SPA를 선택했던 많은 이유가 희석되고 있음을 의미합니다.

React, Next.js 중심의 웹 앱 프레임워크 전망

그렇다면 앞으로의 프론트엔드 개발은 어떤 방식으로 흘러갈지 생각해봅시다. 앞서 살펴본 흐름을 종합해보면, 웹 프론트엔드의 렌더링 패러다임은 “SSR → CSR → (SSR+CSR) → 웹 플랫폼 활용 SSR”로 진화하고 있습니다. 이러한 변곡점에서, 가장 널리 사용되는 라이브러리인 React와 대표적인 메타프레임워크 Next.js의 향후 발전 방향을 전망해보겠습니다.

React의 진화와 전망

React는 원래 UI 제작을 위한 라이브러리였지만, CSR SPA를 위한 라이브러리로 바뀌었고, 현재는 SSR/SSG까지 포괄하는 범용 뷰 레이어로 발전했습니다. React 팀은 꾸준히 SSR 지원을 강화해왔는데, React 18에서는 서버 측 스트리밍 렌더링(Streaming SSR)과 Suspense를 도입하여 SSR 시에도 점진적 스트리밍과 부분적 데이터 대기를 가능케 했습니다. 특히 가장 주목할 변화는 React Server Components(RSC)의 도입입니다. Server Components는 서버 전용 컴포넌트를 만들어 해당 UI 부분은 아예 클라이언트 JS에 포함시키지 않고, 서버가 렌더링한 결과(직렬화된 HTML + 상태)만 보내도록 합니다. Next.js 13+ 버전은 RSC를 기본 채택하여, 페이지의 상당 부분이 순수 서버에서 그리고 클라이언트에는 뼈대 HTML과 최소한의 상호작용 스크립트만 전송됩니다. 이 접근은 React가 불필요한 JS를 줄이고 SSR 성능을 높이는 방향으로 나아가고 있음을 보여줍니다. 앞으로 React는 이러한 서버-클라이언트 역할 분리를 더욱 세밀하게 지원하고, 부분 하이드레이션, 클라이언트 상태 동기화 등의 난제를 해결하는 데 집중할 것으로 예상됩니다. 동시에 React는 브라우저의 새로운 기능들과도 조화를 꾀할 것입니다. 예를 들어 View Transition API를 React 라우터와 연계하거나, Speculation Rules를 자동으로 생성해주는 등의 생태계 도구가 등장할 가능성이 있습니다. 결과적으로 React는 핵심 장점인 선언적 UI와 거대한 생태계를 유지하면서, 점차 “필요할 때만 CSR, 그 외에는 플랫폼/서버 활용” 철학을 반영하는 쪽으로 진화할 전망입니다.

Next.js와 메타프레임워크의 미래

Next.js는 React 기반 웹 개발의 사실상 표준 플랫폼이 되었으며, 앞으로도 주요 개선이 이어질 것입니다. 한 가지 뚜렷한 방향은 더 적은 JS와 더 나은 성능입니다. Next.js 13의 App Router + RSC 조합은 페이지 단위가 아니라 컴포넌트 단위로 SSR/CSR 여부를 결정하는 유연성을 가져왔고, 이는 “필요한 위젯만 CSR”이라는 아일랜드 아키텍처에 가까워지고 있습니다.

앞으로 Next.js는 이러한 부분적인 CSR, 선택적 하이드레이션 기법을 더욱 최적화하고 자동화할 것입니다. 또한 Vercel을 비롯한 호스팅 업체들은 Next.js를 에지 컴퓨팅과 결합하여, 전 세계 사용자에게 SSR 결과를 캐싱/서빙함으로써 지연을 최소화하는 방향으로 발전시킬 것입니다. 이는 곧 Next.js 앱이 전통 MPA처럼 지리적으로 가까운 곳에서 즉시 콘텐츠 제공을 하는 형태로 나아감을 뜻합니다.

Next.js뿐 아니라, SvelteKit, Nuxt, Remix, Astro 등 다양한 메타프레임워크들이 각자의 철학으로 SSR+CSR 혼합 모델을 추구하고 있습니다. 특히 Astro는 “바다 섬(Islands)” 아키텍처를 전면에 내세워, 기본적으로 모든 페이지를 SSR/정적으로 출력하되 꼭 필요한 인터랙티브 컴포넌트만 클라이언트에 로딩합니다.Qwik 같은 새로운 프레임워크는 아예 JS를 미리 분해해 두고 상호작용 시점에만 필요한 조각을 불러오는 방식을 도입하며 제로 JS 초기 페이로드를 실현하기도 합니다. 이러한 시도들은 “얼마나 최소한의 JS로 최대 UX를 뽑아낼 수 있는가”라는 공통된 목표를 지향합니다. 결국 향후 웹 프레임워크들의 경쟁 포인트는 성능 최적화(특히 초기 로드와 상호작용 지연 최소화)와 개발 편의성 두 가지가 될 것입니다. React+Next 조합은 개발자 인구와 생태계 면에서 우위를 가지고 있지만, 성능 면에서는 더 과감한 접근을 하는 신규 프레임워크의 아이디어를 받아들일 가능성이 높습니다. 예컨대 Next.js가 Speculation Rules나 View Transition을 내부적으로 활용하거나, React가 아예 빌드 타임에 뷰 전환 애니메이션을 CSS로 생성해주는 식의 플랫폼 친화적 최적화를 내장할 수 있습니다.

SSR vs CSR: 향후 균형과 선택 기준

미래에는 SSR과 CSR이 엄격히 대립하기보다는, 각 페이지와 컴포넌트의 성격에 맞게 혼재하는 아키텍처가 일반화될 것으로 보입니다. 웹 앱을 설계할 때 처음부터 SPA 일변도로 갈지, MPA로 갈지 결정하는 이분법은 점차 희미해지고, 요구에 따라 섬세하게 구성하는 방향입니다. 상호작용 많은 영역은 CSR로, 정적 콘텐츠 위주는 SSR/SSG로 처리하는 식의 판단이 프로젝트 내부에서도 이루어집니다. 예컨대 한 사이트 내에서도 대시보드 페이지는 SPA로 동작하고, 블로그나 마케팅 페이지는 MPA로 동작하는 식의 혼합형도 가능해질 것입니다. 이를 뒷받침하기 위해 React와 Next.js는 더 모듈화되고, 심지어 Micro-frontend 아키텍처와 접목되어 여러 기술 스택을 한데 묶는 유연성도 중요해질 것입니다.

마지막으로, 웹 플랫폼의 발전 속도가 빨라지고 있기 때문에 프레임워크들도 이에 발맞춰 변화할 것입니다. 브라우저가 지원하는 기능으로 충분히 구현 가능한 부분(예: 라우팅, 전환 애니메이션 등)은 프레임워크가 개입하지 않고 브라우저 기능에 위임하는 쪽으로 최적화될 것입니다. 실제로 “SPA의 가장 큰 존재 이유였던 부드러운 네비게이션은 이제 플랫폼이 해결했다”는 말처럼, 앞으로 프레임워크는 진짜 필요한 부분의 로직에만 집중하고 나머지는 웹 기본 기능을 활용하는 식으로 역할이 재정립될 것입니다. 개발자들은 최신 흐름을 따라가면서, 프로젝트의 실제 요구 사항에 맞는 기술 선택을 해야 합니다. 고도의 실시간 상호작용이 요구되는 애플리케이션이라면 향상된 CSR 기법과 SPA 구조를 택하되, 그렇지 않다면 더 가벼운 SSR/정적 구조로 가는 식의 판단이 중요해질 것으로 전망됩니다. 유행이나 관성에 치우치지 않고, 다양한 기법을 조합해 최적의 솔루션을 만드는 시대가 열리고 있는 것입니다.

결론

React와 Next.js를 중심으로 한 웹 앱 프레임워크 생태계는 향후에도 주도적인 위치를 유지하겠지만, 그 내부에서는 “적정량의 JS만 사용하고, 나머지는 플랫폼과 서버가 담당”하는 효율적 렌더링 전략이 핵심이 될 것입니다. 이는 곧 SSR과 CSR의 경계가 유동적으로 재편됨을 의미하며, 개발자는 2025년 이후의 웹에서는 필요한 만큼만 SPA를 구현하고 나머지는 MPA 철학에 맡기는 균형 잡힌 접근을 해야 할 것으로 전망됩니다.

결국 “웹답게 만든 웹사이트”가 성능과 유지보수성 면에서 승리할 것이며, 프레임워크들은 이를 돕는 방향으로 발전해갈 것입니다. 개발자라면 이러한 흐름을 주시하면서, 새로운 표준과 프레임워크 기능들을 활용해 빠르고 쾌적하며 SEO 친화적인 웹앱을 만들어야 할 것입니다. 현대 웹의 풍부한 도구상자 안에서 적절한 무기를 고르는 지혜가 요구되는 시대가 열리고 있습니다.