서민혁닷컴

IT 시행착오·

정적 사이트 vs SSR — 언제 무엇을 고를까

블로그, 랜딩 페이지, 대시보드, 앱 확장에서 정적 사이트와 서버 사이드 렌더링을 어떻게 선택할지 성능·비용·운영 기준으로 정리합니다.

클라이언트-서버 N-tier 아키텍처 — 정적 vs SSR (cc by-sa 4.0, wikimedia-commons)

웹사이트를 만들 때 “정적 사이트로 충분한가, SSR이 필요한가”는 자주 나오는 질문입니다. 정적 사이트는 빌드할 때 HTML을 미리 만들어 CDN에서 빠르게 제공하는 방식이고, SSR은 사용자가 요청할 때 서버가 HTML을 만들어 응답하는 방식입니다. 둘 중 하나가 항상 더 좋은 것은 아닙니다. 콘텐츠 성격, 사용자별 데이터, 배포 빈도, 운영 인력, 캐시 전략에 따라 선택이 달라집니다.

블로그나 문서 사이트를 운영한다면 정적 사이트가 단순하고 빠른 출발점이 되는 경우가 많습니다. 반면 로그인 후 사용자마다 다른 데이터를 보여 주는 대시보드나, 요청 시점의 최신 재고·가격·권한을 반영해야 하는 앱은 SSR이나 API 기반 렌더링이 필요할 수 있습니다.

1. 정적 사이트란 무엇인가

정적 사이트는 빌드 시점에 HTML, CSS, JavaScript, 이미지 같은 파일을 만들어 둡니다. 사용자가 접속하면 서버가 코드를 실행해 HTML을 만드는 것이 아니라, 이미 만들어진 파일을 그대로 전달합니다. Astro, Hugo, Jekyll, Eleventy, Next.js static export 같은 도구가 이 방식에 잘 맞습니다.

정적 사이트의 장점은 분명합니다.

  • CDN 캐시와 궁합이 좋아 매우 빠르다.
  • 서버 런타임이 단순해 장애 지점이 적다.
  • 트래픽이 늘어도 비용이 예측 가능하다.
  • 보안 면에서 공격 표면이 비교적 작다.
  • 블로그, 문서, 랜딩 페이지, 포트폴리오에 잘 맞는다.

예를 들어 Markdown 글을 작성하고 빌드하면 /posts/static-vs-ssr 같은 HTML이 생성됩니다. 방문자는 가까운 CDN 엣지에서 파일을 받으므로 응답 속도가 빠릅니다. 서민혁닷컴처럼 IT 시행착오를 정리하는 블로그라면 Markdown으로 기술 블로그 운영하기와 정적 배포 조합이 운영 부담을 줄여 줍니다.

2. SSR은 무엇을 해결하는가

SSR은 Server-Side Rendering의 줄임말입니다. 사용자가 페이지를 요청하면 서버가 데이터베이스나 API에서 데이터를 읽고, 그 결과로 HTML을 만들어 보냅니다. Next.js, Nuxt, SvelteKit, Remix 같은 프레임워크에서 흔히 사용합니다.

SSR이 필요한 대표적인 상황은 다음과 같습니다.

  • 로그인한 사용자마다 다른 화면을 보여 줘야 한다.
  • 권한에 따라 노출되는 메뉴와 데이터가 달라진다.
  • 가격, 재고, 예약 가능 여부처럼 요청 시점의 최신성이 중요하다.
  • 검색 조건과 필터에 따라 서버에서 데이터를 조합해야 한다.
  • SEO가 필요한 동적 페이지가 매우 많고 자주 바뀐다.
  • A/B 테스트나 지역별 개인화가 서버에서 결정된다.

SSR은 유연하지만 운영 복잡도도 늘어납니다. 서버 런타임, 캐시 무효화, DB 연결, 장애 대응, 콜드 스타트, 배포 롤백을 고려해야 합니다. 정적 사이트보다 “돌아가는 코드”가 많으므로 보안과 모니터링도 더 중요해집니다.

3. 선택 기준은 콘텐츠의 개인화 정도다

가장 쉬운 질문은 “이 페이지가 모든 사용자에게 같은가?“입니다. 대부분의 사용자에게 같은 HTML을 보여 준다면 정적 사이트가 적합합니다. 사용자별로 다른 이름, 권한, 주문 내역, 알림, 설정을 보여 줘야 한다면 SSR 또는 클라이언트 API 호출이 필요합니다.

다음 기준으로 판단해 보세요.

상황 추천 방식
회사 소개, 가격 안내, 블로그 정적 사이트
문서, 도움말, 릴리스 노트 정적 사이트
로그인 없는 마케팅 페이지 정적 사이트
로그인 후 개인 대시보드 SSR 또는 CSR+API
사용자별 추천 콘텐츠 SSR 또는 API 기반 렌더링
실시간 재고·예약 SSR 또는 서버 API
관리자 화면 SSR, CSR, 내부 앱 구조

정적 사이트에서도 완전히 동적인 기능을 못 하는 것은 아닙니다. 댓글, 검색, 문의 폼, 결제 버튼은 외부 API나 클라이언트 JavaScript로 붙일 수 있습니다. 핵심 콘텐츠가 정적이고 일부 기능만 동적이라면 정적 사이트에 API를 조합하는 방식이 단순합니다.

4. 성능은 정적이 유리하지만 조건이 있다

정적 사이트는 HTML을 바로 제공하므로 TTFB가 짧고 캐시가 잘 먹습니다. Core Web Vitals 관점에서도 첫 응답이 빠른 편입니다. 하지만 이미지가 너무 크거나, 불필요한 JavaScript를 많이 싣거나, 외부 스크립트가 렌더링을 막으면 정적 사이트도 느려집니다.

SSR은 서버가 HTML을 만들어야 하므로 요청 처리 시간이 생깁니다. 데이터베이스 쿼리가 느리거나 외부 API를 기다리면 사용자는 빈 화면을 오래 보게 됩니다. 대신 SSR은 사용자에게 필요한 데이터가 담긴 HTML을 바로 줄 수 있어, 잘 설계하면 앱의 초기 경험을 좋게 만들 수 있습니다.

성능을 비교할 때는 다음 항목을 함께 봐야 합니다.

  • TTFB: 첫 바이트가 얼마나 빨리 오는가
  • LCP: 주요 콘텐츠가 언제 보이는가
  • JavaScript 크기: 브라우저 실행 비용이 큰가
  • 캐시 적중률: 같은 페이지를 CDN에서 제공할 수 있는가
  • API 대기 시간: 렌더링 전에 필요한 데이터가 얼마나 느린가
  • 이미지 최적화: 화면 크기에 맞는 파일을 쓰는가

느린 원인을 직접 확인하려면 브라우저 개발자도구로 네트워크 병목 찾는 법을 참고해 Network 패널에서 요청 순서와 크기를 살펴보세요.

5. 비용과 운영 난이도 비교

정적 사이트는 대체로 저렴합니다. 빌드된 파일을 CDN이나 객체 스토리지에 올리면, 요청이 늘어도 서버 실행 비용이 크게 늘지 않습니다. 운영자가 한 명인 블로그, 초기 스타트업 랜딩 페이지, 문서 사이트는 이 단순함이 큰 장점입니다.

SSR은 요청마다 서버가 일합니다. 서버리스 함수, 엣지 런타임, Node 서버 등 형태는 다양하지만, 결국 실행 시간과 요청 수에 따라 비용이 발생합니다. 데이터베이스 연결 풀, API 제한, 캐시, 로그, 장애 알림도 관리해야 합니다.

운영 체크리스트는 다음처럼 다릅니다.

정적 사이트 운영 체크리스트

  • 빌드가 실패하면 배포가 멈추는가
  • 콘텐츠 변경 후 캐시가 언제 갱신되는가
  • 이미지와 자산에 긴 캐시를 적용했는가
  • 404 페이지와 리다이렉트가 정리되어 있는가
  • 검색 엔진용 sitemap과 robots.txt가 있는가

SSR 운영 체크리스트

  • 서버 오류와 느린 요청을 모니터링하는가
  • DB 연결 수 제한을 이해하고 있는가
  • 인증·권한 체크가 서버에서 확실히 적용되는가
  • 캐시 키와 무효화 조건이 명확한가
  • 배포 중 롤백과 장애 대응 절차가 있는가

6. SEO 관점에서의 차이

정적 사이트는 SEO에 강합니다. 이미 만들어진 HTML에 제목, 설명, 본문, 구조화 데이터가 들어 있으므로 검색 엔진이 읽기 쉽습니다. 블로그, 문서, 지식 베이스는 정적 사이트만으로 충분한 경우가 많습니다.

SSR도 SEO에 좋을 수 있습니다. 특히 상품 상세, 지역별 페이지, 동적 검색 결과처럼 데이터가 자주 바뀌지만 검색 노출이 중요한 페이지에 유용합니다. 다만 요청마다 HTML을 만들어야 하므로 캐시 전략이 중요합니다.

주의할 점은 CSR만으로 만든 페이지입니다. 클라이언트 JavaScript가 실행된 뒤 콘텐츠가 나타나는 구조는 검색 엔진과 공유 미리보기에서 불리할 수 있습니다. 요즘 검색 엔진은 JavaScript를 어느 정도 처리하지만, 중요한 콘텐츠는 가능한 한 초기 HTML에 포함하는 것이 안전합니다.

7. 혼합 구조가 현실적이다

실무에서는 정적과 SSR을 완전히 나누기보다 섞어 씁니다. 예를 들어 다음 구조가 흔합니다.

  • / 랜딩 페이지: 정적
  • /blog 기술 글: 정적
  • /docs 도움말: 정적
  • /app 로그인 앱: SSR 또는 CSR
  • /api 데이터 처리: 서버 함수
  • /admin 관리자 화면: 인증이 필요한 동적 앱

이 방식은 서비스 성장에 유리합니다. 처음에는 정적 블로그로 시작하고, 앱이 필요해지면 /app 또는 app.example.com으로 분리할 수 있습니다. 도메인 구조 확장은 서브도메인으로 서비스 나누는 이유에서 자세히 다룹니다.

8. 언제 정적 사이트를 선택할까

다음 조건이 많다면 정적 사이트를 고르세요.

  • 콘텐츠가 글, 문서, 소개 페이지 중심이다.
  • 모든 방문자가 거의 같은 화면을 본다.
  • 운영자가 적고 서버 관리 부담을 줄이고 싶다.
  • 검색 노출과 빠른 로딩이 중요하다.
  • 배포 빈도가 하루 몇 번 이하이고 즉시성 요구가 낮다.
  • 댓글, 폼, 검색은 외부 서비스나 API로 처리해도 된다.

정적 사이트는 “작은 서비스용”이 아니라 “캐시 가능한 콘텐츠용”입니다. 큰 회사의 문서 사이트와 마케팅 페이지도 정적 구조를 많이 씁니다. 단순함은 규모가 작을 때뿐 아니라 규모가 커질 때도 유지보수 비용을 줄여 줍니다.

9. 언제 SSR을 선택할까

다음 조건이 많다면 SSR을 검토하세요.

  • 로그인 사용자마다 HTML이 달라진다.
  • 권한과 결제 상태에 따라 콘텐츠가 달라진다.
  • 데이터 최신성이 매우 중요하다.
  • 서버에서 SEO용 동적 페이지를 대량 생성해야 한다.
  • API 응답을 조합해 초기 화면을 완성해야 한다.
  • 캐시되지 않는 요청이 많아도 운영할 준비가 되어 있다.

SSR을 선택했다면 캐시 전략을 먼저 설계해야 합니다. 모든 요청을 매번 새로 렌더링하면 비용과 응답 시간이 늘어납니다. 페이지 단위 캐시, 데이터 캐시, ISR, 엣지 캐시, 사용자별 비공개 캐시를 구분해 적용하세요.

마무리

정적 사이트와 SSR의 선택은 기술 취향보다 요구사항의 문제입니다. 모두에게 같은 콘텐츠라면 정적 사이트가 빠르고 단순합니다. 사용자별 데이터와 실시간성이 중요하면 SSR이나 API 기반 구조가 필요합니다. 처음부터 복잡한 서버 구조를 만들기보다, 정적으로 가능한 영역과 동적으로 필요한 영역을 나눠 생각하세요.

블로그, 문서, 랜딩 페이지는 정적으로 시작하고, 로그인 앱과 관리자 기능은 별도 경로나 서브도메인으로 확장하는 전략이 실무적으로 안전합니다. 이렇게 나누면 성능, 비용, 보안, 배포 책임을 각각 관리할 수 있고, 서비스가 커져도 구조를 설명하기 쉬워집니다.