린 스타업과 MVP. 그리고 Quick And Dirty에 대한 고찰

최근 mvp에 대한 고민이 있었다..

관련 정보를 찾다가 방향은 조금씩 다르지만 각자의 타당성이 있는 좋은 글들을 모아본다. 

 

A type

(중략)

그런데 린 스타트업 책을 읽다보니 내가 얼마나 주먹구구식으로 개발하고 있는지를 느낄 수 있었다. 정말 생각 없이 그냥 내가 필요하다고 생각하는 기능들만 추가하는데 집중했구나. 가치를 주는 기능인지도 모르면서 그냥 열심히 개발하는데만 집중하고 있었다라는 생각이 들었다. 이 책에서 제시하고 있듯이 가설을 세우고, 만들고, 학습을 통해 점진적으로 발전시켜 나가야겠구나라는 생각을 하게 되었다.

이 책을 읽다가 박영록씨가 쓴 Quick And Dirty라는 글을 읽게 되었다. 이 글 또한 그 동안 내가 고민하고 있던 많은 부분에 대한 해결책을 제시해 주는 듯하다. 특히 이 글의 린스타트업과 TDD를 비교하는 부분이 마음에 든다. 그 부분을 인용해 보자.

린 스타트업은 말하자면 TDD를 조금 더 큰 스케일로 하는 것이다. 가설을 수립하고, 가설을 확인할 수 있는 지표를 설정한다. 가설을 검증할 수 있는 MVP를 만든다. quick & dirty! 가설이 검증되었다면 완성도를 높여간다. 가설 검증 결과가 틀린 것으로 나온다면 새로운 가설을 수립한다.

(중략)

   더 상세한 내용(원문) -> http://www.slipp.net/wiki/pages/viewpage.action?pageId=8650756

B type

(중략)

국내에서 안되고 있는 부분은, 오히려 초반에 나온 Build - Measure - Learn 부분입니다. 말씀하신 기술 부채에 관한 이야기도 공감하지만, 이상하게 국내에서 Lean Startup을 본 사람들은 자꾸 MVP 이야기를 한다는 느낌이에요.

한국에서는 MVP는 지나치게 많이 만듭니다. Build는 정말 미친듯이 해요. 그 어떤 회사, 그 어떤 조직을 가도 Build 안하는 조직은 없습니다.

오히려 한국에서 안되고 있는 부분은, Measure / Learn 부분이라고 생각해요. 전체 프로세스를 봐야 하는데, Lean Startup 씩이나 들고 와서 결국은 MVP 이야기 하는거에 질려버렸네요 정말... ㅠ.ㅠ (이전에, 꽤 큰 회사에 아주 높으신 분과 이야기 할 때도, 결국 MVP로 귀결 되는걸 보고 경악했었습니다. 뭐, 그 분은 한국 실정을 거의 모르셨으니 어느정도는 이해 하지만요.)

우린(한국에서 일하는 개발자는) 항상 무언가 만들고 있습니다. 만드는 것 만 놓고 보면 세계 최고일 꺼에요. 말도 안되는 일정에 말도 안되는 분량을 소화하니까요.

근데, 단순히 Technical Debt 수준이 아니라, 지난번 플젝에서 뭘 배웠는지, 이런 부분들은 전혀 측정하고 있지 않아 보여요.

여태 있었던 모든 회사에서 동일하게 발생했던 문제는, 지나치게 성실하게 MVP를 Release 하고 끝. 이라는 프로세스 였습니다.

MVP는, 그 말 그대로 Minimum Viable Product 기 때문에, 이걸 만들어서 출시하고 나서 측정하고 뭘 배웠는지를 다시 판단해서, 다음번 MVP가 됐건, 개선 사항이 됐건에 적용하지 않으면 의미 없어요. 걍 개발자 갈아넣겠다는 거랑 다를바가 없는거죠.

MVP니까 빨리 개발. MVP 니까... 라는 이야기만 벌써 14년째 듣고 있는거 같네요. ;;;

Build - Measure - Learn 전체가 움직이지 않으면 Lean Startup은 아닌 걸로 생각합니다. 그리고 우리나라 회사는, 일단 제가 아는 범위에서는 저 3가지 중에 Build 만 있어요. Measure는 어떻게 해야 하는지 모르고 Learn에는 의지가 없어요.

개인적으로는, 얼마나 많은 사람이 린 스타트업을 읽건, 국내에서는 정상동작하지 않으리라 확신합니다. 그리고 그런 스타트업들에서, 개발자들은 계속 MVP를 Build만 하다 지쳐가겠지요.

(중략)

   더 상세한 내용(원문) -> http://www.slipp.net/questions/98

C type

jaceshim(댓글)

제 생각은 조금 다릅니다.
국내 모든 프로젝트가 MVP라고 보는 시각은 MVP를 개념적으로 받아 들인게 아니라
프로젝트의 프로세스와 결과물만 가지고 판단한게 아닌가 생각됩니다.
MVP는 어떤 서비스 또는 제품에 대한 기획(개발)자의 가설에 대한 검증 prototype입니다.
이 말을 좀 더 구체화 보면
뭔가 서비스or제품을 기획하고 있는데 이게 사용자들로 하여금 어느정도 먹힐지를 테스트하기 위한 용도로 보는게 맞다고 생각합니다.

하지만 앞서 거론하신 부분들을 보면

"개발자를 한계까지 밀어붙여서 개발하니까 MVP(정해진 자원으로 얻어낼 수 있는 최소한을 얻어내죠.)
한계까지 밀어 붙였으니 기능 목록을 줄일 수 밖에 없고, 구현 가능한 기능 목록만 구현하니까 MVP.
사장님이 보기에는 최소기능만 만들어졌으니 MVP.
기획자가 보기에도 더이상 뺄게 없을 수준으로 기능이 줄었으니 MVP."

이런 판단 기준은 MVP를 사전적으로만 대입한게 아닐까요?
MVP는 한정된 자원에 맞춰진 제품을 말하는게 아닌
가설을 검증 할 수 있는 최소한의 기능을 최소한의 자원으로 만들어 낸거로 봐야하지 않을까요?

즉, 국내 모든 프로젝트가 MVP라고 말하는것은
시작부터 MVP를 하는게 아니라
하다보니 MVP가 되어버려서가 아닐까요?

반대로 책에서 말한 MVP는
철처하게 시작부터 고려된것을 말하는거라 생각됩니다.

      더 상세한 내용(원문) -> http://www.slipp.net/questions/98

D type

(중략)

Quick & Dirty How-to

진짜 주제로 넘어가기 전에 잠시, clean code에 도달하는 가장 훌륭한 방법인 TDD의 사이클을 복습해보자.

1. 제대로 동작하는지 확인할 수 있는 테스트를 작성한다.
2. 실행 가능하게 만든다. 다른 무엇보다도 중요한 것은 빨리 초록 막대를 보는 것이다. 빨리 초록 막대를 보는 것은 모든 죄를 사해준다. 하지만 아주 잠시동안만이다.
3. 올바르게 만든다. 이제 시스템이 작동하므로 직전에 저질렀던 죄악을 수습하자.

린 스타트업은 말하자면 TDD를 조금 더 큰 스케일로 하는 것이다.

1. 가설을 수립하고, 가설을 확인할 수 있는 지표를 설정한다.
2. 가설을 검증할 수 있는 MVP를 만든다. quick & dirty!
3. 가설이 검증되었다면 완성도를 높여간다.
4. 가설 검증 결과가 틀린 것으로 나온다면 새로운 가설을 수립한다.

2와 4분의 3 승강장

문제는 바로 2와 4분의 3 승강장 2와 3 사이에 있다. 린 스타트업은 개발자를 위한 책이 아니라 스타트업을 위한 일반적인 방법론이므로, 2와 3 사이에 TDD 사이클의 3번 과정을 따로 시간을 할애해서 적어놓지 않은 것이다. 이게 바로 행간을 읽는다는 것이야. 가설 검증에 성공한 스타트업이 이 2.5 리팩토링을 놓치게 되면 바로 이어 등장하는 추격자들에게 자리를 내주게 된다. 추격자들은 모범 답안이 있으니 빠른 속도로 MVP를 만들 게 아니라, 처음부터 완성품을 보고 달려도 되므로, 완성품에 더 빨리 도달할 수 있다. MVP까지는 quick & dirty로 빠르게 만들 수 있지만, 완성품을 만드는 것은 clean code 없이 속도를 낼 수 없다.

하지만, 설령 개발자가 2와 3 사이에 숨겨진 2.5를 인지한다고 해도 문제는 간단하지 않다. CEO는 quick & dirty로 가설을 검증해냈기 때문에 이미 quick & dirty에 맹신이 생긴 상태이고, 앞으로도 쭉 quick & dirty로 해나가면 된다고 생각한다. 그래서, 계속 같은 속도로 움직일 수 있을 거라고 생각한다. 이런 CEO에게 코드를 정리할 시간이 필요하다고 말하는 것이 먹힐 가능성은 매우 낮다. 설령 말로는 동의해도 이후에 액션들은 2.5 작업을 할 수 있도록 내버려 두지 않는다. proof of concept 이후에도 쭉쭉 뻗어나가는 스타트업과, 경쟁에 뒤쳐지는 스타트업에는 결정적인 차이가 바로 이것이다.

뛰어난 엔지니어가 CEO이거나, 혹은 뛰어난 엔지니어가 어떻게 일하는지를 이해하는 CEO라면 2.5를 이해한다. 하지만 대부분의 CEO는 2.5를 받아들이지 못한다. 고속성장을 하다가 경쟁자에게 따라잡히는 스타트업들은 대체로 CEO가 엔지니어링에 대한 마인드가 부족하다. 국내에도 좋은 사례가 있다. 최근 2~3년 간 스타트업을 가장 떠들썩하게 했던 분야 두 개를 떠올려보라. 그리고, 그 두 개의 선두 업체였던 두 회사의 2년 전과 지금을 비교해보라. 하나는 지속적으로 새로운 성장 동력을 발굴해내며 성장을 가속하고 있지만 다른 하나는 외형적인 성장만 해오다가 그마저도 경쟁사에 따라잡혔다. 물론 차이를 만든 이유는 여러 가지가 있고, 여러가지 분석이 있겠지만, 결정적인 차이는 엔지니어링에 대한 마인드의 차이였다는 것이 내 판단이다.

MVP의 조건

물론 위의 이야기는 어쨋든 다 행복한 스토리다. 내가 창업한 이후 5년 간 직간접으로 관련이 있었던 30여개의 스타트업 중 proof of concept에 성공한 스타트업은 단 둘 뿐이니까 말이다. 그럼 대부분의 스타트업에서는 개발자들이 고민해야 할 clean code는 2.5 단계가 아니라 2단계다. 2단계에선 그럼 무작정 quick & dirty를 하면 되는가? PHP라도 상관 없는가? (그건 물론 안됨) 여기서 quick & dirty를 어떻게 할 것인가를 이야기하기 전에 하나 더 짚고 넘어갈 게 있다. 개발이 아니라 MVP에 대한 조건이다.

MVP는 박병호가 아니고, Minimum Viable Product다. 아니, Minimum Viable Product다. 이게 대부분의 스타트업에서 잘못하는 것 중 하나다. MVP는 충분히 작아야 한다. 이베이의 첫번째 제품은 웹사이트에 중고 물품을 등록하는 기능과 열람하는 기능 두 개 밖에 없었다. 거래는 이메일로 하고 수수료는 우편으로 보내는 원시적인 웹사이트였다. 이런 제품에 버그가 많으면 얼마나 많겠으며 코드가 지저분해봐야 얼마나 지저분하겠는가. MVP가 충분히 작다면 quick & dirty로 매우 빨리 만들어도 그 과정에서 쌓는 기술 부채는 얼마 되지 않는다. 가설 검증이 되면 바로 갚을 수 있다.

하지만 대부분의 스타트업들은 Minimum은 커녕 Maximum을 만들기 위해 노력한다. 뭔가 기능이 없어서 고객이 안 온다고 생각한다. 그래서 점점 비대하게 제품을 확장해나간다. 가설 검증도 안되었는데. 그럼 quick & dirty로 인한 기술 부채는 점점 감당할 수 없을 만큼 쌓여간다. 가설 검증이 된다면 기술 부채는 별 거 아니다. 어차피 돈 벌고 있으니까, 혹은 돈 벌 예정이니까, 뛰어난 개발자 채용하고 시간 들여서 기술 부채를 갚으면 된다. 2.5 단계를 진행하면 되는 거다. 근데, 가설 검증이 안된 상태에서 quick & dirty로 개발한 제품이 점점 커져가면 점점 속도가 느려져서 어느 순간 아무 것도 할 수 없는 상태가 온다. 그리고, 이런 상태가 되면 개발자가 도망가거나, 도망은 안 가도 백기를 들곤 한다. 이렇게 된 스타트업에 헬프하러 간 게 몇 번인지 셀 수 없다.(사실은 셀 수 있다, 여덟 번)

그리고, 설령 어찌어찌 가설 검증이 되더라도, 그 사이 quick & dirty로 만든 제품이 이미 너무 비대하다면, 나중에 뛰어난 개발자를 데려와도 어찌할 수 없는 경우도 생길 수 있다. 2번도 통과했고 2.5번도 할 자세가 충분히 되어 있는데, 2.5를 할 수 없는 상황이 될 수 있는 거다.

그래서, 스타트업은 MVP를 만들 때 극도로 절제해야 한다. 가설-검증의 사이클을 활용하고, 가설의 성공/실패 여부가 가려지지 않았을 때 기능 추가하는 것이 결과적으로 성공 확률을 깎아먹는다는 것을 이해할 필요가 있다. 기술 부채를 통제할 수 있는 선에서 MVP를 만들어야 한다. 기술 부채도 부채이므로 많아지면 파산한다.

(중략)

더 상세한 내용 -> http://youngrok.com/QuickAndDirty