첫 번보다 빠른 두 번째, 누적 자산 활용법

두 번째 MVP의 진짜 강점은 시즌1 작업의 '찌꺼기'다.

14일 → 9일, 그 차이가 만들어지는 자리

박서연 씨는 첫 MVP를 Lovable로 14일 만에 출시했어요. 마케팅 칼럼 자동 분류 SaaS, 100명 가입, 30명 활성, 5명 유료. 6개월 뒤, 두 번째 MVP를 시작했습니다. 같은 도메인, 마케팅 SNS 콘텐츠 성능 분석 도구.

첫 번째 때 필요했던 작업들을 되짚어 봤어요.

• 로그인 화면? 첫 번째에서 Supabase 인증 연동했으니 코드 스니펫 하나면 OK
• API 구축? 첫 번째에서 Claude API 연동 경험이 있으니 같은 패턴
• 데이터베이스 스키마? 첫 번째 회고 문서를 펴서 "이번엔 이 부분이 불필요했으니 빼자"
• 디자인 시스템? 첫 번째 Figma 컴포넌트를 그대로 가져와 2시간만에 프로토타입

결과는 9일이었어요. 14일에서 거의 절반 줄었습니다.

여기서 중요한 건, 그가 더 빨리 타이핑하지 않았다는 것이에요. 그가 더 지능적으로 결정했습니다. 무엇을 건너뛸지, 무엇을 재사용할지를 이미 알고 있었기 때문이에요.

두 번째 MVP는 빠른 게 아니라, 똑똑한 것입니다. 그 똑똑함의 원천은 첫 번째에서 남은 찌꺼기 자산들이에요.

첫 MVP 작업에서 남겨진 4가지 자산

1. 코드: 작동하는 패턴의 모음

첫 MVP의 코드는 레거시가 맞아요. 6개월 후엔 자신의 코드도 이해 안 될 정도. 그럼에도 코드가 자산인 이유는, "뭔가 작동했던 패턴"이 남아있기 때문이에요.

박서연 씨가 재사용한 건 정확히는 코드가 아니라, "Supabase 인증이 이런 식으로 작동한다"는 패턴, "Claude API 호출이 이렇게 구조화된다"는 패턴이었어요. Cursor나 Claude Code는 이런 패턴을 인식하고 다음 MVP에 자동으로 적용해요.

첫 번째 프로젝트의 코드는 두 번째 프롬프트의 맥락이 됩니다. "이 기능을 만들 때 먼저 이 구조를 확인해봐"라는 힌트가 돼요.

2. 관계: 신뢰할 수 있는 사람 목록

첫 MVP 출시 후 박서연 씨는 초기 사용자 30명과 메시지를 주고받았어요. 핵심은 5명이었습니다. 두 번째 MVP를 만들 때, 먼저 이 5명에게 아이디어를 보냈어요. 3명에게서 반응, 2명은 베타 테스트 자청.

차갑게 모은 고객 100명과 따뜻하게 소개받은 고객 40명 중 활성도(월 3회 이상 방문)는 37%와 68%로 차이가 납니다.

3. 노하우: 함정과 우회로의 지도

첫 MVP에서 박서연 씨는 초기 스키마 설계에서 실수했어요. 컬럼을 3번 수정했고, 마이그레이션에 2일이 낭비. 회고 문서에 기록했죠. "다음에는 MVP 단계에선 이 컬럼은 빼고, 사용자 피드백 후 추가하자."

두 번째 MVP에서 같은 과정을 반복하지 않았어요. 처음부터 "피드백 이후 추가할 것"과 "지금 꼭 필요한 것"을 구분. 초기 스키마는 50% 더 단순했고 마이그레이션 비용 최소화.

"두 번째는 첫 번째 노하우를 그대로 따라하면 된다"고 생각하면 망칩니다. 중요한 건 패턴 인식이에요. 함정 하나가 또 다른 상황에서 반복되면 그때 룰로 전환해야 합니다.

4. 도구: 설정된 워크플로우

박서연 씨가 첫 MVP에서 쓴 도구: Cursor, Figma, Supabase, Vercel, Linear, Notion. 두 번째도 같은 도구. 하지만 이번엔 설정이 이미 되어 있었어요. Cursor는 이전 프로젝트의 확장 프로그램과 커스텀 설정 자동 인식. Figma 라이브러리 정렬됨. Supabase 분석 대시보드 5분 세팅.

또 박서연 씨는 첫 번째에서 "이 도구는 내 워크플로우에 안 맞는다"는 것도 알아냈어요. 처음 계획했던 관리 도구를 쓰지 않고, 두 번째엔 처음부터 Linear만. 선택지가 줄어들고 집중력이 올라갔습니다.

의식적으로 누적하기, 작업 중 메모의 힘

4가지 자산은 자동으로 쌓이지 않아요. 의식적 기록이 필수입니다.

박서연 씨는 첫 MVP 개발 중 매일 저녁 10분씩 세 가지 기록:

1. 오늘 뭐 했나: "로그인 연동 완료", "DB 마이그레이션 2차"
2. 뭐가 느렸나: "스키마 재설계로 2시간 낭비", "Figma 피드백 1시간"
3. 다음엔 뭐 다르게 할까: "스키마는 사용자 피드백 후에 추가", "디자인은 프로토타입 전 협업자 체크"

3개 문장짜리 노션 페이지에 불과했지만, 14일이 끝났을 때 회고 틀이 완성. 박서연 씨는 이 메모를 "두 번째 MVP 체크리스트"로 변환했어요.

두 번째 MVP 빠르게 만드는 체크리스트:
- 스키마: 피드백 이전 필수 항목만 (이전 4개 → 2개로)
- 디자인: 컴포넌트 라이브러리 미리 복사
- 관계: 초기 사용자 5명 미리 물어보기
- 도구: 검증된 조합만 사용 (새로운 도구 X)

이 체크리스트가 9일을 만들었어요.

14일 vs 9일, 시간대별 분석

가장 큰 절감:

1. 기획: 스키마 단순화로 8시간 절감
2. UI: 컴포넌트 라이브러리로 4시간 절감
3. 디자인: 손에 익은 디자인 시스템으로 8시간 절감

자산 재사용 워크플로우

Step 1. MVP 끝나자마자 (1~2일 내)

하지 말 것: 즉시 마케팅 올인 / 새 기능 추가 (피드백 없이)

해야 할 것:

• 코드 한 번 정독 (30분): "어떤 패턴이 작동했나"
• 도구 설정 스크린샷 (30분)
• 초기 사용자 5명 리스트 정리 (30분): 이름, 연락처, 풀어준 문제
• 개발 일지에서 "2차에 안 할 일" 추출 (1시간)

Step 2. 운영 중 (한 달 이상)

• 피드백에서 안 나온 기능: "아무도 안 썼다" → 다음에는 빼기
• 가장 많이 수정한 부분: "여기를 3번 바꿨다" → 다음엔 먼저 사용자한테 물어보기
• 시간이 오래 걸린 부분: "수익성 없는데 시간 많이 들었다" → 우선순위 낮추기

Step 3. 다음 MVP 시작 직전 (1일 전)

1. 코드: 첫 프로젝트 레포 열어 "패턴만 가져올 것" Cursor 프롬프트에
2. 관계: 초기 사용자 5명에게 "다음 아이디어 봐줄래?" 메시지
3. 노하우: 체크리스트 읽으며 "이 과정 스킵" 결정
4. 도구: 검증된 도구 조합 먼저 세팅

9일 코스 타임라인

마무리

두 번째 MVP가 빠른 이유는 단순히 시간 관리 때문이 아니에요. 당신이 이미 똑똑해졌기 때문입니다. 첫 번째 14일이 만든 자산이 다음 9일을 만들어요.

하지만 주의할 게 있어요. 빨라진 건 좋은데, 같은 실수를 또 하면? 더 빠르게 똑같은 함정에 빠집니다. 다음 편에서는 "두 번 본 실수는 패턴이다"라는 원칙으로, 자신의 실수를 어떻게 미리 방지할 수 있는지를 다룹니다.

이전 편: Persevere의 함정, 좀비 프로젝트 진단법
다음 편: 같은 실수 안 하는 법, 패턴 인식의 기술

이 글에 등장하는 인물(박서연)에 대한 안내
박서연 씨는 페일스쿨이 만든 가상의 페르소나입니다. 단, GitHub Copilot 생산성 보고서, Pieter Levels 시리즈 빌더 사례 등은 모두 실제입니다.

김민철, 프리아이브 CEO, 페일스쿨