프라이빗클라우드 구축 비용 2026, VCF·Azure Local·Outposts 견적 기준
프라이빗클라우드 구축 비용은 서버 견적서 한 장으로 끝나지 않는다.
가상화 라이선스, 스토리지 복제, 백업 복구, 네트워크 이중화, 보안 로그, 운영 인력까지 묶어야 실제 예산이 보인다.
이 글은 VMware Cloud Foundation, Azure Local, AWS Outposts, OpenShift, Nutanix 같은 선택지를 같은 표에 넣고 구매팀과 플랫폼팀이 먼저 확인할 기준을 정리한다.
- 프라이빗클라우드는 장비 구매가 아니라 3년 이상 운영 책임을 사는 결정이다.
- 공식 가격표 숫자는 Azure Local 60일 체험, Outposts 3년 term, Storage Gateway $125 상한처럼 비용 단위를 잡는 데 써야 한다.
- VCF와 Nutanix처럼 견적형 상품은 공개 단가보다 라이선스 범위, CPU core, 지원 조건, 업그레이드 권리를 먼저 고정해야 한다.
- 이 조건이면 검토하고, 운영 인력과 복구 테스트가 비어 있으면 보류한다.
이 글이 필요한 사람
- 데이터센터 장비 교체와 클라우드 전환 사이에서 예산안을 만들어야 하는 인프라 책임자
- VMware Cloud Foundation, Azure Local, AWS Outposts, OpenShift, Nutanix를 한 번에 비교해야 하는 구매 담당자
- 공공, 금융, 제조 환경처럼 데이터 위치와 지연시간 조건 때문에 public cloud 단독 전환이 어려운 보안팀
- 서버 구매비보다 운영 인력, 백업, 로그, 패치 실패 비용이 더 걱정되는 플랫폼팀
30초 결론: 먼저 보류할 조건
프라이빗클라우드는 하드웨어를 싸게 사는 프로젝트가 아니다.
데이터 위치, 지연시간, 기존 라이선스, 24시간 운영 책임 중 최소 두 가지 이유가 명확할 때만 검토할 가치가 있다.
| 조건 | 검토 계속 | 보류 신호 | 확인 책임 |
|---|---|---|---|
| 데이터 위치 | 사내 또는 국내 시설 보관 근거가 문서화됨 | 규제 이유 없이 막연히 내부 보관을 선호함 | 보안팀 |
| 워크로드 안정성 | VM, DB, 파일 서버 사용량이 12개월 이상 예측 가능함 | 개발 테스트처럼 수요가 계속 흔들림 | 플랫폼팀 |
| 운영 인력 | 가상화, 네트워크, 스토리지, 보안 담당 owner가 지정됨 | 벤더가 다 해줄 것이라는 기대만 있음 | 인프라 책임자 |
| 비용 비교 | 3년 TCO와 public cloud 기준선이 같은 단위로 있음 | 서버 구매가만 보고 절감이라고 판단함 | 재무팀 |
공식 가격표 핵심 숫자부터 본다
비용 글에서 가장 위험한 실수는 견적형 상품이라는 이유로 숫자를 빼는 것이다.
공식 문서의 숫자는 최종 가격이 아니라 견적 단위를 고정하는 기준으로 써야 한다.
| 출처 | 공식 숫자 | 견적에 반영할 뜻 | 빠지면 생기는 문제 |
|---|---|---|---|
| Azure Local | 등록 후 첫 60일 free trial, 이후 physical core/month 기준 | core 수와 호스트 유형을 월액 단위로 묶어 비교한다 | CPU core 산정 없이 총액만 받는다 |
| AWS Outposts rack | 3-year term, All Upfront·Partial Upfront·No Upfront 선택 | 설치 24시간 뒤부터 월 비용이 시작되는 조건을 본다 | 도입 지연과 월 비용 시작일이 따로 논다 |
| AWS Outposts EBS | 11TB, 33TB, 55TB tier와 15TB·20TB 증설 단위 | 스토리지는 초기 용량보다 증설 곡선이 예산을 만든다 | 1년 뒤 증설 단가가 갑자기 튄다 |
| AWS Storage Gateway | Tape Gateway는 최대 $125.00/gateway/month, 첫 100GB written free | 백업 연계 비용은 gateway 수와 데이터 유입량으로 나눈다 | 백업을 무료 부가 기능처럼 본다 |
| AWS Storage Gateway | 같은 region EC2 appliance로 나가는 전송은 $0.00/GB | 동일 region 설계와 외부 전송 설계를 분리한다 | 데이터 이동 경로가 바뀌면 비용표가 틀어진다 |
| Azure Arc | Inventory, Manage, VM Self-service 항목은 FREE | 제어 plane 자체와 보안·모니터링 add-on을 분리한다 | 무료 항목과 유료 보안 서비스를 섞어 본다 |
| Red Hat OpenShift | reserved instance는 4vCPU·3년 기준 $0.076/hour부터 제시됨 | 컨테이너 플랫폼은 노드 크기와 계약 기간을 같이 봐야 한다 | VM 비용과 플랫폼 비용을 중복 계산한다 |
이 표만으로 최종 견적을 확정하면 안 된다.
다만 벤더 견적서가 들어왔을 때 단위가 core, rack, gateway, storage tier, worker node 중 무엇인지 검증하는 기준으로는 충분하다.
프라이빗클라우드 구축비를 7개 바구니로 쪼갠다
구축비를 하드웨어와 소프트웨어로만 나누면 거의 항상 운영 예산이 빠진다.
| 비용 바구니 | 포함 항목 | 초기비/반복비 | 검토 질문 |
|---|---|---|---|
| 하드웨어 | 서버, HCI 노드, NIC, 스토리지, 랙, 예비 부품 | 초기비와 교체비 | 3년 뒤 증설 가능한 chassis와 전력 여유가 있는가 |
| 플랫폼 라이선스 | VCF, OpenShift, Nutanix, 백업, 모니터링, 보안 기능 | 대부분 반복비 | CPU core와 노드 수가 견적서 기준과 일치하는가 |
| 데이터센터 | 전력, 냉각, 상면, 회선, 물리 보안 | 반복비 | 피크 전력과 UPS 여유가 현재 수치로 확인됐는가 |
| 운영 인력 | 가상화, 네트워크, 스토리지, 보안, SRE on-call | 반복비 | 장애 담당자가 벤더와 내부 중 누구인지 적혀 있는가 |
| 백업·DR | 스냅샷, off-site 복제, 복구 테스트, 장기 보관 | 초기비와 반복비 | RPO와 RTO를 실제 복구 drill로 확인했는가 |
| 보안·감사 | IAM, 로그 보존, 취약점 scan, 네트워크 분리, 사고 대응 | 반복비 | 보안팀이 증거를 받을 위치와 보존 기간이 있는가 |
| 마이그레이션 | VM 이전, DB 이전, 테스트, 교육, 운영 runbook | 초기비 | 실패하면 public cloud나 기존 센터로 되돌릴 계획이 있는가 |
이 조건이면 검토할 수 있다.
서버 구매가가 public cloud 예상액보다 낮고, 위 7개 바구니를 더해도 3년 TCO가 낮으면 다음 단계로 넘어간다.
이 경우는 보류하는 편이 낫다.
운영 인력 비용을 0원으로 놓거나 백업 복구 테스트를 연 0회로 둔 계산서는 실제 장애 비용을 숨긴다.
VCF, Azure Local, Outposts, OpenShift는 역할이 다르다
같은 프라이빗클라우드 후보라도 제품이 해결하는 문제가 다르다.
| 선택지 | 맞는 상황 | 비용을 키우는 축 | 보류할 신호 |
|---|---|---|---|
| VMware Cloud Foundation | 기존 VMware 운영 경험과 vSphere 기반 표준이 강한 조직 | core license, support, storage, network 가상화 범위 | 라이선스 갱신 조건과 upgrade 권리가 불명확함 |
| Azure Local | 온프레미스 VM과 일부 Azure control plane을 같이 쓰려는 조직 | physical core, Arc add-on, Windows/SQL 조건, 지원 계약 | core 수와 add-on 범위를 분리하지 못함 |
| AWS Outposts | AWS 운영 방식을 시설 내부 또는 edge에 두어야 하는 조직 | rack 구성, 3년 term, EBS/S3 on Outposts, 설치 후 월 비용 | 네트워크 회선과 설치 공간 승인 전에 발주함 |
| Red Hat OpenShift | container 표준화와 hybrid Kubernetes 운영이 핵심인 조직 | worker node, support, managed option, logging stack | VM 이전이 주목적인데 container 전환 계획이 없음 |
| Nutanix Cloud Platform | HCI 기반 운영 단순화와 사내 VM 표준화가 필요한 조직 | node 증설, storage, management suite, support | 스토리지 growth와 snapshot 정책을 계산하지 않음 |
VCF는 기존 가상화 운영 체계를 크게 흔들지 않는 장점이 있다.
반대로 라이선스와 지원 범위가 견적 중심이라 공개 단가만으로 총액을 판단하기 어렵다.
Azure Local은 Microsoft 생태계와 Arc 운영을 묶어 볼 때 의미가 있다.
다만 무료 control plane과 유료 보안·모니터링 서비스를 분리해서 봐야 비용 착시가 줄어든다.
Outposts는 AWS 운영 표준을 내부 위치에 가져오는 방식이다.
설치, term, storage tier, 회선 조건이 강하게 묶이므로 단기 실험용으로 보면 무겁다.
실무 시나리오 1: 금융 데이터센터 교체
금융사는 데이터 위치와 감사 증거 때문에 public cloud 단독 전환을 바로 결정하기 어렵다.
이 조건이면 프라이빗클라우드 검토가 맞다.
- 고객 식별 데이터와 내부 업무 DB가 같은 보안 zone에 남아야 한다.
- VM 수요가 3년 동안 크게 변하지 않고 야간 batch peak가 예측된다.
- 기존 VMware 운영자가 있고 패치와 장애 runbook을 이미 갖고 있다.
- 감사 로그와 백업 증거를 보안팀이 직접 확인해야 한다.
이 경우는 서버 교체 견적만으로 결정하면 안 된다.
랙 전력, 백업 소산, 보안 로그 보존, 라이선스 갱신, 재해복구 drill 비용을 같은 비교표에 넣어야 한다.
실무 시나리오 2: 제조 edge와 공장 네트워크
제조사는 공장 설비와 지연시간 때문에 edge 위치에 계산 자원을 둬야 할 때가 있다.
Outposts나 Azure Local을 검토하더라도 먼저 물어볼 질문은 제품명이 아니다.
- 공장 회선 장애 시 어느 업무가 멈추면 안 되는가.
- 설비망과 업무망 사이에서 로그와 patch 파일이 어떻게 이동하는가.
- 현장 인력이 서버 reboot와 물리 교체를 어디까지 처리할 수 있는가.
- 중앙 클라우드로 되돌릴 exit path가 설계돼 있는가.
이 조건이면 검토를 계속한다.
현장 지연시간과 독립 운영 요구가 문서로 확인되고, 중앙팀이 보안 patch와 image 배포를 원격으로 통제할 수 있으면 후보가 된다.
실무 시나리오 3: 개발 플랫폼 내재화
개발팀이 Kubernetes와 internal platform을 원하면 OpenShift나 자체 Kubernetes를 같이 비교하게 된다.
이때 비용 비교는 VM 단가보다 플랫폼 운영 성숙도가 먼저다.
- cluster upgrade를 분기별로 리허설할 수 있는가.
- namespace, quota, registry, image scan, secret 관리 owner가 정해졌는가.
- observability와 log 저장 비용을 tenant별로 나눌 수 있는가.
- 개발팀 self-service 요청이 보안 승인 흐름과 충돌하지 않는가.
이 경우는 보류한다.
개발팀 요청은 container인데 실제 워크로드는 대부분 기존 Windows VM이고, platform team이 cluster 장애를 처리할 사람이 없으면 구축보다 managed service가 낫다.
도입 전 실전 절차
- 12개월 VM, DB, 파일 서버, batch, container 사용량을 CPU, memory, storage, network peak로 뽑는다.
- public cloud 기준선을 먼저 만든 뒤 같은 업무 범위로 private cloud 3년 TCO를 맞춘다.
- 후보 제품별로 core, node, rack, gateway, worker node 같은 과금 단위를 견적서에 표시하게 한다.
- 전력, 냉각, 상면, 회선, 물리 보안 여유를 시설팀 숫자로 받는다.
- 백업 복구 테스트와 보안 로그 보존 기간을 비용표에 넣는다.
- 장애 drill, patch window, upgrade rehearsal을 운영 달력에 넣고 owner를 정한다.
- 계약 전 exit plan을 작성하고 데이터 이전 시간과 임시 이중 운영비를 따로 계산한다.
실무에서는 2번과 3번이 가장 많이 틀린다.
public cloud는 사용량 변동과 managed service 이점이 들어가는데, private cloud는 고정 자산과 사람 비용을 빼고 비교하기 때문이다.
보안과 운영 리스크는 비용표의 일부다
프라이빗클라우드는 내부에 두면 자동으로 안전해지는 구조가 아니다.
패치, 취약점 scan, 권한 분리, backup immutable 보관, 로그 보존을 운영할 사람이 없으면 보안 부채가 사내 시설 안에 쌓인다.
| 리스크 | 확인 항목 | 비용 영향 | 차단 기준 |
|---|---|---|---|
| 권한 집중 | 가상화 관리자와 보안 감사 권한 분리 | PAM, MFA, 감사 로그 비용 증가 | 관리자 1명이 모든 계층을 열 수 있음 |
| 패치 지연 | host, storage, network, container platform patch 달력 | 야간 작업과 검증 인력 비용 증가 | 패치 owner와 rollback 기준 없음 |
| 백업 착시 | snapshot과 off-site backup 구분 | 소산 저장소와 복구 drill 비용 증가 | snapshot만 있고 복구 테스트 없음 |
| 관측성 부족 | metric, log, trace, alert retention | 로그 저장과 관제 도구 비용 증가 | 장애 후 원인 추적 위치 없음 |
| 퇴거 실패 | 데이터 export, image 변환, DNS 전환 계획 | 이중 운영과 이전 작업 비용 증가 | 계약 종료 전 이전 경로가 없음 |
이 조건이면 구매를 멈춘다.
보안팀이 증거를 받을 위치를 모른다면 구축 완료일보다 감사 실패일이 먼저 올 수 있다.
비용 산정 스켈레톤
아래 스켈레톤은 바로 실행해 예산을 확정하는 코드가 아니다.
벤더 견적서 숫자와 공식 가격표 단위를 같은 구조에 넣기 위한 검토용 틀이다.
# private-cloud-cost-plan.yaml
# 목적: 프라이빗클라우드 구축 견적을 하드웨어, 플랫폼, 운영, 보안 증거 단위로 분리한다.
# 실제 가격은 벤더 견적서와 공식 가격표, 환율, 계약 조건으로 다시 확인한다.
project:
name: private-cloud-review-2026
owner: platform-team
workload_scope:
vm_count: 120
container_node_count: 18
protected_data_grade: internal-confidential
target_availability: zone-level-failure-survival
cost_buckets:
hardware:
compute_nodes: required
storage_nodes: required
network_switches: required
spare_capacity_percent: 20
platform:
virtualization_or_hci_license: quote_required
kubernetes_platform: optional
hybrid_control_plane: azure_arc_or_equivalent
operations:
sre_on_call: required
backup_restore_test: quarterly
patch_window: monthly
security:
identity_integration: required
logging_retention_days: 180
vulnerability_scan: required
incident_drill: twice_per_year
decision_gate:
approve_if:
- three_year_tco_lower_than_public_cloud_baseline
- data_residency_or_low_latency_need_is_documented
- backup_and_exit_plan_has_owner
pause_if:
- license_quote_is_missing
- rack_power_or_cooling_limit_is_unknown
- platform_team_cannot_run_upgrade_drills
TCO 계산은 한 번만 해서는 의미가 없다.
hardware 20% 증설, platform license 15% 상승, 운영 인력 1명 추가 같은 민감도도 같이 돌려야 한다.
# private_cloud_tco_check.py
# 견적 비교용 안전 스켈레톤이다.
# 입력값은 벤더 견적서와 공식 가격표에서 채운 뒤 내부 검토에만 쓴다.
from dataclasses import dataclass
@dataclass
class CostInput:
hardware_krw: int
platform_license_krw_per_year: int
support_krw_per_year: int
power_cooling_krw_per_year: int
operations_people_krw_per_year: int
backup_security_krw_per_year: int
migration_krw_once: int
years: int = 3
def three_year_tco(item: CostInput) -> int:
recurring = (
item.platform_license_krw_per_year
+ item.support_krw_per_year
+ item.power_cooling_krw_per_year
+ item.operations_people_krw_per_year
+ item.backup_security_krw_per_year
) * item.years
return item.hardware_krw + item.migration_krw_once + recurring
def private_cloud_review(private_tco: int, public_cloud_baseline: int, risk_buffer_percent: int = 15) -> str:
adjusted = int(private_tco * (1 + risk_buffer_percent / 100))
if adjusted < public_cloud_baseline:
return '검토 계속: 위험 완충을 더해도 기준 비용보다 낮다.'
return '보류: 비용만 보면 public cloud 또는 managed service 재검토가 필요하다.'
구매 승인 문서에는 숫자보다 누가 책임지는지가 더 중요할 때가 있다.
{
"private_cloud_review": {
"finance_owner": "CFO 또는 구매 담당자",
"platform_owner": "인프라 플랫폼 팀",
"security_owner": "보안 책임자",
"must_have_evidence": [
"3년 TCO 비교표",
"랙 전력과 냉각 여유",
"라이선스 견적서와 갱신 조건",
"백업 복구 테스트 결과",
"보안 로그 보존 정책",
"퇴거와 데이터 이전 계획"
]
}
}
구매팀에 넘길 비교표
| 질문 | 구매팀 답변 형식 | 기술팀 확인 | 결정 기준 |
|---|---|---|---|
| 라이선스 단위는 무엇인가 | core, node, rack, gateway, worker node 중 하나로 표시 | 실제 inventory와 일치 여부 | 단위가 불명확하면 재견적 |
| 3년 총액에 무엇이 빠졌나 | 지원, upgrade, 보안 기능, 교육, 설치비 별도 표시 | 운영 runbook에 필요한 항목 확인 | 별도 항목이 20% 넘으면 위험 |
| 증설 단가는 어떻게 바뀌나 | storage tier와 node 증설 구간 표시 | 12개월 growth와 비교 | 증설 구간이 업무 증가와 맞아야 함 |
| 장애 시 누가 대응하나 | 벤더 SLA와 내부 on-call 분리 | incident drill owner 확인 | 내부 owner 없으면 보류 |
| 퇴거 비용은 얼마인가 | 데이터 export와 임시 이중 운영 범위 표시 | migration test 가능 여부 확인 | exit path 없으면 계약 전 중단 |
프라이빗클라우드 구축 비용의 핵심은 싸게 사는 기술이 아니다.
조직이 3년 동안 같은 표준을 운영할 수 있는지, 그리고 실패했을 때 되돌릴 비용을 감당할 수 있는지 보는 결정이다.
함께 보면 좋은 글
FinOps 도입 2026, 클라우드 비용 줄이기 전 책임·태그·운영 기준
쿠버네티스 운영 비용 2026, 클러스터·노드·로그 비용 줄이는 기준
서버호스팅 비용 2026, VPS·클라우드·트래픽 예산 기준
AI 서버 구축 비용 2026, 온프레미스·임대·클라우드 예산 기준
CNAPP 도입 2026, CSPM·CWPP 통합 전 비용·보안·운영 기준
클라우드 비용 최적화 2026, AWS 비용 줄이기 전 확인할 운영 기준자주 묻는 질문
프라이빗클라우드 구축 비용은 서버 구매비가 가장 큰가요?
초기에는 서버 구매비가 커 보이지만 3년 기준으로는 라이선스, 지원, 전력, 백업, 보안 로그, 운영 인력이 더 큰 차이를 만든다.
Azure Local과 AWS Outposts는 같은 선택지인가요?
둘 다 사내 또는 edge 위치에 cloud 운영 방식을 가져오는 후보지만, Azure 생태계 연계와 AWS rack term 구조가 달라 같은 표에서 단위부터 분리해야 한다.
VMware Cloud Foundation은 공개 가격표가 없으면 비교가 불가능한가요?
불가능하지 않지만 core, 지원 범위, upgrade 권리, storage와 network 가상화 포함 여부를 견적서에 분리해서 받아야 한다.
OpenShift는 프라이빗클라우드 비용표에 왜 들어가나요?
VM 중심 구축이 아니라 container platform 내재화가 목표라면 worker node, support, logging, registry 비용이 실제 예산을 바꾸기 때문이다.
프라이빗클라우드가 public cloud보다 항상 저렴한가요?
아니다.
사용량이 흔들리거나 운영 인력이 부족하면 public cloud managed service가 더 낮은 총비용이 될 수 있다.
구축 전에 반드시 테스트할 항목은 무엇인가요?
복구 테스트, patch rollback, 보안 로그 조회, 권한 회수, storage 증설, 회선 장애 전환을 계약 전 또는 pilot 단계에서 확인해야 한다.
출처와 확인일
- VMware — VMware Cloud Foundation private cloud platform (확인일: 2026-07-28)
- VMware Docs — VMware Cloud Foundation documentation (확인일: 2026-07-28)
- Microsoft Azure — Azure Local pricing (확인일: 2026-07-28)
- Microsoft Azure — Azure Arc pricing (확인일: 2026-07-28)
- AWS — AWS Outposts racks pricing (확인일: 2026-07-28)
- AWS — AWS Storage Gateway pricing (확인일: 2026-07-28)
- Red Hat — Red Hat OpenShift pricing (확인일: 2026-07-28)
- Nutanix — Nutanix Cloud Platform (확인일: 2026-07-28)
- Kubernetes — Kubernetes overview (확인일: 2026-07-28)
위 출처는 2026-07-28 기준으로 확인했으며, 가격표와 기능 범위는 지역, 계약, 환율, 제품 업데이트, 지원 등급에 따라 달라질 수 있다.
이 글은 일반적인 프라이빗클라우드 구축 비용 검토 자료이며, 실제 구매와 보안 판단은 공식 문서, 벤더 견적서, 내부 보안 책임자, 재무 담당자의 검토를 기준으로 최종 확정해야 한다.
댓글
댓글 쓰기