Astro란? 3분 만에 이해하는 제로 JS, 아일랜드 아키텍처, 콘텐츠 우선의 진짜 의미

얼마 전 Next.js로 기술 블로그를 만들었습니다. 코드를 다 작성하고 번들링해 보니 JavaScript 용량이 단숨에 500KB까지 치솟았습니다. 그저 글을 보여 주는 사이트이고 대부분의 페이지가 텍스트와 이미지로 이루어졌는데, 왜 이렇게 많은 JS를 로드해야 하는지 당황스러웠습니다.

Chrome DevTools를 열어 보니 상황은 더 심각했습니다. 첫 화면을 불러오는 데 3초나 걸렸고 ‘사용하지 않는 JavaScript’ 경고도 잔뜩 표시됐습니다. React/Vue로 콘텐츠 사이트를 만드는 것이 혹시 작은 일에 너무 무거운 도구를 쓰는 선택은 아닌지 의문이 들기 시작했습니다.

그러다 Astro를 알게 됐습니다. Astro의 철학은 간단합니다. 대부분의 웹사이트에는 그렇게 많은 JavaScript가 필요하지 않습니다. 꽤 과격하게 들리지 않나요? 하지만 아키텍처 설계를 살펴보고 나니 오히려 상당히 합리적인 생각이라는 것을 알게 됐습니다.

이 글을 끝까지 읽으면 Astro의 세 가지 핵심 철학인 콘텐츠 우선, 기본 제로 JS, 아일랜드 아키텍처가 실제로 무엇을 뜻하는지 이해할 수 있습니다. 또한 Next.js, React 같은 전통적인 프레임워크와 본질적으로 무엇이 다른지, 언제 Astro를 선택하고 언제 선택하지 말아야 하는지도 알게 됩니다. 뜬구름 잡는 이야기는 빼고 쉽게 설명하겠습니다.

먼저 전통적인 프레임워크가 왜 무거운지 살펴보겠습니다. 정적 사이트에 500KB의 JavaScript가 필요한 이유는 무엇일까요?

전통적인 SPA(단일 페이지 애플리케이션)가 어떻게 작동하는지부터 알아보면 왜 그렇게 ‘무거운지’ 이해할 수 있습니다.

React를 예로 들어 보겠습니다. React 웹사이트에 접속하면 브라우저는 먼저 전체 React 런타임(약 130KB)을 로드한 뒤 비즈니스 코드를 불러옵니다. 이어서 ‘hydration’(하이드레이션)을 수행해 서버에서 렌더링한 정적 HTML을 상호작용 가능한 컴포넌트로 바꿉니다. 꽤 합리적으로 들립니다.

하지만 문제가 있습니다. 페이지가 블로그 글 하나를 보여 줄 뿐이고 콘텐츠의 90%가 상호작용이 필요 없는 텍스트와 이미지라면, 왜 이렇게 많은 JS를 로드해야 할까요?

인상적인 데이터를 본 적이 있습니다. 전통적인 SPA 프레임워크가 번들링한 평균 500KB의 JS 중 60%는 사용되지 않습니다. 3초를 들여 로드한 코드 대부분이 사실상 아무 일도 하지 않는 셈입니다.

바로 이것이 핵심적인 모순입니다. 콘텐츠 중심 웹사이트와 상호작용이 많은 애플리케이션의 요구 사항은 완전히 다릅니다. 온라인 문서 편집 도구가 실시간 협업을 처리하기 위해 많은 JS를 필요로 하는 것은 당연합니다. 하지만 제품 소개만 보여 주는 페이지에도 정말 이렇게 무거운 프레임워크가 필요할까요?

Astro는 이 문제를 발견하고 대담한 생각을 제안했습니다. JS를 기본으로 로드하지 말자는 것입니다.

Astro의 핵심 철학 1: 콘텐츠 우선(Content-Focused)

여기서 ‘콘텐츠 우선’이란 콘텐츠를 많이 작성해야 한다는 뜻이 아닙니다. 웹사이트의 중심은 복잡한 애플리케이션 로직이 아니라 콘텐츠를 보여 주는 일이라는 아키텍처 철학입니다.

쉽게 말해 Astro는 웹사이트를 두 종류로 나눕니다.

• 콘텐츠 중심 사이트: 블로그, 문서 사이트, 공식 웹사이트, 제품 소개 페이지, 이커머스 상품 상세 페이지
• 애플리케이션형 사이트: 온라인 협업 도구, 관리자 페이지, 실시간 채팅, 복잡한 폼

Astro의 포지셔닝은 분명합니다. 첫 번째 유형의 웹사이트를 위해 태어난 도구입니다. ‘Next.js로도 블로그를 만들 수 있지 않나?’라고 생각할 수 있습니다. 물론 가능하지만, 장을 보러 갈 때 탱크를 모는 것처럼 다소 낭비가 큽니다.

실제 사례를 하나 들어 보겠습니다. CITIC Bank는 Astro로 금융 수준의 메타데이터 플랫폼을 구축했습니다. Next.js에서 마이그레이션한 뒤 JS 코드 용량을 90% 줄였고 페이지 성능은 30% 향상됐습니다. 지어낸 이야기가 아니라 실제 사례입니다.

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

"CITIC Bank는 Astro로 금융 수준의 메타데이터 플랫폼을 구축했습니다. Next.js에서 마이그레이션한 뒤 JS 코드 용량을 90% 줄였고 페이지 성능은 30% 향상됐습니다."

Astro의 논리는 이렇습니다. 웹사이트가 주로 텍스트, 이미지, 동영상 같은 콘텐츠를 보여 준다면 대부분의 페이지는 빠르게 로드되고 SEO에도 유리한 정적 HTML이어야 합니다. 댓글 영역이나 검색창처럼 실제로 상호작용이 필요한 곳에서만 필요한 JS를 로드합니다.

이것이 ‘콘텐츠 우선’의 진짜 의미입니다. 콘텐츠를 프레임워크에 억지로 끼워 맞추는 대신 아키텍처가 콘텐츠를 지원하게 합니다.

Astro의 핵심 철학 2: 기본 제로 JavaScript(Zero JS by Default)

‘기본 제로 JS’라는 말을 처음 들었을 때 저도 당황했습니다. ‘JS를 쓰지 않으면서 현대적인 프레임워크라고 할 수 있나?’ 나중에야 이 말이 기본적으로 클라이언트에 JS를 전송하지 않지만 필요에 따라 추가할 수 있다는 뜻임을 이해했습니다.

Next.js 같은 전통적인 SSG/SSR 프레임워크는 어떻게 동작할까요? 먼저 서버에서 HTML을 렌더링한 다음 전체 React 프레임워크와 컴포넌트 코드를 브라우저에 전송해 전체 하이드레이션을 수행합니다. 페이지가 텍스트 하나만 보여 주더라도 React 런타임을 로드해야 합니다.

Astro의 접근 방식은 완전히 반대입니다. 먼저 JS가 전혀 없는 순수 정적 HTML을 생성합니다. 상호작용이 필요한 곳에는 개발자가 직접 ‘이 컴포넌트에는 JS가 필요하다’고 표시합니다.

비교 데이터를 보면 차이가 직관적으로 드러납니다. 같은 문서 사이트를 번들링했을 때 Next.js의 JS는 대략 150KB부터 시작합니다. Astro는 어떨까요? 11KB 또는 그보다 작을 수도 있습니다. Lighthouse 성능 점수도 99점에 도달할 수 있습니다.

‘이미지 캐러셀을 추가하고 싶으면 어떻게 하지?’라는 질문이 생길 수 있습니다. 간단합니다. 해당 컴포넌트에 표시를 추가해 Astro에 ‘여기는 JS가 필요하다’고 알려 주면 됩니다. 다른 부분은 그대로 정적으로 유지되므로 영향을 받지 않습니다.

이것이 ‘기본 제로 JS’의 핵심입니다. JS를 쓸 수 없다는 뜻이 아니라, 실제로 필요한 곳에서만 사용한다는 뜻입니다. 페이지에 모듈이 10개 있고 그중 9개가 정적이라면 1개 모듈만 JS를 로드합니다. 아주 깔끔합니다.

Astro의 핵심 철학 3: 아일랜드 아키텍처(Islands Architecture)

‘아일랜드 아키텍처’라는 이름은 조금 신비롭게 들리지만 개념은 매우 단순합니다. 다음처럼 이해하면 됩니다.

정적 HTML로 이루어진 바다 위에 상호작용이 필요한 몇 개의 ‘섬’이 떠 있다고 상상해 보세요.

바다 부분인 정적 콘텐츠는 JS가 필요 없어 매우 빠르게 로드됩니다. 섬 부분인 상호작용 컴포넌트는 각자 필요한 JS를 독립적으로 로드하며 서로 간섭하지 않습니다. 이것이 Astro의 아일랜드 아키텍처입니다.

이 개념은 Etsy의 프론트엔드 아키텍트 Katie Sylor-Miller가 2019년에 처음 제안했고, 이후 Preact의 창시자 Jason Miller가 발전시켰습니다. Astro는 이 아키텍처를 실제 프로덕션 환경에 적용한 최초의 프레임워크입니다.

기술적으로는 ‘부분 하이드레이션’(partial hydration)을 사용합니다. 전통적인 프레임워크는 전체 하이드레이션을 수행하므로 페이지 전체의 가상 DOM을 다시 만들어야 합니다. 반면 Astro는 ‘상호작용 필요’로 표시한 컴포넌트만 하이드레이션합니다.

예를 들어 블로그 글 페이지가 다음 부분으로 구성됐다고 해 보겠습니다.

• 글 제목과 본문(정적)
• 목차 탐색(정적)
• 댓글 영역(상호작용 필요)
• 공유 버튼(상호작용 필요)

전통적인 프레임워크는 페이지 전체를 하이드레이션하지만 Astro는 댓글 영역과 공유 버튼만 하이드레이션합니다. 그 결과 TTI(Time to Interactive)를 300% 단축할 수 있습니다.

더 멋진 점은 Astro가 여러 ‘하이드레이션 지시문’을 제공해 JS를 언제 로드할지 정밀하게 제어할 수 있다는 것입니다.

• client:load - 페이지가 로드된 직후 즉시 로드(핵심 상호작용에 적합)
• client:idle - 브라우저가 유휴 상태일 때 로드(급하지 않은 기능)
• client:visible - 스크롤해 화면에 나타날 때 로드(이미지 캐러셀, 동영상 플레이어)

각 섬은 서로를 차단하지 않고 독립적으로 렌더링됩니다. 댓글 영역의 로드가 늦어져도 공유 버튼은 정상적으로 작동합니다. 여러 컴포넌트를 병렬로 로드하는 상황에서 특히 유용합니다.

쉽게 말해 아일랜드 아키텍처는 ‘필요할 때만 로드한다’는 개념을 극한까지 발전시킨 방식입니다.

전통적인 프레임워크와의 핵심 차이: 세 가지 웹사이트 구축 철학 비교

이제 Astro의 접근 방식을 어느 정도 이해했을 것입니다. 하지만 ‘React, Next.js와 정확히 무엇이 다르고 어떤 것을 선택해야 할까?’라는 고민은 남아 있을 수 있습니다.

관점을 바꿔 보면 이 프레임워크들은 서로 완전히 다른 세 가지 웹사이트 구축 철학을 대표합니다.

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

1. 순수 React/Vue/Svelte - 클라이언트 중심 철학

브라우저를 애플리케이션 실행 환경으로 보고 최고의 상호작용 경험을 추구하는 것이 핵심입니다.

• 특징: 모든 로직이 클라이언트에서 실행되고 JS 용량은 크지만 상호작용이 매끄러움
• 적합한 사용 사례: SaaS 관리자 페이지, 온라인 드로잉 도구, 문서 편집기, 복잡한 폼
• 대표 사례: Figma, Notion, Google Docs

상호작용이 자주 필요한 Web 애플리케이션을 만든다면 이 방식에 문제가 없습니다.

2. Next.js/Nuxt - 풀스택 플랫폼 철학

SPA의 상호작용 능력과 SSR/SSG의 성능 및 SEO를 모두 얻으려는 방식입니다. 이들은 단순한 프론트엔드 프레임워크가 아니라 백엔드 API까지 작성할 수 있는 ‘풀스택 개발 플랫폼’을 지향합니다.

• 특징: 서버 사이드 렌더링 + 클라이언트 하이드레이션, 기능은 포괄적이지만 용량이 비교적 큼
• 적합한 사용 사례: 복잡한 이커머스, 소셜 애플리케이션, 데이터를 자주 갱신해야 하는 웹사이트
• 대표 사례: Netflix, TikTok, Hulu

프로젝트에 복잡한 사용자 상호작용과 서버 로직이 모두 필요하다면 Next.js가 좋은 선택입니다.

3. Astro - 콘텐츠 우선 철학

핵심은 ‘기본 정적 HTML + 필요에 따른 JS’이며 콘텐츠 중심 웹사이트에 맞게 최적화됐습니다.

• 특징: JS 용량이 매우 작고(83~90% 절감) 성능이 뛰어나며 SEO에 유리함
• 적합한 사용 사례: 블로그, 문서 사이트, 공식 웹사이트, 마케팅 페이지, 이커머스 상품 소개
• 대표 사례: 기술 블로그, 기업 웹사이트, 온라인 문서

콘텐츠 사이트를 만든다면 Astro가 압도적으로 유리합니다.

한눈에 볼 수 있도록 비교표로 정리했습니다.

핵심은 Astro가 프레임워크에 종속되지 않는다는 점입니다. React, Vue, Svelte로 컴포넌트를 작성할 수 있고 하나의 프로젝트에서 혼용할 수도 있습니다. Astro는 React를 대체하려는 것이 아니라 ‘필요할 때만 React를 쓰는’ 선택지를 제공합니다.

Astro는 어디에 적합하고 어디에 적합하지 않을까요?

그렇다면 언제 Astro를 사용해야 할까요? 빠르게 판단할 수 있도록 목록으로 정리했습니다.

✅ Astro가 적합한 사용 사례:

1. 개인 블로그, 기술 문서 사이트

   • 텍스트와 이미지가 중심
   • 상호작용이 적음(댓글 영역, 검색창 정도)
   • SEO 최적화가 필요함
   • 예: 지금 보고 있는 대부분의 기술 블로그

2. 기업 웹사이트, 마케팅 랜딩 페이지

   • 제품과 서비스를 소개
   • 빠른 로드가 필요함(첫 화면 속도가 전환율에 영향)
   • 콘텐츠가 비교적 고정적임
   • 예: SaaS 제품 웹사이트, 이벤트 홍보 페이지

3. 이커머스 상품 소개 페이지

   • 장바구니와 결제 흐름이 아니라 ‘소개 페이지’라는 점에 주의
   • 많은 상품 이미지와 설명
   • SEO가 필요함(검색 엔진에 상품 노출)
   • 예: 상품 상세 페이지, 카테고리 페이지

4. 포트폴리오 사이트, 개인 홈페이지

   • 프로젝트와 기술을 소개
   • 간결하고 빠름
   • 유지 보수가 쉬움
   • 예: 디자이너 포트폴리오, 개발자 개인 사이트

❌ Astro가 적합하지 않은 사용 사례:

1. 상호작용이 많은 Web 애플리케이션

   • 온라인 협업 도구(Figma, Miro와 유사한 도구)
   • 복잡한 대시보드(실시간 데이터 갱신)
   • 관리자 페이지(많은 폼과 작업)
   • 이런 환경에서는 페이지 전체에 JS가 필요하므로 Astro를 사용하는 것이 오히려 불필요한 단계를 추가함

2. 실시간 데이터 갱신이 필요한 애플리케이션

   • 채팅 애플리케이션
   • 주식 거래 플랫폼
   • 실시간 협업 문서
   • Astro는 주로 정적 페이지를 생성하므로 실시간 데이터 처리에 능하지 않음

3. 순수 단일 페이지 애플리케이션(SPA)

   • 웹사이트 자체가 복잡한 애플리케이션이며 SEO가 필요하지 않은 경우
   • 이때는 React/Vue를 바로 사용하는 편이 좋고 Astro의 도움을 받기 어려움

간단한 판단 기준이 있습니다.

다음 두 가지를 스스로에게 물어보세요.

1. 내 웹사이트는 주로 콘텐츠를 보여 주는가, 아니면 복잡한 상호작용을 제공하는가?
2. JavaScript를 모두 꺼도 웹사이트를 볼 수 있는가?

답이 ‘콘텐츠 표시’와 ‘볼 수 있음’이라면 Astro가 적합할 가능성이 높습니다. 답이 ‘복잡한 상호작용’과 ‘볼 수 없음’이라면 Next.js나 순수 SPA 프레임워크를 고려하는 편이 좋습니다.

초보자에게 친화적인가요? 학습 비용은 높은가요?

‘또 새로운 프레임워크를 처음부터 배워야 하나?’라고 걱정할 수 있습니다. 다행히 Astro의 학습 곡선은 정말 완만합니다.

매우 익숙한 문법

Vultr - 고성능 NVMe 클라우드 서버, 전 세계 32개 노드, Docker 원클릭 배포

요금 보기 →광고

.astro 파일의 문법은 JSX, Vue와 거의 같습니다. React나 Vue를 사용해 본 적이 있다면 한 번 훑어보는 것만으로도 시작할 수 있습니다. ‘학습 곡선이 놀라울 만큼 완만하다’고 평가하는 사람도 있습니다.

반드시 .astro 문법을 쓸 필요도 없습니다. .md(Markdown), .jsx(React), .vue(Vue)로 바로 콘텐츠를 작성할 수 있습니다. 원하는 형식을 고를 수 있고 하나의 프로젝트에서 혼용할 수도 있습니다.

바로 사용할 수 있는 테마

Astro에는 완성된 블로그, 문서 사이트, 포트폴리오 템플릿이 가득한 테마 마켓이 있습니다. 마음에 드는 템플릿을 골라 글과 색상만 바꾸면 30분 안에 공개할 수 있습니다. 말 그대로 ‘Markdown만 조금 바꿔도 멋진 웹사이트를 만들 수 있는’ 셈입니다.

쾌적한 개발 경험

내부적으로 Vite와 Esbuild를 사용해 시작 속도가 매우 빠릅니다. 핫 리로드도 빨라서 코드를 수정하면 곧바로 결과를 볼 수 있습니다. 개발자에게는 정말 중요한 장점입니다.

문서와 커뮤니티도 잘 갖춰져 있습니다

Astro 공식 문서는 단계별로 시작 방법을 명확하게 설명합니다. 커뮤니티에도 다양한 튜토리얼과 동영상이 있어 문제가 생겨도 대부분 답을 찾을 수 있습니다.

솔직히 블로그나 문서 사이트를 만들고 싶다면 Astro가 가장 빠른 선택일 수 있습니다. 복잡한 번들링 도구를 설정하거나 라우팅 작성법을 고민할 필요 없이 바로 사용할 수 있습니다.

결론

지금까지 살펴본 Astro의 세 가지 핵심 철학을 다시 정리해 보겠습니다.

1. 콘텐츠 우선: 콘텐츠 중심 웹사이트를 위해 설계되어 아키텍처가 콘텐츠를 지원함
2. 기본 제로 JS: 기본적으로 JavaScript를 전송하지 않고 실제로 필요한 곳에서만 로드함
3. 아일랜드 아키텍처: 정적 HTML 바다 위의 상호작용 섬을 독립적으로 하이드레이션해 서로 차단하지 않음

전통적인 프레임워크와의 핵심 차이는 현대적인 프레임워크의 개발 경험으로 정적 웹사이트의 성능을 출력한다는 점입니다. 컴포넌트화, 핫 리로드, TypeScript 지원 같은 현대적인 기능을 누리면서도 순수 HTML에 가까운 로드 속도를 얻을 수 있습니다.

블로그, 문서 사이트, 공식 웹사이트, 마케팅 페이지를 만들고 있다면 Astro를 한 번 사용해 보세요. 만능 도구는 아니지만 잘하는 영역에서는 확실히 압도적인 성능을 발휘합니다.

마지막으로 한 가지를 강조하고 싶습니다. Astro는 ‘JS를 쓸 수 없다’는 것이 아니라 ‘기본적으로 JS를 쓰지 않는다’는 뜻입니다. 상호작용이 필요한 곳에서는 당연히 사용해야 하지만, 전통적인 프레임워크처럼 전체 런타임을 모두 전달하지는 않습니다.

시작하고 싶다면 Astro 공식 웹사이트에서 문서를 확인하세요. 테마 마켓도 둘러보면 마음에 드는 템플릿을 찾을 수 있을 것입니다. 너무 고민하지 말고 직접 사용해 보세요.