원문: Scaling a side project: The story of daily.dev [링크]
[목차]
daily.dev는 다양한 단계를 거쳐 왔습니다. 이 프로젝트는 한 개발자가 시작한 사이드 프로젝트로 출발하여, 이후로는 활발한 기여자와 활기찬 커뮤니티를 가진 오픈 소스 프로젝트로 발전했습니다. 결국 이는 20명 이상의 인원으로 구성된 회사로 성장하게 되었으며, 여러 엔지니어링 팀을 운영하며 수십만 명의 사용자를 대상으로 서비스를 제공하고 있습니다. 이 글에서는 각 단계의 요구 사항을 충족시키기 위한 시스템의 진화에 대해 탐험합니다.
daily.dev는 계속 발전하는 개발자 생태계와의 소통에서 비롯되었습니다. 매일 새로운 정보가 등장함에 따라 업무는 도전적이고 때로는 힘들었습니다. 그러나 최신 정보를 파악하는 것은 소프트웨어 개발자의 전문성 성장에 있어 중요한 열쇠입니다. 예전에는 많은 RSS 구독과 Twitter 계정이 연결된 Slack 채널을 가지고 있었고, 거의 매일 이를 확인했습니다. 나는 Nimrod (제품, 현재는 daily.dev의 CEO)와 Tsahi (디자인)와 협력하여 개발자들이 최신 정보를 얻을 수 있도록 도움을 주는 도전에 나섰습니다. 요즘에는 daily.dev가 확장되어 개발자들을 위한 전문 네트워크로도 활동하고 있습니다.
사이드 프로젝트 개발은 일상적인 직장에서의 개발과는 매우 다릅니다. 사용 가능한 시간은 제한적일 뿐만 아니라 하루에 2~3시간, 주말이 생산성 간극을 줄이는 전투터전의 시간대로 활용됩니다. 매주 이렇게 많은 시간을 투자하는 것은 현실적으로 어렵습니다. 그래서 효율성이 매우 중요해 집니다. 시간을 현명하게 활용하고, 우선순위를 정하며, 가능한 모든 도구를 활용해야 합니다. 전략은 가능한 한 많은 곳에서 단축하기 위한 결정적인 노력에 달려 있습니다.
초기에는 익숙함을 선택하고 이미 숙련된 기술을 사용하여 효율성을 높였습니다. React를 기반으로 한 애플리케이션은 Node.js와 PostgreSQL을 사용했습니다. API 프로젝트는 Google App Engine을 사용하고, 뉴스 발견 및 콘텐츠 크롤링 파이프라인은 Google Functions을 활용했습니다. Cloud SQL은 PostgreSQL 인스턴스를 프로비저닝하는 데 사용되었습니다. 초기에는 브라우저 익스텐션(확장 프로그램)에 중점을 두었기 때문에 전용 프론트엔드 호스팅 솔루션이 필요하지 않았습니다.
서비스 선택 기준은 "제로 옵스"를 중심으로 했습니다. 이러한 서비스는 유연하지 않지만 마음의 안정감을 제공하며 개발을 가속화하며 종종 넉넉한 무료 티어와 결합됩니다. Superfeedr는 초기 아키텍처에서 중요한 역할을 했습니다. 이는 RSS 구독을 관리하는 서비스로, 모든 새로운 게시물에 웹훅을 트리거합니다. 빠르게 움직이기 위해 우리는 이 서비스에 투자하고 바퀴를 다시 발명하지 않았습니다. 한 달도 채 지나지 않아 daily.dev를 출시하고 Chrome 스토어에 익스텐션(확장 프로그램)을 제출했습니다.
사이드 프로젝트를 만들려면 얻을 수 있는 모든 동기가 필요합니다. 우리에게 동기는 “수익 창출” 이었습니다. 이를 위한 가장 쉬운 방법은 제품에 광고를 도입하는 것이었습니다. 메인 피드가 주요 구성 요소인 우리에게는 빠르게 광고 배치를 추가할 수 있을 것이라고 생각했습니다. 그러나 광고가 사용자 경험에 방해가 되어서는 안 되며, 피드의 일부로 자연스러운 경험을 제공해야 했습니다. 또한, 우리는 신발과 같은 캐주얼 제품을 홍보하고 싶지 않았습니다. 개발자 지향 제품, 클라우드 제공업체, 데이터베이스, 생산성 도구 등을 홍보하고 싶었습니다. 당시에는 BSA(Carbon ads)와 Codefund(현재는 더 이상 존재하지 않음)이 개발자 지향 광고 네트워크의 주요 선수로 존재했습니다. 그들과 협력하여 두 네트워크 간에 전환할 수 있는 작은 광고 서버를 만들었습니다. 우리는 단일 네트워크에 의존하고 싶지 않았습니다. 그리고 그 결정은 옳았습니다. 돈을 벌기 위한 우리의 진정한 동기부여는 프로젝트를 계속 유지하는 데 있었습니다. 월 수백 달러에서 시작하여 세 명 모두가 본업을 그만두고 daily.dev에 풀타임으로 종사할 수 있는 지점까지 점진적으로 확장했습니다.
daily.dev를 사용하는 개발자들이 더 많아지면서, 일부 사용자는 확장 프로그램 만으로는 충분하지 않다는 것을 깨달았습니다. 모바일에서 daily.dev를 사용하려는 사용자나 새로운 탭 경험을 좋아하지 않는 사용자들도 있었습니다. 이것이 우리가 웹앱을 소개한 곳이었습니다. 웹 애플리케이션을 구동하기 위해 우리는 Next.js를 선택했습니다. 프론트엔드를 위한 모노레포를 만들었는데, 이는 세 가지 주요 구성 요소로 이루어져 있습니다. 공유 라이브러리(디자인 시스템, 훅 등 많은 재사용 가능한 요소를 포함), 브라우저 확장 프로그램, 그리고 새롭게 생성된 웹앱이 포함되어 있습니다. 우리는 지금까지도 이 구조를 계속 사용하고 있으며, 이는 확장 프로그램과 웹앱을 손쉽게 동기화할 수 있도록 도와줍니다. Vercel은 원활한 개발 경험과 네이티브 Next.js 지원으로 인해 배포 솔루션으로 선택되었습니다. Vercel 및 GitHub 통합 덕분에 메인 브랜치에 대한 모든 커밋은 프로덕션에 배포되며, 각 PR은 미리보기 배포를 받게 되어 내부 테스트에 매우 유용합니다.
자금이 충분해지면서 나는 엔지니어를 고용하기 시작했습니다. 이는 프로젝트에 있어서 중대한 순간이었습니다. 드디어 단일 풀타임 개발자 이상이 작업하는 시점이 도래했습니다. 나는 프론트엔드 및 API를 구축하는 데 중점을 둔 두 명의 재능 있는 웹 엔지니어를 고용했습니다. 이로써 우리는 인프라 및 심도 있는 백엔드 작업에 시간을 할애할 수 있었습니다. 그 시점에서 나는 더 확장될 것을 알았고, 팀 및 아키텍처를 확장할 기반이 필요했습니다. 이미 주요 API 서비스, 몇 가지 cron 작업 및 클라우드 함수가 있었기 때문에 배포를 최적화하고 더 나은 개발 경험을 제공하기 위해 다음 두 가지를 결정했습니다:
쿠버네티스로 이전 - 앞서 언급했듯이, 우리의 배포는 여러 곳에 흩어져 있었습니다. 구글 클라우드에서 앱 엔진, 클라우드 함수 및 관리되는 cron 작업이 있었으며, 이를 효율적으로 관리하는 것은 어려웠습니다. 쿠버네티스는 컨테이너를 예약하여 API, 백그라운드 워커, cron 작업 및 기타 사용 사례를 지원하는 클라우드에 중립적인 환경을 제공합니다. 여러 플랫폼에 배포를 분산시키지 않고 여러 시스템의 모범 사례를 학습해야 했던 우리에게는 이상적이었습니다. 우리는 이미 많은 기업에서 채택하고 있는 쿠버네티스를 활용했고, 이전하여 매우 만족스러운 결과를 얻었습니다.