Ingress NGINX, 28년까지 내다보고 결정해야 하는 이유

Bro's Insights
, ,
1

Ingress NGINX는 2026년 3월 31일 공식 은퇴했습니다. 이미 지나간 사건을 언급하기 보다 다음 18개월 동안 Kubernetes north-south traffic 레이어가 AI 워크로드용으로 재정의되는 국면에서 어느 도구를 고르느냐를 다루어보고자 합니다.

1. 은퇴 한 달, 실제로 벌어진 일은?

공식 은퇴 발표는 2025년 11월 11일 SIG Network와 Security Response Committee가 냈습니다. 2026년 1월 29일 Kubernetes Steering Committee와 SRC가 공동 urgency 성명을 내고, 3월 31일 kubernetes/ingress-nginx 저장소가 read-only로 전환됐습니다. GitHub 저장소는 kubernetes-retired 조직으로 이동했습니다.

은퇴 후 첫 달에 이미 두 건의 CVE가 공개됐습니다. Datadog이 4월 보고한 CVE-2026-24512와 CVE-2026-3288입니다. 이번에는 패치가 나오지 않습니다. Steering Committee가 1월 성명에서 "Choosing to remain with Ingress NGINX after its retirement leaves you and your users vulnerable to attack"라고 쓴 문장이 말 그대로 현실이 됐습니다.

CNCF 자체도 4월 13일에야 내부 서비스 클러스터의 ingress-nginx를 Envoy Gateway로 이전 완료했습니다. 마이그레이션 난이도와 현장 속도를 보여주는 구체적 지표입니다.

2. "Half of cloud native"라는 숫자는 여전히 크다

Steering Committee 1월 성명의 표현은 "Kubernetes will retire Ingress NGINX, a piece of critical infrastructure for about half of cloud native environments"입니다. Traefik CEO가 제시한 수치로는 internet-facing clusters의 약 41%가 Ingress NGINX에 의존했습니다.

은퇴 후 한 달이 지나도 이 숫자 전부가 이동하지는 않았습니다. 여전히 상당한 조직이 EOL 상태의 컨트롤러를 돌리고 있고, 매니지드 서비스 사용자에게는 별도 연장 지원이 제공됐습니다. Azure AKS Application Routing과 일부 GKE 구성은 2026년 11월까지 critical 패치를 받습니다. Microsoft는 AKS의 Gateway API 공식 지원을 3월 18일 preview로 공개했습니다.

3. 한국은 이미 움직이고 있었다

한국 생태계의 움직임을 공식 출처로 정리하면 다음과 같습니다.

  • 토스 : 2023년 공개한 기술 블로그 "토스는 Gateway 이렇게 씁니다"에서 Istio Ingress/Egress Gateway와 Envoy 필터 위에 자체 Gateway 애플리케이션을 올린 구조를 공개했습니다. Kotlin Coroutine 기반 필터, mTLS, 자체 구현한 Passport 토큰으로 세션 전파를 처리합니다. 은퇴 훨씬 이전에 Istio/Envoy 기반으로 이동한 사례입니다.
  • 디비디랩(유저스푼) : 2024년 medium 공식 계정에 “쿠버네티스 API 게이트웨이에 JWT 검증 추가하기 (w/ Envoy Gateway)” 글을 공개했습니다. 초기에는 Istio를 Gateway API 컨트롤러로 검토했으나, 서비스 메시까지는 필요 없다고 판단해 Envoy Gateway로 이동한 의사결정 과정이 상세히 기록돼 있습니다. 한국 중규모 스타트업이 2024년 시점에 이미 Gateway API 기반 선택을 문서화한 사례입니다.
  • 한국어 엔지니어 커뮤니티 : 은퇴 시점 전후로 빠르게 대응 중입니다. youngju.dev(Chaos and Order)는 2026년 3월 1일부터 4일 사이 3편의 한국어 실전 가이드를 연속 공개했습니다. “쿠버네티스 네트워킹의 종말과 부활”, “Gateway API 실전 마이그레이션”, "Envoy Gateway 트래픽 관리 실전"이 그것입니다. 한국 엔지니어들이 영문 공식 문서를 기다리지 않고 직접 한국어 실전 자료를 만들고 있다는 신호입니다.

한편 확인되지 않은 영역도 있습니다. 네이버 클라우드 플랫폼의 NKS는 2024년 기준으로 여전히 ingress-nginx 수동 설치를 권장하는 문서를 유지하고 있습니다. 2026년 3월 은퇴 이후 NKS의 공식 대응 로드맵이나 Gateway API 지원 발표는 공개 채널에서 확인되지 않았습니다. 국내 매니지드 Kubernetes를 쓰는 조직이라면 각 벤더에 공식 EOL 대응 계획을 직접 문의할 필요가 있다고 생각됩니다.

4. 실제 선택 지형도는 이렇게 흘러가고 있다

  • Gateway API 구현체 중심 : Istio는 Gateway API adoption 기준 1위입니다. VMware VCF/VKS는 Istio를 기본 추가 기능으로 제공합니다. Envoy Gateway는 CNCF 자체가 선택한 옵션입니다. kgateway는 2.0 GA로 올라오며 Trust Bank, ParkMobile 같은 레퍼런스를 확보했고, Rust 기반 agentgateway 데이터 플레인을 함께 묶어 AI 워크로드 대응을 전면에 세웠습니다. Cilium Gateway는 이미 Cilium CNI를 쓰는 조직에 shared gateway 패턴으로 자연스럽게 들어갑니다.
  • NGINX 계열 유지: F5/Nginx Inc의 상용 NGINX Ingress Controller는 계속 유지보수됩니다. NGINX Gateway Fabric 2.5.0은 F5의 Gateway API 구현체로 Ingress NGINX 사용자에게 가장 친숙한 마이그레이션 경로를 제공합니다.
  • 기타 : Kong Gateway, Traefik, HAProxy, Contour 등 기존 대안도 모두 Gateway API를 지원합니다. Calico는 Ingress Gateway를 새로 내놓았습니다.

5. 이미 AI Gateway는 시작됐다

Gateway가 단순 트래픽 프록시에서 AI 워크로드 제어 플레인으로 이동하는 중입니다. KubeCon EU 2026에서 네 개의 프로젝트가 이 방향의 구체적 형태를 보여줬습니다.

Agentgateway는 Rust로 작성된 데이터 플레인으로 LLM 트래픽, MCP 연결, agent-to-agent 통신을 프록시합니다. Cedar와 CEL 정책 엔진으로 세분화된 접근 제어를 제공합니다. kagent는 Solo.io가 CNCF Sandbox에 기부한 프로젝트로, agent를 Kubernetes CRD로 정의합니다. kagenti는 IBM이 SPIFFE/SPIRE 기반으로 agent에 암호학적 identity를 부여합니다. Kuadrant는 정책 레이어를 얹으며 MCP 서버 aggregation을 포함합니다.

Envoy AI Gateway는 token 단위 rate limiting과 provider failover를 제공합니다. 주 추론 제공자가 포화되면 보조로 트래픽이 자동 이동합니다. LLM 워크로드에서 요청당 토큰 소비량이 달라지기 때문에 요청 수 기반 rate limiting보다 토큰 기반 rate limiting이 더 정확합니다.

AI Gateway Working Group이 2026년 3월 9일 공식 신설됐고, Gateway API v1.5는 inference 관련 확장을 일부 stable로 올렸습니다. 2025년 6월 Gateway API Inference Extension이 공개된 이후 model-aware routing, token-based rate limiting, inference request queuing이 spec 안으로 들어오고 있습니다.

6. 현장에서 마주치는 함정

지난 한 달 마이그레이션 사례에서 반복 보고된 주의점이 있습니다.

Istio 1.28/1.29는 Gateway API CRD v1.5.x와 호환성 문제가 있습니다(istio/istio#59443). istiod가 crash 합니다. 프로덕션에서는 CRD 버전을 반드시 고정해야 합니다. Gateway API v1.4.x로 핀하면 현재까지 안정적입니다.

Ingress NGINX의 annotation 100여 개 중 ingress2gateway 1.0이 자동 변환하는 것은 30여 개입니다. 나머지는 수동 작업입니다. configuration-snippet 같은 raw NGINX 설정 주입 annotation은 Gateway API에 매핑되지 않습니다. 이건 보안 리스크 관점에서 의도된 설계입니다.

Go 코드에서 프로그래매틱하게 Ingress 리소스를 만드는 플랫폼 팀은 ingress2gateway가 해결해주지 않습니다. Konveyor/KAI 같은 AI 기반 도구가 Go 코드 레벨 변환을 돕기 시작했지만 아직 초기 단계입니다.

LoadBalancer IP가 바뀝니다. 마이그레이션 후 DNS A 레코드 갱신이 필요합니다. 사전에 TTL을 낮춰두지 않으면 cutover 중 예상치 못한 지연이 발생합니다.

7. 오늘의 체크리스트

지금 확인할 수 있는 다섯 가지 체크리스트를 마지막으로 공유드립니다. 도움이 되시기를 바랍니다!

  1. 현재 상태 점검 : kubectl get pods --all-namespaces --selector ``app.kubernetes.io/name=ingress-nginx로 클러스터 전체 Ingress NGINX 배포를 확인하고, 이미 마이그레이션된 클러스터와 그렇지 않은 클러스터를 목록화
  2. 세 가지 구분 확인 : 조직이 쓰는 것이 Ingress API 자체인지, 은퇴한 커뮤니티 controller인지, F5 NGINX 상용 controller인지 분리해서 문서화 (이 구분이 흐려지면 의사결정 자체가 잘못 그려집니다!)
  3. 매니지드 서비스 연장 지원 일정 확인: Azure AKS Application Routing이나 특정 GKE 구성은 2026년 11월까지 critical 패치 제공. 국내 매니지드 Kubernetes(NKS 등)를 쓴다면 각 벤더에 공식 EOL 일정을 직접 문의
  4. 선택지 명시 : 호환성 우선 (F5 NGINX Gateway Fabric, NGINX Ingress Controller 상용) vs Gateway API 전환 (Istio, Envoy Gateway, kgateway, Cilium Gateway). 각 선택의 이유와 trade-off를 조직 내 문서로 작성
  5. AI 워크로드 경로 설정: 현재 또는 12개월 내에 LLM inference, MCP 기반 agent 서비스, multi-provider LLM routing 중 하나라도 들어올 가능성이 있다면, 선택하는 Gateway API 구현체가 AI Gateway WG 논의 방향(agentgateway, Envoy AI Gateway, Kuadrant, kagent 등)과 어떻게 정렬되는지 점검. 2027-2028년 재마이그레이션을 피하는 결정

참고한 자료

3 Likes