테마 전환

Hugo/Hexo/Next.js에서 Astro로 마이그레이션하기: 3일 완성 상세 가이드

Easton editorial illustration: monorepo project desk

들어가며

내 블로그를 열 때마다 페이지가 느릿느릿 로드되는 모습을 보면 마음이 편치 않습니다. Hugo 템플릿에 작은 기능 하나를 추가하려다가 지나치게 불편한 문법에 막힐 때도 있습니다. Next.js로 만든 정적 블로그는 빌드 후 JavaScript 파일이 놀라울 만큼 커지기도 합니다. 블로그일 뿐인데 왜 그렇게 많은 코드를 로드해야 할까요?

저도 예전에 같은 문제를 겪었습니다. 그러다 웹사이트 성능을 극대화해 PageSpeed Insights 100점도 손쉽게 받을 수 있다는 Astro를 알게 됐습니다. 처음에는 반신반의했지만, 생각보다 이전 과정이 복잡하지 않다는 개발자들의 경험담이 늘어나는 것을 보면서 관심이 생겼습니다.

그래도 실제로 마이그레이션하려니 걱정되는 점이 있었습니다. 주로 다음 세 가지였습니다.

  1. 마이그레이션이 너무 복잡하지 않을까? 글이 수십, 수백 개인데 하나씩 수정해야 할까?
  2. SEO에 영향을 주지 않을까? URL 구조가 바뀌면 어떻게 해야 할까?
  3. 미리 알아야 할 함정은 무엇일까? 중간에 막히고 싶지는 않았습니다.

여러분도 이런 걱정이 있다면 이 글이 도움이 될 것입니다. Hugo, Hexo, Next.js라는 세 가지 대표 프레임워크에서 Astro로 옮기는 전체 경로와 각 단계의 구체적인 작업, 자주 마주치는 함정, 모범 사례를 소개하겠습니다. 제가 수집한 개발자 경험에 따르면 전체 마이그레이션은 실제로 1~3일이면 충분합니다.

Astro로 이전할 가치가 있는 이유

먼저 많은 사람이 왜 Astro로 옮기는지 살펴보겠습니다. 유행을 좇아서가 아니라 실제로 분명한 이점이 있기 때문입니다.

Astro의 핵심 장점

Zero JavaScript 전략

Astro의 가장 큰 특징은 ‘기본적으로 JS를 전혀 사용하지 않는다’는 점입니다. 잘못 읽은 것이 아닙니다. Astro가 생성하는 페이지에는 기본적으로 JavaScript가 포함되지 않습니다. 블로그나 문서 사이트처럼 콘텐츠 중심인 웹사이트에는 궁극적인 성능 최적화 방법입니다.

한 일본 개발자는 Next.js에서 Astro로 이전한 뒤 PageSpeed Insights 점수가 85점에서 곧바로 100점으로 올랐고, 테스트할 때마다 100점이 나왔다고 공유했습니다. 이 향상은 주로 다음 두 가지에서 비롯됐습니다.

  • hydration에 필요한 JavaScript 제거
  • CSS 인라인화를 통한 네트워크 요청 횟수 감소
1~3일
마이그레이션 기간
개발자 경험 기준
85→100점
성능 향상
PageSpeed Insights
영향 없음
SEO 영향
URL 구조 유지 가능

Islands 아키텍처

물론 현대적인 웹사이트에는 댓글, 검색창, 테마 전환 버튼처럼 어느 정도의 상호작용이 필요합니다. Astro는 Islands 아키텍처로 이 문제를 해결합니다. 정적인 HTML 페이지 안에서 상호작용이 필요한 특정 컴포넌트에만 JavaScript를 추가하고 나머지는 순수한 정적 콘텐츠로 유지할 수 있습니다.

정적인 바다 위에 떠 있는 섬과 같습니다. 역동적인 생명은 섬에만 존재합니다.

현대적인 개발 경험

Hugo를 사용해 봤다면 템플릿 문법이 얼마나 불편한지 알 것입니다. Astro는 완전히 다릅니다. .astro 파일의 문법은 JSX와 거의 같고 React, Vue, Svelte 등 주요 프레임워크의 컴포넌트도 바로 사용할 수 있습니다.

한 블로거는 Hugo 템플릿으로 개발하기는 편하지 않으며, 오픈 소스 템플릿은 많지만 직접 수정하려면 어렵다고 잘 설명했습니다. 반면 Astro 템플릿은 현대적인 프론트엔드 개발 방식과 같아서 자유롭게 손보기 쉽습니다.

다른 프레임워크와 비교

차이를 빠르게 파악할 수 있도록 간단한 비교표를 만들었습니다.

특성HugoHexoNext.jsAstro
빌드 속도매우 빠름(Go 언어)빠름보통빠름
템플릿 문법Go 템플릿(어려움)EJS/PugJSX/TSXAstro/JSX
프론트엔드 프레임워크 지원없음제한적React다중 프레임워크
기본 JS 크기0보통0
개발 경험보통보통훌륭함훌륭함
생태계 성숙도높음보통높음성장 중

마이그레이션에 적합한 프로젝트

모든 프로젝트가 Astro로 옮기기에 적합한 것은 아닙니다. 먼저 자신의 프로젝트가 다음 유형에 해당하는지 확인해 보세요.

마이그레이션에 적합한 프로젝트:

  • 개인 블로그, 기술 블로그
  • 문서 사이트, 지식 베이스
  • 기업 홈페이지, 제품 소개 페이지
  • 포트폴리오 웹사이트

마이그레이션에 적합하지 않은 프로젝트:

  • 상호작용이 매우 많은 단일 페이지 애플리케이션(대시보드, 관리자 시스템)
  • 실시간 데이터 업데이트가 필요한 애플리케이션
  • 대규모 클라이언트 상태 관리가 필요한 애플리케이션

간단히 말해 웹사이트에서 콘텐츠가 중심이라면 Astro가 적합합니다. 상호작용과 실시간 업데이트가 많다면 Next.js나 SPA 프레임워크를 그대로 사용하는 편이 낫습니다.

마이그레이션 전 준비 작업

바로 작업을 시작하지 말고 먼저 다음을 준비하세요. 마이그레이션 과정이 훨씬 원활해집니다.

1. 기존 프로젝트 백업

가장 중요한 단계입니다. git 브랜치로 관리하는 것을 권합니다.

# 마이그레이션 브랜치 생성
git checkout -b migrate-to-astro

# 현재 작업이 저장됐는지 확인
git add .
git commit -m "백업: Astro 마이그레이션 시작"

마이그레이션 도중 문제가 생겨도 언제든 기존 브랜치로 돌아갈 수 있습니다.

2. 마이그레이션 작업량 평가

시작하기 전에 작업량을 먼저 평가해 두세요.

콘텐츠 평가:

  • 글 수: ____개
  • 사용 중인 Markdown 문법: 표준/확장
  • 이미지 수: ____개
  • 이미지 저장 위치: 상대 경로/절대 경로

예상 소요 시간:

  • 콘텐츠 50개 미만: 1일
  • 50~200개: 2일
  • 200개 이상: 3일

3. Astro 테마 선택

Astro에는 훌륭한 블로그 테마가 많습니다. 기존 블로그와 스타일이 비슷한 테마를 고르면 작업을 많이 줄일 수 있습니다.

추천 테마:

  • AstroPaper: 기술 블로그에 어울리는 간결한 블로그 테마
  • Fuwari: 다국어를 지원하고 기능이 풍부한 테마
  • Astro Cactus: 완전한 목차 트리 컴포넌트를 제공하는 테마

프로젝트를 빠르게 생성하려면 다음 명령을 사용합니다.

# AstroPaper 테마 사용
npm create astro@latest my-blog -- --template satnaing/astro-paper

# 또는 Fuwari 테마 사용
npm create astro@latest my-blog -- --template saicaca/fuwari

4. 환경 준비

개발 환경이 다음 요구 사항을 충족하는지 확인합니다.

  • Node.js: v18.14.1 이상
  • 패키지 관리자: npm, pnpm 또는 yarn
  • VS Code 확장: Astro(필수 공식 확장)

Hugo에서 마이그레이션하는 상세 단계

Hugo 사용자가 가장 많을 테니 먼저 설명하겠습니다. 전반적으로 Hugo에서 Astro로 옮기는 난이도는 보통이며, 주요 작업은 템플릿 변환입니다.

1단계: Astro 프로젝트 생성

npm create astro@latest my-new-blog
cd my-new-blog
npm install

# 자주 사용하는 통합 설치
npx astro add mdx sitemap

2단계: Markdown 콘텐츠 이전

가장 중요한 단계입니다. 다행히 Hugo와 Astro의 Frontmatter는 대부분 호환되며 몇 개 필드만 바꾸면 됩니다.

Frontmatter 필드 매핑:

# Hugo 형식
---
title: "내 글"
date: 2023-01-15
tags: ["프론트엔드", "Astro"]
---

# Astro 형식(변경된 부분을 ⬅로 표시)
---
title: "내 글"
pubDate: 2023-01-15  ⬅ date를 pubDate로 변경
tags: ["프론트엔드", "Astro"]
---

글이 많다면 스크립트로 일괄 변경할 수 있습니다.

# macOS/Linux
find content -name "*.md" -exec sed -i '' 's/^date:/pubDate:/g' {} +

# Windows (PowerShell)
Get-ChildItem content -Filter *.md -Recurse | ForEach-Object {
    (Get-Content $_.FullName) -replace '^date:', 'pubDate:' | Set-Content $_.FullName
}

3단계: 템플릿 변환 요령

Hugo 템플릿은 Go Template 문법을 사용하고 Astro는 JSX와 비슷한 문법을 사용합니다. 하지만 간단한 요령이 있습니다. 기존에 작성한 HTML 템플릿이 있다면 HTML을 .astro 파일에 그대로 붙여 넣는 것만으로 작업의 70%가 끝납니다.

Hugo 템플릿 예시:

{{ range .Pages }}
  <article>
    <h2>{{ .Title }}</h2>
    <p>{{ .Summary }}</p>
  </article>
{{ end }}

Astro로 변환한 결과:

---
const posts = await Astro.glob('../pages/blog/*.md');
---

{posts.map(post => (
  <article>
    <h2>{post.frontmatter.title}</h2>
    <p>{post.frontmatter.description}</p>
  </article>
))}

문법이 훨씬 현대적으로 느껴지지 않나요?

4단계: 이미지와 정적 리소스 처리

Hugo의 static/ 디렉터리 내용을 Astro의 public/ 디렉터리로 복사하고 경로는 그대로 유지합니다.

cp -r hugo-blog/static/* astro-blog/public/

글에서 상대 경로나 /images/pic.jpg 같은 절대 경로로 이미지를 참조한다면 수정할 필요가 없습니다. public/ 디렉터리의 콘텐츠는 웹사이트 루트 디렉터리에 그대로 매핑되기 때문입니다.

5단계: URL 리디렉션 설정

SEO와 직결되는 중요한 단계입니다. URL 구조가 바뀌었다면 반드시 301 리디렉션을 설정해야 합니다.

astro.config.mjs에서 다음과 같이 설정합니다.

export default defineConfig({
  redirects: {
    '/old-path': '/new-path',
    '/posts/[slug]': '/blog/[slug]',
  }
})

Hexo에서 마이그레이션하는 상세 단계

Hexo 마이그레이션은 Hugo와 비슷하지만 몇 가지 고유한 주의 사항이 있습니다.

1단계: 프로젝트 생성 및 Content Collections 설정

pnpm create astro@latest my-blog --template satnaing/astro-paper
cd my-blog
pnpm install

Astro는 Content Collections로 콘텐츠를 관리하므로 src/content/config.ts에서 설정해야 합니다.

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

const blog = defineCollection({
  schema: z.object({
    title: z.string(),
    pubDate: z.date(),
    description: z.string(),
    tags: z.array(z.string()),
  }),
});

export const collections = { blog };

이 설정은 Frontmatter의 타입을 검사합니다. 필드가 맞지 않으면 오류가 발생하므로 유용합니다.

2단계: 콘텐츠와 이미지 이전

Hexo의 source/_posts/ 디렉터리에 있는 글을 Astro의 src/content/blog/로 복사한 뒤 datepubDate로 일괄 변경합니다.

find src/content/blog -name "*.md" -exec sed -i 's/^date:/pubDate:/g' {} +

이미지는 두 가지 방법으로 처리할 수 있습니다.

방법 1: public/ 디렉터리에 배치(간단하며 권장)

cp -r hexo-blog/source/images astro-blog/public/images

글 안의 이미지 경로는 수정하지 않아도 됩니다.

방법 2: Astro Image 컴포넌트 사용(성능 우수)

---
import { Image } from 'astro:assets';
import myImage from '../assets/pic.jpg';
---

<Image src={myImage} alt="설명" />

3단계: URL 경로 리디렉션

Hexo의 기본 경로는 /YYYY/MM/DD/post-name/이고 Astro의 기본 경로는 /blog/post-name/입니다.

기존 경로 형식을 유지하려면 astro.config.ts에서 리디렉션을 설정합니다.

export default defineConfig({
  redirects: {
    '/:year/:month/:day/:slug': '/blog/:slug',
  }
})

4단계: RSS 전문 출력 설정

Hexo는 기본적으로 RSS에 전문을 출력하지만 Astro에서는 직접 설정해야 합니다.

npx astro add rss

src/pages/rss.xml.js에서 다음과 같이 설정합니다.

import rss from '@astrojs/rss';
import { getCollection } from 'astro:content';
import { marked } from 'marked';

export async function GET(context) {
  const posts = await getCollection('blog');

  return rss({
    title: '내 블로그',
    description: '블로그 설명',
    site: context.site,
    items: posts.map(post => ({
      title: post.data.title,
      pubDate: post.data.pubDate,
      link: `/blog/${post.slug}/`,
      content: marked.parse(post.body), // 전문 출력
    })),
  });
}

Next.js에서 마이그레이션하는 상세 단계

Next.js는 아키텍처 차이가 커서 Astro로 옮기는 작업이 조금 더 복잡합니다. 하지만 Next.js의 SSG 모드를 사용하고 있었다면 난이도는 훨씬 낮아집니다.

1단계: 아키텍처 차이 이해

핵심 차이:

  • Next.js는 전역 _app.js가 있는 단일 페이지 애플리케이션(SPA)입니다.
  • Astro는 각 페이지가 독립된 다중 페이지 웹사이트(MPA)입니다.

공통점:

  • 둘 다 JSX 문법 지원
  • 둘 다 파일 시스템 라우팅 사용
  • 둘 다 SSG와 SSR 지원

마음가짐부터 바꿔야 합니다. Next.js 애플리케이션을 그대로 ‘이전’하는 것이 아니라 Astro로 콘텐츠 웹사이트를 ‘다시 만드는’ 작업입니다.

2단계: 프로젝트 생성 및 React 통합 설치

npm create astro@latest my-blog
cd my-blog
npx astro add react

React 통합을 설치하면 기존 React 컴포넌트를 계속 사용할 수 있습니다.

3단계: 컴포넌트 마이그레이션 전략

Astro는 .jsx.tsx 파일을 직접 지원하므로 React 컴포넌트를 그대로 복사할 수 있습니다.

Next.js 컴포넌트(변경 없음):

// components/Button.jsx
export default function Button({ children, onClick }) {
  return <button onClick={onClick}>{children}</button>
}

Astro에서 사용:

---
import Button from '../components/Button.jsx';
---

<Button client:load>클릭하세요</Button>

client:load 지시어에 주목하세요. 이 컴포넌트에 JavaScript가 필요하다는 사실을 Astro에 알립니다. 기본 컴포넌트는 정적입니다.

4단계: React 컴포넌트를 Astro 컴포넌트로 변환

상호작용이 필요 없는 컴포넌트는 Astro 컴포넌트로 변환하는 편이 성능에 유리합니다.

Next.js/React 컴포넌트:

export default function Card({ title, description }) {
  const formattedDate = new Date().toLocaleDateString();

  return (
    <div className="card">
      <h2>{title}</h2>
      <p>{description}</p>
      <span>{formattedDate}</span>
    </div>
  );
}

Astro 컴포넌트:

---
const { title, description } = Astro.props;
const formattedDate = new Date().toLocaleDateString();
---

<div class="card">
  <h2>{title}</h2>
  <p>{description}</p>
  <span>{formattedDate}</span>
</div>

주요 차이점은 다음과 같습니다.

  • classNameclass
  • Props는 Astro.props에서 가져옴
  • JavaScript 코드는 --- 사이에 배치

5단계: Hydration 전략 조정

Next.js는 기본적으로 모든 컴포넌트에 hydration을 적용해 JavaScript를 로드하고 상호작용할 수 있게 합니다. Astro는 기본적으로 적용하지 않습니다.

따라서 상호작용이 필요한 컴포넌트를 직접 지정해야 합니다.

Hydration 지시어:

  • client:load - 페이지가 로드될 때 즉시 hydrate
  • client:idle - 페이지가 유휴 상태일 때 hydrate
  • client:visible - 컴포넌트가 뷰포트에 들어올 때 hydrate
  • client:only - 클라이언트에서만 렌더링
---
import Counter from '../components/Counter.jsx';
import HeavyChart from '../components/HeavyChart.jsx';
---

<!-- 즉시 상호작용 -->
<Counter client:load />

<!-- 지연 로드로 성능 향상 -->
<HeavyChart client:visible />

매우 중요한 전략이며 잘 활용하면 성능을 크게 높일 수 있습니다.

6단계: 동적 라우트 처리

Next.js의 getStaticPaths에 대응하는 구현이 Astro에도 있으며 문법은 거의 같습니다.

Astro 동적 라우트:

---
// src/pages/blog/[slug].astro
import { getCollection } from 'astro:content';

export async function getStaticPaths() {
  const posts = await getCollection('blog');
  return posts.map(post => ({
    params: { slug: post.slug },
    props: { post },
  }));
}

const { post } = Astro.props;
---

<article>
  <h1>{post.data.title}</h1>
  <div set:html={post.body} />
</article>

7단계: 성능 최적화 결과 비교

마이그레이션의 가장 큰 이점입니다. 실제 개발자 경험에 따르면 결과는 다음과 같습니다.

마이그레이션 전(Next.js SSG):

  • PageSpeed Insights: 85점
  • 최초 로드 JS: 약 200KB
  • Lighthouse Performance: 80~90점

마이그레이션 후(Astro):

  • PageSpeed Insights: 100점(매번 동일)
  • 최초 로드 JS: 약 10KB(상호작용 컴포넌트가 없으면 0KB 가능)
  • Lighthouse Performance: 95~100점

성능 향상의 주요 원인은 다음과 같습니다.

  • React hydration 오버헤드 제거
  • CSS 인라인화를 통한 네트워크 요청 감소
  • 필요한 JavaScript만 로드

공통 마이그레이션 모범 사례

어떤 프레임워크에서 옮기든 다음 모범 사례가 적용됩니다.

1. 단계별 마이그레이션 전략

모든 콘텐츠를 한 번에 옮길 필요는 없습니다. 점진적으로 진행할 수 있습니다.

1단계: 시범 이전

  • 글 5~10개를 골라 먼저 이전
  • 마이그레이션 절차가 원활한지 확인
  • 성능 향상 효과 테스트

2단계: 전체 이전

  • 모든 글 콘텐츠 이전
  • 모든 템플릿과 컴포넌트 변환
  • 리디렉션 규칙 설정

3단계: 보완 및 최적화

  • 누락된 기능 추가
  • 성능 최적화
  • SEO 점검

한 블로거는 처음에 일부 새 글만 Astro로 작성하고 기존 글은 그대로 뒀다고 공유했습니다. 이런 점진적인 마이그레이션은 위험이 더 작습니다.

2. SEO 보호 조치

마이그레이션에서 가장 걱정되는 부분은 SEO 영향입니다. 다음 항목은 반드시 처리해야 합니다.

301 리디렉션 설정

URL 구조가 바뀌었다면 반드시 301 리디렉션을 설정합니다.

// Vercel: vercel.json
{
  "redirects": [
    { "source": "/old-path/:slug", "destination": "/new-path/:slug", "permanent": true }
  ]
}

// Cloudflare Pages: _redirects
/old-path/:splat /new-path/:splat 301

Sitemap 업데이트

npx astro add sitemap

astro.config.mjs에서 설정합니다.

import { defineConfig } from 'astro/config';
import sitemap from '@astrojs/sitemap';

export default defineConfig({
  site: 'https://yourdomain.com',
  integrations: [sitemap()],
});

검색 엔진에 제출

마이그레이션을 마친 뒤 Google Search Console과 Bing Webmaster Tools에 새 sitemap을 제출합니다.

3. 이미지 최적화

Astro에는 전용 이미지 최적화 컴포넌트가 있으므로 사용하는 것을 권합니다.

npx astro add image

사용 예시:

---
import { Image } from 'astro:assets';
import cover from '../assets/cover.jpg';
---

<Image src={cover} alt="커버 이미지" width={800} height={600} />

여러 크기의 이미지를 자동 생성하고 WebP 형식으로 자동 변환하며 지연 로딩도 적용할 수 있습니다.

4. 테스트 체크리스트

마이그레이션을 마쳤다고 곧바로 공개하지 말고 먼저 다음 항목을 확인하세요.

콘텐츠 확인:

  • 모든 글이 정상적으로 표시됨
  • Frontmatter 필드가 완전함
  • 글 안의 링크를 클릭할 수 있음
  • 태그와 카테고리 페이지가 정상 작동함

리소스 확인:

  • 모든 이미지가 정상적으로 로드됨
  • CSS 스타일이 올바르게 적용됨

기능 확인:

  • 검색 기능이 정상 작동함
  • 댓글 시스템이 정상 작동함
  • RSS 구독을 사용할 수 있음

SEO 확인:

  • Sitemap이 정상적으로 생성됨
  • robots.txt가 올바름
  • 기존 URL이 올바르게 리디렉션됨

성능 확인:

  • PageSpeed Insights 점수 측정
  • Lighthouse 검사

추천 도구:

자주 묻는 문제와 해결 방법

마이그레이션 중에 다음과 같은 문제를 만날 수 있습니다. 해결 방법을 미리 정리했습니다.

1. 빌드 오류 해결

문제: Could not find Sharp

Astro 이미지 최적화 의존성 문제입니다.

# 해결 방법
npm install sharp

그래도 해결되지 않으면 astro.config.mjs에서 이미지 최적화를 비활성화합니다.

export default defineConfig({
  image: {
    service: { entrypoint: 'astro/assets/services/noop' }
  }
})

문제: MDX 버전 비호환

Astro 5.0을 사용한다면 @astrojs/mdx를 반드시 v4.0.0으로 업그레이드해야 합니다.

npm install @astrojs/mdx@latest

2. 스타일 누락 문제

문제: CSS 범위 때문에 스타일이 적용되지 않음

Astro의 <style> 태그는 기본적으로 현재 컴포넌트에만 적용되는 범위 지정 스타일(scoped)입니다.

<!-- 지역 스타일 -->
<style>
  .card { color: blue; }
</style>

<!-- 전역 스타일 -->
<style is:global>
  .card { color: blue; }
</style>

문제: Markdown 콘텐츠 스타일 누락

Markdown으로 렌더링된 HTML에는 전역 스타일이 필요합니다.

<style is:global>
  .prose h1 { font-size: 2rem; }
  .prose h2 { font-size: 1.5rem; }
  .prose p { margin: 1rem 0; }
  .prose code { background: #f4f4f4; padding: 0.2rem 0.4rem; }
</style>

<article class="prose">
  <Content />
</article>

또는 Tailwind Typography 플러그인을 바로 사용할 수 있습니다.

3. 타사 서비스 통합

댓글 시스템

Astro는 대부분의 댓글 시스템(Disqus, Giscus, Utterances)을 지원합니다.

<script
  src="https://giscus.app/client.js"
  data-repo="your-username/your-repo"
  data-repo-id="your-repo-id"
  data-category="Announcements"
  data-category-id="your-category-id"
  data-mapping="pathname"
  data-strict="0"
  data-reactions-enabled="1"
  data-emit-metadata="0"
  data-input-position="bottom"
  data-theme="light"
  data-lang="zh-CN"
  crossorigin="anonymous"
  async>
</script>

분석 도구

Google Analytics는 바로 사용할 수 있습니다.

<html>
  <head>
    <script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
    <script>
      window.dataLayer = window.dataLayer || [];
      function gtag(){dataLayer.push(arguments);}
      gtag('js', new Date());
      gtag('config', 'G-XXXXXXXXXX');
    </script>
  </head>
</html>

4. 배포 설정

Vercel 배포

GitHub 저장소를 직접 연결하면 Vercel이 Astro 프로젝트를 자동으로 인식합니다.

Cloudflare Pages 배포

빌드 설정:

  • Build command: npm run build
  • Build output directory: dist
  • Node.js version: 18 이상

GitHub Pages 배포

astro.config.mjs에서 다음과 같이 설정합니다.

export default defineConfig({
  site: 'https://username.github.io',
  base: '/repo-name',
})

마무리

지금까지 많은 내용을 설명했지만 Astro 마이그레이션은 실제로 그렇게 무섭지 않습니다. 제가 수집한 개발자 경험에 따르면 대부분 1~3일 안에 이전을 마쳤고 결과에도 만족했습니다.

핵심을 다시 정리하면 다음과 같습니다:

  1. 백업하기: git 브랜치를 만들어 언제든 되돌릴 수 있도록 준비합니다.
  2. 점진적으로 이전하기: 몇 개 글로 먼저 검증한 뒤 전체를 이전합니다.
  3. SEO 중시하기: 301 리디렉션을 설정하고 sitemap을 업데이트해 검색 순위를 보호합니다.
  4. 충분히 테스트하기: 공개 전 링크, 이미지, 기능이 정상인지 확인합니다.
  5. 성과 누리기: 이전 후 성능 향상은 분명하며 PageSpeed Insights 100점도 쉽게 달성할 수 있습니다.

제안: 이전을 망설이고 있다면 먼저 테스트 브랜치를 만들어 보세요. 몇 개 글을 옮긴 뒤 성능 테스트를 실행하고 결과를 확인합니다. 만족스럽다면 전체를 이전하고, 그렇지 않아도 잃을 것은 없습니다.

마지막으로 유용한 리소스를 소개합니다.

마이그레이션이 순조롭게 진행되길 바랍니다. 문제가 생기면 댓글로 함께 이야기해 주세요.

Hugo/Hexo/Next.js에서 Astro로 마이그레이션하는 전체 과정

상세 단계와 자주 마주치는 함정, 모범 사례를 포함해 1~3일 안에 성능과 SEO를 지키며 안정적으로 이전하는 3일 완성 가이드

⏱️ Estimated time: P3D

  1. 1

    Step 1: Astro로 이전할 가치가 있는 이유 이해하기

    Zero JavaScript 전략:
    • Astro의 가장 큰 특징은 '기본적으로 JS를 전혀 사용하지 않는다'는 점입니다.
    • Astro가 생성하는 페이지에는 기본적으로 JavaScript가 포함되지 않습니다.
    • 블로그나 문서 사이트처럼 콘텐츠 중심인 웹사이트에는 궁극적인 성능 최적화 방법입니다.
    • Next.js에서 Astro로 이전한 뒤 PageSpeed Insights 점수가 85점에서 100점으로 상승했습니다.
    • 이러한 향상은 주로 hydration에 필요한 JavaScript를 제거하고 CSS를 인라인화해 네트워크 요청 횟수를 줄인 덕분입니다.

    Islands 아키텍처:
    • 현대적인 웹사이트에는 댓글, 검색창, 테마 전환 버튼 같은 상호작용 기능이 필요합니다.
    • Astro는 Islands 아키텍처로 이를 해결합니다.
    • 정적인 HTML 페이지에서 특정 상호작용 컴포넌트에만 JavaScript를 추가할 수 있습니다.
    • 나머지 부분은 순수한 정적 콘텐츠로 유지됩니다.

    현대적인 개발 경험:
    • Hugo를 사용해 봤다면 템플릿 문법이 얼마나 불편한지 알 것입니다.
    • Astro는 완전히 다르며 .astro 파일의 문법은 JSX와 거의 같습니다.
    • React, Vue, Svelte 등 주요 프레임워크의 컴포넌트도 바로 사용할 수 있습니다.
  2. 2

    Step 2: Hugo에서 Astro로 마이그레이션하기

    템플릿 문법 변환:
    • Hugo는 Go 템플릿 문법을 사용하고 Astro는 JSX와 비슷한 문법을 사용합니다.
    • Hugo 템플릿을 Astro 컴포넌트로 변환해야 합니다.

    콘텐츠 파일 이전:
    • Hugo 콘텐츠 파일은 보통 content/ 디렉터리에 있습니다.
    • Astro는 Content Collections를 사용합니다.
    • Markdown 파일을 src/content/posts/ 디렉터리로 옮겨야 합니다.
    • frontmatter 형식을 조정해야 합니다.

    설정 이전:
    • Hugo의 config.toml 설정을 Astro의 astro.config.mjs 설정으로 변환해야 합니다.
    • 사이트 URL과 테마 설정 등이 포함됩니다.

    URL 구조 유지:
    • Astro의 redirects 기능을 사용합니다.
    • URL 구조를 그대로 유지해 SEO가 영향을 받지 않도록 합니다.
  3. 3

    Step 3: Hexo에서 Astro로 마이그레이션하기

    테마 변환:
    • Hexo 테마를 Astro 컴포넌트로 변환해야 합니다.
    • Hexo는 EJS/Jade 템플릿을, Astro는 .astro 컴포넌트를 사용합니다.

    플러그인 이전:
    • Hexo 플러그인 기능에 대응하는 Astro 통합 패키지를 찾거나 직접 구현해야 합니다.
    • 대부분의 기능에는 대응하는 Astro 통합 패키지가 있습니다.

    배포 설정:
    • Hexo는 hexo deploy 명령으로 배포합니다.
    • Astro는 npm run build로 빌드한 뒤 dist 디렉터리를 배포합니다.
    • Vercel/Netlify/Cloudflare Pages에 간단히 배포할 수 있습니다.

    콘텐츠 파일 이전:
    • Hexo 콘텐츠 파일은 source/_posts/ 디렉터리에 있습니다.
    • Astro는 Content Collections를 사용합니다.
    • Markdown 파일을 src/content/posts/ 디렉터리로 옮겨야 합니다.
    • frontmatter 형식을 조정해야 합니다.
  4. 4

    Step 4: Next.js에서 Astro로 마이그레이션하기

    컴포넌트 이전:
    • React 컴포넌트는 client:load 같은 지시어만 추가하면 바로 사용할 수 있습니다.
    • Vue 컴포넌트도 바로 사용할 수 있습니다.

    라우팅 변환:
    • Next.js와 Astro 모두 파일 시스템 라우팅을 사용합니다.
    • 다만 문법에 약간 차이가 있으므로 라우트 파일을 조정해야 합니다.

    SSR 설정:
    • Next.js의 SSR 기능을 사용했다면 Astro의 SSR 어댑터를 설정해야 합니다.
    • Astro는 SSR, SSG, Hybrid 모드를 지원합니다.

    배포 설정:
    • Next.js는 보통 Vercel에 배포하며 Astro도 Vercel에 배포할 수 있습니다.
    • 설정은 비슷하며 빌드 명령과 출력 디렉터리만 조정하면 됩니다.
  5. 5

    Step 5: 마이그레이션 모범 사례와 자주 마주치는 함정

    마이그레이션 모범 사례:
    1. 백업하기(git 브랜치를 만들어 언제든 되돌릴 수 있도록 준비)
    2. 점진적으로 이전하기(몇 개 글로 먼저 검증한 뒤 전체 이전)
    3. SEO 중시하기(301 리디렉션 설정, sitemap 업데이트, 검색 순위 보호)
    4. 충분히 테스트하기(공개 전 링크, 이미지, 기능이 정상인지 확인)
    5. 성과 누리기(이전 후 성능 향상은 분명하며 PageSpeed Insights 100점도 쉽게 달성)

    자주 마주치는 함정:
    • URL 구조 유지(Astro의 redirects 기능 사용)
    • 콘텐츠 파일 이전(Markdown 파일은 그대로 사용하고 frontmatter 형식만 조정)
    • 컴포넌트 이전(React/Vue 컴포넌트는 client:load 같은 지시어만 추가해 사용)
    • 배포 설정(Vercel/Netlify/Cloudflare Pages에 간단히 배포 가능)

    제가 수집한 개발자 경험에 따르면 전체 마이그레이션은 실제로 1~3일이면 충분했고 결과도 만족스러웠습니다.

FAQ

왜 Astro로 이전할 가치가 있으며, 마이그레이션 효과는 어떤가요?
Zero JavaScript 전략:
• Astro의 가장 큰 특징은 '기본적으로 JS를 전혀 사용하지 않는다'는 점이며, 생성되는 페이지에는 기본적으로 JavaScript가 포함되지 않습니다.
• 블로그나 문서 사이트처럼 콘텐츠 중심인 웹사이트에는 궁극적인 성능 최적화 방법입니다.
• 한 일본 개발자는 Next.js에서 Astro로 이전한 뒤 PageSpeed Insights 점수가 85점에서 100점으로 상승했다고 공유했습니다.
• 이러한 향상은 주로 hydration에 필요한 JavaScript를 제거하고 CSS를 인라인화해 네트워크 요청 횟수를 줄인 덕분입니다.

Islands 아키텍처:
• 현대적인 웹사이트에는 댓글, 검색창, 테마 전환 버튼 같은 상호작용 기능이 필요합니다.
• Astro는 Islands 아키텍처로 이를 해결합니다. 정적인 HTML 페이지에서 특정 상호작용 컴포넌트에만 JavaScript를 추가하고 나머지는 순수한 정적 콘텐츠로 유지할 수 있습니다.

현대적인 개발 경험:
• Hugo를 사용해 봤다면 템플릿 문법이 얼마나 불편한지 알 것입니다.
• Astro는 완전히 다르며 .astro 파일의 문법은 JSX와 거의 같습니다.
• React, Vue, Svelte 등 주요 프레임워크의 컴포넌트도 바로 사용할 수 있습니다.
마이그레이션이 복잡한가요? 얼마나 걸리나요?
마이그레이션 기간: 제가 수집한 개발자 경험에 따르면 전체 과정은 실제로 1~3일이면 충분했고 결과도 만족스러웠습니다.

마이그레이션이 복잡한가요? 그렇지 않습니다. 글을 하나씩 수정할 필요가 없고 URL 구조도 그대로 유지할 수 있어 SEO에 영향을 주지 않습니다.

마이그레이션 모범 사례:
1) 백업하기(git 브랜치를 만들어 언제든 되돌릴 수 있도록 준비)
2) 점진적으로 이전하기(몇 개 글로 먼저 검증한 뒤 전체 이전)
3) SEO 중시하기(301 리디렉션 설정, sitemap 업데이트, 검색 순위 보호)
4) 충분히 테스트하기(공개 전 링크, 이미지, 기능이 정상인지 확인)
5) 성과 누리기(이전 후 성능 향상은 분명하며 PageSpeed Insights 100점도 쉽게 달성)

제안: 이전을 망설이고 있다면 먼저 테스트 브랜치를 만들고 몇 개 글을 옮긴 뒤 성능 테스트를 실행해 보세요. 결과가 만족스러우면 전체를 이전하고, 그렇지 않아도 잃을 것은 없습니다.
Hugo에서 Astro로 마이그레이션하는 구체적인 단계는 무엇인가요?
템플릿 문법 변환:
• Hugo는 Go 템플릿 문법을 사용하고 Astro는 JSX와 비슷한 문법을 사용합니다.
• Hugo 템플릿을 Astro 컴포넌트로 변환해야 합니다.

콘텐츠 파일 이전:
• Hugo 콘텐츠 파일은 보통 content/ 디렉터리에 있습니다.
• Astro는 Content Collections를 사용하므로 Markdown 파일을 src/content/posts/ 디렉터리로 옮겨야 합니다.
• frontmatter 형식을 조정합니다.

설정 이전:
• Hugo의 config.toml 설정을 Astro의 astro.config.mjs 설정으로 변환해야 합니다.
• 사이트 URL과 테마 설정 등이 포함됩니다.

URL 구조 유지:
• Astro의 redirects 기능을 사용해 URL 구조를 그대로 유지합니다.
• SEO는 영향을 받지 않습니다.
Hexo에서 Astro로 마이그레이션하는 구체적인 단계는 무엇인가요?
테마 변환:
• Hexo 테마를 Astro 컴포넌트로 변환해야 합니다.
• Hexo는 EJS/Jade 템플릿을, Astro는 .astro 컴포넌트를 사용합니다.

플러그인 이전:
• Hexo 플러그인 기능에 대응하는 Astro 통합 패키지를 찾거나 직접 구현해야 합니다.
• 대부분의 기능에는 대응하는 Astro 통합 패키지가 있습니다.

배포 설정:
• Hexo는 hexo deploy 명령으로 배포합니다.
• Astro는 npm run build로 빌드한 뒤 dist 디렉터리를 배포합니다.
• Vercel/Netlify/Cloudflare Pages에 간단히 배포할 수 있습니다.

콘텐츠 파일 이전:
• Hexo 콘텐츠 파일은 source/_posts/ 디렉터리에 있습니다.
• Astro는 Content Collections를 사용하므로 Markdown 파일을 src/content/posts/ 디렉터리로 옮겨야 합니다.
• frontmatter 형식을 조정합니다.
Next.js에서 Astro로 마이그레이션하는 구체적인 단계는 무엇인가요?
컴포넌트 이전:
• React 컴포넌트는 client:load 같은 지시어만 추가하면 바로 사용할 수 있습니다.
• Vue 컴포넌트도 바로 사용할 수 있습니다.

라우팅 변환:
• Next.js와 Astro 모두 파일 시스템 라우팅을 사용합니다.
• 다만 문법에 약간 차이가 있으므로 라우트 파일을 조정해야 합니다.

SSR 설정:
• Next.js의 SSR 기능을 사용했다면 Astro의 SSR 어댑터를 설정해야 합니다.
• Astro는 SSR, SSG, Hybrid 모드를 지원합니다.

배포 설정:
• Next.js는 보통 Vercel에 배포하며 Astro도 Vercel에 배포할 수 있습니다.
• 설정은 비슷하며 빌드 명령과 출력 디렉터리만 조정하면 됩니다.
마이그레이션이 SEO에 영향을 주나요? URL 구조를 유지할 수 있나요?
SEO 영향:
• 마이그레이션은 SEO에 영향을 주지 않으며 URL 구조도 그대로 유지할 수 있습니다.
• Astro의 redirects 기능을 사용해 URL 구조를 유지합니다.
• SEO는 영향을 받지 않습니다.

마이그레이션 모범 사례:
• SEO 중시하기(301 리디렉션 설정, sitemap 업데이트, 검색 순위 보호)
• 충분히 테스트하기(공개 전 링크, 이미지, 기능이 정상인지 확인)

이전 후 성능 향상은 분명하며 PageSpeed Insights 100점도 쉽게 달성할 수 있어 SEO에도 도움이 됩니다.

5분 읽기 · 게시일: 2025년 12월 3일 · 수정일: 2026년 9월 4일

댓글

GitHub로 로그인하여 댓글을 남기세요

Easton BlogEaston Blog