솔직히 묻겠습니다. 지금 개발하고 있는 그 기능, 우리 회사 손익분기점(BEP) 달성에 1원이라도 기여합니까?
많은 창업자와 개발자 출신 리더들이 빠지는 치명적인 착각이 있습니다. "우리가 핵심 코어 기술을 가지고 있으니, 그 위에 올라가는 서비스 정도는 식은 죽 먹기다."라는 생각입니다. 저 역시 그랬습니다. LG CNS에서 차세대 시스템을 구축할 때나 토스에서 복잡한 결제 연동을 다룰 때, 솔직히 '사용자 화면(Front-end)이나 기획 따위는 껍데기일 뿐'이라고 오만하게 생각했습니다.
하지만 창업 후, 급여 날 통장 잔고가 바닥을 칠 때쯤 뼈저리게 깨달았습니다. 기술적으로 '어려운 일'을 해낸다고 해서 비즈니스적으로 '돈 버는 일'을 하는 건 아니라는 사실을요.
오늘은 2016년 테크크런치에 실린 명문, '스택 오류(The Stack Fallacy)'를 빌려, 왜 기술 중심 회사가 신사업만 벌이면 말아먹는지, 그리고 여기서 살아남으려면 어떻게 사고를 전환해야 하는지 이야기해보려 합니다.
착각의 늪: "그거 그냥 DB에 UI 씌운 거 아니야?"
엔지니어들 사이에서 흔히 들리는 말이 있습니다.
"세일즈포스(Salesforce)? 그거 그냥 오라클 DB에 웹 화면 입혀서 호스팅하는 거잖아. 우리가 만들면 금방 해."
이것이 바로 스택 오류(Stack Fallacy)의 전형입니다. 자신이 다루는 기술 계층(Layer)이 더 어렵고 복잡하다고 믿기 때문에, 그보다 상위 계층인 애플리케이션이나 서비스를 '사소한 것'으로 치부해 버리는 현상입니다.
수학자가 물리학을 "응용 수학"이라 부르고, 물리학자가 화학을 "응용 물리학"이라 무시하는 것과 똑같습니다.
비즈니스 현장에서는 이런 착각이 곧장 폐업으로 이어집니다. 데이터베이스 1위 기업 오라클(Oracle)은 CRM 시장을 장악하기 위해 수억 달러를 쏟아부었지만, 결국 세일즈포스를 이기지 못했습니다. 오라클 눈에는 CRM이 그저 '데이터 테이블과 워크플로우의 집합'으로 보였기 때문입니다. 하지만 고객에게 CRM은 '영업을 성공시키는 도구'였습니다. 관점이 완전히 다릅니다.
VMware와 AWS의 관계도 마찬가지입니다. AWS의 모든 클라우드 인프라는 결국 가상화 기술 위에서 돌아갑니다. 기술적으로는 VMware가 훨씬 원천 기술에 가깝습니다. 하지만 IaaS 시장의 패권은 AWS가 가져갔습니다. 기술적 우위가 상위 시장의 승리를 보장하지 않는다는 잔인한 증거입니다.
왜 상위 레벨로 올라가는 것이 지옥문인가?
개발자 출신 대표님들, 가슴에 손을 얹고 생각해 봅시다.
"이 정도 기술 스택이면 인스타그램 같은 건 한 달이면 만들지."
맞습니다. 기술적으로는 가능합니다. 하지만 '무엇(What)'을 만들어야 하는지 아는 것과 '어떻게(How)' 만드는지는 완전히 다른 차원의 문제입니다.
상위 계층(애플리케이션, 서비스)으로 진출하는 것이 어려운 이유는 기술 난이도 때문이 아닙니다. 고객에 대한 이해도(Customer Obsession)가 없기 때문입니다.
- DB 엔지니어의 고객: 시스템 관리자, 백엔드 개발자 (나와 비슷한 사람들)
- 공급망 관리 소프트웨어의 고객: 물류 창고 관리자, 배송 기사 (내가 전혀 모르는 사람들)
오라클 엔지니어는 쿼리 최적화는 기가 막히게 알지만, 물류 창고 소장이 재고 파악할 때 어떤 버튼이 필요한지는 죽었다 깨나도 모릅니다. 그런데도 "우리가 데이터는 제일 잘 다루니까"라는 기술 부심 하나로 덤벼드니, 시장이 원하지 않는 고성능 쓰레기를 만들게 되는 겁니다.
반면, 하위 계층(아래)으로 내려가는 혁신은 의외로 성공 확률이 높습니다.
애플(Apple)을 보십시오. 그들은 아이폰(상위)을 만들다가 칩셋(하위, M1/M2)을 직접 설계해서 대박을 쳤습니다. 왜일까요? 애플 스스로가 칩셋의 가장 까다로운 '고객'이었기 때문입니다. "우리가 원하는 성능을 내려면 기존 칩으로는 안 돼. 우리가 뭘 원하는지 우리가 제일 잘 알아."
즉, 내가 곧 고객일 때는 성공하고, 내가 고객이 아닐 때는 실패합니다.
생존을 위한 액션 아이템
그렇다면 우리 같은 기술 기반 스타트업은 어떻게 해야 이 '스택의 함정'에서 빠져나와 생존할 수 있을까요? 당장 실천할 수 있는 3가지 원칙을 제안합니다.
1. "그냥(Just)"이라는 단어를 금지어로 지정하십시오.
회의 시간에 기획자나 마케터에게 이런 말을 했다면 반성해야 합니다. "그 기능? 그냥 API 하나 뚫으면 되는 거 아니에요?" "그냥 엑셀 업로드만 되면 되는 거 아닌가요?"
'그냥'이라는 단어가 튀어나오는 순간, 당신은 기술적 구현 난이도로 비즈니스 가치를 재단하고 있는 겁니다. 그 기능이 고객의 매출을 얼마나 올려줄지, 이탈률(Churn rate)을 얼마나 막아줄지 모른다면 입을 다무십시오. 코드를 짜기 전에 고객의 문제를 정의하는 것이 먼저입니다.
2. 기술 부채보다 '고객 이해 부채'를 먼저 갚으십시오.
우리는 레거시 코드나 스파게티 코드를 보면 참지 못하고 리팩토링을 하려 듭니다. 하지만 정작 우리 제품을 쓰는 고객이 하루에 몇 번 로그인하는지, 어떤 화면에서 짜증을 내며 나가는지는 로그조차 심지어 보지 않는 경우가 허다합니다.
이번 스프린트에는 신기술 도입이나 코드 구조 개선 대신, 실제 고객을 만나거나 CS 채널의 불만 사항을 정독하는 시간을 강제로 할당하십시오. 모니터 뒤에 숨어있는 개발자는 결코 PMF(Product-Market Fit)를 찾을 수 없습니다.
3. 해당 도메인 전문가를 '존중'하며 모셔오십시오.
만약 우리가 핀테크 서비스를 만든다면, 금융 공학도나 은행 출신 기획자를 채용해야 합니다. 그리고 그들에게 "개발도 모르는 게 까분다"고 무시할 것이 아니라, "우리가 모르는 고객의 니즈를 알려달라"고 매달려야 합니다.
기술력은 채용하거나 사 올 수 있지만, 시장에 대한 통찰력은 돈으로 쉽게 살 수 없습니다. 구글조차 소셜 네트워크(Google+)를 만들 때 기술력이 부족해서 실패한 게 아닙니다. 소셜이라는 맥락과 사람들의 심리를 이해하지 못했기 때문입니다.
마치며: 기술은 도구일 뿐, 목적은 '생존'입니다
과거 SI 프로젝트를 리딩할 때, 고객의 요구사항이 비합리적이라며 개발팀끼리 뒷담화를 하곤 했습니다. 지금 생각해보면 참 부끄러운 일입니다. 그 비합리적인 요구사항 속에 진짜 비즈니스 기회가 숨어있었으니까요.
여러분이 가진 화려한 기술 스택, 최신 아키텍처, 깨끗한 코드는 자랑스럽습니다. 하지만 그것이 통장에 꽂히는 매출로 연결되지 않는다면, 냉정하게 말해 그것은 취미 생활에 불과합니다.
'어떻게 만들 것인가'의 감옥에서 탈출하여 '무엇을 팔 것인가'를 고민하십시오. 스택 오류를 인정하고 고개를 숙여 고객을 바라볼 때, 비로소 여러분의 기술은 돈이 되는 비즈니스로 변모할 것입니다.
