AI MVP가 너무 일찍 완성된 것처럼 보일 때 제가 사용하는 폴백 매트릭스

가장 위험한 AI 프로토타입은 고장 난 것이 아닙니다.

너무 일찍, 5분 정도 완성된 것처럼 보이는 것입니다.

이것은 팀원들이 실제 사용자의 경로를 통해 워크플로우가 살아남을 수 있는지 아무도 확인하기 전에 백로그(backlog), 다듬기(polish), 출시 시기에 대해 논의하기 시작하는 순간입니다. 저는 초기 MVP 생성을 위해 NxCode를 많이 사용했기 때문에, 이러한 잘못된 완전성 감각을 포착할 더 빠른 방법이 필요했습니다.

이제 프로토타입이 엔지니어링 시간을 갖기 전에 작은 폴백 매트릭스(fallback matrix)를 실행합니다.

폴백 매트릭스

저는 순서대로 5가지 질문을 합니다.

1. 첫 화면이 사라진다면, 흐름은 여전히 말이 될까요?

이것은 데모 중심의 프로토타입(demo-first prototypes)을 포착합니다.

저는 제품을 한 줄로 다시 작성합니다:

• 사용자 (user)
• 트리거 (trigger)
• 결정 (decision)
• 가시적 결과 (visible outcome)

예시:

• 약함(weak): "팀 요청을 위한 AI 비서"
• 사용 가능함(usable): "직원이 블로커를 보고하면, 관리자가 소유자를 할당하고, 둘 다 블로커가 해결되는 것을 볼 수 있다"

만약 그 문장이 약하다면, MVP는 여전히 워크플로우가 아니라 피치(pitch)에 불과합니다.

2. 어떤 기록이 진실의 원천(source of truth)이 되나요?

저는 UI를 판단하기 전에 최소한의 데이터 객체들을 나열합니다.

요청 흐름의 경우, 보통 다음이 필요합니다:

• 요청 (request)
• 소유자 (owner)
• 상태 (status)
• 우선순위 (priority)
• 해결 메모 (resolution note)

생성된 화면들이 이러한 기록들과 명확하게 매핑되지 않으면, 저는 프로토타입을 신뢰하는 것을 멈춥니다.

3. 첫 번째 보기 싫은 케이스(ugly case)는 무엇인가요?

저는 항상 초기에 하나의 지저분한 경우를 테스트합니다:

• 중복 요청 (duplicate request)
• 필수 필드 공백 (empty required field)
• 잘못된 역할에 의한 상태 업데이트 (wrong role updates status)
• 해결된 항목이 재개되는 경우 (resolved item gets reopened)

만약 MVP가 모든 보기 싫은 케이스를 숨긴다면, 그것은 검토(review)가 아닌 스크린샷을 위해 최적화된 것입니다.

4. 주 흐름이 실패할 때의 폴백은 무엇인가요?

이것이 제 프로세스를 가장 많이 바꾼 질문입니다.

저는 프로토타입이 다음을 보여주는지 확인합니다:

• 수동 수정 경로 (manual correction path)
• 재시도 상태 (retry state)
• "검토 필요(needs review)" 상태
• 자동화만으로는 충분하지 않을 때 명확한 소유자

이것들이 없다면, 매끄러운 행복한 경로(happy path)가 제가 취약한 제품을 승인하도록 속일 수 있습니다.

5. 계획을 시작하기 전에 무엇을 잘라내야 할까요?

저는 다음에 무엇을 추가할지 묻지 않습니다.

스프린트 (sprint) 논의 비용이 커지기 전에 무엇을 제거해야 할지를 묻습니다.

제가 통상적으로 작성하는 제거 목록 (cut list)은 다음과 같습니다:

• 분석 위젯 (analytics widgets)
• 역할 변형 (role variations)
• 내보내기 (exports)
• 첫 번째 알림을 제외한 나머지 알림들 (notifications)
• 나중에나 중요해질 설정 화면들 (configuration screens)

만약 첫 번째 버전에서 20%를 잘라낼 수 없다면, 범위 (scope)가 여전히 부풀려져 있는 것입니다.

이 단계에서 제가 NxCode를 사용하는 이유

NxCode의 가치는 판단 (judgment)을 불필요하게 만드는 데 있지 않습니다.

NxCode의 가치는 거친 설명으로부터 검토 가능한 앱 구조 (app structure)를 충분히 빠르게 만들어줌으로써, 제가 범위 결정 (scope decisions), 인수인계 상태 (handoff states), 그리고 실패 사례 (failure cases)에 실제 시간을 할애할 수 있게 해준다는 점에 있습니다.

그것이 저에게 유용한 루프 (loop)입니다:

프롬프트 (prompt) -> 생성된 MVP -> 폴백 매트릭스 (fallback matrix) -> 제거 목록 (cut list) -> 더 나은 스프린트 인수인계 (sprint handoff)

이 워크플로우 (workflow)를 시도해보고 싶다면, NxCode와 시작 가이드 문서 (getting started docs)로 시작하세요.

여전히 수동으로 검토하는 것들

• 권한 (permissions)
• 보안 경계 (security boundaries)
• 결제 규칙 (billing rules)
• 운영 환경 에러 핸들링 (production error handling)
• 배포 준비 상태 (deployment readiness)

프로토타입 (prototype)은 빠르게 도달할 수 있습니다. 하지만 신뢰 (trust)는 여전히 천천히 쌓여야 합니다.