CollabOps블로그

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

CollabOps 의 최소 요구는 *VM 1대 + 8 vCPU + 16 GB + 200 GB SSD + 내부 IP*. 이 한 줄이 *6개월의 아키텍처 결정* 을 압축한다. 그 결정의 내부.

백재민
백재민
CollabOps 창업자
어떤 환경이든 들어가는 *최소 요구사항* — 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 — 경량 k8s 내장 + 외부에는 투명

CollabOps 단일 VM 배포는 내부적으로 경량 k8s 배포판 을 내장한다. 그러나 사용자에게는 보이지 않음. 사용자는 k8s 라는 단어조차 듣지 못함. 단지 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(부서 단위 VM 1대 도입)의 상당수는 검토조차 시작하지 못한다고 봤다. 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 embedded kubernetes...
[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 인 이유

최소 요구사항이 큰 도구, 의심해야 하나

Self-hosted DevOps 도구의 최소 요구가 VM 1대 + 8 vCPU 보다 훨씬 크다면, 그 의심이 옳다. 큰 최소 요구 뒤에는 고객 환경의 다양성보다 벤더 쪽 아키텍처의 전제 가 먼저 놓여 있는 경우가 많다. 지금 self-hosted 도입을 검토 중인 IT 책임자라면, 최소 사양 한 줄 뒤에 위 4 결정 같은 근거가 있는지부터 확인할 것.

태그#on-prem#minimum-requirements#architecture#kubernetes#postgres#devops

비슷한 글