신입 디자이너의 AI 출근 키트| 클로드 코드로 ‘디자인 에이전트 팀’ 만들기
주니어 디자이너의 반복 업무를 줄이고 판단에 집중하는 AI 실무 워크플로를 소개합니다.
신입 디자이너에게 필요한 AI 활용 능력은 이제 ‘이미지를 빨리 만드는 법’에서 끝나지 않습니다.
AI를 통해 개인이 할 수 있는 영역이 넓어짐에 따라 이제 주니어에게도 경력직에 준하는 성과를 기대하기 때문이죠. 입사 직후부터 실제 제품 기능을 개선하는 업무에 바로 투입될 수 있습니다.
문제는 이 과정에서 실제 화면을 디자인하는 시간보다 자료를 찾고, 정리하고, 반복해서 확인하는 시간이 더 길어질 수 있다는 점입니다. 그래서 AI를 하나의 만능 챗봇으로 사용하는 것보다, 실제 제품팀처럼 역할을 나누는 편이 낫습니다.
이번 글에서는 리서치부터 프로토타이핑, QA까지 반복되는 업무를 AI에 나눠 맡길 수 있도록, 클로드 코드(Claude Code)로 디자인 에이전트 팀을 세팅하고 실제 업무에 적용하는 방법을 정리합니다.
클로드 코드로 ‘디자인 에이전트 팀’ 만들기
| 에이전트 역할 | AI에게 맡길 일 | 직접 판단할 일 |
|---|---|---|
| 리서치 에이전트 | • 퍼널 데이터 탐색 • VOC·인터뷰 내용 분류 • 경쟁 서비스 패턴 조사 • 사실과 가설 분리 • 디자인 가설 초안 작성 |
• 실제 해결할 문제 • 문제의 우선순위 • 추가 검증 방법 • 어떤 가설을 채택할지 |
| 카피 에이전트 | • 화면 상태 목록 작성 • UX 카피 후보 생성 • 오류·빈 화면·도움말 문구 작성 • 제품 내 표현 일관성 점검 |
• 브랜드 맥락 • 정보 위계 • 최종 문구 |
| 프로토타입 에이전트 | • 인터랙션 구현 • 여러 UX 안 빠르게 제작 • 오류·로딩·완료 상태 구현 |
• 어떤 경험이 더 적절한지 • 무엇을 사용자에게 검증할지 • 최종 UX 방향 |
| QA 에이전트 | • 누락 화면 탐색 • 예외 케이스 검수 • 디자인 시스템 위반 확인 • 화면·카피 불일치 발견 • 접근성 체크 항목 점검 |
• 문제의 영향도 • 수정 우선순위 • 출시 가능한 품질인지 |
1.가장 먼저 프로젝트 맥락을 세팅한다
에이전트의 결과물을 가장 크게 좌우하는 것은 프롬프트 한 줄이 아니라 제품과 조직에 대한 맥락입니다.
예를 들어 입사 후 신규 회원 온보딩 개선 업무를 맡았다고 해보겠습니다.
먼저 클로드 코드가 접근할 프로젝트 폴더부터 다음처럼 만들어봅니다.
design-project/
├─ CLAUDE.md
├─ context/
│ ├─ product.md
│ ├─ target-user.md
│ ├─ design-system.md
│ └─ brand-voice.md
├─ input/
│ ├─ prd.md
│ ├─ funnel-data.csv
│ ├─ voc.csv
│ └─ current-flow.md
├─ research/
├─ copy/
├─ qa/
└─ output/
실무에서는 반드시 파일 형태일 필요는 없습니다.
Amplitude나 GA4에서 확인한 퍼널 데이터, VOC·CS 티켓, 사용자 인터뷰 노트, PRD, 기존 Figma 화면, Jira·Linear 이슈 등을 현재 조직에서 접근 가능한 방식으로 연결하면 됩니다.
CLAUDE.md에는 프로젝트 전체에서 모든 에이전트가 지켜야 할 공통 원칙을 넣습니다. 예를 들면 이렇습니다.
# Project Rules
- 현재 목표는 신규 가입자의 온보딩 완료율 개선이다.
- 확인되지 않은 내용을 사실처럼 단정하지 않는다.
- 데이터로 확인된 사실과 AI가 만든 가설을 구분한다.
- 기존 디자인 시스템의 컴포넌트와 변수를 우선 사용한다.
- 기존 컴포넌트로 해결하기 어렵다면 새 컴포넌트를 만들기 전에 이유와 대안을 제시한다.
- 수정안을 제안하기 전에 문제와 근거부터 정리한다.
이렇게 해두면 매번 “추측하지 마”, “디자인 시스템을 지켜줘”라고 반복할 필요가 없어집니다.
단, 고객 데이터나 사내 정보를 AI에 입력하기 전에는 반드시 회사의 AI 사용 정책을 확인해야 합니다. 필요한 경우 개인정보를 제거하거나 데이터를 비식별화한 뒤 사용합니다.
2.리서치 에이전트에게 판단의 재료를 만들게 한다
가장 먼저 만들 에이전트는 ‘리서처’입니다.
여기서 가장 흔한 실수가 있습니다. 이렇게 요청하는 것입니다.
경쟁사 온보딩 UX 조사해줘.
이렇게 요청하면 보기 좋은 경쟁사 레퍼런스는 많이 나오지만 정작 실제 디자인 결정에는 별 도움이 되지 않을 수 있습니다.
리서치 에이전트의 목표는 레퍼런스를 모으는 것이 아니라 디자이너가 의사결정을 내릴 수 있는 증거를 정리하는 것이어야 합니다.
따라서 리서치 에이전트에게는 데이터에서 확인된 사실, 사용자 의견, 경쟁사 패턴, 아직 검증되지 않은 가설을 분리해서 정리하도록 해야 합니다.
예를 들어 에이전트의 역할을 다음처럼 정의합니다.
너는 프로덕트 디자이너를 돕는 UX 리서처다.
목표:
온보딩 과정에서 이탈이 발생하는 구간을 찾고, 가능한 원인에 대한 가설을 만든다.
입력:
- PRD
- 퍼널 데이터
- VOC
- 사용자 인터뷰
- 현재 사용자 플로우
- 경쟁 서비스 자료
해야 할 일:
1. 퍼널에서 이탈이 큰 구간을 찾는다.
2. VOC와 인터뷰에서 반복되는 불편을 분류한다.
3. 경쟁 서비스의 해결 패턴을 정리한다.
4. 데이터로 확인된 사실과 추론을 구분한다.
5. 디자인 가설을 최대 5개 만든다.
출력:
발견 내용 / 근거 / 근거 유형 /
디자인 시사점 / 추가 검증 필요 여부
결과는 이런 식으로 정리할 수 있습니다.
| 발견 내용 | 근거 | 근거 유형 | 디자인 시사점 | 추가 검증 |
|---|---|---|---|---|
| 프로필 입력 단계에서 이탈이 높음 | 해당 단계 이탈률 증가 | 정량 데이터 | 필수 입력 범위 검토 | 불필요 |
| 입력 목적을 이해하기 어렵다는 의견 반복 | CS·인터뷰 | 정성 데이터 | 정보 요청 이유 설명 검토 | 필요 |
| 단계가 많아 부담일 가능성 | 직접 근거 없음 | 가설 | 단계 축소안 검토 | 필요 |
이렇게 하면 AI가 ‘정답’을 말하는 대신 디자이너가 판단할 후보를 압축해서 가져오는 역할을 하게 됩니다. 중요한 것은 AI가 문제의 원인을 확정하지 않게 하는 것입니다.
퍼널에서 이탈이 높다는 것은 사실일 수 있지만, “입력 항목이 많아서 이탈했다”는 것은 아직 가설입니다. 따라서 에이전트가 “프로필 입력을 줄이자”고 제안하더라도, 해당 정보가 비즈니스상 반드시 필요한지, 다른 단계로 옮길 수 있는지 판단하는 것은 디자이너의 역할입니다. AI는 문제 후보를 찾고, 디자이너가 실제로 해결할 문제를 선택하는 구조를 가져가야 합니다.
3.카피 에이전트는 화면 상태 전체를 관리하게 한다
다음은 UX 카피 에이전트입니다.
주니어 단계에서는 보통 완성된 화면을 AI에게 보여주고, “버튼 문구 추천해줘”라고 요청합니다. 하지만 여기서 한 단계 더 나아가, 카피 에이전트에게 화면 단위가 아니라 사용자 상태 전체를 먼저 정의하게 하는 방식이 실무에서는 훨씬 유용합니다.
예를 들어 프로필 등록 화면이라면, 정상 화면만 존재하는 게 아닙니다.
- 최초 진입
- 입력 중
- 필수값 누락
- 잘못된 입력 형식
- 저장 중
- 서버 오류
- 저장 완료
- 기존 정보 존재
- 권한 부족
AI에게 전체 사용자 상태를 먼저 정리하게 하고, 각각 필요한 문구를 작성하게 합니다.
각 화면의 UX 카피를 작성하기 전에
누락된 사용자 상태가 없는지 먼저 점검한다.
각 상태마다 다음을 작성한다.
- 화면
- 사용자 상태
- 사용자 목표
- 제목
- 설명
- CTA
- 오류 메시지
- 도움말
제약:
- 같은 행동에는 같은 표현을 사용한다.
- CTA는 사용자의 다음 행동이 명확해야 한다.
- 오류 메시지에는 가능한 경우 원인과 다음 행동을 함께 제공한다.
- 되돌릴 수 없는 행동에는 확인 문구를 검토한다.
- brand-voice.md의 문체를 따른다.
결과는 화면별 카피표(copy/content-matrix.csv)로 저장하게 하면 화면을 수정할 때마다 UX 카피를 다시 찾아다닐 필요도 없습니다.
카피 에이전트의 중요한 역할은 멋진 문장을 만드는 것이 아니라, 빠진 화면 상태를 찾고 제품 전체의 표현이 일관적인지 검토하는 것입니다.
최종 문구는 브랜드 톤, 정보 위계, 앞뒤 화면의 맥락을 확인해 디자이너가 판단하여 결정합니다.
4. 클로드 코드로 실제 동작하는 프로토타입을 만든다
디자인 방향이 정해졌다면 클로드 코드에게 기존 코드베이스와 디자인 시스템을 참고해 실제로 클릭 가능한 프로토타입을 먼저 만들 게 하면 좋습니다.
예를 들어 이렇게 요청합니다.
현재 온보딩 플로우를 기준으로 두 가지 안을 구현한다.
A안: 단계형 진행 방식
B안: 필요한 정보를 순차적으로 보여주는 방식
조건:
- 기존 디자인 시스템의 Button, Input, Progress 컴포넌트를 우선 사용한다.
- 기존 컴포넌트로 해결하기 어려우면 새로 만들기 전에 이유를 제시한다.
- 모바일 375px을 기준으로 한다.
- 기본 / 오류 / 로딩 / 완료 상태를 포함한다.
- 두 안의 UX 차이도 함께 정리한다.
정적인 화면만 비교할 때보다 실제로 버튼을 눌러보고 다음 단계로 이동해보면 플로우의 문제를 훨씬 빨리 발견할 수 있습니다.
Figma MCP와 필요한 디자인 파일·코드 접근 권한까지 연결되어 있다면, 에이전트가 Figma의 컴포넌트·변수·화면 구조 같은 디자인 맥락을 참고하도록 할 수도 있습니다.
최근에는 코드에서 만든 인터페이스를 다시 편집 가능한 Figma 디자인으로 가져오는 워크플로도 지원되고 있습니다.
즉, [Figma → Claude Code → 동작하는 UI → 다시 Figma에서 검토]처럼, 디자인과 구현을 왕복하는 업무 방식도 가능합니다.
다만 여기서 중요한 것은 ‘AI가 대신 디자인해준다’가 아닙니다. A안과 B안 중 어떤 경험이 더 적절한지, 어떤 안을 실제 사용자에게 검증할지는 여전히 디자이너가 결정해야 합니다.
5.QA 에이전트에게 제품 전체 흐름을 검수시킨다
디자인 QA도 단순히 “이 화면에 문제 있어?”라고 묻는 것보다 검수 기준을 먼저 정의해야 더 수준 높은 결과를 얻을 수 있습니다.
QA 에이전트에는 디자인 파일뿐 아니라 PRD, 디자인 시스템, 화면별 카피표, 구현된 프로토타입까지 함께 보게 합니다.
그리고 다섯 가지 관점으로 나눠 검토시킵니다.
① 화면 상태 누락
정상 상태만 디자인하고 끝나지 않았는지 확인합니다.
- 로딩
- 빈 화면
- 오류
- 비활성화
- 권한 없음
- 오프라인
- 재시도
- 완료
② 플로우 일관성
사용자가 이전 화면으로 돌아가거나, 중간에 이탈하거나, 이미 완료한 사용자가 재진입했을 때도 흐름이 자연스러운지 확인합니다.
③ 디자인 시스템
- 기존 컴포넌트를 올바르게 사용했는가?
- 동일한 기능에 서로 다른 패턴을 사용하지 않았는가?
- 변수·간격·타이포그래피 규칙과 어긋난 부분은 없는가?
④ 카피 일관성
같은 행동을 한 화면에서는 ‘저장’, 다른 화면에서는 ‘완료’라고 부르는 등 표현이 달라지지 않았는지 확인합니다.
⑤ 접근성
- 텍스트 대비는 충분한가?
- 오류를 색상만으로 구분하지 않는가?
- 버튼과 입력 요소의 라벨이 명확한가?
- 키보드나 스크린 리더 사용 시 문제가 예상되지 않는가?
QA 결과는 단순 지적 목록이 아니라, 다음 형식으로 받는 것이 좋습니다.
문제
영향도
근거
문제가 발생하는 화면
기대 동작
수정 제안
‘영향도’는 예를 들어 이렇게 정의할 수 있습니다.
- P0: 사용자가 주요 플로우를 완료할 수 없음
- P1: 완료 가능하지만 심각한 혼란 발생
- P2: 일관성 또는 사용성 문제
- P3: 개선 제안
그러면 QA 결과 자체를 그대로 개발자와 공유할 수 있는 수준까지 만들 수 있습니다.
특히 Figma MCP처럼 실제 디자인 컨텍스트와 코드 컨텍스트를 함께 활용하는 환경에서는 디자인과 구현 결과를 비교해 누락된 상태나 차이를 찾는 워크플로도 만들 수 있습니다.
6.반복 업무 자동화는 Skill로 만든다
여기까지 매번 긴 프롬프트를 복사해서 사용한다면 아직 자동화가 완성된 것은 아닙니다.
반복되는 업무는 클로드 코드의 Skill이나 역할별 에이전트로 저장해두는 것이 좋습니다.
예를 들면 다음과 같습니다.
.claude/
├─ agents/
│ ├─ ux-researcher.md
│ ├─ ux-writer.md
│ └─ design-qa.md
│
└─ skills/
├─ research-feature/
│ └─ SKILL.md
├─ generate-content-matrix/
│ └─ SKILL.md
└─ review-design/
└─ SKILL.md
새로운 기능을 맡았을 때는 매번 처음부터 업무 방식을 설명하는 대신,
이번 기능의 PRD와 퍼널 데이터를 기준으로 리서치 업무를 실행해줘.
디자인이 완료됐어. 기존 QA 기준에 따라 누락된 화면과 예외 케이스를 검수해줘.
처럼 이미 만들어둔 업무 방식을 재사용할 수 있습니다.
결국 잘 만든 AI 활용법이 개인의 프롬프트 모음에서 끝나는지, 반복 가능한 업무 시스템으로 남는지의 차이는 여기서 생깁니다.
실제 출근하면 이렇게 쓰면 됩니다
예를 들어, 오늘 오전 출근했더니 PM이 디자이너에게 이렇게 요청했다고 해보겠습니다.
“최근 회원가입 완료율이 떨어지고 있어요. 이번 주 안으로 온보딩 개선안을 한번 보고 싶어요.”
예전이라면 경쟁 서비스부터 하나씩 찾아보는 것으로 시작했겠지만, 디자인 에이전트 팀을 세팅했다면 업무 순서는 달라집니다.

디자인 작업 전체를 AI가 대신해준 것은 아니지만, 디자이너가 하루 동안 직접 해야 했던 번거로운 과정 중에, [자료 탐색 → 데이터 정리 → 가설 초안 → 카피 후보 생성 → 예외 케이스 확인 → 반복 QA]를 에이전트에게 넘겼습니다.
그만큼 디자이너는 [문제 정의, 경험 설계, 품질 판단] 등 사람이 내려야 하는 더 중요한 결정에 더 많은 시간을 쓸 수 있게 된 겁니다.
AI를 잘 활용하는 디자이너는 ‘AI에게 무엇이든 시키는 사람’이 아니라, AI에게 맡길 일과 자신이 끝까지 책임져야 할 판단을 구분할 수 있는 디자이너입니다.
AI 에이전트에게 탐색과 실행을 충분히 맡기면서도, 어디서 사람이 개입해야 결과의 품질이 달라지는지 판단할 줄 아는 안목을 기르는 연습을 지금부터 시작해보세요.
결국 그 판단력이 AI 시대 디자이너의 경쟁력이 됩니다.
- AI를 하나의 만능 도구로 쓰기보다 리서처·UX 라이터·프로토타이퍼·QA 담당자로 역할을 나누면 디자인 전후의 반복 업무를 크게 줄일 수 있습니다.
- 클로드 코드에서는 역할별 에이전트와 반복 업무용 Skill을 만들어 리서치부터 검수까지 하나의 업무 흐름으로 운영할 수 있습니다.
- AI에게 맡길 것은 탐색·정리·구현·검수이고, 문제 정의와 우선순위, 최종 디자인 결정은 디자이너가 직접 해야 합니다.