왜 똑같이 따라 했는데 우리만 실패하는가
브라이언의 이어지는 이야기 : 태호의 Insight #20
스타트업 씬에 있다 보면 “Do things that don’t scale”, “심리적 안전감이 성과의 핵심이다”, “OKR을 도입하면 된다”, “Airbnb도 이제 실험 안 한다더라” 같은 문장들을 많이 듣게 됩니다. 어떤 말은 카피처럼 멋있고, 어떤 말은 당장 우리 조직에도 적용해야 할 것처럼 들립니다.
문제는 이런 말들이 종종 맥락과 전제를 떼어낸 채 인용된다는 데 있습니다. 누군가에게는 특정 시점의, 특정 회사의, 특정 문제를 해결하기 위해 등장한 문장인데 우리는 그 배경을 잘 모른 채 “성공한 회사가 했다니까 우리도 해보자”는 식으로 가져오곤 합니다.
하지만 방법론이나 기술을 택할 때는 맹목적 믿음이 아니라 그것이 왜 등장하게 되었는지 그리고 혹시 특정 생존편향 하에서만 동작하는 것은 아닌지를 먼저 살펴보아야 합니다.
Google
구글은 ‘아리스토텔레스’ 프로젝트를 통해 사내에서 고성과를 올리는 팀의 5가지 비밀을 밝혀내고 그 중 무엇보다 중요한 것이 ‘심리적 안전감(Psychological Safety)’ 라 하였습니다. 팀원들이 위험을 감수하고 다른 팀원들 앞에서 자신의 취약함을 드러내는 것에 대해 안전함을 느끼는 것이 중요하다는 것이죠. 그래서 국내 스타트업들도 HR 분들의 주도로 이런 배움을 적용하려는 시도가 있었습니다.
그러나 2010년 초반의 구글은 전 세계에서 가장 뛰어난 인재들이 몰려 있었고 채용/평가 기준도 매우 높았습니다. 자연스럽게 동료 간 경쟁 압박(peer pressure)이 강하게 형성될 수밖에 없는 환경이었습니다. 상위 인재들이 경쟁하는 상황에서는 ‘심리적 안전감’ 확보가 고성과를 올리는 하나의 큰 퍼즐 조각이었던 거죠. 하지만 그렇지 않은 환경에서 심리적 안전감 만을 확보하려는 노력은 더 큰 부작용들을 불러오곤 했습니다.
YCombinator
YCombinator는 “Make something people want” 라는 만트라를 강조하기로 유명합니다. 하지만 이는 이미 투자 심사 과정에서 팀의 제품 빌딩 역량을 확인할 수 있기에 할 수 있는 말입니다. 무언가를 만들 능력이 없는 팀에게 사람들이 원하는 것을 만들라고 할 수는 없겠죠.
“Do things that don’t scale” 라고 강조할 수 있는 이유도 역설적으로 확장이 가능한 시장임을 확인하고 투자를 했기 때문에 할 수 있는 말입니다. 즉, YCombinator 심사 중 이미 검토되어 생존한 팀에게 하는 조언에 가깝습니다. 무엇을 어떻게 해도 열 배, 백 배로 성장할 수 없는 시장과 아이템이라면 시드 투자를 유치하는 것은 어렵습니다.
OKR
OKR 이전에 KPI가 있었고 KPI 이전에 MBO가 있었습니다. 모두 좋은 툴입니다. 다만 KPI가 수치 달성 여부 위주 시스템이었기에 기존 업계와는 달리 10x 성과 달성이 가능했던 테크 업계에서는 이를 수용할 수 있는 툴이 필요했습니다. 그래서 도입되고 효과를 본 것이 OKR 입니다.
소프트웨어 기반 테크 업계에서는 기능 개선 하나가 곧바로 전 세계 수백만 유저에게 배포되고, 고정비가 거의 늘지 않은 상태에서 매출이 기하급수적으로 증가할 수 있습니다. 이런 “규모의 경제 + 네트워크 효과”가 있는 환경에서는 10x 성과를 노리는 것이 현실적인 전략이고, 이를 목표로 삼는 OKR이 잘 맞아떨어질 수 있습니다.
그래서 10x 성과 처럼 크게 노리고 크게 달성하는 것이 가능한 소프트웨어 기반 테크 업계에서는 좋은 툴이지만 그렇지 못한 곳에서는 효용이 크지 않을 수 있습니다. 실제로 국내에서 널리 알려진 성공 사례는 대부분 소프트웨어/테크 업계에 집중되어 있습니다.
Airbnb
Airbnb의 창업자 Brian Chesky는 작년부터 Founder Mode라며 기존 스타트업 경영 관례에 대한 반론을 제시해왔습니다. 그 중에서 저는 “버튼색이나 문구 하나 바꾸고 A/B 테스트 실험하지 마라. 가설 기반으로 꼭 필요한 실험만 하고 나머지는 디자인과 고객에 대한 감각으로 책임있게 결정해야 한다.”는 것이 기억에 남습니다.
이것을 인용하여 실험을 하지 않아도 된다는 분들도 계셨기 때문입니다. 재미있는 점은 Airbnb는 실리콘밸리 내에서도 가장 A/B 테스트를 많이 하고 잘하는 조직으로 손꼽혀왔다는 것입니다. 이렇게 A/B 테스트를 끝까지 밀어붙여 본 조직이 정반합의 과정을 거쳐가는 것과, 실험을 제대로 해본 경험없이 “Airbnb도 실험 줄였다더라”를 근거로 삼아 A/B 테스트를 회피하는 것은 결이 좀 다릅니다.
자 이제 우리가 무지성으로 하거나 듣던 말들 - “Do things that don’t scale”, “심리적 안전감이 가장 중요합니다”, “OKR 도입하면 해결됩니다”, “Airbnb도 이제 실험 안합니다” 에 대한 판단과 접근을 다시 해봅시다.
지금 누군가에게 애증의 대상일 애자일도 그전 워터폴의 고통에서 벗어나기 위해 나왔고 자바 스프링도 J2EE와 비교하면 선녀입니다. 그렇다면 맹목적인 애자일 도입/증오, 자바 사랑/혐오를 넘어 우리가 처한 상황과 그들이 풀려고 했던 문제 상황이 얼마나 맞아 떨어지는지 파악하면 더 적절한 선택을 할 수 있습니다.
시간의 흐름상 우리는 현재 어떤 성장통의 고비에 있고 그래서 어떻게 이 고비를 넘으면 성공적으로 다음 고비를 만날 수 있을지를 고민함이 좋습니다. 하나의 방법론 도입, 기술 도입이 어떤 문제를 100% 또는 영원히 해결해 줄 일은 없기 때문입니다.
감사합니다.


자신들이 못할 것 같으니까 다름 사례에서 유리한 것만 과거 컨텍스트 없이 차용하려는 태도가 글처럼 많은 것 같습니다. 많이 공감되네요!