작은 개발팀은 VM, PaaS, 컨테이너, Kubernetes 중 무엇을 선택해야 할까

컨테이너와 운영 모델을 먼저 구분한다

작은 팀은 PaaS를 쓰고 회사가 커지면 Kubernetes로 옮겨야 한다는 식의 설명은 실제 선택에 별 도움이 되지 않습니다. 팀원 수가 같아도 Linux·Network·Incident Response를 직접 운영할 수 있는 팀과 Application 개발에 집중하는 팀은 감당할 수 있는 인프라 책임이 전혀 다르기 때문입니다.

Compute 선택에서 먼저 물어야 할 것은 "우리에게 얼마나 큰 기술이 필요한가"가 아닙니다. "어떤 통제가 반드시 필요하고 그 통제를 얻기 위해 생기는 반복적인 운영 업무를 누가 계속 맡을 것인가"입니다.

VM, PaaS, Managed Container, Kubernetes는 발전 단계가 아닙니다. 같은 회사에서도 오래된 업무 시스템은 VM에, 공개 API는 Managed Container에, 다른 플랫폼 워크로드는 Kubernetes에 둘 수 있습니다. 가장 적합한 모델은 필요한 통제를 충족하는 후보 중에서 팀의 Complexity Budget 안에 들어오는 모델입니다.

Container는 애플리케이션을 패키징하고 실행하는 방법이지 그 자체가 하나의 운영 책임 모델은 아닙니다. PaaS가 Container Image 배포를 받을 수도 있고 Kubernetes도 Container를 실행합니다. 반대로 VM 한 대에서 Docker를 직접 운영할 수도 있습니다. 그래서 이 글에서 비교하는 네 모델은 아래 정의를 따릅니다.

Managed Container의 대표적인 형태는 Cloud Run이나 Azure Container Apps처럼 Container를 배포하지만 Kubernetes Cluster를 직접 운영하지 않는 서비스입니다. Cloud Run의 현재 문서도 별도의 Cluster를 생성하거나 Infrastructure를 관리하지 않고 Service·Job·Worker Pool을 실행하는 구조를 설명합니다. Kubernetes는 Managed Kubernetes로 Control Plane을 Provider에 맡기더라도 Application과 Workload Policy까지 자동으로 사라지지는 않습니다.^[2] 즉 "Container를 쓰고 싶다"는 이유만으로 Kubernetes가 필요한 것은 아닙니다.

VM

Guest OS부터 상당 부분을 팀이 직접 관리하는 모델입니다.

PaaS

Source나 Application Artifact를 올리면 Provider가 OS와 Runtime을 포함한 Platform 영역을 크게 관리하는 모델입니다.

Managed Container

Container Image의 자유도는 유지하되 Cluster와 Host 운영을 Provider에 넘기는 모델입니다. Container를 배포하지만 Kubernetes Cluster를 직접 운영하지 않는 형태가 대표적입니다.

Kubernetes

Container Workload의 Scheduling, Service Discovery, Resource Policy, Rollout, Networking, Storage Integration을 Kubernetes API로 제어하는 운영 모델입니다.

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가 있어야 합니다.^[3] 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입니다.

이 Matrix에서 눈여겨볼 부분은 Kubernetes 열의 운영 부담이 하나의 값이 아니라는 점입니다. Kubernetes 공식 문서부터 Production Cluster를 직접 운영할지 Provider에 얼마나 위임할지를 먼저 결정하라고 안내합니다.^[6] 현재 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 수준의 책임은 계속 고객에게 남습니다.^[4]

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에 더 집중하는 구조를 보여 줍니다.^[4]

일반적인 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는 자유도와 운영 경계의 절충이다

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 조건에 따라 확장하는 모델을 제공합니다.

그래서 표준 PaaS Runtime보다 자유로운 Image가 필요하지만 Node에는 관심이 없고, API·Worker·Job을 독립적으로 배포하면서 Traffic 변화는 Platform에 맡기고 싶은 경우라면 Managed Container가 강한 후보가 됩니다.

그러나 여기에서도 팀의 책임은 사라지지 않습니다. 잘못된 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 등을 별도로 다뤄야 한다고 설명합니다.^[7] 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, Platform Upgrade의 책임자를 적습니다. Incident Commander와 야간·휴일 Escalation, Provider Support Escalation 담당을 적습니다. 마지막으로 각 항목의 Runbook 존재 여부와 최근 실제 복구 또는 장애 훈련 일자를 적습니다.

사람 이름을 채우는 것만으로 충분하지 않습니다. 해당 업무를 수행할 시간과 권한, 관측 수단, Runbook과 Escalation 경로까지 있어야 실제 운영 능력으로 볼 수 있습니다.^[5] 이 때문에 세 명의 팀도 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이 붙습니다.^[2]

작은 팀이라면 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에 따라 달라집니다.^[2]

실제 Exit Cost는 다음을 함께 계산해야 합니다. Exit Cost는 아래 계산 항목으로 정리합니다. VM이라고 이 비용이 0이 되는 것도 아니고 PaaS라서 반드시 큰 것도 아니며 Kubernetes라고 자동으로 작아지는 것도 아닙니다. Compute Portability와 System Exit Cost는 다른 지표입니다.

Exit Cost

아래 여덟 비용 항목의 합계입니다.

Application 변경

총비용에 합산합니다.

Runtime / Deployment 설정 변경

총비용에 합산합니다.

Network / Security 재구성

총비용에 합산합니다.

Data 이동

총비용에 합산합니다.

IAM / Secret 재구성

총비용에 합산합니다.

CI/CD 변경

총비용에 합산합니다.

Observability 변경

총비용에 합산합니다.

운영 절차와 교육 변경

총비용에 합산합니다.

규제와 격리 요구는 Technology 이름으로 해결되지 않는다

규제가 있다는 이유로 "PaaS는 안 되고 Kubernetes여야 한다"거나, 반대로 "Managed Service니까 보안은 Provider가 책임진다"고 결론내릴 수도 없습니다. 확인해야 할 것은 실제 요구사항입니다.

특정 Region에 Data를 보관해야 하는지, Dedicated Host가 필요한지, Network 경로를 통제해야 하는지, 관리자 접근을 감사해야 하는지, Workload 간 격리 수준이 어느 정도인지부터 확정해야 합니다. 그다음 각 서비스가 해당 통제를 실제로 제공하는지 비교해야 합니다.^[8]

Kubernetes는 많은 통제를 구현할 수 있는 도구지만 Kubernetes라는 이름 자체가 Compliance Evidence는 아닙니다. Managed Service 또한 Provider가 Infrastructure를 책임진다는 이유만으로 고객의 Data·Identity·Application 책임이 없어지지 않습니다.

실제 선택은 이 순서가 가장 단순하다

먼저 읽는 글에서 Workload Placement Card가 만들어졌다면 이제 다음 순서로 좁힐 수 있습니다. 그 글은 워크로드와 제약 조건을 먼저 확인하고 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를 대입해 보면 차이가 더 잘 보인다

아래 표는 몇 가지 대표적인 상황에 네 모델을 대입한 결과입니다. 이 표에서도 서비스 수나 회사 규모가 직접적인 선택 기준으로 등장하지 않습니다. 그 숫자는 운영 복잡성을 만드는 여러 입력 중 하나일 뿐입니다.

가장 높은 추상화가 가장 좋은 것은 아니다

가장 낮은 추상화가 가장 강한 것도, 가장 높은 추상화가 가장 좋은 것도 아닙니다. VM은 자유도가 높지만 그 자유를 유지하기 위해 OS를 운영해야 합니다. PaaS는 많은 결정을 Platform에 넘기지만 그 대신 Platform Contract를 받아들여야 합니다. Managed Container는 Application Runtime 자유도와 Platform 운영 위임 사이의 중간 선택을 제공합니다.

Kubernetes는 Scheduling, Policy, Networking과 Platform Extension에 높은 통제력을 제공하지만 그 API와 Workload 운영에 대한 책임도 함께 가져옵니다.^[1] Managed Kubernetes의 발전으로 그 부담을 상당히 줄일 수는 있어도 책임 경계가 완전히 없어지는 것은 아닙니다.

작은 개발팀에 필요한 질문은 "Kubernetes를 쓸 만큼 컸는가?"가 아닙니다. 지금 Workload가 요구하는 통제 수준은 어디까지이며 그 통제를 얻기 위해 생기는 반복적인 운영 책임을 앞으로도 감당할 수 있는가입니다. 그 답을 먼저 적으면 VM, PaaS, Managed Container, Kubernetes는 성숙도 순서가 아니라 서로 다른 책임 계약으로 보이기 시작합니다. 그리고 그때부터 Compute 선택이 훨씬 단순해집니다.