Salesforce · GitLab · Atlassian 의 onprem 패턴 — 그리고 우리 모델이 다른 이유

7 개 enterprise 도구의 onprem 모델을 비교. 각자 *어떤 가정* 으로 짰고, *그 가정이 누구를 배제* 하는지. CollabOps 가 *다른 가정* 으로 시작한 이유.

백재민

CollabOps 창업자

2026년 4월 6일

Salesforce · GitLab · Atlassian 의 onprem 패턴 — 그리고 우리 모델이 다른 이유

미팅에서 자주 듣는 한 줄 — "GitLab Self-managed 처럼 들어오나요?"

답이 아니오 다. 왜 가 이 글의 내용. 7 개 enterprise 도구의 onprem 모델을 분해하고, 각자 어떤 가정 위에 서 있는지를 본다.

7 도구 비교 표

도구                      | onprem 모델           | 최소 요구                | 가정                         | 배제하는 고객
─────────────────────────┼─────────────────────┼────────────────────────┼─────────────────────────────┼──────────────────
Salesforce               | Hyperforce (실질 SaaS) | (없음 — SaaS)            | 모든 데이터가 클라우드 가능     | 한국 공공·금융 90%
GitLab Self-managed     | docker-compose / Helm | 4 vCPU (5명) → 50명+ k8s | 50명+ 는 k8s 인프라 있음        | k8s 없는 중견 기업
GitLab Dedicated         | AWS-managed onprem-like | (관리형)              | AWS 사용 가능                 | air-gapped, 비-AWS
Atlassian Data Center   | k8s + 외부 DB          | k8s + Postgres + LB    | 인프라 전문성 보유              | 운영 IT 5명 미만
GitHub Enterprise (GHES) | VMware OVA              | 4 vCPU + VMware/AWS     | VMware 또는 클라우드           | KVM, Hyper-V, OpenShift
Jenkins (LTS)            | self-managed jar       | Java + DB              | 운영 직접                      | DevOps 인력 없음
Sentry self-hosted       | docker-compose         | docker host             | 프로덕션 비-권장 (공식 문서)   | 프로덕션 사용
CollabOps               | 5 환경 분류 (단독 VM·Helm·OVA·Operator·tarball) | 1 VM + 8 vCPU | 인프라 전문성 가정 X            | (의도적으로 거의 없음)

각 가정의 암묵적 메시지

도구의 최소 요구 는 기술 사양 이 아니라 고객 segment 선택 이다.

Salesforce 의 메시지

"우리는 SaaS 만 한다. onprem 이 필요하면 다른 곳을 보세요." Hyperforce 는 *"고객 region 의 hyperscaler 위에서" 동작하지만, 고객의 자체 데이터센터 는 아님.

배제하는 시장 — 한국 공공기관, 금융섹터 (특히 K-ISMS 적용), 일본 정부, EU 일부 규제 기관. 수십억 달러의 시장 을 의도적으로 배제. 그것이 Salesforce 의 전략.

GitLab 의 메시지

"50명 미만은 4 vCPU 로, 50명 넘으면 k8s 도입하세요." 이 message 가 50명 미만 + k8s 도입 의지 없음 인 시장을 배제. 이 시장이 한국·일본 지방은행 / 보험사 의 핵심.

Atlassian 의 메시지

"인프라 운영 가능한 IT 팀이 있다는 가정." k8s + 외부 DB + LB + 공유 파일시스템 = 인프라 전문성 4 영역. 5명 IT 팀에 4 영역은 과중.

GHES 의 메시지

"VMware 또는 AWS/GCP/Azure." k8s 미지원 — 역설적이지만 GHES 는 k8s 위에 설치 X. KVM·Hyper-V·OpenShift 사용 기관은 별도 wrapping 필요.

CollabOps 의 다른 가정

위 6 도구의 가정은 각자의 ICP 에 맞다. CollabOps 는 다른 ICP 를 보고 다른 가정 으로 시작:

가정                                | 결과
───────────────────────────────────┼─────────────────────────
고객의 인프라 전문성 가정 X        | 5 환경 분류 모두 지원
고객의 *next* 결정을 막지 않음     | k3s 내장 → 기존 k8s 마이그레이션 경로
고객의 데이터 경계를 침해 X         | air-gapped 까지 default 지원
SaaS 는 *옵션*, self-hosted 가 default | → /blog/product/why-self-hosted-default

이 4 가정이 모든 deploy artifact 결정을 정렬시킨다. 1 가정 다르면 전체 stack 이 다른 모양.

누가 어떤 도구 를 골라야 하나

객관적으로:

조건                                    | 권장
────────────────────────────────────────┼────────────────
모든 데이터 클라우드 OK + 표준 ICP      | Salesforce / SaaS DevOps
50+명 + k8s 운영팀 보유                 | GitLab / Atlassian
VMware 표준 + 클라우드 일부 OK           | GHES / GitLab Dedicated
공공·금융·방산 + air-gapped 또는 inhouse | CollabOps
인프라 인력 5명 이하 + 자체 데이터센터    | CollabOps

위 표는 영업 자료가 아니라 결정 매트릭스. CollabOps 가 모든 환경에 답 인 게 아님 — 다른 도구가 못 들어가는 환경 이 우리 영역.

7 개 비교의 진짜 결론

각 도구의 최소 요구 는 그 도구의 출신 을 드러낸다.

Salesforce — 클라우드 first 출신 → onprem 옵션이 후일 추가 → 사실상 SaaS
GitLab — 오픈소스 self-host 출신 → 50명 이상은 가정 외 → k8s 권장
Atlassian — 인프라 강한 enterprise 출신 → 전문가 팀 가정
GHES — VMware 호환성 출신 → 비-VMware 환경 약
CollabOps — 한국·일본 공공·금융 출신 → 어떤 환경이든 가정

도구 선택은 기술 비교 가 아니라 그 도구가 누구의 환경을 가정하는가 의 비교다.

누가 이 글을 읽으면 좋은가

지금 DevOps onprem 도구 를 비교 검토 중인 IT 책임자. 5 도구 의 최소 요구 만 보면 우리 환경에 안 맞는 이유 가 보임. 가장 자주 잘못되는 결정 — 지금 4 vCPU 로 작동 하지만 6개월 후 k8s 도입 강제 하는 도구 선택. 이건 6개월 후 마이그레이션 비용 을 지금 결정 에 포함 안 한 결과.