클라우드 업데이트를 전부 읽으면 안 되는 이유: 운영자의 필터링 기준

매주 AWS 업데이트 이메일을 열어보면 30~50개의 변경 사항이 쌓여 있다. Azure, Kubernetes, Terraform, GitHub Actions까지 합치면 하루에도 수십 개의 릴리스 노트가 업계에 쏟아진다. 이걸 전부 읽는 것은 불가능하다. 더 중요한 것은 — 다 읽을 필요도 없다는 점이다.

요약

클라우드와 오픈소스 생태계는 빠른 속도로 업데이트를 내놓는다. 운영자에게 필요한 것은 모든 변경 사항을 쫓아가는 것이 아니라, 자신의 운영 환경에 실제로 영향을 주는 업데이트를 빠르게 식별하는 능력이다. 이 글에서는 최근 Kubernetes 1.35와 Microsoft Build 2026에서 발표된 AKS 업데이트를 사례로 삼아, 운영자가 클라우드 업데이트를 읽는 실용적인 필터링 기준을 정리한다.

이 글이 필요한 사람

• AWS, Azure, Kubernetes, Terraform 관련 릴리스 노트를 구독하고 있지만 실제로 무엇을 읽어야 할지 막막한 엔지니어
• 업데이트를 놓쳤다가 운영 환경에서 문제가 생긴 경험이 있는 클라우드 운영 담당자
• 팀에 업데이트 내용을 공유해야 하는 시니어 DevOps, SRE 엔지니어

왜 지금 이 주제인가

Kubernetes 1.35가 2025년 12월 릴리스되었고, AWS EKS와 AKS 모두 2026년 1월부터 1.35를 지원하기 시작했다. 5월에는 Microsoft Build 2026에서 AKS 관련 주요 업데이트가 발표되었다. 반년에 두 번씩 나오는 Kubernetes 마이너 릴리스, 상시 갱신되는 managed 서비스 업데이트, 그리고 CNCF 생태계 전반의 변화까지 더하면 운영자가 따라가야 할 정보의 양은 실질적으로 통제하기 어려운 수준이다.

이 상황에서 운영자에게 필요한 것은 "무엇이 나왔는가"보다 "내 운영 환경에서 무엇이 중요한가"를 판단하는 기준이다.

운영자 관점에서 업데이트를 읽는 4가지 기준

1. GA / Beta / Alpha 여부를 먼저 확인한다

Kubernetes를 예로 들면, 릴리스 노트에는 항상 Stable(GA), Beta, Alpha 세 단계의 기능이 섞여 있다. 운영 환경에서 즉각적으로 대응이 필요한 것은 대부분 Stable로 승격된 기능이다.

Kubernetes 1.35에서 주목할 GA 기능은 두 가지다.

In-Place Pod Resize (GA): 실행 중인 Pod의 CPU, 메모리 리소스를 컨테이너 재시작 없이 조정하는 기능이다. 이전에는 리소스 요청이나 한도를 변경하면 Pod를 재스케줄링해야 했다. VPA(Vertical Pod Autoscaler)와의 연계에서 특히 운영 편의성이 높아진다. 트래픽 급증 상황에서 Pod 재시작 없이 리소스를 늘릴 수 있다는 점은 가용성에 직접 영향을 준다.

Image Volumes (Stable): OCI 이미지를 레지스트리에서 직접 끌어와 Pod 내부에 읽기 전용 볼륨으로 마운트하는 기능이다. ML 모델, 정적 설정 파일, 라이선스 파일 등을 컨테이너 이미지에 묶지 않고 분리해서 주입할 수 있다. 이미지 크기 관리와 보안 경계 분리 측면에서 유용하다.

반면 Gang Scheduling(Alpha)처럼 AI/ML 작업에 유용한 기능은 현재 프로덕션 적용 대상이 아니다. Alpha 기능은 API가 바뀔 수 있고 기본값이 off다. 관심은 가지되 즉각 대응을 요구하지 않는다.

2. Breaking Change와 Deprecation을 체크한다

Breaking change와 deprecation은 가장 위험한 업데이트다. 모르고 지나치면 업그레이드 후 장애로 이어진다.

AKS에서는 2026년 6월 8일부터 Flatcar Container Linux 지원이 종료되었다. 이미 Flatcar 노드풀을 사용 중인 클러스터는 마이그레이션 계획이 없었다면 이 시점부터 새 노드풀 생성이 불가능하다. Azure Container Linux(ACL)로 전환해야 한다.

Kubernetes 생태계에서는 특정 API 버전의 deprecation이 반복적으로 운영 사고를 만든다. 1.25에서 PodSecurityPolicy(PSP)가 제거되었을 때처럼, 릴리스 노트에서 deprecated, removed, breaking 키워드는 반드시 먼저 검색해야 한다.

3. 관리형 서비스의 자동 반영 여부를 확인한다

EKS, AKS, GKE 같은 관리형 Kubernetes 서비스는 일부 기능을 자동으로 적용하고, 일부는 사용자가 명시적으로 활성화해야 한다. 같은 Kubernetes 기능이라도 플랫폼에 따라 사용 가능 시점과 방식이 다르다.

AKS에서 Microsoft Build 2026 시점에 GA된 Managed System Node Pool 기능이 좋은 예다. 기존에는 시스템 노드풀의 용량 계획, 패치, 스케일링을 수동으로 관리했다. GA 이후에는 Azure가 이 노드풀의 생애주기를 직접 관리한다. 이 기능이 어떻게 기존 노드풀 설정과 상호작용하는지, 기존 클러스터에 소급 적용 가능한지는 릴리스 노트보다 공식 문서와 GitHub 릴리스 항목에서 확인해야 한다.

4. 보안 패치와 CVE는 별도 추적한다

보안 업데이트는 GA/Alpha 기준과 상관없이 즉각 대응이 원칙이다. Kubernetes, Cilium, containerd, 그리고 사용 중인 클라우드 제공자의 보안 게시판을 별도로 구독해야 한다.

Cilium을 사용하는 AKS 클러스터를 운영 중이라면, AKS 릴리스 2026-05-29에서 Kubernetes 1.34를 위한 Cilium v1.18.9 에이전트 및 오퍼레이터 이미지가 업데이트된 사실을 알고 있어야 한다. 보안 패치가 포함된 경우 클러스터 업그레이드 타임라인에 영향을 준다.

AKS / EKS 관점

AKS

Microsoft Build 2026에서 AKS의 주요 업데이트 방향은 두 가지로 요약된다.

첫째, 멀티 클러스터 운영을 위한 네트워킹 기반이다. AKS Fleet Manager에 Managed Cilium 기반의 크로스 클러스터 네트워킹이 퍼블릭 프리뷰로 도입되었다. 여러 클러스터에 분산된 서비스 간 통신에서 서비스 디스커버리, 정책 적용, 옵저버빌리티를 통합 관리할 수 있다. 멀티 클러스터 구성을 이미 사용 중이거나 계획 중인 팀은 아키텍처 검토 시 고려할 만하다.

둘째, 운영자 부담을 줄이는 자동화다. Managed System Node Pool GA를 통해 시스템 컴포넌트 운영의 책임 범위가 Azure 쪽으로 더 이동했다. Azure Monitor 워크스페이스에서 PromQL 쿼리 스코프를 Azure 리소스 단위로 설정할 수 있는 기능도 추가되어, 모니터링 권한 관리가 더 세밀해졌다.

AWS EKS

EKS는 2026년 1월부터 Kubernetes 1.35를 지원한다. In-Place Pod Resize 같은 GA 기능은 EKS에서도 사용 가능하다. 단, EKS의 Kubernetes 버전 지원 주기와 EOL 일정은 별도로 관리된다. 클러스터 버전 업그레이드 계획이 있다면 aws.amazon.com/kubernetes/eks-kubernetes-release-calendar 를 정기적으로 확인하는 것이 좋다.

실무 체크리스트

• 주요 업데이트 소스를 구독 목록으로 정리해두기: AWS What's New, Azure Updates, Kubernetes 공식 블로그, CNCF 블로그
• 릴리스 노트 열람 순서 고정하기: 1) Breaking/Deprecated → 2) GA 기능 → 3) 보안 패치 → 4) Beta/Alpha
• Managed 서비스 업데이트는 GitHub 릴리스 태그(예: github.com/Azure/AKS/releases)를 구독해 변경 이력 직접 추적
• Kubernetes 버전별 지원 종료 일정을 분기마다 확인하고 업그레이드 로드맵에 반영
• CVE와 보안 패치는 별도 채널(예: Kubernetes 보안 공지 메일링 리스트, 클라우드 보안 게시판)에서 추적

흔한 실수

모든 업데이트를 같은 비중으로 읽는다: Alpha 기능 소개 글에 시간을 쓰다가 GA된 Breaking Change를 놓치는 경우가 생긴다. 릴리스 노트를 읽기 전에 필터링 기준을 먼저 적용하는 습관이 필요하다.

관리형 서비스를 믿고 버전 업그레이드를 방치한다: EKS, AKS 모두 특정 Kubernetes 버전의 지원 종료 이후에는 강제 업그레이드를 진행한다. 미리 준비하지 않으면 운영팀이 갑작스러운 업그레이드를 수행해야 하는 상황이 생긴다.

팀 내 업데이트 공유를 개인에게만 의존한다: 특정 인원만 업데이트를 추적하는 구조는 그 인원이 자리를 비울 때 리스크가 생긴다. 릴리스 노트 요약을 팀 채널에 정기적으로 공유하는 루틴이 필요하다.

마무리

클라우드 업데이트를 따라가는 것이 목적이 아니다. 업데이트가 내 운영 환경에 어떤 영향을 주는지, 언제 무엇을 해야 하는지를 판단하는 것이 목적이다. Kubernetes 1.35의 In-Place Pod Resize GA는 실제로 VPA 전략을 재검토할 계기가 되고, AKS Fleet Manager의 크로스 클러스터 네트워킹 프리뷰는 멀티 클러스터 설계 회의에서 언급할 가치가 있다. 이 둘이 지금 내 운영에 영향을 주는지를 먼저 판단하고, 그 판단에 따라 깊이를 결정하면 된다.

---

이 글이 유용했다면 다음 편도 확인해보세요. 다음 글: 데이터 플랫폼은 왜 Lakehouse 구조로 설명되는가

References

• Kubernetes v1.35: New level of efficiency with in-place Pod restart
• Kubernetes 1.35 Released with In-Place Pod Resize and AI-Optimized Scheduling - InfoQ
• What's new in Azure Kubernetes Service at Microsoft Build 2026
• Release Release 2026-05-29 · Azure/AKS
• Amazon EKS and Amazon EKS Distro now supports Kubernetes version 1.35
• Kubernetes 1.35 "Timbernetes" Introduces Vertical Scaling - The New Stack

---