출시 후 몇 달이 지나면 어느 팀이든 재구축 견적을 한 번쯤 받아봅니다. 막상 구체적인 숫자를 확인하고 나면 다들 말을 아끼며 당장의 결정을 미루곤 합니다.
반대의 경우도 있습니다. 기능 하나를 붙일 때마다 서비스의 다른 영역이 터지고, 그때마다 급한 대로 임시방편 수정을 거칩니다. 이런 일이 두세 번 반복되면 팀 내부에서도 "이대로 계속 기능을 덧붙여도 괜찮을까"라는 우려가 터져 나옵니다.
두 상황 모두 결국 하나의 본질적인 질문으로 귀결됩니다. 지금의 시스템을 계속 키울 것인가, 아니면 다시 지을 것인가. 앞선 1부에서 살펴본 네 가지 신호(도달, 반복, 지불, 요청)를 이미 읽었다면 방향성은 어느 정도 드러났을 것입니다. 이번 글은 그 신호를 바탕으로 실제 의사결정을 내리는 구체적인 기준을 다룹니다.
무엇을 기준으로 볼 것인가
"코드가 지저분해서 새로 짜야 한다"는 진단은 익숙합니다. 단기간에 속도 중심으로 구축한 MVP라면 어디서든 나올 수 있는 지적이며, 이러한 코드 정리는 현재 구조를 키워가는 과정 안에서도 충분히 해결할 수 있습니다.
진짜 재구축 여부를 가르는 본질적인 기준은 기술적 완성도가 아닌 처음 세운 가설에서 제품이 얼마나 멀어졌는가에 있습니다.
여기서 가설이란 MVP를 처음 기획할 때 설정한 타깃 사용자, 그들의 방문 목적, 핵심 가치까지 이르는 도달 경로의 밑그림을 뜻합니다. 최근 수집되는 사용자 요청들이 이 기존 밑그림 위에서 가지를 치는 형태라면 기존 구조를 키우면 됩니다. 하지만 밑그림의 틀 자체를 새로 그려야 하는 신호라면 대응 방식이 전면 달라져야 합니다.
재구축 여부를 가르는 3가지 질문
기존 밑그림에서 얼마나 벗어났는지는 다음 세 가지 질문으로 명확히 검증할 수 있습니다.
- 핵심 데이터 (다루는 대상 자체가 바뀌었는가): 개인의 일정을 관리하던 서비스가 팀 단위 프로젝트 일정까지 처리해야 하는 상황이 대표적입니다.
- 사용자 유형 (처음 가정한 사용자층과 실사용자가 다른가): 개인 소비자를 겨냥해 만들었는데, 기업 담당자나 B2B 문의가 주를 이루는 경우입니다.
- 핵심 흐름 (가입부터 지불까지의 전환 경로가 바뀌었는가): 단발성 결제로 끝나던 흐름에 여러 단계의 내부 승인 절차가 필수적으로 끼어든 상황입니다.
개인용 일정 공유 앱을 예로 들면 판단 과정이 선명해집니다. 출시 두 달쯤 지나 팀 단위 가입자가 늘고, 일정 하나를 여러 인원이 공동 승인하는 기능 요청이 쏟아지는 상황은 드물지 않습니다. 이 경우 다루는 데이터의 대상이 개인에서 조직으로 전환되었고, 일정 확정 흐름에 승인 절차가 추가되어 전환 경로도 바뀌었습니다. 세 가지 질문 중 두 개에 해당하므로, 제품 구조를 다시 설계하는 방안을 우선 검토해야 합니다.
질문 항목의 중복 여부에 따라 판단의 방향이 갈립니다.
| 변형 항목 수 | 의사결정 방향 |
|---|---|
| 0~1개 | 기존 구조를 지속적으로 키운다 |
| 2개 이상 | 제품 구조를 다시 설계하는 쪽을 검토한다 |
단 하나의 항목만 변했다면 현재 구조 위에 기능을 얹는 수준으로 대응이 가능합니다. 하지만 두 개 이상이 동시에 달라졌다면, DB 구조와 화면 뼈대 자체가 애초에 다른 전제 위에 서 있다는 뜻입니다. 이 상태에서 기능만 덧붙이면 시스템 이음매마다 심각한 부작용이 생깁니다.
자주 벌어지는 두 가지 오판
첫째, 성과가 잘 나오고 있는데 시스템을 전면 갈아엎는 경우입니다. 신호가 긍정적이면 팀의 자신감도 커지고 여유 예산이 생기면서 "이번 기회에 제대로 새로 짓자"는 주장이 힘을 얻습니다. 그 결과 몇 달간 신규 기능 개발이 완전히 멈추고, 이미 검증된 사용자 흐름까지 손실을 입습니다. 잘 작동하는 서비스의 흐름을 멈추는 기회비용을 경시한 결과입니다. 새로 구축한 결과물이 기존 서비스보다 뛰어난지는 그 수개월의 정체기를 극복하고 나서야 비로소 증명됩니다.
둘째, 신호가 나쁜데도 집착하며 기능을 계속 덧붙이는 경우입니다. 지표가 부진함에도 매몰 비용에 대한 아쉬움 때문에 재구축을 끝내 미룹니다. 기능을 계속 얹을수록 정작 검증해야 할 본질적 가설은 흐려지고, 지표가 약간 변했을 때 그것이 신규 기능의 효과인지 기존 결함이 잠깐 가려진 것인지 판단할 수 없게 됩니다. 회의 때마다 "다음 업데이트는 다를 것"이라는 기대를 품지만, 정작 가설 자체를 수정해야 할 결정적 타이밍은 계속 뒤로 밀립니다.
부분 재구축이라는 중간 경로
전면 재구축과 현상 유지라는 극단적인 이분법만 존재하는 것은 아닙니다. 핵심이 되는 특정 흐름만 새로 설계하고 나머지는 기존 시스템과 연결하는 부분 재구축도 훌륭한 대안입니다. 대규모 기존 시스템을 개선할 때와 마찬가지로, 기능 단위로 모듈을 분리해 이전하고 문제 발생 시 해당 모듈만 즉시 원상복구하는 원칙은 MVP 단계에서도 그대로 적용됩니다.
다시 짓기로 결정했다면 세 가지 질문 중 가장 차이가 컸던 핵심 흐름부터 우선적으로 재설계합니다. 사용자 계정과 그간 누적된 핵심 데이터는 온전히 유지한 채, 어긋난 화면과 흐름만 새로운 구조로 이관하는 방식입니다.
비용을 비교할 때 놓치는 것
재구축 견적은 일시불 형태로 제시되기 때문에 시각적 충격이 큽니다. 반면 기존 구조를 유지하며 들어가는 유지보수 및 추가 개발 비용은 매달 분납 형태로 지출되어 상대적으로 부담이 적게 느껴집니다.
따라서 두 선택지의 비용을 객관적으로 비교하려면 반드시 동일한 기준 시간을 설정해야 합니다. 대개 6개월 단위로 재구축 예상 비용과 동일 기간의 누적 개발 비용을 나란히 대조해보면, 초기의 직관과는 전혀 다른 분석 결과가 나오는 경우가 많습니다.
이 비교의 핵심은 당장의 단기 지출액에 현혹되지 않고 동일한 관찰 기간을 설정하는 분석 태도입니다. 재구축 견적서의 큰 금액에 지레 겁을 먹고 임시방편 수정만 고집하는 선택이나, 매월 누적되는 막대한 개발비 지출을 방치한 채 구조 진단을 미루는 선택 모두 동일한 오류에서 비롯됩니다.
기존 구조를 유지하며 키우기를 택했을 때 어디까지 갈지는 3부에서, 판을 새로 짜기로 했을 때 무엇을 살려둘지는 4부에서 각각 다룹니다.
인테그래빗이 MVP 구조 진단을 별도 단계로 두는 이유
인테그래빗은 서비스 확장과 재구축 중 어느 길을 택할지 정하기 앞서 'MVP 구조 진단' 과정을 독립된 절차로 진행합니다. 인테그래빗이 직접 제작하지 않은 외부 MVP 프로젝트를 수임할 때도 검증 기준은 동일합니다. 핵심 데이터, 사용자 유형, 핵심 흐름이라는 세 가지 축이 초기 가설에서 얼마나 벗어났는지 우선 파악합니다. 이전 개발자의 코드 작성 방식을 평가하기보다, 현재 아키텍처가 앞으로 몇 사이클을 더 버틸 수 있는지를 객관적으로 산정하기 위함입니다.
진단 결과가 기존 시스템을 키우는 쪽으로 나오든 전면 다시 짓는 쪽으로 나오든, 그다음 단계의 전략 결정은 의뢰인 조직의 명확한 데이터 판단 아래 이루어집니다.
이전 글: MVP를 내놓은 다음, 무엇을 보고 다음 단계를 결정하나
다음 글: 디벨롭하기로 했다면: 어디까지 키우고 언제 멈추나
지금 운영 중인 서비스의 구조가 어느 쪽에 가까운지 판단이 서지 않는다면, 30분 무료 상담을 통해 세 가지 핵심 질문을 함께 짚어보실 수 있습니다.