사이드키크의 제작자 마이크 퍼햄: 고용에서 독립으로
Nov 29, 2023

Contents
마이크, 몇 가지 질문에 답변해 주셔서 감사합니다. Sidekiq 출시 직후에 Sidekiq Pro를 소개하신 것으로 알고 있습니다(검색을 해보니 원래 발표문을 찾을 수 없었습니다). 사이드키크를 상용화할 아이디어를 어떻게 얻게 되었나요? 이전에 진행했던 다른 프로젝트에서 영감을 얻었나요?오픈 코어라는 개념은 2008년에 아담 램핏이 처음 사용한 것으로 알려져 있으며, 2012년에는 비교적 새로운 개념이었습니다(원래 인용문으로 거슬러 올라갈 수는 없지만). 오픈 코어 모델을 선택하게 된 요인은 무엇인가요? 이중 라이선스 구조도 고려했나요?사이드키크 개발을 시작할 당시 전반적인 생활 상황은 어땠나요? 당시 풀타임 직장을 다니고 있었나요?사이드키크 프로와 엔터프라이즈 판매로 스스로를 지탱할 수 있는 지점에 도달하기까지 얼마나 걸렸나요? 사이드키크에 올인하기 위해 언제 직장을 그만두었나요(개발을 시작할 당시 직장을 다니고 있었다면)?파란만장한 역사를 거쳐 Sidekiq는 루비를 위한 백그라운드 작업 처리의 최종 진화라고 할 수 있습니다. 왜 그렇게 생각하시나요?사이드키크 프로에 대한 초기 반응은 어땠나요? 사람들이 무료로 사용하는 것에 익숙해져 있는 것을 유료화할 경우 반발이 있을까 걱정되지는 않았나요?요즘 운영 범위는 어떻게 되나요? 사이드키크에서 일할 다른 개발자를 채용하기 위해 확장했나요?Sidekiq Pro/엔터프라이즈는 어떻게 배포하나요? 당시 코드 코드 쉽이 있었다면 사용하셨을까요?마지막으로 사이드키크의 미래와 더 일반적으로는 본인의 미래는 어떻게 될까요? 팍토리라는 다른 프로젝트도 진행 중이신 것으로 알고 있습니다. 그 프로젝트에 대한 반응은 어땠나요?마이크, 시간을 내어 질문에 답변해 주셔서 감사합니다. 상용 소프트웨어 라이브러리 개발을 고려하고 있는 개발자들이 여러분의 경험과 관점에 많은 관심을 가질 것이라고 확신합니다.조쉬의 프로덕트 레터를 구독해주세요.
퀄리티 높은 1인 창업, 프로덕트 이야기를 일주일에 1번 받을 수 있습니다.[👉🏻👉🏻구독하기]
저는 때마침
사이드키크(Sidekiq
)가 도약하는 것을 보고 루비를 배웠습니다. 2010년대 초, 루비에는 백그라운드잡부터
지연잡
, 레스크
등 수많은 백그라운드 작업 프로세서가 등장했습니다. 각 백그라운드 작업 프로세서는 이전 버전에서 나름의 방식으로 개선되고 혁신되었습니다. DelayedJob은 단일 Ruby 인스턴스에서 여러 작업을 실행할 수 있었습니다(BackgroundJob은 새 작업마다 전체 가상 머신을 로드해야 했습니다). Resque는 이 공식을 개선하여 작업을 Redis에 저장함으로써 훨씬 더 빠른 속도를 구현했습니다.그러나 2012년에 Sidekiq가 등장하기 전까지는 여전히 Ruby 프로세스당 단일 스레드로만 작업을 실행할 수 있었습니다. CPU를 포화시키려면 코어당 많은 스레드가 필요하거나 일반적으로 IO를 포화시키려면 많은 스레드가 필요할 수 있다는 점을 고려하면, 많은 애플리케이션이 최대 CPU 또는 IO에 도달하기 훨씬 전에 메모리에 묶여 있었습니다. 그러던 중 Sidekiq가 등장했고... "Sidekiq는 스레드를 사용하여 동일한 프로세스에서 동시에 많은 작업을 처리합니다." ... 그 문제를 해결했습니다.
Sidekiq은 제가 기억하는 루비 세계에서 코드에 스레드 안전성을 요구한 최초의 프로젝트였습니다. 당시 주요 웹 서버였던 Unicorn과 Passenger도 동시성을 위해 여러 프로세스에 의존하는 멀티스레드가 아니었습니다. 따라서 우리 모두가 수년간 작성해 온 애플리케이션 코드는 말할 것도 없고 실제로 스레드 안전하지 않은 라이브러리도 많았습니다. 멀티 스레딩의 매력은 거부할 수 없었고, 모든 것이 순식간에 바뀌었습니다. 몇 달 만에 모든 주요 라이브러리와 대부분의 마이너 라이브러리가 이미 스레드 안전 문제를 패치했습니다. 2012년 중반에 Rails에 대한 홍보를 통해
스레드 안전이
기본적으로 활성화되었습니다 !
이 변경은 Sidekiq에 의해 촉진되었습니다.2011년에 출시된 이후 Sidekiq는 백그라운드 작업 처리를 위한 Ruby의 주요 라이브러리로 자리 잡았습니다. Sidekiq 0.5 버전 출시와 함께 Mike Perham은 일괄 처리 및 알림을 비롯한 추가 기능을 제공하는 Sidekiq Pro도 소개했습니다. 이어서 더 많은 기능과 더 높은 가격대를 갖춘 0.7 버전이 출시되었습니다. 따라서 Sidekiq는 개방형 코어 모델을 따르며 Sidekiq를 무료로 제공하고 프로 및 엔터프라이즈 기능에 대한 요금을 부과합니다.
최근 마이크에게 코드코드쉽 인터뷰에 응해줄 수 있는지 물었고, 흔쾌히 응해주었습니다. 아래에서 인터뷰 전문을 읽어보실 수 있습니다.
마이크, 몇 가지 질문에 답변해 주셔서 감사합니다. Sidekiq 출시 직후에 Sidekiq Pro를 소개하신 것으로 알고 있습니다(검색을 해보니 원래 발표문을 찾을 수 없었습니다). 사이드키크를 상용화할 아이디어를 어떻게 얻게 되었나요? 이전에 진행했던 다른 프로젝트에서 영감을 얻었나요?
제 블로그에 가서 2012년으로 스크롤을 내리면 Sidekiq의 탄생과 당시 제 생각을 실제로 볼 수 있습니다. 저는 몇 년 동안 백그라운드 작업 시스템을 개발해왔고 거의 모든 루비 회사가 이 시스템에 의존하고 있다는 것을 알고 있었습니다. 작업 처리를 위해 클러스터에 수만 또는 수십만 달러를 지출하는 회사들과 함께 일하고 있었기 때문에 이 시스템이 엄청나게 가치 있다는 것을 알았습니다. 멀티스레딩을 통해 효율성을 개선하는 것은 이러한 회사들에게 당연한 일이었습니다.
또한 오픈소스 개발자들이 무급으로 계속되는 노동으로 인해 지쳐가는 것을 보았습니다. 무료로 제공하는 가치 있는 무언가를 만드는 것은 무임승차자 문제에 대한 완벽한 해결책처럼 들렸습니다. 저는 사이드키크가 성공하기를 원했고, 개발자들이 지치고 싶지 않았기 때문에 몇 가지 '재정적 실험'을 해보기로 했습니다.
"분기당 350달러는 실패라고 생각했습니다."
오픈 코어라는 개념은 2008년에 아담 램핏이 처음 사용한 것으로 알려져 있으며, 2012년에는 비교적 새로운 개념이었습니다(원래 인용문으로 거슬러 올라갈 수는 없지만). 오픈 코어 모델을 선택하게 된 요인은 무엇인가요? 이중 라이선스 구조도 고려했나요?
제 첫 번째 재정적 실험은 기업들이 LGPL 라이선스를 피할 수 있도록 50달러짜리 상용 라이선스 변형을 판매한 것이었습니다. 3개월 동안 7개를 판매했던 것 같아요. 분기당 350달러는 실패라고 생각했죠.
다음 실험은 오픈 코어였습니다. Sidekiq 위에 더 많은 엔터프라이즈 중심 기능을 갖춘 클로즈드 소스 애드온 패키지를 판매하는 것이었습니다. 그렇게 해서 Sidekiq Pro가 탄생했습니다. 제 유일한 의문은 어떻게 하면 세상에 접근 권한을 주지 않고 Sidekiq Pro를 배포할 수 있을까 하는 것이었습니다. 마침 Rubygems가 타사 보석 서버를 잘 지원하고 있었습니다. 저는 아주 간단한 겜 서버를 설정하고 HTTP 기본 인증으로 Sidekiq Pro .gem 파일에 대한 액세스를 게이트했습니다. 디지털 상품을 판매할 수 있는 WePay라는 사이트에서 판매자 계정을 만들었습니다. 구매 시 WePay에서 "판매가 완료되었습니다!"라는 이메일을 보내면, 저는 보석 서버에 로그인하여 구매자의 액세스 권한을 수동으로 추가했습니다.
사이드키크 개발을 시작할 당시 전반적인 생활 상황은 어땠나요? 당시 풀타임 직장을 다니고 있었나요?
그 당시 저는 루비를 5년 동안 사용해왔고, 이전 루비 OSS 작업과 꾸준한 블로깅으로 비교적 잘 알려져 있었습니다. 이미 사람들이 저를 평판으로 알고 있었기 때문에 Sidekiq와 Sidekiq Pro를 홍보하기 시작할 때 매우 유용했습니다. 이미 저를 알고 신뢰하는 잠재고객이 있다면 마케팅은 쉬워집니다!
저는 아웃도어 중심의 이커머스 벤더(매장이 없는 REI라고 생각하시면 됩니다)였던 The Clymb에서 기술 운영 디렉터로 근무했습니다. 4명으로 구성된 팀에서 사이트 개발 및 인프라를 담당하고 있었습니다. 알파 고객이었고 저는 기술 스택을 담당하고 있었기 때문에 완벽했습니다. 물론 Clymb은 즉시 Sidekiq으로 전환했고, 제가 작성한 모든 Sidekiq Pro 기능은 출시 전에 프로덕션 환경에서 실행되었습니다.
사이드키크 프로와 엔터프라이즈 판매로 스스로를 지탱할 수 있는 지점에 도달하기까지 얼마나 걸렸나요? 사이드키크에 올인하기 위해 언제 직장을 그만두었나요(개발을 시작할 당시 직장을 다니고 있었다면)?
"2014년 3월에는 Clymb 월급보다 Sidekiq Pro 판매로 더 많은 돈을 벌었습니다."
2012년 10월에 Sidekiq Pro를 출시했습니다. 2012년 4분기에 7500달러 상당의 Sidekiq Pro를 개당 500달러에 판매했으니 15개의 라이선스를 판매한 셈입니다. 훨씬 더 높은 가격대에 더 많은 판매가 이루어졌습니다. 여기 뭔가 있을지도 몰라요!
저는 2014년 6월까지 The Clymb에서 일하다가 사이드키크에 전념하기 위해 그만두었습니다. 2014년 3월까지만 해도 월 약 10,000달러였던 Clymb의 월급보다 Sidekiq Pro 판매로 더 많은 수익을 올렸던 것으로 기억합니다.
저는 현지 변호사의 도움을 받아 법인 설립을 했고, 그렇게 Contributed Systems가 탄생했습니다.
파란만장한 역사를 거쳐 Sidekiq는 루비를 위한 백그라운드 작업 처리의 최종 진화라고 할 수 있습니다. 왜 그렇게 생각하시나요?
저는 거기까지 갈 수 있을지 모르겠습니다. 그 이후로 여러 가지 Ruby용 작업 시스템이 출시되었지만 Sidekiq만큼 기능이 풍부하고 잘 지원되는 시스템은 없었습니다. 혁신과 새로운 방향은 항상 존재하지만, 대부분의 루비 애플리케이션은 대다수 커뮤니티에서 "수용 가능한" 두 가지 영구 저장소로 Postgres와 Redis에 정착해 왔습니다.
"결국 OSS 번아웃은 견인력을 얻는 모든 무료 프로젝트를 죽일 것입니다."
그리고 저는 "기능이 풍부하고 잘 지원된다"는 것은 100% 상업적인 측면 때문이라고 생각합니다. 가끔 경쟁자들이 시작하는 것을 보지만 결국에는 OSS의 고갈이 무료 프로젝트가 주목을 받는 것을 죽일 것이라는 것을 알고 있습니다. 저는 기술을 사랑하지만, 사용자 지원을 위해 돈을 받고 있기 때문에 여전히 이 일을 하고 있습니다.
사이드키크 프로에 대한 초기 반응은 어땠나요? 사람들이 무료로 사용하는 것에 익숙해져 있는 것을 유료화할 경우 반발이 있을까 걱정되지는 않았나요?
물론이지만 예상했던 것보다 훨씬 더 따뜻했어요. 번아웃 문제에 대해 블로그에 글을 올렸더니 사람들이 100% 지지해줬어요. 사실 지인이나 신뢰하는 사람을 응원하기 위해 구매해야 하는 또 다른 이유가 생겼습니다.
요즘 운영 범위는 어떻게 되나요? 사이드키크에서 일할 다른 개발자를 채용하기 위해 확장했나요?
아직 직원이 0명이며 채용할 계획이 없습니다. 저는 비즈니스 프로세스를 최대한 간소하게 운영하도록 조정합니다: 대부분의 고객이 신용카드를 사용하므로 자동 결제가 이루어집니다. 보석 서버는 1년에 하루 정도 유지보수가 필요합니다. 지원 업무는 매우 기술적이고 전문적이기 때문에 많은 부분을 아웃소싱할 수 없습니다.
"CCS 같은 것이 있었다면 큰 도움이 되었을 것"
Sidekiq Pro/엔터프라이즈는 어떻게 배포하나요? 당시 코드 코드 쉽이 있었다면 사용하셨을까요?
배포 수단을 찾는 데 시간이 좀 걸렸는데 CCS 같은 것이 큰 도움이 되었을 거예요! Rubygems는 매우 잘 설계되어 있어서 나만의 젬을 제공하는 것이 어렵거나 리소스 집약적이지 않다는 것을 알 수 있었습니다. 이에 비해 NPM은 엄청나게 과도하게 설계되어 있고 페더레이션하기가 훨씬 더 어렵습니다. 제 젬 서버는 DigitalOcean에서 6달러짜리 물방울입니다. 보석은 정적 파일에 불과하기 때문에 이 작은 드롭렛은 아파치만으로 하루에 수백만 건의 요청을 처리할 수 있습니다. 그리고 장애 조치 목적으로 세 대의 서버를 병렬로 실행하여 총 월 18달러를 지불하고 있습니다.
마지막으로 사이드키크의 미래와 더 일반적으로는 본인의 미래는 어떻게 될까요? 팍토리라는 다른 프로젝트도 진행 중이신 것으로 알고 있습니다. 그 프로젝트에 대한 반응은 어땠나요?
2017년에 저는 다른 생태계와 언어에도 Sidekiq을 도입하고 싶다고 결심했습니다. 그래서 Sidekiq를 Crystal로 재구현한 Sidekiq.cr을 만들었습니다. Sidekiq.js를 가지고 장난을 쳤지만 우리 모두 알다시피 JavaScript는 끔찍하기 때문에 그 아이디어를 빨리 죽이기로 결정했습니다. 다른 언어로 Sidekiq을 다시 구현할 수 없다는 것을 깨닫고 아키텍처를 변경하고 Faktory를 시작했습니다. 팍토리는 Go로 작성되었으며 Redis를 대체하는 역할을 합니다. 팩토리는 모든 작업 및 큐 관리를 중앙 집중화하고 백그라운드 작업을 위한 간단한 프로토콜을 제공하며, 언어별 작업자 프로세스가 해당 프로토콜을 구현하고 실제로 작업을 실행합니다.
사이드키크와 마찬가지로 팍토리는 더 많은 기능과 지원을 제공하는 팍토리 엔터프라이즈에 상용 확장 기능을 제공합니다.
지난 가을에는 웹 UI에 정말 아름답고 유용한 성능 메트릭을 추가하고 다른 Ruby 프로세스 내에 Sidekiq을 임베드할 수 있는 기능을 추가한 Sidekiq 7.0을 출시했습니다. 지난 몇 달 동안은 남아 있는 버그를 해결하고 7.0을 안정화시키는 데 집중했습니다.
"가치 있는 것을 만들면 돈을 청구하라"
마이크, 시간을 내어 질문에 답변해 주셔서 감사합니다. 상용 소프트웨어 라이브러리 개발을 고려하고 있는 개발자들이 여러분의 경험과 관점에 많은 관심을 가질 것이라고 확신합니다.
저처럼 다른 오픈소스 개발자들도 돈은 본질적으로 악한 것이 아니라 가치를 교환하는 수단일 뿐이라는 사실을 깨닫게 되기를 바랍니다. 가치 있는 무언가를 만들면 그에 대한 비용을 청구하여 커뮤니티를 계속 구축하고 지원할 수 있도록 하세요!
조쉬의 프로덕트 레터를 구독해주세요. 퀄리티 높은 1인 창업, 프로덕트 이야기를 일주일에 1번 받을 수 있습니다.
[👉🏻👉🏻구독하기]
Share article