Figma에서 코드까지,
사람이 옮겨 적는 단계를 없앤 파이프라인
디자인과 개발의 출발점이 달라 토큰을 하나하나 수동으로 맞춰야 했고, 페이지 하나에 1주가 걸렸습니다. 명세서를 더 꼼꼼하게 쓰는 게 아니라, 옮겨 적는 단계 자체를 없애야 했습니다.
화면 코드가 되기까지
검증 루프
오차는 명세서가 아니라
출발점이 달랐던 구조에서 생깁니다
검수 보고서에 같은 지적이 반복된다면,
명세서를 못 써서가 아닙니다.
Ant Design과 디자인 토큰 체계가 달랐습니다. 패딩·갭·라운드값·모드 아키텍처가 1:1로 맞지 않았습니다. CSS Variable 기반 shadcn/ui로 바꾸자 globals.css에서 토큰 하나를 바꾸면 전체 컴포넌트에 반영됐습니다. 선택 기준은 기능 수가 아니라 토큰 구조 호환성이었습니다.
핸드오프 방식이 아니라
출발점의 구조적 불일치가 원인이었습니다.
레이어 이름이 코드가 되면
AI는 추론할 필요가 없습니다
추론이 들어가면 같은 파일을 읽어도
실행마다 다른 코드가 나옵니다.
Group 12 · Rectangle 3 같은 자동 생성 이름을 Card · CardHeader · CardTitle처럼 코드가 export하는 이름과 1:1로 맞췄습니다. 초기 구축 시간의 45%가 들어갔지만, 파이프라인 전체가 이 구조 위에서만 작동하기 때문에 피할 수 없는 투자였습니다.
같은 AI에게 생성과 검증을
함께 시키면 오류를 못 찾습니다
같은 AI가 자기 출력을 검증하면
"일치합니다"만 반복합니다.
Generator와 Reviewer를 독립 세션으로 분리했습니다. Reviewer는 토큰값 일치 · DOM 계층 대응 · 간격 수치 · 속성 매핑 네 항목만 검증합니다. 막연히 "맞는지 봐줘"가 아니라 무엇을 비교할지 고정했습니다.
검증 루프가 3~4회에서
1~2회로 줄었습니다.
파이프라인이 닿지 못하는 영역을
디자이너가 채웁니다
easing · duration · delay 같은 값은
Figma 구조에 담기지 않습니다.
ProtoPie로 인터랙션을 먼저 구현하고 흐름을 확인한 뒤 수치로 변환했습니다. 카드 진입 cubic-bezier(.4,0,.2,1) 280ms, 모달 닫힘 scale 0.95 150ms, 버튼 호버 120ms. "부드럽게"가 아니라 수치로 전달해야 의도가 구현 단계에서 사라지지 않습니다.
자동화가 늘수록 디자이너가 할 일이 없어지는 게 아닙니다. 닿지 못하는 지점을 디자이너가 설계해야 전체 품질이 유지됩니다.
서비스가 커져도
전달 인력이 늘지 않는 구조
오차의 원인을 출발점의 구조적 불일치로 진단하고, 입력을 정리해 AI 추론을 없앴고, 생성과 검증을 분리해 품질을 안정시키고, 파이프라인이 닿지 못하는 인터랙션을 수치로 채웠습니다.
디자인과 개발 사이의 전달을
사람이 아니라 구조가 맡게 만들었습니다.
AI가 판단하고, 사람이 개입하고,
화면이 그 경계를 만든다
AI가 모든 것을 처리할 수 없다는 것을 전제로 설계했습니다. AI가 멈추고 사람이 판단해야 하는 경계가 화면에 없으면, 운영자는 시스템이 아니라 자기 경험에 의존해 일합니다.
화면화
Props로 제어
납품 완료
누가 쓰는지 모르면
화면을 두 번 그립니다
기능 목록만 받아 그리면 중반에 권한이 충돌하고,
그때까지 그린 화면을 전부 다시 그려야 합니다.
화면을 그리기 전에 사용자를 먼저 정의했습니다. 관리자·상담사·시스템 관리자, 세 역할이 볼 수 있는 것과 할 수 있는 것이 달랐습니다. 티켓 카드는 두 뷰에서 동일하게 쓰되 액션 버튼만 권한 Props로 제어했습니다. 관리자는 배정 변경, 상담사는 상담 시작만 보입니다.
50장이 넘는 화면을 그리는 동안
권한 충돌이 한 번도 생기지 않았습니다.
상태가 늘 때마다 컴포넌트가 늘면
운영할 수 없습니다
AI 서비스는 상태가 추가되는 속도가 빠릅니다.
기준 없이 상태 수만큼 만들면 감당할 수 없습니다.
여섯 가지 AI 분기 상태가 한 화면에 동시에 올라와야 했습니다. 정보 구조 자체가 달라지는 상태는 Variant로, 구조는 같고 시각 처리만 다른 상태는 Property로 분리했습니다. 여섯 상태를 두 기준으로 흡수했습니다.
상태가 추가돼도
구조가 흔들리지 않습니다.
수치를 보여줘도 판단을 못 하면
운영자는 감으로 일합니다
데이터를 보여주는 것과
판단하게 만드는 것은 다릅니다.
신뢰도 수치를 그대로 노출하면 운영자가 매번 기준값과 비교해 해석해야 합니다. 임계값 기준 안정·주의·개입 필요 3단계로 나눠 컬러 배지로 처리했습니다. 개입 필요 전환 시 카드 강조 인터랙션은 ProtoPie로 검증한 뒤 border-color 200ms · opacity pulse 600ms로 전달했습니다.
화면을 오갈 때마다
운영자는 방금 본 것을 잊습니다
AI가 처리한 결과를 사람이 검증하는
화면일수록 처리량이 많습니다.
QIDP 가명화 검증에서 이미지 뷰어와 수정 패널을 분할 레이아웃으로 고정했습니다. 이미지에서 영역을 선택하면 오른쪽 패널 항목이 자동 포커스됩니다. 패널 스크롤 animate 150ms · 포커스 highlight 100ms로 전달했습니다.
구조가 운영자의 행동 순서를
따라가야 맥락이 끊기지 않습니다.
AI가 멈추는 지점을
화면으로 만들었습니다
누가 쓰는지 먼저 정의하고, 상태값의 레이아웃 변화로 컴포넌트를 설계하고, 수치가 아니라 판단을 돕는 구조로 만들고, 운영자의 행동 순서에서 레이아웃과 인터랙션을 함께 결정했습니다.
AI가 처리할 수 없는 영역에서
사람이 일할 수 있는 화면을 만들었습니다.
제각각이던 220개 화면을
공통 규칙 하나로 통합했습니다
서비스가 커서 화면 단위로 나눠 개발했더니, 같은 플로우인데 화면마다 버튼·팝업·메시지가 다르게 구현됐습니다. 화면을 하나씩 고치는 대신, 플로우 단위로 공통 규칙을 정의하고 가이드로 배포했습니다.
디자이너 1인 운영
공통 규칙으로 통합
연결 화면 전체 반영
컴포넌트의 문제가 아니라
운영 구조의 문제였습니다
화면당 담당자가 다르면 같은 컴포넌트도
적용 기준이 사람마다 달라집니다.
공통 컴포넌트는 이미 정의돼 있었습니다. 컴포넌트를 더 만들거나 개발자를 한 명씩 설득하는 건 화면 수만큼 비용이 듭니다. 문제의 단위를 화면이 아니라 플로우로 다시 정의해야, 화면 수와 무관하게 한 번에 닫는 해결책이 나옵니다.
화면 220개를 푸는 게 아니라,
플로우 한 번으로 닫는 구조를 택했습니다.
전체 재작업이 아니라
영향 범위 기준 선별을 택했습니다
개발이 상당 부분 진행된 시점에 투입돼,
전체 재작업은 선택지가 아니었습니다.
스켈레톤 로딩·유효성 검사처럼 구현 비용이 큰 항목은 백로그로 분리하고, 버튼·팝업·메시지처럼 정의만으로 적용 가능한 항목을 먼저 가이드화했습니다. 우선순위는 현업·개발팀과 항목별로 합의한 결과입니다. 무엇을 미룰지 먼저 합의했기에, 나머지 가이드가 추가 설득 없이 받아들여졌습니다.
화면이 아니라
용어와 위계를 먼저 확정했습니다
화면 단위로 풀면 작업량이 화면 수에 비례하지만,
플로우 단위로 풀면 한 번의 정의로 닫힙니다.
Register·Save·Submit 혼용을 기능별 레이블로 확정했습니다. 버튼 위계는 화면당 프라이머리 1개 원칙으로, 팝업은 선택 필요=Confirm / 인지=Alert로 정의했습니다. 정의가 끝나면 개발자는 가이드 적용 외 별도 판단이 필요 없습니다.
220번의 개별 판단을,
한 번의 정의로 바꿨습니다.
영향 범위가 큰 패턴부터
묶었습니다
이 UI 하나를 바꿀 때 몇 개 화면이 영향받는가.
그것이 순서의 기준이었습니다.
VIN Search · GNB · 언어 전환 · Quick Link가 포함된 Header는 220~240개 전 화면에 공통이었습니다. Header 하나를 묶자 전체 화면이 DS 단위 1회 수정 체계에 들어왔습니다. 같은 기준으로 Admin 템플릿(40~50개), TSB 패턴, 게시판 공통을 순서대로 흡수했습니다.
적은 작업으로 가장 많은 화면을 한 번에 정상화하는 순서입니다.
정책 결정 회의에 직접 참여해
컴포넌트 증식을 막았습니다
정책이 확정된 뒤 받으면
브랜드마다 별도 컴포넌트를 만들게 됩니다.
현대 OTP / 기아 PIC처럼 2차 인증 방식부터 달랐습니다. 정책이 내려오길 기다리는 대신 결정 과정에 직접 참여해, 브랜드별 차이를 별도 컴포넌트가 아니라 Props 분기로 처리하는 구조를 정의했습니다.
이 구조에서는 브랜드가 추가돼도
DS 코어가 늘어나지 않습니다.
화면 수에
비례하지 않는 운영 구조
분산 개발로 깨진 기준을 플로우 단위로 통일하고, 영향 범위 순으로 적용하고, 브랜드 정책을 Props로 흡수하고, 운영 기준을 문서로 넘겼습니다.
인수받은 시스템을, 한 사람에게 의존하지 않는 구조로 바꿨습니다.
수정 하나가 전체에 반영되고
전담자가 빠져도 멈추지 않는 구조로 바꿨습니다.
4개 서비스 테마를
단일 토큰 코어로 묶은 디자인 시스템
DS가 있어도 테마가 늘 때마다 다시 만들어야 한다면, 그 DS는 비용을 줄이지 못합니다. 재사용이 목적인 DS가 오히려 작업을 늘리던 구조를, 테마가 늘어도 인력이 늘지 않는 구조로 바꿨습니다.
인력이 늘지 않는 구조
컴포넌트 수정량
IDAS · IDSS · Chatbot · Admin
두 번 실패하고 나서야
도메인을 출발점으로 뒀습니다
범용성을 먼저 추구하면
도메인 복잡도를 구조 밖으로 밀어내게 됩니다.
dealer365는 접수·정비·응대·정산이 한 화면에서 도는 딜러십 B2B SaaS입니다. 세 번째 구조는 업무 흐름에서 출발했습니다. 범용 패턴은 shadcn/ui로 흡수하고, 설계 비용은 도메인 특수 패턴 8개(RO Card · Damage Map · Inspection Module 등)에 집중했습니다.
도메인을 구조의 전제로 두면
테마가 늘어도 코어를 건드리지 않습니다.
변경 범위를 예측할 수 없으면
DS를 믿고 쓸 수 없습니다
토큰을 바꿀 때 영향 범위를 알 수 없으면,
수정이 무서워 방치하게 됩니다.
Primitive → Semantic → Mode 3단계 구조. primary-border처럼 의도 단위로 정의해 border만 바꾸고 싶을 때 border만 건드립니다. Dark/Light · RTL/LTR · Density 3단계를 컴포넌트를 건드리지 않고 토큰 분기만으로 대응했습니다.
Semantic Token 120개로
4개 테마 전체를 단일 관리합니다.
속성을 닫을수록
개발자는 DS 밖으로 나갑니다
DS를 만드는 것과
실제로 쓰이게 만드는 것은 다릅니다.
색상·타이포·간격은 단일 진실 공급원으로 사용했습니다. disabled·loading 같은 인터랙션 속성과 children·slots 같은 구조 확장에 대해서는 유연한 구조를 사용했습니다. 기획서 조건은 userRole · vehicleStatus처럼 속성으로 1:1 매핑했습니다.
판단 기준은 하나였습니다. 이 속성을 닫으면 개발자가 DS를 떠나 직접 구현하게 되는가.
쓰이는지 측정하지 않으면
관리 부담만 남습니다
채택률을 측정하지 않으면 DS가 살아 있는지
형식만 남았는지 알 수 없습니다.
GitLab MCP 기반 import 분석, 코드 리뷰 중 import 감지, Storybook 접속 로그로 측정 체계를 만들었습니다. 채택률이 떨어지는 컴포넌트가 보이면 속성 설계로 돌아갔습니다. 전부 만드는 것보다 경계를 정하는 것이 DS를 감당 가능하게 유지하는 방법입니다.
Wrapped 컴포넌트가 팀 요청의
80% 이상을 소화했습니다.
네 개의 판단이
하나의 결과로 모입니다
도메인을 전제로 구조를 잡고, 변경 범위를 제어 가능하게 만들고, 개발자가 우회하지 않도록 속성을 설계하고, 쓰이는지 측정했습니다. 네 판단이 하나의 시스템으로 연결됩니다.
테마가 늘어도 인력이 늘지 않는 구조.
DS가 비용을 줄이는 방식으로 작동하게 만들었습니다.
디자인 시스템이 실제로 작동하는
구조를 만드는 디자이너 김승연입니다.