▲

Astro 개발자를 위한 RSC

 (overreacted.io)
1P by GN⁺ 8시간전 | ★ favorite | 댓글 2개
  • Astro와 React Server Components(RSC) 는 서버와 클라이언트 코드 분리를 유사하게 구현함
  • Astro에서는 Astro Component와 Client Island가 각자 기능적 역할을 분담함
  • RSC는 동일 개념을 Server Component와 Client Component로 나누며 'use client' 지시어로 경계 설정함
  • RSC는 Astro에 비해 인터랙티브 UI 구성 및 코드 공유 유연성이 높음
  • 두 모델 모두 데이터가 서버에서 클라이언트로 단방향 흐름을 갖는 구조임

소개 및 기본 개념

  • Astro는 Astro Component와 Client Island라는 두 가지 주요 컴포넌트 유형을 제공함
  • Astro Component는 .astro 확장자를 가지며 서버 또는 빌드 타임에만 실행되고, 파일 시스템 접근, DB 조회, 내부 서비스 호출 같은 클라이언트에서 할 수 없는 작업이 가능함
  • Client Island는 React, Vue 등을 위한 컴포넌트로, 브라우저 상에서 동작하며 사용자 인터랙션을 담당하는 부분임
  • Astro Component 내부에서 Client Island를 렌더링할 수 있지만, Client Island에서 Astro Component를 호출하는 것은 불가능함
  • 이 구조는 데이터가 항상 서버에서 클라이언트로만 흐른다는 단방향성을 보장함

코드 예시와 역할 분리

  • 예시 코드에서 PostPreview.astro가 서버에서 파일을 읽고 제목을 가져온 뒤, 해당 데이터를 Client Island에 전달함
  • LikeButton은 React로 작성되어, 브라우저 로드 후 상태 변화 및 사용자 클릭 이벤트를 담당하게 됨
  • Astro Component와 Client Island는 서로 다른 세계에서 동작하고, 데이터 전달도 Astro Component에서만 아래로 이루어짐

React Server Components(RSC)와의 비교

  • RSC에서도 Astro와 유사하게 서버 컴포넌트(Server Component)와 클라이언트 컴포넌트(Client Component)로 구분함
  • React Server Component에서는 JavaScript 함수로 서버 컴포넌트를 선언하고, 'use client' 지시어로 어디서 클라이언트 코드가 시작되는지 명확히 지정함
  • RSC에서는 동일한 컴포넌트 파일이 서버, 클라이언트 역할 모두 가능한데, Astro처럼 파일 확장자나 별도의 분리 없이 필요에 따라 'use client' 선언만으로 경계 이동이 가능함
  • 컴포넌트가 클라이언트 전용 기능(예: useState) 혹은 서버 전용 기능(DB 접근 등)을 사용하면, 잘못된 환경에서 사용할 때 빌드 오류가 발생하여 명확한 피드백을 얻음

Astro와 RSC의 시각적/구조적 차이

  • Astro는 .astro 파일과 JS/TS 파일 구분으로 명확한 경계를 가짐
  • RSC는 기본적으로 모든 것이 React이므로 코드 공유성과 유연성이 훨씬 뛰어남
  • 예를 들어, 상태나 서버 기능을 사용하지 않는 중립 컴포넌트(Markdown 파서 등)는 양 쪽 어디서든 사용할 수 있음
  • RSC는 가져오기(import) 경로에 따라 해당 컴포넌트가 어느 세계에서 동작할지 자동 결정됨

RSC 모델의 장점과 한계

  • RSC의 이점은 코드 재사용과 역할 이동의 유연성에 있음
    • 어떤 컴포넌트든 필요에 따라 'use client' 선언만으로 경계를 쉽게 이동 가능함
    • Astro에서는 UI의 정적/동적 성격 변동 시 코드 변환이 번거로울 수 있는데, RSC는 이를 간단히 해결할 수 있음
  • RSC의 단점은 학습 난이도가 높다는 점임
    • 개발자가 현재 “어느 세계에 있는지” 계속 고민하게 되지만, 실수 시 빌드 오류로 빠른 피드백을 얻음
  • Astro에서는 UI의 동적인 부분이 많아질수록 구조가 복잡해지는데, RSC는 React 트리 전체가 통합되어 있어 상태, 맥락(Context) 전달 등이 자연스럽게 이루어짐

HTML 중심인 Astro와 React 트리 중심인 RSC

  • Astro의 결과물은 HTML로, 페이지 이동마다 전체가 새로고침되고 완전한 SPA 경험을 제공하지는 않음
  • RSC의 결과물은 React 트리(처음에는 HTML, 내비게이션 시 JSON 등으로 전송)임
    • 덕분에 SPA와 MPA의 장점을 결합할 수 있음
  • 서버에서 직접 UI 일부만 새로 고쳐 반영하는 부분적 새로고침이 가능하여, 동적 데이터 수신과 클라이언트 상태 유지도 쉬움

고급 React 기능 지원

  • 서버-클라이언트 혼합 트리 구조로, React의 앞선 기능(예: <Suspense>, 뷰 트랜지션 등)이 자연스럽게 통합 지원됨
  • 클라이언트에서 declarative하게 핸들링한 로딩 상태, 폰트/이미지/자바스크립트/스타일 지연 등도 관리 가능함
  • React의 모든 기능이 서버-클라이언트 경계 없이 엔드 투 엔드로 작동함

RSC와 Astro의 위상

  • Astro는 완전한 프레임워크이며, RSC는 프레임워크의 빌딩 블록이나 표준에 가까움
  • 공식적인 RSC 구현은 Next.js App Router와 Parcel RSC가 있음

결론 및 추천

  • RSC의 개발자 경험(DX)은 아직은 거칠지만, 배워볼 가치가 있음
  • Astro를 경험해보지 않았다면 추천하며, Astro는 RSC가 어려운 개발자에겐 더 부드러운 진입로를 제공할 것임
  • 클라이언트 사이드 React만 써온 개발자에게도 Astro는 예상치 못한 문제 해결 경험을 줄 수 있음
▲
GN⁺ 8시간전  [-]
Hacker News 의견
  • 내가 Astro보다 RSC를 사용할 유일한 이유는 섬(island)들 사이에 context를 공유할 수 있기 때문임, 그 외 특별한 장점은 없음, 그리고 사소한 점이지만 이 글에서 Astro의 "code fence" 개념을 명확히 언급하고 설명했으면 좋았겠음, 이 아이디어는 React의 'use client'보다 서버와 클라이언트의 경계를 훨씬 더 명확히 구분해줌
    • 내 생각엔 code fence가 진짜로 경계를 나타낸다고 생각하지 않음, fence 아래 코드도 반드시 서버에서 실행됨, 그렇지 않으면 Astro 컴포넌트를 거기서 참조할 수 없게 됨, 내가 이해하기에 fence는 "바인딩 vs 템플릿" 구분을 의미할 뿐 "서버 vs 클라이언트"를 말해주지는 않음
    • 섬들 사이에 context를 공유하는 건 Astro에선 정말 쉬운 일임, 이 링크를 참고하면 됨 https://docs.astro.build/en/recipes/sharing-state-islands/
  • Astro는 콘텐츠 중심 웹사이트를 위한 웹 프레임워크임, https://github.com/withastro/astro
    • Gatsby를 쓰던 사람들은 결국 GraphQL을 통해 연결된 불안정한 이미지 처리 파이프라인에서 벗어난 날을 평생 기억하게 됨, (그들은 그때 컴퓨터 앞에 있었음), 증거는 없지만 Astro의 net promoter score에는 다섯 개의 9가 들어간다는 건 과학적 사실임
    • Astro 엄청 좋음, 몇 년 전부터 SSG로 기본 선택이 되었고, 이제는 앱 제작에도 Astro를 진지하게 고려 중임, 혹시 Astro를 앱에 써 본 경험 있는 사람 있음?, 나는 Astro로 섬 기반 HTML만 렌더링하고 백엔드는 non-JS로 쓸 생각임
    • "콘텐츠 중심 웹사이트를 위한 웹 프레임워크"라니, 그럼 콘텐츠가 아니라 난수 생성기(random-number generators)로 구동되는 사이트도 있나?
  • Astro 정말 정말 사랑함, 첫 출시 때부터 써왔음, 내 개인 사이트와 첫 제품의 랜딩 페이지 모두 Astro로 만들었음, 빌드 속도가 빠르고, JS 없이도 배포할 수 있고, 어떤 프론트엔드 라이브러리든 쓸 수 있음, 그래서 내가 생각하는 최고의 프레임워크임
답변달기