Claude Design을 활용한 디자인 시스템 만들기 (5) — 디자인 적용하기

4편에서 Claude Design으로 화면을 뽑았다. 이번엔 그 결과를 Claude Code로 실제 코드에 적용해보자.

쉽고 빠른 적용

적용은 역시나 간단하다.
주어진 핸드오프를 Claude Code에게 전달하면, 꽤 오랜 시간과 토큰을 소모한 뒤 결과물을 만들어낸다.

3편에서 깔아둔 인프라 덕에 트러블 슈팅도 거의 없었다.
git dependency로 박혀 있는 디자인 시스템, CLAUDE.md로 자동 주입되는 컨텍스트.
Claude Code가 알아서 토큰 가져다 쓰고, 컴포넌트 import하고, 화면 적용하고.

초안 배포까지 빠르게 도달했다.

근데 그게 5편 본론이 아니다.
적용 자체가 쉬워지니까, 그 다음 단계에서 새로운 문제가 보였다.

Design과 Code 사이의 갭

배포하고 나서 디자인 손볼 게 보이기 시작했다.
근데 손대다 보니 의문이 생겼다.
Claude Design으로 돌아가서 시안을 다시 뽑아야 하나, 아니면 Claude Code에서 직접 고쳐야 하나.

생각해보면 시안과 코드 사이에는 갭이 있다.
시안엔 박혀 있는데 우리 DB엔 없는 필드, 시안의 더미 가격과 실제 동적 가격, 시안엔 없는 로딩·에러 상태 같은 것들.
결국 Claude Code에서 하나씩 메워나갔다.

검수는 귀찮아

근데 일일이 고칠 생각을 하니 귀찮았다.

디자인 한 장 한 장 코드와 비교하고, 토큰 제대로 적용됐는지 보고, 간격이 어색한 곳 조정하고, 모바일에서 깨진 데 고치고.
이걸 화면마다 반복해야 한다.

옛날 같으면 당연히 받아들였을 일이다.
디자인 만들고 코드 짜는 시간이 오래 걸렸으니, 검수 시간이 상대적으로 짧게 느껴졌을 거다.
근데 만드는 게 빨라지니까 검수가 무겁게 느껴진다.

만드는 속도와 검수 속도의 격차.
AI에 적응한 몸이 이걸 견디기 힘들어한다.

다음 작업

여기까지가 디자인 시스템을 만들고 새 프로젝트에 적용해본 이야기였다.

근데 현재 프로젝트에 적용하는 게 매끄러웠던 건, 사실 이게 새로 만드는 프로젝트였기 때문이다.
AI가 자체적으로 만들어둔 디자인이 이미 박혀 있는 다른 프로젝트들은 또 다른 이야기일 거다.
디자인 시스템과 부딪히는 기존 클래스들, 어디까지 갈아엎을지, 어디부터 손댈지.
실제로 적용해봐야 알 일이지만 트러블슈팅이 좀 있을 것 같다.

우선 다음주 클로드 디자인 토큰이 리필되면 적용해보겠다.