제품을 계속 키우는 방향으로 결정한 순간, 그동안 눌러뒀던 기능 요청 목록이 한꺼번에 터져 나옵니다. 고객을 만나는 영업팀은 이 기능을, 문의를 받는 CS팀은 저 기능을 요구하며, 대표 역시 출시 전부터 미뤄둔 아이디어를 꺼내놓습니다. 요구사항 목록은 끝없이 늘어나지만 주어진 예산과 개발 인력은 그대로입니다. 제출된 안건마다 나름의 명분이 뚜렷하기에 무엇부터 손대야 할지는 온전히 우선순위 판단의 영역으로 넘어옵니다.
이 시점에서 가장 흔히 범하는 실수는 접수된 순서나 목소리가 큰 사람의 요구를 먼저 처리하는 것입니다. 그런 방식으로 기획, 개발, 배포를 거치는 사이클을 서너 번 돌고 나면, 무엇을 먼저 다뤘어야 했는지 그리고 언제까지 기능을 덧붙여도 괜찮은지에 대한 명확한 기준이 없었다는 사실을 깨닫게 됩니다. 예산이 넉넉하다면 순서가 다소 꼬여도 티가 나지 않지만, 대부분의 스타트업은 그럴 여유가 없으며 잘못 설정한 우선순위 하나가 제품 사이클 전체를 무너뜨립니다.
앞선 2부에서 제품을 계속 키우기로 결정한 근거는 초기 가설이 여전히 유효하다는 점이었습니다. 그 근거가 이번 우선순위 설정의 출발점이 됩니다.
무엇부터 키울 것인가
제품을 키우기로 결정했다는 것은 사업 가설이 성립한다는 의미일 뿐, 도달, 반복, 지불, 요청이라는 4가지 신호가 모두 강력하다는 뜻은 아닙니다. 보통은 하나둘의 약한 고리가 남아있기 마련입니다. 신규 기능을 무작정 추가하기에 앞서 이 약한 고리를 먼저 보강하는 것이 올바른 순서입니다.
- 도달 신호가 약할 때: 첫 사용자 경험과 온보딩 절차를 우선 개편합니다. 가입 후 핵심 가치를 체험하는 지점까지의 문턱을 낮추는 작업이 최우선입니다.
- 반복 신호가 약할 때: 서비스의 핵심 가치를 한층 강화합니다. 사용자가 지속적으로 다시 돌아와야 할 본질적인 이유를 명확히 만들어야 합니다.
- 지불 신호가 약할 때: 가격 정책과 결제 동선을 먼저 다듬습니다. 단순히 기능을 늘린다고 해서 닫힌 지갑이 열리지는 않습니다.
위 세 가지 신호가 모두 안정적으로 확보된 이후에 비로소 요청 신호, 즉 신규 기능 추가를 검토합니다. 이 순서가 뒤바뀌면 약한 고리는 방치된 채 겉껍데기 기능만 늘어나며, 결국 다음 결정 시점에도 똑같은 난관에 봉착합니다. 이 기준을 한 번 확립해 두면 매 사이클마다 벌어지는 불필요한 우선순위 논쟁을 줄일 수 있습니다.
예약 서비스에서 이런 순서가 뒤바뀌는 상황은 드물지 않습니다. 최종 예약 완료까지 5단계나 거쳐야 하는 구조적 문제를 방치한 채 리뷰 공유 기능을 새로 개발합니다. 두 번의 사이클이 지나도 도달률은 변함없습니다. 공들여 만든 리뷰 기능이 핵심 단계에조차 도달하지 못한 대다수 사용자에게는 닿지 않기 때문입니다. 온보딩 동선부터 개선했다면 신규 리뷰 기능의 효과도 함께 커졌을 자리입니다.
붙이기와 고치기의 비율
신규 기능을 덧붙이는 작업과 기존 시스템을 정돈하는 작업 사이의 균형을 잡는 것 역시 중요합니다. 보통 한 사이클은 2주에서 6주 정도 소요됩니다.
경험상 매 사이클 작업량의 30% 정도는 신규 개발이 아닌 기존 코드 정비와 구조 개선에 할당해야 합니다. 단기간에 짜둔 초기 코드, 임시로 연결한 로직, 미뤄둔 성능 최적화 등이 이에 해당합니다. 이 비율을 무시하고 신규 기능 추가에만 개발 여력을 몰아두면, 세 번째나 네 번째 사이클부터 개발 속도가 눈에 띄게 떨어집니다. 기능을 하나 추가할 때마다 기존 코드 사이의 충돌 지점이 기하급수적으로 증가하기 때문입니다.
이 비율은 거창한 도구 없이도 관리할 수 있습니다. 사이클을 시작할 때 신규 기능 목록과 정비 작업 목록을 나란히 작성하고, 후자가 빈 상태로 방치되지 않는지 점검하는 것으로 충분합니다. 정비 항목이 두 사이클 연속 비어있다면, 그 시점부터는 제품의 성장이 아닌 기술 부채가 쌓이고 있다는 경고 신호입니다.
디벨롭을 멈춰야 하는 신호
기존 구조를 계속 키워가는 과정이 무한히 지속될 수는 없습니다. 다음 네 가지 징후가 나타나기 시작하면 현재 아키텍처로 수용할 수 있는 한계선에 다다랐다는 뜻입니다.
| 멈춤 신호 | 판정의 의미 |
|---|---|
| 기능 하나를 추가하는 기간이 사이클마다 길어진다 | 시스템 구조가 새 기능을 받아들이는 비용이 과도하게 누적되는 상태 |
| 하나를 고치면 다른 기능이 함께 깨진다 | 모듈 간 의존성이 복잡하게 얽혀 독립적 수정이 불가능한 상태 |
| 신규 사용자의 온보딩 절차가 점점 복잡해진다 | 그동안 덧붙인 기능들이 초기 핵심 가치 경험을 가리는 상태 |
| 개발사에서 "구조 변경이 필요하다"고 두 번 이상 제안한다 | 개발 현장에서 시스템의 구조적 한계를 가장 먼저 감지한 신호 |
이 징후들은 독립적으로 오지 않습니다. 온보딩이 복잡해져 신규 전환율이 떨어지면, 이를 보완하려고 기능을 더 얹게 되고, 이는 다시 다음 사이클의 개발 기간을 지연시키는 악순환으로 이어집니다.
특히 개발사의 구조 변경 제안은 주관적인 주장이 아닌 객관적인 데이터 근거로 받아들여야 합니다. 매 사이클 시스템 구조와 직접 씨름하는 주체는 개발팀이며, 동일한 지적이 반복된다는 것은 아키텍처가 한계치에 다다랐음을 의미합니다. 한 번은 관점 차이로 넘길 수 있으나, 두 번째 제안부터는 구조 재설계의 강력한 근거로 삼는 것이 안전합니다.
디벨롭의 끝
디벨롭 과정에는 끝이 없다고 생각하기 쉬우나, 실제로는 기능 완성 시점이 아닌 다음 의사결정을 내리는 타이밍이 바로 디벨롭의 종료 지점입니다. 보통 서너 번의 사이클, 기간으로는 6개월에서 9개월 정도가 지나면 현재 구조를 유지할지 다시 판을 짜야 할지 판단할 시점이 도달합니다.
이 판단은 감에 의존하지 않습니다. 사이클마다 기록된 데이터, 즉 무엇을 추가했고 무엇을 정비했으며 어떤 문제가 반복되었는지를 종합하여 멈춤 신호를 점검하는 과정입니다. 기록이 없으면 판단 시점이 모호해져, 시스템 손실이 심화된 뒤에야 문제를 인지하게 됩니다. 위 멈춤 신호 중 두 개 이상이 겹친다면 전면 재구축을 검토해야 할 시점입니다. 구조를 다시 설계할 때 무엇을 살리고 무엇을 버릴지는 4부에서 다룹니다.
인테그래빗이 사이클 단위로 로드맵을 관리하는 이유
인테그래빗은 로드맵을 사이클 단위로 세분화하여 관리합니다. 한 사이클이 끝나면 해당 기간에 신규 추가된 항목, 기존 구조에서 개선된 항목, 다음으로 이월된 항목을 하나의 단일 표로 정돈합니다.
항목을 파편화하여 관리하면 개발과 정비의 비율이 추상적으로 남아버리지만, 하나의 표로 시각화하면 작업 비율과 아키텍처 멈춤 신호가 명확한 데이터로 나타납니다. 미뤄둔 과제가 반복해서 이월되는 현상 역시 이 표에서 즉시 식별할 수 있습니다.
해당 데이터를 기반으로 현재 시스템을 지속 확장할지, 구조 재설계 시점을 앞당길지에 대한 최종 판단은 오롯이 고객사의 주도적인 의사결정으로 완성됩니다.
이전 글: 고칠까 새로 만들까: MVP 이후 기로의 판단 기준
다음 글: 새로 만들기로 했다면: 무엇을 가져가고 무엇을 버리나
지금 운영 중인 서비스가 멈춤 신호 중 몇 개에 해당하는지 판단이 서지 않는다면, 30분 무료 상담을 통해 현재 상태를 함께 점검해 보실 수 있습니다.