요즘 UI 작업을 할 때마다 묘하게 막힌다. 백엔드 개발을 오래 하다 보니 데이터 흐름, API, 인증, 배치, 장애 대응 같은 건 어느 정도 익숙한데, 화면을 예쁘고 일관되게 만드는 일은 여전히 어렵다. 특히 회사 솔루션은 Angular 기반이라 더 그렇다. React 쪽 생태계에서는 재미있는 UI 도구들이 계속 나오는데, 막상 회사 프로젝트에 바로 가져다 쓰기는 쉽지 않다.
그런 흐름에서 Meta의 Astryx를 봤다. 공식 설명은 “완전히 커스터마이징 가능하고 agent-ready인 오픈소스 디자인 시스템”이다. GitHub 저장소도 facebook/astryx로 공개되어 있고, 2026년 7월 기준 별이 6천 개 정도 붙어 있었다. npm 패키지도 @astryxdesign/core, @astryxdesign/cli, @astryxdesign/theme-neutral 형태로 올라와 있다.
Astryx는 무엇을 노리는 도구일까
Astryx는 단순히 버튼과 카드 몇 개를 복사해서 쓰는 UI 모음이라기보다, AI 코딩 도구가 UI를 덜 틀리게 만들도록 돕는 디자인 시스템에 가깝다. 공식 문서의 Working with AI 섹션도 꽤 노골적이다. AI 모델이 일반적인 React 패턴으로 대충 만들거나 없는 prop을 지어내지 않도록, CLI가 컴포넌트 인덱스와 규칙, 문서 컨텍스트를 생성해준다는 방향이다.
설치 흐름도 그쪽에 맞춰져 있다.
npm install @astryxdesign/core @astryxdesign/theme-neutral @astryxdesign/cli
npx astryx init --features agents즉, 사람이 문서를 보고 하나씩 조립하는 도구라기보다, 사람과 AI 에이전트가 같은 설계 규칙을 보며 UI를 만들게 하려는 느낌이 강하다.
shadcn/ui와는 무엇이 다를까
shadcn/ui는 이미 많은 개발자가 알고 있다. 공식 문서에서도 “component library가 아니라, 너의 component library를 만드는 방식”이라고 설명한다. 패키지를 설치해서 import하는 전통적인 UI 라이브러리라기보다, 필요한 컴포넌트 코드를 프로젝트 안으로 가져와서 직접 소유하고 수정하는 방식이다.
반면 Astryx는 @astryxdesign/core라는 컴포넌트 패키지를 설치해서 쓰는 쪽에 더 가깝다. 여기에 design token, theme, StyleX, Tailwind bridge, CLI, agent docs가 함께 붙는다.
| 구분 | Astryx | shadcn/ui |
|---|---|---|
| 성격 | Meta가 공개한 React 디자인 시스템 | 복사/소유 방식의 UI 컴포넌트 배포 플랫폼 |
| 사용 방식 | @astryxdesign/core 설치 후 import |
CLI로 컴포넌트 코드를 프로젝트에 추가 |
| AI 대응 | agent docs, JSON API, CLI 컨텍스트 생성 강조 | MCP, registry, v0 등 AI 친화 흐름이 강함 |
| 커스터마이징 | token/theme/StyleX/Tailwind/className 조합 | 코드 소유 후 직접 수정 |
| 철학 | 일관된 디자인 시스템과 에이전트 친화성 | 오픈 코드, 복사해서 내 컴포넌트로 관리 |
| 현재 아쉬움 | React 중심. Angular 직접 지원은 보이지 않음 | Angular 지원 없음. 주로 React 생태계 중심 |
Astryx의 장점
백엔드 개발자 입장에서 Astryx의 가장 큰 장점은 “AI에게 줄 맥락”을 도구가 의식하고 있다는 점이다. 요즘 AI에게 화면을 만들어달라고 하면 그럴듯한 JSX는 나오지만, 실제 디자인 시스템 규칙과 맞지 않거나 없는 컴포넌트/속성을 만들어내는 경우가 있다. Astryx는 이 문제를 정면으로 보고 있는 것 같다.
또 하나는 컴포넌트 수와 범위다. 버튼, 카드, 폼, 메뉴 같은 기본 컴포넌트뿐 아니라 Chat 관련 컴포넌트, App Shell, template, theme, token 문서까지 묶여 있다. 단순 랜딩 페이지보다 관리 화면, AI 채팅 UI, 설정 화면 같은 쪽에 더 관심이 간다.
단점과 조심할 점
반대로 단점도 분명하다. 우선 아직 Beta 성격이 강하다. GitHub 이슈도 꽤 있고, npm 버전도 빠르게 움직이고 있다. 회사 솔루션에 넣기에는 API 안정성, 장기 유지보수, 디자인 정책을 더 지켜봐야 한다.
특히 실제 사용자 피드백을 보면 “좋아 보인다”에서 바로 끝나지는 않는다. GitHub 이슈 중에는 기존 React + Vite + Tailwind/shadcn 스타일 대시보드를 Astryx, 당시 XDS 계열로 점진 마이그레이션하려던 기록이 있었다. 나도 React 프로젝트를 바꿔보는 입장이라 이 부분이 더 눈에 들어왔다.
그 기록에서는 @xds/* 시절 네이밍과 공개 패키지인 @astryxdesign/*로 넘어가는 과정의 흔적이 보였다. 패키지 설치, Git 기반 의존성, CLI 실행, workspace 패키지 참조 같은 부분에서 초반 통합 비용이 꽤 있었다. 이후 댓글에서는 실제로 XDSTheme, XDSLinkProvider, XDSAppShell, XDSTopNav, XDSSideNav 같은 요소를 붙이며 마이그레이션을 진행한 기록도 있었다.
이건 Astryx가 나쁘다는 뜻이라기보다, 기존 React 프로젝트에 점진적으로 넣는 것도 마냥 간단한 일은 아니라는 뜻에 가깝다. 새 프로젝트에서 정해진 방식대로 시작하면 훨씬 깔끔하겠지만, 이미 Tailwind나 shadcn/ui 스타일로 만들어진 화면이 있다면 통합 비용을 먼저 생각해야 한다.
그리고 React 중심이라는 점이 가장 크다. 공식 예제도 Next.js, Vite, StyleX, Tailwind 흐름이다. Angular 기반 회사 솔루션에서는 바로 적용하기 어렵다. 디자인 토큰이나 화면 구성 아이디어는 참고할 수 있지만, 컴포넌트를 그대로 가져다 쓰기는 힘들어 보인다.
내가 아쉬운 지점
솔직히 가장 아쉬운 건 Angular다. 회사 솔루션이 Angular 기반이라, 이런 도구를 보고도 “좋네, 바로 써보자”가 안 된다. 게다가 React 프로젝트에서도 기존 앱을 바꾸는 과정에서는 네이밍 전환, 패키징, CLI, 테마 래퍼 적용 같은 마찰이 있었다. Angular라면 그 벽은 더 높아질 수밖에 없다.
백엔드 개발자인 내 입장에서는 UI의 세부 구현보다 일관된 화면 구조와 컴포넌트 선택이 더 어렵다. 그래서 Astryx 같은 도구가 Angular까지 지원했다면 꽤 반가웠을 것 같다. 최소한 Angular용 컴포넌트가 아니더라도, AI가 참고할 수 있는 디자인 토큰과 화면 설계 규칙을 Angular 프로젝트에 쉽게 이식하는 방법이 있으면 좋겠다.
그래도 방향은 흥미롭다. 이제 UI 도구는 단순히 예쁜 컴포넌트를 제공하는 수준을 넘어, AI 에이전트가 어떤 규칙으로 화면을 만들어야 하는지까지 제공하는 쪽으로 가고 있다. shadcn/ui가 “코드를 내 프로젝트에 가져와 소유한다”는 흐름을 만들었다면, Astryx는 “디자인 시스템을 AI가 이해하게 만든다”는 쪽에 더 가까워 보인다.
결론
당장 회사 Angular 솔루션에 Astryx를 적용하기는 어렵다. 그 점은 꽤 아쉽다. 하지만 백엔드 개발자로서 UI에 막힐 때, 앞으로 어떤 도구가 도움이 될지 보는 관점에서는 꽤 의미 있는 신호였다.
내가 원하는 건 화려한 UI 빌더가 아니라, “이런 화면에서는 이 컴포넌트를 쓰고, 이런 규칙으로 배치하면 된다”는 기준이다. Astryx는 그 기준을 사람뿐 아니라 AI에게도 전달하려는 시도처럼 보인다.
그래서 지금은 실무 적용 도구라기보다, React 기반 새 프로젝트나 AI UI 생성 흐름을 볼 때 참고할 만한 디자인 시스템으로 기억해두려 한다. Angular 쪽에서도 이런 흐름이 조금 더 강해지면 좋겠다. 백엔드 개발자도 UI 앞에서 덜 헤매고 싶으니까.