3개월간의 수습기간. 그리고 MVP와 MVF

오늘부로 이직한 새 직장에서의 수습기간이 끝났다. 짧다면 짧고, 길다면 긴 시간이다. 이직할 때마다 항상 이 수습기간을 거쳤는데, 이때마다 이 3개월간의 수습기간은 일종의 회사와 나의 느슨한 결합상태상태라고 생각이 든다. 이걸 흔히 JD에서 볼 수 있는 문장으로 표현하면

 

서로의 Fit을 맞춰본다

 

고 할 수 있을 것 같다. 아무튼 결과론적으로 현재 회사와 나의 Fit은 잘 맞는다. 그리고 굉장히 파편화돼있는 경력때문에 이번에는 꽤 오래 한 직장에 다녀야 할 것 같기도 해서 여러모로 다행이라는 생각이 드는 요즘이다. 그만큼 만족스러운 직장이라는 의미다.

 

 

 

사실 위에것은 사족이고 이제 일과 관련해서 이제 얘기를 해보자면, 나는 이 회사의 신사업팀에 투입이 됐고 굉장히 빠른 주기로 개발과 배포를 하고 있다. 자동화된 CI/CD 파이프라인 위에서 TDD로 기본적인 동작 신뢰성을 보장하는 상태에서 팀원들 각자가 feature개발과 배포까지 진행할 수 있는 권한이 있고 오류가 나면 고치고 나서 공유하면 된다. 그래서 많으면 하루에 feature를 두 개를 따서 배포하기도 한다. 오늘도 이슈가 하나 발견돼서 제보된지 30분만에 fix를 해서 상용환경까지 배포하기도 했고 말이다.

 그리고 일단위 스크럼과 코드리뷰를 통해서 서로의 개발 방향을 공유하고 서로 모르는 부분이 있으면 상호보완을 하고, 서로 작업하는 코드를 보면서 누가 어떤 부분을 맡고 있는지 모든 팀원들이 정확하게 파악을 하고 있는데 그부분을 참고할 일이 있으면 바로 팀원에게 물어보고 피드백을 받을 수도 있다. 이러한 것들이 빠른 기능개발과 배포를 가능케 했다.

 

 

TDD와 엮여있는 CI/CD 파이프라인과 일단위 스크럼/코드리뷰를 통해 하루 혹은 며칠 단위의 feature 개발 및 배포를 수습기간 내내 겪으면서 든 생각이 있었다. 바로 우리가 하는 이 방식이 MVP를 개발하는 스타트업과 크게 다를 바가 없다는 것이다. MVP란 무엇이냐, Minimum Viable Product의 약자로서 최소기능제품이라고 직역할 수 있을 것이다. MVP가 나온 컨셉은 어떠한 마케팅 아이디어나 BM을 최대한 빨리 시장에 출시해서 그 반응을 보고자 하는 니즈에서 시작되었다.

 

 

 

하지만 나와 우리 팀이 만드는 것은 Product단위가 아니다. Feature단위이다. 혹은 Function(기능)이라고도 할 수 있겠다. 그래서 새로운 개발 방법론인 MVF(Minimum Viable Feature | Function)를 제시하고 싶다. 말 그대로 Product를 Feature로 바꾸는 것이다.

 

MVP가 시장의 반응을 보기 위해 만들듯이 MVF는 이미 확보된 사용자들의 반응을 확인하기 위해 적용한다. 어떤 의미에서 보면 PoC (Proof of Concept)와 비슷한 맥락이라고도 생각할 수 있지만 PoC는 새로운 프로젝트가 실제로 실현 가능성이 있는가, 효과와 효용, 기술적인 관점에서부터 검증을 하는 과정이기 때문에 약간 다르다. MVF는 검증을 실제 사용자로 하는 것이기 때문이다.

 

 

 

어떤 가설에 대한 최소기능(Minimum Viable Feature)을 만들고, 반응이 좋으면 개선하고, 반응이 나쁘면 왜 나쁜지 분석해서 해결할 수 있는 문제이면 개선하고 안될 것 같으면 과감하게 폐기한다. 이것이 MVF의 골자이다. 좀 있어보이는 말로 애자일하게, 린하게 움직여야 하는 스타트업들에게는 좋은 컨셉이라고 생각한다. 실제로도 내가 이런 환경에서 일을 하고 있기도 하고 말이다.

 많은 직장을 겪어보진 않았지만 그럼에도 불구하고 지금 이 체제만큼의 생산성을 보여주는 곳은 없었다. 앞으로도 없을 것이라고 생각한다. 그것을 가능케 하는 것이 MVF방법론이기 때문에 이렇게 글을 써서 알리고 싶었다. 실제로 이러한 문화와 환경에서 업무 경험을 하고 있는 요즘이 나에게 엄청난 도움이 되고 있기 때문이다. 아주 만족스럽다.