Page history of 린 스타트업 맹신론 비판

Lean Startup 방법론, 만능인가? (1)에 대한 반박.

여러 가지로 문제가 많은 글이다. 우선, 제목부터가 허수아비 논증이다. 누가 린 스타트업이 만능이라고 했는가? 그렇게 주장한 사람 없다. 한 명이라도 있으면 한 번 데려와봐라. 허수아비 세워놓고 때리는 건 쉬운 일이고, 때리는 사람이 강해보일지 모르지만, 그 타격에는 아무도 쓰러지지 않는다. 이 글 뿐 아니라 이런 류의 글들이 요즘 여기저기서 보이는데, 모두 과거 애자일을 공격했던 논리들과 같은 수준에 머무르고 있다.

이 사람들이 주장 이면에 있는 시나리오는 보통 이런 거다. 어떤 판단을 내려야 할 때, 누군가가 "린 스타트업에서는 이렇게 하는데요"라고 했는데, 그게 맘에 안 드는거다. 그래서, 거기에 맹신이라는 굴레를 씌워버린다. "린 스타트업을 그렇게 맹신하면 안돼", "린 스타트업이 죽으라면 죽을 거니?" 뭐 이런 수준이다.

얼핏 그럴 듯해보이는 논리인데 왜 나쁜 논리일까? 비유를 들어보자. 박사 연구실에서 학생이 연구를 하는데, 변인 통제를 제대로 하지 않고 대조 실험을 했다. 그래서 교수가 "과학적 방법론에 맞게 실험을 해야 결과가 제대로 나오지" 하고 조언했는데, 학생이 "과학적 방법론을 너무 맹신하면 안되요."라고 반박했다고 해보자. 말이 되는가? 교수의 권위가 거슬린다면 교수와 학생을 바꿔놔도 된다. 사실 많은 연구실에서 교수와 학생이 뒤바뀐 이런 현상이 일어나고 있기도 하다. 여기서 과학적 방법론을 맹신하지 말라는 말이 성립한다고 생각하는 사람은 거의 없을 것이다.

과학적 방법론으로 연구한다고 해서 그 학자가 훌륭한 연구성과를 올릴 수 있는 것은 보장되지 않는다. 실제 역사에서도 과학적 방법론이 제대로 정립되기 전에 이미 과학은 발전을 시작했다. 연금술이 의외의 성과를 올리기도 했던 것처럼, 잘못된 방법론으로도 성과를 낼 수 있고, 현대의 수많은 연구실에서 과학적 방법론을 충실히 따르면서 연구를 하고 있지만 성과를 못 내는 연구실이 부지기수다. 그러니까, 과학적 방법론은 연구 성과를 보장해주지 못한다.

이 점은 소프트웨어 개발 방법론과 정확히 일치한다. 소프트웨어 개발 방법론 역시 본질적으로 성과를 보장해줄 수 없다. 린 스타트업을 잘 따라 개발한 스타트업이 망할 수도 있고, 아무렇게나 일한 스타트업이 흥할 수도 있다. 그러니 방법론이 성과를 보장해주지 않는다는 이유로 방법론을 따르지 않아도 된다는 주장이 나오는 것이다. 그렇지만, 같은 논리로 과학적 방법론을 공격할 수 있겠는가?

방법론이라는 게 원래 그런 거다. 더 잘할 수 있는 방법, 그런 것들을 찾아온 노력이 축적된 것이다. "반드시 성공할 수 있는 방법"이어서 따르는 것이 아니라, 그것이 가장 확률이 높기 때문에 따르는 것이다. 그런데 그걸 두고 맹신하지 말라고 하는 것은 지식의 해체를 주장하는 것이나 다름 없다. 우리가 회의를 효율적으로 할 수 있는 것은 팀원들 간에 많은 지식과 컨텍스트를 공유하고 있기 때문이다. 그런데, 회의 때마다 모든 논의를 밑바닥부터 다시 시작해야 한다고 하면 그 논쟁을 감당할 수 있겠는가?

방법론 논쟁에서 가장 나쁜 주장이 맹신하지 말라는 주장이다. 만약 주장의 근거로 방법론을 들이대는 게 맘에 안 든다면, 구체적으로 반박해야 한다. 그 방법론에서 왜 그 부분은 잘못되었고, 왜 우리 상황에는 안 맞고, 더 좋은 대안은 뭐가 있고, 이런 이야기를 해야 한다. 이런 이야기를 해야 방법론 자체도 발전하는 거고, 그 팀도 발전하는 거지, 맹신하지 말라고 공격하는 건 논쟁을 막는 것 밖에 안된다.

인용한 글의 저자는 그나마 구체적인 사례를 들고자 했다. 하지만 불행히도, 그 사례 역시 별로 좋지 않다. 이 사례 역시 애자일 비판에 단골로 등장하던 소재지만, 마찬가지의 오해에 기초하고 있다. 린 스타트업에서 "얼마나 lean 해야 하는가"는 정해져 있지 않다. 의료기기를 만드는 스타트업에는 결함이 있으면 안되니까 린 스타트업을 할 수 없는가? 당연히 아니다. 저자는 미션 크리티컬한 분야에선 MVP의 M이 성립할 수 없다고까지 주장한다. 이는 사실 M보다도 V에 대한 오해에 있다. MVP는 분야에 따라 매우 다양한 레벨로 존재한다.

예를 들어, 쇼핑몰을 만들고 싶다고 해보자. 그런데, 무슨 상품을 팔아야할지 아직 못 정했다. 이런 상황에서 린 스타트업을 하는 사람들이 보여준 최고의 MVP는 팔 상품의 후보만 전시된 1페이지짜리 홈페이지다. 아무 기능도 없다. 그리고 여러 가지 키워드로 광고를 해서 방문한 사람들이 어떤 상품 링크를 많이 클릭하는지 트래킹한다. 그래서 그 결과를 보고 구체적으로 무슨 쇼핑몰을 만들지를 결정한다. 아주 극단적인 사례다. 의료기기를 만드는데 이런 수준의 MVP를 내는 것이 린 스타트업인가? 당연히 아니다.

Minimum Viable Product에서 viable은 독자적으로 생존할 수 있는 상황을 말한다. 의료기기가 만약 버그가 많다면 그 상품을 의사들에게 일단 팔아볼 수 있는가? 아니다. viable이 안된 거다. 당연히 이 분야의 MVP는 요기요나 배달의 민족보다 높은 품질을 요한다. 그렇다고 해서 의료기기는 린 스타트업이 아니어도 되는가? 그렇지 않다. 

예를 들어 소변 샘플을 분석해서 당뇨, 임신여부 등 여러 가지 정보를 주는 의료기기를 만든다고 해보자. 현재 이 회사에서 보유한 소변 분석기술로는 10가지를 측정할 수 있다. 그렇다면 이 10가지를 다 담도록 만들고, 스마트폰 연동도 추가하고, 디자인도 예쁘게 만들어서 출시를 할 수도 있다. 반면, 두세 가지만 제대로 측정되게 만들고, 결과도 액정에 대충 표시하고, 디자인도 투박하게 대충 만들고, 판로도 한두 곳만 뚫어서 출시할 수도 있다. 하지만 핵심 기능은 정확하게 동작하게 만든다. 이러면 후자는 린 스타트업이라고 부를 수 있다. 후자는 아마도 전자보다 훨씬 빨리 제품을 시장에 내놓을 것이고, 전자가 제품을 시장에 내놓을 때쯤이면 이미 사용자들이 정말 원하는 기능만 전자보다 더 높은 완성도로 탑재해서 이미 제품을 팔고 있을 것이다.

이런 포인트에 대해 eXtreme Programming explained 2판에서 단순성에 대해 이야기하면서 설명한 바 있다. XP에서는 단순성을 지향하는데, 그게 무조건 단순하자는 이야기가 아니다. 필요를 충분히 충족할 수 있는 한계 내에서 최대한 단순하게 하자는 것이 XP가 지향하는 단순성이다. 예를 들어 컴파일러를 만드는데 단순하게 만들고자 정규식만으로 문법을 파싱하려 한다면 잘못된 것이다. recursive decent parser는 매우 복잡하고 어려운 기술이지만, 이 경우에는 가장 단순한 선택이 될 수 있는 것이다.

린도, 애자일도 마찬가지다. 얼마나 린해야 하는가, 얼마나 애자일해야 하는가에 대해서는 분야마다, 컨텍스트마다 다르다. 중요한 것은 일이 되게 만드는 범위 내에서 다른 대안보다 더 린하게 가자는 것이다. 그런 면에서 의료기기든 금융이든 린 스타트업이 가능하다.

마지막으로, 린 스타트업의 린(lean)은 본래 도요타의 린 생산에서 나온 것이다. 원 저자에서는 고수준의 의료기기도 아니고 헬스케어 정도를 예로 들고 있는데, 자동차 산업은 보통의 헬스케어보다는 훨씬 높은 품질을 필요로 하는 분야다. 그런 분야에서 나온 린인데, 그보다 덜 미션 크리티컬한 분야에서 린을 쓸 수 없다는 주장을 하는 건 좀 곤란하지 않은가? 도요타는 린 생산을 신차 개발에도 적용하면서 신차 개발 주기를 5~7년에서 2~4년으로 단축시켰다. 스케일이 다를 뿐이다. 미션 크리티컬한 분야가 아닌 소프트웨어라고 해서 린 스타트업으로 개발할 때 출시 일정이 다 똑같이 잡힌다고 생각하는가? 2개월 만에 출시되는 제품도 있겠지만, 6개월 걸리는 제품도 있다. 분야마다 viable을 달성하는 시간이 다를 뿐이다.

세 줄 요약

1. 린 스타트업이 만능이라고 주장한 사람은 없다.
2. 방법론은 원래 만능이 아니므로, 만능이 아니라는 것은 방법론을 따르지 말아야 할 이유가 되지 못한다.
3. 미션 크리티컬한 분야에도 MVP는 가능하며, viable을 달성하는 minimum은 분야마다 다를 수 있다.