Claude Design을 활용한 디자인 시스템 만들기 (6) — 기존 프로젝트에 적용하기
Claude Design으로 디자인 시스템 만들기 (6)
Claude Design으로 디자인 시스템 만들기
- 01Claude Design을 활용한 디자인 시스템 만들기 (1) — 계획 수립
- 02Claude Design을 활용한 디자인 시스템 만들기 (2) — 디자인 소스 추출
- 03Claude Design을 활용한 디자인 시스템 만들기 (3) — 디자인 시스템 구현
- 04Claude Design을 활용한 디자인 시스템 만들기 (4) — 프로토타입 생성
- 05Claude Design을 활용한 디자인 시스템 만들기 (5) — 디자인 적용하기
- 06Claude Design을 활용한 디자인 시스템 만들기 (6) — 기존 프로젝트에 적용하기현재
- 07Claude Design을 활용한 디자인 시스템 만들기 (7) — 디자인 검수 자동화
5편에서는 새 프로젝트 적용해보았으니, 이번엔 기존 디자인이 박혀 있는 서비스에 적용해보자.
또 다른 프로젝트
5편 마지막에 디자인이 이미 박혀 있는 프로젝트는 또 다른 이야기일 거라고 적었다.
역시나. 실제로 다른 이야기였다.
이번 대상은 채점 서비스.
학원에서 학생 답안을 채점하고 결과 리포트를 학부모에게 보내는 도구다.
학부모용 공개 리포트는 외부 노출이라 디자인 무게가 크고, 운영자가 쓰는 admin 페이지도 적지 않다.
거기다 초등·중등·고등 학년별로 비슷하지만 다른 디자인이 필요했다.
5편 bookstore는 기능 골격만 있던 새 프로젝트였는데, 이번 채점 서비스는 AI가 자체적으로 만들어둔 디자인이 이미 곳곳에 박혀 있는 상태였다.
Claude Code에게 명세 요청하기
5편에선 디자인 명세를 내가 직접 적었다.
이번엔 Claude Code에게 맡겼다.
채점 서비스의 Claude Code에게 디자인 시스템 레포 주소를 알려주고, 서비스 기획·페이지 구성·기존 디자인을 종합해서 명세를 작성하게 했다.

그렇게 작성된 약 350줄의 디자인 브리프.
Claude Design에도 코드를 통째로 업로드해서 미리 분석시켰다.
두 AI 모두 코드베이스를 읽은 상태에서 시작하니 정확도가 한 단계 올라갔다.
5편 때보다 한 층 더 위임된 워크플로우다.
Claude Design에게 프로토타입 받기
명세를 던지고 시작.

이번에도 곧 질문이 돌아왔는데, 5편 때보다 정교했다.
명세 안의 모순까지 짚어냈다. 예를 들어 "violet 그라디언트 띠가 언급되지만 디자인 시스템은 'no gradient' 원칙. 어떻게 풀까요?" 같은 식으로.
이번엔 변형 안을 여러 개 받기로 했다.
헤더 톤이나 점수 박스 디자인을 단정함 vs 따뜻함 같은 축으로 비교하고 싶었다.

시안이 한 캔버스에 펼쳐졌다.
모의고사 결과 3안, 일반 결과 2안.
그중에서 골라내고 합치는 큐레이션 작업이 필요했다.
Claude Code에게 디자인 적용시키기
역시 한방에 '딸깍'으로 될 리가 없지.
핸드오프를 받아서 Claude Code에게 던졌는데, 앞서 작성한 프로젝트와는 달리 매끄럽게 흘러가지 않았다.
시안의 컴포넌트 이름이 본 repo의 옛 함수 이름과 충돌했고, 본 repo에는 2200줄짜리 옛 컴포넌트가 살아 있어서 그걸 어떻게 정리할지 결정해야 했다.
작업을 D-1, D-2, D-3 단계로 쪼갰다.
디자인 시스템 자산 도입 → 고등 모의고사 결과 → 초·중등 일반 결과.
각 단계마다 빌드 통과를 확인했다.
세 단계 다 끝나고 디자인을 확인했는데, 100% 적용이 안 된 실망스러운 결과물이 나왔다.

폰트가 시안과 다르고, 색이 다르고, 레이아웃이 깨져 있었다.
빌드는 통과했는데 디자인은 안 먹었다.
번들된 CSS를 직접 grep해서 봤다.
디자인 시스템 토큰이 하나도 안 들어가 있었다.
Pretendard 폰트도 0개.
원인은 두 가지가 겹쳤다.
하나는 app.css의 import 경로가 자기 자신을 다시 거치는 잘못된 경로였고, 다른 하나는 Tailwind v4가 @import "tailwindcss"; 이후의 외부 CSS @import를 자체 파이프라인에서 흡수해버렸다.
main.tsx에서 디자인 시스템 CSS를 직접 import하도록 바꾸니까 토큰이 번들에 들어갔다.
작업 계획의 중요성
또 하나 빠뜨려진 게 있었다. 모바일이었다.
세 단계 데스크톱 디자인 적용을 다 끝내고 나서야 알아챘다.
명세에는 모바일 가이드가 있었고 시안에도 모바일 변형이 따로 있었는데, 본 repo에는 데스크톱만 옮겨져 있었다.
"프로젝트 분석 → 시안 생성 → 적용" 흐름이 매끄럽게 흘러가는 줄 알았는데, 그 사이에서 뭐가 빠질 수 있다는 걸 그제야 알았다.
막상 모바일을 적용하려니 단순한 작업도 아니었다.
표를 카드로 바꾸는 식의 변형은 CSS 미디어 쿼리만으론 안 되고 컴포넌트 자체를 갈라야 했다.
시간과 분량이 꽤나 큰 작업이었다.
이전 프로젝트처럼 "핸드오프 적용해줘" 한 마디로 던질 일이 아니었다.
적용 자체에도 작업 계획을 빡세게 짰어야 했다.
시안의 모든 변형(데스크톱, 모바일, 학년별)을 단계로 미리 펼쳐놓고 시작했어야 누락이 없었을 텐데, AI를 믿고 해당 단계를 건너뛴 게 결국 커다란 페이오프로 돌아왔다.
다음 작업
남는 일은 검수다.
디자인이 정말 들어갔는지, 시안과 다른 건 없는지, 깨진 데는 없는지.
화면마다 일일이 비교해야 한다.
근데 이건 내가 원하는 진정한 자동화와는 거리가 좀 멀다.
AI는 디자인을 만들고 코드를 쓰는데, 정작 사람은 화면 비교만 하고 있는 웃기는 상황이다.
이것도 AI에게 맡길 방법이 있지 않을까.
comments
loading…