화면 기획서보다 작동하는 가설이 중요해졌다: AI 프로토타이핑 시대의 UX 기획 실전법

이경규·약 5시간 전

화면 기획서보다 작동하는 가설이 중요해졌다: AI 프로토타이핑 시대의 UX 기획 실전법

예전 UX 기획 업무는 대체로 다음 순서로 진행됐다.

요구사항 정리
↓
화면 목록
↓
와이어프레임
↓
디자인
↓
개발 전달
↓
QA

기획자는 문서를 만들고, 디자이너는 화면을 다듬고, 개발자는 이를 실제 제품으로 구현했다.

단계가 명확한 대신 문제가 하나 있었다.

기획 단계에서 본 화면과 실제 동작하는 제품 사이에 큰 간격이 존재했다.

기획서에서는 자연스러움

↓

프로토타입에서는 어색함

↓

개발 후에는 더 복잡함

예를 들어 기획서에는 이렇게 적혀 있을 수 있다.

사용자가 날짜를 선택한다.

예약 가능한 시간대를 확인한다.

예약 버튼을 누른다.

정적인 화면으로는 간단해 보인다.

하지만 실제 제품에서는 바로 질문이 늘어난다.

예약 가능한 날짜가 없으면?

사용자가 날짜를 바꾸면 선택한 시간은 초기화되는가?

네트워크가 느리면 무엇을 보여주는가?

지난 날짜를 선택할 수 있는가?

화면 읽기 도구는 날짜를 어떻게 읽는가?

한 손으로 조작하기 어려운 위치는 아닌가?

선택 중 가격이 바뀌면 어떻게 알리는가?

AI 프로토타이핑 도구가 발전하면서 이 간격이 빠르게 줄어들고 있다.

이제 디자이너나 기획자가 짧은 설명과 기존 디자인 시스템을 바탕으로 클릭 가능한 화면을 만들고, 실제 상태 전환을 확인하고, 경우에 따라 코드 저장소와 연결해 작은 수정까지 직접 검토할 수 있다.

여기서 중요한 변화는 단순히 화면을 더 빨리 만든다는 것이 아니다.

잘못된 가설을 더 빨리 발견할 수 있게 됐다는 것이다.

이번 글에서는 AI 프로토타이핑을 단순한 화면 생성 도구가 아니라, UX 기획자가 제품 가설을 구체화하고 검증하는 도구로 사용하는 방법을 정리한다.

1. 이제 화면 생성 자체는 경쟁력이 되기 어렵다

예전에는 완성도 높은 화면을 만드는 데 시간이 많이 들었다.

와이어프레임

↓

컴포넌트 구성

↓

레이아웃 조정

↓

반응형 화면

↓

상호작용 연결

그래서 화면을 빠르게 만드는 능력 자체가 큰 가치였다.

최근에는 AI가 첫 화면과 기본 상호작용을 빠르게 만들어준다.

사용자 설명

↓

초기 화면

↓

버튼과 메뉴 동작

↓

반응형 레이아웃

↓

수정 반복

하지만 첫 결과가 빨라졌다고 UX 문제가 해결되는 것은 아니다.

AI는 다음과 같은 화면을 쉽게 만들 수 있다.

예쁜 로그인 화면

깔끔한 대시보드

세련된 예약 화면

복잡한 데이터 테이블

그렇지만 다음 질문에는 자동으로 답하지 못한다.

사용자가 왜 이 기능을 써야 하는가?

어떤 상황에서 가장 불편한가?

무엇을 먼저 보여줘야 하는가?

어떤 오류가 가장 치명적인가?

이 기능이 실제 행동을 바꾸는가?

누구에게는 이 흐름이 작동하지 않는가?

따라서 UX 기획자의 중심 업무는 화면 제작에서 결정 구조 설계로 이동한다.

2. AI 시대의 UX 기획 산출물은 화면 목록이 아니다

기존 화면 기획서는 보통 다음처럼 시작한다.

화면 1: 홈

화면 2: 검색 결과

화면 3: 상세

화면 4: 결제

이 구조는 개발 범위를 확인하는 데는 도움이 된다.

하지만 사용자의 경험을 설명하기에는 부족하다.

AI 프로토타이핑 시대에는 다음 다섯 가지를 먼저 정의하는 편이 좋다.

사용자 목표

제품 가설

핵심 행동

상태와 예외

검증 기준

예를 들어 여행 숙소 예약 기능이라면 다음과 같다.

사용자 목표

여러 숙소를 오래 비교하지 않고
내 조건에 맞는 숙소를 확신 있게 선택한다.

제품 가설

총비용과 취소 조건을 검색 결과에서 먼저 보여주면
상세 페이지를 반복해서 열어보는 행동이 줄어들 것이다.

핵심 행동

조건 설정

결과 비교

상세 확인

예약 결정

상태와 예외

결과 없음

가격 변경

매진

네트워크 지연

조건 충돌

부분 환불

로그인 만료

검증 기준

사용자가 3분 안에 후보 숙소를 2개 이하로 줄이는가?

총비용을 정확히 이해하는가?

취소 가능 여부를 잘못 판단하지 않는가?

이렇게 정의하면 AI에게도 훨씬 좋은 프로토타입을 요청할 수 있다.

3. “이런 앱을 만들어줘”라는 요청은 너무 약하다

AI 프로토타이핑 도구에 다음처럼 요청할 수 있다.

깔끔한 병원 예약 앱을 만들어줘.

결과는 빠르게 나온다.

하지만 보통 익숙한 패턴을 조합한 일반적인 화면에 가깝다.

상단 검색

의사 카드

날짜 선택

예약 버튼

화면은 그럴듯하지만 실제 기획 의도는 거의 들어 있지 않다.

좋은 요청은 화면 모양보다 사용자 상황과 판단 기준을 포함한다.

처음 진료를 예약하는 사용자를 위한 모바일 흐름을 만든다.

사용자는 어떤 진료과를 선택해야 하는지 확신이 없고,
병원보다 가능한 날짜를 먼저 찾고 싶어 한다.

첫 화면에서는 진료과 선택을 강제하지 말고
증상 또는 가능한 날짜에서 시작할 수 있게 한다.

예약 가능 시간이 없는 경우에는
다음 가능한 날짜와 유사한 진료과를 제안한다.

반드시 포함할 상태:

- 첫 방문
- 재방문
- 예약 가능 시간 없음
- 네트워크 로딩
- 선택 중 예약 마감
- 예약 완료
- 예약 실패

검증 목표:

사용자가 2분 안에 예약 가능한 의사를 찾고
진료과와 비용을 정확히 이해해야 한다.

이제 AI가 단순한 화면 생성기가 아니라 가설을 표현하는 도구가 된다.

4. 먼저 Happy Path가 아니라 State Map을 만든다

기획서와 프로토타입에서 가장 쉽게 빠지는 부분은 정상적인 흐름만 만드는 것이다.

정보 입력

↓

다음

↓

확인

↓

완료

실제 사용자 경험은 대부분 중간 상태에서 결정된다.

예를 들어 결제 화면에는 다음 상태가 있다.

기본 상태

입력 중

쿠폰 적용 중

결제 수단 없음

잔액 부족

가격 변경

결제 처리 중

결제 성공

결제 실패

중복 결제 의심

앱 종료 후 복귀

그래서 화면을 만들기 전에 State Map을 적는다.

feature: checkout

states:
  - idle
  - editing_address
  - applying_coupon
  - validating_payment
  - processing
  - success
  - failed

exceptions:
  - item_sold_out
  - price_changed
  - coupon_expired
  - payment_declined
  - network_timeout

recovery:
  item_sold_out:
    action: return_to_cart

  price_changed:
    action: confirm_new_price

  payment_declined:
    action: select_another_payment

AI에게 이 상태를 전달하면 빈 화면 하나가 아니라 실제 제품에 가까운 프로토타입을 만들 수 있다.

5. UX 기획자는 화면보다 상태 간 전환을 검토해야 한다

프로토타입을 만들고 나면 화면 디자인부터 보게 된다.

색상이 맞는가?

여백이 자연스러운가?

버튼이 예쁜가?

물론 중요하다.

하지만 초기 기획 검토에서는 다음 질문이 더 중요하다.

사용자가 다음 행동을 예측할 수 있는가?

작업 중 현재 위치를 알 수 있는가?

실패 후 돌아갈 길이 있는가?

입력한 정보가 사라지지 않는가?

시스템이 처리 중이라는 것을 알 수 있는가?

취소했을 때 결과가 명확한가?

예를 들어 AI가 만든 예약 프로토타입에서 날짜를 바꿨는데 이전 시간대 선택이 그대로 남는다면 이는 시각 문제가 아니다.

상태 일관성 문제다.

기획자는 다음처럼 기록한다.

{
  "issue": "날짜 변경 후 이전 시간 선택이 유지됨",
  "risk": "사용자가 다른 날짜로 예약했다고 오해할 수 있음",
  "expected": "날짜 변경 시 시간 선택 초기화",
  "priority": "P0"
}

6. 정적 와이어프레임 대신 Evidence Prototype을 만든다

이제 모든 프로토타입을 고해상도로 만들 필요는 없다.

프로토타입은 무엇을 검증하려는지에 따라 달라져야 한다.

구조 검증용

정보 우선순위

탐색 구조

화면 이동

메뉴 이름

시각적 완성도는 낮아도 된다.

행동 검증용

검색

필터

입력

상태 변경

오류 복구

실제 클릭과 상태 전환이 필요하다.

신뢰 검증용

가격 안내

개인정보 동의

AI 추천 이유

자동 결정 설명

위험 경고

문구와 정보 표현이 중요하다.

디자인 시스템 검증용

기존 컴포넌트 사용

변형 상태

반응형 동작

접근성

실제 컴포넌트와 가까워야 한다.

프로토타입마다 검증 목적을 한 줄로 적는다.

이 프로토타입은
사용자가 총 결제 금액과 취소 조건을
결제 전에 정확히 이해하는지 확인하기 위한 것이다.

이 한 줄이 없으면 팀은 서로 다른 기준으로 화면을 평가한다.

7. AI Persona보다 실제 Task를 먼저 만든다

최근 AI 도구는 Persona를 빠르게 생성해준다.

바쁜 직장인

디지털에 익숙하지 않은 고령 사용자

가격에 민감한 대학생

Persona 자체는 아이디어를 넓히는 데 도움이 된다.

하지만 실제 사용자를 대신할 수는 없다.

특히 AI가 만든 Persona는 흔한 고정관념을 반복할 수 있다.

고령자는 기술을 어려워한다.

젊은 사용자는 모든 기능에 익숙하다.

직장인은 무조건 빠른 흐름을 선호한다.

그래서 Persona보다 먼저 Task와 Context를 정의하는 편이 좋다.

사용자는 병원 진료를 처음 예약한다.

현재 몸이 불편하고 집중하기 어렵다.

진료과를 정확히 모른다.

오늘 저녁 이후에만 방문할 수 있다.

가격과 보험 적용 여부를 걱정한다.

이 상황을 AI에게 주고 프로토타입을 걷게 한다.

그다음 실제 사용자 테스트로 확인한다.

AI Persona는 다음 용도로 제한하는 것이 좋다.

누락된 상태 찾기

문구의 모호성 찾기

접근성 질문 만들기

테스트 시나리오 확장

최종 판단은 실제 사용자와 서비스 데이터가 맡아야 한다.

8. “디자인 시스템 적용”보다 “디자인 시스템 포화도”가 중요하다

AI가 화면을 빠르게 생성하면 디자인 시스템의 약한 부분이 바로 드러난다.

예를 들어 Button 컴포넌트는 있지만 다음 상태가 없다.

로딩

긴 텍스트

위험 작업

권한 없음

오프라인

부분 성공

Table은 있지만 다음 상황을 처리하지 못한다.

데이터 없음

오류

행 선택

일괄 작업

긴 셀 내용

작은 화면

키보드 탐색

이 상태에서 AI에게 화면을 생성시키면 임의의 컴포넌트를 새로 만들거나, 기존 시스템과 다른 패턴을 만들어낸다.

따라서 AI 시대의 디자인 시스템은 컴포넌트 개수보다 실제 제품 상태를 얼마나 충분히 표현할 수 있는가가 중요하다.

이를 Design System Saturation으로 볼 수 있다.

확인할 항목은 다음과 같다.

정상 상태만 있는가?

오류와 빈 상태가 있는가?

권한과 읽기 전용 상태가 있는가?

모바일과 넓은 화면을 모두 처리하는가?

긴 문구와 다국어를 처리하는가?

접근성 상태가 정의돼 있는가?

코드 컴포넌트와 이름이 연결되는가?

9. 기획 단계에서 Component Contract를 만든다

AI가 디자인 시스템을 정확히 사용하게 하려면 이름만 제공해서는 부족하다.

PrimaryButton

DataTable

DatePicker

각 컴포넌트가 언제 사용되고 어떤 상태를 가지는지 정의해야 한다.

{
  "component": "DatePicker",
  "purpose": "단일 날짜 또는 날짜 범위 선택",
  "variants": [
    "single",
    "range"
  ],
  "states": [
    "default",
    "focused",
    "selected",
    "disabled",
    "error",
    "loading"
  ],
  "rules": [
    "지난 날짜를 선택할 수 없는 서비스에서는 disabled 상태 사용",
    "날짜 변경 시 종속된 시간 선택 초기화",
    "오류는 색상만으로 전달하지 않음"
  ]
}

기획자와 디자이너가 이런 Contract를 준비하면 AI 결과가 제품 규칙에서 크게 벗어나지 않는다.

10. 디자인과 코드가 연결될수록 Naming이 중요해진다

기존에는 디자인 파일의 이름과 코드 컴포넌트 이름이 달라도 사람이 해석했다.

Figma
Blue Button / Large

Code
PrimaryActionButton

AI Agent는 주어진 정보에 의존한다.

이름과 상태가 일치하지 않으면 엉뚱한 컴포넌트를 선택할 수 있다.

가능하면 다음을 맞춘다.

Figma Component

Code Component

Design Token

Documentation

예:

Button / Primary / Large
PrimaryButton(size: .large)
button.primary.large
Primary button — Large

완전히 동일한 이름을 강제할 필요는 없지만 매핑 규칙은 있어야 한다.

{
  "figma": "Button/Primary/Large",
  "code": "PrimaryButton",
  "props": {
    "size": "large",
    "role": "primary"
  }
}

11. 이제 Handoff는 파일 전달이 아니라 결정 전달이다

전통적인 Handoff는 다음 자료를 넘겼다.

화면

간격

색상

폰트

이미지

동작 설명

AI가 디자인과 코드를 오갈 수 있게 되면 픽셀 정보는 비교적 쉽게 전달된다.

대신 다음 정보가 더 중요해진다.

왜 이 흐름을 선택했는가?

어떤 대안을 제외했는가?

어떤 사용자를 우선했는가?

어떤 위험을 허용했는가?

무엇이 아직 검증되지 않았는가?

그래서 Decision Record를 남긴다.

## 결정

검색 결과 카드에 총 결제 금액을 표시한다.

## 이유

상세 페이지를 반복해서 열어야
실제 금액을 알 수 있다는 사용자 불편이 반복적으로 확인됐다.

## 제외한 대안

1박 가격만 표시:
최종 금액 오해 가능성이 높음.

## 검증 필요

카드 정보량이 지나치게 많아지는지 확인.

이 정보가 디자인 파일, 프로토타입, PR까지 이어져야 한다.

12. 작은 UX 개선은 티켓 대신 직접 검증 가능한 변경으로 바뀐다

기존에는 작은 개선도 티켓을 만들었다.

버튼 문구 수정

대비 개선

빈 상태 문구 변경

날짜 선택기 개선

스크린리더 레이블 수정

문제는 작은 개선이 우선순위에서 계속 밀린다는 것이다.

AI와 코드 연결 도구를 사용할 수 있는 환경에서는 범위가 좁고 위험이 낮은 변경을 디자이너가 직접 Branch에서 제안하고, 개발자가 Review하는 흐름도 가능해지고 있다.

디자이너가 문제 발견

↓

프로토타입으로 변경 확인

↓

코드 저장소의 관련 컴포넌트 확인

↓

작은 변경 생성

↓

PR

↓

개발자 Review

↓

병합

이 방식은 디자이너가 개발자를 대체한다는 의미가 아니다.

역할이 바뀐다.

디자이너
→ 의도와 경험의 마지막 20%를 직접 책임

개발자
→ 구조·품질·안전성 Review

PM
→ 목표와 범위 유지

단, 모든 작업에 적합하지는 않다.

13. 디자이너가 직접 다루기 좋은 변경과 위험한 변경을 구분한다

직접 시도하기 좋은 후보

문구 수정

레이블 명확화

여백과 정렬

색상 대비

빈 상태

도움말

접근성 레이블

기존 컴포넌트의 속성 변경

개발자와 먼저 범위를 맞춰야 하는 작업

공유 컴포넌트 변경

상태 관리 변경

API 응답 처리

로그인과 권한

결제

데이터 저장

외부 라이브러리 추가

직접 변경하면 안 되는 작업

Production 설정

보안 정책

데이터베이스 Migration

Secret

인증 토큰

배포 Workflow

결제 승인 로직

기획과 디자인의 실행 범위가 넓어질수록 권한과 Review 기준도 명확해야 한다.

14. AI 프로토타입은 실제 제품 데이터로 검증해야 한다

AI가 생성한 프로토타입에는 보통 보기 좋은 샘플 데이터가 들어간다.

짧은 사용자 이름

적당한 길이의 제목

항상 존재하는 이미지

오류 없는 숫자

정돈된 그래프

실제 제품 데이터는 다르다.

매우 긴 이름

이모지와 특수문자

이미지 없음

0원

매우 큰 숫자

음수

다국어

누락 데이터

지연된 데이터

프로토타입에 Fixture를 넣는다.

{
  "users": [
    {
      "name": "김민수",
      "status": "normal"
    },
    {
      "name": "매우 긴 이름을 사용하는 조직 관리자 계정",
      "status": "long_text"
    },
    {
      "name": "",
      "status": "missing"
    }
  ]
}

최소한 다음 상태를 확인한다.

정상

긴 텍스트

데이터 없음

로딩

오류

부분 데이터

권한 없음

작은 화면

큰 글자

15. Liquid Glass 같은 최신 시각 흐름도 기능 계층부터 봐야 한다

최근 Apple 플랫폼의 디자인 방향에서는 Liquid Glass가 중요한 시각 요소로 자리 잡았다.

하지만 투명한 효과를 많이 넣는 것이 목표는 아니다.

기능 계층을 분리하는 데 사용해야 한다.

콘텐츠

↓

탐색과 제어

↓

일시적인 상호작용

기획자가 먼저 결정해야 하는 것은 다음이다.

무엇이 콘텐츠인가?

무엇이 조작 장치인가?

무엇이 항상 보여야 하는가?

무엇이 필요할 때만 나타나는가?

예를 들어 카드 본문 전체에 유리 효과를 반복하면 콘텐츠와 조작 요소의 경계가 약해질 수 있다.

Liquid Glass를 적용할 후보는 보통 다음과 같다.

탭 바

툴바

사이드바

검색

일시적으로 나타나는 조작 요소

본문 배경이나 모든 카드에 반복해서 적용하는 것은 신중해야 한다.

최신 시각 효과를 적용하기 전에 다음을 확인한다.

대비가 충분한가?

배경 이미지가 바뀌어도 읽히는가?

투명도 감소 설정에서 유지되는가?

큰 글자에서 컨트롤이 깨지지 않는가?

콘텐츠보다 제어 요소가 더 눈에 띄지 않는가?

16. UX 기획자는 Accessibility를 마지막 QA로 보내면 안 된다

접근성은 프로토타입 단계에서 다뤄야 한다.

특히 AI가 만든 화면은 시각적으로는 자연스럽지만 다음이 빠질 수 있다.

키보드 이동 순서

스크린리더 이름

오류 안내

포커스 표시

터치 영역

색상 외의 상태 표현

동작 감소 설정

큰 글자

기획서에 별도 요구사항으로 붙이는 대신 각 상태 Contract에 포함한다.

component: password_field

accessibility:
  label: 비밀번호
  error_announcement: true
  reveal_button_label:
    hidden: 비밀번호 표시
    visible: 비밀번호 숨기기
  color_only_error: false
  keyboard_order: after_email

프로토타입 Review 때 다음 질문을 한다.

보지 않고도 상태를 이해할 수 있는가?

색상을 구분하지 못해도 오류를 알 수 있는가?

키보드만으로 완료할 수 있는가?

포커스가 어디에 있는지 알 수 있는가?

자동으로 움직이는 요소를 멈출 수 있는가?

17. UX Review도 여러 역할로 나눌 수 있다

AI Agent를 한 명의 가상 사용자처럼 쓰는 것보다 검토 역할을 분리하는 편이 낫다.

Flow Reviewer
→ 화면 이동과 상태 전환

Content Reviewer
→ 문구와 정보 우선순위

Accessibility Reviewer
→ 키보드·스크린리더·대비

Design System Reviewer
→ 컴포넌트와 Token 일치

Risk Reviewer
→ 오류·권한·복구

같은 프로토타입을 서로 다른 기준으로 검토한다.

결과 형식은 통일한다.

{
  "finding": "필터 적용 후 결과 수가 갱신됐다는 안내가 없음",
  "category": "feedback",
  "severity": "medium",
  "evidence": "검색 결과 화면",
  "affected_users": [
    "screen_reader",
    "low_attention"
  ],
  "recommendation": "결과 수 변경을 시각·음성으로 알림"
}

AI Review는 누락을 찾는 보조 수단이다.

실제 사용자 검증을 대체하지 않는다.

18. 좋은 UX Prompt는 해결책보다 문제를 먼저 준다

나쁜 요청:

검색 화면에 Filter Chip을 추가해줘.

이미 해결책이 정해져 있다.

좋은 요청:

사용자는 검색 결과가 200개 이상일 때
자신에게 맞는 항목을 줄이는 데 어려움을 겪는다.

현재 사용자가 가장 많이 비교하는 조건은
가격, 거리, 이용 가능 시간이다.

세 조건을 빠르게 조정하면서도
현재 어떤 조건이 적용됐는지 놓치지 않는 흐름을 제안해.

Filter Chip만을 전제로 하지 말고
최소 3가지 상호작용 방향을 비교해.

각 방향에서 다음을 보여줘.

- 장점
- 위험
- 작은 화면 동작
- 접근성
- 상태가 복잡해졌을 때 확장 가능성

AI를 화면 하청 도구가 아니라 대안 탐색 도구로 사용한다.

19. 한 번에 완성본을 만들지 말고 Variant를 비교한다

AI 프로토타입의 장점은 여러 방향을 빠르게 만들 수 있다는 것이다.

하지만 비슷한 화면 10개를 만드는 것은 큰 도움이 되지 않는다.

가설이 다른 Variant를 만든다.

Variant A — 빠른 행동 중심

핵심 행동을 첫 화면에 배치

설명 최소화

Variant B — 신뢰 중심

추천 이유와 조건을 먼저 설명

결정 전에 비교 정보 제공

Variant C — 단계적 공개

처음에는 선택지를 줄이고

필요할 때 상세 조건 제공

비교 기준도 미리 정한다.

완료 시간

오류율

되돌아가기 횟수

정보 이해도

확신도

도움 요청 횟수

“어느 화면이 더 예쁜가”보다 “어느 가설이 더 잘 작동하는가”를 본다.

20. Prototype Brief를 표준화하자

팀에서 재사용할 수 있는 형식을 만든다.

# Prototype Brief

## 문제

사용자가 해결하지 못하는 구체적인 문제.

## 대상 상황

언제, 어디서, 어떤 제약 속에서 사용하는가.

## 가설

어떤 변화를 주면 어떤 행동이 달라질 것인가.

## 핵심 Task

사용자가 완료해야 하는 행동.

## 필수 상태

- 정상
- 로딩
- 데이터 없음
- 오류
- 권한 없음
- 완료

## 제약

- 기존 디자인 시스템 사용
- 모바일 우선
- 외부 라이브러리 추가 없음

## 검증 질문

- 사용자가 다음 행동을 예측하는가?
- 실패 후 복구할 수 있는가?
- 핵심 정보를 정확히 이해하는가?

## 완료 기준

프로토타입이 제공해야 하는 화면과 동작.

이 문서를 Figma Make나 다른 AI 프로토타이핑 도구에 전달한다.

21. 기획자용 실전 Workflow

1단계 — 문제를 한 문장으로 정의한다

사용자는 숙소의 최종 결제 금액을
상세 화면을 열기 전에는 알 수 없다.

2단계 — 행동 가설을 만든다

검색 결과에 총금액과 취소 조건을 함께 보여주면
불필요한 상세 화면 이동이 줄어들 것이다.

3단계 — State Map을 만든다

기본

필터 적용

가격 변경

매진

결과 없음

로딩

오류

4단계 — 세 가지 Variant를 생성한다

총금액 강조형

취소 조건 강조형

비교 중심형

5단계 — 실제 데이터 Fixture를 넣는다

장기 숙박

세금 별도

무료 취소 불가

긴 숙소명

이미지 없음

6단계 — 역할별 Review를 진행한다

UX Flow

Content

Accessibility

Design System

Engineering Risk

7단계 — 실제 사용자에게 Task를 준다

무료 취소가 가능한 숙소 중
총금액이 가장 낮은 후보를 선택해보세요.

8단계 — 결과를 Decision Record로 남긴다

어떤 방향을 선택했는가?

왜 선택했는가?

무엇은 아직 검증되지 않았는가?

22. AI가 만든 결과에서 반드시 사람이 볼 것

문제가 실제 사용자 문제인가?

가설이 측정 가능한가?

데이터 출처가 맞는가?

법적·정책적 안내가 정확한가?

접근성 요구를 만족하는가?

기존 제품 구조에서 구현 가능한가?

추천 결과가 특정 사용자를 불리하게 만들지 않는가?

특히 금융, 건강, 보험, 채용, 교육 같은 영역에서는 AI가 만든 문구나 추천 기준을 그대로 사용하면 안 된다.

23. 앞으로 UX 기획자의 역량은 이렇게 바뀐다

예전에는 다음 역량이 중요했다.

화면 정의

문서 작성

정책 정리

디자인 전달

앞으로는 여기에 새로운 역량이 더해진다.

문제를 검증 가능한 가설로 바꾸기

상태와 예외를 구조화하기

AI가 사용할 Context를 설계하기

빠른 프로토타입을 평가하기

디자인 시스템과 코드의 연결 이해하기

접근성과 위험을 초기 단계에서 검토하기

결정의 근거를 남기기

코드를 직접 작성하는 능력이 필수라는 뜻은 아니다.

다만 제품이 실제로 어떻게 동작하고, 컴포넌트와 상태가 어떻게 연결되는지를 이해할수록 기획의 정확도가 높아진다.

24. 가장 피해야 할 방식

AI가 만든 첫 화면을 정답으로 채택

빠르게 나왔다

≠

문제가 해결됐다

모든 화면을 고해상도로 제작

검증 목적이 불분명해진다.

정상 흐름만 프로토타입으로 제작

실제 UX 문제는 오류·권한·복구 상태에서 드러난다.

AI Persona만으로 사용자 검증 완료

실제 사용자와 데이터를 대체할 수 없다.

디자인 시스템 이름만 제공

상태·사용 규칙·코드 매핑이 없으면 일관성이 깨진다.

디자이너가 생성한 코드를 검토 없이 반영

작은 시각 변경도 공유 컴포넌트와 다른 화면에 영향을 줄 수 있다.

25. 마무리

AI가 화면과 프로토타입을 빠르게 만들수록 UX 기획자의 일이 줄어드는 것처럼 보일 수 있다.

실제로는 반대에 가깝다.

화면 제작 비용이 내려가면 더 많은 방향을 시도할 수 있다.

그만큼 무엇을 만들지, 어떤 기준으로 선택할지, 무엇을 검증했는지가 중요해진다.

화면 제작

↓

가설 표현

↓

상태 검증

↓

사용자 반응 확인

↓

결정 기록

↓

제품 반영

앞으로 좋은 UX 산출물은 화면 파일 하나가 아니다.

문제 정의

제품 가설

State Map

작동하는 프로토타입

실제 데이터 Fixture

검증 시나리오

Decision Record

가 하나로 연결된 구조다.

한 줄로 정리하면 이렇다.

AI 프로토타이핑 시대의 UX 기획자는
화면을 많이 정의하는 사람이 아니라,

잘못된 제품 가설을
가장 빠르고 안전하게 발견하는 사람이다.

AI가 첫 화면을 만들어주는 시대에는 시각적 초안을 만드는 능력보다 사용자 문제를 명확하게 정의하고, 상태와 예외를 설계하고, 작동하는 결과를 근거로 팀의 결정을 이끄는 능력이 더 중요해진다.

참고 자료

Figma — 2026 AI Report: Can AI Help Us Collaborate Better?
AI가 개인 생산성 도구에서 팀 협업 도구로 이동하고 있으며, 디자이너·개발자·PM의 역할 경계가 빠르게 겹치고 있다는 조사 자료.
Figma — Workflow Lab: Deploying Designs Directly with Figma Make
디자이너가 접근성·레이블·컴포넌트 같은 작은 UX 개선을 코드 저장소와 연결하고, Branch와 PR을 통해 개발자 Review까지 이어가는 Workflow 사례.
Figma — How Decagon Uses AI for Design System Saturation
Figma MCP, Figma Make, Storybook과 Agent Skill을 연결해 디자인 시스템의 상태와 컴포넌트를 코드와 지속적으로 맞추는 실무 사례.
Figma — GPT-5.6 Is Now Available in Figma Make
Prompt에서 반응형·상호작용이 포함된 고충실도 프로토타입으로 빠르게 이동하고, 여러 방향을 짧은 시간 안에 검토하는 최신 Figma Make 흐름.
Apple — Human Interface Guidelines / What’s New in Design
최신 Apple 플랫폼의 Hierarchy, Harmony, Consistency 원칙과 Liquid Glass, 접근성, 반응형 인터페이스 관련 가이드.
Apple — Materials / Adopting Liquid Glass
Liquid Glass를 콘텐츠 자체보다 탐색과 제어를 위한 기능 계층에 제한적으로 사용하고, 대비·가독성·접근성을 우선해야 한다는 공식 지침.

핵심 참고 포인트

Figma의 2026년 조사에서는 AI가 개인의 생산성뿐 아니라 팀의 협업 방식에도 영향을 주기 시작했으며, 디자이너의 개발 참여와 개발자의 디자인 참여가 함께 증가한 것으로 나타났다.

Figma가 공개한 최근 Workflow 사례에서는 작은 접근성·문구·컴포넌트 개선을 디자이너가 코드와 연결해 직접 변경하고, 개발자가 PR 단계에서 구조와 품질을 검토하는 역방향 Handoff가 소개됐다.

또한 디자인 시스템이 충분한 상태와 변형을 제공하지 않으면 Coding Agent도 일관된 결과를 만들기 어렵기 때문에, AI 시대에는 컴포넌트 개수보다 실제 제품 사용 사례를 얼마나 충분히 덮는지가 중요해지고 있다.

Apple의 최신 디자인 지침은 Liquid Glass를 콘텐츠 계층 전체에 반복 적용하기보다 탐색·제어 요소를 구분하는 기능적 계층으로 제한해 사용할 것을 권장하며, 시스템 설정과 접근성 환경에서도 가독성이 유지되는지 확인하도록 안내한다.

이경규

iOS 앱 개발자

이전 포스트

화면 기획서보다 작동하는 가설이 중요해졌다: AI 프로토타이핑 시대의 UX 기획 실전법

화면 기획서보다 작동하는 가설이 중요해졌다: AI 프로토타이핑 시대의 UX 기획 실전법

1. 이제 화면 생성 자체는 경쟁력이 되기 어렵다

2. AI 시대의 UX 기획 산출물은 화면 목록이 아니다

사용자 목표

제품 가설

핵심 행동

상태와 예외

검증 기준

3. “이런 앱을 만들어줘”라는 요청은 너무 약하다

4. 먼저 Happy Path가 아니라 State Map을 만든다

5. UX 기획자는 화면보다 상태 간 전환을 검토해야 한다

6. 정적 와이어프레임 대신 Evidence Prototype을 만든다

구조 검증용

행동 검증용

신뢰 검증용

디자인 시스템 검증용

7. AI Persona보다 실제 Task를 먼저 만든다

8. “디자인 시스템 적용”보다 “디자인 시스템 포화도”가 중요하다

9. 기획 단계에서 Component Contract를 만든다

10. 디자인과 코드가 연결될수록 Naming이 중요해진다

11. 이제 Handoff는 파일 전달이 아니라 결정 전달이다

12. 작은 UX 개선은 티켓 대신 직접 검증 가능한 변경으로 바뀐다

13. 디자이너가 직접 다루기 좋은 변경과 위험한 변경을 구분한다

직접 시도하기 좋은 후보

개발자와 먼저 범위를 맞춰야 하는 작업

직접 변경하면 안 되는 작업

14. AI 프로토타입은 실제 제품 데이터로 검증해야 한다

15. Liquid Glass 같은 최신 시각 흐름도 기능 계층부터 봐야 한다

16. UX 기획자는 Accessibility를 마지막 QA로 보내면 안 된다

17. UX Review도 여러 역할로 나눌 수 있다

18. 좋은 UX Prompt는 해결책보다 문제를 먼저 준다

19. 한 번에 완성본을 만들지 말고 Variant를 비교한다

Variant A — 빠른 행동 중심

Variant B — 신뢰 중심

Variant C — 단계적 공개

20. Prototype Brief를 표준화하자

21. 기획자용 실전 Workflow

1단계 — 문제를 한 문장으로 정의한다

2단계 — 행동 가설을 만든다

3단계 — State Map을 만든다

4단계 — 세 가지 Variant를 생성한다

5단계 — 실제 데이터 Fixture를 넣는다

6단계 — 역할별 Review를 진행한다

7단계 — 실제 사용자에게 Task를 준다

8단계 — 결과를 Decision Record로 남긴다

22. AI가 만든 결과에서 반드시 사람이 볼 것

23. 앞으로 UX 기획자의 역량은 이렇게 바뀐다

24. 가장 피해야 할 방식

AI가 만든 첫 화면을 정답으로 채택

모든 화면을 고해상도로 제작

정상 흐름만 프로토타입으로 제작

AI Persona만으로 사용자 검증 완료

디자인 시스템 이름만 제공

디자이너가 생성한 코드를 검토 없이 반영

최신 시각 효과를 모든 요소에 적용

25. 마무리

참고 자료

핵심 참고 포인트

Codex 5.6 제대로 쓰는 법 총정리: Sol·Terra·Luna 모델 배치부터 서브에이전트와 Context 압축 설정까지

0개의 댓글