클라우드에서 벗어난 SaaS 인프라, 언제 자가 호스팅이 유리할까?

SaaS를 운영하는 입장에서 인프라를 전부 클라우드에 올릴지, 직접 서버를 관리할지 선택은 점점 더 중요해지고 있습니다. 한 창업자는 기존에 전부 AWS에서 돌리던 5개 SaaS 제품(월 매출 10만 달러 이상, 연간 200만 달러 ARR 규모)을 올해부터 점진적으로 자가 호스팅 환경으로 옮겼습니다.

현재는 약 80%를 독일 호스팅 업체의 베어메탈 서버로 옮겼고, 나머지 20%만 AWS에 남겨둔 상태입니다. 이 과정에서 비용, 성능, 사업 구조, 벤더 락인, 보안, AI 연동 등 여러 이슈가 드러났고, 그 경험이 클라우드 사용 전략을 다시 생각하게 만듭니다.

아래에서는 이 사례를 바탕으로, 어떤 선택지가 있는지, 실제로 어떤 스택과 비용 구조로 전환했는지, 무엇을 끝까지 클라우드에 남겼는지, 그리고 우리 제품에는 어떤 전략이 맞을지까지 한 번에 정리합니다.

AWS 올인에서 쿠버네티스 자가 호스팅으로, 전체 구조 비교

처음에는 인프라 전부를 AWS 매니지드·서버리스 서비스로 구성했습니다.

• 애플리케이션 실행: ECS, Fargate, Lambda

• 프론트엔드 호스팅: AWS Amplify

• 데이터베이스: DynamoDB

• 메시지 큐: SQS

• 모니터링·로그: CloudWatch

이 조합의 장점은 분명합니다. 서버가 어디서 어떻게 돌아가는지 직접 신경 쓸 필요가 없고, AWS가 알아서 운영해주며, 사용량 기준 과금으로 청구가 이루어집니다. 코드 실행 시간(밀리초 단위), DB 읽기·쓰기 횟수, 로그 보관 기간 등 모든 것이 세밀하게 사용량 기반으로 청구됩니다.

현재의 새 구조는 완전히 다릅니다.

• 인프라: 독일 호스팅 업체 Hetzner의 전용 베어메탈 서버 3대

• 실행 환경: 모두 Docker 컨테이너 + Kubernetes

• 데이터베이스: PostgreSQL

• 캐시: Redis

• 메시지 큐: BullMQ

• 모니터링·메트릭·로그: Prometheus + Grafana

여기서 핵심은 대부분이 오픈소스라는 점입니다. Kubernetes, PostgreSQL, Redis, BullMQ, Prometheus는 모두 무료이며, Grafana도 커뮤니티 에디션만으로 충분한 기능을 제공합니다.

따라서 지불하는 비용은 사실상 Hetzner 전용 서버 3대의 월 고정 비용입니다. 대신 서버·클러스터 운영, 배포, 모니터링, 장애 대응 등은 모두 직접 관리해야 합니다.

이 글에서 말하는 "클라우드를 떠난다"는 표현은, 집에 서버를 두는 진짜 온프레미스는 아니고, AWS 같은 서버리스·매니지드 환경에서 벗어나, 전용 서버를 직접 운영하는 방식으로 옮긴다는 의미에 가깝습니다.

월 7,800달러에서 2,000달러 이하, 비용 구조가 어떻게 바뀌었나

가장 눈에 띄는 변화는 서버 비용입니다.

• 2025년 초 AWS 사용 시: 월 평균 7,800달러

• 현재, 인프라 80%를 전용 서버로 이전 후: 월 2,000달러 미만

• Hetzner 전용 서버 비용 자체: 월 약 200달러 수준

• 나머지 비용: 아직 AWS에 남아 있는 20% 인프라 비용

마이그레이션이 모두 끝나면 월 1,000달러 이하까지 내려갈 가능성도 있다고 보고 있습니다.

여기서 한 번 더 생각할 지점이 있습니다. 이 SaaS 포트폴리오 전체 매출이 월 10만 달러 이상입니다. 이 규모에서 월 7,800달러 인프라 비용이 정말 큰 문제인가 하는 질문이 생깁니다.

또한, 이번 해 초에 쿠버네티스, Docker, 시스템 관리 기본기를 새로 익히느라 상당한 시간을 투입했습니다. 그 시간 동안 마케팅, 제품 기능 개선, 고객 지원 등 다른 활동을 못 했기 때문에, 시간 비용까지 포함하면 이 선택이 과연 재무적으로 합리적이었는지도 따져봐야 합니다.

하지만 학습 기간 이후를 보면 상황이 달라집니다.

• 초기에 인프라 관련 작업 시간은 크게 증가했습니다.

• 시간이 지나고 경험이 쌓이고, AI 도구의 도움까지 받으면서, 인프라 관련 작업 시간은 다시 예전 수준까지 감소했습니다.

• AWS를 쓰더라도 인프라 관련 시간이 0이 되지는 않습니다. 구성과 운영 자체가 복잡하기 때문에, 이쪽도 분명한 학습 곡선이 있습니다.

현재 시점 기준으로는, 인프라 관리에 쓰는 시간은 AWS 시절과 비슷하거나 오히려 줄어든 상태입니다. 반면, 매달 절감되는 서버 비용은 매출과 함께 계속 증가하고 있고, 이 절감 효과에는 상한선이 없습니다.

정리하면, 인프라를 직접 운영하는 데에는 초기 고정 투자(시간·노력)가 필요하지만, 이후에는 시간이 크게 늘어나지 않는다는 점이 중요합니다. 많은 개발자들이 "자가 호스팅은 유지 보수에 손이 너무 많이 간다"고 생각하지만, 이 경험에서는 초기 구간을 지나면 그렇지 않았습니다.

반대로 사용량 기반 클라우드 비용은 매출과 함께 계속 증가하기 때문에, 장기적으로는 비용 절감 효과가 크게 누적될 수 있습니다.

비용보다 더 중요한 이유, 벤더 락인에서 자유로워지는 구조

AWS의 서비스인 DynamoDB, Lambda, Fargate 등은 성능, 안정성 측면에서 매우 우수하고, 가격도 합리적인 편입니다. 문제는 이 서비스들이 AWS에만 존재한다는 점입니다.

즉,

• AWS가 가격을 올리거나

• 정책 변경으로 특정 고객을 더 이상 받고 싶지 않다고 하거나

• 계정을 제한하는 일이 발생하면

서비스 전체가 그대로 멈출 수 있습니다.

이 상황에서 다른 곳으로의 마이그레이션은 몇 시간 안에 끝낼 수 있는 작업이 아닙니다. 상당한 기간의 설계와 준비가 필요하고, 급하게 옮기려고 하면 비즈니스 전체가 위험해질 수 있습니다. 사용자들은 서비스 중단을 길게 기다려주지 않습니다.

이게 바로 벤더 락인(vendor lock-in) 문제입니다. AWS, Azure, GCP 모두 고객 이탈이 쉬워지기를 바라지는 않습니다. 그래서 특정 서비스에 깊게 의존할수록 빠져나오기 어려운 구조가 만들어집니다.

이번에 구축한 새 구조에서는,

• Kubernetes

• PostgreSQL

• Redis

• BullMQ

• Prometheus / Grafana

같은 범용 오픈소스 소프트웨어를 사용하기 때문에, 이론상 어떤 호스팅 업체든 VPS나 전용 서버만 제공하면 어디로든 옮겨갈 수 있습니다.

흥미로운 실험도 하나 했습니다. 전용 서버 대신 사무실에 있는 라즈베리 파이 3대로 실제 제품 하나를 이틀 동안 운영해 본 것입니다. 인터넷 속도도 부족하고 메모리 문제도 계속 발생해서 상시 운영에는 적합하지 않았지만, 작은 제품 하나를 돌리는 데에는 사용자가 눈치채지 못할 정도로 서비스가 돌아갔습니다.

이 실험의 목적은 라즈베리 파이로 운영하자는 것이 아니라, 동일한 스택을 어디서든 구동할 수 있다는 점을 스스로 검증하기 위해서였습니다. 실제 운영에는 추천하지 않지만, 인프라 의존성을 특정 벤더에서 떼어내는 방향은 강하게 권장하고 있습니다.

현재도 Stripe와 OpenAI 같은 주요 외부 의존성이 남아 있습니다. 이를 줄이기 위해,

• 결제: Stripe 외에 Coinbase를 통한 결제도 검토 중

• AI: OpenAI, Replicate, Vast AI 대신, 독립 GPU 인스턴스에 직접 모델을 올리는 방식 실험 중

을 진행 중입니다. 다만 이 영역은 난도가 높기 때문에, 빠르게 완전 자립 구조로 가기는 쉽지 않은 상황입니다.

평생 이용권(Lifetime deal)과 자가 호스팅, 구조적으로 맞는 조합인가

이 SaaS 포트폴리오에는 두 가지 판매 방식이 공존합니다.

• 월/연 단위 구독

• 5개 도구 전체를 한 번 결제하고 계속 쓸 수 있는 Lifetime deal(평생 이용권)

문제는, 한 번만 돈을 받고 영구 사용을 제공하면서, 운영 비용은 사용자 수가 늘어날수록 계속 증가한다는 점입니다. 사용량 기반 클라우드 과금 구조에서는 이 부담이 점점 커질 수밖에 없습니다.

Lifetime 판매 자체는 충분히 가능한 모델입니다. 다만,

• 고정비에 가까운 인프라 비용 구조를 만들고

• 사용자 수가 늘어도 비용이 기하급수적으로 늘지 않도록 설계하면

재무 리스크를 훨씬 줄일 수 있습니다.

또 하나의 현실적인 질문도 있습니다.

• "이 서비스를 평생 쓸 수 있다고 했는데, 회사가 문을 닫으면 어떻게 되나요?"

• "Lifetime을 샀는데, 서비스가 종료되면 약속은 어떻게 보장되나요?"

현재까지는 "사업이 잘 돌아가고 있고, 쉽게 문 닫을 일은 없다"는 답밖에 할 수 없었습니다. 그러나 이 답은 고객 입장에서 그리 신뢰를 주지 못합니다.

그래서 궁극적으로는 모든 제품을 완전 자가 호스팅 가능한 형태로 제공하려고 합니다.

• 회사가 더 이상 호스팅을 제공하지 못하는 상황이 오더라도

• Lifetime 구매자는 소스코드 혹은 패키지 형태로 받아

• 자신의 서버에 직접 설치하고 계속 사용할 수 있게 만드는 방식입니다.

이 접근법은 "Lifetime access"라는 약속을 기술적으로도 뒷받침할 수 있는 가장 현실적인 방법에 가깝습니다.

클라우드를 떠난 인프라 전환은 단순히 비용 문제가 아니라, 이런 비즈니스 모델(특히 Lifetime deal)과도 밀접하게 연결됩니다.

S3, 인증, 보안: 끝까지 남긴 20%는 왜 AWS에 둘 수밖에 없었나

전체 인프라의 약 80%를 전용 서버로 옮겼지만, 완전히 AWS를 떠난 것은 아닙니다. 아직도 약 20% 정도는 AWS에 남아 있습니다.

대표적으로 남아 있는 영역은 다음 세 가지입니다.

1. 파일 스토리지: S3 대체 시도와 실패

처음에는 S3를 대체하기 위해 여러 후보를 검토했습니다.

• Hetzner Storage Box / Storage Buckets

• Cloudflare R2

두 서비스 모두 S3 호환 API를 제공하고, 비용도 S3보다 저렴한 편입니다. 하지만 스토리지 비용 자체는 전체 비용에서 큰 비중을 차지하지 않았기 때문에, 진짜 문제는 여전히 벤더 락인이었습니다. AWS에서 벗어나도, 다른 특정 업체에 다시 묶이는 구조가 되는 셈입니다.

그래서 MinIO를 도입해 보았습니다. MinIO는 오픈소스 S3 호환 객체 저장소로, 자체 서버에 설치해서 사용할 수 있다는 점에서 이상적인 대안처럼 보입니다.

구성은 다음과 같았습니다.

• Hetzner에서 15TB 하드디스크를 추가 주문

• 메인 전용 서버에 디스크를 붙이고

• 그 위에 MinIO를 설치하여 S3 대체

동작 자체는 어느 정도 잘 되었지만, 문제는 다음 부분이었습니다.

• 백업 전략이 복잡해짐

• MinIO 설계 자체가 분산 시스템(멀티 노드)에 더 잘 맞는 구조

• 각 노드마다 별도 디스크 구성이 필요해져서 인프라 설계가 복잡해짐

• 안정성이 애매하고, 운영 난이도가 올라감

결국 이 구조는 "숙련된 운영자가 아니라면 유지하기 어렵다"고 판단했고, 다시 S3로 회귀했습니다.

2. 사용자 인증: Cognito를 쉽게 대체하기 어려운 이유

사용자 인증은 보안상 가장 민감한 영역입니다. 지금까지는 AWS Cognito User Pool을 사용해왔고, 이는 Auth0 같은 서비스와 비슷한 역할을 합니다.

자체 구현은 보안 리스크가 크기 때문에, 오픈소스 솔루션인 Keycloak을 시도했습니다. 하지만,

• 인터페이스와 사용성이 매우 난해하고

• 개발자 경험도 만족스럽지 못했으며

• Java 기반의 복잡한 설정이 부담으로 작용했습니다.

인증은 서비스 전체의 신뢰성과 직결되는 요소이기 때문에, 불안 요소가 조금이라도 있으면 선택하기 어렵습니다. 그래서 결국 AWS Cognito를 그대로 유지하는 쪽을 선택했습니다.

3. 엣지 보안·DDoS 방어: CloudFront 의존

마지막으로, AWS CloudFront를 현재도 공용 엔드포인트로 사용합니다.

• 모든 외부 요청은 먼저 CloudFront를 통과하고

• 그 다음에 Hetzner 서버로 전달됩니다.

CloudFront는 단순 CDN 역할뿐 아니라,

• WAF(웹 방화벽)

• DDoS 방어

• 각종 보안 필터링

등을 기본으로 제공하기 때문에, 이를 자체 서버에서 모두 구현하려면 상당한 전문성이 필요합니다. 이 영역은 당분간도 AWS에 의존할 가능성이 큽니다.

AI 관련해서도, 현재는 여전히 OpenAI, Replicate, Vast AI 같은 서비스에 의존하고 있습니다. 장기적으로는 GPU가 탑재된 전용 서버에서 모델을 직접 호스팅하는 구조를 원하지만, 지금 시점에서는 구현 난이도와 안정성 문제로 즉시 전환하기는 어렵습니다.

어느 단계에서 클라우드를 떠나는 선택이 현실적인가

그렇다면 우리 SaaS는 어느 시점에 "클라우드를 떠난다"는 선택을 고려할 수 있을까요? 이 사례에서는 다음과 같이 구분합니다.

1. 소규모 사이드 프로젝트 단계

• 취미로 만드는 작은 프로젝트

• 크게 성장할 계획이 없는 도구

이 단계라면 클라우드에 그대로 머무는 것이 합리적입니다.

• Vercel

• Netlify

• Railway, Render, Fly.io 등 "원클릭 배포"에 가까운 서비스

같은 플랫폼을 이용하는 편이 좋습니다. 여기서는 개발 속도와 단순성이 최우선입니다.

2. 대규모·미션 크리티컬 서비스

스케일이 크고, 고객 비즈니스에 치명적인 영향을 미치는 서비스라면, 오히려 AWS 같은 하이퍼스케일러를 계속 쓰는 편이 안전합니다.

• 글로벌 트래픽을 감당해야 하고

• 고가용성·멀티 리전·장애 복구가 필수이며

• 24/7 SRE 수준의 운영이 요구되는 서비스

라면, 직접 서버를 관리하는 것보다 대형 클라우드의 매니지드 인프라에 비용을 지불하는 편이 현실적인 선택일 수 있습니다.

3. 그 중간에 있는 대부분의 SaaS

현재 많은 독립 개발자·소규모 팀 SaaS는 이 두 극단 사이에 있습니다.

• 어느 정도 매출과 사용자가 있고

• 완전한 미션 크리티컬은 아니지만

• 비용과 벤더 락인을 고민해야 하는 단계

이 구간에서는 전용 서버 기반 자가 호스팅을 진지하게 고려할 만한 여지가 충분합니다.

• 쿠버네티스, Docker, 오픈소스 스택으로 인프라를 직접 구성하는 것은 충분히 현실적인 수준까지 내려와 있고

• 초기에만 학습 비용과 설정 시간이 집중적으로 들며

• 일정 수준을 넘으면 인프라 유지 시간은 다시 안정적인 수준으로 떨어질 가능성이 높습니다.

또한, 인프라뿐 아니라 자체 서버에서 내부용 오픈소스 도구를 돌리면서, SaaS 툴 구독료도 추가로 절감할 수 있습니다. 실제로 이 사례에서는 기존에 쓰던 유료 SaaS 도구 여러 개를 자가 호스팅 가능한 오픈소스 도구로 교체하면서, 연간 1만 달러 추가 절감 효과도 얻었습니다.

즉, 인프라를 옮기는 선택은

• 서버 비용 감소

• 벤더 락인 완화

• Lifetime deal 구조와의 궁합 개선

• 내부 툴 비용 절감

까지 함께 엮여 있는, 꽤 큰 방향 전환입니다.

자가 호스팅 전환의 효과와 한계, 현실적인 판단 기준

클라우드 중심에서 전용 서버 기반 자가 호스팅으로 전환한 이 사례를 요약하면 다음과 같습니다.

• 월 서버 비용: 7,800달러 → 2,000달러 미만, 완전 전환 시 1,000달러 이하 예상

• 인프라 스택: AWS 매니지드·서버리스 → Kubernetes + Docker + PostgreSQL + Redis + BullMQ + Prometheus + Grafana

• 벤더 락인: AWS 의존도 대폭 감소, 어떤 호스팅 업체로도 이전 가능한 구조

• 비즈니스 모델: Lifetime deal과 잘 맞는 고정비에 가까운 인프라 구조 마련

• 남아 있는 클라우드 의존: S3, Cognito, CloudFront, OpenAI 등 약 20%

이 접근이 항상 정답은 아닙니다. 현실적인 한계와 리스크도 분명합니다.

• 초기에는 쿠버네티스, Docker, 시스템 관리 관련 학습에 상당한 시간이 필요합니다.

• 스토리지, 인증, 보안 등 민감도가 높은 영역은 여전히 클라우드 매니지드 서비스에 의존할 가능성이 큽니다.

• 장애 대응, 보안 패치, 모니터링 등 운영 책임이 전적으로 팀에 귀속됩니다.

그럼에도 불구하고, 매출이 안정적으로 발생하는 중간 규모 SaaS라면 다음과 같은 질문을 한 번 던져볼 만합니다.

• 지금 사용하는 클라우드 서비스 중, 특정 벤더에만 존재하는 것은 무엇인가?

• 이들 서비스가 없어졌을 때, 며칠 안에 대체할 수 있는가?

• 사용량 기반 비용이 앞으로 몇 년간 얼마나 늘어날 것 같은가?

• Lifetime deal이나 장기 고객 약속을 인프라 구조가 뒷받침하고 있는가?

이 질문에 대한 답이 불안하다면, 전면 전환까지는 아니더라도, 핵심 컴포넌트부터 오픈소스 기반으로 차근차근 옮겨보는 전략은 충분히 고려할 가치가 있습니다.

클라우드를 떠나는 것이 목표가 될 필요는 없습니다. 다만, 어디까지를 클라우드에 맡기고, 어디부터는 직접 통제할 것인지를 제품의 규모와 수익 구조, 팀의 역량에 맞춰 의식적으로 설계하는 것이 필요해지는 시점입니다.

출처 및 참고 :