AI 코딩을 시작하면 기능 추가 비용이 거의 0처럼 느껴집니다. “검색도 넣어볼까?”, “AI 추천도 가능하겠는데?”, “관리자에 통계도 넣자.” 과거라면 개발 견적 때문에 포기했을 기능이 이제는 몇 문장으로 생성됩니다.
그래서 역설적으로 AI 프로젝트는 개발이 느려서보다 기능이 너무 빨리 늘어서 멈춥니다.
4주 안에 런칭하려면 먼저 “무엇을 만들 것인가”가 아니라 무엇을 이번 버전에서는 만들지 않을 것인가를 정해야 합니다.
MVP의 정의를 다시 잡기
MVP는 기능이 적은 제품이 아닙니다. 하나의 핵심 고객 문제를 실제로 끝까지 해결하는 최소 제품입니다.
예약 서비스라면:
핵심 흐름 = 클래스 보기 → 일정 선택 → 예약 → 결제 → 운영자가 확인
여기에 커뮤니티, 추천, 리뷰, 쿠폰, 친구초대가 없어도 예약 서비스는 존재합니다.
1단계. 핵심 사용자 한 명만 고른다
초기 제품에서 관리자, 판매자, 파트너, 일반 사용자, 기업고객 요구를 모두 해결하려고 하면 범위가 폭발합니다.
“첫 4주에 돈을 내거나 가장 중요한 행동을 할 사람”을 한 명 정합니다.
2단계. North Star Action을 한 문장으로
예:
- 사용자가 유료 예약을 완료한다.
- 기업 고객이 리포트를 생성한다.
- 농장주가 오늘 해야 할 작업을 확인한다.
이 행동과 직접 연결되지 않는 기능은 우선순위를 낮춥니다.
3단계. 기능을 Must / Later / Never-now로 구분
Must
핵심 행동을 끝내는 데 필수.
Later
사용성은 좋아지지만 없어도 거래/검증 가능.
Never-now
매력적이지만 현재 검증과 직접 상관없는 기능.
중요한 것은 Later를 “시간 남으면 하자”가 아니라 이번 버전에 하지 않는다로 명확히 하는 것입니다.
4단계. 기능이 아니라 완료 조건으로 범위 정의
나쁜 범위:
- 로그인
- 결제
- 관리자
좋은 범위:
로그인 완료 조건
- 이메일 가입
- 로그인/로그아웃
- 비밀번호 재설정
- 보호 페이지 접근 제어
결제 완료 조건
- 상품 금액 표시
- 테스트/실결제
- 주문 상태 저장
- 취소 처리 가능
이렇게 하면 “완료했다”는 판단이 명확해집니다.
5단계. 디자인 완성도를 구분
모든 화면을 픽셀 단위로 완벽하게 만들 필요는 없습니다.
고객이 처음 보는 핵심 화면
브랜드와 신뢰도가 중요하므로 완성도 높게.
관리자 화면
업무가 되면 충분.
예외/빈 화면
기본 안내만 있어도 됨.
나중에 자주 바뀔 화면
지금 과투자하지 않음.
6단계. 기술 선택도 범위다
초기 서비스에 Kubernetes, Microservice, 복잡한 Event Architecture가 필요하지 않은 경우가 많습니다.
선택 기준:
- 팀이 이해할 수 있는가
- AI가 반복 수정하기 쉬운가
- 운영 비용이 예측 가능한가
- 백업과 배포가 단순한가
- 나중에 이전 가능한가
“최고의 기술”보다 4주 후 운영 가능한 기술이 맞습니다.
4주 Scope 예시
Week 1 — Scope & Skeleton
- 핵심 사용자 흐름 확정
- Git/환경 구성
- 데이터 모델
- 첫 운영 URL
Week 2 — Core Flow
- 인증
- 핵심 기능
- 운영 DB
Week 3 — Transaction & Admin
- 결제/예약/주문
- 최소 관리자
- 오류/예외 처리
Week 4 — Launch
- 모바일 확인
- 백업/로그
- 운영 매뉴얼
- 실제 사용자 오픈
변경 요청을 통제하는 방법
4주 중 새로운 아이디어는 반드시 나옵니다. 없애려고 하지 말고 Parking Lot에 넣습니다.
새 요구가 나오면 세 질문만 합니다.
- 이 기능이 없으면 핵심 거래가 불가능한가?
- 현재 사용자 검증을 막는가?
- 이번 주 추가하면 원래 일정에서 무엇을 빼야 하는가?
셋 다 명확하지 않으면 다음 버전입니다.
Scope Freeze 시점
추천은 1주차 말입니다. 이후에는 치명적 문제나 법적/보안 필수 항목이 아니면 기능 추가를 멈춥니다.
대표가 가장 힘들어하는 “버리기”
대표는 제품을 가장 잘 알기 때문에 모든 기능의 필요성을 설명할 수 있습니다. 그래서 PO/PM의 중요한 역할은 “그 기능이 필요 없는 이유”가 아니라 왜 지금은 아닌지를 설명하는 것입니다.
제품 Roadmap에서 빠지는 것이 아니라 순서가 바뀌는 것입니다.
정리
AI는 개발 속도를 높였지만 프로젝트 관리의 중요성을 줄이지 않았습니다. 오히려 기능을 만드는 비용이 낮아져 범위 관리의 가치가 더 커졌습니다.
완주 관점의 핵심: 4주 동안 무엇이든 만드는 것이 아니라, 실제 사용자가 하나의 핵심 행동을 끝까지 완료할 수 있는 제품만 만듭니다.
4주 프로젝트의 ‘예산’은 돈보다 시간이다
AI가 코드를 빠르게 만들어도 대표와 팀의 검토 시간은 제한되어 있습니다. 따라서 기능마다 개발시간뿐 아니라 의사결정 시간과 테스트 시간을 같이 계산해야 합니다.
예를 들어 소셜 로그인 4종을 붙이는 것은 코드 생성보다 각 개발자 콘솔의 키 발급, Redirect 설정, 테스트에 시간이 더 걸릴 수 있습니다. 그래서 “AI가 10분이면 코드를 만들 수 있다”는 이유만으로 범위에 넣으면 안 됩니다.
기능별 Complexity를 세 가지로 본다
Code Complexity
코드 자체가 어려운가.
External Dependency
심사, API 계정, 외부 업체 설정이 필요한가.
Operational Complexity
런칭 후 사람이 관리하기 어려운가.
예를 들어 결제는 코드 난이도보다 External/Operational Complexity가 높습니다. 이런 기능은 일찍 시작해야 합니다.
범위를 자를 때 사용할 질문 7개
- 이 기능이 없으면 고객이 핵심 가치를 경험하지 못하는가?
- 첫 유료 고객에게 반드시 필요한가?
- 수작업으로 임시 대체 가능한가?
- 고객 10명일 때도 필요한가?
- 데이터가 쌓인 뒤 만들어도 되는가?
- 외부 심사/계정 때문에 일정 위험이 큰가?
- 운영자가 감당 가능한가?
“수작업으로 대체 가능”하면 초기에는 과감히 빼도 됩니다. 예를 들어 첫 20건의 환불을 관리자 콘솔에서 처리하고, 자동 환불 워크플로는 다음 버전에 만들 수 있습니다. 단 데이터 상태는 정확히 관리해야 합니다.
Scope 문서는 한 장이면 충분하다
Goal
4주 후 사용자가 무엇을 할 수 있는가.
Must-have
핵심 사용자 흐름.
Out-of-scope
이번 버전에 절대 하지 않을 것.
Definition of Done
어떤 상태면 완료인가.
Risks
외부 심사, 데이터 이전, 미확정 정책.
Owner
기능별 최종 의사결정자.
이 한 장을 매주 다시 확인하면 기능이 조용히 늘어나는 것을 막을 수 있습니다.
“완벽하지 않은 런칭”을 허용하는 기준
미완성이라고 모든 것이 문제는 아닙니다. 아래 조건을 충족하면 개선 항목이 남아 있어도 런칭할 수 있습니다.
- 핵심 거래가 끝까지 동작
- 데이터 손실 위험 없음
- 보안상 치명적 문제 없음
- 운영자가 예외를 수동 처리 가능
- 고객에게 알려야 할 제한사항이 명확
반대로 기능이 많아도 이 다섯 가지가 안 되면 런칭 준비가 되지 않은 것입니다.