실패한 소프트웨어 프로젝트 구조: 90일 만에 정체된 모바일 앱을 출시하기

2024년 초, 베트남 중견 소매 체인이 저희에게 접근했을 때, 그들의 내부 지표는 저희가 너무 자주 본 이야기를 들려주었습니다. 원래 6개월 빌드로 범위가 정해졌던 그들의 고객 로열티 앱은 14개월이 지났고, 예산을 약 180퍼센트 초과했으며, 여전히 40,000명의 활성 회원을 위해 준비되지 않은 상태였습니다. 두 벤더가 이미 왔다 갔습니다. 세 번째 견적서가 CEO의 책상에 막 도착했고, 추가로 9개월의 작업을 약속하고 있었습니다. 대신, 그들은 저희에게 2주간의 감사를 의뢰했습니다. 90일 후, 앱은 Apple App Store와 Google Play에 출시되었고, 연말 로열티 캠페인을 운영하며 첫 달에만 12,000명 이상의 신규 가입자를 확보했습니다.

이것은 저희가 어떻게 그곳에 도달했는지, 실제로 무엇이 잘못되었는지, 그리고 벤더 정치를 벗겨냈을 때 실패한 소프트웨어 프로젝트 구조가 어떤 모습인지에 대한 이야기입니다.

프로젝트 개요

이 클라이언트는 3개 성(省)에 걸쳐 34개 매장을 운영하는 전문 소매 브랜드로, 원래의 SMS와 플라스틱 카드 인프라에는 너무 복잡해진 로열티 프로그램을 가지고 있었습니다. 비전은 명확했습니다. 회원이 포인트 잔액을 확인하고, 판매 시점에서 리워드를 사용하고, 개인화된 오퍼를 받고, 매장 내 서비스를 예약할 수 있는 iOS 및 Android용 네이티브 모바일 앱이었습니다. 서류상으로는 성숙한 라이브러리와 명확한 비즈니스 로직을 갖춘, 잘 이해된 빌드였습니다.

원래 납품 계획은 호치민시의 한 스튜디오와 6개월 계약을 맺고, 이어서 내부 팀에 3개월간 인계하는 것이었습니다. 14개월이 지나도 내부 팀은 채용되지 않았고, 두 번째 벤더는 백엔드를 두 번 재구축했으며, 앱 자체는 로열티 스캔 플로우 진입 2분 이내에 Android 12에서 여전히 충돌했습니다. 클라이언트의 CFO는 인쇄된 바우처에 묶여 있는 로열티 프로그램에서 발생한 매출 손실을 계산하기 전에도 직접 비용이 이미 41억 VND를 넘어섰다고 추정했습니다.

클라이언트가 직면한 문제

저희의 2주간 감사는 세 가지 뚜렷한 문제를 드러냈고, 클라이언트의 리더십 팀은 그중 실제로 기술적인 문제가 하나뿐이라는 사실에 놀랐습니다.

첫 번째 문제는 기능 성장으로 위장된 범위 이탈이었습니다. 원래의 42페이지 사양은 118페이지로 부풀어 올랐고, 공식적인 변경 프로세스 없이 세 명의 서로 다른 이해관계자가 새로운 기능을 추가하고 있었습니다. 모바일 팀은 움직이는 목표를 쫓고 있었고, 백엔드 팀은 이미 두 번 재설계된 화면을 위한 엔드포인트를 만들고 있었습니다.

두 번째 문제는 프로덕션이 아닌 데모용으로 설계된 백엔드였습니다. API 계층은 클라이언트의 전자상거래 웹사이트도 함께 서빙하는 공유 PHP 모놀리스 위에 구축되어 있었습니다. 포인트 잔액 조회는 회원 ID 컬럼에 인덱스가 없는 2백1십만 행의 MySQL 테이블에서 가져오고 있었습니다. 리딤션 트랜잭션은 멱등적이지 않았기 때문에, 판매 시점의 불안정한 4G 신호가 회원의 포인트를 이중 차감할 수 있음을 의미했습니다. 이전 벤더는 이러한 문제들을 알고 있었고, 세 번째 견적으로 전체 재작성을 제안했습니다.

세 번째 문제이자 가장 큰 피해를 준 문제는 더 이상 서로 대화할 수 없는 팀이었습니다. 12개월 차에 이르러, 클라이언트의 제품 책임자, 디자인 에이전시, 그리고 납품 벤더는 아무도 신뢰하지 않는 공유 스프레드시트를 통해서만 거의 배타적으로 소통하고 있었습니다. 회의는 결정을 내리는 자리가 아니라 책임을 전가하는 자리가 되어 있었습니다.

기술 부채는 실재했습니다. 그러나 출시를 실제로 막고 있던 것은 신뢰와 소통의 붕괴였습니다.

저희가 제공한 솔루션

저희는 세 가지 명확한 단계로 구성된 90일 고정 범위 구조안을 제안했고, 상업적 조건을 클라이언트의 11월 성수기 소매 시즌 이전에 로열티 캠페인을 출시하는 것에 고정시켰습니다.

처음 2주는 계획을 잘라내고, 동결하고, 재기준선을 정하는 것에 관한 것이었습니다. 저희는 클라이언트의 리더십과 엄격한 범위 동결을 협상했습니다. 출시는 사양의 118개 기능 중 31개만 배포하며, 가장 가치가 높은 세 가지 회원 여정을 다루기 때문에 선택되었습니다. 나머지는 모두 소유자가 지정된 문서화된 v1.1 백로그로 이동했습니다. 이 하나의 결정이, 그렇지 않았다면 아무도 요청하지 않은 엣지 케이스를 쫓느라 소비되었을 약 6주의 엔지니어링 시간을 회수했습니다.

다음 6주는 위험한 부분을 재구축하고 나머지를 유지하는 것에 관한 것이었습니다. 저희는 기존 React Native 코드베이스를 보존했습니다. 왜냐하면 모바일 팀의 작업이 실제로 합리적이었고 단지 잘못 통합되었을 뿐이었기 때문입니다. 그런 다음 구조적으로 망가진 두 컴포넌트를 재구축했습니다. 로열티 API는 공유 PHP 모놀리스에서 자체 PostgreSQL 데이터베이스, 회원 조회에 대한 적절한 인덱싱, 그리고 클라이언트 생성 UUID로 키가 지정된 멱등적 리딤션 트랜잭션을 갖춘 작은 Node.js 서비스로 추출되었습니다. 저희는 경량 이벤트 로그를 도입하여 모든 포인트 트랜잭션이 원시 이벤트로부터 재구성 가능하도록 했고, 이는 재무 팀이 마침내 지원 티켓을 열지 않고도 잔액을 감사할 수 있음을 의미했습니다.

마지막 한 달은 안정화, 테스트, 인계에 관한 것이었습니다. 저희는 5개 매장에 걸쳐 200명의 실제 회원과 함께 두 라운드의 비공개 베타를 진행하며, 발견되는 대로 충돌을 수정했습니다. 클라이언트의 신규 내부 팀을 위한 런북을 작성하고, 배포 파이프라인을 문서화하고, 인계 후 코드베이스를 소유할 클라이언트 소속 엔지니어 두 명을 훈련시켰습니다. 앱은 캠페인 마감일보다 3일 앞선 87일차에 양쪽 스토어에 출시되었습니다.

성공을 만든 기술적 하이라이트

세 가지 엔지니어링 선택이 대부분의 무거운 짐을 짊어졌습니다.

멱등적 리딤션 엔드포인트는 수개월 동안 회원 신뢰를 손상시켜 온 이중 차감 버그의 한 부류를 제거했습니다. 모바일 클라이언트로부터의 모든 리딤션 요청은 UUID를 지니고 있었습니다. 백엔드는 UUID를 고유 인덱스에 기록하고 중복을 원래 응답으로 거부했습니다. 불안정한 4G 신호에 있는 회원이 이제 Redeem을 세 번 탭해도 포인트는 한 번만 잃게 됩니다.

이벤트 소싱된 포인트 원장은 가변 잔액 필드를 포인트 이벤트의 추가 전용 로그로 대체했습니다. 잔액은 파생 상태가 되어, 읽을 때 계산되고 캐시되었습니다. 재무 팀에게 매월 악몽이었던 조정 작업이 단일 SQL 쿼리가 되었습니다. 이것은 새로운 패턴이 아닙니다. 돈이나 돈에 준하는 가치와 관련된 모든 것에 대한 올바른 패턴입니다. 이전 벤더들이 이를 건너뛴 이유는 만드는 것보다 설명하는 데 시간이 더 걸리기 때문입니다.

iOS와 Android를 위한 분리된 빌드 파이프라인은 릴리스 사이클을 일주일에서 한 시간 미만으로 단축했습니다. 두 플랫폼은 더 이상 서로를 기다리지 않았고, 한쪽의 실패한 테스트는 해당 플랫폼의 배포만 중단시켰습니다. 서류상으로는 작은 변화지만, 1년 동안 두려움을 앞세워 배포해 온 팀에게는 상당한 사기 진작이었습니다.

결론

정체된 소프트웨어 프로젝트가 단일한 이유로 정체되는 경우는 드뭅니다. 이 경우, 기술 부채는 8주 안에 수정 가능했습니다. 소통 붕괴가 더 어려운 문제였고, 기능에 대해 No라고 말할 수 있는 위치와 그 결정을 CEO에게 방어할 수 있는 신뢰성을 갖춘 외부 팀이 필요했습니다. 이 구조가 성공한 것은 저희가 이국적인 기술을 도입해서가 아니라, 클라이언트가 범위를 동결하고 신뢰를 병렬로 재구축할 의지가 있었기 때문입니다.

귀사의 팀이 예산을 초과하고, 마감일을 넘기고, 이해관계자의 신뢰를 잃어가는 프로젝트를 바라보고 있다면, 그 답은 거의 대개 또 다른 9개월과 더 큰 납품 팀이 아닙니다. 그것은 보통 짧고 정직한 감사이며, 이어서 비즈니스에 중요한 하나의 출시 이벤트를 중심으로 구축된 고정 범위 구조 계획입니다. 그것이 저희 MerkTechs에서 맡는 종류의 일입니다. 길을 잃은 프로젝트에 신선하고 경험 많은 관점을 가져와, 드라마 없이 프로덕션으로 되돌리는 것입니다.