# Uncloud - Kubernetes의 복잡함 없이 서버 간 컨테이너 앱을 배포하는 도구 > Clean Markdown view of GeekNews topic #24862. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24862](https://news.hada.io/topic?id=24862) - GeekNews Markdown: [https://news.hada.io/topic/24862.md](https://news.hada.io/topic/24862.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-06T04:32:58+09:00 - Updated: 2025-12-06T04:32:58+09:00 - Original source: [uncloud.run](https://uncloud.run/) - Points: 23 - Comments: 1 ## Summary Kubernetes의 복잡한 설정 없이도 여러 서버에 컨테이너 앱을 배포할 수 있다면 어떨까요. **Uncloud**는 Docker Compose 기반 워크플로우를 그대로 유지하면서, 중앙 제어 플레인 없이 서버 간 **WireGuard P2P 네트워크**로 연결된 분산형 배포 환경을 제공합니다. 클라우드와 온프레미스를 넘나드는 인프라에서도 동일한 방식으로 동작해, 개발자가 인프라 제어권과 비용 예측성을 함께 확보할 수 있습니다. ## Topic Body - **Uncloud**는 Kubernetes 없이도 여러 서버에 **컨테이너화된 웹 애플리케이션을 배포하고 확장**할 수 있는 오픈소스 도구 - **Docker Compose 기반 워크플로우**를 유지하면서, 무중단 배포·자동 HTTPS·서버 간 스케일링을 지원 - **중앙 제어 플레인 없이** 각 머신이 **WireGuard 기반 P2P 네트워크**로 연결되어, 일부 서버가 오프라인이어도 클러스터 운영 유지 - **Caddy 리버스 프록시**를 통한 자동 HTTPS, 내장 DNS 기반 서비스 디스커버리, 로드밸런싱 기능 포함 - **클라우드·온프레미스 혼합 환경**에서도 동일한 방식으로 배포 가능해, 인프라 제어권과 비용 예측성을 확보 --- ### PaaS 유사 워크플로우 - Heroku나 Fly.io처럼 간단한 배포 경험을 제공하면서도 **서버와 데이터에 대한 완전한 제어권** 유지 - 요청 단위 과금이 아닌 **예측 가능한 비용 구조** - **벤더 종속성 없음**, 표준 SSH 도구로 디버깅 가능 - **Docker Compose 친화적 구조**로, 빌드·푸시·배포를 한 명령으로 수행 - **이미지 레지스트리 불필요**, **무중단 롤링 배포** 지원 - 여러 머신에 걸친 **복제 스케일링** 가능 ### 저유지보수형 설계 - **컨트롤 플레인이나 쿼럼 관리 불필요**, 관리 복잡도 최소화 - **포트 개방 없이 안전한 머신 간 통신** 지원 - **자동 서비스 탐색**과 **Let's Encrypt 기반 HTTPS 자동 발급** 기능 내장 ### 작동 방식 - 복잡한 클러스터 대신 **간단한 머신 네트워크**로 구성, 유지보수 부담 없이 안정적 인프라 제공 - 각 머신은 **WireGuard 메시 네트워크**에 참여해 자동 피어 탐색 및 NAT 트래버설 수행 - 컨테이너는 고유 IP를 받아 **서버 간 직접 통신** 가능 - **완전 분산형 구조**로, 중앙 제어 노드 없이 각 머신이 **클러스터 상태를 동기화** - 일부 머신이 오프라인이어도 클러스터 운영 지속 - **Docker 유사 CLI**로 전체 인프라 제어 - 단일 머신 SSH 접근만으로 **배포·모니터링·스케일링** 수행 가능 ### 주요 기능 - **어디서나 배포 가능**: 클라우드 VM, 전용 서버, 온프레미스 등 모든 Linux 머신 지원 - **자동 HTTPS**: 내장 Caddy 리버스 프록시로 **무설정 TLS 인증서 발급 및 HTTPS 활성화** - **로드밸런싱**: 여러 머신에 분산된 컨테이너 복제본 간 트래픽 분배 - **서비스 디스커버리**: 내장 DNS가 네트워크 내 서비스 위치를 자동 추적 - **Infrastructure as Code**: 기존 **Docker Compose 파일**로 전체 앱 스택 정의 가능 - **벤더 종속성 없음**: 클라우드와 자체 하드웨어를 자유롭게 혼합 사용 가능 ## Comments ### Comment 47283 - Author: neo - Created: 2025-12-06T04:32:58+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=46144275) - 안녕하세요, 제작자임. 공유해줘서 고마움 **Uncloud**는 컨트롤 플레인이 없는 컨테이너 오케스트레이터임. 쉽게 말해, 여러 머신에 걸친 **Docker Compose**에 자동 WireGuard 메시, 서비스 디스커버리, Caddy를 통한 HTTPS가 붙은 형태임. 각 머신은 Fly.io의 Corrosion을 이용해 클러스터 상태를 **p2p 동기화**함으로써 쿼럼 유지가 필요 없음 Kubernetes를 스타트업과 유니콘 기업 양쪽에서 운영해온 경험 끝에, 대부분의 팀이 사실은 단지 몇 대의 머신에서 컨테이너를 잘 돌리고 네트워킹과 롤아웃, HTTPS만 필요하다는 걸 깨달았음. K8s의 운영 오버헤드는 그에 비해 너무 큼 주요 특징은 다음과 같음 - 익숙한 Docker Compose 스펙 사용, 새로운 DSL 학습 불필요 - 외부 레지스트리 없이 직접 머신에 Docker 이미지를 빌드·푸시 (내 다른 프로젝트 [unregistry](https://github.com/psviderski/unregistry) 사용) - 선언적이 아닌 **명령형 CLI** 제공으로 디버깅이 쉬움 - 클라우드 VM, 베어메탈, NAT 뒤의 Raspberry Pi까지 연결 가능 - 메모리 사용량 150MB 미만 프로젝트 링크: [https://github.com/psviderski/uncloud](https://github.com/psviderski/uncloud) - K8s는 이미 소규모 환경에서도 컨테이너를 잘 돌릴 수 있어서, 굳이 다른 걸 쓸 이유가 없다고 생각함. **k3s** 같은 경량 배포도 쉬워졌기 때문에 대안이 필요하다고 느끼지 않음 - 아이디어는 멋지지만 `uc machine init`이 내부적으로 root 권한으로 `curl | bash`를 실행하는 방식은 **보안상 위험**해 보임. 테스트는 해보고 싶지만 실제 머신에서는 돌리지 않을 것 같음 - 정말 흥미로움. 곧 시도해볼 기회가 있을 듯함. 다만 문서를 봐도 클러스터 설정 후 다른 엔지니어를 **온보딩**하는 방법이나 CI/CD 러너에서 배포하는 방식이 명확하지 않음. 새 머신에서 기존 클러스터에 연결하는 절차가 궁금함 - [Kamal](https://kamal-deploy.org/)과의 차이점이 궁금함 - WireGuard로 구성된 프라이빗 네트워크 내에서 AWS RDS 같은 외부 서비스에 **보안 연결**을 어떻게 하는지 궁금함. Tailscale의 [AWS RDS 접근 방식](https://tailscale.com/kb/1141/aws-rds)처럼 지원되는지 알고 싶음 - 커리어 대부분을 **Kubernetes**로 보냈는데, 컨트롤 플레인이 없는 구조의 장점이 무엇인지 궁금함. 내게는 컨트롤 플레인이야말로 K8s의 핵심 기능임. 수백 노드, 만여 개 컨테이너 정도는 관리형 클러스터로 자동 업데이트되기 때문에 큰 부담이 없음. 사람들이 직접 K8s를 **셀프호스팅**하면서 겪는 고통이 이런 대안의 배경인지 궁금함 - “수백 노드, 만 개 컨테이너”가 작다고 느껴지지 않음. 나는 2~5대 노드, 10~30개 컨테이너 정도의 규모인데, 이 정도면 **K8s는 너무 무거움**. 이런 소규모 기업이 많을 것 같음 - 무례한 질문 아님. 컨트롤 플레인이 없는 장점은 모든 머신이 동등한 **피어 구조**로 단순화된다는 점임. 중앙 집중식 “클러스터 브레인”이 없으니 HA 구성이나 etcd 쿼럼 문제를 걱정할 필요 없음. 네트워크가 분할되어도 각 파티션이 독립적으로 동작 가능함. 예전 Chef나 Ansible 시절의 단순함에 K8s의 교훈을 더한 형태임 - 물론 사람들이 셀프호스팅 K8s를 시도함. 백업처럼, 미리 해보지 않으면 필요할 때 못 하게 됨 - 중소기업 입장에서는 만 개 컨테이너는 결코 작지 않음. 나는 10개 미만이지만 **고가용성(HA)** 이 필요함. Uncloud는 내 상황에 잘 맞을 듯함 - “만 개 컨테이너가 작다니, 그건 CI 잡 수치 아님? ;)” - 프로젝트가 멋짐. 나중에 꼭 써볼 생각임. 더 단순한 대안을 찾는다면 [Kamal](https://kamal-deploy.org)도 괜찮음. 이건 K8s와 클라우드를 완전히 벗어난 회사가 직접 운영하며 **실전 검증**된 툴임 - 서버를 지정했을 때 **보안 강화(server hardening)** 를 자동으로 해주는 기능이 있는지 궁금함 - 나는 **Docker Swarm** 사용자임. Uncloud는 처음으로 흥미롭게 느껴지는 대안임 궁금한 점은 다음과 같음 - secrets 지원 계획이 있는지 - Swarm+Traefik처럼 컨테이너 라벨로 URL rewrite 규칙을 정의할 수 있는지 - 두 개의 Compose 스택을 배포했을 때, 서로 다른 스택의 컨테이너 간 네트워크 접근이 가능한지 - 도메인과 내부 포트 매핑은 Compose 파일에서 `x-ports: app.example.com:8000/https`로 정의함. 또는 `x-caddy: Caddyfile`로 **Caddy 설정**을 커스터마이징 가능함. 자세한 내용은 [공식 문서](https://uncloud.run/docs/concepts/ingress/publishing-services) 참고 현재는 스택 간 네트워크 **격리 기능이 없음**. 관련 논의는 [GitHub Discussion #94](https://github.com/psviderski/uncloud/discussions/94)에서 진행 중임. 어떤 동작을 기대하는지 궁금함 - secrets 기능은 [이슈 #75](https://github.com/psviderski/uncloud/issues/75)에서 트래킹 중임. Compose config로 주입은 가능하지만 **암호화 저장**은 아직 없음. 2, 3번 질문의 답은 “아직은 아니고”, “현재는 예”임. 관련 논의는 [Discussion #94](https://github.com/psviderski/uncloud/discussions/94) 참고 Swarm을 써본 입장에서, Swarm이 부족하거나 불편했던 점 중 Uncloud가 개선할 수 있을 부분이 무엇인지 궁금함 - 정말 멋진 프로젝트임. 비슷한 주제의 다른 툴들도 참고할 만함 - [Dokploy](https://dokploy.com/) - [Coolify](https://coolify.io/) - [Kubero](https://demo.kubero.dev/) 더 알고 있다면 추가해줬으면 함 - [Self-hosted PaaS 리스트](https://dbohdan.com/self-hosted-paas)가 유용함. 최근 Coolify를 써봤는데 다소 **미완성** 느낌이었음. 현재는 Dokku를 쓰고 있지만, DB 관리용 UI가 더 나아졌으면 함 - 나는 **k3s**에 만족하지만, Docker Compose와 완전한 K8s 사이의 **중간 지대**에서 새로운 시도가 나오는 게 반가움. 특히 WireGuard 통합이 흥미로움 - 정말 멋진 툴임. 수고에 감사함. 백엔드의 **상태 복제(state replication)** 가 어떻게 동작하는지 궁금함. CRDT와 gossip 프로토콜을 언급했지만 구체적인 구현이 모호함 - 현재 상태 복제는 [Corrosion](https://github.com/superfly/corrosion)을 기반으로 함 - K8s가 아니라면 왜 [Nomad](https://github.com/hashicorp/nomad)가 아닌가? - Nomad도 좋지만 여전히 **컨트롤 플레인**이 존재함 - Nomad는 학습 곡선이 꽤 있음. 반면 Uncloud는 Docker와 Compose를 아는 사람이라면 거의 **즉시 사용 가능**함 - HashiCorp의 라이선스는 수정 후 SaaS 형태로 제공하는 걸 금지함. 즉, 직접 호스팅 외에는 활용이 제한되어 있고, 사실상 **자유로운 서비스화가 불가능**함. [라이선스 전문](https://github.com/hashicorp/nomad/blob/main/LICENSE) 참고 - 참고로, 흥미로운 **p2p 구성요소** 두 가지를 공유함 - [edgevpn](https://github.com/mudler/edgevpn) - [iroh.computer](https://www.iroh.computer/)