Claude를 디자인에 쓰는 방법이 달라졌습니다.
예전에는 “이 화면 어때?”라고 묻고 긴 피드백을 받는 정도였습니다. 지금은 조금 더 실무에 가깝게 쓸 수 있습니다. 화면을 보고 리뷰합니다. 복잡한 요구사항을 UI 플로우로 정리합니다. 컴포넌트 스펙을 씁니다. 프론트엔드 코드 초안도 만듭니다. 필요하면 Claude Code로 실제 코드베이스를 읽고 수정까지 합니다.
다만 중요한 전제가 있습니다.
Claude가 디자이너를 대체한다는 말은 아닙니다. 좋은 디자인은 여전히 사람이 정합니다. 문제 정의, 우선순위, 브랜드 감각, 사용자의 맥락은 사람이 잡아야 합니다. Claude는 그 사이의 반복 작업을 줄이는 도구에 가깝습니다.
이 글은 Claude 최신 모델과 공식 기능을 바탕으로, 디자이너와 프론트엔드 개발자가 바로 따라 할 수 있는 작업법을 정리한 글입니다. 루머는 제외했습니다. Anthropic 공식 릴리즈와 도움말 문서에서 확인되는 기능만 다룹니다.
현재 디자인 작업에 특히 중요한 변화는 네 가지입니다.
Claude Opus 4.7
Claude Sonnet 4.6
Artifacts와 Custom visuals
Claude Code와 Computer Use
핵심은 간단합니다.
Claude에게 “예쁘게 해줘”라고 말하면 결과가 흔들립니다.
좋은 결과를 얻으려면 입력을 좁혀야 합니다. 디자인 작업은 취향 싸움처럼 보이지만, 실제로는 제약 조건의 싸움입니다.
Claude에게 꼭 줘야 하는 정보는 아래 7개입니다.
사용자
상황
목표 행동
비즈니스 목표
브랜드 톤
기술 제약
판단 기준
이 7개를 주면 Claude는 단순 감상이 아니라 작업 가능한 답을 냅니다.
디자인을 바로 시키기 전에 브리프를 먼저 만드세요.
브리프는 길 필요가 없습니다. 한 화면이라면 10줄이면 됩니다. 브리프가 있으면 Claude의 답이 덜 흔들립니다. 팀원끼리 말도 빨라집니다.
아래 템플릿을 그대로 쓰면 됩니다.
너는 제품 디자이너이자 프론트엔드 리뷰어야.
아래 정보를 바탕으로 화면 설계 브리프를 만들어줘.
[제품]
- 이름:
- 한 줄 설명:
[사용자]
- 주요 사용자:
- 사용자의 현재 문제:
- 사용자가 이미 알고 있는 것:
- 사용자가 모르는 것:
[화면]
- 화면 이름:
- 사용자가 이 화면에 들어오는 경로:
- 이 화면에서 반드시 해야 하는 행동:
- 보조 행동:
[비즈니스 목표]
- 가장 중요한 지표:
- 피해야 할 결과:
[제약]
- 플랫폼:
- 디자인 시스템:
- 개발 스택:
- 반드시 유지할 요소:
[결과 형식]
1. 화면의 역할
2. 사용자 흐름
3. 정보 우선순위
4. 섹션 구성
5. CTA 문구 후보 5개
6. 리스크 5개
7. 빠르게 검증할 실험 3개
여기서 중요한 부분은 “리스크”와 “검증할 실험”입니다.
디자인은 보기 좋은지만 보면 안 됩니다. 이 화면이 정말 문제를 푸는지 봐야 합니다. 사용자가 헷갈리는지, CTA가 너무 빠른지, 가격 정보를 숨겨서 신뢰를 잃는지, 핵심 가치가 첫 화면에서 보이는지 확인해야 합니다.
좋은 UI 기획은 “무엇을 보여줄까?”보다 “무엇을 먼저 믿게 만들까?”에 가깝습니다.
디자인 리뷰를 시킬 때는 한 번에 “전체 평가”를 요구하지 않는 편이 좋습니다.
전체 평가를 시키면 답이 넓어집니다. 대신 레이어를 나눠서 봐야 합니다.
추천 순서는 아래와 같습니다.
아래 프롬프트를 쓰면 됩니다.
이 화면을 제품 관점과 프론트엔드 구현 관점에서 리뷰해줘.
칭찬보다 수정점을 우선해줘.
모호한 말은 피하고, 바로 고칠 수 있는 액션으로 써줘.
[화면 설명 또는 이미지]
- 화면 목적:
- 주요 사용자:
- 목표 행동:
- 현재 걱정되는 점:
[리뷰 기준]
1. 사용자가 3초 안에 이 화면의 목적을 이해하는가?
2. 가장 중요한 행동이 눈에 띄는가?
3. 정보 순서가 사용자의 의사결정 순서와 맞는가?
4. 불필요한 요소가 핵심 행동을 방해하는가?
5. 신뢰를 만드는 정보가 충분한가?
6. 모바일에서 터치하기 쉬운가?
7. 색상, 대비, 폰트 크기에서 접근성 문제가 있는가?
8. 프론트엔드에서 구현 비용이 큰 부분은 무엇인가?
9. 디자인 시스템 컴포넌트로 대체할 수 있는 부분은 무엇인가?
10. A/B 테스트를 한다면 어떤 가설로 나눌 수 있는가?
[출력 형식]
- 총평 3줄
- 심각도 높은 문제 5개
- 빠른 수정안 5개
- 시간이 있으면 할 개선 5개
- 개발자에게 넘길 메모
리뷰 결과를 받을 때는 “왜?”를 한 번 더 물어보세요.
위 리뷰에서 가장 중요한 문제 3개만 골라줘.
각 문제에 대해 아래 형식으로 다시 써줘.
1. 문제가 되는 이유
2. 실제 사용자가 겪을 상황
3. 수정 전/후 차이
4. 성공 여부를 측정할 지표
이 과정이 중요합니다.
Claude는 그럴듯한 수정안을 많이 낼 수 있습니다. 하지만 모든 수정이 같은 가치를 만들지는 않습니다. 실제로는 20개 중 3개만 고쳐도 화면이 좋아지는 경우가 많습니다. 반대로 덜 중요한 디테일만 고치면 예뻐 보이지만 성과는 그대로입니다.
많은 팀이 Claude에게 이렇게 말합니다.
온보딩 화면 만들어줘.
이러면 보통 평범한 3단계 온보딩이 나옵니다.
더 좋은 방법은 사용자의 의사결정 흐름을 먼저 만들게 하는 것입니다.
아래 제품의 온보딩을 설계해줘.
화면 목록부터 만들지 말고, 사용자가 가입을 결정하기까지 필요한 의사결정 흐름을 먼저 정리해줘.
[제품 설명]
- 제품:
- 타깃:
- 사용자가 얻는 가치:
- 사용자가 걱정할 점:
- 경쟁 대안:
[원하는 결과]
1. 사용자가 처음 가진 의심 5개
2. 각 의심을 줄이는 정보
3. 정보를 보여줄 순서
4. 각 단계의 CTA
5. 최소 화면 수
6. 버려도 되는 화면
7. 첫 버전에서 꼭 측정할 이벤트
이 프롬프트의 장점은 분명합니다.
특히 초기 제품은 화면을 많이 만들수록 느려집니다. 처음부터 풀 패키지로 만들 필요가 없습니다. 사용자가 결정을 내리는 데 필요한 최소 정보만 보여주는 편이 낫습니다.
Artifacts는 Claude가 만든 결과물을 별도 작업 화면으로 보여주는 기능입니다. 공식 도움말에 따르면 생성한 Artifacts를 공개 링크로 배포하거나, 팀 계정에서는 조직 안에서 공유할 수 있습니다. 다른 사람이 만든 Artifact를 Customize해서 자기 버전으로 수정할 수도 있습니다.
디자인 작업에서는 세 가지에 특히 좋습니다.
예를 들어 SaaS 가격 페이지를 만든다면 이렇게 시킬 수 있습니다.
Claude Artifact로 볼 수 있는 가격 페이지 프로토타입을 만들어줘.
HTML/CSS/JS 한 파일로 구현해줘.
[제품]
- 제품명: B2B 리포트 자동화 도구
- 타깃: 10~100명 규모 스타트업 운영팀
- 핵심 가치: 반복 리포트 작성 시간을 줄임
[페이지 목표]
- 무료 상담 신청 클릭
- 가격 구조 이해
- 도입 리스크 감소
[구성]
1. Hero
2. 문제 제기
3. 요금제 3개
4. 비교표
5. 보안/신뢰 섹션
6. FAQ
7. 하단 CTA
[디자인 톤]
- 깔끔함
- B2B SaaS 느낌
- 과한 그라디언트 금지
- 모바일 우선
[요구]
- 실제 텍스트를 넣어줘
- CTA 문구를 3개 테스트할 수 있게 만들어줘
- 가격 카드 hover 상태를 넣어줘
- 접근성 대비를 신경 써줘
Artifacts를 쓸 때 주의할 점도 있습니다.
Artifacts는 “최종 산출물”보다 “빠른 대화용 시안”에 가깝습니다.
회의에서 말로 싸우는 시간을 줄이는 데 좋습니다. “이런 느낌입니다”를 10분 안에 보여줄 수 있습니다. 그 다음에 버릴 건 버리고, 살릴 것만 컴포넌트 스펙으로 바꾸면 됩니다.
Anthropic 도움말에 따르면 Custom visuals는 Claude가 대화 안에서 다이어그램, 차트, 인터랙티브 시각화를 만드는 베타 기능입니다. HTML로 만들어지며, 필요하면 SVG나 HTML로 다운로드하거나 Artifact로 저장할 수 있습니다.
이 기능은 예쁜 UI보다 생각 정리에 좋습니다.
추천 용도는 아래와 같습니다.
프롬프트는 짧아도 됩니다.
아래 온보딩 흐름을 다이어그램으로 보여줘.
각 단계마다 사용자의 의심, 필요한 정보, CTA를 함께 표시해줘.
[흐름]
1. 랜딩 페이지 방문
2. 문제 공감
3. 샘플 리포트 확인
4. 가격 확인
5. 무료 상담 신청
6. 도입 가능성 확인
[요구]
- 단계 사이의 이탈 리스크를 표시해줘
- 가장 위험한 단계는 빨간색으로 보여줘
- 줄일 수 있는 화면은 점선으로 표시해줘
좋은 점은 대화하면서 계속 바꿀 수 있다는 것입니다.
3단계와 4단계 순서를 바꿔줘.
가격을 먼저 보여주면 생기는 장단점도 옆에 붙여줘.
이렇게 쓰면 기획 회의가 빨라집니다. 말로만 논의하면 각자 다른 그림을 상상합니다. 시각화가 있으면 같은 그림을 보고 이야기할 수 있습니다.
디자인과 개발 사이에서 가장 많이 새는 부분은 컴포넌트 스펙입니다.
Figma에는 예쁜 버튼이 있습니다. 하지만 개발자는 이런 질문을 합니다.
이 질문을 미리 정리하면 개발 속도가 빨라집니다.
아래는 Claude에게 컴포넌트 스펙을 만들게 하는 프롬프트입니다.
아래 UI 요소를 프론트엔드 개발자가 바로 구현할 수 있는 컴포넌트 스펙으로 정리해줘.
디자인 문서 말투가 아니라 실제 작업 티켓처럼 써줘.
[컴포넌트]
- 이름: PricingCard
- 용도: 요금제 1개를 보여주는 카드
- 사용 위치: 가격 페이지, 결제 모달
- 플랫폼: Next.js + React + Tailwind
- 디자인 시스템: shadcn/ui 기반
[필수 정보]
- 요금제 이름
- 가격
- 설명
- 기능 목록
- 추천 여부
- CTA
[출력 형식]
1. 컴포넌트 역할
2. Props 타입
3. 상태 목록
4. 반응형 규칙
5. 접근성 규칙
6. 에러/엣지 케이스
7. Tailwind 스타일 가이드
8. 테스트 케이스
9. Storybook stories
10. 개발자에게 확인할 질문
예상 결과는 이런 식이어야 합니다.
export type PricingCardProps = {
planName: string;
price: string;
description: string;
features: string[];
highlighted?: boolean;
ctaLabel: string;
onCtaClick: () => void;
disabled?: boolean;
loading?: boolean;
};
상태는 최소한 아래를 포함해야 합니다.
테스트 케이스도 같이 받아야 합니다.
PricingCard 테스트 케이스를 작성해줘.
단위 테스트와 시각 테스트를 나눠줘.
실패하면 실제로 어떤 문제가 생기는지도 적어줘.
이렇게 하면 디자인 산출물이 개발 티켓으로 바로 이어집니다.
Claude에게 프론트엔드 코드를 시킬 때 흔한 실수가 있습니다.
“이 페이지 코드 짜줘”라고 하는 것입니다.
초안에는 좋지만 실제 제품에는 부족합니다. 실무에서는 코드보다 검증 가능한 패치가 중요합니다.
Claude Code를 쓸 때는 이렇게 시키는 편이 좋습니다.
이 코드베이스에서 가격 페이지를 개선해줘.
먼저 파일 구조와 디자인 시스템을 읽고, 바로 수정하지 말고 계획을 제안해줘.
[목표]
- 가격 정보를 더 빨리 이해하게 만들기
- 모바일에서 CTA 노출 개선
- 기존 디자인 시스템 유지
- 새 라이브러리 추가 금지
[작업 범위]
1. 관련 파일 찾기
2. 현재 컴포넌트 구조 요약
3. 변경 계획 제안
4. 내가 승인하면 코드 수정
5. 타입체크 또는 테스트 실행
6. 변경 전/후 요약
[주의]
- 기존 스타일 토큰 우선 사용
- 중복 컴포넌트 생성 금지
- 하드코딩 최소화
- 접근성 속성 확인
이 프롬프트에는 중요한 장치가 있습니다.
Claude Code는 강력하지만, 아무 제약 없이 쓰면 코드가 늘어날 수 있습니다. 특히 프론트엔드는 “보기에는 맞는데 구조가 나쁜 코드”가 생기기 쉽습니다.
따라서 산출물은 아래 5개로 받는 것이 좋습니다.
Computer Use는 Claude가 화면을 보고 마우스와 키보드를 조작하는 기능입니다. 공식 문서 기준 베타이며, 스크린샷 캡처, 마우스 제어, 키보드 입력, 데스크톱 자동화를 제공합니다.
디자인 쪽에서는 이런 작업에 쓸 수 있습니다.
하지만 조심해야 합니다.
Anthropic 공식 문서도 Computer Use의 위험을 분명히 말합니다. 인터넷과 함께 쓸 때 프롬프트 인젝션 위험이 있습니다. 웹페이지나 이미지 안에 숨어 있는 지시를 모델이 따를 수 있습니다. 그래서 중요한 행동은 사람이 확인해야 합니다.
실무 규칙은 이렇게 잡는 것을 추천합니다.
Computer Use는 “자동 운영자”가 아니라 “눈과 손이 있는 QA 보조자”로 보는 편이 안전합니다.
아래 체크리스트를 Claude에게 그대로 붙여넣고 리뷰 기준으로 쓰면 됩니다.
아래 체크리스트로 화면을 리뷰해줘.
각 항목은 OK / 문제 있음 / 확인 필요 중 하나로 표시해줘.
문제가 있으면 수정안을 1개만 제안해줘.
[목적]
1. 화면의 목적이 3초 안에 보이는가?
2. 사용자의 다음 행동이 명확한가?
3. 한 화면에 목표가 너무 많지 않은가?
[정보 구조]
4. 가장 중요한 정보가 위에 있는가?
5. 사용자의 의사결정 순서와 정보 순서가 맞는가?
6. 비슷한 정보가 흩어져 있지 않은가?
[전환]
7. CTA가 한눈에 보이는가?
8. CTA 문구가 행동 중심인가?
9. 사용자가 클릭 전에 필요한 신뢰 정보가 있는가?
[시각]
10. 제목, 본문, 보조 정보의 위계가 분명한가?
11. 색상이 의미 없이 많지 않은가?
12. 여백이 섹션 구분에 도움을 주는가?
[접근성]
13. 텍스트 대비가 충분한가?
14. 터치 영역이 충분한가?
15. 키보드 포커스 상태가 있는가?
16. 아이콘만 있는 버튼에 라벨이 있는가?
[개발]
17. 기존 컴포넌트로 만들 수 있는가?
18. 새 상태가 과하게 늘어나지 않는가?
19. 반응형 규칙이 명확한가?
20. 빈 상태, 에러 상태, 로딩 상태가 정의됐는가?
이 체크리스트의 목적은 완벽한 평가가 아닙니다. 놓치는 부분을 줄이는 것입니다.
하나의 랜딩 페이지를 만든다고 가정해봅시다.
가장 효율적인 순서는 아래와 같습니다.
이 흐름의 장점은 명확합니다.
디자인은 결국 성과를 내야 합니다. 예쁜 화면만으로는 부족합니다. 사용자가 이해하고, 믿고, 행동해야 합니다.
아래 프롬프트 하나로 시작해도 됩니다.
너는 제품 디자이너, UX 리서처, 프론트엔드 리드 역할을 함께 맡아줘.
목표는 예쁜 화면이 아니라 사용자가 행동하는 화면을 만드는 거야.
[제품]
- 이름:
- 한 줄 설명:
- 타깃 사용자:
- 핵심 가치:
- 경쟁 대안:
[이번 작업]
- 만들 화면:
- 목표 행동:
- 가장 중요한 지표:
- 피해야 할 것:
[제약]
- 플랫폼:
- 개발 스택:
- 디자인 시스템:
- 반드시 유지할 요소:
- 새로 만들면 안 되는 것:
[작업 순서]
1. 사용자의 의사결정 흐름 정리
2. 화면 정보 구조 제안
3. 섹션별 카피 초안 작성
4. 디자인 리스크 5개 제시
5. 전환율 관점 수정안 제시
6. 컴포넌트 목록 작성
7. 핵심 컴포넌트 1개의 Props 스펙 작성
8. 접근성 체크리스트 작성
9. 개발 작업 티켓으로 변환
10. 출시 후 측정 이벤트 제안
[출력 규칙]
- 짧은 문장으로 써줘
- 번호 리스트 중심으로 써줘
- 모호한 표현 금지
- 바로 실행 가능한 액션으로 써줘
- 구현 비용이 큰 제안은 따로 표시해줘
이 프롬프트는 한 번에 끝내기 위한 것이 아닙니다. 첫 답을 받은 뒤, 꼭 줄이세요.
좋아. 여기서 MVP에 꼭 필요한 것만 남겨줘.
개발 3일 안에 만들 수 있는 범위로 줄여줘.
버릴 기능과 남길 기능을 표로 정리해줘.
초기 제품에서는 이 질문이 중요합니다. 좋은 아이디어도 너무 크게 만들면 출시가 늦어집니다. Claude는 많은 것을 제안합니다. 사람은 줄여야 합니다.
Claude를 팀에 붙일 때는 역할을 분리하는 것이 좋습니다.
기획 검증 모드
포지셔닝 모드
구현 모드
같은 Claude라도 한 대화에서 세 역할을 섞으면 답이 흐려집니다. 먼저 검증하고, 그 다음 메시지를 다듬고, 마지막에 구현으로 넘기는 편이 낫습니다.
디자인 작업에서 가장 위험한 말은 “좋아 보인다”입니다. 좋아 보이는 것과 팔리는 것은 다릅니다. 좋아 보이는 것과 만들기 쉬운 것도 다릅니다. 그래서 Claude에게도 계속 물어야 합니다.
이 제안이 실제 전환에 도움이 된다는 근거가 약한 부분은 어디야?
이 디자인을 만들었을 때 개발 비용이 가장 큰 부분은 어디야?
사용자가 돈을 내기 전에 꼭 봐야 하는 정보는 무엇이고, 지금 빠진 것은 뭐야?
이 질문들이 디자인을 더 현실적으로 만듭니다.
Claude를 한 명의 디자이너처럼 쓰면 결과가 제한됩니다.
더 좋은 방식은 작은 디자인 팀처럼 쓰는 것입니다.
이 흐름을 쓰면 Claude는 단순한 답변 도구가 아닙니다. 기획, 리뷰, 문서화, 구현 사이의 빈틈을 줄이는 작업 파트너가 됩니다.
오늘 바로 해볼 일은 하나입니다.
지금 만들고 있는 화면 하나를 고르세요. 그리고 Claude에게 “예쁘게 해줘”가 아니라 아래처럼 시켜보세요.
이 화면이 사용자의 어떤 의사결정을 도와야 하는지 먼저 정리해줘.
그 다음 정보 구조, CTA, 컴포넌트 스펙, 출시 후 측정 이벤트까지 이어서 만들어줘.
이 한 문장만 바꿔도 결과가 달라집니다.
좋은 디자인은 감으로 끝나지 않습니다. 설명할 수 있어야 합니다. 만들 수 있어야 합니다. 측정할 수 있어야 합니다. Claude는 그 세 가지를 연결하는 데 가장 쓸모가 있습니다.