Blog,Kubernetes Blog

레드햇 오픈시프트 가격 인상에 따른 논란

레드햇이 OpenShift 가격 정책을 코어 기반으로 변경하며 운영 비용이 급증해 논란이 되고 있습니다. 해당 논란을 빠르게 정리해 드립니다!

2025년 04월 09일

레드햇 오픈시프트 가격 인상에 따른 논란

Red Hat OpenShift 재계약 가격 인상 이슈 상세 분석

2025년 상반기, 국내 주요 기업 및 기관들이 Red Hat OpenShift 재계약 과정에서 가격이 최대 300% 이상 인상된 사례를 겪으면서, 업계 전반에 큰 혼란과 반발이 일고 있습니다.

ZDNet Korea와 ITDaily의 보도에 따르면, 이러한 가격 인상은 단순한 물가 상승 수준이 아닌 라이선스 정책 자체의 근본적인 변화에 기인한 것으로 분석됩니다.

가격 인상의 구조적 배경: 소켓 기반 → 물리 코어 기반

기존 Red Hat OpenShift는 소켓(Socket) 기반 라이선스 정책을 적용해 왔습니다. 즉, 물리적 서버에서 CPU 소켓 수를 기준으로 라이선스를 산정했기 때문에, 고코어 CPU를 사용하더라도 비용 증가가 상대적으로 제한적이었습니다.

그러나 최근부터는 물리적 CPU 코어 수 기준의 라이선스 모델로 전환하면서, 다음과 같은 변화가 발생했습니다:

항목 기존 정책 변경 후 정책
기준 CPU 소켓 수 물리 코어 수
비용 영향 고성능 CPU에서 효율적 코어 수 증가 시 비용 급등
예시 2소켓 64코어 서버 128코어 기준으로 계산

이로 인해, 특히 고사양 x86 서버를 활용 중인 대기업, 공공기관, 금융사 등에서 예산 초과 및 재계약 보류 사태가 발생하고 있습니다.

기업과 기관의 반응: “가격이 2억에서 6억으로”

실제 사례로, 국내 모 대기업은 기존 연간 2억 원 수준의 OpenShift 계약을 유지하던 중, 동일한 사용자 수 및 인프라 규모에도 불구하고 재계약 견적이 6억 원 이상으로 증가했다는 내부 보고가 있었습니다.

이 같은 급격한 비용 증가는 다음과 같은 결과를 낳고 있습니다:

  • 재계약 포기 및 라이선스 규모 축소
  • RHEL(Red Hat Enterprise Linux) 또는 CentOS Stream으로 다운그레이드
  • Rancher, VMware Tanzu, Google GKE 등 대체 Kubernetes 솔루션 검토
  • 프라이빗에서 퍼블릭 클라우드로의 워크로드 마이그레이션 고려

또한 일부 공공기관은 기존 예산의 2~3배에 달하는 가격 인상을 수용할 수 없다는 입장을 밝히며, 기술 검토 후 재도입 자체를 중단하거나 최소화하는 사례도 보이고 있습니다.

업계의 해석: 레드햇의 전략적 포지셔닝 변화?

이러한 정책 변화는 Red Hat이 OpenShift를 단순한 오픈소스 플랫폼이 아닌, 프리미엄 엔터프라이즈 솔루션으로 확실히 포지셔닝하려는 전략으로 해석될 수 있습니다. 그러나 이에 대한 설명이나 커뮤니케이션 부족으로 인해, 고객사 입장에서는 사전 고지 없는 일방적 라이선스 변경 및 가격 인상으로 받아들여지고 있습니다.

또한 Red Hat 측은 현재까지 공식적인 입장이나 커뮤니케이션을 언론이나 고객사에 제공하지 않고 있는 상황입니다. 이로 인해 고객들 사이에서는 불신과 이탈 움직임이 더욱 가속화되고 있습니다.

레드햇 OpenShift 라이선스 정책 변경, IT팀들이 대안을 찾는 이유

이 글에서는 레드햇(Red Hat)이 최근에 OpenShift의 라이선스 정책을 변경하면서 많은 기업 IT팀들이 혼란에 빠지고 있는 상황을 다루고 있습니다.

기존에는 OpenShift가 소켓(Socket) 기반으로 라이선스를 부여했지만, 이번 정책 변경 이후에는 물리적 CPU 코어 수(Core-based licensing)를 기준으로 라이선스를 부과하도록 바뀌었습니다.

이로 인해 고성능 다중코어 서버를 운영 중인 기업들은 같은 서버를 사용하더라도 최대 2~3배에 달하는 라이선스 비용을 지불해야 하는 상황에 놓이게 되었습니다.

Red Hat's OpenShift Licensing Changes: Why IT Teams Are Scambling for Soutions

특히 이 글의 작성자는 이 같은 변화가 단순히 가격 인상만이 아닌, 기업들의 아키텍처 설계와 인프라 운영 방식에 직접적인 영향을 줄 수 있다고 지적합니다. 기업들은 라이선스 비용을 줄이기 위해 물리적 코어 수를 줄이는 방향으로 하드웨어 구성이나 클러스터 전략을 바꿔야 할 수도 있으며, 이는 기술적 부작용이나 운영 복잡성을 증가시킬 수 있습니다.

또한, 일부 기업들은 Red Hat의 이러한 정책 변경에 실망하고 있으며, Kubernetes 대안 솔루션(예: Rancher, VMware Tanzu, 또는 클라우드 벤더의 매니지드 서비스)로의 전환을 고려하고 있다는 점도 강조됩니다. 이는 단순한 비용 문제가 아니라 공정성과 신뢰에 대한 문제로 받아들여지고 있으며, “엔터프라이즈 친화적이지 않다”는 비판도 나오고 있습니다.

결론적으로 이 글은 Red Hat의 OpenShift 라이선스 변경이 단기적인 수익 증대에는 기여할 수 있지만, 장기적으로는 기업 고객의 신뢰를 잃고 오픈소스 기반 플랫폼 생태계에서 경쟁력을 약화시킬 수 있다

OpenShift 가격 인상에 따른 고객사 대응 전략

2025년 들어 Red Hat이 OpenShift의 라이선스 정책을 기존 소켓 기반에서 물리 코어 기반으로 변경하고, 이와 함께 최대 3배에 달하는 가격 인상을 적용하면서 국내외 기업 고객들이 큰 혼란에 빠졌습니다. 특히 동일한 인프라 규모, 동일한 워크로드임에도 불구하고 기존 대비 수억 원 단위의 비용 증가가 발생하고 있어, 많은 기업들이 재계약을 망설이거나 대체 방안을 검토하고 있습니다.

이러한 상황에서 고객사는 단순한 재협상 수준을 넘어, 클러스터 아키텍처, 플랫폼 전략, 벤더 정책에 대한 중장기적 재검토에 착수할 필요가 있습니다.

1. 레드햇과의 협상: 단기적 타협 시도

우선 단기적으로는 레드햇과의 재계약 협상이 주요 대응 중 하나입니다. 일부 고객은 다년 계약 체결, 기술지원 축소, 사용자 수 감축 등을 조건으로 가격 인하 또는 동결을 시도하고 있습니다. 또한 리셀러나 파트너사를 통한 유연한 협상도 전략 중 하나입니다.

그러나 Red Hat이 이번 정책을 글로벌 차원에서 일괄 적용하고 있는 만큼, 실질적인 할인 여지는 제한적이며, 장기적으로는 동일한 문제가 반복될 가능성이 높습니다.

2. OpenShift 내부 축소 운영 혹은 다운그레이드

기존 OpenShift Platform Plus 또는 고사양 옵션을 사용 중인 고객은, 이를 기능이 축소된 SKU(OpenShift Container Platform)로 전환하거나, 아예 무료 커뮤니티 에디션인 OKD(OpenShift Origin)으로 일부 클러스터를 이관하는 방식을 고려하고 있습니다. 이러한 방식은 레드햇 생태계 내에서의 호환성은 유지하면서도 비용을 줄일 수 있다는 장점이 있지만, 기능 제한과 SLA 부재는 단점으로 작용합니다.

3. 대체 쿠버네티스 플랫폼으로의 전환

많은 고객들이 이번 기회를 통해 벤더 종속성에서 벗어나기 위한 대체 Kubernetes 플랫폼을 적극 검토하고 있습니다. 그 중에서도 가장 현실적인 대안은 다음과 같습니다:

  • SUSE Rancher: 가볍고 유연하며, 멀티 클러스터 및 엣지 환경 지원에 강점
  • VMware Tanzu: VMware 기반 프라이빗 클라우드와의 통합에 적합
  • Canonical Kubernetes (Charmed K8s): Ubuntu 기반 환경에서 비용 효율적으로 구성 가능

이들은 모두 상용 지원 및 오픈소스 호환을 보장하면서, 다양한 IT 환경에 적용할 수 있는 유연성을 제공합니다.

4. OpenShift에서 OpenShift Kubernetes Engine(OCP → OKE)으로의 전환 방안

Red Hat의 라이선스 정책 변경 이후, 많은 고객사들이 전체적인 오픈시프트 플랫폼(OCP: OpenShift Container Platform)의 재계약을 재고하고 있습니다.

그에 따라 Red Hat이 제공하는 또 다른 제품군인 OpenShift Kubernetes Engine (OKE)으로의 내부 축소 전환도 유력한 대응 방안으로 검토되고 있습니다.

OKE란 무엇인가?

OpenShift Kubernetes Engine(OKE)은 OpenShift 제품군의 가장 기본적인 형태로, 다음과 같은 특징을 가집니다:

  • Core Kubernetes + 기본적인 OpenShift 인프라 서비스만 포함
  • 고급 기능(예: OpenShift Pipelines, Service Mesh, Serverless, GitOps, Logging/Monitoring 등)은 미포함
  • RHEL CoreOS 기반의 클러스터 구성 및 운영 관리는 동일하게 제공
  • Red Hat에서 상용 기술지원(Support)을 받을 수 있음

즉, OpenShift의 기본적인 클러스터 운영 기능만 사용하고 고급 애드온은 제외한 경량 제품으로, 비용을 줄이고 핵심 기능만 유지하려는 고객에게 적합한 구성입니다.

왜 OCP에서 OKE로 전환하나?

최근 고급 에디션(예: OpenShift Platform Plus, OpenShift Container Platform)의 가격을 인상하면서, 그 대안으로 OpenShift Kubernetes Engine을 적극 검토하고 있습니다.

고객 입장에서 OKE 전환은 다음과 같은 이유로 고려됩니다:

  • 전체 오픈시프트를 유지할 필요는 없지만, 기술지원과 호환성은 계속 필요할 때
  • 기존 Red Hat 생태계(RHEL, Ansible, Satellite 등)를 유지하고 싶은 경우
  • 비용 압박이 심하지만, 오픈소스 순수 Kubernetes 도입에 대한 리스크는 부담될 때

비용 측면의 차이

항목 OCP (OpenShift Container Platform) OKE (OpenShift Kubernetes Engine)
포함 기능 Kubernetes + DevOps 기능군 (Pipelines, GitOps 등) + Observability + Add-ons Kubernetes 핵심 + 클러스터 운영 도구만
비용 상대적으로 높음 30~50% 저렴 (Red Hat 기준)
용도 MLOps, DevSecOps 통합, 마이크로서비스 확장 등 기초 인프라 + 경량 워크로드 중심
유지보수 Red Hat 지원 Red Hat 지원

Red Hat은 OKE의 가격을 OpenShift 전체 패키지(OCP) 대비 상대적으로 저렴하게 책정하고 있어, 클러스터 수를 줄이거나, 부하가 낮은 개발/테스트 환경에서는 OKE로 대체하려는 사례가 늘고 있습니다.

전환 시 고려사항

OKE는 OpenShift CLI(oc), Operator Lifecycle Manager(OLM), 콘솔 등 기본적인 오픈시프트 관리 도구는 동일하게 제공하지만, 다음 기능은 포함되지 않습니다:

  • OpenShift Pipelines (Tekton 기반 CI/CD)
  • Service Mesh (Istio 기반)
  • GitOps (ArgoCD)
  • Serverless (Knative)
  • Monitoring/Logging (Loki, Prometheus 등 애드온 형태)

따라서 고객사는 다음 중 하나의 전략을 선택해야 합니다:

  • 이러한 고급 기능이 필수적이지 않다면 OKE로 전환하고 자체 오픈소스 도구(Tekton, ArgoCD, Istio 등)로 대체
  • 혹은, 운영 필수 기능만 OKE로 유지하고, 고급 기능은 클라우드 또는 SaaS 기반 외부 도구로 분리 운영

기술적 전환 작업

OCP에서 OKE로 전환하는 작업은 대규모 마이그레이션을 필요로 하지 않지만, 다음 사항은 사전에 점검되어야 합니다:

  • 클러스터 구성 시 선택한 OpenShift Operator 중, OKE에서 지원되지 않는 항목 제거
  • GitOps/Pipelines/Service Mesh 등 관련된 Deployment YAML/Helm Chart 수정
  • 운영 모니터링 체계를 Prometheus 등 외부 구성으로 전환

5. 관리형 Kubernetes 서비스(GKE, EKS, AKS)로의 마이그레이션

OKE 외에도, 기존의 대세인 Google GKE, AWS EKS, Azure AKS로의 전환도 여전히 유효한 선택지입니다. 이들 플랫폼은 높은 안정성과 글로벌 SLA, 운영 자동화, 보안 통합성을 제공하며, 클라우드 환경에 익숙한 개발 조직에는 매우 적합합니다. 다만, 클라우드 벤더에 대한 종속성이 심화될 수 있다는 점과 리팩토링 비용이 발생할 수 있다는 점은 고려되어야 합니다.

6. 자가 구축형 쿠버네티스 플랫폼으로의 전환

일부 대형 고객들은 레드햇이나 다른 벤더 솔루션이 아닌, 직접 오픈소스 기술 스택을 조합해 자체 플랫폼을 구성하는 방안을 추진하고 있습니다. 예를 들어 Kubernetes + ArgoCD + Istio + Prometheus + Grafana 등을 이용한 클러스터 구성은 고급 DevOps 조직에서 점점 일반화되고 있습니다.

이 방식은 기술적 유연성과 비용 효율성 면에서는 우수하지만, 운영 인력 확보와 장애 대응에 대한 체계가 충분히 마련되어 있어야 현실적인 선택이 됩니다.

7. 인프라 아키텍처 재설계 및 최적화

마지막으로, OpenShift 가격 인상에 따라 서버 구조, 클러스터 토폴로지, 워크로드 배치 방식에 대한 전면적인 최적화가 논의되고 있습니다. CPU 코어 수에 기반한 라이선스 정책 하에서는 고코어 단일 노드보다는 다수의 저사양 노드로 분산하는 전략이 비용 면에서 유리할 수 있습니다.

또한, AWS Graviton이나 OCI Ampere와 같은 ARM 기반 인스턴스의 도입은 연산 성능과 비용의 균형을 잡을 수 있는 실질적인 대안으로 떠오르고 있습니다.

마무리

이번 사태는 단순한 비용 문제를 넘어, 레드햇 생태계의 신뢰 기반이 흔들리는 현상으로 해석될 수 있습니다.

특히 국내 기업들은 “비즈니스 파트너가 아닌 갑의 행보”로 받아들이는 분위기이며, OpenShift 도입을 검토 중이던 신규 고객들 또한 대체 솔루션에 대한 관심을 빠르게 높이고 있는 상황입니다.

이러한 변화는 Kubernetes 관리형 솔루션 시장의 경쟁 구도 변화로 이어질 수 있으며, 향후 퍼블릭 클라우드 벤더 및 오픈소스 기반 대안들의 성장 가능성을 더욱 확대시키는 계기가 될 수도 있습니다.

References & Related Links

이제 나도 MSA 전문가 개념부터 실무까지