월 20달러 스택으로 SaaS를 굴릴 수 있을까 2026 — VPS·Go·SQLite·로컬 GPU 운영 기준

Posted on by

사이드프로젝트 운영비를 계산하다 보면 이상한 순간이 온다.

기능보다 먼저 클라우드 청구서가 눈에 들어온다.

사용자는 아직 많지 않은데 VPC, managed DB, NAT, 관측성, AI API 비용이 조용히 쌓인다.

그때 사람은 보통 둘 중 하나를 택한다.

하나는 나중에 최적화하자 고 넘기는 쪽이고,

다른 하나는 애초에 너무 많이 깔았다 고 의심하는 쪽이다.

2026년 3월 Steve Hanov가 쓴 How I run multiple $10K MRR companies on a $20/month tech stack 는 두 번째 쪽에 훨씬 가깝다.

핵심은 화려하지 않다.

  • 단일 VPS
  • Go 단일 바이너리 배포
  • SQLite WAL
  • 배치용 로컬 GPU
  • 실시간 프런티어 모델은 OpenRouter

이 조합으로 복잡한 엔터프라이즈 기본값을 걷어내고 런웨이와 실험 속도를 늘리자는 이야기다.

이런 글은 쉽게 두 부류의 반응을 부른다.

한쪽은 맞지, AWS 너무 과해 라고 하고,

다른 한쪽은 그건 혼자 하는 특수 케이스지 라고 한다.

솔직히 둘 다 맞는 말이다.

중요한 건 그 조합을 그대로 베끼느냐가 아니라, 어떤 팀과 워크로드에선 이 논리가 유효하고 어디서부터 바로 무너지기 시작하느냐를 구분하는 일이다.

이 글은 Steve Hanov의 글을 그대로 찬양하기보다, 내가 지금 보는 AI 도구 운영 관점에서 이 스택이 맞는 구간과 위험 구간을 나눠보는 메모다.

먼저 결론부터는 아니고, 먼저 판단부터 적자

월 20달러 스택은 “모두가 당장 이렇게 옮겨야 한다”는 처방전이 아니다.

대신 초기 SaaS, 1인 운영, 낮은 동시성, 명확한 장애 복구 루프, AI 배치 작업 비중이 큰 팀이라면 생각보다 꽤 현실적인 선택지다.

반대로 다인 개발 조직, 24시간 온콜, 엄격한 규정 준수, 고가용성 약속, 복잡한 팀 인수인계, 실시간 multi-tenant 부하가 중요한 서비스라면 이 스택은 효율보다 리스크가 더 빨리 커질 수 있다.

한 줄로 줄이면 이거다.

이 글의 핵심은 월 20달러가 아니라 복잡도를 줄이는 순서다.

돈이 적게 드는 이유는 도구가 싸서가 아니라, 운영 구조가 얇기 때문이다.

이 글이 유효한 이유는 “비용”보다 “복잡도”를 건드리기 때문이다

Steve Hanov 글에서 제일 중요한 문장은 사실 숫자가 아니다.

그는 복잡한 엔터프라이즈 기본 구성을 초기 제품엔 과하다고 본다.

여기서 진짜 포인트는 단순히 클라우드 혐오가 아니다.

운영비는 결국 청구서 숫자와 운영 복잡도가 같이 만든다는 감각이다.

이건 꽤 공감이 간다.

AI 툴링이나 자동화도 비슷하다.

모델 비용만 비싼 게 아니라, 관측성, 재시도, 승인 흐름, 리뷰 비용, 장애 분석 비용이 같이 올라간다.

그래서 월 20달러 스택을 그냥 인프라 절약술로 보면 반쪽이다.

이건 어디까지는 얇게 가도 되고 어디서부터 두꺼워져야 하는가 를 묻는 운영 글에 더 가깝다.

Steve Hanov 글에서 실제로 제안한 구조

2026-04-14에 다시 확인한 그의 글 흐름은 대략 이렇다.

1. lean server

비싼 클라우드 기본 세트 대신 월 5달러에서 10달러 정도의 단일 VPS를 쓴다.

핵심 메시지는 인프라 관리보다 요청 처리와 장애 원인 추적에 집중하라는 쪽이다.

2. lean language

메인 백엔드는 Go를 택한다.

이유는 상대적으로 가벼운 메모리 사용, 정적 타입, 단일 바이너리 배포, LLM이 코드 구조를 이해하기 쉬운 점을 든다.

3. local AI for long-running tasks

대규모 배치나 반복 추론은 OpenAI API 같은 외부 호출만으로 다 처리하지 않고, 로컬 GPU와 VLLM 쪽을 본다.

그의 예시에선 중고로 구한 RTX 3090과 VLLM이 나온다.

4. fast/smart model은 OpenRouter

모든 것을 로컬로 하지 않고, 실시간 사용자 경험이나 최신 추론이 필요한 구간은 OpenRouter처럼 모델 라우팅 계층을 쓴다.

5. SQLite for everything

초기 DB는 out-of-process 서버보다 SQLite로 간다.

동시성 문제는 WAL 모드로 완화한다는 쪽이다.

이 다섯 개는 각각 독립적인 기술 선택처럼 보이지만, 사실 하나의 원칙을 공유한다.

초기 단계에서는 운영 경로를 짧게 만들어라

왜 이 논리가 지금도 먹히냐

2026년이라고 해서 초기 제품의 현실이 갑자기 달라지진 않았다.

여전히 많은 서비스는 사용자보다 인프라가 먼저 커진다.

그리고 AI 기능이 붙으면서 이 현상은 더 심해졌다.

기본값으로는 보통 이렇게 간다.

  • managed vector DB
  • 별도 워커 큐
  • 프런티어 모델 API
  • observability stack
  • auth provider
  • managed relational DB
  • container orchestration

이 구성 자체가 틀렸다는 게 아니다.

문제는 PMF 전 단계나 1인 운영 제품에선 이 조합이 너무 일찍 무거워지는 경우가 많다는 거다.

월 20달러 스택 논리가 먹히는 이유는 바로 이 “너무 일찍 무거워짐”을 찌르기 때문이다.

단일 VPS는 언제 진짜 강하고 언제 위험해지나

단일 VPS의 장점은 단순성이다.

로그 위치가 명확하고, 재시작 지점이 선명하고, 네트워크 구성이 짧다.

작은 제품을 초반에 굴릴 때 이 단순성은 꽤 큰 무기다.

특히 다음 같은 상황에 잘 맞는다.

  • 하루 트래픽이 아직 제한적이다
  • 운영자가 한 명이거나 아주 소수다
  • 장애가 나도 서비스 성격상 치명적이지 않다
  • 데이터 크기가 아직 작다
  • 배포 속도가 중요하다

반면 단일 VPS가 위험해지는 구간도 분명하다.

  • 단일 장애 지점이 바로 비즈니스 리스크가 된다
  • 팀원이 늘어 인수인계가 필요하다
  • 네트워크 보안 요구사항이 복잡하다
  • 고객사 대응 문서가 필요하다
  • 복구 시간 목표가 짧다

즉, 단일 VPS는 구식이라서 위험한 게 아니라, 요구사항이 커졌는데도 계속 단일 VPS에 머물면 위험해지는 거다.

Go 단일 바이너리 배포가 주는 진짜 이점

Steve Hanov 글에서 Go는 단순히 “빠른 언어”로만 등장하지 않는다.

운영 측면의 이점이 더 크다.

  • 배포물이 단순하다
  • 런타임 의존성 관리가 상대적으로 적다
  • 작은 서버에서 메모리 부담을 줄이기 쉽다
  • LLM이 코드 구조를 읽고 수정하기 쉬운 편이다

이 마지막 포인트가 재밌다.

2026년엔 언어 선택이 사람 생산성만이 아니라 에이전트 생산성과도 연결되기 시작했다.

정적 타입, 단일 바이너리, 단순한 배포 구조는 코드 유지보수뿐 아니라 AI에게 설명하기도 편하다.

그렇다고 무조건 Go가 답이라는 뜻은 아니다.

이미 Python 생태계 위에서 ML, 데이터, 배치 작업이 굵게 돌아가는 팀이라면 메인 서비스 언어를 갈아엎는 게 더 비쌀 수 있다.

핵심은 언어명이 아니다.

배포 경로가 짧아지는가 가 핵심이다.

SQLite WAL은 생각보다 중요한 운영 힌트다

사람들이 이 글에서 가장 먼저 싸우는 포인트가 보통 SQLite다.

요즘 세상에 SQLite?

이 반응이 바로 나온다.

근데 공식 SQLite WAL 문서를 보면 핵심은 꽤 실용적이다.

WAL 모드에서는 reader와 writer의 충돌 특성이 기본 모드와 달라지고, 읽기와 쓰기를 더 유연하게 분리할 수 있다.

Steve Hanov 글도 바로 이 지점을 활용한다.

초기 서비스에서 네트워크 hop이 있는 별도 DB 서버보다 로컬 파일 DB가 더 단순하고 빠를 수 있다는 논리다.

이건 실제로 맞는 구간이 있다.

  • 데이터 크기가 아직 작다
  • 쓰기 패턴이 통제 가능하다
  • 팀이 복구 절차를 이해하고 있다
  • 백업/스냅샷 루프를 별도로 가져간다

하지만 여기서도 흔한 오해가 있다.

SQLite WAL이 된다고 해서 모든 서비스가 영원히 SQLite로 가도 된다는 뜻은 아니다.

초기 운영 단순화에 좋다는 얘기지, 모든 스케일 문제를 마법처럼 없애준다는 뜻은 아니다.

특히 팀 규모와 요구사항이 커질수록 DB 선택은 기술보다 조직 문제로 바뀐다.

로컬 GPU 전략은 어디까지 현실적일까

이 부분이 AI 시대엔 제일 재밌다.

그의 글은 배치형 추론과 실시간 사용자 경험을 분리한다.

장시간 돌리는 반복 작업은 로컬 GPU와 VLLM으로 돌리고,

실시간 저지연이 필요한 사용자-facing 구간은 OpenRouter로 프런티어 모델을 부른다.

이 분리는 꽤 실전적이다.

왜냐면 AI 비용이 커지는 지점이 항상 같은 게 아니기 때문이다.

보통은 두 군데에서 커진다.

  • 대량 배치 요약/분석
  • 실시간 추론과 fallback

로컬 GPU 전략은 첫 번째에 강하다.

특히 동일한 패턴의 작업을 반복적으로 오래 돌릴수록 가성비가 좋아질 수 있다.

반면 약한 구간도 분명하다.

  • 초기 하드웨어 투자
  • 드라이버와 운영 부담
  • 멀티 모델 관리
  • 팀 내 GPU 운영 지식 필요
  • 실시간 SLA 보장은 별도 문제

그래서 내 기준은 이렇다.

배치면 로컬 GPU 검토

실시간이면 클라우드 API 우선

둘 다 크면 하이브리드

이 판단은 오프라인 LLM은 언제 클라우드 대신 쓸 수 있을까 2026 — Google AI Edge Gallery가 보여준 경계선 글과도 연결된다.

로컬이 무조건 답이 아니라, 경계선이 있다는 점 말이다.

지금 내 워크플로에 대입하면 어디까지 빌릴 것 같나

이 글을 읽으면서 내가 바로 메모한 건 “전부 베끼기”보다 “어떤 원칙만 가져올까” 였다.

지금 내가 굴리는 로컬 워크플로도 이미 꽤 많은 부분이 얇은 구조에서 이득을 본다.

  • 로컬 파일 기반 노트와 문서가 많다
  • 배치성 변환과 요약 작업이 꽤 많다
  • 실시간 사용자 트래픽보다 내부 운영 작업 비중이 크다
  • 복잡한 쿠버네티스보다 경로가 짧은 자동화가 더 잘 맞는다

이런 흐름에서는 Steve Hanov식 사고방식이 꽤 잘 통한다.

특히 내가 바로 가져가고 싶은 원칙은 세 가지다.

첫째, 배치와 실시간을 같은 비용 구조로 보지 않는 것.

둘째, 인프라 계층을 선구매하지 않는 것.

셋째, 운영자가 직접 설명할 수 있는 복잡도까지만 허용하는 것.

반대로 지금 당장 그대로 가져오진 않을 부분도 있다.

예를 들면 공용 서비스 트래픽, 팀 단위 인수인계, 장기 감사 로그, 고가용성 요구가 붙는 순간엔 얇은 구조의 장점보다 조직 리스크가 더 빨리 커질 수 있다.

그래서 내 해석은 이렇다.

월 20달러 스택은 복제할 아키텍처라기보다, 과하게 두꺼워진 기본값을 의심하게 만드는 질문지에 가깝다.

OpenRouter 같은 라우팅 계층이 왜 같이 나오는가

Steve Hanov가 모든 걸 로컬로 처리하자고 말하지 않는 점도 중요하다.

그는 최신 모델 접근, provider fallback, 단일 통합 인터페이스가 필요한 구간에 라우팅 계층을 둔다.

이게 중요한 이유는 현실적으로 많은 제품이 두 세계를 동시에 쓰기 때문이다.

  • 내부 배치 작업은 싸고 느려도 된다
  • 사용자-facing 기능은 비싸도 빨라야 한다

이 둘을 같은 비용 모델로 보면 운영 판단이 꼬인다.

그래서 하이브리드가 필요하다.

다만 하이브리드도 공짜는 아니다.

  • fallback 정책을 직접 봐야 한다
  • 로그와 비용 추적이 필요하다
  • 어떤 작업이 어느 모델 계층으로 가는지 규칙이 필요하다

즉, 하이브리드는 똑똑한 기본값이지만 운영 규칙 없이는 새 복잡도일 뿐이다.

이 스택이 특히 잘 맞는 팀

나는 이 조합이 다음 조건에서 꽤 설득력 있다고 본다.

1. 1인 또는 극소수 팀

owner가 명확할수록 얇은 스택은 강하다.

설정 기억도, 배포 루프도, 복구도 한 사람 머릿속과 문서로 이어지기 때문이다.

2. PMF 전 단계 또는 낮은 동시성 제품

이때 제일 중요한 건 기능 실험 속도와 고정비 절감이다.

아직 사용자보다 실험이 많다면 복잡한 managed stack이 과할 수 있다.

3. 문서 분석, 요약, 연구, 배치형 AI 작업이 많은 제품

실시간보다 배치 비중이 높으면 로컬 GPU의 의미가 커진다.

4. 운영 복구가 단순한 제품

서버가 하나여도 복구 절차를 이해하고 있고 데이터 백업 루프가 명확하면 초기엔 꽤 강하다.

5. 비용 민감도가 높은 부트스트랩 제품

투자금보다 런웨이가 더 중요할 때, 작은 고정비는 진짜 무기다.

반대로 이 스택이 금방 힘들어지는 팀

1. 팀이 여러 명이고 책임이 분산되는 경우

“그 서버에 ssh 해서 보면 돼” 라는 운영은 한 명일 땐 쉽다.

세 명이 넘어가면 설명 비용이 급격히 오른다.

2. 고가용성이 계약사항인 경우

단일 VPS, 로컬 DB, 로컬 GPU 전략은 고가용성과는 다른 언어를 쓴다.

강할 수는 있어도, 기본값 자체가 그걸 중심으로 설계된 건 아니다.

3. 규정 준수와 감사 요구가 강한 경우

보안, 접근 제어, 감사 로그, 데이터 위치 요구가 강하면 얇은 구조의 단순함만으로는 부족하다.

4. 실시간 추론이 핵심이고 부하 변동이 큰 경우

이럴 땐 로컬 GPU보다 managed inference나 클라우드 scaling이 훨씬 편할 수 있다.

5. 데이터 복구와 팀 인수인계가 핵심인 경우

SQLite가 나쁘다는 게 아니라, 조직 운영 요구사항이 바뀌었다는 뜻이다.

결국 이 글의 핵심은 “언제 두꺼워질지”를 아는 것이다

많은 사람이 얇은 스택 vs 두꺼운 스택을 신념 싸움처럼 본다.

근데 실무에선 그런 식으로 안 굴러간다.

좋은 운영자는 언제 얇게 시작하고, 언제 어떤 층을 두껍게 해야 하는지 안다.

예를 들면 이런 식이다.

  1. 시작은 단일 VPS
  2. 백업과 복구 문서 추가
  3. 사용자 증가 후 read/write 부담이 커지면 DB 분리 검토
  4. 실시간 AI 사용량이 늘면 inference 계층 분리
  5. 팀이 커지면 배포/관측성 표준화

즉, 이 글을 읽고 얻어야 하는 건 “나도 무조건 월 20달러로 가야지”가 아니다.

대신 내 스택은 어디에서 이미 과해졌나 를 묻는 습관이다.

내가 지금 사이드프로젝트를 다시 짠다면

완전히 다시 짠다면 나는 이런 순서로 볼 거다.

1단계

  • 단일 VPS 또는 아주 단순한 호스팅
  • 앱 배포 경로 최소화
  • 로그 위치 하나로 통일

2단계

  • 초기 DB는 가장 단순한 경로부터
  • 백업 자동화 먼저
  • 복구 연습 최소 1회

3단계

  • AI 기능을 배치와 실시간으로 분리
  • 배치는 로컬 또는 저비용 경로 검토
  • 실시간은 fallback과 비용 추적 우선

4단계

  • 사용자와 팀이 늘면 그때 계층 분리
  • 분리 이유가 생길 때만 두껍게

핵심은 이거다.

복잡도는 미래를 대비해 선구매하는 게 아니라, 문제를 확인한 뒤 증설하는 편이 낫다.

실수 TOP

실수 1. 월 20달러라는 숫자만 복사한다

숫자는 결과다.

원인은 구조다.

단순한 구조를 빼고 숫자만 따라 하면 금방 무너진다.

실수 2. 로컬 GPU를 만능 절약법으로 본다

배치엔 강할 수 있다.

하지만 운영 지식, 하드웨어, 실시간 요구사항을 같이 봐야 한다.

실수 3. SQLite를 영원한 답으로 본다

초기엔 훌륭할 수 있다.

하지만 조직 요구사항이 바뀌면 선택도 바뀌어야 한다.

실수 4. 단일 VPS를 낭만으로 본다

단순함은 무기지만, 복구와 백업이 없으면 그냥 단일 실패 지점이다.

실수 5. 엔터프라이즈 스택을 무조건 악으로 본다

그건 또 다른 극단이다.

두꺼운 스택은 필요한 순간이 분명 있다.

문제는 타이밍이다.

언제 이 선택이 맞고 언제 아닌가

이 선택이 맞는 경우는 이렇다.

  • 1인 또는 극소수 팀이다
  • 초기 검증 단계다
  • 비용 민감도가 높다
  • 배치형 AI 작업이 많다
  • 운영 owner가 선명하다
  • 장애 복구 범위를 이해하고 있다

이 선택이 아닌 경우는 이렇다.

  • 팀 규모가 크다
  • 규정 준수 요구가 높다
  • 고가용성이 계약사항이다
  • 실시간 multi-tenant 부하가 핵심이다
  • 데이터와 권한 경계가 복잡하다

FAQ

진짜로 월 20달러만 들 수 있어?

모든 서비스가 그렇다는 뜻은 아니다.

그 숫자는 Steve Hanov가 제안한 매우 얇은 운영 구조와 그의 워크로드 전제를 깔고 나온 값에 가깝다.

핵심은 숫자보다 복잡도 축소 전략이다.

단일 VPS는 너무 위험하지 않아?

요구사항에 따라 다르다.

초기 제품, 낮은 동시성, 명확한 owner, 간단한 복구 루프라면 충분히 현실적일 수 있다.

반대로 고가용성과 팀 운영이 중요하면 빨리 한계가 온다.

SQLite WAL이면 동시성 문제는 끝나?

그렇게 단순하진 않다.

WAL은 reader/writer 충돌 특성을 개선해 초기 운영에 유리한 면이 있다.

하지만 서비스 요구사항 전체를 대체하는 만능 해법은 아니다.

로컬 GPU가 클라우드 API보다 항상 싸?

항상은 아니다.

배치 작업이 많고 반복량이 크면 유리해질 수 있다.

하지만 초기 하드웨어 투자, 운영 지식, 실시간 성능 요구까지 보면 클라우드가 더 나은 경우도 많다.

OpenRouter 같은 라우팅 계층은 왜 필요해?

모든 걸 로컬로 처리하기 어렵기 때문이다.

실시간 사용자 경험과 최신 모델 접근은 외부 API가 더 나은 경우가 많다.

그 대신 비용 추적과 fallback 규칙을 같이 가져가야 한다.

이 글은 AWS 쓰지 말라는 얘기야?

아니다.

AWS나 managed stack이 나쁘다는 뜻이 아니라, 초기 단계에서 너무 일찍 무거워질 수 있다는 이야기다.

문제는 클라우드가 아니라 타이밍이다.

Python으로도 비슷한 철학을 구현할 수 없나?

가능하다.

이 글의 핵심은 Go라는 언어명보다 배포 경로를 짧게 유지하는 사고방식에 있다.

이미 Python 기반 역량이 크다면 그 위에서 얇은 구조를 설계하는 편이 더 현실적일 수 있다.

참고 자료

관련 글