은전 한 닢 - LLM으로 디자인시스템 만들기 part 2
생각난 김에 시작해볼까.
한 번 "쓰읍"을 외친 이상, 돌아가기는 어렵다.
일단 키보드 앞에 앉아서, 내 원래 의도와 지금 상황에 대한 생각, 결정 필요한 것들, 결정한 것들 을 쭈우우우욱 적었다. 그 때 넣었던 프롬프트를 다행히; 저장해둔 md가 살아있어서 그대로 옮겨본다.
이 프로젝트는 개인 사용 목적으로 shadcn ui에 기반한 코드형태의 디자인 시스템을 만들고, storybook으로 형태를 시각화/preview하고, figma에서 활용할 수 있도록 figma에 library를 구축하는 것 까지를 목표로 했고, 지금까지 작업해 왔어. 지금은 어느 정도 형태가 갖춰진 상태라고 판단되지만, shadcn을 무비판적으로 옮기다보니 정작 어떤 구조로 어떻게 구성해야 할 지 생각하지 않았던게 더 드러나는것 같아. 지금의 massive-design 상태를 기준으로, 몇 가지 외부의 다른 디자인 시스템 사례들을 보면서 아래와 같이 목표/목적지를 바꿔보고 싶다는 생각이 들었어.
- Code가 정본. 여기에 추가로 프리뷰 목적의 별도의 설명문서 site 구축(스토리북을 그대로 쓸지, 다른 형태로 할지도 논의 필요).
- Figma는 모든 작업이 마무리 된 뒤 판단. (진행할지, 안 할지)
- 시작하는 기반은 Base UI를 선택하고 싶어.
- 디자인시스템의 구성부터 다시 고민해보고 싶은데, 아래의 사이트들을 바탕으로 최적안을 도출해보고 싶어. 한 번에 모든 컴퍼넌트를 만드는건 무리라고 생각되고, 필요한 구성을 먼저 만들고, phase를 나누어 채워나가는 식으로 진행하는게 좋겠어.
여기까지 생각에 대해 의견을 듣고 싶어. 이 프로젝트를 기반으로 하고 점진적으로 변화시켜나가는 방향이 좋을지, 새로 프로젝트를 시작하는 편이 좋을지도 의견 부탁해.
스킬은 아마도(높은 확률로) /grill-with-docs 를 썼던 걸로 기억하고, 요구사항과 내가 원하는 것이 무엇인지 확실한 상태여서 /wayfinder 쓸 필요 없이 바로 /to-spec 으로 넘길 수 있었다.
두 번째 시작하면서
아래는 'LLM이 쓴게 확실한' 문장들이라 보기 좀 거시기하겠지만, 저 map 하나 쓰기 위해서 질문 몇개를 답했는지 대충 감이 오실거라 본다. 정말 큰거/중요한거 외에 기술적인 디테일은 맡기긴 했다만...
사실 첫 생각은 '갈아엎고 새로 시작'이었는데, LLM의 추천은 '그래도 기존 플젝에서 이어갈만한 것도 있고, 틀은 유지하는게 좋지 않겠냐'라는 거였다. 그래서 2세대라는 개념으로.
덧붙여서, 이전까지는 적용할 프로젝트를 그냥 넘겼었는데, 실제 개인프로젝트에 적용하기로 결정했다.
위 이슈에서 내린 주요 결정들
- 세대 전환은 삭제로 시작한다. v1-shadcn 태그를 찍고 1세대 컴포넌트·매니페스트 생성기·계약 검증·parts 커버리지·sync:checklist·Figma digest·카탈로그 verify·alias/shadcn.json·verification/의 Figma 기준선 소비 코드를 지운다. git 히스토리가 보존한다.
- primitive 기반은 Base UI 하나다. 접근성 동작·키보드·포커스는 Base UI에 맡기고 DS는 스타일과 조립만 진다. Tabs는 자동 활성화로 기본값을 감싼다. 독립 Label은 없고 Field.Label이다.
- API는 네임스페이스형이다. 한 컴포넌트는 하나의 서브패스에서 하나의 이름으로 나가고 파트는 그 아래에 산다. 프리셋은 Phase 1에 없다.
- 스타일은 Tailwind v4 + cva다. 상태는 Base UI의 data-* 속성 셀렉터로 그린다. 상태 레이어 사다리(state layer)는 셀렉터만 바꿔 살린다. 히트 영역 24px은 재사용 클래스 하나다.
- 토큰은 semantic 이름을 직접 소비한다. alias 층이 없으므로 컴포넌트 클래스는 bg-neutral-soft류의 semantic 유틸리티만 쓴다. 램프 생성기는 @massive/tokens의 공개 API가 되어 소비처가 자기 패밀리를 만든다.
- 패키지는 둘이고 빌드가 생긴다. @massive/ui는 서브패스 export와 타입 선언을 내고 sideEffects를 CSS로 한정한다. @massive/tokens는 CSS와 타입, 램프 API를 낸다. 대상은 GitHub Packages, 첫 버전 0.1.0. 아이콘은 lucide-react peer.
- meta가 계약의 후계다. 컴포넌트당 category·status·since뿐이며 Storybook 사이드바 순서와 상태 표만 읽는다.
- 문서는 Storybook 안이다. MDX 문서 페이지 + 분류 사이드바 + 매니저 테마. 별도 사이트는 Phase 2 말 재판단.
- 손익 색은 앱 소유다. DS는 패밀리를 더하지 않는다. warning·info는 Phase 2.
- 이행은 소비처에서 화면 단위로 한다. 앱의 components/ui/가 비는 것이 완료 조건이고, 앱의 수동 복사 규약은 npm 의존으로 개정한다.
Batch Process / 자동화
맵을 한 번 열면 적게는 6~8개, 많으면 위 예시처럼 20개 가까운 이슈가 열린다. 사람이 보고 처리해야 하는 ready-for-human 라벨붙은 이슈들 말고, ready-for-agent는 그냥 배치로 돌려버리는게 (특히 잠들기 전에) 여러모로 좋다. 이 생각을 나만 한 건 아닌 거 같다. 비슷한 논의를 유튜브에서도 가끔 듣곤 한다.
내가 쓰는 프롬프트 예시는 이렇다. 나름 여러번의 시행착오를 거쳐서 지금 정착한 것. 중요한건 이걸 돌리는 주체/메인 thread의 모델은 Fable이나 Opus를 사용하고, subagent는 sonnet을 쓴다는 거. 자다가 interrupt 걸려도 방법이 없기 때문에 "나 대신 적절한 판단을 해 달라"는 것도 들어가 있다.
지금 레포에 열려있는 000번 map에 딸려있는 이슈들을 순차적으로(가능한경우 병렬로) 처리해줘. 개별이슈는 subagent를 불러서 실행해줘. subagent는 sonnet을 사용하고, 내가 꼭 확인해야 하는 결정포인트가 아니라면, 나 대신 적절한 판단을 내려줘. 개별이슈 해결할때는 /implement 스킬을 사용해주고, 테스트를 수행할때는 백그라운드 대신 포어그라운드에서 실행하도록 지침을 줘. 가능한 경우 grep대신 graft를 사용해. 이렇게 진행하기 전에 결정이 필요한 질문이 있다면 해줘.
아 그래서 결과는요?
그게 결과는 (아직까지는) 꽤 마음에 든다.
개인적으로 만들어서 돌리던 투자일지 플젝에도 적용했는데, 무리없이 적용되었고, 눈에 띄는 큰 이슈들은 몇 번 수정 거쳐서 어느정도는 안정화 된 것 같다. 지금은 두번째 플젝까지 migration 완료된 상태.
막상 다 만들어 놓고 크게 걸렸던건 문서에 사용된 표현들, 특히 정말 대놓고 '아 이건 LLM이 썼어요'라고 외치는 문장들의 어투를 자연스럽게 바꾸는 작업이었다. 비주얼을 어떻게 바꾼다거나 다듬는것 보다 이걸 하고 나서 만족도가 훨씬 크게 높아졌다.
하면서 느낀 것, 앞으로의 계획
원래의 목표인 "개인플젝 할 때 고민하지 않고 적용할 수 있는 틀, 기반"이라는 목표는 달성한 것 같다.
무슨 프로젝트든 일단 이걸로 시작하고, 디자인시스템 rule 상 필요한 요소가 생기면 그 때 추가하면 되는거라 내 작업이랑 같이 커나가는(?) 디자인시스템이 될 것 같다.
1단계 하면서 토큰날리고 시간 쓴것 때문에 너무 데어서 그런지 아직 Figma Library형태로 포팅하지는 않았다. 정말 "이정도면 이제 됐다" 싶을때까지는 안하고 버틸려는 심산.
(사실 개인 플젝은 이제 figma로 뭘 테스트하는 경우는 거의 없고.. 차라리 손그림/스케치 -> LLM -> Wireframe -> Variation 의 흐름으로 작업한다.)
그리고 스토리북 말고 별도의 Design System문서를 만드려는 계획이었는데 이것도 정말 "더 할게 생각 안난다" 상태까지는 미뤄두기로.
하면서 많은 삽질을 했지만, 그 과정에서 많이 배웠다고 느겼다.
꼭 디자이너가 아니더라도, 개인프로젝트에 뜻이 있는 분이라면 한 번 해볼만한 작업이니 추천.