제품비전·MVP·로드맵·생명주기

제품비전·MVP·로드맵·생명주기

작게 만들라는 말은 대충 만들어도 된다는 뜻일까

배움연결 팀은 연락 상태를 공유하는 작은 제품을 만들기로 했다. 어떤 팀원은 “최소 제품이니 권한과 취소 처리는 다음에 넣자”고 하고, 다른 팀원은 “결제·추천·통계·모바일 앱을 전부 넣어야 쓸 만하다”고 한다. 첫 의견은 실제 사용의 위험을 남기고, 둘째 의견은 무엇을 배우려는지 모른 채 범위를 키운다.

두 문제는 모두 ‘최소’를 기능 개수로만 해석할 때 생긴다. 최소 범위는 확인하려는 가설과 실제 사용의 필수 조건을 함께 고려해 정해야 한다. 이 절은 앞에서 찾은 고객문제와 사업 가설을 제품비전, 시험 가능한 범위, 로드맵과 지속 운영·종료 계획으로 옮긴다.

배움연결과 아래 기간·결과·합격선은 자체 교육 사례다. 앞 절 PP-C1의 40개 기관 조사와 아래 PP-P2의 10개 기관 시험은 별도로 만든 자료이며 실제 고객 추적 결과가 아니다.

먼저 연결할 앞선 설명

고객문제와 가치제안은 누구에게 어떤 결과를 제공하고 무엇과 비교할지를 정했다. 요구사항과 수용기준은 약속을 확인 가능한 조건으로 바꾸었다. 전략 로드맵은 선행조건·책임·검증 지점을 연결했으며 여기서는 이를 제품의 학습과 제공 계획에 적용한다.

1. SW 제품 개발계획은 개발 일정만 적는 문서가 아니다

SW 제품 개발계획은 고객문제와 가치·사업 가설을 제품비전, 제공 범위, 검증 가능한 첫 제품, 우선순위·로드맵·자원 및 운영·종료 책임으로 연결하는 계획이다. 무엇을 개발할지뿐 아니라 어떤 근거로 계속하거나 바꿀지, 누구에게 어떤 상태로 제공할지도 정한다.

일정표는 어느 작업을 언제 할지 설명하지만 그 작업의 가치가 맞는지를 대신 판단하지 않는다. 제품 개발계획에는 대상 고객, 해결할 문제, 제외 범위, 효과·위험 가설, 성공·중단 조건, 실제 사용을 지원할 사람과 비용이 필요하다. 이미 끝낸 개발량을 고객문제의 해결량으로 세지 않는다.

비전·목표·로드맵·작업 목록을 구별한다

제품비전은 어떤 고객의 삶이나 업무를 어떤 방향으로 바꾸려는지 표현한 장기적인 가치 방향이다. 배움연결의 비전은 ‘작은 강좌 운영기관이 담당자 교대에도 대기 안내를 빠뜨리지 않고 이어 갈 수 있게 한다’로 정한다. ‘기능 30개 출시’는 비전이 아니라 산출물 수다.

백로그는 해야 할 모든 일을 확정한 계약서가 아니라 우선순위를 다시 정할 작업 후보 목록이다. 반대로 고객에게 이미 약속한 제공 범위나 보호 조건은 단순 후보처럼 조용히 지울 수 없다. 약속 변경은 영향과 안내·승인을 별도로 다룬다.

비전이 유지되더라도 제품 방식은 바뀔 수 있다. 새 앱이 아니라 기존 접수 화면과의 연결이 더 적절할 수 있고, 자동 알림보다 담당자 인계가 먼저일 수 있다. 수단을 바꾸는 것을 비전 포기로 오해하지 않으려면 처음부터 제품명보다 가치 방향을 적는다.

2. 무엇을 모르는지에 따라 먼저 확인할 것이 달라진다

제품의 불확실성을 ‘잘될까?’ 하나로 묶으면 시험을 설계하기 어렵다. 이 사례에서는 다음 네 질문으로 나눈다. 질문 분류와 판정 조건은 학습을 위한 자체 설계이며 모든 방법론의 고정된 분류표는 아니다.

틀렸을 때 계획 전체를 깨뜨리는 가정을 먼저 확인한다. 기존 프로그램에서 필요한 상태를 가져올 수 없는데 추천 화면부터 정교하게 만들면 앞선 전제가 무너질 때 많은 일을 버리게 된다. 반대로 기술 연결은 충분히 확인됐지만 사용자가 문제를 중요하게 여기지 않는다면 더 많은 부하 시험보다 가치 가설 확인이 우선이다.

The Lean Startup의 공개 설명은 제품을 만든 양보다 고객과 사업 가설에 대해 무엇을 배웠는지를 중시하고, 만들기·측정·학습의 반복으로 방향을 조정한다. 이 원리는 안전조치를 생략하거나 모든 결과를 성공으로 해석하라는 뜻이 아니다.¹

3. PoC·프로토타입·MVP가 답하는 질문

PoC(개념검증)는 특정 아이디어나 기술적 가정이 정한 조건에서 가능한지를 확인하는 시험이다. 예를 들어 승인된 시험 자료로 기존 접수 상태를 읽을 수 있는지 확인한다. 이 결과만으로 고객이 값을 지불할지 알 수는 없다.

프로토타입은 상호작용이나 형태를 시험하기 위한 모형이다. 종이 화면으로 담당자가 ‘연락 전·연락 중·거절·종료’를 구별하는지 확인할 수 있다. 화면이 눌린다는 사실은 실제 권한·저장·전송이 구현됐다는 뜻이 아니다.

최소기능제품(MVP)은 중요한 고객·사업 가설을 실제 사용이나 이에 준하는 검증 가능한 행동으로 학습하기 위해 필요한 최소 범위의 제품이다. 최소한의 노력으로 학습을 시작한다는 관점에 이름의 핵심이 있으며, 최소 품질이나 필수 의무의 면제를 뜻하지 않는다.¹

세 용어의 사용 범위는 조직마다 일부 겹칠 수 있다. 여기서는 이름보다 시험하려는 질문, 실제로 구현된 범위, 참여자에게 제공하는 약속과 증거의 한계를 기록한다. 종이 화면으로 사용성을 확인한 것을 ‘MVP로 시장 검증 완료’라고 쓰지 않는 것이 중요하다.

사람이 일부 처리를 돕는 방식도 초기 학습에 사용할 수 있다. 다만 참여자에게 자동 처리인 것처럼 속이지 않고 사람이 보는 정보·권한·처리 범위를 알린다. 수작업 지원 시간을 비용에서 빼면 나중에 자동화하지 못했을 때의 지속 가능성을 오판한다. 필요한 품질이 낮아지는 것이 아니라 검증할 기능의 폭을 줄이는 것이다.

4. 작은 범위에도 처음부터 끝까지 이어지는 일이 있어야 한다

자체 MVP안 PP-P1은 ‘동의한 한 유형의 기관에서 담당자가 취소 안내의 진행을 이어받을 수 있는가’를 확인한다. 새 강좌 추천이나 결제·전국 기관 통합은 제외한다. 기존 배정 원장을 대체하지 않고 정한 상태와 안내 결과를 사용하는 범위다.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

권한 있는 담당자가 대상·상태를 확인한 뒤 다음 담당자에게 인계한다. 연락 결과는 실패·거절·종료를 구별하고 문의·정정·연락 중단을 처리한 뒤 기록과 범위를 종료한다. 이는 업무 순서이며 기존 배정 원장을 대체하지 않는다.

화살표는 사용자가 해야 할 일이 이어지는 순서다. 각 단계가 전부 거대한 기능이라는 뜻은 아니다. 하지만 실패했을 때 어디에서 멈추고 누가 도울지 빠지면 실제 사용의 결과를 관찰하기 어렵다.

디자인을 단순하게 할 수는 있어도 다른 기관의 자료가 보이는 위험을 ‘다음 버전에서 해결’로 미룬 채 실제 사용을 시작하지 않는다. 실제 배정의 변경 권한을 다루지 않는다면 그 경계도 명확히 한다. 연구에 필요 없는 자동 추천·새 결제 경로는 현재 학습을 방해하므로 제외한다.

GOV.UK의 discovery와 alpha 설명은 문제를 먼저 이해하고 위험한 가정을 시험하는 단계와 실제 서비스 제공을 구별한다. 여기서는 그 구별만 참고하며 영국의 평가·승인 절차나 기간을 국내 제품의 의무로 적용하지 않는다.²³

5. 시험 전에 산식과 중단 조건을 적는다

PP-P2는 제품안 PP-P1을 사용한 10개 기관을 28일 동안 끝까지 관찰했다고 가정한다. 열 기관 모두 같은 관찰 기간을 채웠고, 반복 사용이 가능한 주간 강좌를 운영한다. 앞 절의 40개 기관 조사와는 다른 교육용 자료다.

다음 조건을 시험 전에 정했다고 하자. ‘최초 전체 흐름 완료’는 대상 확인부터 인계·결과 기록까지를 실제로 마친 기관, ‘반복 사용’은 첫 성공 뒤 별도의 주간 업무에서 다시 같은 흐름을 마친 기관이다. 로그인·화면 열람만은 사용 완료로 세지 않는다.

지원 시간 320/8=40분은 28일 총 지원 시간을 그 기간 활성 기관 수로 나눈 값이다. 주 지원 시간은 같은 주의 지원 시간(분)과 그 주의 활성 기관 수를 짝지어 계산해야 한다. 네 주를 합쳐 기관·주당 평균을 보려면 주별 활성 기관 수의 합인 활성 기관·주 노출량이 필요하다. 28일 중 한 번 활성인 8개 기관을 네 주 내내 활성인 32 기관·주로 바꾸어 320/32=10분이라고 계산할 근거는 없다. 제품·고객지원 담당은 주별 분모와 지원 기록을 확보하고 미판정을 해소한다.

기관·주를 읽는 별도 작은 예를 보자. 첫 주에는 8개 기관에 지원 160분, 둘째 주에는 첫 주의 기관 중 4개 기관에 지원 80분이었다고 가정하면 첫 주 160/8=20분/기관·주, 둘째 주 80/4=20분/기관·주다. 두 주의 지원 240분을 활성 기관·주 8+4=12로 나눈 값도 20분/기관·주다. 첫 주와 둘째 주에 같은 기관이 다시 활동해도 두 주의 지원 기회를 따로 세므로 분모는 고유 기관 수 8이 아니라 12 기관·주다. 지원을 많이 받는 주와 적게 받는 주가 다르면 전체 평균만으로 각 주의 조건 충족을 판단할 수 없으므로 주별 값도 함께 본다. 이 예의 주별 자료는 PP-P2에서 관찰한 자료가 아니며, PP-P2의 운영 목표 미판정은 그대로다.

최초 흐름을 마친 기관이 8개라면 활성 비율은 8/10=80%다. 그중 반복 사용한 6개를 분자로 삼으면 6/8=75%다. 이 75%를 전체 참여 기관 대비 기준인 70%와 비교해 통과시키면 분모를 바꾼 것이다. 전체 대비 반복 사용은 60%로 남긴다.

처리 100건 중 98건이 중복 없이 진행됐다고 해서 ‘98%이므로 품질 통과’라고 할 수 없다. 미리 정한 중복 안내 0건 조건은 실패했다. 실패한 2건의 원인·피해·수정과 재시험이 필요하며, 실제 확인한 내용보다 넓게 ‘보안 사고 없음’을 주장하지 않는다.

이용 기간이 28일보다 짧은 기관이 섞였다면 같은 표로 비교할 수 없다. 가입 시점이 비슷하고 같은 기간을 관찰한 집단을 코호트로 묶거나, 아직 기간을 채우지 않은 상태를 별도로 남겨야 한다. 반복 사용의 기간·기회가 다른 고객을 무조건 같은 분모로 넣지 않는다.

실패는 폐기 명령이 아니라 구체적인 다음 질문이다

PP-P2에서는 전면 확대를 보류한다. 중복 안내는 기록·재시도·담당 교대 중 어느 지점에서 생겼는지 고치고, 처음 사용하지 못한 두 기관과 한 번만 사용한 두 기관의 경험을 나누어 조사한다. 문제 자체가 약한 것과 화면·설정 때문에 사용하지 못한 것은 서로 다른 원인이다.

가설이 유지되고 전달 방식만 잘못됐다면 제품을 개선해 다시 확인할 수 있다. 고객 집단이나 핵심 가치 가설을 바꾸는 경우에는 피벗이라고 부르는 방향 전환을 검토한다. 예를 들어 자동 안내보다 교대 인계가 중요하다는 근거가 모이면 그 가치를 중심으로 다시 설계한다. 버튼 색을 바꾸는 모든 수정을 피벗이라고 부르지는 않는다.

반대로 충분한 조사에서 문제가 거의 없거나 현재 대안보다 낫지 않다면 중단이 합리적일 수 있다. 이미 쓴 개발비만을 이유로 계속하지 않는다. 이 판단은 소규모 관찰을 전체 시장의 실패로 일반화하는 것과도 다르다. 관찰 범위·수정 가설·다음에 필요한 증거를 함께 적는다.

6. 로드맵은 기능을 시간순으로 배열하는 것에서 끝나지 않는다

PP-P3의 로드맵은 다음처럼 문제·산출물·판정·책임을 연결한다. 순서는 합리적인 선행관계이고 각 날짜를 확정한 실제 프로젝트 계획은 아니다.

작업의 우선순위는 필수 의무·치명적 위험·선행조건을 먼저 분리하고, 남은 후보에서 가치·학습 효과·비용을 비교한다. 중요해 보이는 기능에 점수를 높게 줘서 기관 간 자료 노출이나 미확정 입력 계약을 상쇄하지 않는다.

로드맵에서 먼 단계일수록 조건과 불확실성을 더 명확히 표시한다. 현재는 핵심 인계 문제도 확인되지 않았는데 ‘3개월 뒤 전국 확대’를 확정 약속으로 쓰면 학습 결과가 일정에 종속된다. 고객과 이미 합의한 계약·종료일이 있다면 그 제약은 따로 지키면서 범위와 대안을 조정한다.

7. 시장의 생명주기와 제작·운영의 생명주기는 다르다

제품의 시장 생명주기는 판매·이익·경쟁 상태의 변화를 도입·성장·성숙·쇠퇴 등으로 살피는 관점이다. OpenStax는 이 구별과 함께 모든 제품이 같은 속도로 모든 단계를 거치지는 않는다는 한계를 설명한다.⁴ 따라서 한 달 매출 하락만으로 ‘쇠퇴기’라고 확정하지 않는다.

소프트웨어에서는 같은 제품 안에서도 기능·고객집단·계약의 단계가 다를 수 있다. 신규 기관 도입은 늘지만 오래 사용한 기관의 해지가 늘어나는 상황도 있다. 전체 매출만 보면 그 차이를 놓치므로 신규 도입·반복 사용·유지·지원 부담을 구분해 본다.

제작·운영의 생명주기는 문제 발견, 가정 검증, 실제 제공, 지속 개선, 종료를 거치며 누가 어떤 책임을 수행하는지 보는 관점이다. ‘공개 서비스로 운영 중’이라는 상태가 시장에서 성장 중이라는 뜻은 아니다. 시장의 성숙과 소프트웨어의 지원 종료도 같은 사건이 아니다.

GOV.UK의 live 안내는 지속 지원과 개선, 여러 채널에 대한 영향을 확인하는 운영을 설명한다. 배움연결에서도 고객이 늘 때 새로운 기능만 늘리지 말고 문의·실패·수정·보호·복구를 수행할 자원을 확보해야 한다.⁵ 다만 이 자료를 국내 법정 운영 기준이나 이 사례의 특정 인력 규모 근거로 쓰지는 않는다.

종료도 제품이 지켜야 할 약속이다

새 고객을 받지 않는 것, 기능 하나를 없애는 것, 제품 전체 지원을 끝내는 것은 서로 다르다. 종료할 때에는 기존 고객의 남은 업무와 정보가 어디로 이어지는지 먼저 확인한다. GOV.UK의 종료 안내도 사용자의 다음 경로, 사전 안내와 정보 보호를 함께 다룬다.⁶

배움연결의 자체 종료안은 신규 계약 중단일, 기존 기관의 이용 종료일, 진행 중 안내 처리, 필요한 자료 제공·보존·파기 조건, 접근권한과 통신 계약의 종료, 문의 담당과 결과 확인을 분리한다. 다음 제품을 제공하더라도 불필요한 옛 처리 경로를 영구히 유지하지 않고 검증된 종료를 계획한다.

종료 공지를 게시한 것과 고객의 업무·자료 처리가 끝난 것은 다르다. 안내를 받지 못한 기관, 실패한 자료 제공, 남은 계정과 예약 발송이 있는지 확인해야 한다. 계약·법령의 구체 의무는 실제 대상에 맞게 확인하며 이 원고가 새로운 공통 보존기간이나 통지 기한을 정하지 않는다.

8. 자체 10점 문제와 완성 답안

MVP를 PoC·프로토타입과 비교하고, PP-P2의 관찰 결과로 확대 여부를 판단하시오.

‘작은 제품’이라고만 정의하지 말고 무엇을 확인하려는지와 무엇을 아직 확인하지 못했는지까지 답한다. 아래는 자체 교육용 문제·답안이며 공식 채점기준은 아니다.

답안 목차·풀이·교정 근거 보기

목차: 확인할 질문 → 실제 제공 범위 → 분모·품질·지원 계산 → 다음 결정.

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

PP-P2는 전체 반복 6/10=60%로 사전 70% 조건에 미달하고 중복 2건으로 중복 0 조건에 실패했다. 28일 지원 320분/활성 8개 기관=40분은 주 단위 목표 30분 판정 근거가 아니다. 전면 확대를 보류하고 가치 가설·사용 장애·중복 원인·주별 지원 기록을 구분해 다음 결정을 내린다.

완성 답안

MVP는 중요한 고객·사업 가설을 학습하는 데 필요한 최소 범위의 제품이다. 기술 연결 가능성을 묻는 PoC, 상태와 행동의 이해를 묻는 프로토타입과 구별한다. 실제 사용을 제공하면 기관별 권한·실패 처리·지원·종료 조건을 범위 안에서 갖춰야 하며 필수 품질을 최소화한다는 뜻이 아니다.

PP-P2의 최초 사용은 8/10=80%, 전체 반복 사용은 6/10=60%, 활성 기관 중 반복은 6/8=75%다. 전체 대비 70%라는 사전 기준을 75%로 통과시키지 않는다. 처리 100건 중 중복 2건은 중복 0건 조건의 실패이며, 28일 총 320분/활성 8개 기관=40분을 주 목표 30분과 바로 비교할 수 없다. 주별 활성 기관·지원 기록이 없어 운영 목표는 미판정이다.

따라서 전면 확대를 보류하고 중복 원인, 미사용·일회 사용의 이유, 지원 부담을 확인한다. 가치 가설이 유지되면 전달 방식을 수정하고 고객·가치 자체가 틀렸다는 근거가 있으면 방향 전환이나 중단을 검토한다. 소규모 관찰을 전체 시장 검증이나 모든 보안의 증명으로 표시하지 않는다.

9. 자체 25점 문제와 완성 개발계획

배움연결의 SW 제품 개발계획을 제품비전·MVP·판정 기준·로드맵·생명주기와 종료 책임까지 연결하여 작성하시오.

답안은 ‘MVP를 만든다, 성과를 관리한다’로 끝내지 않는다. 앞에서 정한 대상·제외·수치·책임과 실제 보류 결정을 사용한다.

답안 목차·풀이·교정 근거 보기

목차: 비전·가설 → 최소 범위·필수 조건 → 시험·선택 → 운영·종료.

위험 가정과 필수 조건 아래 실제 인계·결과·지원·종료의 MVP 범위는 관계 그림에서 확인하고, 아래 완성 답안에서 조건과 판단을 확인한다. 사전 기준과 관찰에 따라 가설·원인을 구별하는 결정은 관계 그림에서 확인하고, 아래 완성 답안에서 조건과 판단을 확인한다. 단계의 증거·책임은 제품 로드맵표, 시장/제작/기술 관점은 생명주기 비교표에서 확인한다.

완성 개발계획 답안

제품비전은 소규모 강좌 운영기관의 담당자 교대에도 대기 안내가 끊기지 않게 하는 것이다. 고객문제·현재 대안·지불과 지원 가설을 유지하고 새 앱 출시나 기능 개수를 목표 자체로 삼지 않는다. 연결 가능성·사용성·가치·지속 가능성 중 틀리면 계획을 크게 바꿀 가정을 먼저 확인한다.

첫 MVP는 한 유형의 제한 기관에서 권한 있는 담당자가 안내 대상·진행 상태를 확인하고 인계·결과·실패·거절·종료를 처리하는 전체 흐름으로 정한다. 기존 배정 원장을 대체하지 않으며 자동 추천·새 결제·전국 통합은 제외한다. 기관 간 자료 접근 거부, 잘못된 결과의 수정과 문의·종료 책임은 포함한다. 모형 화면과 기술 실험을 실제 제공 제품의 검증으로 혼동하지 않는다.

PP-P2는 동일한 28일을 관찰하고 전체 반복 70% 이상·중복 0건·활성 기관당 주 지원 30분 이하를 자체 조건으로 정한다. 관찰 결과는 전체 반복 60%·중복 2건으로 기준에 미달하며, 28일 총 지원 320분의 주별 분모가 없어 주 지원 목표는 미판정이다. 확대를 보류하고 주별 활성 기관·지원 기록도 확보한다. 고객 담당은 미사용 이유, 개발·운영 담당은 중복·권한·지원 원인, 제품 담당은 가치 가설을 대조한다. 개선 후 같은 정의로 재확인하거나 근거에 따라 고객·가치·방식을 바꾸며 과거 기준을 소급해 성공으로 만들지 않는다.

로드맵은 문제 확인→위험 가정 확인→제한 사용→확대 검토→운영·종료로 구성하고 각 단계의 증거와 책임을 붙인다. 실제 운영에서는 반복 사용·계약 유지와 문의·실패 비용을 함께 보며, 시장의 도입·성장·성숙·쇠퇴와 제작 상태를 구별한다. 종료 시에는 신규 계약, 기존 이용, 진행 중 안내, 자료 처리, 권한·통신 계약과 문의 종료를 나누어 확인한다. 출시·계산 통과·공지 게시만으로 제품의 책임이 끝났다고 보고하지 않는다.

10. 자기교정

조건을 바꾸어 다시 판단한다

반복 사용이 7개 기관으로 늘면? 먼저 원래 조건에서 바뀐 항목만 표시하고 답을 적는다.

조건 변경의 풀이·교정 보기

전체 7/10=70%, 활성 8개 기관 대비 87.5%다. 전체 반복 조건은 충족하지만 중복 실패와 주 지원 시간의 미판정까지 없어지지는 않는다. 판정표의 조건을 각각 유지한다.

28일 지원 총시간이 240분으로 줄면? 먼저 원래 조건에서 바뀐 항목만 표시하고 답을 적는다.

조건 변경의 풀이·교정 보기

기간 활성 8개 기관으로 나누면 28일 기준 30분이지만 여전히 주 단위 목표를 판정할 수 없다. 별도 가정으로 같은 한 주의 지원 240분과 그 주 활성 8개 기관이 확인된 경우에만 240/8=30분/기관·주로 그 주의 목표 충족을 판단한다. 다른 주와 확대 뒤 지속 가능성은 별도다. 지원을 받지 못한 문의를 누락해 시간을 줄여서는 안 되며 측정 정의를 유지한다.

고객이 상태 공유보다 담당자 교육을 원한다면? 먼저 원래 조건에서 바뀐 항목만 표시하고 답을 적는다.

조건 변경의 풀이·교정 보기

요청을 바로 새 결론으로 쓰지 말고 실제 오류·행동을 대조한다. 교육과 기존 도구로 문제가 해결되면 소프트웨어 범위나 제공 방식을 수정할 수 있다. 가설과 학습에서 가치와 수단을 구별한다.

회독의 핵심

제품계획은 가치 가설을 제공 범위·판정·책임에 연결한다. PoC·프로토타입·MVP는 이름이 아니라 확인한 질문과 증거로 구별한다. 작게 제공해도 실제 사용의 필수 조건과 끝까지 이어지는 흐름은 필요하다. 확대·운영·종료는 날짜나 기능 수가 아니라 고객 결과와 감당 가능한 책임을 보고 결정한다.

근거와 사용 범위

외국 정부 지침을 국내 법정 의무로 옮기지 않았고 기간·합격선·고객 수·운영 약속은 자체 교육 가정이다. 실제 사용자 시험·보안·제품 출시 또는 사람의 독립적인 승인을 수행한 원고가 아니다.

Footnotes

1. The Lean Startup, Methodology, “Develop An MVP”, “Validated Learning”, “Build-Measure-Learn”. 2026-09-20 공개 본문 대조. 가설·학습·방향 조정의 개념만 참고했으며 PP-P1~P3의 정의 적용·수치·표·답안은 자체 작성이다. https://theleanstartup.com/principles ↩ ↩²

2. GOV.UK Service Manual, How the discovery phase works, 문제·맥락·다음 단계 판단. 2026-09-20 대조. https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works ↩

3. GOV.UK Service Manual, How the alpha phase works, 위험 가정과 프로토타입의 범위. 2026-09-20 대조. https://www.gov.uk/service-manual/agile-delivery/how-the-alpha-phase-works ↩

4. OpenStax, Principles of Marketing, §9.3 “The Product Life Cycle”, 네 단계와 비선형 진행의 한계. 책 발행일 2023-01-25와 이번 관찰일 2026-09-20을 구별한다. 원문 그림·기업 사례·문제를 복제하지 않았으며 현재 표시된 권리조건의 독립 검토는 대기다. https://openstax.org/books/principles-marketing/pages/9-3-the-product-life-cycle ↩

5. GOV.UK Service Manual, How the live phase works, 지속 지원·개선과 채널 영향. 2026-09-20 대조. https://www.gov.uk/service-manual/agile-delivery/how-the-live-phase-works ↩

6. GOV.UK Service Manual, Retiring your service, 사용자 필요·안내·정보 보호. 2026-09-20 대조. https://www.gov.uk/service-manual/agile-delivery/retiring-your-service ↩