어떤 온프레 환경이든 들어가기 — CollabOps 가 보는 5가지 환경 분류

작년 가을, 한 지방은행 IT 팀장이 첫 미팅에서 한 줄을 말했다.

"k8s 같은 거 없어요. VMware vSphere 호스트 3대가 전부고, 운영팀 5명 다 합쳐도 컨테이너 라는 단어 들어본 사람이 절반."

이건 문제 진술 이 아니다. 대부분의 한국·일본·EU 공공·금융 IT 의 기본 조건 이다. 현대 DevOps 도구 가 광고하는 k8s + GitOps + service mesh 는 그들에게 일어나지 않는 일.

이 글은 17개 PoC 에서 본 온프레 환경 5분류와, 우리가 각 환경 에 어떻게 들어가는지의 정리다.

환경 1 — VM only, k8s 도입 의지 없음

가장 흔한 환경. VMware / Hyper-V / KVM 위에 VM 을 굴리고, k8s 도입은 향후 3년 계획에도 없음.

• 고객 프로필: 지방은행, 보험사, 일부 공공기관 (IT 인력 5~30명)
• 최소 요구: VM 1대 (8 vCPU / 16 GB RAM / 200 GB SSD), 내부 IP 1개, sudo 권한
• 우리 도입 경로: 단독 VM 배포. CollabOps stack (DB·인덱스·api·worker) 전체 를 단일 VM 에 패키징. 내부적으로 k3s 사용 (사용자에게는 완전히 투명)
• 함정: VM 의 백업 정책 을 사전 합의. single point of failure 인식. HA 가 필요해지면 환경 2 로 업그레이드 경로 명시
• 도입 시간: PoC 시작 후 4시간 이내 첫 로그인 가능

환경 2 — 기존 k8s 클러스터 운영 중

다음으로 흔한 환경. Rancher / OpenShift / 자체 kubeadm 으로 k8s 를 운영 중. DevOps 도구를 그 위에 올리고 싶음.

• 고객 프로필: 대형 보험·증권사, 일부 통신사, 공공 클라우드 도입 기관 (IT 인력 100+명)
• 최소 요구: k8s 1.27+, ingress controller, persistent storage class, 내부 image registry, namespace 1개
• 우리 도입 경로: Helm chart. 기존 클러스터의 namespace 단위 배포. 외부 DB (Postgres) 권장 — 클러스터의 stateful set 자체가 RPO 가 약함
• 함정: 기존 ingress / DNS / cert-manager 와 충돌. 첫 미팅에서 현재 ingress class, DNS provider, cert-manager 버전 확인 필수
• 도입 시간: helm install + 검증 = 1~2 일

환경 3 — VMware vSphere, OVA template 선호

대규모 데이터센터 운영 환경. VMware vSphere 가 표준. VM 을 OVA template 로 받는 워크플로우 에 익숙.

• 고객 프로필: 대기업 IT, 일부 금융 그룹, 방산 (IT 인력 200+)
• 최소 요구: vSphere 7.0+, OVA 배포 권한, 내부 DNS 등록 가능, NTP 서버 도달 가능
• 우리 도입 경로: OVA template 제공. vCenter 에서 deploy → 5분 후 부팅 → 자동 초기 설정 → 첫 로그인. cloud-init 으로 IP·DNS·hostname 자동 설정
• 함정: VMware tools 버전 호환성. resource pool / DRS 정책 사전 합의. 일부 환경에서 vmxnet3 드라이버 이슈
• 도입 시간: OVA 받음 → 첫 로그인 30분

환경 4 — OpenShift

RedHat OpenShift 도입 기관. Operator 패턴 이 표준. 일반 Helm chart 가 security context constraints 와 충돌.

• 고객 프로필: 통신사, 일부 금융사, 공공기관 RHEL 표준 채택
• 최소 요구: OpenShift 4.13+, Operator install 권한, image stream, 내부 registry
• 우리 도입 경로: OpenShift Operator 제공. OperatorHub 또는 internal CatalogSource 로 설치. SCC 호환 image (non-root + readonly rootfs)
• 함정: RHACM 통합 요구사항이 자주 추가됨. FIPS 모드 활성화 환경 — FIPS-validated base image 필요 (별도 인증)
• 도입 시간: Operator install + CR 적용 = 2~4시간

환경 5 — Air-gapped + VM only

가장 엄격한 환경. 인터넷 연결 0. VM 1~3대 로 완전 자급자족.

• 고객 프로필: 방산, 일부 공공 (보안 등급 높은 망), 핵심 금융 인프라
• 최소 요구: VM 1대, 전송 영역(transit zone) 으로의 단방향 file transfer 가능, 시간 동기화 (내부 NTP)
• 우리 도입 경로: offline tarball 제공. tarball 안에 모든 컨테이너 이미지 + Helm chart + 의존성 + verification script 포함. installer 가 오프라인 검증 + 내부 registry push + 배포 자동화
• 함정: CVE DB / 보안 패치 의 별도 sync 절차 필요 (→ 폐쇄망 CVE 미러 설계). 라이선스 갱신 도 오프라인 — 분기 1회 암호화 라이선스 파일 수령 절차
• 도입 시간: tarball 수령 → 첫 로그인 반나절~1일

5 환경의 결정 — 어떤 경로로 들어가나

환경                   | 우리 default 경로     | 다음 옵션
─────────────────────┼─────────────────────┼──────────────
1. VM only            | 단독 VM (k3s 내장)   | 환경 2 로 업그레이드 경로
2. 기존 k8s           | Helm chart           | 환경 4 (OpenShift) 옵션
3. VMware vSphere    | OVA template         | 환경 2 로 마이그레이션 가능
4. OpenShift          | Operator             | 환경 5 (FIPS) 옵션
5. Air-gapped         | offline tarball      | (가장 엄격, 다음 단계 없음)

5 환경 모두 동일한 CollabOps 다. 다만 진입 포장 이 다름. 고객은 자기 환경에 맞는 경로 하나만 선택하면 됨.

17 PoC 의 환경 분포

환경 1 (VM only)         | 6
환경 2 (기존 k8s)        | 4
환경 3 (vSphere)          | 3
환경 4 (OpenShift)        | 2
환경 5 (air-gapped)       | 2

환경 1 이 35%. 글로벌 SaaS / DevOps 시장에서는 없다고 가정 하는 환경. 우리에게는 최대 시장.

핵심 — 고객의 인프라 전문성을 가정하지 않는다

위 5 환경 모두에 들어가는 기술적 핵심 은 최소 요구사항 의 정의에 있음. → 최소 요구사항으로 어떤 환경이든 들어가기 에서 그 내부를 다룸.

어디든 들어갈 수 있다 는 게 영업 메시지 가 아니라 제품 설계 결정 이어야 한다.

누가 이 글을 읽으면 좋은가

지금 온프레 도입을 검토 중 인 고객사 IT 책임자. 위 5 분류 중 우리 환경이 어디인지 식별하면, 다음 미팅에서 정확한 도입 경로 를 바로 받을 수 있음. 미리 식별 안 하고 들어가면 3~4번 의 미팅이 환경 정의 에 쓰임.