SSR에 기능 더하기
SSR의 기본 원리는 서버에서 HTML을 만들어서 보내는 것이에요. 그런데 HTML만 보내면 버튼을 클릭해도 아무 일도 일어나지 않아요.
이번 장에서는 이 문제를 해결하고, SSR에 필요한 기능들을 하나씩 붙여볼게요.
이 장의 흐름
이 장의 모든 문제는 하나의 근본 제약에서 비롯돼요:
“네트워크는 문자열만 전송할 수 있다”
이게 직렬화(Serialization)의 본질이에요. 서버에서 클라이언트로 데이터를 보내려면 문자열로 변환해야 하는데, 모든 것이 문자열이 되는 건 아니에요.
기능 | 문제 | 직렬화와의 관계 |
Hydration | 이벤트 핸들러가 안 넘어감 | 함수는 직렬화 불가 |
데이터 페칭 | 데이터는 되지만 제한 있음 | Date, 클래스 인스턴스 등 불가 |
라우팅 | URL에 따라 다른 페이지 | 경로 = 문자열 (이건 문제 없음) |
SSG/ISR | 매번 렌더링이 비효율 | 결과물(HTML) 캐싱 |
이 문제들은 순서가 있어요:
1. 먼저 기본 인터랙션을 해결하고 (Hydration)
2. 여러 페이지로 확장하고 (라우팅)
3. 데이터를 추가하고 (데이터 페칭)
4. 효율을 높여요 (SSG, ISR)
각 섹션을 읽을 때 “이것도 결국 직렬화 제약 때문이구나”라고 생각하면 전체 그림이 보여요.
이 장에서 다루는 내용
장 | 주제 | 핵심 질문 |
4-1 | 서버 HTML에 어떻게 인터랙션을 붙이나? | |
4-2 | URL에 따라 다른 컴포넌트를 어떻게 보여주나? | |
4-3 | 렌더링 전에 데이터를 어떻게 가져오나? | |
4-4 | 빌드 시점에 HTML을 미리 만들 수 있나? | |
4-5 | SSG의 한계를 어떻게 극복하나? |
학습 순서
4-1 → 4-2 → 4-3은 독립적으로 읽어도 돼요.
4-4(SSG) → 4-5(ISR)는 순서대로 읽는 게 좋아요.
정리: 직접 구현으로 본 SSR
이 장에서 다루는 내용을 한눈에 정리하면:
문제 | 해결책 | 핵심 |
이벤트가 안 되는데? | Hydration | hydrateRoot로 이벤트 핸들러 연결 |
URL이 여러 개면? | 라우팅 | URL별 다른 컴포넌트 렌더링 |
데이터가 필요하면? | 데이터 페칭 | 렌더링 전 fetch → props 전달 |
매번 렌더링이 비효율적 | SSG | 빌드 시 renderToString → 파일 저장 |
정적 파일 업데이트가 어려움 | ISR | 캐시 + TTL + 백그라운드 재생성 |
각각이 별개의 기능처럼 보이지만, 모두 “서버에서 HTML을 만들어서 보내는” 기본 원리 위에 쌓인 것들이에요.
