재구축을 결정한 뒤 처음 열리는 회의에서는 거의 같은 질문이 나옵니다. "그럼 처음부터 다시 기획해야 하나요?" 질문 안에는 걱정이 섞여 있습니다. 지금까지 쌓아온 것을 전부 지우고 백지 위에서 다시 시작해야 한다는 걱정입니다.
앞선 3부에서 다룬 멈춤 신호를 만나 디벨롭을 접는 경우가, 재구축으로 들어오는 가장 흔한 입구입니다.
다행히 재구축은 백지에서 다시 시작하는 일이 아닙니다. 지금까지 쌓은 것 중 상당 부분은 그대로 다음 버전으로 넘어갑니다. 무엇을 가져가고 무엇을 버려도 되는지, 그 기준부터 세워야 합니다.
가져가는 것과 버리는 것
재구축이라는 말을 들으면 대개 코드 저장소를 지우고 처음부터 새로 짜는 장면을 떠올립니다. 하지만 실제로 버려도 되는 대상은 코드와 화면, 그리고 둘을 엮은 구조뿐입니다. 나머지는 다음 버전에도 그대로 넘겨받을 수 있습니다.
- 사용자: 계정과 그동안 쌓인 관계입니다. 로그인 정보, 소속, 권한처럼 누가 이 서비스를 쓰는지를 규정하는 값들입니다.
- 데이터: 행동 기록과 거래 내역입니다. 사용자가 남긴 과거는 구조가 바뀌어도 여전히 유효한 자산입니다.
- 배운 것: 검증된 흐름, 버린 기능 목록, 요청 로그입니다. 어떤 순서로 안내해야 이탈이 적은지, 어떤 기능을 시도했다가 접었는지, 무엇을 반복해서 요청받았는지에 대한 기록입니다.
이 중 가장 놓치기 쉬운 항목이 배운 것, 그중에서도 검증된 흐름입니다. 검증된 흐름은 화면이 아니라 순서입니다. 화면을 새로 그리더라도 그 순서만큼은 지켜야 합니다.
정기구독 서비스에서 이런 상황은 드물지 않습니다. 결제 직전 마지막 확인 화면 하나가 이탈을 줄이는 역할을 했다는 사실이 데이터로 이미 확인되었는데, 재구축 과정에서 디자인팀이 그 화면을 통째로 걷어냅니다. 새 화면은 더 깔끔해졌지만, 확인 단계가 사라지면서 결제 취소 문의가 다시 늘어납니다. 화면은 바뀌어도 되지만, 그 화면이 맡고 있던 순서는 다음 버전에서도 그대로 지켜야 합니다.
흔한 실수 두 가지
재구축 과정에서 반복되는 실수는 크게 두 가지입니다.
첫째, 검증된 부분까지 바꾸는 실수입니다. 재구축을 시작하면 팀 전체가 모처럼 백지 위에서 일할 기회를 얻습니다. 이 기회를 리브랜딩의 계기로 삼고 싶은 유혹이 커집니다. 로고를 바꾸고 서비스명을 다듬는 정도를 넘어, 이미 반응이 좋았던 흐름까지 이번 기회에 손을 댑니다. 문제는 무엇이 검증되었고 무엇이 그렇지 않은지 구분하지 않은 채 손을 대면, 새 버전의 성과가 나빠졌을 때 원인을 찾을 방법이 사라진다는 점입니다. 구조를 바꾼 탓인지, 검증된 흐름을 건드린 탓인지 가려낼 기준이 없어집니다.
둘째, MVP 때 뺐던 기능을 이번에 다 넣는 실수입니다. 처음 MVP를 만들 때는 정해진 예산과 기간에 맞춰 기능을 걷어냈습니다. 재구축은 그 목록을 다시 꺼내 하나씩 되살릴 핑계처럼 보입니다. 그러나 2.0을 완성품으로 여기는 순간, MVP 때 겪었던 문제가 그대로 반복됩니다. 빼둔 기능 목록 중 이번에 되살릴 항목은, 재구축을 촉발한 세 가지 질문, 즉 핵심 데이터와 사용자 유형, 핵심 흐름 중 가장 크게 어긋났던 지점과 맞닿은 기능부터 고릅니다. 나머지는 다음 사이클로 미뤄도 됩니다. 두 번째 버전도 범위를 정하는 결정이라는 사실은 달라지지 않습니다.
병행 운영
재구축한 새 버전을 출시한다고 해서 기존 버전을 그 자리에서 곧장 내리지는 않습니다. 두 버전을 얼마간 함께 운영하는 기간이 필요합니다.
- 기존 버전을 언제까지 둘지: 새 버전이 기존 버전의 핵심 흐름을 전부 대체할 때까지입니다. 흐름 하나라도 새 버전에서 아직 검증되지 않았다면, 그 흐름을 쓰는 사용자에게는 기존 버전을 계속 열어둬야 합니다.
- 새 버전을 누구부터 태울지: 신규 사용자부터 새 버전으로 안내합니다. 기존 흐름에 대한 기대가 없는 사람들이라 마찰이 적습니다. 안정성이 확인되면 기존 사용자를 초대 형태로 옮기고, 마지막에 전체를 전환합니다.
- 데이터 이관: 한 번에 옮기지 않습니다. 정본을 한쪽으로 정하고 흐름을 단방향으로 유지합니다. 기존 버전과 새 버전이 같은 데이터를 양쪽에서 고치기 시작하면, 어느 쪽이 최신인지 아무도 장담할 수 없는 상태가 됩니다.
전환 커뮤니케이션
병행 운영 기간 동안 기존 사용자에게 무엇을 언제 알릴지도 별도로 정리해야 합니다.
먼저 알려야 할 것은 바뀌는 목록이 아니라 안 바뀌는 목록입니다. 로그인 정보가 그대로 유지되는지, 그동안 쌓인 데이터가 남아 있는지, 요금제가 달라지지 않는지부터 안내합니다. 사용자가 재구축 소식을 들었을 때 가장 먼저 걱정하는 지점이 여기이기 때문입니다. 무엇이 달라지는지는 그다음입니다.
알리는 시점에도 순서가 있습니다. 배포 전에 미리 알리고, 전환 대상이 된 사용자에게는 개별로 다시 안내하며, 전환이 끝난 뒤에는 문제가 생겼을 때 되돌아갈 경로가 있다는 점까지 알립니다. 공지 한 번으로 끝내면 병행 운영 기간 내내 같은 문의가 반복해서 들어옵니다.
기간과 예산
재구축에 걸리는 기간과 예산은 MVP 때와 같은 잣대로 잡히지 않습니다.
짧아질 수도 있습니다. MVP 단계에서 검증해야 했던 가설은 이미 검증이 끝났으므로, 무엇을 만들지 고민하는 시간이 크게 줄어듭니다.
반대로 이관과 병행 운영 때문에 늘어나는 구간도 있습니다. 보통 두세 사이클 안에서 병행 운영을 마무리하는 팀이 많지만, 이관 대상 데이터의 양과 흐름의 복잡도에 따라 이 기간은 크게 달라집니다.
견적을 볼 때 확인할 지점은 이관과 병행이 개발 항목 어딘가에 뭉쳐 있는지, 아니면 별도 항목으로 분리되어 있는지입니다. 뭉쳐 있으면 그 작업에 실제로 얼마의 시간과 비용이 들어갔는지 나중에 확인하기 어렵습니다.
디벨롭이든 재구축이든, 제품을 세상에 내놓고 운영하는 두 번째 사이클부터는 이전과 전혀 다른 종류의 문제들과 부딪히게 됩니다. 5부에서는 라이브 상태에서의 배포 통제, 피드백 스크리닝, 예산 재추정 등 두 번째 사이클의 공통 과제들을 다룹니다.
인테그래빗이 재구축 견적에서 이관과 병행을 따로 잡는 이유
인테그래빗은 재구축 견적에서 데이터 이관과 병행 운영을 개발 항목과 분리된 별도 항목으로 산정합니다. 두 작업 모두 화면에 드러나는 신규 기능이 아니라서, 뭉뚱그려 넣으면 견적 단계에서는 보이지 않다가 프로젝트 중반에 "이런 공수가 들어갈 줄 몰랐다"는 이야기로 돌아옵니다.
이관 대상 데이터의 규모, 병행 운영을 유지할 예상 기간, 기존 버전에서 새 버전으로 사용자를 옮기는 전환 방식까지 견적 단계에서 미리 짚어두면, 실제 진행 중 항목이 늘어나더라도 처음 예산과 얼마나 차이가 나는지 바로 확인할 수 있습니다. 이 정보를 보고 병행 기간을 얼마나 길게 가져갈지, 어디까지 이번 재구축에 포함할지는 의뢰하는 조직이 판단할 몫입니다.
이전 글: 디벨롭하기로 했다면: 어디까지 키우고 언제 멈추나
다음 글: 어느 쪽을 택했든 마주치는 것들: 두 번째 사이클의 공통 과제
재구축을 앞두고 무엇을 가져가고 무엇을 버릴지 판단이 서지 않는다면, 30분 무료 상담을 통해 현재 상태를 함께 점검해 보실 수 있습니다.