IA부터 사용성 테스트 질문지까지, AI로 UX 업무 흐름을 바꾸는 방법

왜 지금 UI/UX 디자이너의 AI 워크플로우를 봐야 할까

안녕하세요? 오늘 다룰 주제는 UI/UX 디자이너가 Claude Design, Cursor, Codex 같은 AI 도구를 활용해 IA부터 와이어프레임, 클릭 가능한 프로토타입, UX 카피, 사용성 테스트 질문지, 코드 기반 프로토타입까지 이어가는 실무 워크플로우입니다.

이 글의 핵심은 “AI가 디자인을 대신한다”가 아닙니다. 더 정확히 말하면, AI는 분리되어 있던 UX 산출물 사이의 전환 비용을 낮추는 도구에 가깝습니다. IA를 만들고, 사용자 플로우를 정리하고, 와이어프레임을 그리고, 개발자에게 넘기고, 테스트 문서를 따로 만드는 과정은 지금까지 꽤 단절되어 있었습니다.

AI 도구가 바꾸는 지점은 바로 이 단절입니다. 좋은 디자이너는 여전히 문제를 정의하고, 사용자의 맥락을 해석하고, 어떤 경험이 더 나은지 판단해야 합니다. 다만 초안 생성, 대안 탐색, 코드 프로토타입 변환, 테스트 질문지 작성 같은 반복 작업은 훨씬 빠르게 묶을 수 있게 됐습니다.

특히 2~7년 차 UI/UX 디자이너나 프로덕트 디자이너라면 이 변화가 실무 역할에 직접 영향을 줍니다. 앞으로는 Figma 화면을 잘 만드는 능력만큼이나 “AI에게 어떤 기준으로 산출물을 만들게 하고, 어디서 사람의 검토를 넣을 것인가”가 중요해질 가능성이 큽니다.

Claude Design, Cursor, Codex는 각각 무엇을 맡을 수 있을까

먼저 도구의 역할을 분리해서 봐야 합니다. Claude Design은 디자인 초안과 인터랙티브 프로토타입, 슬라이드, 원페이저 같은 시각 산출물 생성에 가깝고, Cursor는 코드베이스 안에서 AI 에이전트와 함께 프론트엔드 구현을 반복하는 개발 환경에 가깝습니다. Codex는 OpenAI가 제공하는 코딩 에이전트로, 코드 읽기·수정·실행·클라우드 작업 위임 등을 지원하는 개발 보조 도구로 설명됩니다.

Claude Design은 Anthropic이 2026년 4월 17일 발표한 Anthropic Labs 제품입니다. 공식 발표에서는 디자인, 프로토타입, 슬라이드, 원페이저 등을 Claude와 협업해 만들 수 있다고 설명했고, Pro, Max, Team, Enterprise 구독자에게 리서치 프리뷰로 제공된다고 밝혔습니다.

Cursor는 2026년 4월 Cursor 3를 소개하며, 에이전트와 함께 소프트웨어를 만들기 위한 통합 워크스페이스를 강조했습니다. Cursor 공식 블로그는 로컬·클라우드 에이전트를 한곳에서 관리하고, 여러 에이전트를 병렬로 실행하며, 데모와 스크린샷으로 결과를 검토하는 흐름을 설명합니다.

Codex는 OpenAI의 공식 제품 페이지에서 “ChatGPT 기반 AI 코딩 파트너”로 소개되며, 기능 구현, 리팩터링, 마이그레이션, 테스트, 문서화 등 실제 엔지니어링 작업을 돕는 코딩 에이전트로 설명됩니다. 공식 문서 기준 IDE 확장은 VS Code뿐 아니라 Cursor, Windsurf 같은 VS Code 호환 에디터에서도 사용할 수 있습니다.

다만 여기서 중요한 주의점이 있습니다. Claude Design, Cursor, Codex를 하나의 묶음으로 쓰는 방식은 이 글에서 제안하는 실무 활용 예시입니다. 현재 확인 가능한 공식 자료 기준으로 “Claude Design에서 Cursor와 Codex까지 한 번에 연결되는 공식 단일 워크플로우”라고 단정하기는 어렵습니다.

Claude Design 발표에서 확인된 핵심 변화

Claude Design의 흥미로운 점은 단순히 예쁜 목업을 만드는 도구가 아니라는 점입니다. Anthropic 공식 발표는 정적 목업을 공유 가능한 인터랙티브 프로토타입으로 바꾸거나, 제품 와이어프레임과 목업을 Claude Code로 넘겨 구현에 활용하는 사례를 제시합니다.

공식 Help Center 문서를 보면 Claude Design은 좌측 채팅 인터페이스와 우측 캔버스를 중심으로 작동합니다. 사용자가 만들고 싶은 것을 설명하면 Claude가 캔버스에 디자인을 생성하고, 이후 채팅과 인라인 코멘트로 반복 수정하는 방식입니다.

또 하나 중요한 기능은 디자인 시스템 반영입니다. Claude Design은 조직의 디자인 시스템을 설정하면 색상, 타이포그래피, 컴포넌트 패턴을 산출물에 반영하도록 설계되어 있습니다. Help Center 문서는 디자인 시스템 설정을 위해 코드베이스, 슬라이드 덱, 브랜드 가이드라인 자산 등을 소스로 활용할 수 있다고 설명합니다.

내보내기와 핸드오프도 핵심입니다. 공식 문서 기준 Claude Design은 PDF, PPTX, Canva, standalone HTML, ZIP 다운로드, Claude Code 핸드오프 등을 지원합니다. 또한 핸드오프 시 디자인 파일, 대화 내용, README, 번들 URL을 포함해 로컬 Claude Code 또는 다른 코딩 에이전트에 전달할 수 있는 프롬프트를 제공하는 방식이 안내되어 있습니다.

이 지점에서 UI/UX 디자이너가 주목해야 할 것은 “디자인 산출물 → 구현 전달”의 간격입니다. 이전에는 와이어프레임, 목업, 프로토타입, 개발 문서가 각각 다른 문서로 존재했습니다. 이제는 디자인 의도, 컴포넌트 선택, 상태 정의, 예외 케이스를 하나의 대화와 번들 안에 남기는 방식이 가능해지고 있습니다.

UX 산출물 자동화가 중요한 진짜 이유

UX 업무에서 시간이 많이 드는 부분은 화면을 한 번 만드는 일만이 아닙니다. 문제 정의가 바뀌면 IA가 바뀌고, IA가 바뀌면 플로우가 바뀌며, 플로우가 바뀌면 와이어프레임과 카피, 테스트 질문지도 함께 바뀝니다. 실무에서는 이 연쇄 수정이 가장 큰 병목이 됩니다.

AI 보조 워크플로우의 가치는 바로 이 반복 수정에 있습니다. 예를 들어 회원가입 온보딩을 개선한다고 해보겠습니다. 기존 방식에서는 리서처가 문제를 정리하고, 디자이너가 플로우를 그리고, 기획자가 카피를 다듬고, 개발자가 프로토타입을 만들고, 다시 사용성 테스트 질문지를 별도로 작성하는 식으로 흘러갑니다.

AI를 잘 쓰면 이 흐름을 하나의 작업 단위로 묶을 수 있습니다. 먼저 Claude Design에 “신규 사용자가 3분 안에 핵심 가치를 이해하도록 온보딩 플로우를 설계해줘”라고 요청합니다. 이후 생성된 플로우를 기준으로 UX 카피를 바꾸고, 테스트 질문지를 만들고, Cursor나 Codex에서 React 기반 프로토타입으로 동작을 확인합니다.

이 방식이 의미 있는 이유는 산출물이 서로 연결되기 때문입니다. 와이어프레임에서 정의한 화면 목적이 UX 카피에 반영되고, UX 카피의 의도가 사용성 테스트 질문으로 이어지며, 테스트에서 발견한 문제는 다시 프롬프트와 컴포넌트 수정으로 돌아옵니다. 결국 AI 자동화의 핵심은 빠른 생성이 아니라 빠른 순환입니다.

OpenAI가 공개한 Simplex 사례도 이 맥락에서 참고할 수 있습니다. Simplex는 ChatGPT Enterprise와 Codex를 활용해 CRUD 기반 웹 애플리케이션 개발을 검증했고, 공개 사례 기준 화면 개발 시간 70%, 화면 디자인 시간 40%, 내부 통합 테스트 시간 17% 감소를 측정했다고 밝혔습니다. 다만 이 수치는 특정 기업의 조건에서 측정된 결과이며, OpenAI 페이지도 AI 생성 결과가 시스템 설정과 입력 데이터에 따라 달라질 수 있다고 명시합니다.

프롬프트에서 코드 프로토타입까지 이어지는 실무 흐름

실무에서 바로 적용해볼 수 있는 흐름은 다음과 같습니다. 먼저 디자이너가 문제 정의와 사용자 맥락을 정리합니다. 그 다음 Claude Design으로 IA, 사용자 플로우, 와이어프레임, 인터랙티브 프로토타입을 생성합니다. 이후 Cursor 또는 Codex로 React 컴포넌트, 상태 처리, 테스트 코드, 접근성 보완을 진행합니다. 마지막으로 디자이너가 UX 카피와 사용성 테스트 질문지를 검토합니다.

첫 단계는 문제 정의입니다. AI에게 바로 “화면 만들어줘”라고 말하기보다, 사용자의 목표, 비즈니스 목표, 제약 조건, 성공 지표를 먼저 줘야 합니다. 예를 들어 “B2B SaaS의 신규 관리자가 첫 로그인 후 팀원을 초대하고 권한을 설정하는 흐름”처럼 맥락을 구체화해야 합니다.

두 번째 단계는 Claude Design에서 구조를 만드는 것입니다. 여기서는 화면의 시각 완성도보다 IA와 사용자 플로우를 먼저 봐야 합니다. Claude Design 공식 튜토리얼도 단일 화면이 아니라 사용자 여정을 설명하면 각 화면을 맥락 속에서 생성할 수 있다고 안내합니다.

세 번째 단계는 코드 기반 프로토타입입니다. Claude Design의 핸드오프 번들을 Claude Code로 넘길 수도 있고, 실무 조합 예시로 Cursor나 Codex에서 React 컴포넌트를 구현하도록 요청할 수도 있습니다. Codex IDE 문서는 Agent 모드에서 파일을 읽고, 명령을 실행하고, 프로젝트 디렉터리 안에서 변경을 쓸 수 있다고 설명합니다.

네 번째 단계는 디자이너 검토입니다. 이때 디자이너는 버튼 색상만 보는 사람이 아니라, 상태 정의가 맞는지, 빈 상태와 오류 상태가 빠지지 않았는지, UX 카피가 사용자의 불안을 줄이는지, 테스트 질문이 유도 질문이 아닌지 확인해야 합니다.

기존 UX 업무 방식과 AI 보조 방식의 차이

이 표에서 중요한 것은 AI 보조 방식이 기존 업무를 없애는 것이 아니라는 점입니다. 오히려 디자이너가 더 명확한 기준을 가져야 AI 결과물을 제대로 걸러낼 수 있습니다. 기준 없이 생성 속도만 높이면, 그럴듯하지만 검증되지 않은 화면이 더 빨리 쌓일 뿐입니다.

바로 써볼 수 있는 프롬프트·산출물·핸드오프 예시

아래 예시는 Claude Design으로 UX 시안과 프로토타입 생성 → Cursor 또는 Codex로 React 컴포넌트·테스트 코드·상태 처리 보완 → 디자이너가 사용성 테스트 질문지와 UX 카피 검토 흐름을 기준으로 한 실무 예시입니다.

프롬프트 예시 1: IA와 사용자 플로우 만들기

산출물 예시

프롬프트 예시 2: Claude Design에서 프로토타입 만들기

Claude Design의 공식 가이드에서도 좋은 프롬프트에는 목표, 레이아웃, 콘텐츠, 대상 사용자가 포함되는 것이 좋다고 설명합니다. 또한 생성 후 채팅과 인라인 코멘트로 구조적 수정과 컴포넌트 단위 수정을 나눠 진행할 수 있습니다.

개발 핸드오프 예시

Codex IDE 문서에 따르면 Codex는 에디터 안에서 파일을 읽고 수정하며 명령을 실행할 수 있고, 더 큰 작업은 클라우드로 위임할 수도 있습니다. 따라서 코드 기반 프로토타입 단계에서는 “화면을 만들어줘”보다 “상태와 테스트 기준을 포함해 구현해줘”처럼 검토 가능한 기준을 함께 주는 것이 좋습니다.

사용성 테스트 질문지 예시

한계와 확인이 필요한 부분

가장 먼저 확인해야 할 부분은 제공 범위입니다. Claude Design은 현재 확인 가능한 공식 자료 기준 리서치 프리뷰이며, Enterprise에서는 기본적으로 꺼져 있고 조직 설정에서 켜야 합니다. 또한 Claude Design은 현재 웹 인터페이스인 claude.ai/design을 통해 제공된다고 Help Center가 안내합니다.

요금과 사용량도 단정하면 안 됩니다. Claude Help Center는 Claude Design이 기존 Claude 채팅이나 Claude Code 한도와 별도로 과금·측정되며, 주간 allowance와 extra usage 구조를 갖는다고 설명합니다. 다만 베타 기간의 rate limit은 변경될 수 있다고 안내하므로, 실제 도입 전에는 팀의 계약 조건과 관리 화면에서 다시 확인해야 합니다.

지원 국가 역시 제품별로 다르게 느껴질 수 있습니다. Anthropic의 지원 국가 페이지에는 Claude.ai 접근 가능 국가 목록에 South Korea가 포함되어 있지만, 조직 정책, 플랜, 점진적 롤아웃, 기능별 제한에 따라 실제 사용 가능 여부는 달라질 수 있습니다.

Cursor와 Codex를 함께 쓰는 방식도 신중히 표현해야 합니다. OpenAI 문서는 Codex IDE 확장이 Cursor 같은 VS Code 호환 에디터에서 작동한다고 안내하고, Cursor는 OpenAI Codex 계열 모델을 에이전트 환경에 맞게 조정한 내용을 공식 블로그에서 설명합니다. 하지만 이 글에서 말하는 Claude Design → Cursor/Codex → UX 테스트 질문지 흐름은 공식 패키지라기보다 도구별 기능을 연결한 실무 워크플로우 제안입니다.

마지막으로 AI 결과물의 품질은 입력 품질에 크게 좌우됩니다. 문제 정의가 흐릿하면 IA도 흐릿해지고, 디자인 시스템 정보가 부족하면 프로토타입이 브랜드와 맞지 않을 수 있습니다. 대형 코드베이스를 한 번에 연결하면 성능 문제가 생길 수 있다는 Claude Design 튜토리얼의 주의사항도 실무에서 중요합니다.

디자이너의 역할은 어떻게 바뀌는가

AI 도구가 UX 산출물을 빠르게 만들어준다고 해서 디자이너의 역할이 사라지는 것은 아닙니다. 오히려 반대로, 디자이너가 무엇을 검토해야 하는지 더 선명해집니다.

예전에는 디자이너의 시간이 화면 제작과 문서 정리에 많이 쓰였습니다. 앞으로는 화면을 만드는 시간보다 “이 화면이 맞는 문제를 풀고 있는가”, “사용자가 이 흐름을 이해할 수 있는가”, “개발자가 이 디자인 의도를 오해 없이 구현할 수 있는가”를 판단하는 시간이 더 중요해질 가능성이 큽니다.

OpenAI의 Simplex 사례에서도 사람의 역할은 사라지지 않습니다. Simplex 사례는 AI가 구현, 리뷰, 수정 속도를 높일 수 있음을 보여주지만, 동시에 사람은 최종 판단과 품질 책임을 유지한다는 방향을 강조합니다.

UI/UX 디자이너에게 이 변화는 꽤 실질적입니다. 단순히 “프롬프트를 잘 쓰는 사람”이 되는 것이 아니라, AI가 만든 산출물을 평가할 수 있는 UX 기준을 갖춘 사람이 되어야 합니다. 좋은 질문, 좋은 제약 조건, 좋은 검토 기준을 설계하는 역량이 더 중요해집니다.

결론: 자동화보다 중요한 것은 연결된 판단 흐름

정리해보면, UI/UX 디자이너의 AI 워크플로우에서 중요한 것은 “AI가 어디까지 대신할 수 있느냐”보다 “분리되어 있던 UX 산출물을 얼마나 잘 연결할 수 있느냐”입니다.

Claude Design은 공개 자료 기준 디자인, 프로토타입, 슬라이드, 원페이저, 핸드오프 번들을 만드는 방향으로 진화하고 있습니다. Cursor와 Codex는 코드 기반 프로토타입과 구현 검토를 빠르게 반복하는 데 도움을 줄 수 있습니다. 하지만 이 모든 도구는 디자이너의 판단을 대체하기보다, 판단을 더 자주, 더 빠르게, 더 구체적으로 하게 만드는 보조 장치에 가깝습니다.

실무적으로는 작은 흐름부터 시작하는 것이 좋습니다. 예를 들어 “온보딩 4개 화면”이나 “관리자 설정 플로우”처럼 범위를 좁히고, IA → 와이어프레임 → 코드 프로토타입 → 테스트 질문지까지 한 번에 연결해보는 것입니다. 그 과정에서 어떤 프롬프트가 유효했는지, 어떤 산출물은 사람이 반드시 고쳐야 했는지, 어떤 검토 기준이 반복적으로 필요했는지를 팀 자산으로 쌓아야 합니다.

이번 주제는 어떠셨나요? 저는 AI 시대의 디자이너가 더 이상 화면 제작 속도만으로 평가받지는 않을 것 같습니다. 오히려 문제를 정의하고, 산출물 간의 맥락을 연결하고, 사용자 경험의 품질을 판단하는 역량이 더 중요해지는 시점이라고 생각합니다. 긴 글 읽어주셔서 감사합니다.