어떤 환경이든 들어가는 *최소 요구사항* — 8 vCPU·16 GB·VM 1대의 의도적 결정

CollabOps 의 최소 시스템 요구사항 한 줄:

VM 1대 + 8 vCPU + 16 GB RAM + 200 GB SSD + 내부 IP 1개 + sudo 권한.

이 줄이 우리 영업 메시지의 절반 이다. 그러나 이 줄을 만들기 위해 우리는 6개월 동안 4가지 아키텍처 결정 을 했다. 이 글은 그 4 결정이다.

비교 — 왜 우리만 이 줄 이 가능한가

도구                     | 최소 요구
────────────────────────┼─────────────────────────────────────────────────
GitLab self-managed     | 4 vCPU + 4 GB (5명 user 기준), 50명+ → k8s 권장
Atlassian Data Center   | k8s 클러스터 + 외부 PostgreSQL + LB + 공유 파일시스템
GitHub Enterprise (GHES) | VMware/AWS 전용, 4 vCPU 최소, k8s 미지원
Jenkins (LTS)           | Java 11+, 256 MB 최소, 운영은 별도
GitLab self-managed (50+) | k8s + 외부 DB + Redis + S3 호환 storage
CollabOps               | VM 1대 + 8 vCPU + 16 GB + 200 GB + sudo

겉보기에 GitLab 5명 기준이 가장 가벼움. 그러나 50명 넘으면 k8s 권장. CollabOps 는 50명까지 같은 VM 1대. 200명까지 같은 VM 1대 (8 vCPU 가 아니라 16 vCPU 로 stepping 하면).

결정 1 — k3s 내장 + 외부에는 투명

CollabOps 단일 VM 배포는 내부적으로 k3s (경량 k8s) 를 쓴다. 그러나 사용자에게는 보이지 않음. 사용자는 k3s 라는 단어를 듣지 못함. 단지 systemd unit 1개 가 동작.

이렇게 한 이유:

• k8s 의 운영 모델 을 사용자 지식 없이 활용 가능
• 환경 2 (기존 k8s) 와 동일한 deploy artifact — Helm chart 가 둘 다 동작
• 5년 후 환경 1 → 환경 2 마이그레이션 시 재설치 없이 데이터 이주 가능

대안 — static binary + supervisord. 더 단순하지만 이주 경로가 끊어짐. 우리는 현재 단순성 보다 5년 후 옵션 을 택함.

결정 2 — Postgres embedded vs external — embedded 가 default

VM 1대 안에 Postgres 도 함께 동작. 외부 DB 옵션 은 있지만 default 가 embedded.

• 백업: VM 의 snapshot 또는 pgdump 자동 cron
• HA: 없음 (환경 1 의 정의)
• 데이터 마이그레이션: VM 교체 시 pg_dump → 새 VM 에서 pg_restore

대안 — 처음부터 외부 DB 강제. 더 견고하지만 고객의 진입 장벽 이 VM 1대 → VM 1대 + DB 서버 로 2배. 영업 분석에서 이 결정 한 줄로 환경 1 시장의 40% 를 잃을 것 으로 봄. embedded 결정.

결정 3 — observability stack 도 함께 굽기

Prometheus / Grafana / loki 같은 o11y stack 도 같은 VM 안 에 들어감. 사용자가 추가 인프라 셋업 안 해도 모니터링이 기본 동작.

이 결정의 비용 — 메모리 +2 GB. 우리는 RAM 최소를 14 → 16 GB 로 올림. 이 2 GB 의 영업 영향 은 0 에 가까움 — 어차피 대부분 VM 의 default profile 이 16 GB.

대안 — o11y 를 외부 의존 으로. 고객 환경의 기존 Prometheus 클러스터 와 통합. 옵션 으로는 제공하지만 default 아님.

결정 4 — bootstrap 자동화 — 첫 명령부터 첫 로그인까지

VM 에 우리 installer 1개를 download → run. 4 시간 안에 첫 로그인 가능 상태.

$ curl -sSL https://onprem.collabops.ai/install.sh | sudo bash
[OK] Validated VM (8 vCPU, 16 GB RAM, 200 GB SSD)
[OK] Internal IP detected: 10.0.45.12
[INFO] Installing k3s (embedded)...
[INFO] Pulling images (offline tarball if available)...
[INFO] Bootstrapping Postgres...
[INFO] Bootstrapping CollabOps services...
[INFO] Configuring observability...
[OK] Done. First login: https://10.0.45.12:8443/  (admin / <one-time token>)

4 시간 동안 사람이 한 일 — 첫 명령 1번. 토큰 받아 첫 로그인 1번. 그 외에는 기다림.

이 자동화의 비용 — 12개월의 작업, 3 명 의 SRE 시간. 그러나 영업 단계에서 이게 결정적 — 첫 PoC 미팅 1시간 동안 라이브 데모로 도입을 완료 할 수 있음.

4 결정의 공통 원칙

• 고객의 인프라 전문성을 가정하지 않는다
• 고객의 기존 인프라를 침해하지 않는다
• 고객의 다음 결정을 막지 않는다

이 셋이 최소 요구사항 한 줄 의 진짜 의미.

왜 다른 도구들은 그렇게 못 하나

GitLab / Atlassian 의 최소 요구 가 큰 이유는 처음부터 클라우드 + 큰 팀 가정. 우리가 다른 가정으로 시작했고, 그 가정 차이가 지금의 deploy artifact 차이를 만든다.

클라우드 first 로 시작한 시스템이 self-hosted 를 후일 추가 하면 큰 최소 요구 가 됨. → self-hosted 가 default 인 이유

누가 이 글을 읽으면 좋은가

지금 DevOps 도구의 self-hosted 도입 을 검토 중인 IT 책임자. 도구의 최소 요구 가 VM 1대 + 8 vCPU 보다 훨씬 큰 이유를 의심하고 있다면, 그 의심이 옳음. 큰 요구는 고객을 보호 하는 게 아니라 벤더의 단순함 을 위한 결정인 경우가 많다.