달력

022017  이전 다음

  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  •  
  •  
  •  
  •  

'2017/02'에 해당되는 글 1건

  1. 2017.02.05 RethinkDB shutdown 관련 글을 읽으면서

평소 데이터 저장소 관련해서 CockroachDB, ArangoDB와 RethinkDB를 관심있게 보고 있었습니다.
CockroachDB는 확장성과 Consistency를 ArangoDB는 다양한 모델 지원(K-V, Doc, Graph), RethinkDB는 real time 을
무기로 본인들의 DB가 좋다고 내세웠다. (순전히 저의 생각이에요.)


어느날 RethinkDB가 shutdown 했다는 트윗을 보게 되었습니다. 기술적으로 꽤 괜찮았다고 생각했는데 
어떤 이유로 문을 닫는지 궁금해서 관련 글을 찾아보게 되었습니다.

부족한 영어지만 찾은 글들을 정리해보려고 합니다.



https://rethinkdb.com/blog/rethinkdb-shutdown/

공식 홈페이지 블로그에 올라온 shutdown 된다는 얘기, 기술력은 꽤 괜찮았지만 적당한 비지니스 모델을 못 찾아서

shutdown 했다는 얘기와 Stripe에 합류해서 오픈소스로서 RethinkDB를 진행한다는 얘기를 하고있다.


Why RethinkDB failed  ***** 별 다섯개!!


※ 원래는 읽어보고 기억에 남는것만 적으려고 했는데 읽다보니 한줄 한줄 정말 저에게 도움 되는 내용들이 많아서
안되는 영어지만 의역을 하였습니다. (뭐 반 이상은 구글 번역기가 해주었지만요...)

생략하기도 하고 제가 틀리게 해석한 부분이 있을수도 있으니 여기서는 느낌만 가졌으면 좋겠습니다.
오역이 있다면 알려주세요.


우리가 RethinkDB shutdown 발표했을 때 저는 여기서 얻은 교훈을 쓰겠다고 약속했었습니다. 

경험들을 정리할 시간이 필요했고 이젠 명확하게 써보려고 합니다.

Hacker News에 RethinkDB shutdown글에 달린 댓글 들을 종합해봤는데 대부분은 실패한 원인이 아니라 증상이었습니다.


나중에 생각해보니 두가지 를 잘못했습니다. 하나는 최악의 시장을 선택한 것이고 다른 하나는 제품 측정의 잘못된 최적화를 한 것입니다. 하나하나 실수는 RethinkDB 가치를 반 토막 냈습니다. 의미 없는 얘기지만 앞에 두가지 중 한가지라도 했다면 우리는 MongoDB 정도 크기의 회사가 됐을 것이고, 두 가지 모두를 잘했다면 RedHat 정도의 회사가 되었을 것입니다.


Terrible Market

신생 기업은 Oracle 기반으로 세워지지 않기 때문에 새로운 인프라 회사로 돈 벌 기회가 있을 거라 생각했고, 
특히
DB 시장은 아주 큰데 이 시장에 맞는 제품을 만들면 우리는 성공한 회사를 만들 거라고 생각했습니다.


불행하게도 우리는 우리가 생각한 시장에 있지 않았고, 우리는 사용자가 생각한 시장에 있었습니다.

RethinkDB 사용자들은 우리를 오픈소스 개발자 도구 회사로 생각하고 있었습니다. 

오픈 소스 시장은 최악의 시장이 소지가 다분합니다. 천 명의 사용자가 RehinkDB 실제 상업적으로 사용하고 있었는데

이들 대부분은 실제 사용한 시간보다 적은 스타벅스 커피 한 잔 값보다 못한 가격을 지불하려고 했습니다. (말하자면 내기 싫었다는 것입니다.)


사용자들이 지원금을 보내지 않을 정도로 제품이 훌륭한것도 아니고, 개발자들이 예산관리를 안 해서도
자본주의가 무너진것도 아니었습니다. 답은 미시 경제학입니다. 
개발자들은 공짜 개발자 도구를 좋아해서 엄청난 수요가 있는데 공급은 그 수요를 훨씬 뛰어 넘습니다.

대체 가능한 도구들이 많다는 것을 뜻하고 그래서 가격은 0으로 수렴한다. 

내용이 어떻게 적용되는지 보기 위해서 $1.6B 가치와 700명의 직원이 있는 MongoDB $1B 가치와 300명의 직원이 있는 Docke 살펴보겠습니다.
회사는 각자의 시장을 완벽하게 지배했습니다. 연봉도 엄청나고 가치도 급성장하고 있습니다. 


굉장히 좋아 보입니다. 개발자 도구 회사가 아닌 시장의 회사들을 보기 전까진….(SalesForce, Palantir 그리고 Box)

그들이 보기에는 MongoDB Docker 굉장히 작아 보일 겁니다. 


회사를 세우는데 이미 파트너십도 존재하고, 유통 인프라, 미친듯이 성장하는 고객들을 보유 했다는것이
지금 시작하는 스타트업에겐 어떤 의미 일까요?


고집스러운 사용자를 모은다는 것을 의미했다. 괜찮은 B2B 시장으로 시작하는 스타트업은 100개의 기회중에 10개의 실제 판매를 한다면개발자 도구 스타트업은 이것의 10배의 기회가 있습니다.
개발자 도구 회사는 우수한 잠재 고객들을 확보 할수 있습니다. - 굉장히 많은 사람들이 당신의 제품을 다운로드 하는것을 의미.
그런데 실제 판매되는건 조롱받을 정도로 낮습니다.


이것은 도미노 효과를 일으켜 피해를 일으켰습니다.
팀의 사기를 떨어뜨렸고 투자 유치하는것과 유능한 인재들을 영입하는것이 어려워졌습니다.

결국 제품 유통에 효과적인 투자를 할 수 없도록 리소스가 제한되었습니다.
스타트업은 살고 죽는것은 한 순간인데, 초기 유통 문제는 대부분 망하는것으로 이어집니다.


Wrong metrics of goodness(잘못된 제품 측정?)

시장이 잘못된 건 알겠는데 다른 개발자 도구 회사들은  나갑니다. RethinkDB 된 걸까요?

시장은 우리가 어떻게 할수 있는 부분은 없지만 제품 결정은 우리가 할수 있었습니다.

우리는 우아하고 강력하고 아름다운 제품을 만들기로 했고 그래서 다음과 같은 측면에 힘쓰기로했습니다.

  • 정확성 : 굉장히 정확하도록 만들었습니다. (그래서 성능이 떨어진다…)
  • 인터페이스 단순화: 구현의 복잡성은 감수 했으므로 사용자가 간단하게 사용하는것에 초점을 맞췄습니다.
  • 일관성: 모든것을 query 만들려고 했습니다. client 드라이버, 설정, 문서 가능한건 모두!!

http://dreamsongs.com/RiseOfWorseIsBetter.html 에서는 3개가 
대부분의 사용자가 제품에게 바라는게 아니라고 말하고 있습니다.


대신 사용자가 원하는 3가지는

  • 원하는게 있을때 그걸 해결할수 있는 제품
  • 빠른 속도: 우리가 제시하는 실 생활의 부하가 아니라 테스트 가능한 범위에 부하 테스트를 견딜만큼 빠르길 원합니다.
    MongoDB는 슬기롭게 해결했지만 우리는 그렇지 못했습니다.
  • 실제 사용기(?): 우리는 괜찮은 DB 시스템을 만들었지만 사용자는 “X 하기 위한 좋은 방법 원했습니다.
    (hapi
    에서 JSON 문서를 저장하는 방법, 로그를 저장하고 분석하는 좋은 방법, 리포트를 만드는 좋은 방법)


3가지를 한건 아닙니다. 하지만....시장에 내놓기 까지 3년이 걸렸습니다.

3 뒤에 시장에 내놓았더니 대부분의 사용자가그래서 RethinkDB MongoDB 다른점이 뭔가요?” 질문을 했습니다.

위에서 나열한 것들의 중요성에 관 설명했지만, 사용자는 신경도 썼습니다.


솔직히 말하면 상처 받았습니다. 엄청 받았어요. 우리는 사용자들이 MongoDB 선택하는지 이해할수 없었습니다.

※ MongoDB 좋은 나열ㅋㅋㅋ


MonoDB 새로운 릴리즈를 출시하면 사용자들은 개선 사항을 보며 축하를 보냈는데, 저 분노를 느꼈습니다

A 수정했다고 했지만, B 성능을 떨어뜨린 거였고, C 기능을 추가했다고 했지만, D 기능을 줄인 것이었습니다.


하지만 시간이 지나자 MongoDB 일반 개발자를 영웅으로 만들었습니다.
저장은 굉장히 빨랐고, 제품 개발 속도도 빠르게 만들어 주었습니다
우리가 원했던 아름다운 제품은 아니었지만, 동작했습니다.


2014 중반이 되자 우리는 MongoDB 경쟁이 되었습니다, 그래서 MongoDB 차별성을 두어 일 했고 굉장히 멋진 방법으로

realtime push 기능을 만들었고 이를 이용해서 이전에는 만들 수 없었던 앱을 개발하기를 바랬습니다

하지만 갑자기 우리가 realtime push를 생각하고 개발하기 훨씬 전부터 realtime push에만 전념했던 

Meteor Firbase 회사가 등장했습니다.

우리는 다시 시장에서 3 뒤처졌고, 우리는 그들과 경쟁할 수 없다는 것을 깨달았습니다.


Cloud 어때?

종종 사람들이 cloud 서비스를 제공하는건 어떠냐는 제안을 했습니다.

우리같은 작은 database 기업이 클라우드를 이용 한다는것은 스트타업의 망하는 패턴과 비슷한 문제가 있습니다.

빌드, 배포, 관리는 매우 어려운데 모든것에 집중을 해야하기 때문입니다.

하지만 우리는 더이상 선택지가 없었고 클라우드를 어떤 형태로 할지 정하기로 했습니다.


datababase 클라우드로 제공하는 방법은 3가지 방법이 있는데, 호스팅 관리, database service형태로 제공, 

아예 플랫폼 형태로 제공 이렇게 있습니다.


호스팅 관리는 이미 AWS가 꽉잡고 있어 쉽지 않습니다. 

Compose.io와 mLab가 RethinkDB보다 두배나 많은 사용자를 지닌 MongoDB를 제공하는것을 고려할때 

호스팅관리는 우리와 맞지 않다고 생각했습니다. 

(※ 제 생각은 MongoDB를 제공하는데도 두 회사 규모가 작은것을 얘기하는것 같습니다.)


DBaaS은 호스팅 관리보다 좀 더 복잡합니다. DB의 깊은 이해 없이도 사용 할수 있도록 추상화된 노드 관리 기능을 

사용자에게 제공 해야합니다. 이것은 사업적으로 굉장히 도전적이었는데, 

1. DynamoDB나 DocumentDB와 같은 거물급들과 경쟁해야 합니다.

2. 대체할 제품이 많이 있는데 사용자가 자신의 데이터를 스타트업에게 맡기는것을 꺼려합니다.
우리는 DBaaS도 제외 했습니다.


마지막 Paas가 우리의 길이라고 생각했는데, 왜냐하면 우리는 굉장한 기술적 우위를 가졌기 때문이었습니다. 

Firebase와 Meteor는 MongoDB위에서 어플리케이션 레벨에서 realtime 로직을 수행했는데, 

이는 대규모 실시간 query 처리량과 성능의 제한을 둡니다.

반대로 우리는 어플리케이션 레벨뿐 아니라 모든 부분을 다뤘기때문에 Firebase와 Meteor는 할수 없는 
특별한 이점을 제공할수 있었습니다.

그래서 우리는 Horizon과 함께 사용자가 Horizon Cloud에서 RethinkDB와 Horizon을 배포하고 

확장이 가능하도록 작업을 시작했습니다. 하지만 작은 팀들이 3개의 대형 프로젝트를 진행하면서 겪는 어려움은 우리를 붙잡았고, 돈이 떨어지기 전에 우리는 cloud로 제공하지 못했습니다. 하지만 엔지니어는 잘 해주었습니다. 거의 완성 단계였습니다.


근본적인 질문

우리는 나쁜 시장을 선택하고, 잘못된 제품 최적화를 했을까요?


어렸을 때 저는 나만의 라디오를 만들고 싶었습니다.
합판으로 박스를 만들고 안에 금속을 집어 넣고 전원선과 박스를 연결했습니다.

그때 집에 전자공학 책이 있었지만 책이 없어도 만들수 있다는 확신이 있었습니다.

마침내 라디오를 만들었습니다. 하지만 전자공학 기초를 배울 필요성을 깨닫는데 몇년이 걸렸습니다.


초기 RethinkDB 사례와 거의 흡사했습니다.
우리는 제품이나 시장에 대한 직관이 없었기 때문에 우리가 해야할지에 대한 정확한 이해 없이 회사를 세웠습니다. 

더군다나 우린 낙관주의자였습니다. 경제 법칙과 회계는 우리와 상관없다고 생각했지만 아니었습니다.


어렸을때 라디오를 만들었을때와 별반 다르지 않습니다. 우리는 사업적으로 서툴렀고, 이것을 깨닫는데 몇년이 걸렸다.


몇몇 사람들은 우리가 go-to-market 팀을 꾸렸다면 지금보다 훨씬 잘했을거라고 얘기합니다다.

초기에 우리는 go-to-marker 전문가의 필요성에 대해 알지 못했고, 그래서 재무팀을 포함해 찾을 생각을 안 했습니다.

우리가 현실을 깨달았을때는 이미 자금이 부족했고, 가뜩이나 어려운 시장에 나가는 경쟁자들,
그리고 우리의 제품이 3 정도 뒤쳐졌다는 것을 깨달았습니다.


세계에서 유능한 go-to-market 팀도 우리를 살릴수는 없었습니다.



맺으며

많은 사람들은 개발자 도구 시장에 대해서 굉장히 강한 인상을 가지고 있습니다. 

엔지니어는 개발자 도구를 만드는것을 굉장히 좋아해서 개발자 도구 회사가 번창하기를 원합니다.


나는 시장을 무시하는걸 망설이고 있습니다. 이유는 3가지인데

한번의 경험으로 이렇게 생각하는것을 바라지 않습니다.

그리고 나는할수 없다라는 말을 싫어합니다.

마지막으로 예외적으로 성공한 회사들이 있습니다. GitHub, MongoDB, Docker같이 나가는 회사도 있고,
GitLab, Unity 같이 해내는 회사 처럼 하는 회사들이 있습니다


만약에 여러분이 개발자 도구 회사를 만들기 시작했다면 신중하세요.  시장은 대체 가능한 제품들로 가득차있습니다.

사용자들은 높은 기대와 낮은 가격을 기대하고 있습니다. 사용자에게 어떤 가치를 제공해줄수 있는지 깊게 생각하세요.

기억하세요 - 세상이 특정 방향으로 흘러가길 바란다고 세상이 그렇게 만들어지지 않는다.


2009 YCombinator 데모데이때 우리는 투자자들에게 RethinkDB 초기 아이디어를 발표했었습니다.
슬라이드에서 기억해야할 3 가지를 얘기하고 발표를 마쳤습니다

“RethinkDB 대해 3가지만 기억해야 한다면”, “이것만 기억하세요라고 말했고, 효과가 있었습니다.

다른것은 기억 했지만, 마지막에 얘기한 3가지는 기억했습니다.


이글에서 기억해야할 3가지 포인트를 남기려고 합니다. 해당 글을 기억해야 한다면 이것만 기억하세요.


시장을 선택하세요. 하지만 특정 사용자를 위해 만드세요

당신이 무엇을 놓치고 있는지 깨닫는것을 배우고, 당신 팀이 얻기위해 지옥처럼 일하세요.

The Economist를 자세히 읽으세요. 이것은 더 빠르게 당신을 좋게 만들것입니다.



Summarizing RethinkDB why we failed  





Rethinkdb joins linux foundation

CNCF가 RethinkDB를 사면서 라이센스가 ASLv2로 변경됐다는 것과 기존 Github이나 웹페이지, SNS계정들은 계속 운영 됨을
얘기하고 있다. RethinkDB가 shutdown 되면서 RethinkDB 직원든이 Stripe에서 일하게 됐고, 그곳에서 RethinkDB
오픈소스 참여를 통해 지속적으로 발전 시킨다고 한다. 곧 2.4를 릴리즈 하는데 2.5에서는 개발자들이 좀 더 다가가기 쉽게 코드를 개선하는것을 최우선으로 하고 Legacy코드와 기술 부채 제거 하면서 성능 향상이 목표라고 얘기 한다.



https://www.joyent.com/blog/the-liberation-of-rethinkdb

함께 만들어가는 입장에서 AGPL의 문제점을 설명하고  CNCF에서 RethinkDB의 지적재산권(?)을 샀다는 얘기
그리고 Apache Public License 2.0. 로 변경했다는 얘기를 전한다.

RethinkDB meeting Note


라이센스에 관한 설명



RehinkDB is dead long live RethinkDB

Social Tables 서비스를 운영하면서 MySQL 적용했을때의 단점을 얘기하고 Rehink로 옮겼을때의 장/단점을 언급한다.

RethinkDB의 단점이 큰 문제가 아니라는 점을 언급하고 오픈소스가 주는 자유의 힘, 그리고 참여하고 싶다는 얘기로 마무리 한다.



RethinkDB vs Postgres

해당 포스트와 거리는 멀지만 RethinkDB를 잘 사용하다가 shutdown과 license로 인해 PostgreSQL로 전환한 얘기가 흥미로워 추가했다. (※ PostgreSQL에 notify, listen이 있는건 처음 알았네요.)


스타트업을 그만두며 깨달은 3 가지 (이 글도 관련있는 글이라 첨부해봅니다. ㅎ)




※ 내 생각

3년 전 부터인가? 기회가 된다면 1인 기술회사 운영을 막연하게 생각"만"하고,
주위 사람들에게 말하고 다녔습니다. (사회 초년생때 만난 송상욱 형님 영향이 크다고 생각되요.ㅎ)
위에서도 말했지만 저도 기술력만 뛰어나면 마케팅이나 투자 없이도 성공할수 있다고 생각했습니다. 

제프딘이나 더그 커팅, 존 카맥 정도는 되야 앞의 문장이 성립하고,
그게 아니라면 기술뿐 아니라 비즈니스도 뒷받침 되어야하는걸 이제야 알게되었습니다. (참 빨리도 알았네요;;)
(각자 생각하는 성공의 관점에 따라 다르겠지만 돈 많이 버는것, 생존 이후의 step)

더군다나 최근에는 굉장히 멋있는 설계와 꽤 괜찮은 기술을 썼다고 성공 하는것도 아니고, 10년 전 기술을 사용하고
아슬아슬한 설계라고 해서 성공 못하는것도 아님을 깨닫고 있습니다. 

제가 생각했던 시장이 그다지 좋지 않다는것도 알게 되었구요. 단순한 지적 호기심과 인기에 따라 움직이지 않고

제가 잘하는건 무엇이고 지금 해야할 것들을 잘하는 것과 어떻게 연관시킬수 있을지 항상 고민하고 실행 해야겠습니다.

값진 경험을 잘 정리해준 RethinkDB 아끼고, 오픈소스 만세~~~~~


ps:
"Done is better than perfect. 수 백번의 이상적인 생각보다 한번의 실행이 변화의 시작이다."
다양한 요구사항을 손쉽게 수정할수 있고 멋진 설계를 하는게 당연히 좋지만
정해진 시간 안에 완성 하는게 최우선되어야합니다.
주어진 시간 안에 요구사항을 충족하는 동시에 나름 괜찮은 걸 만들수 있도록 많은 연습을 해야겠습니다.

X 같은 프로페셔널리즘 (이곳에서 말하는 프로란 허용할 수 있는 품질을 주어진 시간안에 만들수 있는 사람을 말한다.)

저작자 표시 비영리
신고
Posted by 오산돌구