▲

The One-Person Framework 실전 적용기

 (bramjetten.dev)
15P by GN⁺ 7시간전 | ★ favorite | 댓글 2개
  • 혼자서 Rails로 전체 서비스를 개발하고 유지보수하며, 연 100만유로 ARR(반복 매출) 을 달성한 1인 개발자의 실전 경험기
  • 초기에는 기초적인 MVP만 가지고 시작했으나, 풀 리라이트와 구조 개선을 거쳐 유지 가능한 구조로 성장시킴
  • 핵심은 Rails의 일관된 철학, 구성요소, 그리고 Turbo Native를 통한 모바일 대응 능력임
  • 전체 트래픽과 사용량을 감당하면서도 월 1,500유로 이하 서버비용으로 운영할 수 있었던 효율적 구조
  • 최종적으로는 장기지향적 투자자에게 일부 지분을 매각하고, 14년 만에 두 번째 개발자를 채용하여 새로운 국면을 맞이함

The One-Person Framework 실전 적용기

Rails 하나로 100만 유로 ARR 달성

  • 2022년 초, PlanGo는 연간 반복 매출(ARR) 100만 유로를 돌파했으며, 이는 단일 Rails 코드베이스와 한 명의 개발자로 이루어진 서비스에겐 꿈 같은 성취였음
  • 기술 이외의 모든 영역—비전 수립, 고객 유치, 성장 전략—은 공동창업자와 고객지원팀이 맡았지만, 아키텍처 설계부터 배포, 운영, 프론트/백엔드 구현까지 전부 혼자 수행
  • DHH가 주장한 “One Person Framework”, 즉 한 명의 개발자가 전 애플리케이션을 관리할 수 있는 구조가 이론이 아닌 현실로 입증됨
  • Rails의 구조적 철학—데이터베이스 설계, 비즈니스 로직, 프론트엔드 UI까지 일관된 도구 안에서 수행 가능—은 소규모 또는 1인 창업자에게 특히 유리
  • 이 글은 다음과 같은 사람들을 위해 작성됨:
    • Rails 개발자: 요즘에도 혼자서 큰 제품을 만들 수 있는지 고민하는 사람
    • 기술 창업자: 여러 역할을 떠맡고 과중함을 느끼는 사람
    • 장인 정신과 기술 선택을 중요시하는 사람

시작 당시 상황

  • 글쓴이는 2011년, 21세의 개발자로서 기존에 PHP(CodeIgniter) 프로젝트를 하던 중, Rails에 입문
  • 큰 전략은 없었고, 트렌드를 따라 Rails를 써보고 싶다는 단순한 동기에서 시작
  • 공동창업자의 마케팅 아이디어로 런칭 주간 가입자는 1년 무료 제공이라는 오퍼 전략 실행
    • 수십 명 수준을 예상했지만, 실제로는 첫 주에 500명 이상 가입
    • MVP 수준의 제품이었기 때문에, 곧바로 수백 명의 기능 요청, 질문, 지원 요청이 쇄도함
  • 서버는 잘 돌아갔지만, 제품이 완성되지 않은 상태에서 고객 요구가 폭주
  • 두 공동창업자 모두 본업이 있었기 때문에 풀타임 대응이 불가능
    • 그 결과, 많은 초기 사용자들을 실망시킬 수밖에 없는 상황이 발생함
    • 이 경험을 통해 “소프트웨어 개발”과 “소프트웨어 비즈니스 운영”은 완전히 다른 문제임을 절감
  • 기능 구현만으로는 부족하며, 지속가능한 고객 응대, 기대 관리, 서비스 운영 체계가 필요하다는 교훈 획득

만들면서 배우기

  • Rails 튜토리얼과 Stack Overflow를 참고해 개발을 시작했지만, 생산 환경에서 실제 고객 비즈니스를 책임지는 애플리케이션 구축은 전혀 다른 차원의 일이었음
  • 초창기 Rails 코드에는 다음과 같은 전형적인 초보 실수가 포함되어 있었음:
    • 200줄 이상짜리 컨트롤러 메서드
    • 역할이 뒤섞인 거대한 모델
    • 비효율적인 SQL 쿼리
    • 테스트 코드 없음
    • Git에 커밋된 설정값 및 시크릿 키
  • 기능 구현은 가능했지만, 전체 애플리케이션은 임시방편 코드와 불안정한 구조에 의존한 상태였음
  • 사용자 인증, 파일 업로드, PDF 생성, 관리자 UI, 이메일 처리 등 다양한 기능은 Gem에 의존하여 빠르게 구현했지만, 시간이 지나며 각 Gem이 새로운 복잡성과 문제를 유발함
  • .round(2) 사용 시 기대와 다르게 "banker's rounding"이 적용되어 금액 계산 오류 발생
    • 단순한 계산도 외부 Gem에 맡긴 결과, 숫자 처리의 본질적인 이해 부족으로 문제 발생
  • 2013년 무렵, 제품 운영 경험이 쌓이면서 동시에 기술 부채가 빠르게 증가, 새로운 기능 개발이 점점 어려워짐

전면 재작성

  • 전체 재작성(Full Rewrite)는 일반적으로 위험하고 비효율적인 선택으로 간주되지만, 2014년 Rails 4 기반으로 아예 처음부터 새롭게 구축하기로 결정
  • 기존 애플리케이션을 유지하면서 동시에 새 코드베이스를 개발하는 집중 작업을 수개월 동안 병행
  • 아키텍처를 단순화하고, Gem 의존성을 절반 이하로 줄이며, 핵심 기능에 테스트 도입
  • 새로운 구조는 이전보다 간결하고 빠르며, 특히 파트타임 1인 개발자가 유지보수 가능한 수준으로 설계됨
  • 이 리라이트는 이후 10년 넘게 단독 개발자가 운영 가능한 기술 기반이 되어줌

Rails는 초능력임

  • PlanGo는 2025년까지 단 한 명의 개발자에 의해 운영되었으며, 그 가능성을 만들어준 핵심 이유는 Rails였음
  • Convention over Configuration, 통합 테스트, ActiveRecord, ActiveStorage, ActiveJob 등 Rails의 구조적 특징 덕분에 비본질적인 의사결정을 최소화하고 핵심 가치 창출에 집중할 수 있었음
  • Turbolinks, Hotwire 도입 이후에는 복잡한 JS 프레임워크 없이도 현대적 UI 구현이 가능했음
  • 2011년 개발 초기에는 모바일 앱 수요가 거의 없었지만, 이후에는 iOS/Android 앱이 PlanGo의 주된 인터페이스로 자리잡음
  • Titanium, RubyMotion, Objective-C 등 여러 프레임워크를 시도하며 품질과 속도 사이의 균형 문제를 겪음
  • Turbo Native 도입 이후 생산성이 급격히 향상되었으며, 기초적인 네이티브 개발 지식만으로도 Rails 코드베이스를 활용한 고품질 앱 구현이 가능해짐
  • 이 방식은 특히 B2B나 SaaS 앱에서 이상적인 접근법으로, 네이티브 성능과 경험을 소규모 개발 비용으로 달성할 수 있음
  • 결과적으로 연간 10만 회 이상의 앱 다운로드, 일시적으로 네덜란드 앱스토어에서 Duolingo보다 상위 기록도 달성
  • 모든 앱은 하나의 Rails 개발자에 의해 개발 및 유지됨
  • 주요 지표:
    • Ruby 코드: 36,170줄
    • JavaScript 코드: 13,495줄
    • 테스트 커버리지: 40%
    • 일일 활성 사용자: 6,332명
    • 피크 시간 분당 요청 수: 7,000건
    • 월 서버 운영비: €1,500 미만
  • 구조화된 모놀리식 아키텍처를 유지한 것은 최고의 선택 중 하나였으며, 마이크로서비스 복잡성 없이 Capistrano로 간편 배포, 디버깅까지 용이
  • 기술 창업자에게 Rails는 단순한 프레임워크가 아닌, 한 사람이 팀 전체의 일을 해낼 수 있게 해주는 슈퍼파워

1백만 유로를 넘어서

  • 2022년 말, 예상치 못한 전환점이 찾아옴. 해외 투자자가 PlanGo에 관심을 보이며 인수 제안을 전달
  • 당시 PlanGo는 부트스트랩 방식으로 €1M ARR을 넘긴 상태였으며, 외부 자금 없이도 지속 가능한 수익 구조와 효율적인 운영을 유지 중이었음
  • 이 제안은 팀 내부에 "우리는 앞으로 무엇을 원하는가?" 라는 질문을 던지는 계기가 됨
  • 기존 방식대로 유지할지, 외부 자금으로 스케일업할지, 완전히 매각할지 등 다양한 가능성을 탐색함
  • 사업에 대한 애정은 여전히 깊었지만, 더 많은 리소스와 전문성을 확보하면 더 쉽게 기회를 실행에 옮길 수 있다는 인식이 생김
  • 수익 실현 측면에서도, 10년 넘게 쌓은 가치 중 일부를 회수하면서도 사업을 계속 성장시킨다는 선택지는 합리적이었음
  • 최종적으로 선택한 방식은, 가치와 장기적 방향성이 잘 맞는 네덜란드의 에버그린 펀드와의 파트너십 체결
    • 일부 지분을 매각하고, 경영권과 다수 지분은 유지
    • 추가 리소스를 확보하면서도 기존 구조와 문화를 해치지 않는 형태
  • 이 결정은 단기적 엑싯이나 공격적 확장이 아닌, 지속 가능하고 고객 중심의 비즈니스를 기반으로 한 안정적 성장 전략의 일환임
  • 이후에도 Rails 기반의 접근 방식은 그대로 유지하면서, 기존에는 시도하기 어려웠던 기회를 보다 적극적으로 추구하는 새로운 국면에 진입함

배운 것들

  • PlanGo를 14년 동안 1인 기술 창업자로 운영하며 얻은 교훈은 다음과 같음
  • Embrace Rails conventions
    • Rails의 철학과 규칙을 거스르려 하지 않는 것이 중요함
    • “Rails Way”는 이미 검증된 문제 해결법이며, 이를 따를수록 제품 고유의 가치에 집중할 수 있음
  • Less is more
    • Gem이나 JS 라이브러리는 기능을 빠르게 구현할 수 있지만, 동시에 복잡성과 고장 가능성도 증가시킴
    • 새로운 의존성을 추가하기 전에는 반드시 "이게 정말 필요한가?"를 스스로에게 질문해야 함
  • Find a community
    • 솔로 개발자는 다른 Rails 개발자들과의 연결이 매우 중요함
    • 예시로, Spina CMS를 만들면서 얻은 커뮤니티는 직장 동료는 아니지만 지식 공유와 피드백을 위한 소중한 연결고리가 되어줌
  • Technical debt isn't always bad
    • 빠르게 시장에 진입하기 위한 실용적인 선택이 기술적 완벽함보다 나을 때도 있음
    • 기술 부채는 의식적으로 감수할 시점과 갚을 시점을 구분하는 것이 핵심
  • You can go far alone
    • Rails를 활용하면 한 명의 개발자도 팀 전체 규모의 제품을 설계, 확장, 배포할 수 있음
    • “팀이 꼭 있어야 한다”는 일반적인 통념에 얽매일 필요 없음

앞으로

  • 신규 투자 파트너는 PlanGo의 슬림한 운영 방식에 동의하면서도 단 하나의 조건을 제시함: Rails 개발자 한 명 추가
  • 문제는 1인 개발을 고집한 것이 아니라, 14년에 걸쳐 발전해온 코드베이스에 새로운 개발자를 온보딩하는 과정 자체의 난이도에 있었음
  • 코드베이스는 PlanGo의 진화일 뿐 아니라, 초보에서 숙련자로 성장해온 개인의 개발 히스토리가 고스란히 담긴 구조였고,
    서로 다른 시기의 나 자신이 만든 다양한 판단과 코드 스타일이 혼재되어 있었음
  • Rails World(캐나다)에서 만난 두 번째 Rails 개발자를 채용하면서 구조적인 변화와 긍정적인 영향이 생김
    • 단일 장애 지점이었던 기술 리스크 해소
    • 새로운 시각과 아이디어 유입
    • 페어 프로그래밍을 통한 코드 품질 향상
    • 같은 언어를 공유하는 동료 개발자와의 협업이 주는 지적 자극
  • 향후에도 대규모 개발팀을 구성할 계획은 없음
  • 지금까지 증명된 것처럼, Rails 기반 접근만으로도 작지만 강력한 팀이 의미 있는 소프트웨어를 만들 수 있음
  • 다만, 가장 효율적인 1인 개발자조차 좋은 팀원을 통해 더 성장할 수 있음을 체감
  • PlanGo의 여정은 Rails의 One-Person Framework가 실제로 작동함을 보여주는 사례이며,
    적절한 도구를 가진 작은 팀이 스스로의 기준으로 진지한 비즈니스를 구축할 수 있다는 증거
  • 첫 제품을 만드는 1인 개발자든, 기술 스택을 고민하는 소규모 팀이든, 이 이야기가 Rails를 최대한 활용했을 때 가능한 가능성을 보여주길 바람
▲
xguru 4시간전  [-]

이 내용을 NotebookLM 오디오 오버뷰로 팟캐스트를 만들어봤습니다.

https://notebooklm.google.com/notebook/…

이 정도면 훌륭하네요. 더 다듬어봐야 겠어요.

답변달기
▲
GN⁺ 7시간전  [-]
Hacker News 의견

  • Django와 유사한 경험을 가진 사용자가 자신의 앱을 운영 중임

    • 가장 큰 앱은 중형 기업의 ERP와 비슷하며, 다양한 권한 수준을 포함함
    • 한 달 만에 대부분의 기능을 프로덕션에 올렸으며, 이는 일반적으로 팀이 2년 걸리는 작업임
    • 월간 페이지 뷰는 1-2백만이며, 서버 부하를 줄이기 위해 정적 HTML과 Cloudflare를 사용 중임
    • 가능한 한 간단하게 유지하며, REST/프론트엔드 프레임워크를 피하고 Bootstrap 기반의 HTML 폼을 사용함
    • 필요할 때만 JavaScript를 사용하며, 현재는 AlpineJS/HTMX를 사용 중임

  • 프레임워크보다 사람이 더 중요하다고 주장하는 사용자가 있음

    • 자신의 개발 스타일에 맞춘 프레임워크를 작성하여 시간과 비용을 절약함
    • 일반화된 프레임워크는 팀 환경에서 유용하지만, 개인 개발자 환경에서는 중요하지 않다고 생각함

  • Rails와 Phoenix를 사용한 경험을 공유하는 사용자가 있음

    • 전통적인 웹 앱을 구축할 때 유용하며, Postgres와 비슷한 선택임
    • 현재는 Clojure를 사용 중이며, 서버 측 도메인과 API 호출에 집중하고 있음

  • Rails 7+가 솔로 개발자에게도 야심 찬 앱을 구축하는 데 도움을 준다는 발표를 한 사용자가 있음

  • 새로운 파트너가 Rails 개발자를 추가하길 원했던 경험을 공유하는 사용자가 있음

    • 코드베이스는 개발자의 성장 과정을 반영하며, 다양한 경험 수준의 결정이 포함됨
    • 다른 회사에서 경험이 부족한 개발자가 시작한 코드베이스를 접한 경험을 공유함

  • AdonisJS를 사용하여 앱을 구축 중인 사용자가 있음

    • Rails와 Adonis, Fiber를 비교한 후 Adonis를 선택함
    • 튜토리얼 비디오와 문서가 훌륭하며, LLMs가 구버전에서 혼란스러울 수 있음을 언급함

  • Rails가 Django보다 나은 점이 많다고 생각하는 사용자가 있음

    • Hotwire, SOLID 캐시/큐, 터보 네이티브 등을 언급함
    • 그러나 여전히 Python 생태계를 선호함

  • Rails를 사용하여 앱을 구축 중인 솔로 개발자가 있음

    • Hotwire Native를 사용하여 모바일 앱도 개발 중임
    • Rails 생태계가 모든 것을 처리할 수 있어 놀랍다고 언급함

  • 전체 재작성은 피해야 한다고 주장하는 사용자가 있음

    • 재작성은 몇 달간의 집중적인 작업이었으며, 기존 앱을 유지하면서 대체 앱을 구축함
    • 작은 앱일 경우 재작성보다 리팩토링이 더 나을 수 있음

  • 프레임워크가 그리 중요하지 않다고 생각하는 사용자가 있음

    • 인기 있는 것을 선택하면 충분한 도움이 있을 것이라고 언급함
    • Laravel을 11년간 사용 중이며, 비즈니스 측면이 더 어렵다고 생각함
답변달기