초기 스타트업에서 새로운 언어나 데이터베이스를 먼저 도입하는 현상은 흔히 '도전 정신'으로 미화된다. 그러나 ideolalia.com에 실린 한 엔지니어의 회고 에세이는 이 익숙한 서사를 뒤집는다. 그는 Clojure가 세상에 나온 지 2년밖에 지나지 않은 시점에 그 언어로 처음 돈을 벌었고, 당연하게도 그 일자리는 초기 단계 스타트업이었다. 왜 '당연'한지를 추적하는 과정에서, 그는 우리 산업이 특정 유형의 인간을 체계적으로 길러내도록 설계되어 있다는 결론에 도달한다.
두 번의 실패가 가르쳐 준 것
첫 직장 Runa는 소규모 온라인 소매업체를 위한 동적 가격 책정을 표방했지만, 실제로는 장바구니를 이탈한 고객에게 고정 할인을 제공하는 수준이었다. 일부 고객을 대조군으로 두어 매출 기여분(lift)을 계산하고 수수료를 떼는 구조였는데, 가장 큰 난관은 소매업체에게 가격 통제권을 넘기도록 설득하는 일, 그리고 그 계산의 타당성을 믿게 하는 일이었다. 회사는 '곧 대형 계약이 성사되어 트래픽이 10배로 늘 것'이라는 이야기를 스스로에게 반복했고, '확장 가능하다'는 이유로 HBase를 주력 데이터 저장소로 썼다. 결국 회사를 지탱한 것은 CEO의 인맥으로 따낸 eBay 전용 제품이었고, 그 임원이 Staples로 옮긴 뒤 회사를 통째로 인수했다. Staples에게 필요했던 것은 기술이 아니라 '혁신하는 능력의 증거'였고, 그렇게 꾸려진 팀은 이후 해체됐다.
두 번째 직장 Factual은 웹 크롤링 데이터에 수백 가지 휴리스틱을 적용해 전 세계 장소의 색인을 만든 회사였다. 각 항목은 고유 ID와 이름·주소·영업시간을 갖고, Yelp나 Foursquare 같은 플랫폼의 대응 ID까지 연결해 불완전하거나 일부 틀린 정보로도 해당 개체를 찾아 주는 API를 제공했다. 저자는 이를 '세계를 위한 외래 키'라 불렀다. 문제는 온톨로지에는 돈이 되지 않는다는 점이었다. 이 데이터는 이미 Facebook Places와 애플 지도의 기반이 되었지만, 지리 정보를 다루는 거대 기술 기업의 수는 한정돼 있어 10억 달러 가치로 가는 길이 보이지 않았다.
애드테크로의 하강
Factual은 데이터의 '내재적 가치를 증명하는 것'이라는 명분으로 서비스를 팔기 시작했고, 첫 고객은 모바일 광고의 지역 타기팅을 노린 애드테크 기업들이었다. 저자는 하루 수십억 건의 광고 노출을 처리하는 서비스를 만들면서도 '우리 사업은 데이터지 광고가 아니다'라고 되뇌었다. 그러나 성장은 전부 광고 쪽에서 나왔고 제품 방향은 영업을 돕는 쪽으로 흘렀다. 퇴사 면담에서 CEO조차 '광고는 일시적 우회로이고 곧 데이터로 돌아갈 것'이라 말했지만, Factual은 결국 위치 기반 광고에 더 깊이 빠져들어 Foursquare와 합병했다. 브랜드에서 대행사, 수요측 플랫폼(DSP), 그리고 Factual로 이어지는 사슬에서, 온라인 판매가 아닌 이상 광고 효과를 측정하기란 거의 불가능했다. 그래서 각 단계는 '거래를 성사시킬 수 있는 말'을 서로에게 팔 뿐이었다.
정체된 조직의 '방어적 웅크림'
저자가 끌어낸 통찰은 성장과 기술 역량의 관계에 있다. 벤처 투자를 받은 스타트업의 목표는 오로지 성장이며, 성장은 두 가지 과제를 낳는다. 더 많은 기계와 복잡한 인프라를 요구하는 기술적 과제, 그리고 사용자가 늘수록 개인이 비즈니스 로직 속에서 추상화되어 사업 도메인에 대한 깊은 이해를 요구하는 과제다. 성장이 계속되는 한 엔지니어는 역량을 키워야 하고 또 키울 수 있다. 그러나 대다수 스타트업은 거의 성장하지 못한 채 실패한다. 정체에 직면한 엔지니어링 조직은 회사를 재발명하려 하거나, '반드시 올 성장'을 계속 대비하려 한다. Runa는 후자를 택했다.
유망하지만 잘 이해되지 않은 기술(Clojure, HBase)을 먼저 채택한 것은 훗날의 레버리지를 위한 준비였지만, 정체가 시작되자 그 준비는 상시 대기 상태로 굳어졌다. 초기의 기술적 실수는 그대로 박혀 버렸고, 그것을 되돌려 더 나은 것을 만들려는 시도는 '성장이 왔을 때 허둥대게 만들 위험'으로 치부됐다. 매일이 젠가 게임이었다. 저자가 핵심 시스템 재구축을 밀어붙이자 돌아온 답은 '포기하거나 3주 치 퇴직금을 받고 떠나라'였다. 정작 아무도 건드리지 않은 진짜 문제는 비즈니스 모델 자체가 작동하지 않는다는 사실이었는데, 엔지니어들은 자신을 '모델 성공을 기다리며 준비하는 하류 공정'으로만 여겼다.
면접 질문이 빚어내는 인간상
에세이의 핵심 주장은 채용 방식에 있다. 회사가 실패하는 거의 모든 경우는 '잘못된 것을 만들어서'다. 고객이 엔지니어가 아닌 이상, 이를 해결할 사람은 경쟁 환경을 배우고 고객과 대화하려는 '제품 엔지니어'다. 그러나 표준 면접 질문은 자료구조, 재귀, 계산 복잡도다. 저자는 재귀를 자주 쓴다고 인정하지만, 그것은 여러 데이터 타입을 일반화하려는 추상화의 산물이다. O(log N)과 O(N)의 차이도 특정 도메인에선 사소할 수 있으나 범용 도구를 만들 때만 병적인 경우에 집착하게 된다. 결국 이 질문들은 일반화와 추상화를 즐기는 '기술자'를 선별할 뿐, 제품을 잘 만드는 사람을 가려내지 못한다. 구글에서 프런트엔드 경력자를 낮은 기준으로 뽑아 2류로 취급했다는 일화는 이 편향을 상징한다.
제품 엔지니어를 뽑고 싶어도 산업의 범위가 너무 넓어 동일 제품 영역 경력자만 볼 수도, 지원자의 과거 영역을 평가할 전문성을 갖출 수도 없다. 좋은 설계와 평범한 설계를 가르는 공통 어휘가 없기 때문이다. 그래서 우리는 가로등 밑에서만 열쇠를 찾는다. 열쇠는 어디에나 있을 수 있지만 빛이 비치는 곳은 거기뿐이다. 운이 좋다면 뽑힌 기술자가 인간적이고 쓸모 있는 소프트웨어를 만들 나머지 능력까지 갖추고 있기를 바랄 뿐이다. 한국의 IT 조직에도 시사하는 바가 분명하다. 코딩 테스트와 알고리즘 면접이 측정하는 역량과, 실제로 '무엇을 만들 것인가'를 판단하는 역량은 다르며, 전자에만 최적화된 채용은 비즈니스 모델의 공백을 기술로 메우려는 조직 문화를 되먹임한다. 신기술을 가장 먼저 쓰는 곳이 초기 스타트업인 이유도 결국 여기에 있다. 도입 절차가 없는 조직일수록 좁은 인재 풀에서 사람을 끌어올 수 있고, 그 과정에서 기술자가 아니어도 기술자인 척하는 법을 배우게 되는 것이다.