타임리프에서 SPA로? SSR과 CSR 개념 정리

프로젝트에서 타임리프(Thymeleaf)로 서버 템플릿 기반의 프론트엔드를 만들다가, 좀 더 동적인 화면과 사용자 경험을 위해 SPA(Single Page Application)로 전환하고 싶다는 생각이 들었다. 그러다 보니 자연스럽게 SSR(서버사이드 렌더링)과 CSR(클라이언트사이드 렌더링)이라는 용어도 자주 접하게 됐다.

이번 글에서는 SSR과 CSR, 그리고 SPA가 각각 무엇이고, 이들이 어떻게 연결되는지 정리해보려고 한다.

SPA, SSR, CSR 용어 정리

1. SPA (Single Page Application)

• 한 번만 페이지 전체를 받아오고, 이후에는 새로고침 없이 동적으로 화면을 바꾸는 웹앱 구조
• 대표적으로 React, Vue, Angular 같은 프레임워크가 SPA를 구현할 때 많이 쓰인다
• 장점: 빠른 화면 전환, 앱 같은 사용자 경험
• 단점: 초기 로딩이 느릴 수 있고, SEO(검색엔진 최적화)가 어렵다

2. CSR (Client Side Rendering)

• 화면 렌더링(HTML 생성)을 브라우저(클라이언트)에서 JavaScript로 처리하는 방식
• 서버는 데이터를 API로만 전달하고, 실제로 화면을 그리는 건 클라이언트가 담당
• SPA는 기본적으로 CSR을 기반으로 동작한다
• 장점: 서버 부담이 적고, 사용자와의 상호작용이 빠르다
• 단점: 초기 로딩이 느릴 수 있고, JS가 비활성화된 환경에서는 제대로 동작하지 않는다

3. SSR (Server Side Rendering)

• 화면 렌더링을 서버에서 미리 HTML로 만들어서 클라이언트에 보내주는 방식
• 타임리프, JSP, EJS 등 서버 템플릿 엔진이 대표적인 SSR 방식
• 최근에는 React, Vue 같은 SPA 프레임워크도 Next.js, Nuxt.js 등으로 SSR을 지원한다
• 장점: 초기 로딩 속도가 빠르고, SEO에 유리하다
• 단점: 서버 부하가 크고, 사용자와의 빠른 상호작용에는 한계가 있다

SPA, CSR, SSR의 관계와 차이

• SPA와 CSR은 완전히 같은 개념은 아니다
  • SPA는 "앱의 구조(한 페이지에서 동적으로 화면이 바뀜)"를 의미하고,
  • CSR은 "렌더링을 어디서 하냐(클라이언트에서 함)"를 의미한다
  • SPA는 주로 CSR을 사용하지만, SSR을 일부 적용한 하이브리드 방식도 있다(예: Next.js)
• SSR은 전통적인 서버 템플릿 방식(타임리프, JSP 등)과도 연결된다
  • 서버에서 HTML을 렌더링해서 보내주기 때문에, 초기 화면이 빠르고 검색엔진에도 잘 노출된다

나의 고민과 앞으로의 방향

타임리프 기반 SSR에서 SPA로 전환하려면,
결국 "SSR → CSR 구조로 바꿀 것인가?"를 고민하게 된다.
이때 각각의 장단점(초기 로딩 속도, SEO, 사용자 경험 등)을 잘 비교해서 선택하는 게 중요하다.