Claude Code 기반 AI 디자인 워크플로우 구축
AI의 할루시네이션을 막는 기준점, SSOT
AI 덕분에 생산성이 비약적으로 올라갔죠. 그런데 문득 이런 생각이 들더라고요. 개발은 이렇게 빨라졌는데, 디자이너가 정적인 스크린 플로우를 일일이 그리고 핸즈오프를 하는 이 방식이 오히려 병목 아닐까?
이러한 생각에서 시작해 Cluade Code를 활용해 기획서의 리뷰부터 코드 생성까지 이어지는 디자인 프로세스를 구축해 봤어요. AI를 디자인에 활용할 때 직면하는 '일관성 부족'과 '근거 부족'이라는 어려움을 해결하려고 했던 노력을 공유해보려고 해요.
1. 신뢰할 수 있는 기반 : 단일 진실 공급원(SSOT)의 구축
AI가 디자인 시스템을 학습하고 정확한 결과물을 내놓으려면 명확한 기준점, 즉 '정답지'가 필요해요. 이를 위해 다음과 같은 기술적 환경을 우선적으로 조성했어요.
스토리북 기반의 관리 : 모든 디자인 시스템 컴포넌트는 스토리북을 통해 관리해요. AI에게 '우리 팀이 사용하는 컴포넌트의 표준은 이것이다'라고 정의하는 기준점이 돼요.
Component Registry 정의 : 예를 드면 design.md 파일을 통해 컴포넌트 이름과 속성(Props) 목록을 정리했어요. 이는 AI의 할루시네이션을 방지하는 강력한 제어 장치가 돼요.
컴포넌트 호출 스킬 최적화 : 특정 컴포넌트를 정확히 추출해서 실제 경로에서 호출하도록 명령 체계를 세팅했어요. 불필요한 코드 생성을 억제하고 프로덕션 수준의 정교함을 유지하기 위해서예요.
UX 원칙의 기준 체계화 : 컴포넌트뿐만 아니라 UX 원칙 역시 SSOT로 구축했어요. 첨부된 이미지처럼 docs/ux-principles/ 폴더 내에 UX원칙부터 판단 원리(Playbook), 화면 분류 기준까지 체계적으로 정리했어요. 모든 디자인 AI 스킬은 이 문서들을 공통의 '두뇌'로 삼아, 디자이너가 합의한 논리대로 일관된 판단을 내릴 수 있게 했어요.
하단 Phase 2 : 디자인 접근에서 좀 더 자세히 다룰게요.
SSOT로 관리되는 폴더 내 문서 예시이런 기술적 전제 조건들을 하나하나 해결해 나가는 구체적인 과정은 팀의 업무 환경이나 개인의 방식에 따라 정말 다양할 수 있다고 생각해요.
그래서 이번 글에서는 전체적인 방향을 잡기 위한 개념 위주로 정리했어요. SSOT를 구현했던 과정은 추후 별도의 포스팅을 통해 작성해 보겠습니다!
2. 프로세스의 전환 : 시안이 곧 코드로
가장 본질적인 변화는 시안이 별도의 도구가 아닌 실제 프로덕트 코드베이스 위에서 만들어진다는 점이에요. 프로젝트에 등록된 디자인 시스템 컴포넌트를 그대로 가져와 사용하기 때문에, 일관성이 잘 유지돼요. 전체 흐름은 기획서를 기반으로 두 가지 스킬을 사용해요.
Skill 1. Spec-Review : 기획의 해석
화면 레이아웃에 매몰되기 전, 해결하려는 문제의 본질을 분리하고 정의하는 단계입니다.
Skill 2. Spec-to-UI : 인터랙티브 시안 생성
합의된 해석을 바탕으로 실제 디자인 시스템을 활용해 작동하는 React 시안을 생성합니다.
3. 첫 번째 스킬 : Spec-review
AI 기반 디자인에서 가장 우려되는 지점은 앞서 말했듯, '일관성 부족'과 '근거 부족'이에요. 첫 번째 스킬인
design-spec-review는 그중에서도 '디자인의 근거'를 탄탄하게 세우기 위한 시도입니다.
우리는 기획서를 받자마자 "이 화면을 어떻게 그릴까" 고민하며 툴부터 켜지 않아요. 레이아웃부터 떠올리는 순간, 기획서를 그대로 복사만 하는 디자이너가 되기 쉽기 때문인데요. 대신 한 걸음 뒤로 물러나 이 기획이 풀고자 하는 진짜 문제가 무엇인지 차분히 분리하는 과정을 거칩니다.
Spec-review 스킬의 프로세스Phase1 : 문제 진단
기획서를 받자마자 화면 레이아웃을 떠올리면, 기획서를 그대로 복사하는 수준의 디자인에 머물게 됩니다. 그래서 이 단계에서는 한 걸음 뒤로 물러나 이번 프로젝트가 해결하려는 핵심 문제가 무엇인지 정의해요. 문제가 모호하면 이후의 모든 디자인 결정이 근거 없이 흔들리게 되므로, 단단한 공통 기반을 먼저 만드는 과정입니다.
Phase2 : 디자인 접근
사용자의 맥락에 따라 디자인 요구사항은 달라지기 마련이 이예요. 그래서 저는 각 화면을 누가, 어떤 목적로 사용하는지 파악하고 그에 맞는 '화면 유형'을 매핑하는 것부터 시작해 보기로 했습니다. 이때 진행하는 매핑은 단순히 디자이너의 직관이나 감에만 의존하지 않아요. 앞서 언급했던 SSOT(Single Source of Truth)로 관리되는 폴더 내 문서들을 철저히 기준으로 삼습니다.
AI에게 요구사항을 전달하면 보통 '왜 하는지(Why)'와 '어떤 결과가 나와야 하는지(What)'는 잘 알고 있습니다. 하지만 그 사이를 이어주는 구체적인 '판단 기준(How)'이 비어 있다고 생각했어요. 보통 이런 기준은 디자이너 개개인의 암묵적인 노하우나 감각으로 진행해 왔으니까요. 이 중간 고리가 없으면 결국 '누가 작업하느냐'에 따라 디자인 결과물이 매번 달라질 수밖에 없다고 생각했습니다.
- 원칙 (Why) : 우리 서비스에서 무엇이 가장 중요한 가치인지를 정의합니다.
- 중간 체계 (How) : 특정 화면에서 어떤 원칙을 얼마나 강하게 적용할지 판단하는 기준입니다.
- 구현 스펙 (What) : 실제 UI가 코드와 디자인 시스템상에서 어떻게 구현되는지 알려줍니다.
그래서 이를 보완하기 위해 추상적인 원칙들을 실무에서 바로 꺼내 쓸 수 있는 판단 근거로 구체화해 봤습니다. 디자이너 머릿속에 흩어져 있던 기준들을 공통 자산으로 끌어올렸어요.
이렇게 기준을 정리해 두면, 팀원 누구나 정의한 UX의 최소 원칙을 지키며 제품을 설계할 수 있을 것이라 샌각했어요. 이로 인해 사용하는 모든 디자인 AI 스킬이 이 문서들을 원칙으로 삼아 작동하도록 했습니다. 사람이 아닌 AI가 시안을 만들 때도, 디자이너들이 합의한 논리 구조를 따를 수 있게 했죠.
2개의 축으로 완성하는 '비중 매트릭스'
이 원칙들을 바탕으로 화면별 중요도를 결정하는 '비중 매트릭스'를 참고해 디자인 방향을 결정합니다. 이 과정을 거쳐야만 해당 화면에서 어떤 UX 원칙을 얼마나 강하게 적용할지 객관적으로 판단할 수 있기 때문이에요. 이 매트릭스는 크게 두 가지 축으로 구성됩니다.
첫 번째 축 : 역할 — 누가 쓰는 화면인가
같은 원칙이라도 누가 쓰느냐에 따라 적용 방향이 180도 달라지기도 합니다. 커머스 서비스로 예를 들면,
소비자(Buyer) : 서비스를 이용하는 사람입니다. 일반적으로 복잡한 로직은 최대한 숨겨서 사용을 편하게 해주는 것이 좋다고 생각했어요.
판매자(Seller) : 서비스를 관리하는 사람입니다. N명의 고객에게 영향을 줄 수 있기에, 복잡한 로직이라도 사용자의 언어로 풀어서 보여줌으로써 실수를 막는 것이 더 중요합니다.
두 번째 축 : 맥락 — 어떤 상태로 쓰는가
같은 사람이라도 지금 어떤 상황에 있느냐에 따라 목적과 감정이 다릅니다. 탐색 중인 사용자에게는 귀찮은 입력을 최대한 줄여야 하고, 결정 순간의 사용자에게는 실수를 막는 안전장치가 더 중요합니다. 이처럼 같은 원칙이라도 사용자의 상황에 따라 얼마나 강하게 적용할지가 달라집니다. 마찬가지로 커머스로 예를 들면,
탐색 : 쇼핑몰에서 상품을 둘러보는 단계입니다. 호기심은 있지만 언제든 떠날 수 있죠. 이때는 귀찮은 '입력 최소화'가 생명입니다.
결정 : 결제 버튼을 누르는 순간입니다. 긴장도가 높고 실수가 두려워지는 시점이라, 실수를 막아주는 '예외 설계'와 '다음 행동 명확' 원칙이 최우선입니다.
사용 : 주문 내역을 확인하거나 상품을 등록하는 일상적인 단계입니다. 익숙하지만 반복이 피곤하기에 '상태 명확'과 '효율성'이 중요해집니다.
6 분류 매트릭스 — 형태가 아닌 '맥락' 중심의 분류
앞서 정의한 역할(2개)과 맥락(3개)을 조합하면 총 6가지 화면 유형이 나옵니다. 같은 '목록 화면'이라도 소비자가 쇼핑을 위해 둘러보는 목록과 판매자가 송장 번호를 입력하기 위해 보는 목록은 지켜야 할 원칙의 우선순위가 전혀 다릅니다.
비중 매트릭스 기반, 디자인의 '우선순위'를 결정하는 법
화면 유형이 정해지면 우리가 정의한 5가지 원칙 중 무엇을 얼마나 강하게 지킬지도 함께 결정해요. 모든 화면에서 모든 원칙을 100% 사수하는 것은 불가능에 가깝고, 때로는 비효율적이기 때문입니다. 화면 유형마다 목적과 사용자의 심리 상태, 그리고 실패 시 치러야 할 비용이 다르기에 그 비중을 다르게 가져가기 위해 가중치를 부여했어요.
정의한 원칙을 어떤 비중으로 지킬 것인가그리고 이 가중치를 기반으로 기획서를 리뷰하면 Claude Code가 아래와 같이 제안해 줍니다.
Phase3 : 질문 도출(확인 필요 사항)
앞서 디자인 접근이 완료된 후 디자이너가 기획의 공백을 혼자만의 추측으로 메우면, 시안 공유 시점에 '의도한 것과 다르다'라는 피드백을 받을 확률이 높다고 생각했어요. 이를 방지하기 위해 공백을 6가지 축으로 분류하고, 각 질문의 담당자(@PM, @BE, @FE)를 명시합니다. 질문을 공식화하면 디자이너는 명확한 의사결정 히스토리를 확보할 수 있습니다.
Phase4 : 기획 단계 선제 리스크(UX 원칙 기반)
시안 제작 단계에서 발견하면 수정이 필요한 리스크를 기획 단계에서 미리 감지해요. Phase 2에서 정의한 화면 유형을 기준으로, 기획서 텍스트만으로 판단 가능한 리스크를 UX 원칙별로 점검해요. 아래는 예시입니다.
원칙 1 : 실패·중간 상태가 기획서에 정의되어 있는가?
원칙 2 : 되돌릴 수 없는 작업의 영향 범위가 명시되어 있는가?
Phase5 : 디자이너 해석 정리
기획서를 읽은 뒤 디자이너 머릿속에 만들어진 해석과 가정은 미리 공유되어야 해요. 그렇지 않으면 시안에 그대로 반영된 뒤에야 충돌이 드러나고, 이는 곧 높은 수정 비용으로 이어지게 됩니다. 시안 착수 전에 '나는 이 기획을 이렇게 이해했고, 이런 가정을 세웠다'는 메시지를 명확히 전달합니다.
4. 두 번째 스킬 : Spec-to-ui
앞선 단계에서 합의된 해석을 바탕으로, 실제 디자인 시스템 컴포넌트를 호출해 클릭과 입력이 작동하는 React 시안을 만들어요. 총 8개의 Phase로 구성됩니다.
Phase1 : 목표 세우기
본격적인 작업에 들어가기 전, 무엇을 그릴지보다 '왜, 그리고 누구를 위해' 그릴지부터 합의해요. 앞서 진행한 Spec-review 결과가 있다면 이를 적극적으로 재사용하고, 데이터가 없다면 내부적으로 다시 분석을 실행합니다. 이 과정에서 시안의 성격에 따라 '확정 시안'과 '확장 시안' 중 하나를 선택하게 되는데요.
디자인 시안을 잡을 때 가장 큰 고민은 "기획서에 충실할 것인가, 아니면 디자이너로서 더 나은 방향을 제안할 것인가?" 하는 지점이죠. 이런 고민을 해결하기 위해 시안 제작 모드를 두 가지로 정의했습니다.
확장 시안 : 기획서의 내용을 기반으로 하되, 전문가의 시선에서 UX 관점의 추가 제안을 포함합니다.
확정 시안 : 기획서에 명시된 기능과 요구사항을 정확하게 구현하는 데 집중합니다.
Phase2 : 상황 나열하기(UI 스펙 추출)
기획의 해석과 실제 UI 구현 사이의 연결 단계에요. 본격적인 디자인에 앞서 각 화면이 마주할 수 있는 UI 상태(Default, Empty, Error 등)를 리스트업 합니다.
이 과정에서 기획 내용 중 불분명한 지점은 디자이너가 임의로 추측하지 않아요. 대신 명확한 질문으로 남겨두어 답변을 기다립니다.
Phase3 : 컴포넌트 매핑
프로덕션 레벨로 일관성을 유지하기 위해 등록된 디자인 시스템 컴포넌트와 UI 스펙을 매핑해요. 디자인 시스템에 있는 것을 없다고 착각해 처음부터 재작성하는 일을 막습니다.
1) 컴포넌트 레지스트리로 후보 검색
2) 각 컴포넌트 소스 파일을 열어 export명·props·variant를 확인
3) 존재하지 않는 props나 variant를 추측으로 사용하는 것을 차단
4) 대응 컴포넌트가 없으면 사용자에게 보고 → 신규 생성 여부 결정
Phase4 : 시안 만들기
매핑한 컴포넌트를 직접 import 하여 실제 제품 환경에서 렌더링 되는 프로토타입을 만들어요. 이때 핵심 규칙은 절대 CSS로 컴포넌트를 흉내 내지 않는다는 점이에요. 반드시 실제 시스템 컴포넌트를 사용해 기술적 정확도를 높입니다.
Phase5 : 말투 고치기
시안에 포함된 모든 문구를 팀이 합의한 UX 라이팅 가이드에 따라 일괄 점검해요. 디자이너 개인의 감각에 의존하지 않고, 사전에 정의된 가이드를 기준으로 톤 앤 매너를 조정합니다.
Phase6 : 결과 공유하기
이 단계에서는 디자인 시안 파일과 함께 리뷰어가 시안을 객관적으로 평가하는 데 필요한 맥락 정보를 정리해서 공유해요.
Phase7 : 최종 점검하기
시안 공유 전, AI가 생성한 코드가 규칙을 완벽히 지켰는지 자동 검수 단계를 거칩니다. 기술적 오류가 없는지, 디자인 시스템 가이드를 준수했는지 *4개의 축으로 점검해요.
*4개의 축이란?
1) 디자인 시스템 적합성
- CSS로 컴포넌트를 흉내 낸 곳이 없는가?
- 사용한 props/variant 값이 실제 컴포넌트에 존재하는가?
- primitive 컬러(gray-500, red-50 등) 없이 시맨틱 토큰만 사용했는가?
2) UX 규칙
- 화면 유형에 맞는 원칙 비중이 반영되었는가
- 파괴적/되돌릴 수 없는 액션이 기본 흐름과 분리되었는가
- ux-playbook 조합 규칙이 적용되었는가 (예: Empty 상태에서 Pagination 숨김)
3) 문구 톤 (Phase 4 결과 반영 확인)
- Phase 4의 정식 위반 항목이 모두 수정되었는가
- 보조 제안 중 반영하지 않은 항목에 사유가 있는가
4) 시안 모드 준수
- (확장 시안) 추가 요소에 모두 PROPOSAL 주석이 달려 있는가
- (확장 시안) Phase 5 보고의 제안 목록 표와 PROPOSAL 수가 일치하는가
- (확정 시안) PROPOSAL 주석이 코드에 하나도 없는가
Phase8 : 목적 기반 리뷰
마지막으로 시안이 본래의 설계 목적에 부합하는지 확인해요. 기술적으로 완벽해도 목적을 놓치면 전체를 다시 수정해야 할 수도 있거든요. Phase 1에서 정의한 문제와 맥락을 기준으로 스스로 질문을 던지고, 모두 통과할 때까지 시안의 완성도를 높입니다.
Phase 9 : 핸즈오프 없는 이터레이션
팀원들과 리뷰할 때 정적인 스크린샷이 아니라 실제로 클릭하고 입력할 수 있는 화면을 함께 보며 논의해요. "이 버튼 누르면 다음 화면이 어떻게 되지?"라는 질문에 말로 설명하는 대신, 직접 눌러보면 되니까요.
수정이 필요한 부분이 발견되면 Claude Code에 자연어로 요청합니다. "이 카드 사이 간격을 좁혀줘", "빈 상태일 때 CTA 문구를 바꿔줘"처럼요. 그러면 디자인 시스템 컴포넌트 기반으로 바로 수정이 반영되고, 다시 화면에서 확인할 수 있어요.
더 정밀한 조정이 필요할 때는 디자이너가 직접 CSS 수치를 미세하게 손보기도 해요. 코드가 곧 시안이니까, 수정한 결과를 바로 눈으로 확인할 수 있어서 오히려 피그마에서 프레임 잡는 것보다 빠르게 느껴질 때도 있어요. 또한 머릿속 레퍼런스를 전달하기 어려운 경우에는 Figma MCP를 활용하기도 해요. 피그마에서 원하는 화면을 그려 전달하며 "이런 느낌으로 만들어줘"라고 요청하면, Claude Code가 해당 시안을 참고해 코드를 수정합니다.
이 과정에서 기존 워크플로우에 있던 많은 것들이 자연스럽게 사라졌어요. 간격 1px, 컬러값 하나를 수정하기 위해 스크린샷에 빨간 동그라미를 치고 코멘트를 다는 일. 플로우의 부자연스러움을 정적인 화면 위에 화살표와 텍스트로 설명하던 일. 그리고 무엇보다, 디자이너의 의도를 오차 없이 전달하기 위해 핸즈오프 문서를 정성스럽게 준비하던 시간까지요.
시안 자체가 코드이기 때문에 '전달'이라는 단계가 필요 없어졌어요. 디자이너가 의도한 인터랙션과 레이아웃이 이미 코드에 담겨 있으니, FE 개발자는 별도의 해석 없이 그 코드를 기반으로 작업을 이어갈 수 있습니다.
오늘자 스크린 타임. figma을 사용하는 시간이 점점 줄어든다.마치며 : 디자이너의 시간은 어디에 쓰여야 할까
최근 스크린타임을 들여다보면 변화가 숫자로 보여요. 피그마를 열어두는 시간이 눈에 띄게 줄었고, 그 자리를 안티그래비티(또는 VS code) 브라우저가 채우고 있어요. 처음에는 어색했지만, 지금은 이 비율 변화 자체가 프로세스가 어느 정도 작동하고 있다는 지표라고 느끼고 있어요.
이번에 AI를 업무에 접목하며 느낀 점은 생각보다 훨씬 더 디자이너에게 반복 작업이 많았다는 사실이에요. 스크린 플로우를 그리고, 핸즈오프를 준비하고, 예외 케이스를 하나하나 정의하는 등..
저는 디자인 시스템 에이전트, UX 라이팅 스킬, UX 검증 스킬 등을 마련하면서 그동안 디자이너의 업무 환경에 얼마나 많은 반복 작업이 있었는지를 체감할 수 있었어요. 그러면서 프로덕트 디자이너에게 요구되는 역량이 단순히 AI로 결과물을 빠르게 추출하는 스킬에 그치지 않는다는 것도 느꼈어요.
이제는 누가 작업하더라도 프로덕션 레벨의 일관성을 유지할 수 있도록 ‘시스템과 프로세스’ 자체를 설계하고 구조화하는 능력이 중요하다고 생각했어요.
또한 내부의 병목 구간을 발견하고 팀원의 문제까지 해결할 수 있는 프로세스를 구축해 나가는 과정은 저에게도 매우 유의미했습니다. 단순히 내 일을 편하게 만드는 것을 넘어, 우리 팀 전체의 효율을 고민하는 계기가 되었거든요.
앞으로도 저는 이러한 고도화 작업을 지속해 나가려고 해요. 반복적인 태스크는 시스템에 과감히 위임하고, 디자이너로서 디자인의 본질이자 핵심적인 의사결정에 몰입할 수 있는 시간을 더 많이 확보해 보려고요.
결국 디자이너의 시간은 화면을 채우는 작업이 아니라 '무엇을, 왜 만들어야 하는가'라는 질문에 답을 내리는 곳에 쓰여야 한다고 생각해요.
긴글 읽어주셔서 감사합니다! 혹시 더 나누고 싶은 이야기가 있다면 링크드인으로 언제든 연락주세요!