휴먼 디자이너를 AI 디자인 에이전트로 복제

 

X의 Karan🧋님(@kmeanskaran)

 

디자이너의 머릿속을 복제해 누구나 90점 이상의 UI를 만들게 한다

핵심 아이디어를 한 문장으로 정리하면 다음과 같습니다.

“디자이너가 직접 모든 화면을 만드는 대신, 디자이너의 판단 기준과 작업 프로세스를 코드·문서·디자인 시스템으로 구조화하고 AI가 이를 매번 참조하도록 만든다.”

즉, 단순한 AI UI 생성기가 아니라 ‘디자이너의 사고 과정 자체를 시스템화’한 것입니다.

---

1. 왜 이런 시스템을 만들었나

기존 NEWT 개발 조직은 대략 다음과 같았습니다.

Before

3개 팀

팀마다
PM 1명
엔지니어 약 3명
디자이너 1명

그런데 AI 도입 이후 개발 속도가 빨라지고 엔지니어의 풀스택화가 진행되면서 소규모 팀을 많이 만들 수 있게 되었습니다.

After

8개 팀

그중
3개 팀 → 디자이너 있음
5개 팀 → 디자이너 없음

문제는 개발팀 수는 늘어나지만 디자이너 수는 그대로라는 것입니다.

디자이너 한 명이 여러 팀을 담당할 수도 있지만,

모든 화면 직접 디자인
↓
모든 화면 검토
↓
수정
↓
다시 검토

를 반복하는 것은 현실적으로 어렵습니다.

그러나 개발 속도를 위해 디자인 품질을 포기할 수도 없습니다.

그래서 이들이 내린 결론은 다음과 같습니다.

UI 품질이 흔들리는 이유는 디자인 판단 기준이 디자이너의 머릿속에만 있기 때문이다.

그렇다면

디자이너 머릿속의 판단 기준을 밖으로 꺼내 AI가 읽을 수 있게 만들자.

라는 접근입니다.

---

2. 목표

최종 목표는 다음과 같습니다.

PM / 엔지니어
        ↓
Claude Code
        ↓
NEWT 디자인 기준 참조
        ↓
90점 수준 UI 생성
        ↓
디자이너 리뷰
        ↓
확정

즉 디자이너의 역할을

Before

디자인 제작자

에서

After

디자인 기준 설계자
+
최종 리뷰어

로 바꾸는 것입니다.

---

3. 반드시 구현하고 싶었던 5가지

① Figma가 아니라 Claude Code로 UI를 만들 수 있어야 한다

PM이나 엔지니어가 Figma를 능숙하게 다루는 데에는 진입장벽이 있습니다.

반면 회사에서는 Claude Code를 전사적으로 사용하고 있기 때문에 직군에 관계없이 쉽게 사용할 수 있습니다.

그래서 디자인 작업 인터페이스를

Figma

가 아니라

Claude Code

로 설정했습니다.

---

4. ② 디자이너의 사고 과정을 그대로 재현

디자이너는 보통 바로 화면부터 그리지 않습니다.

실제 과정은 다음과 같습니다.

문제 이해
↓
PRD 확인
↓
기존 UI 조사
↓
경쟁사 조사
↓
여러 디자인안 작성
↓
비교
↓
추천안 결정
↓
세부 UX 검토
↓
디자인 제안

그런데 일반적인 AI UI 생성은

프롬프트
↓
UI 생성

으로 끝나는 경우가 많습니다.

그래서 NEWT에서는 디자인 결과물만 생성하지 않고 디자인 사고 과정 자체를 AI Workflow로 만들었습니다.

---

5. ③ 디자인 리뷰하기 쉬운 결과물을 만든다

UI 이미지만 던져주면 디자이너가 리뷰하기 어렵습니다.

예를 들어 이런 질문이 발생합니다.

왜 이 화면을 만들었지?

경쟁사는 어떻게 하고 있지?

사용자가 어떤 행동을 해야 하지?

이 버튼을 누르면 어떻게 되지?

이 상태에서는 어떤 UI가 나오지?

그래서 최종 결과물에는 단순 화면뿐 아니라

문제 정의
경쟁사 조사
설계 근거
디자인 후보
추천안
상세 사양

을 모두 포함합니다.

최종적으로 한 장의 HTML 문서로 만들어집니다.

---

6. ④ 디자인 단계에서는 구현을 잊되, 바로 구현으로 연결

이 부분이 상당히 중요합니다.

디자인 단계에서

API
DB
서버 상태
데이터 연결

같은 것을 고민하기 시작하면 UI 탐색 범위가 제한됩니다.

그래서 디자인 환경에서는 이런 구현 요소를 제거합니다.

하지만 디자인이 확정된 후 다시 UI를 개발하면 비효율적입니다.

그래서

디자인할 때 사용하는 UI 컴포넌트와 실제 서비스에서 사용하는 UI 컴포넌트를 동일하게 만들었습니다.

---

7. 핵심 아키텍처

전체 시스템에는 2개의 핵심 저장소가 있습니다.

newt-design-system
        +
newt-spec

역할은 명확하게 나뉩니다.

newt-design-system

"어떻게 디자인해야 하는가"
디자인의 기준 / Single Source of Truth

그리고

newt-spec

"무엇을 만들어야 하는가"
PRD / 기능 명세 / 실제 디자인 작업

입니다.

---

8. newt-design-system

구조는 다음과 같습니다.

newt-design-system/
│
├── tokens/
│   └── newt.tokens.json
│
├── packages/ui/
│   └── src/components/
│
├── design-mock/
│   ├── components/
│   ├── screens/
│   ├── design/contracts/
│   ├── foundations/
│   └── src/
│
├── docs/
│   └── communication-design/
│
├── plugin/
│
└── storybook/

단순 UI 컴포넌트 라이브러리가 아닙니다.

여기에 NEWT 디자인과 관련된 모든 정보를 모읍니다.

예를 들면

색상
폰트
여백
UI Component
UX 철학
UX Writing
브랜드 디자인
Communication Design
Figma Plugin
Storybook

등입니다.

즉

NEWT 디자인의 Single Source of Truth

입니다.

---

9. Design Token

예를 들어 컬러나 여백을 각각의 화면에서 AI가 마음대로 결정하지 않습니다.

tokens/newt.tokens.json

에 정의합니다.

개념적으로는

{
  "color": {
    "primary": "...",
    "text": "...",
    "background": "..."
  },
  "spacing": {
    "sm": "...",
    "md": "...",
    "lg": "..."
  }
}

같은 형태가 됩니다.

따라서 AI 역시 임의 값을 생성하는 것이 아니라 기존 토큰을 사용합니다.

---

10. 실제 제품과 디자인 시안이 같은 UI Component 사용

이 시스템에서 가장 중요한 결정 중 하나입니다.

처음에는 디자인 시안을 일반 HTML로 만들었습니다.

그런데 문제가 발생했습니다.

화면 A Button
17px

화면 B Button
16px

화면 C Button
padding 약간 다름

AI가 계속 비슷하지만 조금씩 다른 컴포넌트를 만들었습니다.

그래서

packages/ui

를 만들고 실제 서비스와 디자인 mock이 모두 동일한 컴포넌트를 사용하도록 변경했습니다.

               packages/ui
                    │
           ┌────────┴────────┐
           │                 │
실제 NEWT 서비스       design-mock

따라서 디자인 시안 단계부터 실제 서비스와 동일한 버튼, 카드, 입력창 등이 사용됩니다.

이것이 상당히 중요한 포인트입니다.

---

11. design-mock

design-mock은 디자인 실험 공간입니다.

Next.js 앱으로 만들어져 있습니다.

여기서는

API
Backend
DB

를 연결하지 않습니다.

UI/UX만 집중해서 검토합니다.

---

12. 디자인을 4단계로 구조화

디자인을 대략 다음과 같은 계층으로 나눕니다.

Page
 └─ Section
      └─ Domain Component
            └─ UI Component

예를 들어 여행상품 상세 화면이라면

TourDetailPage

 ├─ HeroSection
 ├─ PriceSection
 │    ├─ PriceCard
 │    │    ├─ Text
 │    │    ├─ Badge
 │    │    └─ Button
 │
 └─ ScheduleSection

처럼 됩니다.

---

13. 실제 코드와 공유하는 것은 UI Component만

흥미로운 부분입니다.

UI Component

만 실제 제품과 공유합니다.

반면

Domain Component
Section
Page

는 디자인 mock 전용입니다.

왜냐하면 실제 제품에서는 이 부분들이 비즈니스 로직에 따라 다시 구성되기 때문입니다.

대신 이름과 구조는 동일하게 맞춥니다.

그래서 디자인팀과 개발팀이

PriceSection
TourHero
PriceCard

같은 동일한 언어로 이야기할 수 있습니다.

---

14. Component Contract

AI가 UI 컴포넌트를 정확하게 이해하려면 단순 TSX 코드만으로 부족합니다.

따라서

design/contracts/

안에 컴포넌트의 기계 판독 가능한 사양을 관리합니다.

예를 들어 개념적으로

Button

Variant
- Primary
- Secondary
- Text

Size
- Small
- Medium
- Large

Usage
Primary action은 페이지당 하나를 권장

Avoid
위험 작업에서 Primary 사용 금지

같은 것입니다.

즉 AI용 디자인 명세서입니다.

---

15. MCP를 이용해 AI가 디자인 시스템을 읽는다

여기서 MCP가 등장합니다.

design-mock은 Next.js 웹앱인 동시에

design-system MCP Server

역할을 합니다.

Claude Code가 이 MCP를 이용해 NEWT 디자인 시스템을 검색합니다.

예를 들어 AI가

여행 상세페이지의 가격 영역을 수정해줘.

라는 요청을 받으면

전체 디자인 시스템을 읽지 않습니다.

대신

get_section("price")

같은 방식으로 필요한 부분만 가져옵니다.

버튼이 필요하면

get_ui_component("Button")

을 호출합니다.

---

16. 필요한 만큼만 가져오는 것이 중요

NEWT에는 화면이 매우 많기 때문에 전체 디자인 시스템을 매번 LLM Context에 넣는 것은 비효율적입니다.

그래서 검색 단위를 나눕니다.

Page
Section
Domain Component
UI Component
Token
UX Writing

Claude가 필요한 디자인 정보만 가져올 수 있습니다.

즉 일종의

Design RAG

구조라고 볼 수도 있습니다.

---

17. 회사 공용 MCP

또 중요한 것이

reiwatravel-mcp

입니다.

각 프로젝트마다 MCP를 설치해야 한다면

설정 파일 추가
Server 실행
Token 설정
권한 설정

등이 필요해서 사람들이 잘 사용하지 않게 됩니다.

따라서 사내 공통 MCP 환경을 구축했습니다.

결과적으로 회사 직원은

어떤 Repo
어떤 프로젝트
어떤 직군

에서도 NEWT Design System을 불러올 수 있습니다.

---

18. 두 번째 저장소 newt-spec

이곳에는

PRD
기능 정의
UX Specification
Design Workflow

가 들어갑니다.

그리고 중요한 AI Skill이 존재합니다.

대표적인 것이

design-builder

입니다.

---

19. design-builder Skill 구조

design-builder/
│
├── SKILL.md
│
├── references/
│   ├── principles.md
│   ├── proposal-rules.md
│   ├── checklist.md
│   └── ...
│
├── scripts/
│
└── templates/

여기서 가장 중요한 것은

SKILL.md
+
references/

입니다.

---

20. SKILL.md = 디자이너의 작업 프로세스

SKILL.md에는 Step 0~8까지 디자인 프로세스를 정의합니다.

즉 Claude에게

"디자인해."

라고 요청하는 것이 아니라

Step 0
문제 파악

Step 1
자료 읽기

Step 2
모호한 점 확인

Step 3
조사

Step 4
디자인안 제작

Step 5
비교

Step 6
추천

Step 7
문서화

Step 8
PR 생성

같은 강제 Workflow를 실행시키는 것입니다.

---

21. references = 디자이너의 머릿속

이 부분이 이 글의 핵심입니다.

references/의 약 11개 파일에 디자인 판단 기준이 들어 있습니다.

예:

principles.md

UI 생성 시 반드시 지켜야 하는
10개의 디자인 원칙

proposal-rules.md

디자인 제안서 작성 규칙

checklist.md

완료 조건

Claude는 체크리스트를 모두 만족하기 전까지 디자인 작업이 완료된 것으로 판단하지 않습니다.

즉

디자이너의 경험
↓
문서화
↓
AI 규칙
↓
매 디자인 작업 적용

구조입니다.

---

22. 실제 AI 디자인 Workflow

실제 디자인은 대략 다음 순서로 진행됩니다.

Step 1. 전제 확인

어떤 화면인가?
어떤 문제가 있는가?

---

Step 2. 자료 확인

PRD
Design System
기존 화면
UX Guide

를 읽습니다.

---

Step 3. 모호한 부분 해결

AI가 질문합니다.

예를 들어

결제 버튼은 항상 노출되어야 하나요?

로그인하지 않은 사용자도 가격을 볼 수 있나요?

설계에 중요한 불확실성을 하나씩 제거합니다.

---

Step 4. 조사

Claude가

사내 기존 화면
+
경쟁사 화면

을 조사합니다.

그리고

Screenshot
출처
패턴
장단점

을 정리합니다.

---

Step 5. 여러 디자인안 제작

예:

Option A
기존 패턴 유지형

Option B
정보 계층 개선형

Option C
전환 최적화형

각각 실제 NEWT 컴포넌트를 이용해 작동하는 화면으로 만듭니다.

---

23. AI가 추천안까지 선택

단순히 3개를 만들고 끝내지 않습니다.

AI가

추천안: B

이유:
- 정보 구조가 명확함
- 기존 NEWT 패턴과 일치
- 구현 변경이 작음
- 모바일에서도 안정적

같은 판단을 내립니다.

---

24. 최종 결과는 하나의 HTML

최종 결과는 이런 식입니다.

Design Proposal

1. Problem
2. PRD
3. Existing UI
4. Competitor Research
5. Findings

6. Design Option A
7. Design Option B
8. Design Option C

9. Recommended Design

10. Interaction Spec
11. UX Writing
12. Edge Cases

13. Implementation Notes

이 모든 것이 한 페이지 HTML에 들어갑니다.

따라서 디자이너는 화면만 보는 것이 아니라

왜 이런 디자인이 나왔는지

까지 동시에 검토할 수 있습니다.

---

25. GitHub PR + Vercel Preview

디자인도 코드처럼 PR을 만듭니다.

Claude Code
↓
Design HTML
↓
Git Commit
↓
Pull Request
↓
Vercel Preview
↓
Designer Review

리뷰어는 URL 하나만 클릭합니다.

Vercel Preview에서 실제 화면을 보고 댓글도 남길 수 있습니다.

---

26. 디자이너 승인

AI 디자인
↓
Designer Review
↓
수정
↓
Approve
↓
구현

방식입니다.

중요한 점은 AI가 디자이너를 없애는 시스템이 아니라는 것입니다.

AI는 90점 정도를 목표로 하고,

마지막 10점

을 디자이너가 판단합니다.

---

27. 아직 AI에게 맡기기 어려운 것

글에서도 한계를 명확히 인정합니다.

특히

완전히 새로운 UX를 만드는 0→1 디자인

은 아직 어렵다고 이야기합니다.

예를 들어

기존에 전혀 없던 기능
새로운 Interaction
새로운 User Journey
브랜드의 중요한 Experience

등입니다.

이때는

AI → 아이디어 / 참고안
Designer → Figma에서 최종 설계

방식을 사용합니다.

---

28. 그래서 역할을 구분한다

AI에 잘 맞는 작업

기존 화면 개선
기존 패턴 확장
일상적인 UI 변경
폼 추가
Section 변경
정보 구조 개선

디자이너가 직접 해야 할 가능성이 높은 작업

새로운 서비스
새로운 UX
핵심 Experience
브랜드 핵심 화면
0→1 제품

입니다.

---

29. Figma의 역할도 바뀐다

기존에는

Figma = 디자인의 Master

였습니다.

하지만 새로운 구조에서는

Design System Code
+
design-mock main

이 Master가 됩니다.

Figma는

필요할 때 쓰는 디자인 도구

로 바뀝니다.

---

30. 확정 디자인은 main으로 Merge

승인된 디자인은

design-mock/main

에 들어갑니다.

그러면 다음 Claude 작업에서 이 디자인을 다시 참조할 수 있습니다.

즉

AI 디자인
↓
사람 리뷰
↓
승인
↓
Design System 축적
↓
다음 AI 디자인의 Reference

라는 학습 루프가 생깁니다.

---

31. 이 시스템의 진짜 핵심

기존 Design System은

인간이 읽는 문서

였습니다.

하지만 이 시스템에서는

AI가 매번 읽는 실행 가능한 지식베이스

가 됩니다.

기존 문제는

Design System 작성
↓
사람이 안 봄
↓
오래됨
↓
실제 제품과 달라짐
↓
아무도 안 봄

이라는 악순환이었습니다.

AI가 사용하면 반대가 됩니다.

AI가 매 작업 참조
↓
Design System 중요도 증가
↓
계속 업데이트
↓
더 정확한 AI 결과
↓
사용 증가

---

32. 앞으로의 목표

현재는 UI Design System이 중심이지만 앞으로는 범위를 확장하려고 합니다.

Product UI
+
UX Writing
+
Brand
+
Communication Design
+
Advertisement
+
Landing Page

까지 모두 하나의 Single Source에 넣는 것입니다.

그리고

reiwatravel-mcp

를 통해 AI에게 전달합니다.

결국 구조는 이렇게 됩니다.

               NEWT Design SSOT
                     │
       ┌─────────────┼─────────────┐
       │             │             │
      UI           Brand       UX Writing
       │             │             │
       └─────────────┼─────────────┘
                     │
                     MCP
                     │
             AI / Claude Code
                     │
       ┌─────────────┼─────────────┐
       │             │             │
      App            LP           Ads

---

이 글에서 가장 중요한 구조

제가 이 글을 시스템 관점에서 압축하면 다음과 같습니다.

                Designer Brain
                     │
                     ▼
           ┌───────────────────┐
           │ Design Knowledge │
           └───────────────────┘
                     │
       ┌─────────────┼─────────────┐
       │             │             │
    Tokens       Components     Principles
       │             │             │
   UX Writing     Contracts     Checklist
       │             │             │
       └─────────────┼─────────────┘
                     │
                    MCP
                     │
                     ▼
                Claude Code
                     │
                     ▼
                 SKILL.md
                     │
                     ▼
             Design Workflow
                     │
         ┌───────────┼───────────┐
         │           │           │
      Research     Design      Review Doc
         │           │           │
         └───────────┼───────────┘
                     ▼
               Vercel Preview
                     │
                     ▼
               Designer Review
                     │
                     ▼
                   Merge
                     │
                     ▼
              Design SSOT 갱신

---

특히 주목할 만한 7가지

이 글의 핵심은 Claude Code로 UI를 만든다는 것 자체가 아닙니다.

진짜 중요한 것은 다음 7가지입니다.

1. 디자인 시스템을 AI가 읽을 수 있는 형태로 만든다.
2. 실제 서비스와 디자인 Mock이 동일한 UI 컴포넌트를 사용한다.
3. Component Contract로 AI에게 사용법까지 알려준다.
4. MCP로 필요한 디자인 정보만 검색해서 가져온다.
5. SKILL.md로 디자이너의 작업 순서를 강제한다.
6. Designer Principles와 Checklist를 파일로 명문화한다.
7. 승인된 결과를 다시 SSOT에 넣어 다음 AI가 사용하게 한다.

---

일반적인 AI UI 생성과 차이

일반적인 AI UI 제작NEWT 방식

프롬프트 → 화면	PRD → 조사 → 분석 → 여러 안 → 추천
AI가 임의 UI 생성	Design System 기반
임의 CSS	Design Token
비슷한 버튼 새로 생성	실제 Button Component 사용
결과 이미지 중심	작동하는 TSX
맥락 없음	PRD + 조사 + 설계 근거
AI 출력 후 종료	Designer Review
결과가 사라짐	승인 결과 SSOT 편입
Figma가 Master	코드 기반 Design System이 Master

---

이 시스템을 한 단계 더 추상화하면

사실 이것은 단순한 AI Design System보다 더 큰 개념입니다.

Design System
+
RAG
+
MCP
+
Agent Skill
+
Workflow
+
Code Component
+
Human Review
+
Git
+
CI/CD

를 합친 구조입니다.

저라면 이것을

Design Engineering Agent System

또는

AI-Native Design Operating System

이라고 볼 수 있습니다.

가장 중요한 철학은 이것입니다.

좋은 프롬프트를 만드는 것
        X

좋은 디자인을 반복해서 만들 수 있는
환경을 만드는 것
        O

그리고 글 마지막의 메시지도 사실 여기에 있습니다.

디자이너가 한 화면을 잘 디자인하면 한 화면만 좋아지지만, 디자인 판단 기준 하나를 시스템에 추가하면 모든 팀의 AI 출력이 동시에 좋아진다.

이게 이 방식에서 가장 큰 레버리지입니다.