MVP를 만들 때는 빈 땅 위에 집을 지었습니다. 아무도 살고 있지 않으니 기초를 새로 놓아도, 구조를 통째로 바꿔도 문제가 없었습니다. 두 번째 사이클부터는 상황이 다릅니다. 디벨롭이든 재구축이든, 지금 손대는 코드 위에는 이미 사람이 살고 있습니다. 빈 땅에 집을 짓는 일과 사람이 사는 집을 고치는 일은 방법 자체가 다릅니다.
앞선 4부에서 다룬 병행 운영은 재구축 특유의 상황이었지만, 지금부터 다루는 다섯 가지는 디벨롭과 재구축을 가리지 않고 두 번째 사이클부터 똑같이 마주치는 과제입니다.
라이브 변경 통제
운영 중인 시스템 위에서 코드를 바꾸는 일은 빈 화면에 코드를 얹는 일과 위험의 크기가 다릅니다. 배포 하나가 지금 이 순간 결제를 진행 중인 사용자, 글을 쓰고 있던 사용자를 그대로 건드립니다. 그래서 두 번째 사이클부터는 배포 자체를 하나의 작업으로 설계해야 합니다.
- 되돌릴 수 있는 배포: 전체 사용자에게 한 번에 내보내지 않습니다. 일부 사용자에게 먼저 열어 문제가 보이면 그 자리에서 원복하고, 문제가 없으면 범위를 점진적으로 넓힙니다.
- 되돌릴 기준을 미리 정해 둔다: 오류율이 얼마를 넘어 몇 분간 이어지면 되돌리는지, 응답 시간이 어느 선까지 느려지면 되돌리는지를 배포 전에 숫자로 정해 둡니다. 배포 도중에 기준을 새로 정하면 판단이 늦어집니다.
- 배포 시점 선택: 사용자가 가장 적은 시간대를 고르고, 문제가 생겼을 때 즉시 대응할 사람이 그 시간대에 실제로 대기하고 있는지까지 확인합니다. 새벽에 배포했는데 되돌릴 사람이 잠들어 있으면 시간대를 고른 의미가 없습니다.
결제 서비스에서 이런 상황은 드물지 않습니다. 새 배포를 전체 사용자에게 한 번에 열었는데 특정 카드사 연동에서만 오류가 나타납니다. 되돌릴 기준을 미리 정해 두지 않은 탓에 팀은 로그를 지켜보면서도 판단을 미루고, 그사이 결제 실패가 쌓여갑니다. 기준을 미리 숫자로 정해 뒀다면 5분 만에 원복하고 끝났을 상황입니다.
이 세 가지를 갖추지 않은 채 두 번째 사이클에 들어가면 배포는 매번 도박이 됩니다. 운이 좋으면 넘어가고, 운이 나쁘면 몇 시간 동안 서비스가 멈춘 채로 원인을 찾아야 합니다.
피드백 스크리닝
디벨롭이든 재구축이든 서비스를 운영하기 시작하면 요청이 끊이지 않고 들어옵니다. 문제는 요청의 양이 아니라, 그중 무엇이 진짜 과제인지 가려낼 기준이 없다는 데 있습니다.
먼저 요청을 한곳에 모읍니다. 누가 요청했는지, 언제 요청했는지, 같은 요청이 몇 번 반복되었는지가 한 화면에서 보여야 합니다. 이메일과 메신저, 통화 메모에 흩어져 있으면 같은 요청이 세 번 들어왔다는 사실조차 알아채지 못합니다.
모은 다음에는 거르는 질문을 던집니다. 이 요청을 처리하면 약한 신호 중 무엇이 움직이는가. 새로 들어온 사용자를 핵심 행동까지 데려가는 도달인지, 떠난 사용자를 다시 돌아오게 만드는 반복인지, 결제로 이어지는 지불인지 답이 나오지 않는 요청은 우선순위 목록의 맨 아래로 내려갑니다.
이 질문을 기준으로 삼지 않으면 목소리가 큰 고객이나 가장 최근에 들어온 요청이 자연스럽게 앞자리를 차지합니다. 실제로 서비스에 도움이 되는 요청과 그저 먼저 말한 요청이 뒤섞이는 지점이 바로 여기입니다.
두 번째 공수 계산
두 번째 사이클의 예산과 기간은 MVP 견적을 그대로 늘린 값으로 잡히지 않습니다.
기존 것과의 호환, 데이터 이관, 운영 병행이 공수 안에 새로 들어갑니다. MVP 때는 아무것도 없는 자리에 처음부터 짰지만, 이번에는 지금 돌아가고 있는 화면과 데이터를 건드리지 않으면서 새 코드를 얹어야 합니다. 같은 기능 하나를 만들어도 기존 로직과 충돌하지 않는지 확인하는 시간이 별도로 붙습니다. 이관 대상 데이터의 양이 많을수록, 기존 사용자가 예전 방식대로 쓰던 기능을 그대로 유지해야 하는 제약이 겹칠수록 이 시간은 비례해서 늘어납니다.
MVP 견적 기준으로 이번 공수를 가늠하면 어긋나는 이유가 여기 있습니다. MVP 견적은 아무것도 없는 자리에서 짜인 비용이고, 이번 견적에는 이미 돌아가고 있는 것을 지키는 비용이 함께 들어갑니다. 같은 크기의 기능이라도 후자가 더 오래 걸리는 경우가 흔합니다.
성과 입증 지표
새 기능을 넣었으면 "나아졌다"는 말을 데이터로 뒷받침해야 합니다. 이때 흔히 놓치는 지점이 비교 기준입니다.
바꾸기 전에 기준값을 먼저 고정합니다. 새 기능을 배포하고 나면 이전 상태를 다시 잴 방법이 없습니다. 지금 전환율이 얼마인지, 지금 이탈 지점이 어디인지를 배포 직전에 기록해 두지 않으면, 나중에 "확실히 좋아진 것 같다"는 느낌만 남고 근거는 사라집니다.
지표 하나에 기능 하나를 원칙으로 둡니다. 여러 기능을 한 사이클에 몰아넣고 지표 하나만 올랐다면, 그 지표를 움직인 것이 어떤 기능이었는지 가려낼 방법이 없습니다. 다음 사이클에도 같은 기능을 우선순위에 올릴지 판단하려면 무엇이 효과가 있었는지부터 알아야 합니다.
온라인 교육 서비스에서 이런 일이 자주 벌어집니다. 한 사이클에 결제 화면 개편과 알림 기능 추가를 함께 배포하고 나서 전환율이 올랐다는 결과만 보고합니다. 어느 쪽이 효과였는지는 아무도 답하지 못하고, 다음 사이클에도 두 가지를 한꺼번에 넣고 판단하는 습관이 그대로 반복됩니다.
장애 대응 최소 기준
두 번째 사이클에 들어가기 전, 규모와 상관없이 세 가지는 갖추고 시작합니다.
| 최소 기준 | 갖추지 못했을 때 일어나는 일 |
|---|---|
| 오류 탐지: 사용자보다 먼저 안다 | 고객 문의나 항의 메시지로 장애를 먼저 알게 되며, 그 시점엔 이미 수 시간이 지나 있습니다. |
| 원복 체계: 즉시 되돌릴 수 있다 | 배포 후 문제가 생겨도 원인을 다 찾고 수정할 때까지 서비스가 중단 상태로 방치됩니다. |
| 담당자 지정: 누가 받을지 정해져 있다 | 장애 알림이 울려도 누군가 보겠지 하고 넘어가며 귀중한 초기 대응 시간을 놓칩니다. |
세 가지를 넘어서는 전체 운영 체계, 그러니까 백업 주기나 보안 패치 리듬, 지표를 확인하는 요일까지는 출시 다음 날부터 해야 할 일: 서비스 운영 체크리스트에서 이미 정리해 두었습니다. 여기서는 두 번째 사이클을 시작하기 전 반드시 갖춰야 할 최소한만 짚었습니다.
다섯 가지 과제를 하나씩 넘기고 나면, 남은 질문은 이 다섯 가지가 전체 그림에서 어디에 놓이는지입니다. 그 전체 그림은 한 장의 결정 지도로 정리한 마지막 편, 6부에서 다룹니다.
인테그래빗이 요청과 배포, 지표를 한 화면에서 관리하는 이유
요청 목록과 배포 기록, 지표가 각각 다른 도구에 흩어져 있으면 "이 기능을 넣은 뒤 지표가 어떻게 됐는지"를 되짚는 일 자체가 어려워집니다. 배포 시점을 확인하려면 깃 로그를 뒤져야 하고, 그 요청이 애초에 어디서 들어왔는지는 메신저 대화를 다시 찾아야 하는 식입니다.
인테그래빗은 요청 접수와 배포 기록, 지표 확인이 같은 화면에서 이어지도록 관리합니다. 다만 어떤 요청을 우선순위에 올릴지, 다음 사이클에 무엇을 넣을지는 이 화면이 대신 정해주지 않습니다. 그 판단은 여전히 의뢰하는 조직의 몫입니다.
이전 글: 새로 만들기로 했다면: 무엇을 가져가고 무엇을 버리나
다음 글: MVP 다음 단계 결정 지도: 이 결정은 한 번으로 끝나지 않는다
두 번째 사이클을 앞두고 배포와 피드백, 지표 관리 체계가 갖춰져 있는지 판단이 서지 않는다면, 30분 무료 상담을 통해 현재 상태를 함께 점검해 보실 수 있습니다.