• 와이어프레임(Wireframe) → 클릭 가능한 프로토타입(Clickable prototype) → 코드로 구현된 프로토타입(Coded prototype) 파이프라인이 단일 단계로 통합됩니다.
• 4단계: 와이어프레임 캡처 (20–40분), 기본 앱 생성 (2–3분), 시각적 반복 작업 (Iterate visually) (1–2시간), 실제 하드웨어로 배포 (30초).
• 전통적인 첫 테스트 가능 빌드: 2–4주. AI 네이티브 방식: 1–3시간. 압축의 대부분은 역할 간의 인수인계(Handoffs)를 제거하는 데서 옵니다.
• 가장 좋은 와이어프레임 입력값은 스케치가 아닙니다. 경쟁사 스크린샷이나 정교하게 작성된 문단입니다.

대부분의 가이드가 혼동하는 세 가지 결과물

대부분의 프로토타이핑 대화에서 혼란을 주는 한 가지 명확한 구분은 다음과 같습니다:

• 와이어프레임 (Wireframe) — 정적인 레이아웃. 상호작용(Interactivity) 없음.
• 클릭 가능한 프로토타입 (Clickable prototype) — 정적 화면 사이에 핫스팟(Hotspots)이 연결됨 (Figma, InVision). 실제 로직을 실행할 수 없음.
• 작동하는 프로토타입 (Working prototype) — 실제 React Native 코드, 실제 네비게이션(Navigation), 실제 상태(State)가 포함되며, QR 코드를 통해 기기에 설치 가능함.
• 프로덕션 앱 (Production app) — 작동하는 프로토타입에 백엔드(Backend), 인증(Auth), 분석(Analytics), 스토어 등록 정보가 추가된 형태.

대부분의 "프로토타이핑" 튜토리얼은 두 번째 단계에서 멈춥니다. 흥미로운 압축은 첫 번째 단계에서 바로 세 번째 단계로 넘어가는 것입니다.

4단계 워크플로우

1. 와이어프레임 캡처 (20–40분)

화면, 요소, 탭 동작(Tap behaviour)을 캡처할 수 있는 매체라면 무엇이든 가능합니다: 손 스케치, 화이트보드 사진, Excalidraw, Figma 프레임, 경쟁사 스크린샷 또는 작성된 문단.

와이어프레임을 일회용으로 취급하세요. 와이어프레임의 역할은 최종 결과물이 아니라, *생성기를 위한 입력값(Input to the generator)*이 되는 것입니다.

2. 기본 앱 생성 (2–3분)

와이어프레임과 한 문단의 설명을 AI 모바일 앱 빌더에 입력하세요. 라우팅(Routing), 스타일이 적용된 화면, 스터브 데이터(Stubbed data)가 포함된 라이브 React Native + Expo 앱을 돌려받게 됩니다.

약 70% 정도 정확하며, 반복 작업을 진행하기에 충분한 수준입니다.

3. 시각적 반복 작업 (1–2시간)

기본 앱의 약 30%는 오류가 있습니다. '포인트 앤 에디트 (Point-and-edit)'가 가속기 역할을 합니다. 라이브 프리뷰에서 아무 요소나 클릭하고, 변경 사항을 설명하면 ("카드를 더 둥글게 만들고, 가격을 우측 상단으로 이동시켜줘") 기반 코드가 업데이트됩니다. 제품 팀은 보통 첫 한 시간 동안 30~50회의 마이크로 반복 작업 (micro-iterations)을 수행합니다.

이 단계에서의 두 가지 규칙:

• 어떤 화면이든 첫 번째 버전을 그대로 받아들이지 마세요.
• 흐름 (flow)을 검증하기 전에 시각적 요소를 과도하게 상세화하지 마세요. 색상은 저렴하지만, 내비게이션 (navigation)은 비용이 많이 듭니다.

4. 실제 하드웨어로 배포 (30초)

QR 코드를 스캔하여 iPhone 또는 Android의 프리뷰 클라이언트에 설치하고, 실제 하드웨어에서 앱을 사용해 보세요.

이 단계에서 Figma가 보여줄 수 없는 버그들이 실제로 드러납니다: 엄지손가락 탭 영역 (thumb-tap zones), 세이프 에어리어 (safe areas), 키보드 동작, 다크 모드 등입니다.

전통적 방식 vs. AI 네이티브 (AI-native)

5개 화면의 MVP 기준:

이러한 압축은 주로 역할 간의 인수인계 (handoffs)가 제거되었기 때문에 발생합니다. 한 명의 운영자가 전체 루프를 주도하면, "다른 사람을 기다리는" 시간들이 증발합니다.

어떤 와이어프레임 입력값이 가장 잘 변환되는가

신호 대 잡음비 (signal-to-noise)에 따라 최악 → 최고 순으로 나열:

1. 냅킨 스케치 사진 — 작동은 하지만, 미세한 뉘앙스 손실을 예상해야 합니다. 서술형 설명과 함께 사용하세요.
2. 화이트보드 사진 — 더 좋습니다. 화이트보드는 더 크고 읽기 쉬운 그림을 그리게 만듭니다.
3. Excalidraw / FigJam — 탁월합니다. 디지털 매체는 깔끔한 도형과 레이블을 생성합니다.
4. Figma 프레임 — 매우 좋습니다. 레이아웃과 계층 구조 (hierarchy)가 깔끔하게 전달됩니다.
5. 작성된 PRD 단락 — 과소평가되어 있습니다. 정확한 3~4문장의 설명은 종종 형편없는 스케치보다 낫습니다.
6. 경쟁사 스크린샷 — 가장 높은 신호 값을 가집니다. 이미 모바일 UI이므로 레이아웃, 타이포그래피, 상호작용 (interaction)이 모두 그대로 전달됩니다.

시간별 계획: 오후 한 번에 끝내는 음식 배달 MVP

2인 팀, 5개 화면 (음식점 목록 → 상세 → 장바구니 → 결제 → 주문 추적):

• 0:00–0:30 — 화이트보드 스케치 (Whiteboard sketch), 휴대폰 촬영.
• 0:30–0:38 — 업로드 및 한 단락의 설명 추가. 기본 앱 생성 완료.
• 0:38–1:20 — 첫 번째 반복 (First iteration) 단계. 클릭 및 편집 (Point-and-edit)을 통해 약 40군데 수정.
• 1:20–1:35 — 팀원 양쪽 휴대폰에 QR 설치. 두 개의 내비게이션 (Nav) 버그 발견; 3분 만에 수정.
• 1:35–2:20 — 세 명의 테스트 사용자에게 QR 전송, 공유 문서에 피드백 수집.
• 2:20–3:15 — 두 번째 반복 (Second iteration) 단계. 상위 10개의 UX 노트 해결.
• 3:15–3:30 — 공유 가능한 미리보기 URL 게시, Slack에 공유.

iOS와 Android 모두 실제 휴대폰에서 처음부터 끝까지 총 3시간 30분 소요.

이 워크플로우를 사용하지 말아야 할 때

AI 루프 (AI loop)가 만능은 아닙니다. 다음과 같은 경우에는 전통적인 방식을 유지하세요:

• 전례가 없는 새로운 상호작용 패턴 (Interaction patterns). 생성기 (Generators)는 패턴 매칭 (Pattern-match)을 수행합니다. 패턴이 없다는 것은 결과물의 품질이 보장되지 않음을 의미합니다.
• 규제 산업 (의료, 항공, 금융 거래)과 같이 문서화된 의사결정 경로 (Decision trails)가 필요한 분야.
• **