왜 쿠버네티스와 조용히 결별하는 기업들이 늘고 있는가
학습 차원에서 틈틈이 해외 전문가들이 블로그나 미디어 그리고 책에서 쓴 글을 번역 또는 요약 정리하고 있습니다. 이번 포스팅도 그중 하나고요. 거칠고 오역된 부분이 있을 수 있습니다. 제대로 번역되지 않은 부분은 확인 주시면 반영토록 하겠습니다. 의미 전달이 애매한 문장은 삭제했습니다. 이번에는 Sohail Saifi가 미디엄에 올린 글을 정리한 것입니다.
나는 회의실에서 느껴진 그 이상한 침묵을 아직도 기억한다. 우리 CTO는 2년간 투자 끝에 Kubernetes에서 벗어나기로 결정했다고 발표했다. 아무도 먼저 왜 그런 결정을 내렸는지 묻고 싶어하지 않았다. K8s를 기반으로 전체 인프라를 구축하고 팀을 교육시킨 후, 우리는 다시 한 번 방향을 전환해야 했다.
하지만 우리는 혼자가 아니었다. 기술 컨퍼런스 스포트라이트 밖에서, 폐쇄된 회의실 안에서 중요한 변화가 일어나고 있다. 한때 Kubernetes를 컨테이너 오케스트레이션의 성배로 선전하던 기업들이 조용히 대안을 모색하고 있다. 작은 스타트업들만 그런 건 아니다. — 여기에는 클라우드 네이티브 아키텍처로 제국을 건설한 테크 거인들도 포함된다.
분명히 하자면, Kubernetes는 하루아침에 사라지지 않을 것이다. 거대한 생태계와 CNCF 지원을 바탕으로 Kubernetes는 많은 조직에서 여전히 깊이 뿌리내리고 있다. 하지만 균열이 나타나기 시작했고, 불만의 목소리는 점점 더 커지고 있다. 수십 명 엔지니어링 리더들과 대화와 최근 인프라 트렌드 분석을 통해, 이 변화가 왜 일어나고 있는지, 어떤 대안이 주목받고 있는지 파악했다. 드러난 그림은 나조차도 놀라게 했다.
전환의 분수령: 기업들이 쿠버네티스를 재검토하는 이유
보상 없는 복잡성
약속은 유혹적이었다.: 컨테이너화된 애플리케이션을 배포, 확장, 관리하는 통일된 방식. 현실은? 학습 곡선이 너무 가파르다 못해 거의 수직에 가깝다.
“우리는 새로운 기능을 개발하는 것보다 쿠버네티스 클러스터를 유지보수하는 데 더 많은 엔지니어링 시간을 썼다.”라고 최근 K8s 구현을 포기한 유니콘 스타트업 시니어 플랫폼 엔지니어가 고백했다. “어느 시점에는 운영 부담이 그만한 가치가 있는지 스스로에게 물어야 한다.”
이같은 감정은 모든 규모 기업들에서 공감을 얻고 있다. 포드(Pod), 서비스, 인그레스 컨트롤러, 그리고 끝없이 이어지는 YAML 파일 집합을 이해하는 데 필요한 인지적 부담은 많은 팀이 결코 완전히 극복하지 못하는 장벽을 형성한다.
포춘 500대 기업(이름을 밝히지 않은) 한 엔지니어링 디렉터는 직설적으로 말한다.: “우리 DevOps 팀 시간 중 38%가 배포 파이프라인을 개선하기 보다는 Kubernetes 문제 해결에 소요되었다. 이는 지속 불가능한 비율이다.”
숨겨진 비용 센터
Kubernetes의 마케팅 메시지는 최적화된 리소스 활용을 통한 비용 절감에 초점을 맞춘다. 현실은 더 복잡하다. 전문적인 DevOps 인재(K8s 인증 엔지니어는 프리미엄 급여를 요구한다), 예상치 못한 트래픽 급증을 처리하기 위한 과도하게 할당된 클러스터, 컨트롤 플레인을 실행하기 위해 필요한 클라우드 리소스 등 때문에 Kubernetes 총 소유 비용(TCO)은 초기 예상치를 초과하는 경우가 많다.
“우리는 마이크로서비스를 관리형 Kubernetes 서비스로 통합하는 것이 현명한 선택이라고 생각했다,”라고 중견 SaaS 기업 기술 리더가 말했다. “6개월 후 클라우드 비용이 25% 증가했고, 오히려 감소하지 않았다. 추가 인력 비용은 포함되지도 않았다.”
운영 성숙도 불일치
가장 간과되기 쉬운 요소는 쿠버네티스가 많은 조직이 갖추지 못한 수준의 운영 성숙도와 마이크로서비스 아키텍처를 요구한다는 점이다.
“아키텍처가 준비되지 않은 상태에서 Kubernetes에 모든 것을 걸었다”라고 최근 K8s 환경을 축소한 기업 CTO가 인정했다. “컨테이너 내에서 모놀리식 아키텍처를 운영하며 Kubernetes의 복잡성을 처리했지만 그 혜택을 활용하지 못했다. 두 세계의 최악을 경험한 것이었다.”
5가지 주목받는 대안
그렇다면 기업들은 어디로 이동하고 있을까? 기술 리더들과 대화에서 반복적으로 언급된 5가지 대안은 다음과 같다.
1. AWS App Runner + ECS: 단순성 vs. 제어
아마존 컨테이너 솔루션은 “필요한 만큼의 오케스트레이션” 옵션으로 자리 잡았다. ECS(Elastic Container Service)는 Kubernetes보다 더 오래 존재해 왔고 App Runner는 컨테이너 관리 관련 문제를 거의 모두 추상화해 단순성을 한 단계 더 높였습니다.
흥미로운 점은 기업들이 이 서비스를 어떻게 결합하고 있는지다.. 여러 기술 리더들은 단순하고 상태 비저장형 애플리케이션에는 App Runner를 사용하고, 더 많은 맞춤화가 필요한 워크로드에는 ECS를 유지한다고 설명했다.
“EKS에서 App Runner와 ECS의 조합으로 마이그레이션한 후 인프라 관리 부담을 60% 줄였다”라고 한 핀테크 회사 엔지니어링 부사장이 전했다. “개발자들은 쿠버네티스 네트워킹의 복잡성을 이해하지 않고도 자체적으로 배포할 수 있게 되었다.”
이 대가는 세밀한 제어의 감소이지만, 많은 기업들은 운영 단순화를 위해 이같은 비용을 지불할 가치가 있다고 판단하고 있다.
2. Nomad: 평가받지 못한 오케스트레이터
HashiCorp Nomad는 수년간 쿠버네티스 그늘에 있었지만, 상황이 변하고 있다.. Nomad 아키텍처는 단순하지만 놀라운 유연성을 제공하며, 컨테이너뿐 아니라 전통적인 애플리케이션과 배치 작업도 오케스트레이션할 수 있다.
“Nomad는 Kubernetes에서 필요로 했던 기능 80%를 20% 복잡성으로 제공했다”라고 Kubernetes를 2년간 사용하다 전환한 기업 주니어 엔지니어는 말했다. “우리 팀의 학습 곡선은 달이 아닌 날로 측정되었다.”
특히 주목할 점은 Nomad가 Consul과 Vault 같은 다른 HashiCorp 도구들과 잘 통합되어, Kubernetes 올인원 접근 방식 없이 서비스 발견과 비밀 관리 문제를 해결하는 생태계를 형성한다는 것이다.
완전히 컨테이너화되지 않은 기업들은 전환 기간 동안 Nomad의 혼합 워크로드 관리 능력을 특히 가치 있게 생각한다.
3. 서버리스 컨테이너 플랫폼: Google Cloud Run 및 Azure Container Apps
Google Cloud Run과 Azure Container Apps로 대표되는 서버리스 컨테이너 모델은 전통적인 Kubernetes에서 가장 극적인 사고 방식의 전환을 상징한다.
이들 플랫폼은 최소한의 구성으로 컨테이너 런타임 환경 확장, 네트워킹, 운영을 처리한다. 개발자는 단순히 컨테이너 이미지를 제공하면 플랫폼이 나머지를 처리한다.
“우리는 마이크로서비스 70%를 GKE에서 Cloud Run으로 이전했다,”라고 한 플랫폼 엔지니어링 담당 디렉터는 말했다. “과거에는 수많은 Kubernetes 리소스를 수정해야 했던 배포 작업이 이제 단일 명령어로 완료된다. 엔지니어들은 포드 관리에서 벗어나 실제 서비스에 집중할 수 있게 되었다.”
이러한 플랫폼들이 빠르게 채택되고 있다는 것은 시장에서 컨테이너 배포 옵션을 극도로 단순화하려는 명확한 수요를 보여준다. 네트워크나 스토리지와 같은 분야에서 유연성이 감소하는 것이 단점이지만, 많은 스테이트리스 서비스들에서는 이러한 제한이 실제 환경에서 거의 문제가 되지 않는다.
4. 내부 개발자 플랫폼(IDP)을 활용한 플랫폼 엔지니어링
내가 보고 있는 흥미로운 트렌드는 Kubernetes를 직접 대체하는게 아니라 그 위에 위치한 레이어다. 바로 인프라 복잡성을 추상화하는 내부 개발자 플랫폼이다.
Backstage, Porter, Humanitec과 같은 도구는 개발자에게 Kubernetes를 둘러싼 복잡성에 노출되지 않고 셀프 서비스 기능을 제공하는 방법으로 채택되고 있다.일부 기업은 특정 요구사항에 맞춘 맞춤형 플랫폼을 구축하기도 한다.
“우리는 Kubernetes를 유지했지만 대부분 엔지니어에게 보이지 않도록 만들었다”라고 한 대형 기업 플랫폼 팀 리더는 설명했다. “내부 플랫폼은 버튼 클릭만으로 배포를 제공하며, 플랫폼 팀이 모든 복잡성을 처리한다. 개발자는 YAML 한 줄도 작성하지 않는다.” 이같은 접근 방식은 조직이 Kubernetes의 강력한 기능을 유지하면서 사용성 문제를 해결할 수 있게 해준다. 플랫폼 엔지니어링에 투자해야 하지만 개발자 경험을 크게 개선할 수 있다.
5. “적은 것이 더 많다” 접근 방식: 오케스트레이션 없이 컨테이너화
가장 놀라운 점은 단순한 배포 모델로 돌아가는 기업들이 늘고 있다는 것이다. 로컬 개발에는 Docker Compose와 같은 기본 오케스트레이션 도구를 사용하고, 생산 환경에는 systemd나 supervisor를 활용해 컨테이너를 가상 머신에 직접 실행하는 방식이다.
“우리는 실제 요구사항을 면밀히 분석한 결과, 못을 박기 위해 망치를 사용하는 것과 같은 상황을 깨달았다.”라고 한 스타트업 CTO는 말했다.. “우리 서비스 대부분은 복잡하지 않으며 동적 스케일링이나 고급 네트워킹이 필요하지 않는다. VM에서 컨테이너를 실행하고 좋은 모니터링 및 배포 자동화를 적용하면 10% 번거로움으로 90% 혜택을 얻을 수 있다.”
이 접근 방식은 특히 전통적인 배포 사이클을 가진 소규모 팀이나 기업에 잘 맞는다. 매일 수십 개 업데이트를 푸시하는 지속적인 배포 파이프라인을 사용하는 경우와는 다르다.
팀에 맞는 올바른 선택을 하는 것
Kubernetes에서 벗어나려는 움직임은 모든 조직에 Kubernetes가 잘못된 선택이라는 의미는 아니다. 규모, 운영 성숙도, 복잡성의 적절한 조합을 갖춘 조직은 그 기능을 진정으로 활용할 수 있다. 하지만 많은 다른 조직들에게는 다음 프레임워크가 대안이 더 적합한지 판단하는 데 도움이 될 수 있다.
규모에 대해 솔직히 평가하라. 여러 지역에서 수백 개 마이크로서비스를 운영 중인가, 아니면 아키텍처가 여전히 비교적 단순한가? 작은 규모 배포는 Kubernetes의 복잡성을 정당화하기 어렵다.
팀의 운영 역량을 평가하라. Kubernetes를 관리할 전담 플랫폼 엔지니어가 있나? 아니면 개발자들이 여러 역할을 맡고 있나? 인력이 부족한 팀은 K8s 오버헤드에 어려움을 겪을 것이다.
실제 오케스트레이션 요구사항을 평가하라. 자동 스케일링, 복잡한 네트워킹, 리소스 관리와 같은 고급 기능이 필요한가 아니면 더 간단한 솔루션으로 충분할까?
배포 빈도를 고려하라. 매일 여러 번 배포하는 조직은 주간 또는 월간 배포하는 조직보다 Kubernetes 자동화에서 더 큰 혜택을 받는다.
기존 투자 요소를 고려하라. Kubernetes 전문 지식과 도구링에 이미 대규모 투자를 했다면 전환 비용이 잠재적 혜택보다 클 수 있다.
컨테이너 오케스트레이션의 미래
단순성으로 돌아가고 있는 것이 트렌드다. 많은 조직이 Kubernetes의 복잡성이 특정 사용 사례에서 보상이 줄어드는 결과를 가져온다고 판단하고 있다. 이는 Kubernetes 자체의 종말을 의미하지는 않지만, 전문적인 대안과 함께 오케스트레이션 환경을 공유하는 미래를 보여준다.
가장 가능성이 높은 결과는 더 큰 계층화(stratification)다. 복잡한 요구사항과 전담 플랫폼 팀을 갖춘 기업은 Kubernetes를 계속 사용할 것이며, 시장 출시 속도와 운영 비용 절감을 추구하는 기업은 간소화된 대안을 점점 더 선택할 것이다.
모든 기술 선택과 마찬가지로, 일반적인 정답은 없다.— 조직의 특정 맥락, 제약 조건, 목표에 따라 평가해야 할 타협점일 뿐이다.
Kubernetes에서 조용히 이탈하는 현상은 중요한 교훈을 제공한다: 때로는 ‘산업 표준’ 솔루션이 특정 요구사항에 맞는 해결책이 아닐 수 있다. 상당한 투자 후에도 기술 선택을 재평가하는 용기는, 감소하는 수익의 패턴에 빠지는 조직과 진정으로 적응력 있는 조직을 구분짓는 요소다.
