4개 서비스 테마를 단일 토큰 코어로
묶은 디자인 시스템
DS가 있어도 테마가 늘 때마다 다시 만들어야 한다면, 그 DS는 비용을 줄이지 못합니다.
재사용이 목적인 DS가 오히려 작업을 늘리던 구조를, 테마가 늘어도 인력이 늘지 않는 구조로 바꿨습니다.
디자이너 1명이 처리
컴포넌트 수정량
IDAS · IDSS · Chatbot · Admin
구조는 도메인 이해에서
출발해야 합니다
DS 구조를 잘못 잡는 가장 흔한 원인은
범용성을 먼저 추구하는 것입니다.
dealer365는 차량 접수·정비·고객 응대·정산이 한 화면 안에서 동시에 도는 딜러십 전용 B2B SaaS입니다. 세 번의 구조 재설계 끝에, 딜러십 업무 흐름을 구조의 전제로 두었습니다. 도메인 특수 패턴 8개를 도출하고 범용 패턴은 shadcn/ui로 흡수했습니다.
비즈니스 로직을 이해하지 못한 채 화면만 그리는 설계는
확장 시점에 반드시 무너집니다.
변경 범위를 예측할 수 없으면
DS를 믿고 쓸 수 없습니다
토큰을 바꿀 때 영향 범위를 알 수 없으면,
그 DS는 건드리기 무서운 시스템이 됩니다.
Primitive → Semantic → Mode 3단계 구조. border만 바꾸고 싶을 때 border만 건드립니다. Dark/Light 전환, RTL/LTR, Density 3단계를 컴포넌트를 건드리지 않고 토큰 구조만으로 대응했습니다.
Semantic Token 120개로
4개 테마 전체를 단일 관리합니다.
속성을 닫을수록
개발자는 DS 밖으로 나갑니다
DS를 만드는 것과 실제로 쓰이게 만드는 것은 다릅니다.
디자인 일관성에 직결되는 색상·타이포·간격은 닫았습니다. disabled, loading 같은 인터랙션 상태와 children, slots처럼 화면마다 다르게 채워지는 구조는 열었습니다.
판단 기준은 하나였습니다. 이 속성을 닫으면 개발자가 DS 컴포넌트를 포기하고 직접 만들 이유가 생기는가.
쓰이는지 측정하지 않으면
거버넌스가 아닙니다
채택률을 측정하지 않으면 DS가 살아 있는지
형식만 남았는지 알 수 없습니다.
GitLab MCP 기반 import 분석, Storybook 접속 로그로 측정 체계를 구축했습니다. 채택률이 떨어지는 컴포넌트가 보이면 속성 설계로 돌아갔습니다. 개발자가 그 컴포넌트를 피하는 이유가 있다는 신호이기 때문입니다.
Wrapped 컴포넌트가 팀 요청의
80% 이상을 소화했습니다.
네 개의 판단이
하나의 결과로 모입니다
도메인을 전제로 구조를 잡았고, 변경 범위를 제어 가능하게 만들었고, 개발자가 우회하지 않도록 속성을 설계했고, 쓰이는지 측정했습니다. 네 판단이 분리된 작업이 아니라 하나의 시스템으로 연결됩니다.
테마가 늘어도 인력이 늘지 않는 구조.
DS가 비용을 줄이는 방식으로 작동하게 만들었습니다.
Figma에서 코드까지,
사람이 옮겨 적는 단계를 없앤 파이프라인
디자인과 개발 사이 오차는 명세서를 더 꼼꼼하게 써도 사라지지 않습니다.
옮겨 적는 단계 자체를 없애야 사라집니다. Figma 구조가 그대로 코드가 되도록 설계했습니다.
화면 코드
검증 루프
오차는 명세서가 아니라
옮겨 적는 구조에서 생깁니다
검수 보고서에 같은 지적이 반복된다면,
그건 명세서를 못 써서가 아닙니다.
디자인을 명세서로, 명세서를 코드로—두 번의 변환 단계가 오차를 만듭니다. 디자인 토큰 구조와 1:1 호환되는 shadcn/ui로 베이스를 통일하고, Figma 구조가 그대로 코드가 되는 길을 열었습니다.
핸드오프 방식의 문제가 아닌,
디자인과 개발의 출발점이 어긋난 구조의 문제였습니다.
레이어 이름이 코드가 되면
AI가 추론할 필요가 없습니다
AI가 구조를 추론하면 같은 화면을 읽어도
실행마다 다른 코드가 나옵니다.
Group 12, Rectangle 3 같은 자동 생성 이름을 Card, CardHeader, CardTitle처럼 실제 코드 컴포넌트 이름과 1:1로 맞췄습니다. 초기 구축 시간의 45%가 들어갔지만, 파이프라인 전체가 이 구조 위에서만 작동합니다.
파이프라인이 못 담는
디자인 영역을 직접 설계했습니다
AI는 UI 구조와 토큰은 코드로 옮기지만,
디자인 판단이 필요한 지점까지 대신하지 못합니다.
design-to-ui 에이전트를 직접 설계해 5단계 파이프라인에 끼워넣었습니다. 인터랙션은 ProtoPie로 구현 후 cubic-bezier와 ms 단위로 명세화해 "부드럽게"라는 해석의 여지를 없앴습니다.
개발 영역을 가져온 게 아닙니다. 자동화가 닿지 못하는 지점을 설계해 전체 품질을 책임지는 협업 모델입니다.
같은 AI에게 생성과 검증을
함께 시키면 안 됩니다
자기 출력을 맞다고 유지하려는 경향이 생깁니다.
생성과 검증은 반드시 분리되어야 합니다.
Generator와 Reviewer를 독립 세션으로 분리했습니다. 검증 기준을 토큰값 일치 · DOM 계층 대응 · 간격 수치 · 속성 매핑 4항목으로 명세화해, 막연한 "맞는지 봐줘"가 아닌 비교 항목을 고정했습니다.
검증 루프 3~4회 → 1~2회.
재작업 반복이 줄었습니다.
서비스가 커져도
전달 인력이 늘지 않는 구조
오차 구조를 진단하고, 입력을 정리해 추론을 없앴고, 자동화가 닿지 못하는 디자인 지점을 직접 설계했고, 생성과 검증을 분리해 품질을 안정시켰습니다.
프로젝트마다 개발팀이 바뀌는 SI 환경에서, 전달을 구조로 만들어두면 팀이 바뀌어도 동일하게 작동합니다.
사람에 의존하던 전달을
시스템으로 옮긴 것입니다.
3개 브랜드 220개 화면을
디자이너 1인이 운영한 디자인 시스템
공통 컴포넌트는 이미 있었습니다. 그런데도 수정 하나가 220개 화면을 찾아다니는 작업이 됐습니다. 컴포넌트의 문제가 아니라 운영 구조의 문제였습니다. 이미 망가진 시스템을 인수해, 수정이 한 번에 끝나는 구조로 바꿨습니다.
디자이너 1인 운영
화면 찾아다니던 작업 소멸
운영 환경
Detach를 없애는 게 아니라
Detach할 이유를 없앱니다
공통 컴포넌트가 있어도 Detach가 쌓이면
수정 비용이 화면 수에 비례합니다.
Detach가 생기는 이유를 분석했습니다. 패턴화 우선순위는 영향 범위로 정했습니다. Header를 패턴화하자 전체 220개 화면이 DS 단위 1회 수정 체계 안으로 들어왔습니다.
화면이 늘어도 수정 비용이
비례해 늘지 않는 구조를 만들었습니다.
정책이 확정된 뒤
반영하면 늦습니다
정책이 결정된 뒤 디자인으로 받으면 컴포넌트를
새로 만들거나 예외 처리를 반복하게 됩니다.
수행사 디자이너였지만 브랜드별 정책 결정 회의에 직접 참석했습니다. 현대 OTP / 기아 PIC 같은 정책 차이를 컴포넌트를 새로 만들지 않고 Props 분기로 처리했습니다. 브랜드가 추가되어도 DS 코어는 하나로 유지됩니다.
기준이 없으면
누락도 셀 수 없습니다
파일 구조에 기준이 없으면
같은 화면을 직군마다 다르게 셉니다.
기획팀 누락 41개, 직접 식별 50개. 세는 기준이 달랐기 때문입니다. WBS · Figma 화면 ID · 퍼블리싱 3자 교차 확인 기준을 수립하고, 파일 구조 가이드를 작성해 팀 전체에 배포했습니다.
기준이 제 머릿속에만 있으면 제가 빠지는 순간 구조도 사라집니다.
문서로 배포해야 제가 없어도 구조가 돌아갑니다.
수정 비용이
화면 수에 비례하지 않는 구조
Detach가 생기는 이유를 구조에서 없앴고, 브랜드 정책 차이를 결정 과정에서부터 Props로 처리했고, 운영 기준을 문서화해 팀에 넘겼습니다.
인수받은 시스템을 한 사람에게 의존하지 않는 구조로 바꿨습니다.
이미 망가진 글로벌 DS를 인수해,
제가 빠져도 돌아가는 구조로 바꿨습니다.