[OpenStack 비용] 자체 구축 vs 퍼블릭 클라우드 1년 운영비를 정확하게 계산하는 방법

홈랩이든 사내 서비스든, 인프라를 오래 운영하다 보면 결국 한 번은 OpenStack 비용 계산으로 돌아오게 됩니다. 저도 처음엔 “서버 몇 대 사서 돌리면 퍼블릭보다 무조건 싸지 않나?” 싶었거든요. 근데 1년 단위로 운영비를 쪼개서 보니까 생각보다 단순하지 않더라고요. 하드웨어 구입비만 보는 순간 계산이 틀어지고, 반대로 퍼블릭 클라우드는 눈앞의 월 과금만 보고 있으면 장기 비용 구조가 제대로 보이지 않습니다. 이번 글에서는 제가 실제로 프라이빗 클라우드를 설계하고, 퍼블릭 클라우드 청구서를 뜯어보면서 정리했던 방식으로 클라우드 비용 비교를 해볼 텐데, 핵심은 “어떤 항목을 넣어야 제대로 된 비용이 나오는가”입니다.

특히 주의할 점! 비용은 항상 구매비 + 운영비 + 장애 대응비 + 인력비를 같이 봐야 정확해집니다. 숫자만 보면 틀리는 이유가 여기 있어요.

OpenStack 프라이빗 클라우드와 퍼블릭 클라우드의 비용 항목을 한눈에 보여주는 개요 이미지입니다.

OpenStack 비용 계산이 자꾸 틀어지는 이유

쉽게 말해 OpenStack은 소프트웨어 자체보다 운영 모델이 비용을 결정하는데요. Compute(컴퓨트, 가상 머신), Network(네트워크, 가상 네트워크), Storage(스토리지, 블록/오브젝트 저장소) 같은 걸 직접 운영하니까, 퍼블릭 클라우드처럼 사용량 기반 청구서가 깔끔하게 나오지 않습니다. 대신 내가 놓친 비용이 뒤늦게 튀어나오는 경우가 많아요. 저도 처음엔 장비 감가상각만 넣고 끝냈다가, 스위치 전력과 예비 디스크 비용에서 삽질을 좀 했습니다.

반대로 퍼블릭 클라우드는 과금 체계가 복잡하거든요. 인스턴스 비용은 보이는데, 스냅샷, 데이터 전송, 로드밸런서, 유휴 IP, 매니지드 백업이 조용히 붙습니다. 그래서 퍼블릭 클라우드 비용은 “월 요금”이 아니라 “실제로 굴러가며 발생하는 총소유비용(TCO, Total Cost of Ownership)”으로 봐야 정확해요.

비용 분석 전에 먼저 잡아야 할 기준

• 워크로드 성격: 항상 켜져 있는지, 낮밤 편차가 큰지
• 성능 요구사항: CPU 중심인지, 메모리 중심인지, 스토리지 IOPS 중심인지
• 운영 인력: 플랫폼 운영 담당자가 있는지
• 가용성 목표: 장애 허용 범위가 어느 정도인지
• 확장 방식: 1년에 몇 번 증설하는지, 매달 자동 확장이 필요한지

이 기준 없이 숫자부터 비교하면 거의 항상 결론이 흔들려요. 특히 프라이빗 클라우드 비용은 유휴 자원을 감수하고 안정성을 살 것인지, 아니면 장비를 빡빡하게 써서 효율을 올릴 것인지에 따라 체감이 완전히 달라집니다.

1년 운영 비용을 나누는 현실적인 방법

제가 실제로 써본 결과, 비용 항목을 아래처럼 5개 묶음으로 나누는 게 가장 헷갈리지 않더라고요. 회계팀과 이야기할 때도 이 방식이 잘 통합니다.

1. 초기 자본 지출(CAPEX, Capital Expenditure): 서버, 스토리지, 스위치, 랙, UPS
2. 운영 지출(OPEX, Operational Expenditure): 전력, 회선, 상면, 유지보수
3. 플랫폼 운영비: 설치, 업그레이드, 백업, 모니터링, 장애 대응
4. 서비스 부가비용: 로드밸런서, 백업, DR(재해복구), 로그 보관
5. 숨은 비용: 유휴 자원, 러닝커브, 야간 장애 대응, 벤더 의존도

OpenStack 자체 구축과 퍼블릭 클라우드 비용 비교

표만 보면 답이 쉬워 보이죠. 근데 실제 판단은 워크로드 패턴이 좌우해요. 예를 들어 사내 업무 시스템처럼 24시간 비슷한 부하가 유지되면 OpenStack ROI를 계산해 볼 만합니다. 반대로 이벤트성 트래픽이나 시즌성 서비스라면 퍼블릭 쪽이 더 깔끔한 경우가 많습니다.

실전 구현: 1년 비용 계산용 데이터 모으기

이제 실전이에요. 비용 분석을 감으로 하면 안 되거든요. 최소한 현재 자원 사용량과 앞으로 1년간 유지될 패턴을 뽑아야 하는데, 저는 보통 현재 사용량 수집 – 단가 정의 – 시나리오 계산 순서로 갑니다.

1. 현재 OpenStack 자원 현황 확인

먼저 실제로 얼마나 쓰고 있는지 확인해요. 아래 명령은 OpenStack CLI 기준으로 많이 쓰는 기본 점검입니다.

openstack server list --all-projects
openstack hypervisor list
openstack hypervisor stats show
openstack volume service list
openstack network list
openstack floating ip list

이 단계에서 보는 포인트는 단순 개수보다 과할당 비율(overcommit ratio), 스토리지 여유율, 네트워크 외부 연결 수예요. 처음엔 VM 수만 세고 끝냈었는데, 실제 비용은 스토리지 복제본과 백업 보관량이 더 크게 작용하더라고요.

2. 하드웨어와 운영 단가를 변수로 분리

비용표를 엑셀로 관리해도 되지만, 저는 재현성을 위해 간단한 변수 파일로 빼는 걸 선호해요. 계산식이 눈에 보이면 팀 설득도 편하거든요.

openstack_cost_model:
  capex:
    servers: 0
    storage: 0
    network: 0
    rack_power: 0
  opex_yearly:
    electricity: 0
    colocation_or_space: 0
    maintenance: 0
    spare_parts: 0
  labor:
    platform_engineer_monthly: 0
    oncall_overhead_monthly: 0
  public_cloud:
    compute_monthly: 0
    storage_monthly: 0
    data_transfer_monthly: 0
    managed_service_monthly: 0

여기서 숫자를 바로 넣기보다, 각 항목이 왜 필요한지 팀 안에서 먼저 합의하는 게 중요해요. 예를 들어 플랫폼 엔지니어 인건비를 100% 넣을지, 여러 업무 중 일부 비율만 반영할지는 조직마다 다르거든요.

3. 1년 비용 계산 스크립트 만들기

간단한 계산은 파이썬으로 돌리면 편해요. 아래 예시는 숫자를 채워 넣는 틀인데, 특정 제품 가격을 가정하지 않고도 구조를 검증할 수 있습니다.

capex = {
    "servers": 0,
    "storage": 0,
    "network": 0,
    "rack_power": 0,
}

opex_yearly = {
    "electricity": 0,
    "colocation_or_space": 0,
    "maintenance": 0,
    "spare_parts": 0,
}

labor_yearly = {
    "platform_engineer": 0,
    "oncall_overhead": 0,
}

public_cloud_yearly = {
    "compute": 0,
    "storage": 0,
    "data_transfer": 0,
    "managed_service": 0,
}

openstack_total = sum(capex.values()) + sum(opex_yearly.values()) + sum(labor_yearly.values())
public_total = sum(public_cloud_yearly.values())

diff = openstack_total - public_total

print(f"OpenStack yearly total: {openstack_total}")
print(f"Public cloud yearly total: {public_total}")
print(f"Difference: {diff}")

이거 진짜 편하더라고요. 항목 하나 추가할 때도 구조가 안 깨지고, 시나리오를 여러 개 돌릴 수 있어요. 예를 들면 기본 운영 시나리오, 30% 성장 시나리오, 장애 대비 이중화 강화 시나리오로 나눠 계산해볼 수 있습니다.

비용 산정용 변수 파일과 OpenStack 자원 수집 흐름을 설명하는 구성 이미지입니다.

실전 판단 기준: 어떤 워크로드가 어디에 유리할까?

여기서 많은 분이 궁금해하는 게 바로 이거에요. “그래서 언제 OpenStack이 이득이냐?” 제 경험상 아래처럼 보면 꽤 정확했습니다.

OpenStack 자체 구축이 유리한 경우

• VM이 24시간 꾸준히 돌아가고 사용량 변동이 적을 때
• 데이터 전송량이 많아 퍼블릭 egress 비용이 부담될 때
• 보안, 규제, 내부 통제가 중요한 워크로드일 때
• 이미 운영 인력과 장비 조달 체계가 있을 때
• 장기적으로 3년 이상 같은 플랫폼을 유지할 계획일 때

퍼블릭 클라우드가 유리한 경우

• 트래픽 급증과 급감이 반복될 때
• 프로젝트 시작이 급하고 장비 구매 리드타임을 기다릴 수 없을 때
• DB, 메시징, 관측성 같은 매니지드 서비스를 적극 활용할 때
• 인프라 전담 인력이 적을 때
• 실험성 서비스가 많아 빨리 만들고 빨리 접어야 할 때

결국 클라우드 비용 비교는 단가 싸움이 아니라 운영 형태의 싸움이에요. 제가 직접 해보니, OpenStack은 잘 맞는 조직에선 정말 강력합니다. 대신 안 맞는 조직에선 플랫폼 자체가 팀의 병목이 됩니다.

⚠️ 주의사항: OpenStack 비용 계산에서 자주 빠지는 것들

여기서부터가 진짜 중요한데요. 표면적인 계산은 누구나 할 수 있지만, 실무에선 빠지는 항목 때문에 결과가 자꾸 낙관적으로 나옵니다.

1. 인력비를 너무 낮게 잡는 문제

OpenStack은 설치보다 운영이 어려워요. 업그레이드, 인증서, 네트워크 이슈, 스토리지 재동기화 같은 작업이 은근히 손이 많이 갑니다. 저도 처음엔 “자동화해두면 되겠지” 했었는데, 실제로는 장애 한 번 나면 로그 추적과 서비스 상관관계 파악에 시간이 꽤 들어가더라고요. 그래서 플랫폼 운영 인력비는 반드시 별도 항목으로 넣어야 합니다.

2. 유휴 자원을 비용에서 빼는 문제

HA(고가용성)를 하려면 여유 자원이 필요해요. N+1 정도만 잡아도 체감이 다르거든요. 그런데 계산표에는 종종 실제 사용량만 넣고, 예비 노드와 여유 스토리지 공간은 빼버립니다. 그러면 프라이빗 클라우드 비용이 과도하게 낮아 보이는 거죠.

3. 퍼블릭 클라우드의 부가 과금을 빼먹는 문제

반대로 퍼블릭 쪽은 데이터 전송, 백업 스냅샷, 로드밸런서, NAT, 모니터링, 로그 저장을 빼먹기 쉬워요. 특히 멀티 AZ(가용 영역) 구성과 백업 보존 정책이 들어가면 체감 비용이 확 올라갑니다.

4. 감가상각과 교체 주기를 무시하는 문제

1년 비용만 본다고 해도, 장비 교체 주기와 잔존 가치는 같이 생각해야 해요. 예를 들어 올해 장비를 샀다면 내년엔 CAPEX 부담이 줄어드는 대신, 디스크 교체나 유지보수 비중이 올라갈 수 있습니다. 즉 1년 분석은 반드시 3년 그림과 연결해서 봐야 정확해집니다.

트러블슈팅: 제가 실제로 겪었던 삽질 포인트

이 부분은 숫자보다 더 중요할 때가 있는데요. 비용 계산은 맞았는데 운영 현실이 달라서 계획이 어긋나는 경우가 있거든요.

1. 스토리지 복제 비용을 늦게 반영
   처음엔 순수 데이터 용량만 생각했는데, 복제와 백업 보관을 합치니 실제 필요한 디스크가 훨씬 많았어요.
2. 네트워크 장비 전력 소모를 별도 계산 안 함
   서버 전력만 넣어두고 스위치와 부대 장비를 빼먹으면 연간 운영비가 생각보다 차이 나더라고요.
3. 운영 자동화 수준을 과신
   Ansible이나 Terraform을 써도 장애 대응 시간이 0이 되진 않습니다.
4. 퍼블릭의 매니지드 서비스 대체 비용을 과소평가
   퍼블릭에서 쉽게 쓰던 관리형 DB, 로드밸런서, 모니터링을 온프레미스로 대체하려면 생각보다 손이 많이 갔어요.

혹시 이런 경험 있으신가요? 인프라는 항상 “보이는 비용”보다 “운영하면서 드는 손”이 크더라고요. 저도 처음엔 이게 뭔가 싶었는데, 결국 사람 시간까지 숫자로 바꿔 넣어야 판단이 맞더라고요.

검증: 1년 비용 분석 결과를 어떻게 읽어야 하나

계산이 끝났으면 단순 합계만 보지 말고, 아래 세 가지로 나눠서 봐야 해요.

1. 고정비 비중: OpenStack은 고정비가 크고, 퍼블릭은 변동비 비중이 큽니다.
2. 증설 민감도: 사용자 증가 시 어떤 항목이 가장 먼저 튀는지 봐야 해요.
3. 운영 리스크 비용: 장애와 야간 대응이 잦다면 숫자 이상의 부담이 생겨요.

제가 실무에서 보고서를 만들 때는 아래처럼 정리했어요.

이렇게 보면 OpenStack ROI는 “계속 많이 쓰는 자원을 내가 직접 통제할 수 있을 때” 좋아지는 경향이 있어요. 반대로 짧게 쓰고 빨리 바꾸는 서비스는 퍼블릭 쪽이 운영 피로도까지 포함해 더 낫습니다.

OpenStack과 퍼블릭 클라우드의 연간 비용 흐름을 비교한 결과 대시보드 이미지입니다.

정리: OpenStack 비용, 단순 숫자가 아니라 운영 역량이 핵심이에요

정리해보면 이렇습니다. OpenStack 비용은 장기적으로 안정적인 워크로드에선 경쟁력이 있을 수 있어요. 하지만 그 전제는 명확합니다. 운영 인력이 있고, 하드웨어 수급과 장애 대응 체계가 있고, 매니지드 서비스 부재를 감당할 수 있어야 하는 거죠. 퍼블릭은 비싸 보일 때도 있지만, 그 안에는 속도와 유연성, 그리고 플랫폼 운영 부담을 외부화한 가치가 들어 있습니다.

그래서 제 결론은 늘 같아요. 프라이빗 클라우드 비용과 퍼블릭 클라우드 비용은 숫자 한 줄로 비교하면 안 됩니다. 최소 1년 기준으로 봐야 하고, 가능하면 3년 시나리오까지 같이 봐야 정확해요. 특히 OpenStack ROI를 검토하신다면, 장비비보다 먼저 운영 역량부터 냉정하게 체크해보세요. 그게 진짜 분기점입니다.

OpenStack ROI와 클라우드 선택 기준을 한눈에 정리한 요약 인포그래픽입니다.

다음 단계 체크리스트

• 현재 VM, 스토리지, 네트워크 사용량을 3개월 이상 수집해보세요.
• 퍼블릭 청구서에서 데이터 전송, 백업, 로드밸런서 비용을 분리해보세요.
• OpenStack 운영 인력의 실제 투입 시간을 월 단위로 계산해보세요.
• 증설 시나리오와 장애 대비 시나리오를 따로 계산해보세요.
• 이전 글의 홈랩 자동화 사례와 연결해 내부 운영 표준도 같이 점검해보세요. 이 부분은 다음 글에서 다룰 예정입니다.

자주 묻는 질문

Q1. OpenStack은 무조건 퍼블릭보다 저렴한가요?

아닙니다. 고정적이고 장기적인 워크로드엔 유리할 수 있지만, 운영 인력과 유휴 자원 비용을 넣으면 생각보다 차이가 줄어들어요.

Q2. 퍼블릭 클라우드는 왜 예상보다 비싸지나요?

컴퓨트 외에도 스토리지, 전송, 백업, 로드밸런서, 로그 보관 같은 부가 과금이 조용히 누적되기 때문이에요.

Q3. OpenStack ROI는 어떤 기준으로 봐야 하나요?

1년 비용만 보지 말고, 3년 유지 계획과 운영 역량, 장애 대응 체계까지 포함해서 판단해야 정확해요.

Q4. 처음 비교할 때 가장 먼저 할 일은 뭔가요?

현재 사용량과 서비스 패턴을 수집하는 거예요. 숫자보다 먼저 워크로드 특성을 알아야 비교가 맞습니다.

결국 인프라는 “어디가 더 싸냐”보다 “우리 팀이 어디서 더 안정적으로 오래 운영할 수 있냐”가 핵심이에요. 저도 여러 번 돌아보니 답은 항상 워크로드와 팀 구조 안에 있었어요. 이 글이 OpenStack 비용 판단하실 때 기준점이 되면 좋겠습니다.