개인적인 MVP에 대한 이해와 적용 경험을 정리해 봅니다.

MVP?

MVP는 Minimum Viable Product의 약어이다. ‘Viable’이 실행 가능한이란 뜻이고, ‘Minimum’은 실행 가능하기 위해 최소한으로 필요한 기능이라는 뜻이다. MVP는 주로 ‘어떤 서비스가 있다면 어떤 문제를 해결할 수 있을 것이다’라는 가설을 빠르게 검증하기 위한 용도로 사용되는데, 여기서 검증하고자 하는 어떤 서비스가 실행 가능한, 최소한의 상태를 정의하는데 MVP가 사용된다.

제품 스펙 분류하기

이제 MVP를 실천하기 위해서는 수집된 모든 제품 스펙을 두 가지로 나누어야 한다. 하나는 가설 검증을 위해 제품에 없어서는 안되는 핵심 기능(Core)이고 나머지는 가설 검증과 직접적인 연관이 적은 고급 기능(Advanced)이다.

데드라인 안에서

뿐만 아니라 프로젝트에 데드라인 시간이 있다면 주어진 시간 안에 만들 수 있는 제품 스펙을 정의하는데 사용할 수도 있다. 만약 제품 스펙을 일정 안에 구현할 수 없다고 판단되면 가설의 크기를 줄여 제품의 스펙을 줄여 나갈 수도 있을 것이다.

괴팍한 고객과 대화의 실마리 만들기

만약 고객이 터무니 없이 짧은 일정을 제안하며 거대한 제품 스펙을 요구하는 경우에도 MVP 전략은 우리에게 유용하다. 그런 상황에서 말도 안되는 제안이라며 화를 내거나, 무작정 못한다고 말하면 상황이 많이 나빠진다. 이 때 침착하게 마음을 가다듬고 냉철하게 분석하여 “이 정도 기간이면 우리는 최소한의 기능이 동작하여 사용할 수 있는 이러이러한 스펙의 제품을 먼저 만들 수 있고, 추후 편리성이나 성능을 개선하는 Advanced 한 기능을 보완해 나갈 수 있을 것 같습니다.” 라고 피드백을 주면 많은 경우 대화가 풀리기 시작한다.

기준 설명하기

위와 같이 MVP를 위해 초기 제품 스펙을 분류하고 나면 반드시 팀내에 그리고 모든 이해 관계자들에게 위 기준을 충분히 설명해야 한다. 왜냐하면 제품의 스펙은 프로젝트를 진행하면서 진화(요구사항이 추가되거나, 변경되거나.)하기 나름인데 이 때 협상에 위 기준을 설득력 있게 사용할 수 있다.

이제 협상하기

이제 프로젝트가 진행되다 보면 제품 스펙이 진화하기 시작한다. 개발팀 스스로 보기에 이런 것들이 더 필요해 보이거나 저런 것은 불필요 보이기도 한다. 또한 고객이 ‘이것 해주세요. 저것 바꿔주세요’ 라는 요구를 쏟아 놓기도 한다. 이 때 개발팀 스스로에게 또는 이해 관계자에게 우리가 이미 정한 기준을 리마인드 해주면 협상이 조금 수월해 진다. “우리는 지금 주어진 자원으로 정해진 일정에 제품이 동작하도록 하기 위하여 핵심 기능을 먼저 개발하고 있습니다. 그 기능은 당장 없으면 조금의 불편을 감수해야 할 수도 있지만 대세에는 영향이 없습니다. 먼저 동작하게 하는 것이 우선입니다.”

고객의 신뢰 얻기

만약 위의 이유로 고객의 새로운 요구사항을 보류 해야 하는 상황이라면 유용한 팁이 하나 있다. 그건 바로 현재 보류하고 있는 고객의 요구를 공적인 문서에 기록하고 (고객도 항상 볼 수 있는 WIKI 페이지가 적절하다) 추후 구현을 위해 추적 관리할 것이라고 말해 주는 것이다. 고객은 자신의 요구가 흘러가지 않고 메모되며, 그럴듯한 테이블 안에서 추적되어 가고 있음을 볼 때 안도감을 느끼는 경우가 많은 것 같다. 나아가 시간이 갈 수록 테이블의 ‘완료’ 컬럼이 하나씩 동그라미로 채워져 가고 있다면 다음번에 동일한 상황에서는 더욱더 신뢰를 가지는 경우가 많다.

마치며

이 처럼 MVP를 적용하면 빠르게 제품 가설을 검증해 볼 수 있고, 혹 SI 프로젝트라면 데드라인 안에 반드시 동작하는 최소 기능 제품을 완성하여 프로젝트의 위험을 줄일 수도 있다. MVP 기준을 잘 설명하고 설득해 두면 프로젝트 진행 기간 내내 팀 스스로도 고객과도 원만히 협상에 임할 수 있고, 고객의 추가적인 요구들을 Wiki 페이지에 잘 기록하고 관리해 나가면 고객의 신뢰를 얻을 수도 있다.