RethinkDB: 우리가 실패한 이유

우리가 RethinkDB의 종료를 발표했을 때, 나는 포스트모템을 쓸 것이라 약속했습니다. 그동안의 경험을 정리하느라 시간이 걸렸고, 이제 명확하게 쓸 수 있게 되었습니다.

이해할 수 없는 왜곡과 MongoDB 마케팅 직원들의 모략에서부터 시장 출시를 위한 경험 있는 팀의 구성 실패와 수를 다루는 타입이 64-bit float밖에 없다는 것까지 해커뉴스의 스레드에서 RethinkDB가 실패한 원인에 대하여 많은 의견이 나왔습니다. 나는 그 의견들을 여기에 정리해 놓았습니다.

이들 중 일부는 사실처럼 보이기도 하지만, 돈을 벌지 못해 실패했다고 말하는 것처럼 대부분 이유보다는 증상을 말하고 있습니다. 이런 것들은 우리가 실패한 원인을 밝히지 못합니다.

다시 되돌아보면 두 가지가 잘못되었습니다. 우리는 가혹한 시장을 선택했고, 잘못된 기준으로 제품을 최적화했습니다. 각각의 실수가 RethinkDB의 가치를 절반씩 떨어트렸습니다. 두 개 중 하나라도 제대로 했다면 우리는 MongoDB 만큼 되었어야 하고, 둘 다 제대로 했다면 언젠가 Red Hat이 되었을지도 모릅니다.¹

가혹한 시장

우리는 이렇게 생각했습니다. 새롭게 세워진 회사들이 Oracle 기반으로 만들지는 않을 것이고, 여기에 새 인프라스트럭처 회사를 만들 기회의 창이 있다고 우리는 생각했습니다. 데이터베이스 시장은 매우 거대합니다. 우리가 그 시장의 일부분을 가질 수 있다면 이후에는 매우 성공적인 회사로 만들 수 있을 것입니다.

불행하게도, 여러분은 여러분이 생각하는 시장에 있으면 안 됩니다. 여러분의 사용자가 여러분이 있다고 생각하는 시장에 있어야 합니다. 사용자들은 우리를 오픈소스 개발툴 회사로 생각했습니다. 실제로 그랬기 때문이죠. 이것이 결국 불행하게 만들었습니다. 오픈소스 개발툴 시장은 최악의 시장 중 하나입니다. 수천명이 RethinkDB를 사용하고 대체로 상업적으로 사용하면서도, 그들 대부분은 스타벅스 커피 한 잔 값보다 적은 돈을 내려했습니다. (한 푼도 내려 하지 않은 것은 아닙니다.)

제품이 너무 좋아 기술 지원을 위해 돈을 낼 필요가 없거나, 개발자가 예산을 집행하지 못한 것이 아닙니다. 답은 간단한 미시경제학에 있습니다. 개발자들은 개발툴 만들기를 좋아합니다. 수익이 없이도 말이죠. 그래서 엄청난 수요가 있음에도 공급이 그것을 크게 넘어서고 있습니다. 대체가능한 제품이 많아지고, 가격은 무료에 가까워집니다.

이것이 어떻게 다른 회사에 작용하는지 MongoDB(대략 ~700명의 직원과 16억 달러의 가치)와 Docker(대략 ~300명의 직원과 10억 달러의 가치)를 보죠. 두 회사는 각자의 시장을 완전히 지배하고 있습니다. 경험적으로, 성장단계에 있는 비상장 기술회사들은 연 매출 10배의 가치를 가지면서, 직원당 연 매출이 대략 20만 달러 정도가 됩니다. 이것은 MongoDB의 연 매출은 약 1억 4천만에서 1억 6천만 달러이고, Docker의 연 매출은 약 6천만에서 1억 달러 정도 된다는 의미입니다.

꽤 좋아 보입니다. 개발툴 회사가 아닌 시장을 지배하는 B2B 기술회사로 볼 때까지는 말이죠. SalesForce, Palantir, Box 같은 회사를 떠올려 봅시다. 갑자기 MongoDB와 Docker의 모든 것이 작아 보이기 시작합니다.

저 회사들은 매우 성공한 회사들입니다. 기존의 파트너십, 유통 인프라, 대량의 장부(accounts)에 대한 접근을 가지고 있는 이런 회사들이 성장에 어려움을 겪는다면, 이제 시작하는 스타트업에게 이것이 무엇을 의미할까요?

우리에게는 고객 획득의 어려움을 의미합니다. 좋은 B2B 시장에서 스타트업이 제품 하나를 팔기 위한 10번의 기회를 얻기 위해 100명의 사람을 만나야 한다면, 개발툴 스타트업은 이 수치가 10배로 올라갑니다. 많은 사람들이 여러분의 제품을 다운로드하고 응원하지만, 제품 하나를 파는데 어처구니없는 수의 기대 고객을 찾아야 합니다.

이것이 심각한 도미노 효과를 만듭니다. 팀의 사기를 꺾고, 투자를 유치하거나 좋은 인재의 영입을 어렵게 합니다. 그리고 여러분의 자원을 제약하고 제품과 유통에 충분한 투자를 하지 못하도록 합니다. 스타트업은 모멘텀에 살고 죽습니다. 거의 항상, 초기의 유통 문제는 스타트업을 결국 죽게 만듭니다.

잘못된 기준

예, 시장이 좋지 않습니다. 그런데 다른 개발툴 회사는 제품을 잘 팔고 있습니다. 왜 RethinkDB는 안 될까요?

우리가 이 시장을 어떻게 해볼 수는 없었지만, 제품에 대한 결정은 완전히 우리가 할 수 있었습니다. 우리는 세련되고, 튼튼하면서, 아름다운 제품을 만들고 싶었습니다. 그래서 다음의 기준으로 제품을 최적화하였습니다.

• 정확성. 우리는 매우 엄격하게 정확성을 보장하며 실행되도록 했습니다.
• 인터페이스의 단순함. 우리가 구현의 복잡성을 모두 감수하여 개발자들에게 단순해지도록 했습니다.
• 일관성. 우리는 쿼리 언어에서부터, 클라이언트 드라이버, 클러스터 설정, 문서화, 홈페이지의 마케팅 문구까지 모든 것을 가능한 일관되게 만들었습니다.

익숙한 이것들은 worse is better 에세이에 나온 것입니다. 여기서는 정확성과 인터페이스의 단순함, 일관성은 대부분의 사용자에게 잘못된 기준이라고 결론 내렸습니다. 대부분의 사용자가 원하는 것들은:

• 적시에 출시. 사람들은 그들이 필요한 제품이 3년 뒤가 아니라, 지금 있기를 바랍니다.
• 체감할 수 있는 속도. 사람들은 RethinkDB가 우리가 제시하는 “실제” 부하보다 그들이 시험하는 부하에서 빠르기를 바랍니다. 예를 들어, 사람들은 전혀 읽지 않고 만 개의 문서를 삽입만 하는데 걸리는 시간을 측정하는 스크립트를 작성합니다. 우리가 시장을 가르치느라 싸우는 동안, MongoDB는 이런 종류의 부하를 잘 해결했습니다.
• 유스 케이스. 우리는 좋은 데이터베이스 시스템을 만들기 위해 시작했습니다. 하지만 사람들은 X를 하기위한 좋은 방법(예를 들어, hapi로부터 JSON 문서를 저장하는 방법, 로그를 저장하고 분석하는 방법, 리포트를 생성하는 방법 등)을 원했습니다.

우리가 RethinkDB를 빠르게 만들거나, 빨리 출시하려 하지 않은 것은 아닙니다. 우리도 그렇게 했습니다. 하지만 정확하고, 단순하며, 일관된 소프트웨어를 만드는 것은 아주 많은 시간이 걸립니다. 그것이 우리를 시장에서 3년 뒤지게 했습니다.

우리가 RethinkDB의 설계 목표에 도달했다고 느끼고 사람들에게 실제 제품에서 사용해보도록 추천할 수 있게 되었을 때, 대부분의 사람들은 “RethinkDB가 MongoDB와 다른 게 뭐야?”라고 물었습니다. 우리는 정확성, 단순함, 일관성의 중요함에 대해 열심히 설명했지만, 대부분의 사용자들이 중요하게 여기는 기준이 아니었습니다.

솔직히 말해, 상처를 받았습니다. 많은 상처를 받았습니다. 왜 사람들이 겨우 예상된 일(데이터를 저장)을 하고, Big Kernel Lock(BKL)을 걸고, 알 수 없는 에러를 내고, 샤딩을 할 때 노드가 멈추고, 제일 중요한 기능 중 하나이지만 겨우 작동하는 샤딩 시스템을 가지며, 기본적인 정확성 보장이 없고, 일관성 없이 뒤범벅인 인터페이스를 노출하는 제품을 선택하는지 우리는 이해할 수 없었습니다.

MongoDB가 매번 향상된 새 버전을 출시하고 사람들이 거기에 환호할 때, 나는 분개한 기분을 느꼈습니다. 그들은 BKL을 수정했다고 발표했지만, 사실은 granularity 레벨을 데이터베이스에서 컬렉션으로 낮춘 것이었습니다. 더 많은 동작을 추가했다고 발표했지만, 시스템의 기존 인터페이스를 잘 조합한 것이 아니라, 단순히 하나의 명령어를 새로 만든 것이었습니다. 샤딩을 향상했다고 발표했지만, 그들은 근본적인 데이터 일관성을 보장하게 만들려는 의지가 없거나, 능력이 없었습니다.

하지만 시간이 흐르면서 나는 대중들의 현명함을 인식하게 되었습니다. MongoDB는 사람들이 MongoDB를 필요로 할 때에는 보통 개발자를 영웅으로 바꿔놓았습니다. 몇 년 뒤가 아니라 바로 그 순간 말이죠. 그들은 데이터 스토리지를 빠르게 만들었고, 사람들이 제품을 빨리 출시할 수 있게 만들었습니다. 시간이 지나면서 MongoDB는 성장했습니다. 그들은 문제를 구조적으로 하나씩 하나씩 고쳐내며, 이제는 훌륭한 제품이 되었습니다. 우리가 만들고 싶었던 것 만큼 아름답지 못했더라도, MongoDB는 자기 일을 잘 해냈습니다.

2014년 중반이 되었을 때, 우리는 더 이상 경쟁할 수 없었습니다. MongoDB와 차별화 하기 위해 열심히 일했습니다. 우리는 실시간 푸시를 추가할 수 있는 아주 세련된 방법을 찾았고, 개발자들이 이전에는 만들 수 없었던 종류의 앱을 만들 수 있기를 바랬습니다. 하지만 그것도 충분하지 못했습니다. 우리가 이제 Meteor와 Firebase와도 경쟁하고 있다는 것을 알게된 것이죠. 두 회사는 우리가 그것을 생각지도 못했을 때부터 몇 년 동안 바로 그 실시간 문제를 해결하기 위해 매진해왔습니다. 다시 우리는 시장에서 3년 뒤처졌습니다. 또 한 번 우리는 경쟁할 수 없다고 판단했습니다.

클라우드는 어떨까요?

몇몇 사람들은 우리가 클라우드 서비스를 해야 한다고 제안했습니다. 우리는 이미 작동 중인 것이 있었기 때문에 흥미로운 것이었죠.

클라우드 서비스를 만드는 작은 데이터베이스 회사가 가지는 명확한 문제는 집중을 분산하게 되면서 실패하는 스타트업의 공통된 모습과 일치한다는 것입니다. 안정된 클라우드 서비스를 만들고 출시하고 운영하는 것은 어렵습니다. 뛰어난 전문지식과 자원이 필요합니다. 여러분이 이 길로 간다면, 한 번에 스타트업 두 개를 운영하는 것과 비슷할 것입니다. 우리는 현실적인 문제에 직면해 있었지만, 자금도 빠르게 떨어져 가고 있었습니다. 그래서 그냥 포기해 버렸죠. 하지만 우리가 클라우드 서비스를 할 수 있었다고 가정해 봅시다.

우리의 논리는 이랬습니다. 데이터베이스 클라우드는 다음 세 가지 중 하나를 제공한다: 관리형 호스팅, 서비스로서의 데이터베이스(DBaaS), 서비스로서의 가치 있는 플랫폼(PaaS). 위에서 사용했던 경험적인 계산으로 시장을 간략히 분석해 봅시다.

이 시장은 작습니다. 데이터베이스 시장 자체보다도 더 작습니다. 우리도 저기에 들어가는 것이 더 나은 것일까요?

관리형 호스팅은 AWS를 사용 중인 사람들이 기본적으로 사용할 수 있기 때문에, 사람들이 다른 걸 쓸 필요가 없습니다. 이런 서비스를 사용하지 않는 대안으로 AWS에 직접 데이터베이스를 설치하는 방법도 있습니다. 귀찮기는 하지만, 실제로는 그리 어렵지가 않습니다. 이렇다 보니 관리형 데이터베이스 호스팅 서비스에 얼마나 많은 돈을 낼 수 있는지에는 한계가 있습니다. RethinkDB보다 2배 이상 더 많은 사용자를 가진 MongoDB를 호스팅하는 Compose.io와 mLab를 고려했을 때, 우리는 관리형 호스팅을 제공하는 것이 영향을 줄 수 없다고 결론내렸습니다.

서비스형 데이터베이스(DBaaS)는 관리형 호스팅보다 더 복잡한 버전입니다. 사용자로부터 노드 관리를 완전히 추상화해야 합니다. 여러분은 단순히 쿼리만 하고 시스템이 그것을 알아서 처리합니다. 거기에 얼마나 많은 노드가 실행 중인지 아무것도 알 필요가 없는 것이죠. 또한 이 사업은 도전적입니다. DBaaS 회사는 DynamoDB와 DocumentDB같은 대형 제품과 경쟁해야 하기 때문입니다. 너무나도 많은 대안과 대체품이 있는데도 스타트업에게 모든 데이터 관리를 맡겨야하는 고객들의 큰 거부감도 있습니다. (스타트업의 DBaaS를 사용하는 사람을 알고 있나요?) 그래서 DBaaS도 탈락했습니다.

마지막 옵션은 서비스형 플랫폼(PaaS)을 만드는 것입니다. 우리는 큰 기술적 우위가 있었기 때문에 이것이 가능성 있는 길이라고 생각했습니다. Firebase와 Meteor는 MongoDB를 기반으로 애플리케이션 레벨의 실시간 로직을 만든 것입니다. 이것은 규모가 커질수록 실시간 쿼리 능력과 성능에 본질적인 한계를 가집니다. 반대로 우리는 모든 스택을 컨트롤하고 있었기 때문에 Firebase와 Meteor가 만들 수 없을 큰 장점을 제공할 수 있을 것입니다.

그래서 우리는 Horizon을 만들었고, 사용자가 RethinkDB와 Horizon 앱을 배포하고 확장할 수 있는 Horizon Cloud의 작업을 시작했습니다. 아주 작은 팀으로 세 개의 큰 프로젝트(RethinkDB, Horizon, Horizon Cloud)를 만드는 것은 도전이었고, 결국 우리에게 나쁜 결과를 가져왔습니다. 자금이 바닥나기 전에 클라우드를 출시할 수 없었던 것이죠. 그렇지만 엔지니어링팀에게는 찬사를 보냅니다. 그들은 거의, 거의 끝까지 완성했습니다.

근원적 질문

우리가 할 수 있는 근본적인 원인의 분석에는 여러 단계가 있습니다. 우리는 왜 나쁜 시장과 잘못된 기준으로 제품을 최적화했을까요?

어렸을 때 저는 라디오를 직접 만들고 싶었습니다. 합판으로 박스를 만들고, 안쪽을 금속 폐물로 메꾼 후 전원선을 연결했습니다. 집에 전자공학책이 있었지만, 그런 것들이 필요하다고 생각하지 않았습니다. 혼자서 할 수 있다는 확고한 믿음이 있었던 것이죠. 결국 저는 작동하는 수신기를 만들 수 있었지만, 기본적인 전자공학을 배울 필요가 있다는 것을 깨닫는 데 몇 년이 걸려버렸습니다.

초기의 RethinkDB도 매우 비슷합니다. 우리는 제품이나 시장에 대한 통찰이 없었고, 그래서 우리가 하는 것에 대한 이해 없이 회사를 만들어왔습니다. 더해서 무모하게 낙천적이었습니다. 경제학의 법칙이나 사업에 필요한 계산(math)들은 우리에게 영향을 주지 않는다고 믿었습니다. 결국 그 계산에 우리는 발목을 잡혔습니다.

이 실수들을 피할 수 있었을까요? 어릴 때의 제가 작동하는 라디오를 만들 수 있었던 것 이상은 없습니다. 우리는 능력이 없었고 그것을 알아채는데 몇 년이 걸렸습니다.

어떤 사람들은 우리에게 시장 출시를 위한 경험있는 팀이 있었다면 더 나았을 것이라고 합니다. 100% 사실입니다. 하지만 우리 개개인들의 성장이 회사의 필요성에 발 맞추지 못했습니다. 초기에 우리는 시장 출시를 위한 전문가가 필요하다고 알지 못했기 때문에 설립할 때에도 그들을 구하지 않았습니다.² 우리에게 현실 감각이 생길 동안, 우리는 돈이 적고, 능력있는 경쟁자들이 가득한 어려운 시장에 있으며, 우리 제품이 시장에서 3년 뒤처졌다는 것을 깨닭았습니다. 그때까지는 세계 최고의 시장 출시 팀이라도 우리를 구할 수 없었을 것입니다.

떠나며 드는 생각

많은 사람들이 개발툴 시장에 대해 강한 감정을 가지고 있습니다. 엔지니어들은 개발툴 만들기를 좋아하기 때문에 개발툴 회사들이 성공하기를 바랍니다.

나는 이 시장을 완전히 떠나기가 망설여집니다. 단 한 번의 경험으로 일반화 하고 싶지가 않습니다. “어쩔 수 없었다"라고 말하고 싶지 않습니다. 꽤 많은 예외가 있기도 합니다. GitHub, MongoDB, 그리고 Docker는 강력한 회사를 만들었습니다. GitLab과 Unity도 잘하고 있는 것으로 보입니다.

만약 여러분이 개발툴 회사를 만들려 한다면, 돌다리도 두들겨 보면서 건너세요. 시장은 좋은 대체품으로 가득 차 있습니다. 사용자들의 기대치는 높고 가격은 낮습니다. 여러분이 고객들에게 제공하는 가치에 대해 깊이 생각하세요. 세상이 원하는 대로 되지 않는다는 것을 기억하세요.

2009년, 우리는 Y Combinator 데모데이에서 (소프트웨어는 아직 없었지만) 초기의 RethinkDB 아이디어에 대해 투자자들에게 발표했습니다. 기억해야 할 세 가지 핵심 포인트로 마지막 슬라이드를 끝냈습니다. “여러분이 RethinkDB에 대해 딱 세 가지만 기억한다면, 이것만 기억하세요.” 사람들은 발표의 나머지는 아무것도 기억하지 않았지만, 마지막의 세 가지 포인트는 기억했습니다.

이제 저는 여러분에게 기억해야 할 세 가지 포인트를 남겨드리겠습니다. 이 글에서 아무것도 기억하지 않더라도, 이것만은 기억하세요:

• 큰 시장을 선택하고 특정한 사용자를 위한 제품을 만드세요.
• 여러분이 놓치고 있는 재능을 발견하는 법을 배우고, 여러분의 팀에서 그것을 얻기 위해 치열하게 일하세요.
• 이코노미스트지를 진지하게 읽으세요. 여러분을 더 훌륭하고 빠르게 만들어줄 것입니다.