▲

월 $20 스택으로 월매출 $10K 회사를 여러 개 운영하는 법

 (stevehanov.ca)
8P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • 단일 VPS, Go 언어, SQLite, 로컬 GPU를 활용해 월 20달러 이하의 인프라 비용으로 MRR 1만 달러 이상의 SaaS 회사를 복수 운영하는 부트스트래핑 전략
  • AWS나 복잡한 클라우드 오케스트레이션 대신 5~10달러짜리 VPS 한 대로 모든 서비스를 운영하며, 인프라 관리가 아닌 요청 처리에 집중
  • 백엔드 언어로 Go를 선택해 의존성 관리 없이 단일 바이너리로 컴파일 후 서버에 배포하는 극도로 단순한 배포 프로세스 확보
  • 로컬 GPU(RTX 3090)에서 VLLM을 실행해 AI 배치 처리 비용을 제로로 만들고, 사용자 대면 기능에만 OpenRouter를 통해 프론티어 모델 사용
  • 벤처 캐피털 없이도 비용을 거의 제로로 유지하면 사실상 무한한 런웨이를 확보할 수 있으며, 제품-시장 적합성을 찾는 데 충분한 시간 확보 가능

린(Lean) 서버 운영 전략

  • 2026년 웹 앱 출시의 일반적 방식은 AWS에서 EKS 클러스터, RDS 인스턴스, NAT Gateway를 프로비저닝하는 것이며, 이 경우 사용자 한 명 없이도 월 300달러 이상 지출 발생
  • 대안으로 Linode 또는 DigitalOcean에서 월 5~10달러짜리 VPS를 임대해 단일 서버로 운영
  • 1GB RAM도 적절히 활용하면 충분하며, 여유가 필요하면 swapfile 사용
  • 서버가 하나이면 로그 위치, 크래시 원인, 재시작 방법을 정확히 파악 가능
  • AWS 대신 VPS를 선택하는 이유는 예측 가능한 비용과 단순한 아키텍처 유지

Go 언어를 선택하는 이유

  • Python이나 Ruby는 인터프리터 부팅과 gunicorn 워커 관리만으로 RAM의 절반을 소모
  • Go는 웹 작업에서 훨씬 뛰어난 성능을 제공하고, 엄격한 타입 시스템을 갖추며, 2026년 기준 LLM이 추론하기 매우 쉬운 언어
  • Go의 핵심 장점은 배포 프로세스의 단순성: 전체 애플리케이션을 단일 정적 링크 바이너리로 컴파일해 노트북에서 빌드 후 scp로 서버에 전송하여 실행
  • pip install 의존성 지옥이나 가상 환경이 불필요하며, 블로팅된 프레임워크 없이도 프로덕션 수준 웹 서버 구현 가능
  • 기본 Go 표준 라이브러리만으로 초당 수만 건의 요청을 처리할 수 있는 서버 작성 가능

로컬 AI 활용: 배치 작업의 비용 제로화

  • 집에 그래픽 카드가 있다면 무제한 AI 크레딧을 이미 보유한 것과 동일
  • eh-trade.ca 구축 시 수천 개 기업의 분기 보고서를 분석하는 대규모 정성적 주식 리서치가 필요했으며, OpenAI API 사용 시 수백 달러가 소요될 수 있었음
  • 대신 Facebook Marketplace에서 900달러에 구매한 RTX 3090(24GB VRAM) 에서 VLLM을 실행해 AI 제공업체에 비용을 지불할 필요 제거
  • 로컬 AI 업그레이드 경로:
    • Ollama로 시작: 한 줄 명령어(ollama run qwen3:32b)로 설정하고 다양한 모델을 즉시 테스트하며 프롬프트 반복에 최적
    • VLLM으로 프로덕션 전환: Ollama는 동시 요청 시 병목이 되며, VLLM은 PagedAttention을 사용해 비약적으로 빠름. 8~16개 비동기 요청을 동시 전송하면 GPU 메모리에서 배치 처리하여 1개 요청 처리 시간과 거의 동일
    • Transformer Lab: 모델 사전 학습이나 파인튜닝이 필요할 때 로컬 하드웨어에서 쉽게 수행 가능
  • 이를 관리하기 위해 자체 개발한 laconic: 8K 컨텍스트 윈도우에 최적화된 에이전트 연구 도구로, OS의 가상 메모리 관리자처럼 대화의 불필요한 부분을 "페이지 아웃"하여 핵심 사실만 활성 LLM 컨텍스트에 유지
  • llmhub: 모든 LLM을 provider/endpoint/apikey 조합으로 추상화하여 텍스트와 이미지 IO를 로컬이든 클라우드든 원활하게 처리하는 도구

OpenRouter를 통한 프론티어 모델 접근

  • 모든 작업을 로컬에서 처리할 수는 없으며, 사용자 대면 저지연 채팅 상호작용에는 Claude 3.5 Sonnet이나 GPT-4o 같은 최첨단 추론 모델이 필요
  • Anthropic, Google, OpenAI 각각의 빌링 계정, API 키, 속도 제한을 관리하는 대신 OpenRouter 하나로 통합
  • OpenAI 호환 통합 코드 하나만 작성하면 모든 주요 프론티어 모델에 즉시 접근 가능
  • 원활한 폴백 라우팅 지원: Anthropic API 장애 시 자동으로 동등한 OpenAI 모델로 전환되어 사용자는 오류 화면을 전혀 보지 않으며 복잡한 재시도 로직 불필요

GitHub Copilot을 활용한 비용 효율적 AI 코딩

  • 새로운 고가 모델이 매주 출시되는 가운데, 개발자들이 Cursor 구독과 Anthropic API 키에 월 수백 달러를 지출
  • 반면 Claude Opus 4.6을 하루 종일 사용해도 월 비용이 60달러를 거의 넘지 않음
  • 비결은 Microsoft의 가격 모델 활용: 2023년에 GitHub Copilot 구독을 구매해 표준 VS Code에 연결
  • Copilot의 핵심 트릭: Microsoft는 토큰 단위가 아닌 요청 단위로 과금하며, "요청"은 채팅 박스에 입력하는 내용 하나. 에이전트가 30분간 전체 코드베이스를 분석하고 수백 개 파일을 변경해도 약 0.04달러만 소요
  • 최적 전략: 엄격한 성공 기준이 포함된 상세한 프롬프트를 작성하고, "모든 오류가 수정될 때까지 계속 진행"이라고 지시한 후 실행하면 됨

SQLite를 모든 데이터베이스로 활용

  • 새로운 벤처를 시작할 때 항상 sqlite3를 메인 데이터베이스로 사용
  • 엔터프라이즈 관점에서는 별도 프로세스의 데이터베이스 서버가 필요하다고 여기지만, 실제로 C 인터페이스나 메모리를 통해 통신하는 로컬 SQLite 파일은 원격 Postgres 서버로 TCP 네트워크 홉을 거치는 것보다 수 자릿수 빠름
  • 동시성 문제에 대한 오해: SQLite가 모든 쓰기에서 전체 데이터베이스를 잠근다는 인식은 잘못된 것이며, Write-Ahead Logging(WAL) 활성화로 해결
    • PRAGMA journal_mode=WAL;과 PRAGMA synchronous=NORMAL; 설정 시 읽기와 쓰기가 서로 차단하지 않음
    • NVMe 드라이브의 단일 .db 파일로 수천 명의 동시 사용자 처리 가능
  • 사용자 인증 구현 편의를 위해 자체 라이브러리 smhanov/auth 개발: 사용 중인 데이터베이스와 직접 통합되며 가입, 세션, 비밀번호 재설정, Google/Facebook/X/SAML 로그인 지원

결론: 복잡한 인프라 없는 스타트업 구축

  • 기술 업계는 실제 비즈니스 구축에 복잡한 오케스트레이션, 대규모 월 AWS 비용, 수백만 달러의 벤처 캐피털이 필요하다고 주장하지만 그렇지 않음
  • 단일 VPS, 정적 컴파일 바이너리, 로컬 GPU 하드웨어를 통한 배치 AI 작업, SQLite의 원시 속도를 결합하면 월 커피 몇 잔 가격으로 확장 가능한 스타트업 부트스트래핑 가능
  • 프로젝트에 무한한 런웨이를 부여해 번 레이트(burn rate) 걱정 대신 사용자 문제 해결에 집중할 시간 확보

함께 보면 좋은 글 β

▲
GN⁺ 4시간전  [-]
Hacker News 의견들

  • 기업 환경에서는 외부 DB 서버를 써야 한다는 인식이 강하지만, 실제로는 로컬 SQLite 파일이 C 인터페이스나 메모리로 통신할 때 원격 Postgres보다 훨씬 빠름
    물론 SQLite는 훌륭하지만, 로컬호스트에서 Unix domain socket으로 Postgres에 연결하면 네트워크 오버헤드를 거의 없앨 수 있음
    SQLite보다 어렵지 않게 쓸 수 있고, Postgres의 모든 기능을 활용할 수 있으며, 리포트 실행이나 read replica 설정, HA 구성도 훨씬 쉬움
    앱과 같은 서버에서 Postgres를 돌리는 건 Kubernetes 클러스터를 세우는 과잉 대비와는 전혀 다른 수준의 선택임

    • 같은 머신에서도 SQLite가 domain socket을 쓰는 Postgres보다 훨씬 빠름 (100,000 TPS 예시)
      단일 머신에서 monolithic app을 돌릴 때 Postgres가 SQLite보다 제공하는 기능은 많지 않음
      SQLite는 Application functions으로 앱 언어로 직접 확장할 수 있고, Litestream 덕분에 백업과 복제도 훨씬 나아짐
      다만 기본 설정이 좋지 않아, 읽기/쓰기 연결을 분리하고 앱이 직접 write queue를 관리해야 함
    • 실제로 100,000번의 SELECT 1 쿼리를 실행하면 Postgres는 2.77초, SQLite(in-memory)는 0.07초로 큰 차이가 남 (벤치마크 링크)
    • 나는 수백만 문서를 초당 처리하는 고성능 시나리오에서 SQLite를 확장 기능과 함께 사용했음
      원격 서버로도 가능했겠지만 훨씬 복잡했을 것임
      대신 DB를 S3에 올려 각 인스턴스가 복사본을 받아 병렬로 처리했음. SQLite는 기능보다 성능이 필요한 경우 검증된 대안임
    • “Postgres의 모든 기능을 쓸 수 있다”는 말이 바로 TFA가 비판하는 YAGNI(You Ain’t Gonna Need It) 접근 아님?
    • 필요하지 않은 기능이 많을수록 오히려 순손실임. 이상적인 DB는 필요한 기능만 제공하는 것임

  • 많은 사람들이 처음부터 serverless, Kubernetes, multi-zone HA 같은 복잡한 구성을 해야 한다고 믿음
    “그냥 저렴한 VPS에서 돌려도 된다”고 하면 “스케일링은?”, “백업은?”, “유지보수는?” 같은 반응이 돌아오는데, 사실상 클라우드 마케팅 문구를 되풀이하는 것임
    이런 태도는 학습된 무력감에 가까움

    • 컨설턴트로 일할 때, 200명도 안 될 사용자용 앱에 25개 클라우드 구성요소를 설계하곤 했음. 모두 ‘클라우드=복잡해야 한다’는 훈련의 결과였음
    • IT 구매 담당자들은 이해하지 않아도 되게 만드는 데 회사 돈을 아낌없이 씀
    • 요즘은 에이전트 기반 워크플로우에서도 같은 현상을 봄. 학습 데이터가 대규모 팀용 코드베이스로 가득해서, 작은 프로젝트도 거대한 구조로 유도됨
      예를 들어 단순한 입력 폼 몇 개짜리 SPA에 Shadcn, Tailwind, React, Zod, Vite까지 다 넣는 식임. 유지보수 부담이 엄청남
      이런 구성은 “정답”일 수는 있어도, 상황에 맞는 답은 아님
    • “클라우드 네이티브 세대”는 무료 플랜 덕분에 기본 앱이 실제로 무엇이 필요한지 배울 기회가 없었음
    • 그래도 백업은 중요하다고 생각함

  • 나는 Linode나 DigitalOcean을 써서 월 5~10달러만 냄. 1GB RAM이면 충분함
    여러 프로젝트를 하나의 전용 서버에 모으면 비용을 더 줄일 수 있음
    예를 들어 Hetzner 서버 경매에서 월 40유로짜리를 쓰는데, Proxmox를 올려 여러 VM을 돌림 (Proxmox 링크)
    VM 15개를 만들어도 VM당 2.66유로 수준이라 규모 대비 비용 효율이 매우 높음
    리퍼비시 장비라면 백업은 필수지만, 어차피 필요한 일임
    Hetzner나 Contabo, Scaleway 같은 곳이 여전히 저렴한 선택지임

    • Hetzner 가격이 오르긴 했지만, OVH가 비슷한 가격에 더 최신 하드웨어를 제공함
    • 왜 VM을 쓰고 컨테이너는 안 쓰는지 궁금함
    • IPv4는 어떻게 처리하는지도 궁금함. 하이퍼바이저로 큰 VM을 빌리는 게 상업적으로 허용되는지도 의문임
    • 그냥 Docker 컨테이너로 돌리는 게 더 효율적이지 않나 싶음

  • SQLite의 WAL 모드가 가장 큰 비용 절감 요소라고 생각함
    Python이나 Node도 Go만큼 잘 쓸 수 있음. Hetzner의 4GB RAM, 10TB 네트워크 VPS가 월 5달러 수준임
    단, 전용 서버를 쓴다면 DB 백업을 자주 해야 하고, 보안도 직접 책임져야 함
    나는 Terraform으로 SSH 접근을 내 IP로만 제한하고, Tailscale을 설정한 뒤 공개 SSH 포트를 닫는 식으로 세팅함

    • 백업은 VM 제공업체와 다른 회사의 스토리지를 쓰는 게 안전함. 계정이 정지돼도 복구 가능해야 함
      나는 Backblaze B2를 쓰지만, Restic으로 다른 서비스에도 쉽게 백업 가능함
    • SSH 보안을 위해 꼭 복잡한 설정이 필요한 건 아님. 강력한 비밀번호만으로도 충분함
    • 예전에 Postgres를 기본 비밀번호로 열어놨다가 하루 만에 봇 서버로 해킹당한 적 있음
      최근에도 SSH 시도 로그가 1시간 만에 쌓였음. 이제는 비밀번호 로그인은 끄고 Tailscale로만 접근함
      인터넷에 노출된 서버는 정말 위험함
    • SSH로 한 시간 만에 감염된다는 건 믿기 어려움. 약한 비밀번호나 VNC를 열어둔 게 아니면 불가능할 듯
    • 나도 Django 사이트를 Docker Compose로 옮기면서 Postgres를 버리고 SQLite WAL로 전환했음. 훨씬 관리와 백업이 간단해짐

  • 1GB RAM 제한은 불필요하다고 생각함. 월 20달러면 8GB RAM을 얻을 수 있고, 캐시나 DB에 활용 가능함
    15달러 차이는 사업 운영에 큰 영향이 없음. 5달러 VPS에 맞추려는 사고는 비즈니스 성장에 도움 안 됨

    • 하지만 15달러도 무시할 돈은 아님. 1GB로 충분하면 굳이 더 쓸 필요 없음
      예전엔 128MB로도 LAMP 스택을 잘 돌렸고, 지금 웹사이트도 복잡하지 않음
    • NVMe 읽기 지연이 100µs 수준이라, SQLite로도 초당 수백 요청을 처리 가능함
      캐시 없이도 1일 1,700만 요청을 감당할 수 있는데, 그 전에 인프라를 4배로 늘리는 건 낭비임
    • 1GB 제한의 진짜 이유는 과공학을 피하고 고객 가치에 집중하는 훈련임
    • 현대 시스템은 페이지 압축과 NVMe 스왑 덕분에 RAM 효율이 훨씬 높음.
      Macbook Neo 8GB 모델이 그 좋은 예임
    • 나도 15달러 차이는 크지 않다고 보지만, 핵심은 호스팅 비용을 최소화하는 데 있음

  • WebSequenceDiagram은 멋진 제품 같음
    하지만 기술 구현보다 어려운 건 가치 있는 문제를 찾고 사용자에게 도달하는 일임. 거기에 진짜 가치가 있음

    • 나도 같은 고민을 함. 일하고 가족과 시간 보내면 하루가 부족함. 그런데 특정 도메인 문제를 알게 되면 해결책이 너무 명확해 보임
    • 경쟁 제품이 이미 많음. 예를 들어 Excalidraw 같은 것들

  • 나는 2023년에 GitHub Copilot을 구독하고 VS Code에 연결한 뒤 계속 사용 중임
    Microsoft가 요청 단위 과금을 한다는 점이 핵심임. 한 번의 요청으로 수십 분간 코드 전체를 수정해도 약 0.04달러만 냄
    그래서 나는 매우 구체적인 프롬프트를 작성하고 “모든 오류가 해결될 때까지 계속하라”고 시킨 뒤 커피를 마심. Satya Nadella가 내 컴퓨팅 비용을 보조하는 셈임

    • 하지만 이런 요청 단위 악용으로 계정이 정지된 사례가 있음 (Reddit 사례)
    • 글쓴이가 GPT‑4o와 Sonnet 3.5를 SOTA라 부르는데, AI 팁은 조금 의심하며 보는 게 좋음
    • (삭제된 댓글) 다운보트 받은 이유를 모르겠다고 함

  • 글에서 새로 배운 건 없었음. 대부분 기초적인 조언을 AI가 포장한 느낌이었음
    제목만 보고 아이디어 발굴과 성공적인 런칭 얘기일 줄 알았음

    • “월 $5 이하로” 같은 제목이면 기본 조언이 나오는 게 당연함. 하지만 의외로 이런 걸 모르는 사람도 많음
    • 그렇다면 블로그를 시작해보라고 권함. 당신이 기본이라 여기는 지식이 누군가에겐 새로움임
    • 나도 월 5천 달러를 써서 1만 달러를 벌 수 있다면 기꺼이 하겠음. 문제는 수익을 만드는 방법을 찾는 것임
    • “Claude 3.5 Sonnet이나 GPT‑4o의 최첨단 추론이 필요하다”는 문장은 AI 글의 흔적임
    • 하지만 글쓴이가 말한 리소스 인플레이션은 실제로 존재함. 단순한 Python 스크립트로 충분한 일을 AWS와 Spark로 과하게 푸는 경우를 자주 봄

  • 혹시 나처럼 궁금한 사람을 위해, MRR은 “Monthly Recurring Revenue(월 반복 수익)”을 뜻함

    • 16년 전에 가입했는데 MRR을 몰랐다는 게 놀라움
    • ARR(Annual Recurring Revenue) 도 있는데, 보통은 MRR을 단순히 12배 해서 부풀린 숫자임.
      두 달 운영하고 ARR을 발표하는 사람도 봤음

  • 클라우드 중심 사고가 많은 경우 복잡성과 비용을 불필요하게 증가시킴
    중간 규모의 VPS로도 충분한 프로젝트가 대부분임
    우리 회사는 60만 사용자 페이지를 30유로 VPS로 돌릴 수 있었는데, AWS로 옮기고 월 800유로를 냄. 이득은 전혀 없음
    이유가 없다면 수십 년간 잘 작동해온 단순한 서버 방식을 유지하는 게 좋음
    참고로 StackOverflow도 강력한 루트 서버 몇 대로 운영된다고 들었음

답변달기