# 월 $20 스택으로 월매출 $10K 회사를 여러 개 운영하는 법 > Clean Markdown view of GeekNews topic #28457. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28457](https://news.hada.io/topic?id=28457) - GeekNews Markdown: [https://news.hada.io/topic/28457.md](https://news.hada.io/topic/28457.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-13T09:41:07+09:00 - Updated: 2026-04-13T09:41:07+09:00 - Original source: [stevehanov.ca](https://stevehanov.ca/blog/how-i-run-multiple-10k-mrr-companies-on-a-20month-tech-stack) - Points: 64 - Comments: 1 ## Summary VPS 한 대, Go 단일 바이너리, SQLite, 로컬 GPU라는 **극한의 린 스택**으로 MRR $10K 사업을 여러 개 돌리는 부트스트래퍼의 운영기입니다. AWS에 월 300달러 쓰기 전에 5달러짜리 VPS로 시작하라는 메시지인데, 특히 RTX 3090에서 **VLLM을 돌려 AI 배치 처리 비용을 제로로 만드는 부분**이 요즘 로컬 AI 흐름과 맞물려 실용적입니다. VC 없이 런웨이를 무한히 늘리는 전략이 궁금한 1인 개발자, 사이드 프로젝트 운영자라면 꼭 읽어보시길 권합니다. ## Topic Body - 단일 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) 걱정 대신 사용자 문제 해결에 집중할 시간 확보 ## Comments ### Comment 55166 - Author: neo - Created: 2026-04-13T09:41:08+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47736555) - 기업 환경에서는 **외부 DB 서버**를 써야 한다는 인식이 강하지만, 실제로는 로컬 SQLite 파일이 C 인터페이스나 메모리로 통신할 때 원격 Postgres보다 훨씬 빠름 물론 SQLite는 훌륭하지만, 로컬호스트에서 **Unix domain socket**으로 Postgres에 연결하면 네트워크 오버헤드를 거의 없앨 수 있음 SQLite보다 어렵지 않게 쓸 수 있고, Postgres의 모든 기능을 활용할 수 있으며, 리포트 실행이나 **read replica** 설정, HA 구성도 훨씬 쉬움 앱과 같은 서버에서 Postgres를 돌리는 건 Kubernetes 클러스터를 세우는 과잉 대비와는 전혀 다른 수준의 선택임 - 같은 머신에서도 SQLite가 domain socket을 쓰는 Postgres보다 훨씬 빠름 ([100,000 TPS 예시](https://andersmurphy.com/2025/12/02/100000-tps-over-a-billio...)) 단일 머신에서 **monolithic app**을 돌릴 때 Postgres가 SQLite보다 제공하는 기능은 많지 않음 SQLite는 [Application functions](https://sqlite.org/appfunc.html)으로 앱 언어로 직접 확장할 수 있고, [Litestream](https://litestream.io/) 덕분에 백업과 복제도 훨씬 나아짐 다만 기본 설정이 좋지 않아, 읽기/쓰기 연결을 분리하고 앱이 직접 **write queue**를 관리해야 함 - 실제로 100,000번의 `SELECT 1` 쿼리를 실행하면 Postgres는 2.77초, SQLite(in-memory)는 0.07초로 큰 차이가 남 ([벤치마크 링크](https://gist.github.com/leifkb/1ad16a741fd061216f074aedf1eca...)) - 나는 수백만 문서를 초당 처리하는 **고성능 시나리오**에서 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 서버 경매](https://www.hetzner.com/sb/)에서 월 40유로짜리를 쓰는데, Proxmox를 올려 여러 VM을 돌림 ([Proxmox 링크](https://www.proxmox.com/en/)) 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 사례](https://old.reddit.com/r/GithubCopilot/comments/1r0wimi/if_y...)) - 글쓴이가 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도 **강력한 루트 서버** 몇 대로 운영된다고 들었음