원문: https://github.com/facebook/astryx/wiki/Swizzle-Ergonomics · 번역 기준: 2026-09-03
Status: 아직 구현되지 않음. 이것은 미래의 swizzle 시스템을 위한 디자인 탐구입니다. 여기서 기술하는 dual-path 아키텍처(theme extension + functional override)와 Tailwind 포맷 옵션은 미래 지향적 디자인이며, 현재 기능이 아닙니다.
Exploration — 2026년 1월
Swizzle 레이어에는 경쟁하는 긴장이 있습니다:
| 질문 | 답 | 시사점 |
|---|---|---|
| Core로의 기여(contribution back)가 중요한가? | 그렇다, 그러나 builder를 unblock하는 것이 더 중요하다 | Builder ergonomics를 먼저 최적화 |
| 무엇이 swizzle되는가? | 대부분의 swizzle 콘텐츠는 use-case 의존적 | 어차피 core로 흘러 돌아오지 않을 것 |
| 작은 조정인가 구조적 변경인가? | 두 진영: DS 팀 (무거운 커스터마이징) + 일반 builder (스타일링보다 기능) | 두 persona 모두를 지원해야 함 |
| AI 지원이 결정적인가? | 그렇다 — builder를 unblock하는 흔한 워크플로우 | AI 친화적이어야 함 |
| Tooling/문서에 투자할 수 있는가? | 당연히 | Gap을 잇는 추상화를 만들 수 있음 |
누구: 회사 디자인 시스템을 유지하는 디자이너/엔지니어
목표: 브랜드 가이드라인에 맞게 컴포넌트 커스터마이징
숙련도: 높음 — StyleX를 배울 의향 있음
Swizzle 사용: 무거운 커스터마이징, 스타일링 중심
필요 예시: