직접 CI/CD 파이프라인과 인프라를 구축하여 백엔드 서버를 운영하고 있습니다.
이렇게 하게 된 이유는 가지고 있는 DevOps 지식을 활용하면서도 자유롭게 저의 서비스를 올리기 위함이었고,
그 중에서도 집중했던 부분은 Kubernetes(K8s) 구축과 가격이었습니다.
K8s는 DevOps 엔지니어의 필수 역량이기 때문에 포기할 수 없었고, 그럼에도 일반적으로 K8s 구축에 들어가는 비용이 크기 때문에 이 사이의 균형을 찾고 싶었습니다.
Overall Architecture
Home Server (feat. Mac mini)
K8s를 가장 싸게 구축할 수 있는 법 중 하나가 서버를 직접 구매하는 것입니다. 구축한 이후에는 전기세만 지불하면 되고, 미니PC를 활용하면 초기 비용도 비싸지 않아 좋은 방법이라고 생각합니다.
개인적인 공간이 있다면 Linux 서버를 사는 것이 가장 좋다고 생각하지만, 저는 그렇지 않은 상황이었기 때문에 비싸지만 전성비가 좋고, 소음과 발열이 상대적으로 적은 Mac mini를 선택하였습니다.
Mac mini의 장점은 MacBook에서 쉽게 원격 제어가 가능하고,1 macOS 생태계와 서비스를 그대로 쓸 수 있으며, 나중에 다른 용도로도 사용이 가능하다는 것입니다. 하지만 Mac mini는 macOS 특성상 K8s를 구성하기 위해 가상화 환경이 강제된다는 단점이 있습니다. 이를 최대한 쉽게 해결하기 위해 여러 시행착오를 거쳐 지금은 Colima를 사용하고 있습니다.
설정을 간편하게 하기 위해 CLI도 만들었는데, 이 링크를 참고해 주세요.
Cloud Server (OKE)
초기에는 홈 서버만으로 K8s 전체를 운영하려는 계획을 가지고 있었습니다.
그러나 2025년 초 정전 등의 사건으로 인해 홈 서버가 다운되는 경험을 하게 되었고, 결국 지속적인 서비스를 위해서는 클라우드 환경이 필요하다고 판단하였습니다.
제가 사용 중인 클라우드 환경은 Oracle Kubernetes Engine (OKE)입니다.
OKE는 다음과 같은 이유로 매우 저렴하게 구성할 수 있습니다.
- Control Plane에 대한 가격을 받지 않습니다. AWS 등 메이저 클라우드 서비스가 기본 클러스터 비용만 0.1$/hour를 받는 것을 생각하면 큰 차이입니다.
- 강력한 Free Tier가 있습니다. A1 Ampere 인스턴스를 사용할 경우 메모리 기준 24Gi까지 무료입니다.
저는 Free Tier로 인한 혹시 모를 제재를 방지하기 위해 13Gi짜리 노드 2개를 구성하고, Load Balancer까지 약간의 추가 요금을 지불하여 사용하고 있습니다.
OKE를 사용할 수 없다면 Vultr도 좋은 선택입니다. 무료 VM은 없지만 가격이 저렴하고, 역시 Control Plane 가격을 받지 않습니다.
Frontend & Mobile
프론트엔드는 Vercel, Netlify, GitHub Pages, GitLab Pages 등 다양한 서비스의 무료 플랜을 사용합니다. 특히 GitLab Pages는 코드를 비공개로 유지하면서도 비용 없이 페이지를 공개할 수 있다는 이점이 있습니다.
모바일 환경은 필요할 경우 직접 빌드하여 스토어에 배포하는 표준 방식을 사용합니다.
Android 환경을 위한 Play Store 계정은 설정해 두었고, iOS 환경은 추후에 고려할 예정입니다.
Database
DB는 Supabase를 메인으로 하고, 필요할 경우 추가로 Oracle Cloud를 활용하고 있습니다.
Supabase는 거의 모든 작업을 Postgres + S3만으로 처리하는 단순함, 그리고 다양한 기능과 외부 서비스 연동이 마음에 들었습니다.
Pro Plan만 결제하면 추가 서비스 구독 없이 Supabase만으로 중규모 서비스까지 처리할 수 있다는 견적도 나왔습니다.
처음에는 DB도 K8s 상에 배포할 계획을 가지고 있었지만, 아무래도 DB는 분리된 환경 + Managed Service를 사용하는 것이 안전하고 관리 포인트도 적어진다고 판단하였습니다.
Northflank (Monitoring)
모니터링을 위해 Northflank에 Uptime Kuma를 배포해 두었습니다.
Uptime Kuma의 가장 강력한 장점은 단순함인데, Grafana, Prometheus 등의 고급 모니터링 도구는 다른 곳에서 활용할 기회도 있고,
개인 서버에서 모니터링 복잡도를 불필요하게 높일 필요는 없다고 생각했습니다. 같은 이유로 Gatus와 같은 고급 Uptime monitoring도 채택하지 않았습니다.
Northflank는 기존 인프라와 독립적인 환경을 선택하면서도, Docker 컨테이너 하나를 쉽게 배포하고 무료로 사용할 수 있기 때문에 선택하였습니다.
설정에 특이사항은 없고, 데이터가 날아가는 것을 방지하기 위해 Persistent Volume만 간단히 설정해 주었습니다.2
Windows (Optional)
Windows를 사용하는 경우 Hyper-V를 사용하거나, VMWare, VirtualBox 등을 사용하여 K8s를 구성할 수 있습니다. 저는 가끔씩 VMWare를 사용하여 가상 머신을 띄우고 테스트 용도로 활용하고 있습니다.
Public CI/CD & Helm chart
CI/CD 파이프라인과 Helm chart를 투명하게 공개하고 있습니다.
공개 Helm chart
2024년에 처음 K8s 서버를 구성할 때의 Helm chart는 비공개였습니다.
하지만 2025년 7월부터 Helm chart를 공개하여 제가 어떠한 서비스를 어떻게 설정하여 사용하는지 투명하게 확인할 수 있도록 하였습니다.
External Secrets Operator 등의 관리 도구를 사용하면 Helm chart를 공개로 유지하면서도 Secret 관리를 안전하게 할 수 있다고 판단하였습니다.
배포는 Argo CD를 사용한 GitOps 패턴을 사용하며, App of Apps 패턴을 적용하였습니다.
Integrated CI/CD
저의 GitHub에는 다수의 백엔드 Repository가 있습니다.
백엔드 구조의 통일이 같이 이루어진다면, 각각 CI/CD 설정을 하지 않고 한 곳에 통합이 가능하다고 판단하였습니다.
그래서 Helm chart 저장소에 GitHub Actions를 설정하여, Repository 이름만 변수로 입력하면 이를 Clone하여 빌드 작업을 수행하고, 태그까지 업데이트하도록 설정하였습니다.