화면 기획서가 더 이상 기획자의 핵심 산출물이 아닌 시대가 됐다. AI 프로토타이핑 도구들이 짧은 설명 한 줄로 클릭 가능한 인터페이스를 뚝딱 만들어내는 지금, 기획자가 가장 먼저 질문해야 할 것은 "이 화면을 어떻게 구성할까"가 아니라 "이 흐름에서 우리가 확인하고 싶은 가설이 무엇인가"다.
기존 UX 기획 프로세스의 문제는 속도가 아니라 검증 시점의 지연이었다. 요구사항 정리 → 와이어프레임 → 디자인 → 개발 전달로 이어지는 선형 흐름 안에서, 기획서 위의 '예약 버튼'은 언제나 자연스러웠다. 하지만 실제 제품에서는 즉시 질문이 쏟아진다. 예약 가능한 날짜가 없으면? 날짜를 바꾸면 선택한 시간대는 초기화되는가? 네트워크가 느리면 무엇을 보여주는가? 정적인 화면이 감추고 있던 복잡성이 개발 이후에야 드러나는 것, 그것이 진짜 병목이었다.
AI 프로토타이핑은 이 간격을 좁혀준다. 중요한 것은 단순히 화면을 빨리 만든다는 게 아니다. 잘못된 가설을 더 빨리 발견할 수 있게 됐다는 것이다. velog에 게재된 'AI 프로토타이핑 시대의 UX 기획 실전법'은 이 변화를 정확히 짚는다. AI는 예쁜 로그인 화면, 깔끔한 대시보드를 순식간에 만들어주지만, '사용자가 왜 이 기능을 써야 하는가', '어떤 오류가 가장 치명적인가' 같은 질문에는 자동으로 답하지 못한다. 그 질문에 답하는 것이 기획자의 몫으로 더 선명하게 남는다.
그렇다면 AI 프로토타이핑 시대의 기획자는 무엇을 먼저 설계해야 할까. 화면 목록보다 먼저 다섯 가지를 정의하는 편이 효과적이다: 사용자 목표, 제품 가설, 핵심 행동, 상태와 예외, 검증 기준. 여행 숙소 예약 기능을 예로 들면, "총비용과 취소 조건을 검색 결과에서 먼저 보여주면 상세 페이지를 반복해서 열어보는 행동이 줄어들 것이다"처럼 가설을 명문화하고, "사용자가 3분 안에 후보 숙소를 2개 이하로 줄이는가"라는 검증 기준을 붙이는 것이다. 이 구조가 갖춰져야 AI에게도 훨씬 정밀한 프로토타입을 요청할 수 있다.
AI 프로토타이핑 요청의 질은 상황과 판단 기준을 얼마나 포함하느냐에 달려 있다. "깔끔한 병원 예약 앱을 만들어줘"는 익숙한 패턴의 일반적인 화면만 돌려준다. 반면 "처음 진료를 예약하는 사용자는 어떤 진료과를 선택해야 하는지 확신이 없고, 병원보다 가능한 날짜를 먼저 찾고 싶어 한다. 첫 화면에서 진료과 선택을 강제하지 말고, 예약 가능 시간이 없는 경우엔 다음 날짜와 유사 진료과를 제안하라"는 요청은 AI를 단순한 화면 생성기가 아닌 가설을 표현하는 도구로 만든다.
기획서에서 가장 쉽게 빠지는 것은 정상 흐름 바깥의 상태들이다. 실제 사용자 경험의 대부분은 '입력 중', '쿠폰 적용 중', '결제 실패', '앱 종료 후 복귀' 같은 중간 상태에서 결정된다. 그래서 화면을 만들기 전에 State Map을 먼저 작성하는 것이 유효하다. 결제 화면 하나에도 idle, editing, processing, success, failed, 중복 결제 의심 등 열 개가 넘는 상태가 존재하고, item_sold_out 시엔 장바구니로 복귀, price_changed 시엔 새 금액 확인이라는 복구 경로도 명시해야 한다. 이 상태 명세를 AI에게 전달하면 빈 화면 하나가 아니라 실제 제품에 가까운 프로토타입이 나온다.
프로토타입을 검토할 때도 관점의 이동이 필요하다. 색상이 맞는가, 버튼이 예쁜가보다 먼저 물어야 할 것은 이것이다: 사용자가 다음 행동을 예측할 수 있는가? 실패 후 돌아갈 길이 있는가? 시스템이 처리 중이라는 것을 알 수 있는가? 날짜를 바꿨는데 이전 시간대 선택이 그대로 남는 문제는 시각 문제가 아니라 상태 일관성 문제다. 이런 이슈를 기획자가 발견하면, 문제·위험·예상 동작·우선순위를 담은 Decision Record 형식으로 기록하고 디자인 파일, 프로토타입, PR까지 연결해야 한다. 왜 이 흐름을 선택했는지, 어떤 대안을 제외했는지가 픽셀 정보보다 더 중요한 Handoff 자산이 된다.
AI가 화면을 빠르게 생성할수록 디자인 시스템의 빈틈도 바로 드러난다. Button 컴포넌트는 있는데 로딩·위험 작업·권한 없음·오프라인 상태가 없다면, AI는 임의의 컴포넌트를 새로 만들거나 기존 시스템과 다른 패턴을 생성한다. 이 글에서는 이를 Design System Saturation 개념으로 설명한다. 컴포넌트 개수보다 실제 제품 상태를 얼마나 충분히 표현할 수 있는가가 기준이다. DatePicker 하나라도 default, focused, selected, disabled, error, loading 상태와 함께 "날짜 변경 시 종속된 시간 선택 초기화