MVP는 MVA가 필요하다

주간SaaS 이번주 소개글:

안녕하세요 주간SaaS 입니다. SaaS 아키텍처 설계 시 컨트롤 플레인 패턴의 필요성과 중요성을 강조 합니다만 아직 PMF를 찾지 못한 상태에서 무리한 컨트롤 플레인 설계와 개발에 자원을 소비하는 것은 낭비일수 도 있습니다. 그렇다고 당장의 민첩함을 위해 나중의 리팩토링과 리아키텍쳐링의 수고를 담보로 잡을 수도 없는 어려운 상황이 됩니다. 오늘 소개하는 글은 이런 어려운 상황에서 중심을 잡을 수 있도록 도와주는 중요한 틀, Minimum Viable Architectdure, 을 소개 합니다. 읽어보시고 도움 얻어가시면 좋겠습니다.

요약

최소기능제품(Minimum Viable Product)이라는 개념은, 팀이 고객에게 가장 가치 있다고 생각되는 제품을 조기에 제공하는 데 집중할 수 있도록 도와줍니다. 따라서 이를 통해 성공하지 못할 수도 있는 제품에 상당한 시간과 자원을 투자하기 전에 해당 제품의 시장 규모를 빠르고 저렴하게 측정할 수 있습니다. 간단히 말해 MVP는

"초기 고객이 사용할 수 있을 만큼 충분한 기능을 갖춘 제품 버전으로, 향후 제품 개발에 대한 피드백을 제공할 수 있습니다. MVP를 출시하는 데 초점을 맞추면 개발자는 잠재적으로 불필요한 긴 작업을 피할 수 있습니다. 대신, 개발자는 작동 중인 버전을 통해 반복적으로 피드백에 대응하면서 제품의 요구 사항에 대한 가정을 실험하고 검증할 수 있습니다."

하지만 MVP 개념은 꼭 스타트업이 아니어더라도 유용합니다. 모든 애플리케이션에는 MVP로 생각할 수 있는 초기 버전의 릴리스를 거칩니다. 거의 모든 조직에서 수개월 또는 수년에 걸쳐 새로운 시스템을 개발한 후 배포한 결과 사용자의 요구 사항을 충족하지 못한다는 사실을 알게 된 사례는 수없이 많다는것만 봐도 알 수 있습니다. MVP를 조기에 릴리스 하면 잘못된 요구 사항에 많은 시간, 비용 및 노력을 투자하는 것을 방지할 수 있습니다.

MVP의 목표를 더 잘 이해하려면 "실행 가능"하다는 것이 무엇을 의미하는지 생각해봐야 합니다. MVP는 경제적으로 실행 가능하기 위해 충분한 수의 사람들에게 충분한 규모의 가치를 제공한다는 것을 입증해야 합니다. 즉, 충분한 사람들이 구매하여 좋은 투자 수익률을 제공할 수 있는 제품 이어야 합니다. 다시 말해, MVP를 통해 해결하고자 하는 문제는, 해결 가치가 있을 만큼 충분히 크고 충분한 사람들에게 필요한 문제라는 뜻입니다. 그러나 경제성에는 비용이라는 또 다른 차원이 있습니다. 제품의 가격이 저렴해야 하고, 제품의 총 수명 주기 비용이 제품의 원하는 수익 마진에 의해 정의된 한도 내에 있어야 합니다.

또한 최신 애자일 접근 방식을 사용하여 시간이 지남에 따라 피드백 및 변화하는 요구 사항을 기반으로 제품을 점진적으로 발전시킬 수 있어야 하며, 단순한 프로토타입과 달리 MVP는 "버려지는" 것이 아니어야 합니다. 바로 이 부분에서 최소 실행 가능한 아키텍처가 중요한 역할을 합니다.

최소 실행 가능한 아키텍처란 무엇인가요?

사람들이 "최소 실행 가능한 아키텍처(MVA)"라는 용어를 사용할 때는 보통 다음 중 하나를 의미합니다:

MVA에 대한 이러한 접근 방식의 결점은 "솔루션의 아키텍처는 고객에게 중요하지 않다"는 믿음입니다. 하지만 고객은 솔루션의 지속 가능성에 관심이 있기 때문에 아키텍처가 중요합니다. 이전 글에서 지적했듯이 이 접근 방식은 초기 설계를 크게 리팩토링해야 하므로 시간과 노력이 낭비되고 잠재적으로 상당한 기술 부채가 발생할 수 있습니다. 팀의 현재 주기 시간이 너무 느려 효과적인 피드백 루프를 제공할 수 없는 경우에는 아키텍처적인 문제(그 자체로 문서화해야 하는 아키텍처적 결정)보다 제공 속도를 우선시 하기로 결정하는 것이 옳을 수 있습니다. 하지만 팀은 자신이 제공하는 결과물 중 상당 부분이 나중에 상당한 재 작업이 필요할 수도 있다는 사실을 반드시 받아들여야 합니다.

어떤 종류의 결정을 통해 MVA 만들어가는가

"무엇이 충분한가?"라는 질문에 대한 답은, 제품의 실행 가능성을 위해 아키텍처 결정을 내려야 하는지 여부에 따라 달라집니다. 결정을 내리는(또는 내리지 않는) 것이 제품의 실행 가능성 및 지속 가능성에 영향을 미치거나 결정을 변경하는 것이 비용이나 시간 측면에서 너무 많은 비용이 들어 제품을 비 경제적 이거나 비 실용적 이거나 불가능하게 만드는 경우, 해당 결정을 MVA의 일부로 포함시켜야 합니다.

이러한 결정에는 다음과 같이, 제품이 제품/시스템의 특성과 연관된 QAR을 어떻게 다룰지를 포함합니다:

이 목록은 완전한 목록이 아니므로 개발팀은 자체 QAR에 따라 이 목록에서 추가하거나 제외해야 할 수도 있습니다.

개발 팀이 제품의 MVA를 발전시키는 방법

일회용 프로토타입과 달리 개발팀은 제품의 첫 번째 릴리스인 MVP 구축의 일부로 초기 MVA를 구축합니다. 애자일 접근 방식을 사용하여 일련의 반복(또는 스크럼에서는 스프린트)을 통해 MVP를 발전시키는 것처럼 MVA도 발전시킵니다. 어느 시점에서든 제품은 알려진 QAR을 충족해야 합니다. 이렇게 하면 추측과 가정에 기반한 불필요한 기능으로 제품에 부담을 주지 않으므로 지속 가능한 방식으로 비즈니스 기능을 지속적으로 제공하는 데 도움이 됩니다.

이런 접근 방식은, 개념적 수준에서 다음과 같이 설명할 수 있습니다:

즉, 팀에서 제품에 필요한 것이 무엇인지 더 많이 알게 되면 현재 알고 있는 요구 사항을 충족하는 데 꼭 필요한 만큼만 제품을 만들고 아키텍처에 대한 결정은 최소화하여 제품은 계속 MVP로, 아키텍처는 계속 MVP를 지원하는 MVA로 유지합니다. 팀에서 제품에 기능과 QAR을 구현하는 데 많은 시간과 노력을 들이고도 고객이 그 가치에 대한 의견을 공유하지 않는다면, 가치에 대한 믿음은 고객에게 검증되기 전까지는 가정에 불과할 뿐입니다. 이때 가설과 실험이 유용합니다.

간단히 말해서 가설은 아직 입증되지 않은(또는 입증되지 않은) 어떤 관찰을 통해서 제안된 설명입니다. 요구 사항의 맥락에서 가설은 어떤 일을 하면 다른 결과가 나올 것이라는 믿음, 예를 들어 기능 X를 제공하면 결과 Y가 나올 것이라는 믿음입니다. 실험은 이러한 가설을 증명하거나 거부하기 위해 고안된 테스트입니다.

모든 기능과 모든 요구 사항(QAR 포함)은 실제로 가치에 대한 가설을 나타냅니다. 경험적 접근 방식의 목표 중 하나는 이러한 가설을 명시하고 기능과 요구 사항의 가치를 명시적으로 테스트하는 실험을 설계하는 것입니다. 가치 여부를 판단하기 위해 실제로 전체 기능이나 요구 사항을 구축할 필요는 없으며, 팀이 그 가치를 증명하거나 반증할 수 있는 중요한 가정을 검증할 수 있을 만큼만 구축하는 것으로 충분합니다.

MVA의 맥락에서 팀은 모든 반복(스프린트)에서 솔루션에 대한 가정을 경험적으로 테스트한 다음 배운 내용을 바탕으로 의사 결정을 내림으로써 가정을 검증합니다. 예를 들어 스크럼의 맥락에서 스크럼 팀은 제품 백로그의 항목을 가져와 학습해야 할 사항을 고려합니다; 제품 백로그 자체는 기능 요구 사항(기능 및 스토리 같은 것)과 QAR로 구성됩니다.

팀은 스프린트를 계획할 때 스프린트의 목표를 충족하기 위해 제품 백로그에서 항목을 가져오는데, 여기에는 제품이 고객에게 제공하는 가치에 대한 가설 뿐만 아니라 시간이 지남에 따라 제품이 발전함에 따라 어떻게 지속 가능한지에 대한 가설도 반영됩니다. 따라서 QAR을 포함한 제품 백로그의 항목 순서에 따라 팀은 가치에 대한 가정과 제품이 지속 가능한 가치를 제공하기 위해 어떻게 작동해야 하는지에 대해 직면하게 됩니다.

결론

MVP는 제품의 시장성뿐만 아니라 시간이 지남에 따라 변화하는 요구사항에 맞춰 유지 및 조정할 수 있는 기술적 실행 가능성도 고려해야 합니다. 모든 애플리케이션에는 MVP로 생각할 수 있는 초기 릴리스 버전을 거치며, 이는 제품 개발 전략의 유용한 구성 요소가 될 수 있기 때문에 MVP는 스타트업에만 국한되지 않습니다. MVP의 일부로 MVA를 만들면 팀이 기술적 실행 가능성을 평가하고 제품이 발전함에 따라 조정할 수 있는 안정적인 제품 기반을 제공하는 데 도움이 됩니다. 아키텍처 결정을 투명하게 하면 조직이 특정 선택이 이루어진 이유를 더 잘 이해할 수 있으므로 변화하는 시장 상황과 진화하는 고객 요구에 맞게 제품을 조정하는 방법에 대해 더 나은 결정을 내릴 수 있습니다.

주간 SaaS 에 대한 피드백(익명)을 남길 수 있어요