▲

Astro는 웹의 기본으로의 회귀입니다

 (websmith.studio)
8P by GN⁺ 9시간전 | ★ favorite | 댓글 1개

"Astro는 개발자를 위한 최고의 프레임워크임"

  • Astro는 컨텐츠 중심 웹사이트에 최적화된 신개념 웹 프레임워크로, 기본적으로 Zero JavaScript 정책과 뛰어난 성능, 간편한 개발 경험을 제공함
  • Island Architecture라는 독특한 방식으로 필요한 부분만 JavaScript를 적용, 나머지는 빠른 정적 HTML로 처리함
  • Astro 사이트는 기존 React 기반 대비 40% 이상 빠른 로딩 속도를 보여주며, 이로 인해 SEO, 사용자 경험, 전환율 등 실질적 이점을 제공함
  • 다른 프레임워크와 달리 데이터 로직과 프론트엔드 컴포넌트가 명확히 분리되어 있고, React·Vue 등 다양한 프레임워크와 혼용 가능함
  • 단, SPA나 복잡한 상태 관리, 대규모 라우팅이 필요한 경우에는 Next.js 등 기존 프레임워크가 더 적합할 수 있음

Astro란 무엇인가

  • Astro는 2021년에 등장한 웹 프레임워크로, 복잡한 앱을 위한 기존 JS 프레임워크와 달리 컨텐츠 중심 사이트에 집중해 설계됨
  • 기본 철학은 “컨텐츠 우선, 서버 우선, 기본은 Zero JavaScript” 로, 툴링 또한 직관적이고 쉽다는 점이 강점임

Island Architecture

  • Astro는 "Island Architecture" 라는 개념을 도입하여, 페이지 전체가 아닌 필요한 일부만 JavaScript를 적용함
  • 블로그 포스트처럼 대부분이 텍스트인 페이지는 HTML로만 렌더링되고, 코멘트나 캐러셀 등 상호작용이 필요한 부분만 JS를 로드함
  • 덕분에 페이지가 매우 빠르고 가벼움

실질적인 성능과 효과

  • Astro 기반 사이트는 전통적인 React 프레임워크보다 40% 이상 빠른 로딩을 기록함
  • 이런 성능 개선은 검색엔진 랭킹, 사용자 만족도, 전환율 등 비즈니스 성과로 이어짐
  • 느린 디바이스, 저속 네트워크 환경에서도 속도 차이가 더욱 크게 체감됨

개발자 경험(Developer Experience)

  • 프로젝트 셋업이 간단하고, “Houston”이라는 친절한 셋업 도우미가 가이드해줌
  • Astro 컴포넌트는 빌드 타임에만 실행되는 로직(예: 데이터 패칭, API 호출 등)이 가능함
  • 복잡한 상태 관리, 라이프사이클, 훅에 신경 쓸 필요 없이 필요할 때만 클라이언트 측 JS 활용 가능

다양한 프레임워크 호환성

  • React, Vue 등 주요 프레임워크를 Astro와 자유롭게 혼용할 수 있음
  • 예: 관리자 대시는 React, 데이터 시각화는 Vue, 나머지는 Astro로 구성 가능

‘작동하는’ 편의 기능들

  • Markdown을 컴포넌트처럼 직접 임포트하여 활용 가능
  • TypeScript, Sass, 이미지 최적화, 핫 모듈 리플레이스 등 현대적 빌드 파이프라인 지원
  • 정적 사이트/SSR/혼합 렌더링 모두 선택 가능, 프로젝트 성격에 맞게 유연하게 적용 가능

Astro가 빛나는 영역

  • 마케팅 사이트, 블로그, 이커머스 카탈로그, 포트폴리오 등 컨텐츠 중심 사이트에서 탁월한 성능
  • 복잡한 클라이언트 상태 관리가 필요 없는 환경에서 이상적임

트레이드오프

  • SPA, 복잡한 라우팅, 컴포넌트 간 상태 공유가 중요한 프로젝트에는 Next.js 등 다른 프레임워크가 더 적합함
  • 에코시스템 규모가 아직 작고, 파일 기반 라우팅이 대형 프로젝트에선 제한적으로 느껴질 수 있음

빠른 시작 방법

  • npm create astro@latest my-site
  • 필요시 npx astro add react 등으로 프레임워크 추가
  • src/pages/에 페이지, src/components/에 컴포넌트 추가 후 개발 시작

Astro의 의의

  • 최근 JS 프레임워크들이 점점 복잡해지는 가운데, Astro는 웹의 기본(빠르고 접근성 좋은 컨텐츠 중심 경험)으로 회귀하며 개발 편의성도 보장함
  • “빠른 사이트가 기본, 필요한 곳에만 인터랙티브 추가, 원하는 프레임워크 자유롭게 사용”이라는 설계 철학이 개발자를 만족시킴
  • 블로그부터 이커머스까지 컨텐츠 중심 프로젝트에 Astro를 적극 추천할 만함
▲
GN⁺ 9시간전  [-]
Hacker News 의견

  • 전통적인 웹 프레임워크는 항상 전체 페이지를 자바스크립트로 ‘하이드레이션’했음, 예를 들어 간단한 블로그 글에 단 하나의 인터랙티브 위젯이 있어도, 전체가 자바스크립트로 처리됨, 반면 Astro는 디폴트로 정적 HTML을 사용하고, 필요한 부분만 ‘자바스크립트 아일랜드’로 동작하게 함, 예전엔 이런 방식을 ‘점진적 향상(progressive enhancement)’ 또는 그냥 ‘웹 페이지’라고 불렀고, 이게 웹사이트를 만들 때 표준임, 그 후에 SPA가 등장해서 점진적 향상은 점점 덜 쓰였음, 지금은 ‘자바스크립트 아일랜드’라고 부르지만 결국 예전 방식으로 돌아간 것임, 관심 있는 신입 웹 개발자들에게 점진적 향상 개념을 추천하고 싶음

    • 누군가가 새로운 툴의 기능 설명을 듣고 기존에 했던 것과 같은 거라 착각할 때가 많음, 하지만 Astro의 진짜 가치는 다양한 자바스크립트 프레임워크와 연동되어 HTML의 일부 서브트리만 각각 처리할 수 있다는 것임, 이 때 초기 상태를 문자열로 렌더링해 클라이언트 쪽에서 미리 받아온 데이터로 하이드레이션됨, React/Svelte/Solid/Vue같은 프레임워크를 페이지의 일부에만 쓰고 싶고, 데이터를 서버에서 미리 불러오고 싶을 때 가치를 발휘함, 단 이 방식은 ‘점진적 향상’은 아님, 하이드레이션 전의 HTML이 제대로 동작할 필요는 없음, 예를 들어 <form>이 자바스크립트 없이 동작되지 않아도 됨, 이런 세부사항이야말로 냉소적으로 굴기보다는 호기심 있게 접근해야 깨달을 수 있는 점임

    • 완전히 동의함, Astro는 멋진 툴이지만 가장 어려웠던 점은 2010년 이후 입사한 개발자들이 웹 작동 방식을 설명하기 위해 만들어낸 각종 용어를 이해하는 것이었음

    • 새로운 개념은 아니지만, 지금 방식이 훨씬 더 세련된 느낌임, 예전엔 PHP와 jQuery로 인터랙티브 웹을 만들었는데, React와 SPA가 등장하기 전 시대였음, 지금 다시 생각해보면 아키텍처적으로는 옛날 방식이 더 우아했지만, 그 때는 디버깅이나 DX가 정말 안 좋았음, PHP로 프론트엔드에서 디버깅하는 시간은 다시 돌아가고 싶지 않음, SPA는 복잡한 대시보드나 인터랙티브 앱에서 여전히 용도가 있음, Astro는 서버와 클라이언트 코드를 한 곳에서 관리하게 해주고, 구분도 명확해서 데이터를 굳이 PHP 파싱해서 JS로 넘길 필요가 없어 DX가 크게 개선됨

    • AJAX라고 불렀던 시절이 기억남, 완전히 흐름을 잃은 느낌임

    • 초기 웹 프레임워크는 무상태 웹사이트와 서버 렌더링에 대해서는 정말 제대로 접근했다고 생각함

  • 개인적으로 Astro를 적극 추천함, 처음엔 "html과 css에 include 기능만 추가된 툴"이라 여겼는데, 개인 웹사이트와 Matrix Conference 사이트 리뉴얼 때 사용해보니 정말 번거로움 없이 쓸 수 있어 즐거웠음
    Astro의 주요 장점:

    • 여전히 html과 css 중심임
    • 빌드 후에는 js가 기본적으로 필요 없음
    • 인터랙티브가 필요한 곳에만 js를 선택적으로 추가 가능함
    • 컨텐츠 컬렉션 기능이 깔끔함
    • 속도 최적화가 극도로 잘 되어있고, 메인테이너가 방법을 잘 알고 있음
    • 개발용 Devbar가 있어서 웹사이트가 더 빨라질 수 있는 부분을 시각적으로 보여줌(예: 화면 아래 이미지 lazy load 등)
    • CSS 미니파이어가 일부 CSS를 인라인해서 추가 쿼리를 줄여줌
    • 이미지 컴포넌트는 content layout shift를 막기 위해 width/height 속성을 자동 설정해주고, responsive image도 제공함

    • Astro가 html과 css 중심이고 필요할 때 js만 추가하는 것이라면, 파일 디렉토리에 직접 .html, .css, .js 만들고 배포해도 똑같은 경험임, 오히려 그게 dev-time 오버헤드나 불필요한 bloat 없이 더 빠르지 않냐는 의문이 듦, 또한 CSS를 인라인하는 것이 실제로 성능상 큰 이슈였던 적은 없음, 수백 개의 웹사이트 경험에서도 CSS가 병목인 경우는 거의 없었고 실제로는 네트워크가 문제였음

    • 딱 한 가지 아쉬운 점은 라우팅이 복잡해질수록 추상화가 빠르게 증가해서 오히려 혼란스러워졌음, 복잡성은 무조건 friction을 동반한다는 점에서 결국 다른 방식을 선택했음

    • "html과 css에 include 기능"이 필요하다면 nginx 같은 일반 웹서버에서 서버사이드 인클루드를 활성화해 쓰면 됨, 20년 넘게 안정적이고 유지보수도 거의 필요 없는 솔루션임, 템플릿 엔진 같은 추가 보안 리스크도 없고, redundancy는 막으면서도 백엔드 취약점 걱정 없이 순수 인클루드만 할 수 있음

    • 20년간 데이터/백엔드만 하다 프론트엔드 프로젝트 때문에 다시 돌아왔는데, React로 고생하다 Astro+Svelte로 전환해서 정말 성공적이었음, HTML/CSS 중심이라 코드 구조가 예측 가능하고 깔끔한데, React 경력 개발자에게 프론트엔드를 넘겼을 때도 거의 바로 적응했음

  • "전통적인 프레임워크"라는 표현을 SPA/Virtual DOM 프레임워크 지칭으로 쓰는 걸 보니 세대 차이를 느낌, Backbone, jQuery 같은게 진짜 전통적 웹프레임워크였고, 이들이야말로 블로그 글 설명처럼 동작했음

    • "전통"이라는 건 결국 언제 태어났느냐에 따라 다르다고 생각함, 내게 전통 인터넷은 56k 모뎀, vbulletin 포럼, GTA:VC 모드, IRC 등이고, 더 오래된 세대한텐 BBS가, 더 젊은 세대한텐 Discord가 "전통" 인터넷일 것임, 정치에도 비슷한 현상이 있는데 다들 자기가 젊을 때가 좋았다고 여기는 경향임

    • Backbone은 pure SPA용으로 클라이언트 MVC를 지향했던 기억이 남

  • Astro, NextJS 등 SSR 프레임워크가 SvelteKit처럼 동적인 경로가 있는 정적 페이지를 지원하지 않는 이유가 궁금함, 예를 들어 /todos/[todoId] 같은 페이지를 NextJS에서는 아예 static bundle에 넣을 수 없음, 반면 SvelteKit은 404.html을 이용해서 실제로는 404지만 클라우드플레어나 모바일 웹뷰 환경에서 완벽히 동작함, 이런 기능이 특히 모바일 웹뷰 번들링 시 매우 유용함

    • 부분적으로 동의하는데, 이런 설계는 단점도 있음, /todos/123 같은 URL을 SPA에서 하드 리로드하면 실제 서버에 해당 파일이 있는지 요청하게 되고, 없는 경우 404로 받음, 그래서 404 페이지에서 클라이언트 라우팅으로 다시 데이터를 불러와 처리해야 하는데, 이건 nginx 등 HTTP 서버 설정이 꼭 필요함, 즉 순수 정적 파일만으로는 불가능함, 또 HTTP 스펙상 브라우저 캐시는 404 응답을 절대 저장하지 않음, 그래서 하드 리로드나 북마크 시 캐시를 절대 못 씀, 이런 설정이 부담스럽다면 쿼리 파라미터를 써서 /todo?id=123처럼 처리하는게 오히려 좋다고 봄

    • 내가 잘못 이해한 걸 수도 있지만, Next나 Astro의 static build에서도 동적 라우팅/페이지를 구현한 적 있음, CMS로 contentful이나 storyblok을 쓸 때 에디터가 자유롭게 라우트와 컴포넌트를 만들게 했고, [...slug] 패턴으로 모든 라우트를 커버함, getStaticPaths 함수를 활용해서 모든 페이지를 사전 생성했음, ISR/ISP 옵션 켜면 빌드타임에 몰랐던 페이지도 동적으로 프리렌더 됨, Next에선 dynamic routes, Astro에선 dynamic pages라고 부름
      참고: Next dynamic routes, Astro dynamic pages

    • 혹시 내가 이해를 잘못했을 수도 있는데, Astro의 getStaticPaths 함수가 원하는 기능 지원하는 것 같음
      참고

    • 나도 정적 배포를 좋아해서 참고 차원에서 말하자면, NextJS에서도 정적 파라미터 생성 지원함

    • 내가 Astro나 다양한 프레임워크를 완전히 이해한 건 아니지만, 혹시 Astro의 server islands가 원하는 기능과 비슷한지 살펴보길 추천함

  • 프론트엔드 논의 자체가 너무 혼란스럽다고 느껴짐, 기사에서 이야기하는 내용도 결국 “브라우저를 HMI로 쓸 것인가, 애플리케이션 런타임으로 쓸 것인가”로 귀결됨, 하지만 논의 대부분이 “신선하다”, “빨리 로드된다” 같은 애매한 주장임, 프레임워크를 브랜드처럼 홍보하는 분위기가 패션 산업과 너무 흡사하다고 생각함

    • 패션 산업이야말로 프론트엔드 프레임워크 논의를 설명할 수 있는 최고의 비유라고 봄, “content-driven”, “server-first” 같은 주장을 기술적으로 엄밀하게 따지는 경우가 거의 없음

    • “빨리 로드된다”가 허상이라고 하기엔 이해가 안 됨, 실제로 중요한 요소임

  • 최근 의료 기관 웹사이트를 Astro로 만들었는데, 예전에 Wordpress로 만들 때보다 훨씬 쉽고, 무료로 Netlify 같은 곳에 호스팅할 수 있어서 해킹 걱정 안 해도 됨, git 기반의 단순한 CMS까지 만들어서 클라이언트가 직접 컨텐츠도 수정 가능하게 했음, 웹 개발이 진짜 많이 발전했다고 느낌

    • 혹시 지인이 부탁해서 만든 것인지, 의료기관 웹사이트 제작 의뢰는 어떻게 구하는지 궁금함

    • Netlify가 Vercel보다 대역폭 요금이 더 높으니 주의하길 바람

  • Astro의 가장 큰 장점은 React나 Vue 같은 기타 프레임워크 의존 없이, HTML이나 Web Component만으로 작업 가능하다는 점임, 하지만 Astro 역시 Next, Nuxt와 마찬가지로 SSR, ISR, SSG, 미들웨어를 지원함
    차별점으로는 아일랜드 아키텍처가 있는데, 이를 통해 마이크로 프론트엔드 구현이 가능함
    예를 들어, 하나의 기업 내 여러 팀이 각각 결제, 장바구니, 상품 페이지를 만들어도 한 페이지에 통합 적용 가능하고, 렌더링 방식을 직접 제어할 수 있음, 글로벌 상태도 공유할 수 있어서 각 팀이 독립적으로 전체 책임을 지고 파트별로 개발/배포 가능함
    단, 이런 구조는 대형 프로젝트에나 필요한 솔루션임, 모든 팀이 React를 각자 다르게 쓰면 다양한 버전이 혼재하지만, Astro처럼 아키텍처로 분리하면 그 문제를 해결할 수 있음
    개인적으로 웹을 완전히 바꿀지는 확신하지 못함, Next/Nuxt에서 프레임워크 의존성 제거하고 아일랜드 아키텍처 추가된 정도라고 느낌, 하지만 써보는 걸 추천함
    React/Vue를 벗어나 web-component로 이전하거나 Next/Nuxt를 대체하고 싶으면 단계적으로 Astro를 활용할 수 있어 추천함

  • 나에게 Astro가 모든 상황에서 완벽하진 않음, 어떤 때는 offline rendering만 필요하다면 굳이 자바스크립트를 억지로 써야 할 이유가 없었음
    아일랜드 아키텍처도 한계가 있고, 빌드된 결과물이 지나치게 inlined되는 경우도 많아짐
    솔직히 Astro 하이프는 Vite 덕이 더 큰 것 같음, Vite는 정말 최고임

    • “아일랜드 아키텍처가 한계에 부딪힐 때”가 언제냐고 묻고 싶음

  • Next.js를 React의 표준 프레임워크로 추천하지 않았으면 함, 프론트엔드에는 더 비판적 사고가 필요함, Remix(React Router v7)나 TanStack이 훨씬 더 좋은 대안임

    • 나도 동의함, Next.js가 잠재력 있었던 건 맞지만 Vercel이 개입한 후로 많이 퇴보했다고 느낌, v10부터 써왔고, v13 혼란기와 v15까지 경험하면서 많이 실망했음, React와 Next.js는 변화 속도가 너무 빨라서 따라가기 불가능하고, 변화가 정말 필요해 보이는 순간보다 변화를 위한 변화가 더 많다고 느낌

    • React 자체를 디폴트 프레임워크로 추천하는 것조차 멈추고 싶음, 프론트엔드 개발에는 HTML/CSS/JS가 훨씬 낫다고 생각함

    • Remix/React Router v7은 올바른 방향이라 생각함, 특히 Remix가 preact를 쓰고 웹 표준 중심으로 간다면 더 견고한 웹사이트 제작 방식이 돌아올 거라 기대함, 다만 Remix에서 RR7로 갈아타는 전환이 매끄럽지 못해서 프로젝트를 rewrite해야 했음

  • 웹의 기본 원칙들은 여전히 유효하다고 생각함, PHP, Spring, Quarkus, ASP.NET MVC를 쓰는 개발자 입장에선 JS 프레임워크 기반 웹 개발 환경이 얼마나 힘들어졌는지 체감하지 못할 수 있음, 패션 주도적인 업계 분위기 탓에 기본으로 돌아가기가 쉽지 않다고 느낌

답변달기