[🚖모여타 회고] 2. 이름뿐인 애자일 | MVP? MXP!

이 게시글은 이효린의 애자일 방법론 적용기시리즈 중 하나입니다.
1.[🚖모여타 회고] 1. 좋은 팀원을 만나기까지 | 팀 구성, 팀원 모집의 과정
2. [🚖모여타 회고] 2. 이름뿐인 애자일 | MVP? MXP!
3.[🐾놀멍 회고] 3. 10일 동안 640명이 쓴 서비스 만들기(1) | 애자일 방법론(Scrum), 유레카 최종 프로젝트 우수상

4. [🐾놀멍 회고] 4. 10일 동안 640명이 쓴 서비스 만들기(2) | 서비스 배포 과정, 유레카 최종 프로젝트 우수상

 

 

 

저는 모여타를 진행하며 애자일을 도입했지만, 제대로 적용하지 못한 경험이 있습니다.   

그러나 이러한 실패 경험을 바탕으로 그 다음 프로젝트인 '놀멍'에선 애자일 방법론을 철저히 적용했고, 성공적인 결과로 이끌 수 있었습니다.

 

본 글은 저의 애자일 프로세스 실패 경험을 공유함으로써 실패를 통해 얻은 교훈을 함께 나누고자 글을 쓰게 되었습니다.

 

덧붙여 이 글을 읽으시는 분들은 보다 성공적으로 프로젝트를 진행하셨으면 하는 소망을 담아 글을 씁니다 😊

 

(참고로 이 글에서 이야기하는 모든 모여타의 문제점은 리더인 저의 역량 부족으로 인한 문제라고 생각합니다. 팀원들은 정말 최선을 다 하고 좋은 팀원이었습니다 🥹)

어떻게 진행했어 ?

모여타는 공모전을 목표로 기획된 팀으로, 빠르게 개발하고 배포하는 것이 핵심이었습니다. 따라서 효율적인 협업과 신속한 피드백을 가능하게 하는 애자일 프로세스를 적용하기로 결정했습니다. 

 

그래서,  잘 했어?

마일스톤을 설정하고, 주 단위 스프린트를 진행하였습니다. 그리고 결론적으로 ..

 

무려 56차 회의까지 진행하게 되었습니다....

 

중간중간 추가적인 회의가 있었던 것을 감안해도 56차 회의면,, 느껴지시겠지만 1년 이상 프로젝트가 진행되었습니다.

 

배포가 뭐죠 ?

 

 

네네.. 맞습니다.. 애자일을 하겠다고 했지만 1년동안 개발만하고, 배포는 시도도 못했습니다.

지금와서 생각해보면 전혀 애자일 하지 못하고 오히려 스네일(Snail)이었던 것 같습니다.

 

진짜 애자일 방법론이란..

출처: https://velog.io/@jhpark0912

 

스크럼 등의 프로세스를 활용해 짧은 사이클로 제품 개발 및 테스트 후 피드백을 진행하는 방식입니다.

1~4주 작은 단위로, 디자인 -> 개발 -> 테스트 순서로 진행하게 됩니다.

 

가장 중요한 것은 짧은 사이클로 제품을 개발하는 것으로, 1차 MVP를 설정하는 것이 가장 중요합니다. (안 그러면 1차 MVP만 개발하다 파토가 날 수 있기 때문에.. 맞아요.. 내 얘기예요..)

 

그럼 MVP란 무엇이냐

MVP란, Minimum Viable Product으로 최소 기능 제품으로 제품 개발 과정에서 가장 기본적인 기능만 구현하여 사용자에게 빠르게 제공하고, 피드백을 통해 점진적으로 개선해 나가는 전략입니다. 

 

From Henrik Kniberg’s “ What is Scrum? ” presentation slides (pdf)

 

위 그림처럼 자동차를 만드는 것이 목표라면,

`바퀴 만들기` -> `바퀴 잇기` ->  `자동차 몸체 만들기` -> `자동차 뚜껑 만들기`가 아닌,

`스케이트보드` -> `킥보드` -> `자전거` -> `오토바이`-> `자동차` 순서로 발전시켜나가야 한다는 것이죠.

 

자동차의 가장 기본 기능이 '이동'인 것처럼, 우선 당장 이동이 가능한 스케이트보드를 만들고, 거기에 손잡이를 붙여 킥보드를 만들고, 이후에는 안정성을 더한 자전거, 더 강력한 성능의 오토바이를 거쳐 최종적으로 자동차에 이르게 되는 방식입니다.

 

즉, 처음부터 완벽한 자동차를 만들겠다고 모든 부품을 하나씩 개발하며 시간을 소비하는 대신,
이동이라는 핵심 가치를 초점으로 맞추어 초기 단계에서도 사용자에게 가치를 제공하는 것입니다.

 

 

MVP의 목적

1. 빠른 시장 테스트

• 최소한의 기능으로 제품을 사용자에게 제공해 시장의 반응을 빠르게 확인합니다.

2. 비용 절감

• 초기 개발 비용과 시간을 최소화하면서 사용자로부터 실제 니즈를 파악할 수 있습니다.

3. 효율적 개선

• 사용자 피드백을 바탕으로 필요한 기능만 추가하며 제품을 점진적으로 발전시킵니다.

 

위 3가지 목적을 이루기 위해 가장 선행되어야 할 것은 MVP를 명확히 정의하고, 개발 범위를 정확히 설정하는 것입니다.

 

 

MVP에서 중요한 요소

1. 핵심 문제 및 사용자 니즈 파악

• MVP는 사용자가 겪고 있는 핵심 문제를 해결하는 데 초점을 맞춰야 합니다.
• 이를 위해 타겟 사용자 그룹을 명확히 정의하고, 그들의 가장 큰 니즈를 파악하는 과정이 필요합니다.

2. 우선순위 설정

• 모든 기능을 담으려다 보면 MVP의 본질을 잃을 수 있습니다.
• 제품의 기능 중 가장 핵심적이고 필수적인 기능만 우선 구현하고, 부가적인 기능은 나중으로 미뤄야 합니다.

 

3. 명확한 목표 수립

• MVP를 통해 검증하고자 하는 가설과 목표를 구체적으로 설정해야 합니다.
• 예: "사용자들이 택시팟을 모집하고 참여하는 프로세스를 얼마나 빠르게 이해하고 사용하는가?"

 

4. 적정 수준의 퀄리티 확보

• 최소 기능만 구현한다고 해서 제품의 완성도를 무조건 낮춰도 된다는 의미는 아닙니다.
• 사용자가 편리하게 사용할 수 있는 최소한의 안정성과 사용자 경험(UX)은 반드시 고려해야 합니다.

 

그래서 모여타는 뭐가 문제였나요?

1. 쉽지 않은 일정관리

저희 팀원 모두 학생 신분이었기 떄문에 회의 3~4번 하면 중간고사, 얼마 안 되면 기말고사 ... 이게 반복이었습니다. 시험 공부도 해야했기 떄문에 `매 시험마다 2~3주 가량 프로젝트를 아예 진행하지 못했습니다.`

 

그래서 프로젝트 열이 올라갈때 쯤 시험기간으로 쉬고, 이걸 반복했습니다. 지금 생각해보면 오히려 시험기간 전까지의 3~4주 가량을 한 사이클로 잡아서 `1차 개발 + 배포` -> `시험기간 동안 휴식` -> `2차 개발 시작` .. 이런 구조로 가도 좋았을 듯 합니다.

 

2. MVP가 아닌 MXP(Maximum Viable Product)

1번 문제도 문제였지만, 제가 생각했을 때 모여타 프로젝트의 가장 큰 문제는 MVP가 제대로 정의되지 않았던 것입니다. 사실 이건 리더였던 제가 애자일 프로세스에 대해 많이 공부하고 프로젝트를 시작했어야 했는데, 그러지 못해서 발생한 문제라 생각합니다.

 

프로젝트를 진행하며 초기 기획에서 추가적으로 기획해야 하는 부분이 많았습니다.

그 과정에서 UX를 그리고 사용자의 편의성을 최우선으로 생각했기 때문에 많은 기능이 추가되었습니다.

 

 

1차 기획 (합승 서비스)

택시팟을 모집하고 합승하는 서비스를 만들자 !

 

2차 기획 (채팅 기능 추가)

근데 그러면 채팅이 필요하지 않나 ? 채팅 기능 추가하자 !

 

3차 기획 (거리별 더치페이 기능 추가)

우리 서비스만의 특색이 없는 것 같아. 거리별 더치페이 기능을 추가하자!

 

4차 기획 (사용자 현 위치 추적)

거리별 더치페이 기능에서 사용자가 각자 어디서 내렸는지 알 수 있으면 거리 별 더치페이 기능의 신뢰도가 올라갈 것 같아.

웹 소켓을 활용해서 사용자 현 위치를 추적해서, 사용자의 이동 경로를 추적하고 지도로 보여주자 !

 

등등..

 

이런 식으로 꼬리에 꼬리를 물어 기능이 추가되었고, 초기 생각했던 1차 MVP보다 정말 많은 기능이 추가 되었습니다.

 

3. 기획의 문서화 부족

추가된 기능들이 대부분 주간 회의 중에 나온 아이디어였습니다. 하지만 이런 기획 사항을 체계적으로 문서화하지 않아 팀원들 간의 이해 차이가 발생했습니다. 특히, 디자이너와 제가 생각하는 사용자 플로우가 달라 충돌이 발생했었습니다.

 

하나하나 해결해보자 !

1. 일정 관리

운이 좋게도(?) 모여타 프로젝트를 1년간 진행한 끝에 팀 내 일정 관리 문제가 자연스럽게 해결되었습니다. 4학년이었던 팀원들은 모두 졸업을 했고, 3학년이었던 디자이너님은 휴학을 결정하면서 시험 기간이라는 방해 요소가 사라졌기 때문입니다.

 

이는 모여타라는 프로젝트의 특수한 상황에 해당하는 이야기이기에, 이후 진행했던 프로젝트에서는 보다 체계적인 일정 관리 방법을 도입했습니다.

• 데일리 스크럼: 매일 정해진 시간에 짧은 회의를 열어 각자의 진행 상황과 당일 목표를 공유했습니다.
  • 이를 통해 각자의 작업 진척도를 빠르게 파악하고, 병목현상이 생길 경우 바로 해결할 수 있었습니다.
• 작업 기간 블록화: 큰 작업을 주 단위 또는 월 단위 블록으로 나눠 설정하고, 팀원들이 작업을 명확히 계획하도록 했습니다.

관련해서는 다음 글인 놀멍의 성공적인 애자일 프로세스 글에서 더 구체적으로 말씀드리도록 하겠습니다. 

 

2. MVP 정의

 

이전에도 말씀드렸다시피 모여타에서 애자일 프로세스를 제대로 적용하기 힘들었던 이유는 MVP가 제대로 정의되지 않은 것, 그리고 MVP가 아닌 MXP(Maxium Viable Product), 였던 것 같습니다.

 

팀원들과 함께 오프라인으로 만나 소통하며 필요한 기능과, 당장은 필요하지 않은 기능을 구분하였습니다.

 

이렇게, MVP의 범위를 명확히 정의하니,  애자일 방식에 가까운 프로세스를 조금씩 적용할 수 있었습니다. 이를 통해 초반에 있었던 개발 범위의 혼란을 줄이고, 프로젝트 진행 효율성을 높일 수 있었습니다.

 

3. 기획의 문서화 부족

기획을 문서화하지 않아 팀원들 사이에 이해 차이와 의사소통 문제가 발생했던 것도 큰 장애물이었습니다.

이를 해결하기 위해 유저 플로우차트와, 기능 세부사항을 정의하였습니다.

 

이렇게 팀원들과 함께 기획된 기능들을 하나하나 짚어보는 시간을 가졌습니다.

이를 통해 팀원들 간의 기능 구현 우선순위와 목표를 다시 한번 확인하고, MVP를 명확히 정의할 수 있었습니다.

• 불필요하거나 우선순위가 낮은 기능은 제거하거나 나중으로 미루고, 핵심 기능 구현에 집중할 수 있었습니다.
• 기획을 재정립하면서 팀원들 간의 이해와 협업도 한층 더 원활해졌습니다.

 

그 결과는 ?

프로세스 개선 자체는 성공적이었습니다. 기획을 재정립하고 작업 흐름을 체계화하면서 팀원들 간의 소통 문제를 해결할 수 있었고, 이를 통해 팀원들의 사기를 북돋우며 프로젝트의 방향성을 명확히 할 수 있었습니다.

특히, 기획을 다시 되짚고 현실적인 목표를 설정함으로써 팀원들이 새로운 목표를 향해 달려나갈 동력을 얻을 수 있었습니다.

 

새로운 도전과 현실적인 제약

그러나 이미 프로젝트가 8~9개월차에 접어들면서 팀원들의 개인적인 상황이 달라지기 시작했습니다.

• 부트캠프에 들어간 팀원: 개인 학습과 성장에 집중하면서 프로젝트에 할애할 시간이 줄어들었습니다.
• 취업한 팀원: 새로운 환경에서의 적응과 업무로 인해 프로젝트에 참여하기 어려워졌습니다.
• 다양한 개인 목표: 팀원 각각의 목표가 달라지면서 프로젝트에 대한 몰입도와 기여도가 점차 분산되었습니다.

결과적으로, 팀원들의 다양한 목표를 인정하고, 모여타는 개인의 발전을 위한 포티폴리오용 프로젝트로 남겨두자는 결론을 내릴 수 있었습니다.

 

개인적인 성장과 배움

특히 저같은 경우에는 주도적으로 참여한 프로젝트가 처음이었기 떄문에, 코드가 정말 개판이었는데..^^ 이를 리펙토링하는 용도로 야무지게 활용했습니다.

모여타는 비록 공모전 수상, 서비스 배포 등의 초기 목표를 달성하진 못했지만 팀 프로세스 관련해서 배울 수 있는 정말 감사한 기회였다고 생각합니다.

 

프로젝트를 통해 얻은 교훈

• 프로젝트 관리의 유연성
  • 팀원들의 상황 변화와 외부적인 제약에 적응하며, 프로젝트를 관리하는 데 있어 유연성의 중요성을 배웠습니다.
• 효율적인 팀 커뮤니케이션
  • 서로의 이해 차이를 줄이고, 명확한 목표를 공유하는 방법을 익히게 되었습니다.
• 애자일 방법론의 실제 적용
  • 애자일 프로세스를 적용하는 과정에서, 우선순위 설정과 MVP 정의가 얼마나 중요한지를 체감했습니다.

 

앞으로의 도전

 

이 경험에서 멈추지 않고, 저는 애자일 방법론에 대해 더 깊이 배우고자 『스크럼』이라는 책을 읽으며 다음 프로젝트를 준비하고 있었습니다.

 

모여타는 단순히 하나의 프로젝트를 넘어, 제 개인적인 성장과 학습의 중요한 출발점이 되었습니다.

 

그리고 그 결실은 다음 프로젝트인 놀멍에서 빛을 발할 수 있었습니다.

놀멍에서의 애자일 프로세스 이야기는 다음 글에서 이야기 하겠습니다.