brunch

You can make anything
by writing

C.S.Lewis

by 노랑자 Aug 11. 2024

MVP가 너무 크면 워터폴이 된다

나는 석사과정 대학원생이다. 2년이라는 짧은 시간 동안, 연구 이외의 시간을 웹 서비스를 만드는 데 매진했다. 대학원 과정 동안 살 첫 전셋집을 구하면서, 어떻게 이렇게 위험한 시스템이 있는지 많은 의문이 있었다. 그런 의문에 스스로 내린 답이 다른 사람들에게도 도움이 될 수 있을지 검증해보고 싶었다. 1년 반에 가까운 시간 동안 팀을 꾸리고, 사업을 구체화하고, 지원을 받고 구현하는 단계까지. 그렇게 만들어진 AI 전세계약 진단 체크리스트 ‘깡전킬러’의 여정을 기록으로 남긴다. 이번 글은 깡전킬러의 개발과정과 그 시행착오에 대한 이야기다.

애자일 프로세스를 위한 프로젝트 초기세팅

시장에서 먹어주는(!) 서비스를 만들자는 일념하에, 우리는 애자일 프로세스를 도입해 보기로 한다. 업무 단위를 결정하기 앞서 협업 방식부터 결정. 주 1회는 정기 미팅을 가지며 지금까지 뭘 했는지(1), 앞으로 뭘 할 건지(2), 문제점은 무엇이 있었는지(3)를 돌아가면서 이야기하기로 했다. 그리고 스크럼마스터가 미팅의 내용들을 노션에 기록하도록 하여 트랙백을 할 수 있도록 했다. 우리는 서울과 대전에서 각각 찢어져서 파트타임으로 일해야 했기 때문에 모든 게 원격이었다. 트랙백을 하고 기억하는 것은 별표 10개가 매겨질만큼 중요했다.

기획 단계에서의 스크럼 캘린더

막상 애자일 하게 서비스를 개발하려고 하니 문제가 많았다. 사업계획서만 덜렁 있을 뿐, 서비스에 대한 밑그림이 전무하다시피 했다. 기획부터 다시 다듬어야 했던 상황. 애자일은 2-3주의 짧은 기간 안에 기능하는 최소 단위의 프로덕트를 만들어내는 것이라고 하던데,, 우리가 계획한 것은 그 안에 만들어질 수 있는 무언가가 아니라고 생각했다. 그래서 우선 목표로 하는 서비스 전체를 구상해보기로 한다. 그리고 우리는 별 생각 없이 서비스 전체를 4달 안에 완성하는 계획까지 세우고 만다.. 이때 당시에는 해당 스코프가 큰 게 아니라고 생각했고, 유의미한 피드백을 거두기 위해선 유저들에게 적.어.도 이정도는 보여줘야 한다고 생각했었다. (여기서 MVP에 해당하는 것은 고작 빨간색 박스 하나였다.)

깡전킬러 베타 ver 1.0 서비스 흐름도

수십 번 뒤돌아와야 했던 우리의 개발 프로세스

서비스 전체를 개발해야 하는 상황에서 다음 다이어그램과 같은 일들을 해야 했다. 이대로 간다면 사실상 순차적 개발프로세스인 워터폴 프로세스이다. 이 모든 내용을 개발 한 뒤 1차 피드백을 받겠다는 계획이었다. 이는 서비스 개발에서 하지 말하야 할 정석을 따르고 있는 계획안이다. 각각의 항목에 대해 반성의 글을 함께 기록한다.

우리의 개발 프로세스

① 서비스 골격에 해당하는 서비스 흐름도 & 데이터 ERD

[반성] 애초에 핵심 서비스만 개발했으면 이렇게 복잡한 서비스 흐름도와 ERD를 그리느라 애먹지 않아도 됐을 것이다.

② 페이지별 화면 와이어프레임 작성

[반성] 이것도 마찬가지 문제, MVP 선정을 잘했다면 수십 장의 와이어프레임을 만드느라 날밤을 깔 이유도 없었다.

③ BI · UI 디자인 의뢰를 통한 주요 페이지별 디자인 프레임워크 & 컴포넌트 개발

[반성] 1번에서 했던 잘못된 선택 때문에 여기서는 어마어마한 비용을 지출하게 된다. 앞에서 계획한 흐름도에 수정이 있을 것을 감안하고서라도 기본 페이지들에 대한 디자인과 컴포넌트들을 확보해 두자는 의미에서 UI 디자인 업체에게 서비스를 의뢰하게 되었다. 이 실수로 무려 800만 원의 출혈을 감내해야 했다.

④ 임대차 관련 법률 검토

[반성] 우리의 계획은 모든 주택 좌표에 대해 임대차 리스크를 지도상에 표기하는 것이었다. 하지만 그것이 과연 집주인들로부터 민원제기가 발생하는 요소가 되거나, 개인의 재산권을 침해하는 요인이 되지 않을지 고민했다. 결론은 그것은 자극적일 뿐, 한 명의 고객인 임차인에게 별달른 차별화된 가치를 제공하지 않는다고 판단하여 스킵하게 되었다. 하지만 이 고민도 마찬가지로 최소 단위의 MVP가 만들어진 이후 논의되어야 할 사항이었다.

⑤ 웹 애플리케이션 구현 및 머신러닝 데이터셋·모델 개발

[반성] 우리는 두 프로세스를 병행했는데, 이러면 안 됐다.. 핵심 서비스인 머신러닝 모델이 0순위로 개발되어야 했다. 모델에서 도출되는 결과를 중심으로 MVP를 구성하고, 그에 따른 개발이 뒤따라왔어야 했다. 하지만 우리는 거대한 시스템 계획을 먼저 수행하고 그 뒤 작동하는 컴포넌트를 개발했다.

전체서비스를 초기에 구상하는 것은 로드맵 차원에서 적절한 일이었지만, 우리는 이것을 최소단위의 작업으로 쪼개지 않고 통째로 개발하였다. 현재 시점에서 시간을 되돌릴 수 있다면, MVP에 초점을 맞춘 개발을 수행하고, 단계마다 피드백 프로세스를 두어 비즈니스 인사이트를 얻는 영역까지 적극적으로 확장할 수 있었을 것 같다. 워터폴로 진행한 덕에 서비스 개발 속도는 느렸고, 불쑥불쑥 튀어나오는 에러와 이슈들로 매 번 긴 토론을 해야 했으며, 서비스를 간신히 완성하여 피드백을 받아볼 시점에는 모두가 지쳐있었다. 또한 해당 시점에 깡전킬러를 통해 각자가 원하는 바를 모두 취했기 때문에 추가적인 개발 동력이 바닥나기도 했었다. 초기부터 최소단위 서비스를 식별하여 진행했다면 시간을 훨씬 압축적으로 사용할 수 있었으리라.

애자일 하게 했다면 진행되었을 프로세스

그래서 이게 뭐 하는 서비스인데?

그럼에도 불구하고 우리는 완성했다. 지원을 받은 시점인 2023년 1월로부터 1년이 지난 2024년 1월이었다. 엄청난 비효율을 끌어안고 1년을 존버한 팀원들의 끈기와 집념은 정말 대단했다. 깡전킬러에 Beta 딱지를 붙여 주변인들을 대상으로 대망의 1차 오픈을 했다. 본 서비스가 가진 사회적 가치와, 이 서비스의 완성도와 깊이, 우리들의 집념에 대한 칭찬과 이 서비스가 근본적으로 더 나아질 수 있는 방향성에 대한 따끔한 조언을 두구두구 기대했었다.

그래서 이게 뭐 하는 서비스인데? 깡통전세를 어떻게 죽이겠(킬링)다는거야?

사람들의 반응이었다.

주변인들을 통한 서비스 피드백 결과 기록

MVP가 너무 크면 결국 애자일이 아닌 워터폴이 된다

사실 첫 프로덕트에서 사업계획서의 대부분을 담아야겠다고 생각했던 것 자체가 엄청난 패착이었다. 위 서비스 흐름도 전체가 우리의 MVP라고 생각했던 것이다. 그것은 MVP가 아닌 전체 사업이었다. 서비스 개발경험도 없는 4인이서 바닥에서부터 집을 지으려 했으니 잘 될 리가 만무했다. 거대하게 접근하다 보니 초반부터 한 번 회의를 했다 하면 4시간이 넘어가는 끝장토론이 벌어졌다. 월요 정기 회의일은 새벽에 취침하는 날이었다.

거대한 틀을 처음부터 이고 가려고 했으니 애자일한 프로세스가 돌아가기는커녕, 한번 지나가면 돌아갈 수 없는 비가역적인 워터폴 프로세스로 진행하고 있었다. 일을 진행하기 앞서 반문했어야 한다.

기능하는 최소 단위의 범위는 어디까지인가?

깡전킬러 팀은 각자의 내력(內力)으로 1년에 걸친 사이드 프로젝트를 완주했다. 그 점은 칭찬할만하지만, 결코 시간을 효율적으로 썼다고 이야기하기 어렵다. 프로젝트의 규모가 커지다 보니 무리하지 않기 위해 마감기한을 길게 길게 잡았고, 이에 따라 가시적인 결과물을 확인할 수 있는 텀이 늘어지는 문제가 발생했다. 이번 기회에 절절히 깨달았다. 다음 단계로 나아가기 위한 동력은 눈에 보이고 손에 잡히는 결과로부터 비롯되고, 팀 단위의 self-motivation을 얻기 위한 방법은 결과를 얻는 텀을 과감히 축소하는 것이라는 걸.

워터폴 VS 애자일, 머리로 아는 것과 정말 아는 것은 사뭇 다르다

프로젝트와 팀원들의 이해관계

나에겐 롱텀 프로세스의 프로젝트를 이끌었던 경험이 없었다. 회사에선 주니어이자 석사과정 대학원생인 나는 논문, 제안서 등 요청에 따른 결과물이 정해져 있는 것들에 대해서는 잘할 자신이 있었다. 하지만 짧게 경험한 서비스 개발은 그런 것이 아니었다. 결과물에 대한 목적이 명확해야 하는 것은 물론이요 팀원들의 이해관계도 동시에 이해하고 있을 필요가 있었다.

당초 깡전킬러 멤버들이 소중한 저녁시간을 쪼개 참여한 이유는 각자 분야에서 서비스 개발 경험을 얻기 위함이었다. 개발자는 개발 포트폴리오를, 기획자는 사업기획의 경험을, 마케터는 서비스 홍보경로를 뚫는 경험을 필요로 했다. 그래서 서비스를 개발하기 위한 지름길을 제시하기보다, 그들의 니즈를 충족시켜 주려면 현업에서 사용하고 있는 방법론들을 적극 적용할 수 있는 기회를 열어줘야 한다고 생각하기도 했었다. 그렇지 않으면 함께 할 동기가 없으리라 미루어 짐작했다.

그렇게 우리는 제품이 아닌 작품을 만드는 여정을 걷게 되었다. 팀원들에 대한 이해가 충분하지 못했던 탓이다. 실은 몇 번의 문제제기로 해결되면 될 일이었지만, 누구도 그런 질문을 하지 않았(못했?)다. 프로덕트 규모가 너무 크다고. 서로의 의견에 대한 존중이 너무나 컸기 때문이라고 생각한다. 하지만 반응 좋은 서비스를 만들었다면 방법론 따위가 우선순위에 들어오는 것이 중요치 않았으리라. 1차 개발에 장작 1년이 소모되었다. 이번을 기회로 깨닫게 되었다. 진정한 존중은 솔직함이라는 것을. 서로의 시간과 자원을 낭비하지 않도록 하기 위한 미덕이라는 점을 새기게 되었다.