Angular 렌더링 전략

이 문서에서는 Angular 애플리케이션의 각 부분에 적합한 렌더링 전략을 선택하는 방법을 알아봅니다.

렌더링 전략이란?

렌더링 전략은 Angular 애플리케이션의 HTML 내용을 언제, 어디서 생성할지 결정합니다. 각 전략은 초기 페이지 로딩 성능, 상호작용, SEO 기능, 서버 자원 사용량 측면에서 서로 다른 장단점이 있습니다.

Angular는 세 가지 주요 렌더링 전략을 지원합니다.

• 클라이언트 사이드 렌더링(CSR) — 모든 내용을 브라우저에서 렌더링합니다.
• 정적 사이트 생성(SSG/프리렌더링) — 빌드 시점에 내용을 미리 렌더링합니다.
• 서버 사이드 렌더링(SSR) — 라우팅 규칙의 첫 요청을 처리할 때 서버에서 내용을 렌더링합니다.

클라이언트 사이드 렌더링(CSR)

CSR은 Angular의 기본 방식입니다. JavaScript가 로드된 뒤 모든 내용을 브라우저에서 렌더링합니다.

CSR을 사용하기 좋은 경우

✅ 다음과 같은 경우에 적합할 수 있습니다.

• 상호작용이 많은 애플리케이션(대시보드, 관리자 화면)
• 실시간 애플리케이션
• SEO가 중요하지 않은 내부 도구
• 클라이언트 상태가 복잡한 싱글 페이지 애플리케이션

❌ 다음과 같은 경우에는 가능하면 다른 방식을 고려하세요.

• SEO가 필요한 공개 콘텐츠
• 초기 로딩 성능이 중요한 페이지

CSR의 장단점

정적 사이트 생성(SSG/프리렌더링)

SSG는 빌드 시점에 페이지를 정적 HTML 파일로 미리 렌더링합니다. 서버는 첫 페이지 요청에 미리 생성한 HTML을 전송합니다. 하이드레이션이 완료되면 기존 SPA처럼 애플리케이션 전체가 브라우저에서 실행됩니다. 이후 내비게이션, 라우팅 규칙 변경, API 호출은 서버 렌더링 없이 모두 클라이언트에서 처리됩니다.

SSG를 사용하기 좋은 경우

✅ 다음과 같은 경우에 적합할 수 있습니다.

• 마케팅 페이지와 랜딩 페이지
• 블로그 게시물과 문서
• 내용이 자주 바뀌지 않는 상품 카탈로그
• 사용자별로 달라지지 않는 콘텐츠

❌ 다음과 같은 경우에는 가능하면 다른 방식을 고려하세요.

• 사용자별 콘텐츠
• 자주 바뀌는 데이터
• 실시간 정보

SSG의 장단점

📖 구현 방법: SSR 가이드의 빌드 시점 프리렌더링 조정하기를 참고하세요.

서버 사이드 렌더링(SSR)

SSR은 라우팅 규칙의 첫 요청을 처리할 때 서버에서 HTML을 생성하므로 동적 콘텐츠와 좋은 SEO를 함께 제공합니다. 서버가 HTML을 렌더링해서 클라이언트에 전송합니다.

클라이언트가 페이지를 렌더링하면 Angular가 애플리케이션에 하이드레이션을 적용합니다. 이후에는 기존 SPA처럼 애플리케이션 전체가 브라우저에서 실행됩니다. 추가 서버 렌더링 없이 이후 내비게이션, 라우팅 규칙 변경, API 호출을 모두 클라이언트에서 처리합니다.

SSR을 사용하기 좋은 경우

✅ 다음과 같은 경우에 적합할 수 있습니다.

• 전자상거래 상품 페이지(동적 가격과 재고)
• 뉴스 사이트와 소셜 미디어 피드
• 자주 바뀌는 개인화 콘텐츠

❌ 다음과 같은 경우에는 가능하면 다른 방식을 고려하세요.

• 정적 콘텐츠(SSG를 사용하세요)
• 서버 비용이 부담되는 경우

SSR의 장단점

📖 구현 방법: SSR 가이드의 서버 라우팅과 서버와 호환되는 컴포넌트 작성하기를 참고하세요.

적합한 전략 선택하기

선택 기준

하이드레이션으로 SSR/SSG에 상호작용 추가하기

SSR이나 SSG를 사용할 때 Angular는 서버가 렌더링한 HTML에 "하이드레이션"을 적용해서 상호작용할 수 있도록 만듭니다.

사용할 수 있는 전략:

• 전체 하이드레이션 — 애플리케이션 전체가 한 번에 상호작용 가능한 상태가 됩니다(기본값).
• 점진적 하이드레이션 — 필요한 부분부터 상호작용 가능한 상태가 됩니다(성능 개선).
• 이벤트 재생 — 하이드레이션이 완료되기 전에 발생한 클릭을 수집합니다.

📖 더 알아보기:

• 하이드레이션 가이드 — 전체 하이드레이션 설정
• 점진적 하이드레이션 — @defer 블록을 사용하는 고급 하이드레이션

다음 단계