메타프레임워크와 렌더링 전략

메타프레임워크(meta-framework)는 React·Vue·Svelte 같은 UI 라이브러리 ‘위에’ 한 겹을 더 얹어, 애플리케이션을 만드는 데 필요한 공통 결정들을 미리 내려주는 프레임워크다. Next.js, Astro, Remix, SvelteKit, Nuxt가 대표적이다. UI 라이브러리는 화면을 그리는 방법만 알려줄 뿐, 실제 서비스를 만들려면 그 바깥에서 풀어야 할 문제가 훨씬 많다.

React로 빈 프로젝트를 시작하면 곧바로 마주치는 질문들이 있다. 라우팅은 어떻게 하지? 데이터는 서버에서 가져올까 브라우저에서 가져올까? 빌드는 어떤 도구로? SEO를 위해 HTML을 미리 만들어 둘 방법은? 메타프레임워크는 이 질문들에 ‘기본 정답’을 제공한다.

• 라우팅: 파일·폴더 구조를 URL로 매핑하는 규칙(file-based routing)을 제공한다. 라우터를 직접 설정할 필요가 없다.
• 데이터 로딩: 서버에서 데이터를 미리 가져와 HTML에 담아 보내는 표준 진입점(서버 컴포넌트, loader 등)을 둔다.
• 렌더링 위치: 같은 컴포넌트를 서버에서 그릴지(SSR), 빌드 때 미리 그릴지(SSG), 브라우저에서 그릴지(CSR)를 선택할 수 있게 한다.
• 번들링·최적화: 코드 분할, 이미지 최적화, 정적 자산 처리 등을 기본 내장한다. 설정 파일을 거의 건드리지 않아도 된다.

메타프레임워크가 내려주는 가장 중요한 결정은 ‘HTML을 언제, 어디서 만들 것인가’다. 같은 화면이라도 빌드 때 미리 만들 수도, 요청마다 서버에서 만들 수도, 브라우저에서 그릴 수도 있다. 이 선택이 첫 화면 속도(TTFB·LCP), 서버 비용, 데이터 최신성을 좌우한다.

네 가지 전략은 대립하는 진영이 아니라 하나의 스펙트럼이다. ‘콘텐츠가 얼마나 자주 바뀌는가’와 ‘사용자마다 달라지는가’를 축으로 두면 어디에 놓을지 자연스럽게 정해진다.

// 60초마다 백그라운드에서 페이지를 다시 생성한다.
// 첫 요청은 캐시된 정적 HTML을 즉시 받고,
// 60초가 지난 뒤의 요청이 재생성을 트리거한다.
export const revalidate = 60

export default async function ProductPage({ params }) {
  const product = await getProduct(params.id) // 빌드/재생성 시 서버에서 실행
  return <ProductView product={product} />
}

Astro는 ‘기본적으로 자바스크립트를 0으로 보낸다’는 발상에서 출발한 메타프레임워크다. 대부분의 콘텐츠 사이트는 사실 정적 HTML이면 충분한데, SPA 프레임워크는 페이지 전체를 자바스크립트로 다시 그리느라(하이드레이션) 불필요한 비용을 치른다. Astro는 이 기본값을 뒤집는다.

아일랜드 아키텍처(islands architecture)는 페이지를 ‘정적인 바다’로 보고, 상호작용이 필요한 부분만 ‘섬’으로 분리해 그 섬에만 자바스크립트를 붙이는 방식이다. 검색창·캐러셀·좋아요 버튼만 동적이고 나머지 본문은 순수 HTML로 남는다.

---
// 이 컴포넌트는 서버(빌드 시점)에서만 실행된다.
import Header from '../components/Header.astro'   // 정적 HTML로만 출력
import SearchBox from '../components/SearchBox.jsx' // 상호작용 필요 → 섬
const posts = await getPosts() // JS 번들에 포함되지 않음
---
<Header />

<!-- client:visible: 화면에 보일 때 비로소 하이드레이션 -->
<SearchBox client:visible />

<ul>
  {posts.map((p) => <li>{p.title}</li>)}  <!-- 순수 HTML, JS 0 -->
</ul>

핵심은 client:* 지시어다. 섬마다 ‘언제 하이드레이션할지’를 따로 정할 수 있어, 자바스크립트를 필요한 만큼만, 필요한 시점에만 로드한다. 이것을 부분 하이드레이션(partial hydration) 혹은 선택적 하이드레이션이라 부른다.

블로그·문서·포트폴리오처럼 ‘글이 주인공’인 사이트에서는 렌더링 전략만큼이나 콘텐츠를 어떻게 관리하느냐가 중요하다. 메타프레임워크는 Markdown/MDX 파일을 데이터처럼 다루는 워크플로우를 기본 제공해, 별도 CMS 없이도 글을 타입 안전하게 관리하게 해 준다.

Astro의 Content Collections가 대표적이다. 콘텐츠 폴더에 스키마를 선언해 두면, 각 글의 프런트매터(frontmatter)가 빌드 때 검증되고, 본문을 불러올 때 타입이 따라온다. 오타 난 필드나 빠뜨린 날짜는 빌드 단계에서 걸러진다.

import { defineCollection, z } from 'astro:content'

const blog = defineCollection({
  type: 'content',
  // 프런트매터 스키마를 Zod로 선언 → 빌드 시 검증
  schema: z.object({
    title: z.string(),
    publishedAt: z.coerce.date(),
    tags: z.array(z.string()).default([]),
    draft: z.boolean().default(false),
  }),
})

export const collections = { blog }

---
import { getCollection } from 'astro:content'

// entry.data는 위 스키마 타입을 그대로 따른다 (자동완성·타입체크)
const posts = (await getCollection('blog'))
  .filter((entry) => !entry.data.draft)
  .sort((a, b) => +b.data.publishedAt - +a.data.publishedAt)
---
<ul>
  {posts.map((post) => (
    <li><a href={`/blog/${post.slug}`}>{post.data.title}</a></li>
  ))}
</ul>

• MDX: Markdown 안에서 컴포넌트를 직접 쓸 수 있어, 글 속에 인터랙티브 데모(섬)를 섞기 좋다. 이 핸드북도 같은 발상으로 콘텐츠와 컴포넌트를 함께 둔다.
• 정적 생성과의 궁합: 콘텐츠가 파일이므로 빌드 때 전부 SSG로 굳혀 CDN에 올리기 자연스럽다. 글이 늘어도 서버 비용은 늘지 않는다.
• 헤드리스 CMS와의 경계: 비개발자가 자주 글을 올려야 한다면 파일 기반보다 헤드리스 CMS(Contentful·Sanity 등)를 데이터 소스로 두는 편이 낫다.

‘무엇이 제일 좋은가’라는 질문은 답이 없다. 메타프레임워크는 각자 가정하는 ‘전형적인 앱의 모양’이 다르기 때문이다. 만들려는 것이 콘텐츠 사이트인지, 상호작용이 많은 앱인지, 데이터 변경이 잦은 트랜잭션 서비스인지에 따라 정답이 바뀐다.

축은 하나면 충분하다. ‘자바스크립트가 얼마나 많이 필요한 앱인가’. 정적 콘텐츠가 대부분이면 Astro 쪽으로, 화면 전체가 살아 있는 앱이면 Next/Remix 쪽으로 기운다.