스타트업 씬에 있다 보면 “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% 또는 영원히 해결해 줄 일은 없기 때문입니다.

감사합니다.