시리즈 빌더의 운영법, 한 사람이 여러 MVP

시리즈 빌더는 멀티태스킹이 아니라 페이즈 관리다.

"동시에 두 개를 운영할 수 있을까?"

박서연 씨는 첫 번째 MVP(마케팅 칼럼 자동 분류 도구)를 6개월간 운영했어요. 이제 월 50명씩 신규 사용자가 들어오고, 유료 사용자도 5명. 그런데 머릿속에는 4개의 새 아이디어가 맴돕니다. "다음 것도 지금 만들어야 할까? 동시에 두 개를 운영할 수 있을까?"

이준호 씨도 비슷해요. 첫 MVP는 이미 월 250만 원 수익을 만들고 있지만, "계속 이것만 해야 하나" 싶어요. 새로운 서비스 3개를 구상 중.

여기서 두 가지 길이 갈려요. 하나는 진짜 시리즈 빌더처럼 움직이는 것. 또 하나는 멀티태스킹한다고 착각하면서 셋 다 죽이는 것. 차이는 "동시"가 아니라 "페이즈"예요.

멀티태스킹의 거짓, 동시 O 순차 X

"멀티태스킹은 뇌에 해롭다"는 얘기를 많이 듣지만, 시리즈 빌더가 직면한 현실은 조금 달라요. 우리는 정말로 동시에 여러 프로젝트를 진행해야 합니다. 문제는 방식이에요.

멀티태스킹과 동시 진행은 달라요.

• 멀티태스킹: "모든 프로젝트를 매일 조금씩 건드리는 것" → 생산성 지옥
• 동시 진행: "각 프로젝트를 다른 페이즈에 놓고 동시에 관리하는 것"

박서연 씨의 첫 번째 MVP는 지금 Maintenance 페이즈예요. 주 1~2시간으로 충분. 두 번째 MVP는 아직 Production 페이즈, 주 15시간. 같은 시간대에 두 프로젝트가 움직이지만, 뇌의 부담이 달라요. 첫 번째는 자동화된 일이고, 두 번째는 창의적인 일이기 때문입니다.

Pieter Levels는 이를 극단적으로 증명했어요. Nomad List, Remote OK, Photo AI, Hoodmaps를 거의 동시에 운영. 하지만 각 프로젝트를 다른 페이즈에 놨어요. 어떤 것은 Growth, 어떤 것은 Maintenance, 어떤 것은 Sunset.

시리즈 빌더의 비결은 "많은 프로젝트를 한다"가 아니라 "각 프로젝트를 다른 페이즈에 놓는다"입니다.

각 MVP의 페이즈 매핑, Production에서 Sunset까지

Production 페이즈 (출시 전~첫 100명)

집중력이 최고로 필요. 주 15~20시간. 설계 변경, 사용자 피드백 즉각 반응. 시리즈 빌더라면 보통 한 프로젝트만 이 단계에 두는 것이 현실적이에요.

Growth 페이즈 (100~1,000명)

기본 기능은 정해졌어요. 마케팅, 사용자 피드백 반영, 소소한 기능 추가. 주 8~12시간. 창의력보다는 실행력이 중요.

Maintenance 페이즈 (1,000명 이상 안정)

버그 패치, 서버 유지, 고객 지원. 자동화 가능. 주 2~4시간. 한 사람이 3~4개의 Maintenance 상태 프로젝트를 동시에 운영하는 것이 가능해요. 이 단계에서는 진짜 멀티태스킹이 가능.

Sunset 페이즈 (의도적 종료)

신규 사용자 모집 중단, 기존 사용자를 다른 솔루션으로 유도. 주 1~2시간. 마지막 업데이트, 피드백 수집, 마지막 메시지, 서버 다운.

많은 시리즈 빌더가 빠지는 함정은 여러 프로젝트를 모두 Growth 페이즈에 놓으려는 것이에요. 그럼 망합니다. 최대 2개까지가 성장 가능한 범위예요.

이준호 씨 사례: 첫 MVP는 Growth 페이즈 중후반(월 250만 원, 주 10시간). 새 아이디어 3개. 그 중 두 개는 잠시 미루기로(Sunset). 하나만 Production으로. 결과: 세 프로젝트가 모두 산다.

주 단위 캘린더로 보기

시리즈 빌더가 가장 자주 하는 실수는 "분배 없이 시작"하는 것. "이번주엔 첫 번째 MVP에 집중"이라고 결심해도, 월요일에 두 번째 버그 터지고, 수요일에 세 번째 아이디어가 좋아 보여 손댐. 금요일엔 모두 중단.

해결책은 주 단위 캘린더예요. Sahil Lavingia는 매주 월요일 "이번주의 2~3개 빅 프로젝트"를 정하고, 매일 아침 4시간의 "creative work"를 그중 하나에 집중합니다.

박서연 씨 샘플 캘린더 (회사 + MVP 병행)

월요일: 회사 8h → 저녁 7~9시 (2h) 두 번째 MVP 개발
화요일: 회사 8h → 저녁 7~8시 (1h) 첫 번째 MVP 유지보수
수요일: 회사 8h → 저녁 7~9시 (2h) 두 번째 MVP 개발
목요일: 회사 8h → 저녁 7~8시 (1h) 사용자 피드백 (1번, 2번 모두)
금요일: 회사 8h → 저녁 7~9시 (2h) 두 번째 MVP 마무리
주말  : 완전 휴식 또는 1시간 자유

주 9시간을 두 프로젝트에 분배. 첫 번째 Maintenance(1h/주), 두 번째 Production(8h/주). 명확하고 수정되지 않습니다. 번아웃도 없고, 두 프로젝트 모두 진전.

스탠포드 경영대학원 연구에 따르면, 일관된 시간 할당으로 진행된 다중 프로젝트는 "임의 할당"보다 완료율이 2.3배 높다고 합니다.

동시 vs 순차, 자원 한계 인식하기

"이게 정말 동시에 가능한가?" 정직하게 답하면 상황에 따라 다릅니다.

의사결정 트리

• 회사 풀타임 + MVP → 동시 진행 최대 2개 (1 Maintenance + 1 Production)
• 회사 풀타임 + 야간 개발 → 최대 1.5개 (1 Maintenance + 0.5 Production)
• 메이커 풀타임 → 최대 4개 (3 Maintenance + 1 Growth, 또는 2 Maintenance + 2 Growth)

이준호 씨 상황: 월급 500만 원, MVP 월 250만 원. 회사 못 나감. 동시 진행 최대 1.5개가 현실. 3개 아이디어 중 가장 유망한 1개만 Production, 나머지 2개는 "언젠가 할 리스트"로. 3개월 뒤 첫 MVP가 월 500만 원 넘기면 두 번째 시작.

많은 시리즈 빌더가 실패하는 이유는 자신의 자원(시간, 에너지, 돈) 한계를 무시하고 모든 걸 동시에 하려고 하기 때문이에요. "일단 시작하고 본다"는 태도는 첫 번째 MVP에선 옳지만, 두 번째부터는 치명적입니다.

우선순위 의사결정 프롬프트

세 개의 아이디어 A, B, C가 있을 때:

1단계. MRR 기대값 (Market × Willingness to Pay)
A: $500/월 × 30% = $150
B: $1,000/월 × 10% = $100
C: $200/월 × 50% = $100

2단계. 구현 난도 (개발 시간)
A: 40시간
B: 120시간
C: 60시간

3단계. 우선순위 = MRR 기대값 / 개발 시간
A: 150/40 = 3.75 ← 1순위
C: 100/60 = 1.67 ← 2순위
B: 100/120 = 0.83 ← 대기

이 프레임으로 보면 거의 항상 명확한 우선순위가 나옵니다. 감정이 아니라 데이터로 결정하면, 세 프로젝트 모두를 죽이지 않을 수 있어요.

4단계 캘린더 만들기

1. 현재 프로젝트들을 페이즈로 분류: 프로젝트 이름 / 현재 페이즈 / 주간 시간
2. 주 단위로 시간 할당: 각 요일별 어느 프로젝트에 몇 시간
3. 대기 중 프로젝트 리스트: "언젠가 할" 리스트에 2~3개 추가
4. 4주마다 점검: 계획대로 진행됐나, 진전 있었나, 페이즈 전환 필요한가

마무리

시리즈 빌더가 여러 MVP를 동시에 운영하는 비결은 멀티태스킹이 아니라 페이즈 관리. 각 프로젝트를 다른 단계에 놓고, 주 단위로 명확하게 시간을 분배하면 세 개, 네 개의 프로젝트도 모두 살아남아요.

다음 편에서는 더 중요한 질문을 다룹니다. "이 프로젝트를 정말로 계속 키워야 할까? 아니면 지금 죽여야 할까?" 각 MVP의 라이프사이클을 진단하고 결정하는 방법이에요.

이전 편: 5일 짧게 만드는 법, 압축의 기술
다음 편: 각 MVP의 라이프사이클, 살리고 죽이는 시점

이 글에 등장하는 인물(박서연, 이준호)에 대한 안내
본 시리즈에 등장하는 인물은 페일스쿨이 만든 가상의 페르소나입니다. 단, Pieter Levels (Nomad List, Remote OK), Sahil Lavingia (Gumroad), Marissa Goldberg, 스탠포드 다중 프로젝트 연구는 모두 실제입니다.

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