대부분의 기업이 아직 쿠버네티스 성숙도에 도달하지 못한 이유

F5 리서치 | 2026년 11월 09일

10여 년 전, 솔루션 엔지니어로 일하던 저는 여러 조직이 부수적인 프로젝트로 Kubernetes를 도입하기 시작하는 모습을 지켜봤습니다. 이는 소규모 팀의 비공식 실험 프로젝트로, 다른 컨테이너 스케줄러 테스트와 병행되는 경우가 많았습니다. 실제 워크로드는 여전히 vSphere의 가상 머신에서 실행되고 있었으며, 이 환경은 서비스 수준 목표와 복구 시간 목표를 중심으로 구축되어 있었습니다. 서버 관리자뿐 아니라 모두가 각자의 역할을 맡고 있었습니다. 그런 환경이야말로 이른바 엔터프라이즈급이었습니다.

그러다 변화가 시작되었습니다. 퍼블릭 클라우드가 급성장하고 애플리케이션이 현대화되면서, Kubernetes는 기업이 컨테이너화된 애플리케이션을 실행하는 표준 방식으로 자리 잡았습니다. 이러한 변화의 원동력은 늘 그렇듯 빠른 규모 확장이 필요한 비즈니스였습니다. 기업들은 더 빠르게 움직이기를 원했고, 저는 Kubernetes를 엔터프라이즈 플랫폼으로 만들려는 여러 초기 고객과 그 여정을 함께했습니다.

이러한 고객들이 지향하는 목표는 비즈니스의 기대 수준에 따라 정해졌습니다. 비공식 실험 프로젝트라면 여건이 허락하는 만큼만 노력해도 충분하거나, 그조차 요구되지 않을 수 있습니다. 하지만 엔터프라이즈 플랫폼은 비즈니스와 보조를 맞춰야 하며, 이상적으로는 경쟁력을 좌우하는 핵심 요소가 되어야 합니다. Kubernetes에 대한 기대도 이제 그 수준에 이르렀지만, Kubernetes 자체만으로는 vSphere처럼 완전한 플랫폼이라고 할 수 없습니다. 오픈 소스라는 기반은 훌륭하지만, 이는 시작에 불과합니다.

F5가 SlashData에 의뢰한 새로운 연구에 따르면, 엔터프라이즈 수준에 도달하기까지의 격차가 상당한 것으로 나타났습니다. 프로덕션 환경에서 Kubernetes를 운영하는 기업 중 61%는 Kubernetes에 나머지 IT 환경과 같거나 더 높은 기준을 적용하지만, 엔터프라이즈급 성숙도에 도달한 기업은 38%에 불과합니다.

프로덕션 환경에서 Kubernetes를 운영하는 기업 중 엔터프라이즈급 성숙도에 도달한 기업은 38%에 불과합니다.

이 보고서에서 엔터프라이즈급은 단순히 높은 점수를 의미하지 않습니다. 자동화된 수용 제어, 강제 적용되는 테넌트 격리, 중앙 집중식 관측 가능성, 문서화된 복구 목표, 최근 12개월 이내에 테스트된 장애 조치가 필요합니다. 이 설문조사는 2026년 8월에 직원 수 500명 초과 조직의 실무자들로부터 수집한 응답 445개를 바탕으로, 팀이 스스로 평가한 성숙도가 아닌 실제 수행하는 활동을 평가했습니다.

대부분의 IT 환경은 자리를 잡았지만, 아직 성숙하지는 않습니다

저는 이 보고서의 정의를 모두가 함께하는 여정의 이정표로 봅니다. 어떤 조직이든 완성된 상태에 도달하기는 어렵고, 우선순위를 정할 때는 언제나 절충이 따릅니다. 이 보고서는 오늘날 기업들이 어디에 있는지 보여줍니다. 기업의 절반(51%)은 표준이 정의되어 대체로 준수되고 있지만 여전히 뚜렷한 격차가 존재하는 정착 단계에 속합니다. 또 다른 11%는 아직 표준화 과정에 있습니다. 기업 10곳 중 약 9곳(88%)은 최소 한 개 영역에서 최상위 등급에 도달하지만, 네 개 영역 모두에서 최상위 등급을 달성한 기업은 22%에 불과합니다. 종합 점수가 80점 이상인 기업 51% 중에서도 네 곳 중 한 곳(24%)은 필수 요건 하나를 충족하지 못해 최상위 등급에 오르지 못합니다.

가장 흔히 부족한 요소는 관측 가능성입니다. 최상위 등급에 아깝게 미치지 못한 기업 중 36%는 중앙 집중식 관측 가능성을, 31%는 자동화된 승인 제어를 갖추지 못했습니다. 두 가지 모두 제가 현장에서 본 상황과 일치합니다. 제가 담당한 고객 대부분은 Kubernetes 사용 여부와 관계없이 관측 가능성이 부족했습니다. 문제 해결이 어려웠고, 필요 이상으로 많은 인력이 투입되었으며, 서로 책임을 떠넘기는 상황으로 번지는 경우도 너무나 잦았습니다.

어드미션 컨트롤이 중요한 이유는 규모 때문입니다. 한 고객은 환경 규모가 워낙 커서 vSphere를 관리하는 데 어드미션 컨트롤을 적극적으로 활용했습니다. Kubernetes 환경은 빠르게 확장되며, 보고서에서 가장 많이 언급된 과제는 클러스터 및 환경 관리의 복잡성(39%)입니다. 대규모 환경에서 중요한 통제 수단은 대부분의 팀이 예상하는 것보다 더 이른 시점부터 중요해집니다. 그런데도 향후 12개월 내에 관측 가능성에 투자할 계획이라는 응답은 28%에 불과한 반면, 보안 및 정책 적용에 투자할 계획이라는 응답은 42%에 달합니다.

성숙도 향상은 팀워크의 결과입니다

시간이 지나면서 각 팀의 역할은 제 예상보다 더 중요해졌습니다. 플랫폼 및 DevOps 팀과 만난 것은 이들이 NGINX를 잘 알고 신뢰하며 사용하고 싶어 했기 때문입니다. 네트워크 및 보안 팀과도 만났는데, 이들은 Kubernetes가 완전히 별개의 워크플로를 만드는 대신 기존 엔터프라이즈 NetOps 및 SecOps 운영 방식에 통합될 수 있는지 확인하고자 했습니다.

한 고객사는 당시로서는 이례적인 일을 했습니다. 자사의 DevOps 엔지니어에게 전용 F5 BIG-IP를 제공한 것입니다. 그는 이 장비를 속속들이 익혔고, 기존 BIG-IP 관리자들도 직접 해내는 경우를 좀처럼 보지 못했던 일들을 구현했습니다(Steven에게 박수를 보냅니다!). 이것이 바로 신뢰를 실천한 사례였습니다. 성공은 언제나 파트너십과 신뢰에서 비롯되었습니다. 엔터프라이즈 수준의 성과를 내려면 팀들이 서로를 우회하는 것이 아니라 서로를 의지해야 하기 때문입니다.

연구 결과도 같은 방향을 가리킵니다. 전담 플랫폼 엔지니어링 팀이 Kubernetes를 운영하고 별도의 중앙 보안 팀이 정책을 수립하는 기업의 경우, 66%가 엔터프라이즈급 성숙도에 도달합니다. 이는 다른 운영 체계를 갖춘 기업의 약 두 배에 달하는 비율입니다. 하지만 이러한 방식으로 운영하는 기업은 19%에 불과합니다. 도입 범위도 중요합니다. Kubernetes를 조직 전체의 표준 플랫폼으로 운영하는 기업 중 53%가 최상위 수준에 도달한 반면, 단일 팀에서만 운영하는 기업은 그 비율이 25%에 그쳤습니다.

이는 상관관계일 뿐, 인과관계를 입증하는 것은 아닙니다. 규모가 크고 도입 의지가 강한 조직일수록 이런 방식으로 업무를 분담할 가능성이 더 높을 뿐일 수도 있습니다. 그래도 제 경험과는 일치합니다. 업무 부담을 나누고 각자 맡은 역할을 잘 해낼 것이라 서로 신뢰하는 팀이야말로 엔터프라이즈 수준에 도달합니다.

AI가 거버넌스를 앞서가고 있습니다

저 역시 이런 현상의 초기 모습을 목격했습니다. 한 기업은 비즈니스의 핵심으로 자리 잡아 가던 머신러닝 워크로드를 빠르게 배포하고 있었습니다. 전반적으로는 전통적인 기업이었지만, 해당 부문은 혁신의 중심에 있었습니다. 이처럼 속도가 빠르면 거버넌스가 뒤처질 수 있습니다.

프로덕션 환경에서 Kubernetes를 운영하는 기업 중 45%가 모델을 배포하거나 서비스하고 있으며, 이 중 86%는 기존 웹 애플리케이션 방화벽(WAF) 또는 API 보호 기능을 해당 트래픽에도 확대 적용했습니다. AI 전용 통제 조치의 도입은 더딘 편입니다. 에이전트 도구와 모델 컨텍스트 프로토콜(MCP) 트래픽을 검사하는 기업은 43%에 불과하지만, 49%는 향후 12개월 내에 이를 도입할 계획입니다. 성숙한 운영 환경을 갖춘 기업은 요청 속도 제한과 토큰 할당량 적용에서 앞서고 있지만(80% 대 50%), 프롬프트 검사와 MCP 트래픽 검사에서는 이러한 우위가 사라집니다. 기존 워크로드를 위해 확립한 거버넌스 관행이 도움이 되기는 하지만, 아직 모든 영역을 포괄하지는 못합니다.

연구 결과가 여러분의 기술 스택에 주는 시사점

이 연구는 특정 제품 하나를 제시하지 않습니다. 대신 격차를 짚어 내며, 각 격차는 담당 조직의 역할과 연결됩니다. 관측 가능성은 엣지에서의 텔레메트리 수집으로 시작되며, 이는 플랫폼 및 네트워크 팀의 소관입니다. Web application and API protection(WAAP)은 환경 등급 간 기술 도입률 격차가 가장 큰 영역 중 하나로, 엔터프라이즈급 환경의 69%가 이를 사용하는 반면 나머지 환경에서는 50%만 사용합니다. 관련 정책은 보안 팀이 책임지고 관리하며, 모든 클러스터에 상속되어야 합니다. 장애 조치는 여러 클러스터에 걸쳐 테스트해야 하므로 네트워크 팀과 플랫폼 팀의 협업이 필요합니다.

F5의 접근 방식은 이러한 팀의 실제 업무 방식을 따릅니다. Kubernetes와 같은 소프트웨어 스택에서는 오픈 소스가 기본이므로, Kubernetes 팀은 오픈 소스에서 시작합니다. 예를 들어, 커뮤니티 ingress-nginx 프로젝트의 지원 종료에도 불구하고 장기 지원되는 Ingress 솔루션인 NGINX Ingress Controller나 NGINX Gateway Fabric과 같은 프로젝트로 시작할 수 있습니다. NGINX Gateway Fabric은 Gateway API를 완벽하게 준수합니다.

결국 팀들은 상용 솔루션이 제공하는 신뢰성을 원하게 되며, 이때 F5 NGINX Enterprise로 전환하여 보안이 강화된 이미지, 엣지 ID, 애플리케이션별 보안 정책, 지원 SLA 또는 대규모 인프라 운영 기능을 확보합니다.

네트워크 및 보안 팀은 Kubernetes가 기존 운영 방식에 부합하기를 원합니다. 따라서 Container Ingress Services(CIS)를 갖춘 F5 BIG-IP를 사용하면 플랫폼 팀이 Kubernetes에서 계속 작업하는 동안 네트워크 및 보안 팀은 BIG-IP에서 중앙 집중식 트래픽 및 보안 정책과 클러스터 간 장애 조치를 적용할 수 있습니다.

네오클라우드 또는 AI 팩토리 규모로 실행되는 AI 워크로드의 경우, F5 BIG-IP Next for Kubernetes는 Kubernetes의 AI 환경에 맞게 설계된 트래픽 관리 및 보안 기능으로 이러한 접근 방식을 확장합니다. 각 팀은 익숙한 도구를 계속 사용하면서 공유 제어 지점을 통해 서로 보조를 맞출 수 있습니다.

함께 제공되는 백서에서는 이를 단계별 완료 기준이 있는 네 단계로 구체화합니다. 제시된 일정은 예시이므로 현재 성숙도에 맞는 단계부터 시작하고 상황에 맞게 일정을 조정하세요.

표준화(0~3개월): 모든 클러스터에 지원되는 단일 인그레스 패턴 적용, 엣지 텔레메트리 확보, 플랫폼 및 보안 역할 정의.
정립(3~9개월): Gateway API 표준, 상속된 보안 정책을 적용하는 WAF, 중앙 집중식 텔레메트리.
엔터프라이즈급(9~18개월): 자동화된 승인 제어, 트래픽과 정책을 위한 단일 제어 지점, 검증된 장애 조치.
최적화(18개월 차 이후): AI 가드레일, 코드형 정책, 분기별 성숙도 재평가.

4단계에서는 앞서 언급한 머신 러닝 워크로드처럼 AI가 다시 등장합니다. 팀은 F5 NGINX Enterprise와 CIS를 연동한 BIG-IP로 이미 구축해 놓은 기반을 바탕으로 이 단계에 도달합니다. 네오클라우드와 AI 팩토리 규모에 대응하려면 이 기반을 BIG-IP Next for Kubernetes로 확장할 수 있습니다. 규모와 관계없이 기술의 효과는 이를 뒷받침하는 파트너십이 얼마나 탄탄한지에 달려 있습니다.

어디서부터 시작할지 확인해 보세요. 로드맵을 다운로드하여 엔터프라이즈급 Kubernetes 성숙도를 달성하기 위한 자가 진단과 단계별 계획을 확인하세요. 그런 다음 2026년 엔터프라이즈 Kubernetes 전략 현황 보고서에서 전체 연구 결과를 살펴보세요.

또한 다음 블로그 게시물도 꼭 확인해 보세요. “모든 팀을 위해 설계된 Kubernetes용 클라우드 네이티브 트래픽 제어 및 보안”