MSA 프로젝트 중 MVP를 만들었던 이유(feat. 일정 딜레이)

 

 

 

 

 

MVP 란?

• Minimum Viable Product의 약자로 최소 실행 가능 제품이란 뜻입니다.

 

 

MVP는 왜 만들까?

• 보통 아이디어가 실제 시장에서도 유효한지 검증하기 위해 최소한의 핵심기능만 구현해서 확인하기 위해 만드는 것 같은데 현재 프로젝트의 경우에는 설계 컨셉에 대해 합의점 도출이 되지 않고, 각 주장하는 설계 방안에 대한 장단점이 추상화된 사항으로 의사결정이 되지 않았기 때문입니다.

 

장점 : 추상적으로 생각했던 것을 확인하고 최적안을 도출 할 수 있습니다.

단점 : 설계기간이 길어지기 때문에 전체적인 프로젝트 기간이 길어지거나 타이트해집니다..

 

 

 

MSA 프로젝트 중 MVP를 만들었던 이유

• 설계기간을 진행하면서 Event Storming 을 통해 도메인을 나누었습니다.

(Event Storming 이란? https://orange-makiyato.tistory.com/52)

그리고 검토하는 과정에서 여러 도메인 중 두 도메인에 대해 의견이 나뉘게 되었습니다.

 

 

A사 : 도메인은 역할에 따라 명확히 나눠야 한다. DB도 겹치는 데이터 없게 해야한다. 인터널 call 사용하자.

B사 : 두 도메인은 의존성이 강하다. 차라리 합쳐서 하나의 도메인으로 가자. 인터널 call이 매우 많아질 것인데 그에 따른 성능저하없음이 보장되느냐

 

 

이 두 의견이 좁혀지지 않아 결국 MVP를 만들게 되었습니다. 여기서 A 사는 다른 프로젝트에서 MSA 경험이 있지만 현 프로젝트 시스템의 비지니스는 모르는 상태이고 B 사는 MSA 경험은 없지만 해당 시스템의 기존 개발사로서 비지니스를 잘 알고 있는 상태였습니다.

 

 

제가 느끼기에 A사는 이게 MSA임. MSA 이렇게 해야함. 이라고 말하는 것 같았고

B사는 MSA 개념 알겠는데 이 부분은 이렇게 하는게 더 효율적임. 이라고 하는 것 같아서

속으로 B사쪽이 맞는 것 같은데.. 라고 생각했었습니다ㅎ

 

 

그래서 각자 MVP를 만들었고 메인으로 본 것은 성능(응답시간) 이었습니다.

결과적으로 B사의 의견으로 가는 것으로 결정되어서 지금까지 잘 개발하고 있습니다.

 

 

최근에 이런 글을 봤는데요

 - 전 GitHub CTO, "지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환한 것

https://news.hada.io/topic?id=7839 

전 GitHub CTO, "지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환 | GeekNews

댓글 중에 이런 말이 있어서 와닿았습니다.

'어디까지나 상황에 맞게 필요에 의해서 응용 & 적용해야 하는데..'

 

 

MSA 라는 것도 결국엔 시스템을 효율적으로 만들기 위한 하나의 제시인 것인데

무조건적으로 이래야만 MSA다! 라고 하는 것은 좀 억지스럽다는 생각합니다.

시스템마다 특성이나 비지니스가 다 다르고 복잡할테니까요.

유연하게 대처하는 자세가 필요하다고 생각합니다.

 

 

 

 

 

 

이미지 출처

https://m.blog.naver.com/maru7091/220517632062