원문: https://github.com/facebook/astryx/wiki/Vibe-Evaluation · 번역 기준: 2026-09-03
Astryx가 대안 대비 얼마나 잘 수행하는지 측정하는 nightly 및 주기적 평가입니다. 이것이 벤치마킹 시스템입니다 — 디자인 시스템이 시간이 지나며 좋아지는지 나빠지는지 알려주는 지속적인 스코어카드입니다.
vibe test로 API 결정을 내리는 것(API 형태 선택, 네이밍 분쟁 해결)에 대해서는 API Arbitration을 참고하세요.
디자인 시스템은 UI 구축을 더 빠르고 일관되게 만들기 위해 존재합니다. AI 지원 시대에는, 시스템이 문서를 읽는 인간뿐 아니라 그 문서로부터 코드를 생성하는 LLM에게도 잘 작동해야 한다는 뜻입니다.
nightly 평가는 이렇게 답합니다: Astryx는 대안보다 측정 가능하게 더 나은가? baseline(shadcn/Tailwind)이 지속적으로 Astryx를 앞선다면 무언가 regress되고 있는 것입니다 — 오래된 문서, 커져 가는 API 복잡성, 혹은 멘탈 모델과 싸우는 컨벤션.
이것은 시스템의 건강 검진이지 설계 도구가 아닙니다. vibe test를 설계 도구로 쓰는 방법은 API Arbitration을 참고하세요.
| Dimension | 측정하는 것 | 중요한 이유 |
|---|---|---|
| Correctness | 유효한 컴포넌트 사용, hallucinate된 prop이나 import 없음 | 기본 중의 기본 — 애초에 동작하는가? |
| Accessibility | 레이블, 시맨틱, 키보드 지원, ARIA 속성 | 디자인 시스템은 a11y를 기본 경로로 만들어야 합니다 |
| Code Quality | 복잡도, 패턴, TypeScript 사용, 가독성 | API가 깔끔한 소비자 코드로 이어지는가? |
| Efficiency | 요소당 결정 수, DRY함, 간결함 | 결정이 적을수록 = 틀릴 기회도 적음 |
| Maintainability | semantic token vs magic value, 다크 모드 지원, 지역성(locality) | 이 코드가 테마 변경에서 살아남을까? |
| Design | 이상적 레퍼런스 이미지 대비 시각적 충실도(레이아웃, 위계, 간격, 컴포넌트 충실도, 색/테마) | 출력이 보기에도 맞는가? 선택 사항 — 이상적 이미지가 존재하고 vision LLM을 쓸 수 있을 때만 채점합니다. |
| 타겟 | 사용하는 것 | 제공되는 문서 |
|---|---|---|
| Astryx | @astryxdesign/core 컴포넌트 + StyleX |
CLI를 통해 소스에서 자동 생성 |
| Baseline | shadcn/ui + Tailwind CSS | .baseline-docs/ |
| HTML | Raw HTML + CSS | 없음 (HTML/CSS 지식만) |
| Astryx + Tailwind | @astryxdesign/core • Tailwind (StyleX 없음) |
.generated/astryx-tailwind-skill.md |