대규모 트래픽에서 프론트엔드 설계는 진짜 달라지나?

Frontend Architecture at Scale

Jun 24, 2026

ArchitectureRenderingNetworkPerformance

난이도: ★★☆☆☆
연관 노트: 크롤러가 CSR 페이지를 못 읽는 이유

핵심 요약

“프론트엔드는 대규모에서 설계가 안 달라진다”는 말은 절반만 맞다.
서버는 트래픽이 늘면 시스템이 직접 죽는다. 프론트엔드는 죽지 않는 대신 성능이 점진적으로 나빠진다.
대규모 환경에서 프론트엔드의 핵심 역할 중 하나는 서버로 가는 부하를 사전에 줄이는 것이다.

왜 이런 말이 나왔나

두 가지 관찰이 합쳐진 오해다.

관찰 1 (맞음): 서버는 트래픽이 폭증하면 DB 커넥션 고갈, 메모리 OOM, 응답 타임아웃이 직접 발생한다. 로드 밸런싱, 캐싱, 스케일 아웃, DB 샤딩 같은 깊은 인프라 경험이 필요하다.

관찰 2 (맞음): 사용자가 1명이든 100만 명이든, 브라우저에서 실행되는 JS 코드의 동작 방식은 동일하다.

틀린 결론: “그러니까 프론트엔드는 스케일에 따라 달라질 게 없다.”

개별 브라우저 실행 환경은 같지만, 전체 시스템 설계는 달라진다.

메커니즘

[트래픽 폭증]
      │
      ├───────────────────────────────────────────────┐
      │ 서버                                           │ 프론트엔드
      │                                               │
      │  요청 ↑ → DB 커넥션 고갈                       │  사용자 ↑ → 성능 저하 (점진적)
      │          메모리 OOM                            │  코드 ↑  → 빌드 시간 폭증
      │          응답 타임아웃                          │  팀 ↑   → 배포 병목, DX 붕괴
      │             ↓                                  │             ↓
      │       [즉각적 장애]                             │      [점진적 악화]
      └───────────────────────────────────────────────┘

프론트엔드가 서버 부하를 줄이는 4가지 전략

사용자 요청
    │
    ├── 1. 요청 자체를 줄인다 ─────────────────────────────────
    │       디바운스/쓰로틀링 → 검색창 입력마다 API 호출하지 않음
    │
    ├── 2. 이미 받은 데이터를 재활용한다 ──────────────────────
    │       React Query / SWR 클라이언트 캐시
    │       → 같은 데이터 두 번 서버에 묻지 않음
    │
    ├── 3. 정적 파일을 서버 대신 CDN에서 서빙한다 ────────────
    │       HTML, JS, CSS, 이미지
    │       WAS에서 직접 서빙하면 트래픽 폭증 시 서버 다운
    │       CDN → 서버 도달 전에 처리
    │
    └── 4. 렌더링 전략을 조정한다 ──────────────────────────────
            SSR 과부하 → ISR 캐싱으로 origin 요청 최소화

주의: 흔한 오해 — “연산을 클라이언트로 옮기면 서버 부담이 줄어든다”

서버 CPU 부담을 줄이려고 정렬·필터를 클라이언트로 옮기는 접근은 역효과가 날 수 있다.

❌ 잘못된 접근
  서버 → 전체 데이터 내려보냄
  클라이언트 → JS로 정렬/필터

  문제:
  1. 전체 데이터 전송 → 네트워크 비용 증가
  2. 저사양 기기에서 메인 스레드 블로킹 → 오히려 UX 악화
  3. 보안: 클라이언트 필터링은 표시용, 서버 검증은 여전히 필수

✅ 올바른 접근
  서버에서 페이지네이션 + 필터링 → 클라이언트는 표시만
  React Query 캐싱으로 중복 요청 차단

다음에 이 상황을 만나면

“이 기능, 사용자 많아지면 서버에 부담 안 줄까?” → 아래 순서로 점검

불필요한 API 호출이 있는가? → 디바운스/쓰로틀링 적용
같은 데이터를 반복 요청하는가? → React Query 캐싱
정적 파일이 WAS를 타고 있는가? → CDN 서빙으로 분리
SSR 서버 부담이 큰가? → ISR 캐싱 전략 검토

커넥팅 닷

← 선행 개념 (이걸 알아야 이해된다)

크롤러가 CSR 페이지를 못 읽는 이유 — CSR/SSR/SSG 각 방식의 차이를 알아야 렌더링 전략 선택 기준이 잡힘
HTTP Cache-Control 헤더 — CDN이 origin 요청을 줄이는 원리. max-age, s-maxage, stale-while-revalidate 차이가 핵심
Critical Rendering Path — FCP/LCP가 느린 구조적 원인. 렌더링 방식 선택의 근거

→ 확장 개념 (여기서 더 나아가면)

ISR (Incremental Static Regeneration) — SSR 서버 부담과 SSG stale 문제를 동시에 해결하는 패턴
Core Web Vitals (LCP/CLS/INP) — 사용자 증가에 따른 성능 저하를 측정하는 공식 지표. SEO에 직결

↔ 같은 원리가 적용되는 곳

왜 서버는 이전 요청을 기억하지 않는가 — HTTP stateless 원리가 CDN 캐싱과 연결됨. 요청마다 독립적이라는 특성을 역이용해 캐시로 반복 요청을 차단
React Query stale-while-revalidate — CDN의 stale-while-revalidate와 동일한 원리. 캐시된 것을 먼저 보여주고, 백그라운드에서 갱신

참고

Web Vitals — Google Core Web Vitals 공식 문서