요즘 웹 서비스를 보면 Next.js를 사용한 경우를 많이 봅니다.
이 기술이 널리 사용된 것은 LLM의 유행보다 더 오래되긴 했지만 LLM이 React + Next.js 조합으로 된 코드를 많이 출력하면서 요즘 들어 부쩍 그 수가 늘어나는 것 같습니다. 그런데 대부분의 웹 서비스들이 콘텐츠 위주의 페이지가 많다는 점을 생각해보면 더 단순하고 정적 사이트 제작에 중점을 두는 Astro가 어울리는 경우가 많습니다.
Astro와 Next.js는 겹치는 영역이 많지만 정적 사이트(SSG)를 중심으로 SSR을 지원하는 Astro와 SSR 때문에 크게 주목받기 시작한 Next.js는 실제 개발과 운영에서 복잡도의 차이가 큽니다.
대개 정적 콘텐츠는 기획할 때 어느 정도 결정이 됩니다. 동적인 부분을 어떻게 처리할지에 따라 사용할 기술과 아키텍처가 결정되는데, 이 시점에 Astro는 유연한 선택지가 많아 고민을 줄일 수 있습니다.
페이지 단위나 컴포넌트 단위로 React, Vue, Svelte 같은 기술을 선택할 수 있고(물론 함께 쓸 수도 있지만 실무에서 그렇게 배포하는 경우는 없을 겁니다. 하지만 초반에 탐색해보기엔 용이하죠.), SSG와 SSR을 섞어 쓸 수 있으니 말입니다.
콘텐츠 중심 사이트를 만들 때 가장 먼저 고민하는 지점은 “이 페이지를 언제 만들어야 하는가”입니다. Astro에서 SSG와 SSR은 대립 관계가 아니라, 페이지 성격에 따라 골라 쓰는 두 개의 도구라고 보는 편이 실용적입니다.
렌더링 모드의 선택 기준
판단의 기준은 크게 세 가지입니다. 이 페이지가 누구에게 보여지는가(로그인 여부), 얼마나 자주 바뀌는가, 그리고 첫 화면 속도가 얼마나 중요한가입니다.
- 공개되고 자주 바뀌지 않는다 → SSG
- 로그인한 사용자별로 내용이 다르다 → SSR
- 실시간 데이터가 필요하다 → SSR + 클라이언트 요청
콘텐츠 페이지는 SSG로
빌드 시점에 생성되는 SSG 페이지는 정적 파일이므로 CDN 캐시에 그대로 올라갑니다. 첫 화면에 네트워크 왕복이 필요 없어 체감 속도가 좋습니다.
---
// Astro 프로젝트: 기본적으로 SSG로 빌드됩니다.
import Layout from '../layouts/Layout.astro';
---
<Layout>
<h1>이 페이지는 빌드 시 정적 HTML로 생성됩니다</h1>
</Layout>동적 데이터는 SSR로
사용자별로 달라지는 정보, 실시간 API 응답이 필요한 페이지는 Astro의 SSR 렌더링을 활용합니다.
---
// SSR: 페이지에서 동적 렌더링 활성화
export const prerender = false;
---실무 적용 기준
실제 프로젝트에서는 SSG를 기본으로 두고, 동적인 성격의 페이지만 SSR로 예외를 두는 것이 가장 안정적입니다.
Next.js에는 ISR도 있잖아
Next.js에서는 ISR(Incremental Static Regeneration)라는 기능을 제공해서 정적 페이지의 데이터를 시간이 지남에 따라 업데이트하는 기능을 제공합니다. Next.js에서 ISR을 크게 홍보해서 많이 알려졌지만 Astro도 지원하는 기능입니다. 다만 정적 페이지 로딩 후에 필요한 데이터를 가져와서 채우는 것과 비교해서 그리 큰 장점이지도 않고 대신 복잡도가 꽤나 올라가서 되도록 쓰지 않고 해결하는 편입니다.