스펙 주도 UI 컴포넌트 개발
1. 스펙은 디자인 의도를 연결하는 중심 허브입니다
- 스펙은 Figma, 프로토타입, 코드 라이브러리, 문서 사이에서 디자인 의도를 동기화하는 기준점입니다
- 단순 설명 문서가 아니라 컴포넌트의 구조, 규칙, 예외, 구현 계약을 함께 담는 중간 언어에 가깝습니다
- 디자인 시스템이 커질수록 “어디에 진짜 기준이 있는가”를 명확히 해주는 역할을 합니다
2. 스펙은 자동 생성과 작성형으로 나뉩니다
- 모든 컴포넌트 정보를 Figma나 코드에서 자동으로 뽑아낼 수는 없습니다
- 자동 생성 스펙(Generated Spec): Figma 등에서 추출되는 API, Variant, 스타일, 토큰, 레이아웃 규칙, 예시 정보를 담습니다
- 작성형 스펙(Authored Spec): 접근성, 복잡한 동작, 상호작용, 예외 처리처럼 사람이 맥락을 해석해 Markdown으로 보완해야 하는 내용을 담습니다
- 두 스펙이 함께 있어야 AI 에이전트나 개발자가 컴포넌트를 더 정확히 이해할 수 있습니다
3. 핵심은 다방향 전환 아키텍처입니다
- 디자인 의도는 Figma, 웹 프로토타입, 코드 어디에서든 시작될 수 있으므로 스펙은 여러 방향으로 오갈 수 있어야 합니다
- Figma → Specs: 플러그인, REST API, CLI, GitHub Action 등을 통해 컴포넌트 구조와 속성을 스펙 데이터로 추출합니다
- Specs → Figma: 스펙 데이터를 바탕으로 Figma 컴포넌트와 에셋을 결정론적으로 복원합니다
- Specs → Prototypes: React 스캐폴드, CSS, TypeScript 계약, Storybook 등을 생성해 빠르게 검증 가능한 프로토타입으로 연결합니다
- Prototypes → Specs: 프로토타입 구현 중 생긴 결정과 예외를 다시 스펙으로 끌어올려 기준을 갱신합니다
4. 운영의 핵심은 버전 관리와 순환 구조입니다
- 스펙이 실제 시스템의 중심이 되려면 변경과 피드백을 관리하는 방식도 함께 필요합니다
- Breaking, Minor, Patch 같은 변경 단위를 구분해 팀이 영향도를 이해할 수 있게 합니다
- ADR을 활용해 아키텍처 결정과 합의 과정을 기록합니다
- 토큰 사용, 속성 모델, 컴포넌트 의존성 같은 정보를 분석해 시스템 상태를 모니터링합니다
- 개발자가 발견한 접근성, 동작, 플랫폼별 예외가 다시 상류 스펙으로 반영되는 선순환이 중요합니다
