최소 기능 제품, Minimum Viable Product(MVP)

Iterative and Icremental Development를 강조한다. 완전하게 설계된 하나의 프로젝트를 진행하는 것보다 먼저 작은 기능을 구현한 프로젝트에다 반복적으로 기능을 추가하면서 개선하는 방식의 개발이 더 효율적이다는 개발방법론이다. MVP wiki link

두가지 시나리오의 비교

위 그림의 두 가지 시나리오를 비교해보며 조금 더 자세히 알아보자.

고객은 물건을 편하게 옮기기 위한 제품을 만들기를 원하고, 스스로 조사한 결과 자동차라는 결과물을 만들어달라고 의뢰하였다.

최적의 분업화로 최적의 퍼포먼스를.

첫번째 시나리오를 나타낸 그림이다. 최종목표인 자동차를 만들기 위해서 필요한 부품들을 각각 다른 팀에 의뢰하였다. 개발이 완성된 부품은 하나로 조립되어 자동차가 완성된다.

이때 바퀴를 만든 경험이 있는 팀은 바퀴 생산에만 집중할 수 있으며 각각 분업화 된 업무로 최상의 퍼포먼스를 낼거라고 생각했다.

이 접근법에서 문제점은 무엇일까? 계획대로 진행되지 못했을 경우 위험부담이 크다는 점이다. 예를 들어 하나의 부품이 일정대로 완료되지 못한 경우 다른 부품들이 완성된 상태라도 자동차라는 상품을 내놓을 수 없게 된다. 고객의 눈에는 내가 의뢰한 제품이 완성되지 못한 상황만 보여질 것이다. 90%의 제품이 초안대로 개발되었지만 의뢰자의 입장에서는 0의 결과물을 가져가는 최악의 상황이 발생할 수 있다.

작은 기능에서 시작해서 반복적인 개선을.

이제 두번째 시나리오를 살펴보자. 고객의 목표는 물건을 쉽고 빠르게 옮기기 위한 제품을 만들어 달라는 것이다. 고객이 처음 예상한 결과물인 자동차는 고도의 기술이 필요하다. 그러므로 우선 핵심 기능을 하는 간단한 형태의 프로토타입을 만들어본 후 개선점을 찾아나가도록 한다.

개발팀은 바퀴를 가지고 있고 적은 힘으로 쉽게 이동할 수 있는 물건으로 스케이트보드라는 첫번째 프로토타입을 만들었다. 예상했던 자동차에 비해서 스케이트보드는 너무 터무니없어 보일 수 있다. 하지만 이 간단한 프로토타입의 진정한 가치는 고객에게 피드백을 받을 수 있다는 점이다. 고객의 요구사항과 프로젝트의 진행사항이 일치하는지를 프로토타입을 통해 검증하면서 개발을 진행할 수 있다. 이 방식의 또 다른 장점으로는 고객이 다른 요청사항을 추가 했을 경우 유연하게 대처할 수 있게 된다.(다음 프로토타입에 적극적으로 반영 해볼 수 있다.)

Iterative and incremental하게 프로젝트를 진행하는 시나리오를 조금 더 구체적으로 가정해보자.
우리는 1번 프로토타입인 스케이트보드를 만든 후 고객에게 제공했다. 고객은 사용해본 후 '물건을 옮기는 용도에는 사용하지 못했지만 내가 다른 건물로 이동할 때 걷는 것보다 편리하게 이용할 수 있었다. 하지만 몇차례 넘어질 뻔한 상황을 겪었고 손잡이가 추가되어야할 것 같다'고 의견을 제시했다.

2번 프로토타입 개발에 고객의 피드백을 반영하여 손잡이를 추가해본다. 그리고 고객에게 다시 한 번 사용을 권유한다. 고객은 손잡이가 생긴 점은 좋지만 여전히 물건을 옮기는데 쓸 수 있는 물건이 아니라고 했다.

핵심 요청사항인 물건을 옮기는 기능을 수행하기 위해서 제품의 사이즈를 키우기로 했다. 그 결과 3번 프로토타입인 자전거를 개발했다. 고객은 자전거를 사용해보고 크게 만족한다. 우선 스케이트보드보다 훨씬 적은 힘으로 이동할 수 있고 어느 정도의 짐을 나를 수도 있게 되었기 때문이다.

이때 고객이 "처음엔 자동차 형태를 생각하고 주문했지만, 이 자전거 제품을 사용해보니 저의 사용환경에서 충분한 성능을 갖고 있는 것 같네요. 이 제품에서 조금의 디자인을 수정하고 프로젝트를 완료하고 싶어요." 라고 말했다고 상상해보자.
고객과 개발팀은 모두 불필요한 시간과 비용을 대폭 절감하면서도 고객에게 만족스런 제품을 제공한 훌륭한 프로젝트로 마무리 될 것이다.

하지만 우리의 고객은 자전거에도 역시 만족하지 못했다. 직접 페달을 밟아서는 먼 거리로 짐을 나를 수 없다는 이유 때문이었다.

이번에는 장거리 이동을 위해 엔진을 부착하고 4번 프로토타입인 오토바이를 만들었다.
오토바이를 사용해본 고객은 직접 페달링을 하지 않아도 되는 점에 만족했지만 조금 더 많은 양의 짐을 싣기를 원했다.

개발팀은 오토바이를 만들 때의 경험으로 엔진과 바퀴, 손잡이, 시트 등을 자동차에 맞게 업그레이드한 후 최종 프로토타입인 자동차를 만들었다. 고객은 자동차를 사용해보고 아주 만족했다. 힘들이지 않고 많은 양의 물건을 편안하게 운반한다는 목적을 달성했기 때문이다.

< Scenario 1의 자동차 >

< Scenario 2의 자동차 >

여기서 눈여겨볼 점은 두 시나리오의 최종 결과물인 자동차의 형태가 다르다는 점이다. 고객이 오토바이 프로토타입을 사용한 후 바람을 맞으며 달리는 기분이 매우 좋았고 자동차에서도 이런 장점을 누릴 수 있으면 좋겠다는 피드백을 전해왔다. 그래서 두번째 시나리오에서 개발팀은 자동차를 개발할 때 컨버터블 형태의 자동차르 개발했고 고객은 이 점에 대해 매우 만족했다.

두번째 시나리오의 가장 큰 장점은 의뢰 고객이 프로젝트의 참여자가 된다는 점이다. 대체로 프로젝트의 요구사항은 한번에 정확히 작성되기 힘들기 때문에 고객에게 직접 사용할 수 있는 프로토타입을 제공함으로써 피드백을 얻고 상호간의 프로젝트에 대한 요구사항을 조율할 수 있는 기회를 갖는다. 게다가 최종 결과인 자동차 형태의 제품을 만들지 못했더라도 고객은 최소한 오토바이 형태의 대체품을 얻을 수 있으며, 성공한 프로젝트는 아니지만 최소한의 결과물을 얻을 수 있다. 위에서 언급한대로 훨씬 심플한 형태의 프로토타입으로 고객이 만족할 경우 비용을 크게 절약할 수 도 있을 것이다.

하지만 고객은 자동차를 사고 싶어한다.

사실 고객은 자동차를 사고 싶을 때, 바퀴를 사지도 않고, 자전거부터 사지도 않는다. 고객은 자동차를 사고 싶어할 때 자동차를 산다. 그러므로 자동차를 개발하기 위해 스케이트보드나 자전거를 만드는 일은 최소 기능의 범위를 너무 좁게 잡은 것이다. 바퀴 달린 물건이라는 점보다 비바람을 막을 수 있고 네 바퀴로 안전하게 달릴 수 있는 가장 심플한 형태의 자동차라는 올바른 최소 기능의 범위를 지정하고 개발을 시작할 수 있도록 해야한다. 그래서 위의 스케이트보드 사례는 Viable한 기준을 지나치게 심플한 기능으로 지정했다는 비판을 할 수도 있을 것이다.

Summary

간단히 말하자면 고객으로부터 양질의 피드백을 얻고 시행착오를 줄이며 개선된 버전의 제품을 만드는 과정을 반복하는 것이다. 이때 가장 중요한 점은 사용자가 직접 사용해보고 피드백을 줄 수 있는 적절한 수준의 최소 기능을 정의해야한다는 점이다. 자동차를 만들고 싶다면 자동차의 기본인 주행이 가능한 프로토타입을 만드는 것이 우선이 되어야하고, 피드백을 통해 주행 성능을 개선할지 혹은 승차감을 개선할지 프로젝트의 방향성을 잡을 수 있을 것이다.

최소 기능 제품 개발방법론은 작은 규모의 팀이나 혼자서 프로젝트를 진행할 때 효율적이다. 작은 기능을 하나씩 업데이트하는 과정으로 완성도를 높여나가는 것이 프로젝트를 끝까지 마칠 수 있는 좋은 원동력이 될 수 있다.

더 자세한 내용은 Henrik Kniberg의 글에서 확인할 수 있습니다.