Cursor나 Claude Code에 "그 버튼, 느낌 있게 만들어줘"라고 부탁하면, 가끔 <Button variant="primary" size="lg">와 같은 코드가 돌아온다. 실제로 실행해보고 나서야 깨닫는다. 그 컴포넌트에는 variant 같은 prop이 존재하지 않는다. AI가 그럴듯한 API를 지어내고 있었던 것이다.

이는 능력 부족이라기보다 구조적인 문제다. LLM은 당신의 디자인 시스템 내부를 알지 못한다. 학습 데이터에 포함된 무수한 UI 라이브러리의 평균적인 모습으로부터 "아마 이런 prop이 있을 것이다"라고 보간(interpolation)한다. 사내 독자적인 컴포넌트일수록 이러한 환각 (hallucination)이 일어나기 쉽다. 매번 문서를 컨텍스트 (context)에 붙여넣으면 줄어들겠지만, 인간이 그것을 계속 수행하는 것은 현실적이지 않다.

Meta가 6월에 MIT 라이선스로 공개하고, 7월 16일에 다시 GitHub 트렌드에 오른 astryx는 이 문제에 정면으로 대응한 React 디자인 시스템이다. 셀링 포인트는 150개 이상의 접근 가능한 컴포넌트나 7종의 테마가 아니다. 설계의 출발점이 "인간과 에이전트(agent) 모두가 읽을 수 있는 것"에 놓여 있다는 점에 있다. 공식 문서의 표현을 빌리자면 다음과 같다.

built for how we build now: by people and the agents working alongside them.

보통의 디자인 시스템은 문서를 인간을 위한 웹사이트로 공개한다. AI에게 그것을 읽히고 싶다면 개발자가 페이지를 복사하여 붙여넣거나 스크레이핑 (scraping)에 의존해야 한다. astryx는 이 부분을 역전시켜, 에이전트가 직접 쿼리 (query)할 수 있는 경로를 처음부터 마련했다.

중심에 있는 것은 MCP (Model Context Protocol, AI 도구가 외부 데이터 소스에 연결하기 위한 공통 규격) 서버다. Meta가 호스트하는 엔드포인트 (endpoint)를 설정 파일에 하나 적는 것만으로, Claude Desktop에서도 Cursor에서도 Windsurf에서도 동일한 통로를 통해 디자인 시스템을 불러올 수 있다.

{
"mcpServers": {
"xds": {
...

이 서버가 공개하는 도구는 단 두 가지뿐이라는 점이 깔끔하다. 자연어로 컴포넌트나 템플릿을 찾는 search(query)와, 이름을 전달하여 prop, 사용법, 코드 예시가 포함된 완전한 문서를 가져오는 get(name)이다. 에이전트는 "Dialog의 prop은 무엇인가"를 추측하지 않고, 그 자리에서 정답을 가져올 수 있다. 환각을 사후에 검출하는 것이 아니라, 애초에 추측하게 만들지 않는 접근 방식이다.

MCP를 사용하지 않거나 사용할 수 없는 도구를 위한 길도 막아두지 않았다. CLI에는 --dense라는 플래그가 있으며, 공식 문서에 따르면 "AI의 컨텍스트 윈도우 (context window)를 위해 토큰 효율화된 형식"으로 문서를 출력한다. ChatGPT나 Claude의 채팅창에 붙여넣는 것을 전제로 한 출력이다.

astryx component --list
astryx component Dialog --dense
astryx docs styling --dense

도입 자체는 일반적인 npm 패키지와 다르지 않다. core와 theme, CLI를 설치하여 초기화한다.

npm install @astryxdesign/core @astryxdesign/theme-neutral @astryxdesign/cli
npx astryx init

npx astryx init은 프롬프트를 출력하지 않는 비대화형 명령어로 만들어져 있다. 문서는 "no prompts — so it's safe for AI agents, CI, and scripts"라고 명시하고 있어, 에이전트에게 init을 맡겨도 대화 대기 상태로 멈추지 않는다. 에이전트가 실행해도 막히지 않도록 곳곳에 배려가 녹아 있는 점이, 사후에 AI를 대응시킨 것과의 차이점이다.

컴포넌트는 카테고리별 서브 패스 (sub-path)에서 import 한다.

import {Button} from '@astryxdesign/core/Button';
import {VStack} from '@astryxdesign/core/Layout';
export default function Page() {
...

또 하나 실무에서 유용한 것은 도구별 규칙 파일을 생성하는 명령이다. 에이전트용 규약을 각 도구가 기대하는 위치와 포맷으로 작성해 준다.

npx @astryxdesign/cli init --features agents --agent claude # .claude/CLAUDE.md
npx @astryxdesign/cli init --features agents --agent cursor # .cursorrules
npx @astryxdesign/cli init --features agents --agent codex # AGENTS.md

보시는 바와 같이, 출력 위치가 모두 다릅니다.

・CLAUDE.md

・.cursorrules

・AGENTS.md

에이전트용 규약을 어디에 어떻게 배치할지에 대한 표준은 아직 난립하고 있으며, astryx는 하나에 도박을 거는 대신 전부 생성하는 쪽을 택했습니다. 이러한 결단은 현 상황을 솔직하게 반영합니다.

구조화된 컴포넌트 문서(Component Documentation) 자체는 새로운 것이 아닙니다. Storybook의 docs도 prop의 타입을 가지고 있습니다. 차이점은 문서를 '사람이 보는 결과물'이 아니라 '에이전트가 호출하는 API'로서 설계하고 배포했다는 점에 있습니다. 백엔드에서 10년 전에 OpenAPI를 통해 했던 일(구현과는 별개로, 기계가 읽을 수 있는 계약(Contract)을 먼저 정의하고, 이를 통해 사람과 기계 모두를 위한 것을 생성하는 방식)을 프론트엔드 디자인 시스템에 도입했다고 이해하는 것이 가장 적절합니다. 실제로 MarkTechPost는 동봉된 JSON 매니페스트(Manifest)를 OpenAPI 사양에 비유하여 보도했습니다.

astryx는 React 19 이상을 전제로 하며, Meta의 컴파일 타임 CSS 엔진인 StyleX 위에 구축되어 있습니다. 보도된 수치에 따르면, 사내에서 8년에 걸쳐 1만 3천 개 이상의 앱을 통해 검증되었다고 합니다. 즉, 공개된 것은 실험적인 프로토타입이 아니라 실운용의 축적을 가진 내부 시스템입니다.

과도한 기대는 금물입니다. MCP를 통해 올바른 prop을 가져온다 하더라도, 에이전트가 그것을 올바르게 사용할 것이라는 보장은 없습니다. 가져온 문서를 무시하고 환각(Hallucination)을 일으킬 여지는 남아 있습니다. astryx가 한 일은 환각을 제로로 만드는 것이 아니라, 정답에 대한 액세스 비용(Access Cost)을 추측보다 낮게 만들어 '굳이 틀릴 이유'를 줄인 것입니다.

도입 판단의 재료로서 현실적인 점은, 이것이 Meta 내부 XDS(eXtended Design System)의 사상이 그대로 드러난 결과물이라는 점일 것입니다. 컴포넌트 설계 사상도 테마 체계(neutral, butter, chocolate, gothic, matcha, stone, y2k)도 Meta의 방식이며, 기존 프로덕트에 부분적으로 도입하기에는 적합하지 않습니다. StyleX를 전제로 한다는 점 또한 스택에 따라 마찰을 일으킬 수 있습니다. 그럼에도 불구하고 AI가 코드를 작성하는 비율이 계속해서 늘어난다면, '에이전트가 읽을 수 있음'을 라이브러리의 1급 요구사항으로 삼는 발상은 astryx만의 이야기로 끝나지 않을 것입니다. 직접 만든 컴포넌트 군에 MCP 인터페이스와 규칙 파일 생성을 추가하는 것만으로도, 사내에서 AI가 작성하는 UI의 사고는 상당히 줄어들 것입니다. Meta가 오픈 소스로 그 템플릿을 보여준 의미는 결코 작지 않습니다.

1차 소스는 다음과 같습니다.