SSR은 반드시 필요할까?

Next.js를 처음 배울 때 SSR(Server Side Rendering)은 항상 “좋은 것”으로 소개된다.
SEO에 유리하고, 초기 로딩이 빠르며, 서버에서 HTML을 만들어 내려준다는 점에서 매력적인 기술처럼 보인다.

나 역시 처음에는 “중요한 페이지는 SSR로 처리해야 한다”고 자연스럽게 생각했다.
하지만 실제로 부하 테스트를 해보고 나서 생각이 완전히 바뀌었다.

SSR과 ISR 간단 개념

SSR (Server Side Rendering)

SSR은 요청이 들어올 때마다 서버에서 HTML을 새로 생성해 내려주는 방식이다.

• 요청마다 데이터 패칭 및 렌더링 발생
• 사용자별 맞춤 페이지에 적합
• 트래픽이 늘어날수록 서버 부하가 급격히 증가

ISR (Incremental Static Regeneration)

ISR은 정적 HTML을 캐시로 제공하면서,
설정한 주기마다 백그라운드에서 페이지를 다시 생성하는 방식이다.

• 대부분의 요청은 캐시된 HTML을 반환
• 재검증 시점에만 서버 렌더링 수행
• 정적 페이지의 성능 + 서버 렌더링의 유연성을 동시에 제공

Artillery로 SSR / ISR 간단한 부하 테스트

SSR과 ISR의 차이를 체감하기 위해
간단한 부하 테스트 도구로 Artillery를 사용했다.

Artillery는 Node.js 기반의 오픈소스 부하 테스트 도구로,
YAML 설정 파일만 작성하면 HTTP 요청 부하를 쉽게 시뮬레이션할 수 있다.

Artillery 설치

Node.js 환경에서 아래 명령어로 전역 설치할 수 있다.

npm install -g artillery

테스트에 사용한 Artillery 설정 (.yml 파일)

테스트에서는 상품 상세 페이지에 대한 단순 GET 요청만 반복했다.
SSR / ISR 페이지의 순수 서버 응답 차이를 보기 위함이었다.

config:
  target: "http://localhost:3000"
  phases:
    - duration: 10
      arrivalRate: 50 # 초당 50명 접속

scenarios:
  - name: "Product detail page load"
    flow:
      - get:
          url: "/product/668ad20ace70c4eb38bd8575"

위 테스트는 10초 동안 총 500명 이상의 사용자가 동시에 상품 상세 페이지에 접속하는 상황을 가정한 테스트다.

테스트 환경

• Next.js 16 (App Router)
• 배포 환경: Vercel (Free Plan)
• 데이터베이스: MongoDB Atlas (Free Tier)
• 상품 상세 페이지: DB 조회 + 서버 렌더링
• ISR 재검증 시간: 60초

테스트 실행

설정 파일을 예를 들어 test.yml로 저장한 뒤,
아래 명령어로 바로 실행할 수 있다.

artillery run test.yml

동일한 조건에서 비교하기 위해, 하나의 상품 상세 페이지를 SSR과 ISR 두 가지 방식으로 구현하고 각각 부하 테스트를 진행했다.

테스트 결과

테스트 결과 비교 표

항목	SSR 페이지	ISR 페이지	개선율
평균 응답 시간	59.2ms	3.4ms	약 17배 단축
p95 응답 시간	172.5ms	4ms	약 43배 단축
최대 응답 시간	279ms	86ms	약 3배 단축
요청 처리 속도	31 req/sec	60 req/sec	약 2배 증가
실패 요청	1건 (ETIMEDOUT)	0건	안정성 확보

SSR 페이지는 대부분의 요청을 처리하긴 했지만, 요청 처리 속도가 낮았고 일부 요청에서 타임아웃이 발생했다. 응답 시간 편차도 상대적으로 컸다.

ISR 페이지는 모든 요청을 안정적으로 처리했고, 응답 시간도 매우 짧고 일정하게 유지되었다.

결과 해석

기존 SSR 방식은 초당 50명의 동시 접속 상황에서 일부 타임아웃(Timeout)이 발생하고 응답 시간이 불안정했다.
반면, ISR로 전환 후에는 모든 요청을 4ms 이내(p95 기준)로 처리하며, 트래픽이 몰리는 상황에서도 매우 안정적이고 빠른 성능을 보여주었다.
이는 SSR이 요청마다 서버에서 렌더링을 수행하는 반면, ISR은 캐시된 정적 HTML을 제공하기 때문에 발생한 구조적 차이에서 비롯된 결과이다.

그럼 SSR은 언제 사용해야할까?

SSR은 다음 조건을 여러 개 동시에 만족할 때만 고려하는 것이 좋다.

• 사용자별로 HTML 내용이 완전히 달라야 한다.
• 첫 HTML에 반드시 최신 데이터가 포함되어야 한다.
• SEO가 정말 중요하다.
• 트래픽이 많지 않다.
• 캐시 전략을 적용하기 어렵다.

SSR을 사용하면 좋은 대표적인 예시는 다음과 같다.

• 실시간 데이터가 제공되어야 하는 페이지
• 권한에 따라 콘텐츠 자체가 달라지는 페이지
• 개인화된 금융 및 대시보드 페이지

반대로,
“상품 상세 페이지”, “콘텐츠 페이지”, “마케팅 페이지”처럼
모든 사용자가 거의 동일한 화면을 보는 페이지는 SSR보다는 ISR 또는 CSR이 훨씬 안전한 선택이다.

SSR은 무조건적인 해결책이 아닌 정합성과 개인화가 최우선일 때 사용하는 특수한 도구에 가깝다.

마무리

SSR은 분명 강력한 기술이다. 하지만 동시에 아주 비싼 기술이기도 하다.

SSR은 기본값이 아니라, 최후의 선택지에 가깝다.

SSR을 적용하기 전 ISR, CSR를 한 번 더 고려해보면 좋을 것 같다.

이번 부하 테스트와 ISR 페이지 전환 경험을 통해 “SSR이 좋다”는 말보다
“SSR은 언제 쓰면 안 되는가”를 더 많이 배웠다.
이 글이 SSR을 고민하는 누군가에게 한 번쯤 멈춰서 생각해볼 계기가 되었으면 좋겠다.