Vue + SSR 아키텍처 가이드

Vue + SSR은 단순히 서버에서 HTML을 한 번 만들어 주는 기술이 아닙니다. 렌더링 책임을 브라우저와 서버 사이에 다시 나누고, 초기 표시 속도, SEO, 캐시 전략, hydration 비용, 데이터 로딩 위치를 새로 설계하는 문제입니다. 그래서 SSR은 프레임워크 옵션이 아니라 아키텍처 선택에 가깝습니다.

아키텍처 그림 설명

[Incoming Request]
       |
       v
[SSR Entry / Route Match]
       |
       v
[Server Data Fetch]
       |
       +--> [Public Cacheable Data]
       +--> [User-specific Data]
       |
       v
[HTML Render]
       |
       v
[Browser Hydration]
       |
       v
[Client-side Interaction]

SSR에서 중요한 것은 서버가 HTML만 만드는 것이 아니라, 어떤 데이터를 렌더 전에 확정해야 하는지를 먼저 판단하는 점입니다. 공개 데이터와 사용자별 데이터를 같은 방식으로 다루면 캐시 전략이 무너지고, 반대로 모두 클라이언트로 미루면 SSR의 이점이 사라집니다. 그래서 이 구조는 렌더링과 캐싱을 함께 설계해야 안정적입니다.

Vue에서 SSR이 필요한 대표 상황

SSR은 다음 상황에서 가치가 큽니다.

공개 콘텐츠가 많고 검색 유입이 중요하다
첫 화면 표시 속도가 제품 성과에 큰 영향을 준다
공유 링크 미리보기와 메타데이터 품질이 중요하다
페이지마다 서버에서 준비된 데이터가 있어야 한다

반대로 대부분 로그인 후에만 쓰이고 SEO 중요도가 낮은 제품은 SPA가 더 단순할 수 있습니다.

SPA와 SSR의 가장 큰 차이

SPA는 브라우저가 애플리케이션을 부팅하고 데이터를 가져와 화면을 그립니다. SSR은 서버가 먼저 HTML을 만들고, 브라우저는 그 결과를 보여준 뒤 interactive 상태로 이어받습니다.

이 차이는 다음 구조적 변화를 만듭니다.

데이터 로딩 위치가 서버와 클라이언트로 나뉜다
캐시 전략이 브라우저 캐시만이 아니라 HTTP 캐시까지 확장된다
hydration 비용을 고려해야 한다
서버와 클라이언트에서 모두 안전하게 동작하는 코드가 필요하다

Vue SSR에서 Nuxt가 중요한 이유

순수 Vue로도 SSR을 구현할 수 있지만, 실무에서는 대부분 Nuxt 같은 프레임워크가 필요합니다. 라우팅, 데이터 패칭, 메타 태그, 서버 렌더링 파이프라인, 배포 모델을 직접 모두 구성하는 것은 비용이 크기 때문입니다.

Nuxt를 사용하면 SSR, SSG, hybrid rendering, route rules 같은 선택지를 더 실용적으로 가져갈 수 있습니다.

데이터 로딩은 “언제 어디서”가 핵심이다

SSR에서는 데이터 요청이 화면 렌더보다 앞설 수 있습니다. 이 점이 장점이지만, 동시에 서버 지연이 곧 초기 응답 지연이 되기도 합니다. 그래서 다음 판단이 중요합니다.

모든 데이터를 서버에서 기다릴 것인가
일부는 클라이언트에서 보충할 것인가
캐시 가능한 데이터와 실시간 데이터는 어떻게 다를 것인가
에러와 빈 상태는 서버/클라이언트 각각 어떻게 표현할 것인가

SSR에서는 데이터를 많이 미리 가져올수록 HTML은 풍부해지지만, TTFB가 길어질 수 있습니다.

Hydration 비용을 항상 의식해야 한다

서버가 HTML을 먼저 만들었다고 해서 끝이 아닙니다. 브라우저는 그 HTML 위에 Vue 애플리케이션을 다시 연결해야 합니다. 이 hydration 비용이 크면 사용자 입장에서는 “보이긴 빨리 보였는데 바로 반응하지 않는” 어색한 경험이 생길 수 있습니다.

그래서 SSR 프로젝트에서는 다음이 중요합니다.

정말 인터랙션이 필요한 부분만 복잡하게 만든다
큰 클라이언트 번들을 줄인다
무거운 위젯과 에디터는 지연 로딩한다
서버에서만 가능한 계산과 클라이언트 계산을 구분한다

캐시 전략이 SSR 품질을 크게 좌우한다

SSR은 매 요청마다 서버에서 전부 렌더링하면 비용이 큽니다. 그래서 HTTP 캐시, CDN 캐시, 페이지 단위 재생성, API 캐시를 함께 설계해야 합니다.

예를 들어 뉴스, 문서, 블로그처럼 변경 빈도가 낮은 페이지는 강한 캐시가 가능하지만, 개인화 대시보드는 캐시 전략이 완전히 달라집니다. SSR은 “서버에서 그린다”보다 “어떤 요청을 얼마나 재사용할 수 있는가”가 더 중요한 경우가 많습니다.

Vue SSR에서 자주 겪는 실수

실무에서는 다음 문제가 자주 보입니다.

브라우저 전용 API를 서버 코드에서 바로 사용한다
모든 데이터를 SSR로 가져와 응답 시간이 길어진다
hydration mismatch가 발생한다
캐시 무효화 전략 없이 동적 콘텐츠를 운영한다
SEO 목적이 약한 화면까지 SSR로 밀어 넣어 복잡도만 높인다

SSR은 강력하지만, 모든 화면에 일괄 적용하는 것이 항상 정답은 아닙니다.

Vue SSR이 잘 맞는 구조적 조건

Vue SSR은 특히 다음 조건에서 효과가 큽니다.

공개 페이지와 앱 성격이 혼합된 서비스
콘텐츠와 인터랙션이 모두 중요한 제품
브랜딩 페이지, 문서, 블로그, 커머스 상세처럼 초기 렌더 품질이 중요한 경우
서버와 프런트 인프라가 함께 협업 가능한 팀

마무리

Vue + SSR의 핵심은 “서버에서 렌더링한다”가 아니라, 초기 경험과 SEO와 캐시를 더 잘 설계한다는 데 있습니다. SPA보다 복잡하지만, 제품 요구가 맞는다면 훨씬 더 좋은 첫 인상과 구조적 장점을 줄 수 있습니다. 중요한 것은 SSR을 유행이 아니라 비용 대비 가치가 있는 렌더링 전략으로 보는 것입니다.

운영 환경에서 어려워지는 지점

SSR은 초기 로드와 인덱싱에 도움이 되지만 route 데이터 의존성, 캐시 동작, hydration 가정이 명확하지 않으면 시스템이 빠르게 어려워진다.
서버 런타임을 브라우저 앱처럼 다루면 공유 singleton이 요청 간 상태를 누수시킬 수 있다.
일부 페이지는 SSR처럼 보이고 일부는 사실상 client-only 가정에 기대는 혼합 경로가 생기면 전체를 이해하기 어려워진다.

중요한 아키텍처 결정

요청마다 새로운 app, router, store 인스턴스를 만든다.
HTML 완전성에 반드시 필요한 데이터와 hydration 이후 불러와도 되는 데이터를 나눈다.
store 상태와 민감한 데이터에 대한 직렬화 규칙을 명시적으로 둔다.

실무 예시

지속 가능한 SSR 부트스트랩은 요청 범위 생성과 렌더링을 분리한다.

export function createAppContext() {
  const app = createSSRApp(App)
  const router = createRouter()
  const pinia = createPinia()

  app.use(router)
  app.use(pinia)

  return { app, router, pinia }
}

피해야 할 안티패턴

요청 사이에서 프로세스 전역 가변 상태를 재사용하는 것.
SSR을 SEO 체크박스로만 보고 데이터 의존성과 캐시 설계를 건너뛰는 것.
서버 렌더 이점을 지워버릴 만큼 큰 직렬화 payload를 넣는 것.

운영 체크리스트

store, i18n, auth context의 요청 격리를 점검한다.
서버 렌더 지연과 hydration 비용을 분리해서 측정한다.
직렬화 크기와 escaping 규칙을 검증한다.
SSR HTML과 API 데이터의 캐시 무효화를 함께 테스트한다.

최종 판단

Vue SSR은 요청 격리와 HTML 완전성을 엄격하게 지킬 때 가치가 크다. 그렇지 않으면 실패 모드만 늘어난 복잡한 SPA가 되기 쉽다.

다음으로 읽기 좋은 글

🖥️ Frontend

AI 서비스 개발, 운영, 성능개선을 하나의 루프로 연결합니다