작은 팀은 PaaS를 쓰고 회사가 커지면 Kubernetes로 옮겨야 한다는 식의 설명은 실제 선택에 별 도움이 되지 않는다. 팀원 수가 같아도 Linux·Network·Incident Response를 직접 운영할 수 있는 팀과 Application 개발에 집중하는 팀은 감당할 수 있는 인프라 책임이 전혀 다르기 때문이다.
Compute 선택에서 먼저 물어야 할 것은 “우리에게 얼마나 큰 기술이 필요한가”가 아니라 “어떤 통제가 반드시 필요하고 그 통제를 얻기 위해 생기는 반복적인 운영 업무를 누가 계속 맡을 것인가”다.
VM, PaaS, 관리형 컨테이너, Kubernetes는 발전 단계가 아니다. 같은 회사에서도 오래된 업무 시스템은 VM에, 공개 API는 관리형 컨테이너에, 다른 플랫폼 워크로드는 Kubernetes에 둘 수 있다.
가장 적합한 모델은 필요한 통제를 충족하는 후보 중에서 팀의 Complexity Budget 안에 들어오는 모델이다.
먼저 ‘컨테이너’를 운영 모델과 구분해야 한다
Container는 애플리케이션을 패키징하고 실행하는 방법이지 그 자체가 하나의 운영 책임 모델은 아니다.
PaaS가 Container Image 배포를 받을 수도 있고 Kubernetes도 Container를 실행한다. 반대로 VM 한 대에서 Docker를 직접 운영할 수도 있다.
따라서 이 글에서 비교하는 네 모델은 다음처럼 정의한다.
VM은 Guest OS부터 상당 부분을 팀이 직접 관리하는 모델이다.
PaaS는 Source나 Application Artifact를 올리면 Provider가 OS와 Runtime을 포함한 Platform 영역을 크게 관리하는 모델이다.
Managed Container는 Container Image의 자유도는 유지하되 Cluster와 Host 운영을 Provider에 넘기는 모델을 뜻한다. Cloud Run이나 Azure Container Apps처럼 Container를 배포하지만 Kubernetes Cluster를 직접 운영하지 않는 형태가 대표적이다. Cloud Run의 현재 문서도 별도의 Cluster를 생성하거나 Infrastructure를 관리하지 않고 Service·Job·Worker Pool을 실행하는 구조를 설명한다.
Kubernetes는 Container Workload의 Scheduling, Service Discovery, Resource Policy, Rollout, Networking, Storage Integration 등을 Kubernetes API로 제어하는 운영 모델이다. Managed Kubernetes를 사용해 Control Plane을 Provider에 맡기더라도 Application과 Workload Policy까지 자동으로 사라지는 것은 아니다.
즉 “Container를 쓰고 싶다”는 이유만으로 Kubernetes가 필요한 것은 아니다.
Compute 선택을 Complexity Budget으로 바꿔보자
Compute Operating Model을 정할 때는 세 가지를 함께 봐야 한다.
Required Control — 어느 정도 통제가 정말 필요한가
표준 HTTP Routing과 몇 개의 환경변수만 있으면 되는 애플리케이션과, 특정 Network Topology·GPU Placement·Privileged Workload·세밀한 Service-to-Service Policy가 필요한 플랫폼은 같은 수준의 통제를 요구하지 않는다.
플랫폼이 제공하는 추상화 때문에 실제 요구사항을 구현할 수 없다면 더 낮은 수준의 통제를 가져와야 한다.
Sustainable Operations — 그 통제를 계속 운영할 수 있는가
한 번 설치할 수 있다는 것과 Production에서 계속 운영할 수 있다는 것은 다르다.
OS Patch, Certificate, Image Update, Node 교체, Runtime Upgrade, Autoscaling, Network Policy, Logging, Alert, Backup, 장애 대응을 앞으로도 맡을 Owner가 있어야 한다.
Owner가 없는 운영 책임은 팀의 Complexity Budget에 포함됐다고 볼 수 없다.
Acceptable Exit Cost — 나갈 수 있는가
쉬운 도입이 항상 쉬운 이탈을 뜻하지 않는다.
Application Runtime만 옮기면 되는지, Deployment 설정·IAM·Network·Storage·Managed Database·Observability·CI/CD까지 다시 만들어야 하는지를 따로 봐야 한다.
이를 간단히 표현하면 다음과 같다.
선택 가능한 Operating Model
=필요한 통제를 충족하고 + 반복 운영 책임이 팀 역량을 넘지 않으며 + Exit Cost가 허용 범위 안에 있는 모델
이 조건을 통과한 후보가 여러 개라면 가장 “현대적인” 것을 고를 이유는 없다. 지속적으로 운영해야 할 복잡성이 더 적은 쪽이 기본 후보가 된다.
Compute Operating Model Decision Matrix
아래 표는 제품 기능의 우열이 아니라 운영 책임을 비교하기 위한 Matrix다.
| 판단 축 | VM | PaaS | Managed Container | Kubernetes |
|---|---|---|---|---|
| Number of Services | 적거나 강하게 결합된 서비스도 단순하게 운영 가능. 많아지면 배포·설정 표준화가 별도 과제 | 표준 Web/API 중심의 여러 App을 각각 운영하기 좋음 | 독립 배포되는 여러 Container Service·Job에 잘 맞음 | 여러 Workload에 공통 Scheduling·Policy·Platform API가 필요한 경우 가치가 커짐 |
| Stateful / Stateless | Local State까지 직접 제어 가능하지만 Backup·HA·Migration 책임도 커짐 | 보통 영속 상태를 외부 Managed DB·Storage로 분리 | Stateless 실행과 외부 State 조합이 단순함 | Stateful Workload도 가능하지만 StorageClass·Backup·Upgrade 운영까지 고려해야 함 |
| Traffic Variability | 직접 Capacity와 Scaling 구조를 설계 | 플랫폼의 내장 Scaling 사용 가능 | Request·Event 기반 자동 확장에 유리한 서비스가 많음 | Pod와 Node Scaling을 세밀하게 설계 가능하지만 설정과 운영 책임이 따라옴 |
| Deployment Frequency | Pipeline·Artifact·Rollback 체계를 직접 구축 | 플랫폼 표준 Deployment 경로를 사용하기 쉬움 | Image Revision 기반 배포와 Traffic Control이 일반적 | Rolling Update·GitOps 등 강력한 표준화가 가능하지만 Platform 운영면이 커짐 |
| Isolation | VM 단위 OS 경계를 직접 구성 | Provider가 제공하는 격리 모델 안에서 선택 | Container Instance·Environment 단위의 Platform 격리를 사용 | Namespace·Node·Cluster 등 다양한 경계를 설계할 수 있으나 요구 수준에 맞는 별도 정책이 필요 |
| Networking | OS·Firewall·Route까지 높은 통제 | 가장 Opinionated. 표준 네트워크 경로에 맞아야 단순 | VPC Integration·Ingress·Egress 등 중간 수준의 통제 | CNI, NetworkPolicy, Ingress/Gateway, Service Mesh 등 높은 통제와 높은 운영면 |
| Scaling | VM 또는 Process Scale을 직접 설계 | Platform Scale 기능 중심 | Instance/Request/Event Scaling을 Provider에 크게 위임 | Pod·Node·Custom Metric 기반으로 매우 세밀하게 구성 가능 |
| Portability | OS와 Application 자체는 옮기기 쉬울 수 있지만 Network·Data·Managed Service는 별개 | Platform Runtime·Build·Configuration 의존성 확인 필요 | Container Image는 이식성이 높아질 수 있지만 주변 Platform 설정은 별개 | Kubernetes API는 공통 기반을 제공하지만 Storage·Load Balancer·IAM 등 Provider Integration은 별도 |
| Platform Operations | OS·Runtime·Patch·Agent 등을 팀이 관리 | 낮음 | 낮음~중간 | 중간~높음. Managed/Auto Mode에 따라 Node 운영 부담은 크게 줄어들 수 있음 |
| Observability | Agent와 수집 경로까지 직접 설계 | 기본 Platform Telemetry 활용 가능. Application 관측은 여전히 팀 책임 | Platform Log·Metric Integration 활용 가능. Application Trace·SLI는 별도 | Application뿐 아니라 Cluster·Pod·Node·Control Surface까지 관측 범위가 넓어짐 |
| Security Responsibility | Application에 더해 OS Patch·Host·Network 책임이 큼 | OS 책임은 Provider 쪽으로 이동하지만 Code·Data·Identity·Configuration은 팀 책임 | Image·Application·IAM·Secret·Configuration을 팀이 책임 | Application 책임에 RBAC, Pod Security, Workload Identity, Network Policy 등 Kubernetes 운영 책임이 추가될 수 있음 |
| On-call Capability | Host와 Application 장애를 모두 처리할 능력이 필요 | Platform 장애는 Provider Escalation 가능. Application 장애 책임은 남음 | Container Workload와 Dependency 중심으로 대응 | Cluster/Workload Layer까지 대응 가능한 운영 체계가 필요. Auto Mode라도 Application 책임은 남음 |
| Regulatory / Isolation | Dedicated VM·Network 등 세밀한 구조를 설계하기 쉬우나 준수 책임도 직접 가짐 | Platform이 요구 통제를 제공하는지 먼저 검증 | 해당 Service의 Isolation·Region·Network 조건을 검증 | 세밀한 정책을 구현할 수 있지만 Kubernetes 사용 자체가 규제 준수를 증명하지 않음 |
| Team Capability | Linux·Network·Patch·Automation 운영 능력이 중요 | Application 운영 능력 중심 | Container·Image·Cloud Runtime 이해가 필요 | Kubernetes 운영·Networking·Resource·Security·Upgrade·Incident 역량 필요 |
| Exit Cost | OS/App 이동 외에 Data·Network·Automation 재구성 비용 확인 | Runtime·Build·Platform API 의존성 확인 | Image 외에 IAM·Scaling·Network·Managed Service 의존성 확인 | Manifest뿐 아니라 CSI·Load Balancer·IAM·Observability·Data 의존성을 확인 |
이 Matrix에서 눈여겨볼 부분은 Kubernetes 열의 운영 부담이 하나의 값이 아니라는 점이다. Kubernetes 공식 문서부터 Production Cluster를 직접 운영할지 Provider에 얼마나 위임할지를 먼저 결정하라고 안내한다. 현재 GKE Autopilot이나 EKS Auto Mode처럼 Worker Node와 Infrastructure Operation의 상당 부분까지 Provider가 가져가는 형태도 존재한다.
반대로 관리형 서비스라고 해서 Application 책임까지 없어지지도 않는다. Microsoft의 Shared Responsibility Model에서 IaaS는 고객이 VM·OS·Application을 관리하고 PaaS는 OS 책임이 Provider 쪽으로 이동하지만 데이터·Identity·Configuration과 Application 수준의 책임은 계속 고객에게 남는다.
VM은 오래된 선택이 아니라 ‘OS까지 통제하겠다’는 선택이다
VM의 장점은 단순하다. 무엇을 설치할지, 어떤 Process를 실행할지, Network와 File System을 어떻게 구성할지 직접 결정할 수 있다.
오래된 Application, 특수한 System Package, 특정 Daemon, 기존 방식의 Stateful Service, OS 수준의 설정이 중요한 Workload라면 이 통제가 오히려 가장 단순한 해법일 수 있다.
문제는 통제권과 함께 운영 책임도 돌아온다는 것이다.
OS 보안 업데이트가 밀렸을 때 누가 처리할지, Runtime을 언제 올릴지, Disk가 가득 차면 누가 대응할지, 서버 한 대가 내려갔을 때 어떻게 다시 띄울지까지 팀의 문제다.
따라서 “트래픽이 작으니 VM”보다 더 나은 질문은 다음이다.
이 Workload가 OS 통제를 실제로 필요로 하는가, 그리고 그 OS를 계속 운영할 사람이 있는가?
둘 중 하나라도 아니면 VM의 자유도는 장점보다 미사용 책임이 될 수 있다.
PaaS는 기능이 적은 플랫폼이 아니라 책임을 제한하는 계약에 가깝다
PaaS의 가장 큰 장점은 Server 숫자가 적다는 데 있지 않다. 팀이 책임져야 할 Layer가 줄어든다는 데 있다.
Azure의 현재 Shared Responsibility 문서도 PaaS에서 Provider가 OS와 Platform Service를 관리하고 사용자는 Application·Data·Identity·Configuration에 더 집중하는 구조를 보여준다.
일반적인 Web Application, REST API, Background Process가 Platform이 지원하는 Runtime과 Deployment Model 안에서 충분히 동작한다면 이 제약은 손해가 아닐 수 있다.
오히려 “OS에 접속해서 무엇이든 할 수 없음”이 운영 복잡성을 막는 Guardrail 역할을 한다.
반대로 특정 System Package, Runtime Extension, 특수 Networking, 장시간 Process, 지원되지 않는 Protocol처럼 Platform Contract 바깥의 요구가 반복되면 PaaS를 억지로 우회하는 비용이 커진다.
그때 필요한 것은 곧바로 Kubernetes가 아니라 한 단계 더 많은 Application Runtime 통제가 필요한지 확인하는 것이다.
Managed Container는 Container의 자유도와 PaaS의 운영 경계를 절충한다
Managed Container는 이 중간 영역을 맡는다.
팀은 자신이 만든 Container Image에 Runtime과 System Dependency를 포함할 수 있지만 어느 VM에 배치할지, Host OS를 어떻게 패치할지, Cluster Control Plane을 어떻게 운영할지는 Provider에 넘긴다.
현재 Cloud Run은 HTTP Service뿐 아니라 Batch Job과 항상 실행되는 Worker Pool까지 지원한다. Service는 부하에 따라 Instance를 자동으로 늘리고 줄일 수 있고 필요하면 최소·최대 Instance나 Manual Scaling도 구성할 수 있다.
Azure Container Apps 역시 Server나 Container Orchestration Infrastructure를 직접 운영하지 않고 Container Application을 배포하고 HTTP·Event·CPU·Memory 조건에 따라 확장하는 모델을 제공한다.
그래서 다음과 같은 상황이라면 Managed Container가 강한 후보가 된다.
표준 PaaS Runtime보다 자유로운 Image가 필요하지만 Node에는 관심이 없고 API·Worker·Job을 독립적으로 배포하면서 Traffic 변화는 Platform에 맡기고 싶은 경우다.
그러나 여기에서도 팀의 책임은 사라지지 않는다. 잘못된 Container Image, Secret, IAM, Application Memory Leak, DB Connection 고갈이나 잘못 잡은 최대 Instance 수는 Provider가 대신 해결해주지 않는다.
Platform Operations를 줄인 것이지 Application Operations를 제거한 것이 아니다.
Kubernetes가 필요한 시점은 ‘트래픽이 커질 때’가 아니다
Kubernetes를 도입할 가장 약한 근거 중 하나가 “나중에 커질 것 같아서”다.
Traffic이 급격히 늘어난다는 이유만으로 Kubernetes가 필요한 것은 아니다. 관리형 Container Platform도 Traffic이나 Event에 따라 Instance를 확장할 수 있다.
서비스 수 역시 단독 기준이 아니다.
열 개의 API가 모두 같은 배포·Network·Security 패턴을 사용한다면 Managed Container에서 충분히 운영할 수도 있다. 반대로 서비스 수가 많지 않아도 Workload Scheduling, 특수 Hardware, 세밀한 Network Policy, Kubernetes 생태계의 Operator나 CRD, 조직 공통의 Deployment Policy를 직접 통제해야 한다면 Kubernetes의 API가 의미를 가질 수 있다.
Kubernetes를 검토할 이유는 대체로 같은 운영 문제를 여러 Workload에 반복해서 해결해야 하고 그 문제를 Platform API와 Policy로 표준화할 가치가 있을 때 생긴다.
대신 Production Kubernetes가 추가하는 운영면을 무시해서는 안 된다.
Kubernetes 공식 문서는 Production 환경에서 Control Plane의 가용성뿐 아니라 Worker Node, User Access, Resource Policy 등을 별도로 다뤄야 한다고 설명한다. Managed Kubernetes는 이 중 일부를 Provider에 맡기지만 GKE의 현재 Shared Responsibility 문서에서도 Application Code, Build File, Container Image, Data, IAM/RBAC, Pod와 Workload, Monitoring과 Incident Response 등 상당한 책임은 사용자에게 남아 있다.
“Managed Kubernetes니까 Cluster 운영을 몰라도 된다”도 정확하지 않다.
EKS Auto Mode나 GKE Autopilot처럼 Node·Patch·Scaling을 더 많이 위임할 수 있는 모델은 분명 운영 부담을 낮춘다. 하지만 Kubernetes API를 사용하는 Workload의 Resource, Policy, Identity, Deployment와 장애 판단까지 Provider가 대신 소유하는 것은 아니다.
팀원 수가 아니라 실제 운영 능력을 적어보자
“개발자 5명인데 Kubernetes가 가능한가?”라는 질문만으로는 판단할 수 없다.
다섯 명 중 한 명이 Production Kubernetes와 Network, Incident Response를 지속적으로 담당할 수 있는 팀과, 다섯 명 모두 Product Feature 개발이 주업무인 팀은 전혀 다른 Complexity Budget을 가진다.
다음 역할의 실제 Owner가 있는지를 적는 편이 낫다.
[Complexity Budget Card]
OS / Host Patch 책임:
Runtime / Base Image Upgrade 책임: Deployment / Rollback 책임: Network / Access Policy 책임: Secret / Identity 책임: Scaling 정책 책임: Application Observability 책임: Platform Observability 책임: Backup / Restore 책임: Incident Commander: 야간·휴일 Escalation: Platform Upgrade 책임: Provider Support Escalation: 각 항목의 Runbook 존재 여부: 최근 실제 복구 또는 장애 훈련:
사람 이름을 채우는 것만으로 충분하지 않다.
해당 업무를 수행할 시간과 권한, 관측 수단, Runbook과 Escalation 경로까지 있어야 실제 운영 능력으로 볼 수 있다.
이 때문에 세 명의 팀도 Kubernetes가 합리적인 경우가 있을 수 있고 개발자가 수십 명인 조직도 Platform Ownership이 없다면 Kubernetes 운영이 적합하지 않을 수 있다.
Stateful이라는 이유만으로 Kubernetes를 선택할 필요도 없다
Kubernetes는 StatefulSet과 Persistent Volume을 통해 Stateful Workload를 실행할 수 있다. 그렇다고 Database를 Kubernetes 안에 넣는 것이 자동으로 더 좋은 운영 모델이 되는 것은 아니다.
Persistent Storage를 운영하면 Volume Provisioning, Availability Zone, Backup, Restore, Upgrade와 Failure Recovery를 함께 다뤄야 한다.
Kubernetes의 StorageClass도 실제 Storage를 생성하는 provisioner와 Provider별 Parameter를 사용한다. 공식 문서의 AWS EBS, EFS, Azure, vSphere 등의 예시에서도 같은 Kubernetes API 뒤에 서로 다른 Storage Integration이 붙는다.
작은 팀이라면 Application Compute는 PaaS나 Managed Container에 두고 State는 Managed Database에 맡기는 조합이 더 낮은 Complexity Budget을 요구할 수도 있다.
반대로 Data Locality나 Storage Control 때문에 직접 운영이 필요하다면 VM 또는 Kubernetes가 후보가 될 수 있다.
Stateful이라는 단어 하나가 답을 정하는 것이 아니다.
Portability도 Container Image 하나로 판단하면 안 된다
Container를 사용하면 Application Runtime을 일정한 Image로 패키징할 수 있어 Compute 이동성에는 도움이 된다.
Kubernetes도 공통 API를 제공해 Deployment나 Service 같은 일부 운영 표현을 여러 환경에서 재사용하기 쉽게 만든다.
그러나 이것을 “Kubernetes를 쓰면 Vendor Lock-in이 사라진다”로 확대하면 안 된다.
예를 들어 Kubernetes의 Service type: LoadBalancer는 외부 Load Balancer라는 공통 개념을 제공하지만 실제 구현은 Cloud Provider가 담당하며 Provider별 Annotation과 제약이 존재할 수 있다.
Storage 역시 CSI Provisioner, StorageClass Parameter, 실제 Storage Backend에 따라 달라진다.
실제 Exit Cost는 다음을 함께 계산해야 한다.
Exit Cost
=Application 변경 + Runtime / Deployment 설정 변경 + Network / Security 재구성 + Data 이동 + IAM / Secret 재구성 + CI/CD 변경 + Observability 변경 + 운영 절차와 교육 변경
VM이라고 이 비용이 0이 되는 것도 아니고 PaaS라서 반드시 큰 것도 아니며 Kubernetes라고 자동으로 작아지는 것도 아니다.
Compute Portability와 System Exit Cost는 다른 지표다.
규제와 격리 요구도 Technology 이름으로 해결되지 않는다
규제가 있다는 이유로 “PaaS는 안 되고 Kubernetes여야 한다”거나, 반대로 “Managed Service니까 보안은 Provider가 책임진다”고 결론내릴 수도 없다.
확인해야 할 것은 실제 요구사항이다.
특정 Region에 Data를 보관해야 하는지, Dedicated Host가 필요한지, Network 경로를 통제해야 하는지, 관리자 접근을 감사해야 하는지, Workload 간 격리 수준이 어느 정도인지부터 확정해야 한다.
그다음 각 서비스가 해당 통제를 실제로 제공하는지 비교해야 한다.
Kubernetes는 많은 통제를 구현할 수 있는 도구지만 Kubernetes라는 이름 자체가 Compliance Evidence는 아니다. Managed Service 또한 Provider가 Infrastructure를 책임진다는 이유만으로 고객의 Data·Identity·Application 책임이 없어지지 않는다.
실제 선택은 이 순서가 가장 단순하다
Parent Article에서 Workload Placement Card가 만들어졌다면 이제 다음 순서로 좁힐 수 있다. Parent는 워크로드와 제약조건을 먼저 확인하고 Operating Model을 정한 뒤 Vendor를 비교하도록 경계를 잡고 있다.
Workload가 반드시 요구하는 통제를 적는다. OS 접근, 특수 Runtime, Network, Isolation, GPU, Deployment Policy처럼 없으면 후보에서 탈락할 항목만 남긴다.
각 모델에서 팀에 남는 반복 운영 업무를 적는다. Patch, Upgrade, Scaling, Network, Observability, Backup, Incident Response의 Owner를 확인한다.
필요한 통제를 제공하지 못하는 후보를 제거한다. Platform 제약을 억지로 우회해서 후보를 유지하지 않는다.
팀의 Complexity Budget을 넘는 후보를 제거한다. “배울 수 있다”는 계획과 현재 Production을 책임질 능력을 구분한다.
남은 후보 중 Exit Cost와 운영 복잡성이 가장 낮은 모델을 고른다.
Vendor와 상품은 마지막에 비교한다. 같은 Operating Model 안에서도 Region, Networking, Scaling, Support와 실제 책임 경계가 다르기 때문이다.
이 순서는 PaaS에서 시작해 Kubernetes까지 차례대로 승급하라는 뜻이 아니다.
처음부터 VM이 맞을 수 있고 PaaS에 오래 머무는 것이 합리적일 수 있으며 Managed Container와 Kubernetes를 동시에 사용하는 것도 가능하다.
몇 가지 Workload를 대입해보면 차이가 더 잘 보인다
| 상황 | 먼저 볼 후보 | 이유 | 추가 확인 |
|---|---|---|---|
| 공개 Web API + Worker + 외부 Managed DB, Traffic 변동 큼, 표준 HTTP | PaaS / Managed Container | OS나 Cluster보다 Application 배포와 Autoscaling이 중요 | PaaS Runtime 제약, Container 필요 여부, Cold Start, DB Connection |
| 오래된 업무 Application, 특정 Daemon·System Package와 OS 설정 필요 | VM | OS 통제가 실제 요구사항 | Patch, Backup, Failover, Deployment 자동화 Owner |
| 여러 API·Worker·Batch가 독립 배포되지만 Network와 Scheduling 요구는 표준적 | Managed Container / PaaS | 독립 배포는 필요하지만 Cluster Control까지는 필요하지 않을 수 있음 | Service별 Scaling, IAM, Cost, Platform Limit |
| 여러 팀과 Workload가 공통 Platform을 사용하며 세밀한 Scheduling·Policy·Network Control 필요 | Kubernetes | 반복되는 운영 문제를 공통 API와 Policy로 만들 가치가 있음 | Platform Owner, Upgrade, RBAC, Network, Observability, On-call |
| 특정 규정 때문에 전용 격리·Network·Audit 조건 존재 | 요구사항에 따라 VM / Managed Platform / Kubernetes 모두 가능 | Technology 이름이 아니라 실제 통제 요건이 후보를 결정 | 규정 원문, Provider Architecture, Audit Scope |
이 표에서도 서비스 수나 회사 규모가 직접적인 선택 기준으로 등장하지 않는다.
그 숫자는 운영 복잡성을 만드는 여러 입력 중 하나일 뿐이다.
가장 낮은 추상화가 가장 강한 것도, 가장 높은 추상화가 가장 좋은 것도 아니다
VM은 자유도가 높지만 그 자유를 유지하기 위해 OS를 운영해야 한다.
PaaS는 많은 결정을 Platform에 넘기지만 그 대신 Platform Contract를 받아들여야 한다.
Managed Container는 Application Runtime 자유도와 Platform 운영 위임 사이의 중간 선택을 제공한다.
Kubernetes는 Scheduling, Policy, Networking과 Platform Extension에 높은 통제력을 제공하지만 그 API와 Workload 운영에 대한 책임도 함께 가져온다. Managed Kubernetes의 발전으로 그 부담을 상당히 줄일 수는 있어도 책임 경계가 완전히 없어지는 것은 아니다.
작은 개발팀에 필요한 질문은 “Kubernetes를 쓸 만큼 컸는가?”가 아니다.
지금 Workload가 요구하는 통제 수준은 어디까지이며 그 통제를 얻기 위해 생기는 반복적인 운영 책임을 앞으로도 감당할 수 있는가?
그 답을 먼저 적으면 VM, PaaS, Managed Container, Kubernetes는 성숙도 순서가 아니라 서로 다른 책임 계약으로 보이기 시작한다.
그리고 그때부터 Compute 선택이 훨씬 단순해진다.