공지
주간 SaaS 의 발전을 위해 설문조사에 참여해 주세요!

MVP는 MVA가 필요하다

최소 실행 가능한 아키텍처의 중요성

2024.05.14 | 조회 829 |
2
from.
SaaS노동자

주간 SaaS

B2B SaaS 비즈니스 모델과 멀티 테넌트 아키텍처 설계에 관한 좋은 콘텐츠를 소개합니다.

Created by 주간SaaS with DALLE
Created by 주간SaaS with DALLE

주간SaaS 이번주 소개글:

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


요약

  • 최소기능제품(MVP)의 개념은, 팀이 고객에게 가장 가치 있다고 생각되는 제품을 조기에 제공하는 데 집중하여 상당한 시간과 리소스를 투자하기 전에 제품의 시장 규모를 저렴한 비용으로 신속하게 측정할 수 있도록 도와줍니다.
  • MVP는 제품의 시장성뿐만 아니라 시간이 지남에 따라 변화하는 요구사항에 따라서 기술도 유연하게 변화할 수 있는지, 기술적 실행 가능성도 고려해야 합니다.
  • 모든 애플리케이션에는 MVP로 생각할 수 있는 초기 버전의 릴리스를 거치기 때문에, MVP는 스타트업에만 국한되지 않습니다. MVP는 제품 개발 전략의 유용한 구성 요소입니다. 단순한 프로토타입과 달리 MVP는 '버려지는' 것이 아닙니다.
  • MVP의 일부로 최소 실행 가능한 아키텍처(MVA)를 만들면 팀이 기술적 실행 가능성을 평가하고 제품이 발전함에 따라 조정할 수 있는 제품의 안정적인 아키텍처 기반을 제공하는 데 도움이 됩니다.
  • 어떤 결정을 내리는것(혹은 내리지 않는 것)이 제품의 실행 가능성 및 지속 가능성에 영향을 미치거나, 결정을 변경하는 데 비용이나 시간 측면에서 너무 많은 비용이 들어 제품을 비 경제적 이거나 비 실용적 이거나 불가능하게 만드는 경우라면, 해당 결정은 MVA 사상의 일부를 통해서 내려져야 합니다.
  • 아키텍처 결정을 투명하게 공개하면 조직이 특정 선택이 이루어진 이유를 더 잘 이해할 수 있으므로 변화하는 시장 상황과 진화하는 고객 요구에 맞게 제품을 조정하는 방법에 대해 더 나은 결정을 내릴 수 있습니다.

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

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

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

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

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

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

출처: https://www.infoq.com/articles/minimum-viable-architecture/
출처: https://www.infoq.com/articles/minimum-viable-architecture/

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

  • 최소한의 구성 요소 집합을 포함하는 설계. 팀이 주로 MVP를 최대한 빠르게 구현하는 데 중점을 두는 경우, MVA는 아직 잘 이해되지 않은 품질 속성 요구사항(QAR)보다는 기능적 요구사항에 주로 영향을 받는 경향이 있습니다. 속도가 주요 관심사이기 때문에 디자인 결정은 전술적인 경향이 있으며, 일반적으로 MVP가 성공하여 최종적으로 본격적인 제품으로 발전할 경우 MVA를 다시 작업해야 할 것으로 예상합니다. 제품의 지속 가능성은 우선순위가 아닙니다. MVA를 만드는데 사용되는 구성 요소는 상용 클라우드 공급업체에서 제공하는 서비스, 로우코드 또는 노코드 제품으로 부터 조달하거나 기존 시스템을 최소한의 변경 만으로 재 사용할 수 도 있습니다.

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

  • 개발 팀이 솔루션에 대해 내린 몇 가지 기본적인 선택입니다. 이 정의는 지속 가능성을 달성하기 위해 기술 부채를 최소화하면서 제품이 기능적 요구 사항과 더불어 QAR을 충족하는 방법을 고려함으로써 MVP의 지속 가능성, 즉 장기적인 실행 가능성에 초점을 맞추고 있습니다.

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

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

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

  • 동시성 - 제품이 응답해야 하는 이벤트를 생성하는 동시 사용자, 센서 및 기타 디바이스의 수와 관련된 것입니다.
  • 처리량 - 제품이 정의된 기간 동안 처리할 수 있어야 하는 트랜잭션 또는 데이터의 양과 관련된 것입니다.
  • 지연 시간 및 응답성 - 제품이 이벤트에 얼마나 빨리 응답해야 하는지와 관련된 사항입니다.
  • 확장성 - 일반적으로 거의 선형적인 관계에 있는 시스템 비용 증가에 따라 증가하는 워크로드를 처리할 수 있는 시스템의 능력과 관련된 것입니다.
  • 지속성 - 제품에서 저장하고 검색해야 하는 데이터의 처리량 및 구조(또는 그 부족)와 관련된 것입니다. 종종 다양한 종류의 데이터 저장 기술(예: SQL DBMS, NoSQL DBMS 등)에 대한 결정이 포함됩니다.
  • 보안 - 기밀성, 무결성 및 가용성을 확보하여 제품 데이터에 대한 무단 사용 또는 액세스로부터 제품을 보호하는 방법과 관련된 사항입니다.
  • 모니터링 - 제품을 지원하는 사람들이 제품이 QAR을 충족하지 못하는 시점을 파악하고 중요한 시스템 문제를 예방할 수 있도록 제품을 계측하는 방법과 관련됩니다.
  • 플랫폼 - 메모리, 스토리지, 이벤트 시그널링 등과 같은 시스템 리소스 제약과 관련된 QAR을 제품이 어떻게 충족할 것인지와 관련된 것입니다. 예를 들어, 실시간 및 임베디드 제품(예: 디지털 시계 또는 자동 제동 시스템)은 클라우드 기반 정보 시스템과는 상당히 다른 제약 조건을 가지고 있습니다.
  • 사용자 인터페이스 - 제품이 사용자와 통신하는 방법에 대한 결정과 관련된 것으로, 예를 들어 가상 현실 인터페이스는 2차원 그래픽 사용자 인터페이스와 상당히 다른 QAR을 가지며, 명령줄 인터페이스와도 상당히 다른 QAR을 가집니다. 이러한 결정은 위에서 언급한 다른 QAR에 영향을 미칠 수 있습니다. (GUI, VR, 명령줄 또는 다른 종류의 인터페이스).

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

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

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

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

  • 팀은 처음에 소프트웨어 시스템의 QAR을 정확히 충족하는 충분한 아키텍처를 개발하여 실제 고객이 사용할 수 있을 만큼 실행 가능한 제품을 신속하게 만듭니다.
  • 그런 다음 팀은 고객이 실제로 필요로 하는 것이 무엇인지 더 많이 알게 되면서 추가 요구 사항이나 요구 사항 변경(QAR 포함)을 충족하도록 제품을 지속적으로 발전시킵니다. 아키텍처를 유연하게 유지하는 것은 필수적이며, 지속적 아키텍처 원칙, 특히 원칙 3인 "꼭 필요할 때까지 설계 결정을 연기한다"를 적용하는 것이 이 목표를 달성하는 효과적인 방법입니다.

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

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

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

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

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

결론

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

다가올 뉴스레터가 궁금하신가요?

지금 구독해서 새로운 레터를 받아보세요

✉️
댓글 2개

의견을 남겨주세요

확인
  • 팬텀

    0
    about 1 month 전

    좋은 글 고맙습니다.

    ㄴ 답글 (1)

© 2024 주간 SaaS

B2B SaaS 비즈니스 모델과 멀티 테넌트 아키텍처 설계에 관한 좋은 콘텐츠를 소개합니다.

자주 묻는 질문 오류 및 기능 관련 제보

서비스 이용 문의admin@team.maily.so

메일리 (대표자: 이한결) | 사업자번호: 717-47-00705 | 서울 서초구 강남대로53길 8, 8층 11-7호

이용약관 | 개인정보처리방침 | 정기결제 이용약관 | 070-8027-2840