Ingress API 자체의 대안인 Gateway API의 개념부터, 후보로 선정한 7개 구현체에 대한 설명, 실제 PoC 테스트 결과, 그리고 앞으로 준비해야 할 사항까지 차례대로 다뤄보겠습니다. 현재 시점에서 어떤 구현체를 선택하는 것이 적절한지, 또 어떤 기술을 기다리는 것이 더 좋을지까지 함께 살펴보겠습니다.

쿠버네티스 게이트웨이의 등장

Gateway API는 쿠버네티스에서 서비스 네트워킹을 정의하는 차세대 표준 API입니다. 기존 Ingress API의 한계를 극복하기 위해 Kubernetes SIG Network에서 개발했으며, 더 높은 표현력과 확장성, 그리고 역할 기반 설계를 제공하는 것이 특징입니다.

좀 더 쉽게 이해하기 위해서는, 먼저 Gateway API와 Ingress API의 관계부터 명확히 하는 것이 좋습니다. 이 관계를 이해하면 Gateway API가 어떤 문제를 해결하려는지, 어떤 방향으로 설계됐는지 더 잘 이해할 수 있습니다.

Gateway API와 Ingress API의 관계

Gateway API는 Ingress API를 ‘대체’하는 것이 아닌 ‘차세대 표준’으로 설계됐습니다. SIG Network는 공식 FAQ에서 이에 대해 다음과 같이 설명하고 있습니다.

Q. “Gateway API가 Ingress API를 대체하게 되나요?”
“Will Gateway API replace the Ingress API?”

A. 아닙니다. Ingress API는 Kubernetes 1.19부터 GA 상태이며, 이 API를 Deprecated할 계획은 없습니다. 또한 대부분의 Ingress 컨트롤러가 앞으로도 이를 지속적으로 지원할 것으로 예상하고 있습니다.
No. The Ingress API is GA since Kubernetes 1.19. There are no plans to deprecate this API and we expect most Ingress controllers to support it indefinitely.

즉, 두 API는 무기한 공존을 전제로 했습니다.

여기서 이 글의 주제와 관련해 혼동하기 쉬운 포인트가 하나 있습니다.

Deprecated 아닌 것: Ingress API = API 자체
은퇴(Retired) 예정인 것: Ingress NGINX Controller = 구현체

이번에 은퇴하는 대상은 Ingress API가 아니라 ingress-nginx 컨트롤러입니다. 실제 2025년 기준으로도 Ingress API(networking.k8s.io/v1)는 GA 상태를 유지하고 있으며, Deprecated에 대한 계획이 없습니다. 다른 Ingress 컨트롤러나 클라우드 서비스 제공자(CSP, Cloud Service Provider)가 제공하는 네이티브 솔루션을 사용한다면, Ingress API 자체는 계속 사용할 수 있다는 뜻입니다. 예를 들어 AWS ALB Controller, Azure AGIC, GCP GCE Ingress 등이 이에 해당합니다.

Ingress NGINX의 은퇴 배경은?

인그레스 NGINX는 전 세계 쿠버네티스 클러스터의 40% 이상에서 사용되던 핵심 프로젝트였습니다. 그러나 실제 유지보수는 매우 소수의 메인테이너가 본업 외 개인 시간을 쪼개 진행하는 구조였습니다. 이로 인해 CVE 대응과 버그 수정에 지속적인 부담이 쌓여 갔고, 커뮤니티 차원에서 기여자를 모집했음에도 충분한 인력을 확보하지 못했습니다. 이는 오픈소스 생태계의 지속 가능성에 대해 다시 한 번 고민하게 만드는 계기로 남을 것 같습니다.

그렇다면 왜 마이그레이션이 필요한가?

다만 Gateway API에는 기존 Ingress 방식과 비교했을 때 여러 장점이 존재합니다. 그렇기 때문에 기존 환경에서 전환을 고려하거나 신규로 도입하는 환경이라면 Gateway API를 우선 고려해 보는 것이 좋습니다.

예시로 차이점 이해하기

여러 차이점이 있지만, 그중에서도 가장 크게 체감되는 것은 역할이 분리된 구조입니다. 예를 하나 들어보겠습니다.

기존 Ingress API를 사용하는 ingress.yaml 코드를 Gateway API 형태로 변경하면, 다음과 같습니다.

Ingress API (단일 리소스)

Gateway API (역할별 분리)

코드 내용을 보면 알 수 있듯 기존의 ingress.yaml과 비교했을 때 크게 차이가 없는데, 역할이 분리되면, 인프라 관리자, 클러스터 운영자, 애플리케이션 개발자가 각자의 책임 범위 내에서 리소스를 독립적으로 관리할 수 있게 됩니다.

이 구조는 기존에 StorageClass에서 사용하던, 미리 정의된 리소스를 불러와 사용하는 개념이 포함돼 있습니다. 이를 더 보기 좋게 다이어그램으로 그리면 이렇습니다.

이 과정에서 Ingress API는 클라우드 서비스 제공자가 직접 제공하는 솔루션을 제외하면 사실상 Ingress NGINX Controller를 사용하는 것이 표준에 가까웠습니다. 반면 Gateway API는 아직 발전 중인 단계에 있기 때문에, 현재 시점에서 어떤 구현체를 선택해야 할지 판단하기가 쉽지 않을 수 있습니다.

이러한 배경에서, 이 글에서는 대표적인 Gateway API 구현체들을 선정하고, 각각을 선택한 이유를 함께 살펴보도록 하겠습니다.

7개의 게이트웨이를 선정한 이유와 결과 요약

Gateway API는 표준 스펙이며, 여러 프로젝트와 벤더에서 컨트롤러를 구현해 제공하고 있습니다.

이에 따라 이 글에서는 대표적인 Gateway API 구현체 7개를 선정해 PoC를 진행했습니다. 선정 기준은 CNCF 생태계와의 연관성, 커뮤니티 활성도, 그리고 실제 프로덕션 환경과 유사한 조건에서 테스트한 뒤 충분히 검증됐는지를 중심으로 삼았습니다. 각 구현체별로 총 17개 테스트 시나리오를 실행해 기능 완성도를 평가했고, 그 결과를 바탕으로 장점과 단점을 정리했습니다.

1. NGINX Gateway Fabric

한 줄 평

검증된 NGINX의 안정성을 Gateway API로 계승
30년 웹 서버 역사가 보장하는 신뢰성

장점과 단점

NGINX Gateway Fabric의 가장 큰 장점은 결국 NGINX입니다. 수십 년간 웹 서버 시장에서 검증된 안정성과 성능, 그리고 전 세계 개발자들이 축적해 온 풍부한 문서와 대규모 커뮤니티가 그 배경입니다. 문제가 발생했을 때 Stack Overflow나 공식 문서에서 해결책을 찾기도 쉽습니다. 이미 NGINX를 사용 중인 조직이라면, 기존 운영 경험을 그대로 활용할 수 있다는 점 역시 매력적인 요소입니다.

다만 Rate Limiting을 구현하려면 SnippetsFilter를 통해 로우 레벨의 NGINX 설정을 직접 주입해야 합니다. Envoy 기반 Gateway처럼 선언적인 CRD로 간단히 설정하는 방식은 현재 지원되지 않습니다. 이로 인해 동적 설정 변경의 유연성 역시 Envoy 기반 구현체와 비교하면 상대적으로 낮은 편입니다.

테스트에는 v2.2.1(2025-11-18 공개) 버전을 사용했는데, 17개 시나리오 중 Rate Limiting을 제외한 모든 테스트를 통과했습니다. NGINX 환경에서 Gateway API로 자연스러운 전환을 원하는 팀에 가장 적합한 선택지입니다.

2. Envoy Gateway

한 줄 평

Gateway API 표준 준수의 모범, Rate Limiting 네이티브 지원
CNCF 생태계와 함께 성장하는 차세대 표준

장점과 단점

Envoy Gateway의 가장 큰 강점은 선언적 CRD를 통한 Rate Limiting 네이티브 지원입니다. BackendTrafficPolicy CRD 하나로 초당·분당 요청 제한을 직관적으로 설정할 수 있는 것은 7개 구현체 중 Envoy Gateway가 유일했습니다. xDS 프로토콜 기반의 동적 설정, 풍부한 필터 체인, 그리고 뛰어난 관측성 역시 주요 장점입니다.

다만 NGINX에 비해 상대적으로 역사가 짧아 커뮤니티가 아직 성장 중입니다. 또한 Envoy 자체의 복잡성으로 인해 학습 곡선이 존재합니다. 처음 접하는 팀이라면 초기 러닝 커브를 어느 정도 감안해야 합니다.

테스트에는 v1.6.0(2025-11-11 공개) 버전을 사용했으며, 17개 시나리오 중 Backend TLS(사이드카 필요)를 제외한 16개 테스트를 모두 통과했습니다. 새로운 프로젝트에서 Gateway API를 도입한다면, 가장 먼저 고려해볼 만한 선택지입니다.

3. Istio Gateway

한 줄 평

서비스 메시 환경의 최적 선택
mTLS 자동화와 세밀한 트래픽 관리의 끝판왕

장점과 단점

Istio Gateway의 가장 큰 장점은 서비스 메시와의 완벽한 통합입니다. mTLS가 자동으로 적용되며, 세밀한 트래픽 관리 기능을 별도 설정 없이 활용할 수 있습니다. 2024년 CNCF Graduated 프로젝트로 승격되면서, 안정성과 신뢰성 역시 공식적으로 검증됐습니다. 이미 Istio를 사용 중이거나 서비스 메시 도입을 계획하고 있다면 가장 좋은 선택지입니다.

다만 Rate Limiting을 구현하려면 EnvoyFilter를 통한 로우 레벨 설정이 필요해, 복잡도가 상당히 높은 편입니다. 또한 서비스 메시 전체 스택을 함께 도입해야 하므로, 오버엔지니어링이 될 수 있습니다.

테스트에는 v1.28.0(2025-11-05 공개) 버전을 사용했으며, Envoy Gateway와 동일하게 16개 테스트를 통과했습니다. 서비스 메시가 필요한 환경이라면 Istio Gateway는 충분히 좋은 선택지입니다.

4. Cilium Gateway

한 줄 평

eBPF 기반 커널 레벨 고성능 처리
CNI와 Gateway의 완벽한 통합, 단 Cilium 필수

장점과 단점

Cilium Gateway의 장점은 eBPF 기반의 커널 레벨 패킷 처리입니다. 유저스페이스를 거치지 않고 커널에서 직접 처리하기 때문에, 뛰어난 성능을 기대할 수 있습니다. 또한 CNI와 Gateway가 통합돼 있어 별도로 컴포넌트를 관리할 필요가 없고, Cilium의 네트워크 정책과도 자연스럽게 연동됩니다.

다만 HTTP Rate Limiting은 현재 미지원 상태로, Feature Request 단계에 머물러 있습니다. 이 때문에 API 트래픽 제어가 필수인 환경에서는 적합하지 않습니다. 무엇보다 가장 큰 제약은 CNI로 Cilium을 사용하는 환경에서만 동작한다는 것으로, Calico, Flannel 등 다른 CNI를 사용하는 클러스터에서는 적용할 수 없습니다.

테스트에는 v1.18.4(2025-11-12 공개) 버전을 사용했으며, Rate Limiting과 Session Affinity를 제외한 13개 테스트를 통과했습니다. 이미 Cilium CNI를 사용 중이고, eBPF 기반의 고성능 처리가 필요한 환경일 때 최적의 선택지입니다.

5. Kong Gateway

한 줄 평

엔터프라이즈 API Gateway의 대명사
풍부한 플러그인, 하지만 Gateway API 지원은 성숙 중

장점과 단점

Kong Gateway는 엔터프라이즈 API Gateway 시장의 선두 주자입니다. 풍부한 플러그인 생태계를 기반으로 API 관리, 인증·인가, 트래픽 제어 기능을 내장합니다. Ingress Controller로서도 오랜 기간 검증된 솔루션입니다.

다만 이번 PoC에서는 Gateway API 호환성 이슈가 확인됐습니다. HTTPRoute가 Kong 내부로 동기화되지 않았고, 'no Route matched with those values' 오류가 발생하며 기본 라우팅부터 실패했습니다. 해당 문제는 Kong Ingress Controller v3.5.3과 Kong Gateway v3.9 조합에서 발생했으며, 추가 구성 검토가 필요한 상태입니다.

테스트에는 v3.9(KIC v3.5, 2025-07-17 공개) 버전을 사용했습니다. Kong 자체는 좋은 솔루션이지만, Gateway API 지원은 아직 발전 중인 단계로 보입니다. 엔터프라이즈급 API 관리 기능이 필수라면 Kong을 고려할 만하지만, 순수 Gateway API 호환성을 우선한다면 다른 구현체를 검토하세요.

6. Traefik Gateway

한 줄 평

자동 서비스 디스커버리와 Let's Encrypt 통합의 강자
설정 간소화의 대가, 하지만 Gateway API는 아직

장점과 단점

Traefik Gateway는 자동 서비스 디스커버리와 Let’s Encrypt 통합으로 유명한 클라우드 네이티브 프록시입니다. 설정을 간소화한 구조와 다양한 백엔드 지원이 특징이며, Ingress Controller로서는 이미 널리 쓰이고 있습니다. 또한 MIT 라이선스로 제공돼, 라이선스 측면에서도 자유롭습니다.

다만 Kong과 마찬가지로, 이번 PoC에서는 Gateway API 호환성 이슈가 확인됐습니다. Gateway가 Ready 상태에 도달하지 못하는 문제를 비롯해, EntryPoints 포트 불일치, BackendTLSPolicy CRD 버전 불일치 등 문제가 발생했습니다. 이는 Traefik 고유의 설정 방식과 Gateway API 표준 사이에 아직 간극이 존재함을 보여줍니다.

테스트에는 v3.6.2(Helm Chart v37.4.0, 2025-11-18 공개) 버전을 사용했습니다. Traefik IngressRoute(CRD) 방식으로는 검증된 솔루션이지만, Gateway API 지원에는 구성 검토가 필요한 단계로 보입니다.

7. kgateway

한 줄 평

CNCF Sandbox 정식 승인, Envoy 기반의 새로운 선택지
Solo.io의 7년 Gloo Edge 기술력 기반

장점과 단점

kgateway는 2025년 3월 CNCF Sandbox에 정식 승인된 신흥 프로젝트입니다. Solo.io가 7년간 개발해 온 Gloo Edge 기술을 기반으로 하고 있으며, GraphQL 지원과 Envoy 필터 확장성이 주요 특징입니다. CNCF 생태계 안에서 성장 가능성이 기대되는 프로젝트로 평가받고 있습니다.

다만 ARM64 아키텍처를 지원하지 않아, 이번 PoC 환경인 Apple Silicon 기반에서는 테스트를 수행하지 못했습니다. 현재는 AMD64 전용으로 제공되며, Apple Silicon Mac이나 AWS Graviton 환경에서는 사용할 수 없습니다. 또한 CNCF Sandbox 단계에 있는 만큼, 아직은 성숙도에 대한 검증이 더 필요한 프로젝트이기도 합니다.

테스트 대상 버전은 v2.1.1(2025-11-18 공개)입니다. AMD64 환경에서 새로운 구현체를 찾고 있다면, 주목할 만합니다.

이렇게 선별한 7개 Gateway API 구현체에 대한 테스트 결과를 요약해 보았습니다.

곧이어 17개 테스트를 통해, 각 기능에 대해 검증한 결과를 살펴보겠습니다.

기술 검증(PoC, Proof of Concept) 시나리오 17개

이번 기술 검증을 위해 총 17개의 테스트 시나리오를 설계해, 각 Gateway 구현체의 기능 완성도를 평가했습니다.

1. 라우팅 테스트(3개)

Gateway의 가장 기본적인 역할은 들어오는 트래픽을 적절한 백엔드 서비스로 전달하는 것입니다. 호스트 기반 라우팅은 도메인별로 서비스를 분리할 때 쓰이며, 경로 기반 라우팅은 하나의 도메인에서 여러 마이크로서비스를 운영할 때 활용됩니다. 또한 헤더 기반 라우팅은 A/B 테스트나 특정 클라이언트 버전에 따른 분기 처리에 주로 사용됩니다. 이 세 가지는 모든 Gateway 구현체가 반드시 지원해야 하는 핵심 기능입니다.

2. TLS/보안 테스트 (3개)

프로덕션 환경에서 보안은 선택이 아닌 필수입니다. TLS 종료는 Gateway에서 HTTPS 암호화를 처리해 백엔드 서비스의 부담을 줄여주며, HTTPS 리다이렉트는 HTTP 접속을 자동으로 HTTPS로 전환해 보안 정책을 강제합니다. Backend TLS(mTLS)는 Gateway와 백엔드 간 내부 통신까지 암호화하는 Zero Trust 아키텍처의 핵심 요소로, 특히 금융이나 헬스케어처럼 규제가 강한 산업에서 중요합니다.

3. 트래픽 관리 테스트 (4개)

안정적인 서비스 운영을 위해서는 트래픽을 세밀하게 제어할 수 있어야 합니다. Canary 배포는 새로운 버전을 일부 트래픽에만 적용해 위험을 최소화하는 방식이며, Rate Limiting은 과도한 요청으로부터 서비스를 보호하는 역할을 합니다. Timeout과 Retry 정책은 일시적인 장애 상황에서도 사용자 경험을 유지하는 데 도움을 주고, Session Affinity는 세션 상태를 서버 메모리에 저장하는 레거시 애플리케이션이나 로그인 상태 유지가 필요한 환경에서 필수적인 기능입니다.

4. 요청/응답 수정 테스트 (2개)

백엔드 코드를 수정하지 않고도 라우팅 동작을 조정할 수 있다면 운영 유연성은 크게 높아집니다. URL Rewrite는 API 버전 마이그레이션이나 레거시 엔드포인트 통합 과정에서 유용하며, Header Modifier는 인증 토큰 주입, CORS 헤더 추가, 디버깅용 추적 ID 삽입 등 다양한 상황에서 활용됩니다. 특히 여러 팀이 협업하는 환경에서는 서비스의 독립성을 유지하면서도 통합을 지원하는 핵심 기능입니다.

5. 고급 기능 테스트 (5개)

대규모 클러스터를 운영하다 보면 기본 기능만으로는 부족한 상황이 발생합니다. Cross-namespace 라우팅은 멀티 테넌트 환경에서 네임스페이스 간 통신을 가능하게 하며, gRPC 라우팅은 마이크로서비스 간 고성능 통신에 필수입니다. Health Check와 Failover는 장애 상황에서도 자동 복구를 보장하고, Load Test는 실제 트래픽을 받기 전에 Gateway의 성능 한계를 파악하는 데 중요한 역할을 합니다.

이렇게 라우팅부터 TLS·보안, 트래픽 관리, 요청·응답 수정, 그리고 고급 기능까지 총 17개의 테스트 항목을 살펴봤습니다. 이제 각 Gateway 구현체가 이 테스트들에서 어떤 결과를 보여줬는지, 실제 PoC 결과를 기준으로 하나씩 확인해보겠습니다.

기술 검증(PoC) 결과

7개 Gateway 구현체에 대해 17개 테스트 항목을 100회씩 반복 실행하며, 기능의 일관성과 안정성을 함께 검증했습니다. 먼저 테스트가 수행된 환경을 살펴본 다음, 각 구현체별 결과를 차례대로 확인해 보겠습니다.

1. 테스트 환경

모든 테스트는 애플 실리콘인 M 시리즈 기반 로컬 쿠버네티스 클러스터에서 진행했습니다.

클러스터 개요

노드 구성

그림으로 테스트 환경을 표현하면 다음과 같습니다.

다만 이번 PoC 환경에는 아래 특이사항이 존재합니다.

ARM64 아키텍처: 애플칩인 M 시리즈 기반 환경으로, AMD64 전용 이미지를 사용하는 kgateway는 테스트가 불가능했습니다. 따라서 아래 결과 항목에서도 모두 제외됩니다.
멀티 Gateway 구성: 하나의 클러스터에서 7개의 서로 다른 Gateway 구현체를 서로 독립적으로 운영했습니다.
CNI 선택: Cilium Gateway 테스트를 위해 Cilium CNI를 사용했으며, 다른 CNI를 사용할 경우 Cilium Gateway는 테스트 대상에서 제외됩니다.

2. 기능 검증 표

이제 이러한 환경을 바탕으로 수행한 테스트의 전체 결과를 표로 정리해 살펴보겠습니다.

3. Rate Limiting 테스트 상세 결과

검증 표를 보면 특히 rate-limiting 항목에서 구현체별 결과가 서로 다른 것을 확인할 수 있습니다. 이는 Gateway API 표준 스펙에 아직 Rate Limiting이 포함돼 있지 않아, 각 구현체가 이를 서로 다른 방식으로 지원하고 있기 때문입니다.

따라서 Rate Limiting 항목은 별도로 조금 더 상세히 살펴볼 필요가 있습니다.

표로 정리하고 보니 Envoy Gateway만이 선언적 CRD를 통한 네이티브 Rate Limiting을 지원합니다.

예외로 NGINX(SnippetsFilter)와 Istio(EnvoyFilter) 역시 CRD로 구성할 수 있지만, 로우 레벨 설정을 직접 주입하는 방식으로 복잡도가 높은 편입니다.

4. 종합 결론

모든 항목을 확인해 마지막으로 결론을 도출하도록 하겠습니다.

성공률은 SKIP을 제외한 PASS / (PASS + FAIL) 기준으로 계산

100회 반복 테스트 결과, NGINX, Envoy, Istio, Cilium 4개 Gateway는 100% 일관된 결과를 보여줬습니다. 반면 Kong과 Traefik은 Gateway API 호환성 이슈로 인해 대부분의 테스트에서 실패했습니다.

Kong Gateway의 오류는 “no Route matched with those values”로, HTTPRoute 리소스가 Kong 내부로 동기화되지 않아 기본 라우팅부터 정상적으로 동작하지 않았습니다. 한편 Traefik Gateway는 “404 page not found” 오류와 “Gateway not ready” 경고가 발생했습니다. EntryPoints 포트 불일치와 BackendTLSPolicy CRD 버전 불일치로 인해 Gateway가 Ready 상태에 도달하지 못한 모습입니다.

등급과 성공률까지 함께 반영해 PoC 결과를 그림으로 만들면 다음과 같습니다.

테스트 결과를 종합해 보면, NGINX, Envoy, Istio, Cilium 총 4개 Gateway는 프로덕션 환경에 적합합니다.

Kong과 Traefik은 Ingress Controller로서는 이미 검증된 솔루션이지만, Gateway API 도입 시에는 최신 버전 기준으로 추가적인 호환성 테스트를 권장합니다. kgateway는 ARM64 환경에서 테스트를 진행하지 못했지만, Gateway API Benchmarks 기준으로 트래픽 성능 테스트에서 최고 처리량(512 연결 기준 400K QPS)을 기록한 만큼, AMD64 환경이라면 충분히 검토해볼 만한 선택지입니다.

앞으로 준비해야 할 일

마지막으로, 실제 마이그레이션을 위해 어떤 준비가 필요한지 살펴보겠습니다. Ingress NGINX 은퇴 일정(2026년 3월)을 고려하여 시기별로 준비해야 할 사항을 정리했습니다.

1. 즉시 조치

먼저 현재 클러스터에서 Ingress NGINX가 어떻게 사용되고 있는지 정확히 파악해야 합니다. 특히 Annotation 사용 여부는 마이그레이션 복잡도를 가늠하는 지표입니다.

# 현재 Ingress NGINX 사용 현황 확인
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
kubectl get ingress -A -o yaml > ingress-backup.yaml

# Annotation 사용 현황 분석 (마이그레이션 복잡도 파악)
kubectl get ingress -A -o json | jq '.items[].metadata.annotations'

이와 함께 Gateway API에 대한 학습도 병행해야 합니다. 공식 문서를 숙지하고, GatewayClass, Gateway, HTTPRoute와 같은 핵심 리소스를 이해하며, 팀 내 교육 세션으로 지식을 공유하는 것도 좋습니다.

2. 단기 계획

이 시기에는 실제 PoC 환경을 구축해 Gateway API를 직접 다뤄보는 것이 핵심입니다. Gateway API CRD를 설치한 뒤, 앞선 검증 결과를 바탕으로 선택한 구현체를 배포해 봅니다.

# Gateway API CRD 설치
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/standard-install.yaml

# 선택한 구현체 설치 (예: Envoy Gateway)
helm install envoy-gateway oci://docker.io/envoyproxy/gateway-helm \
  --version v1.3.0 \
  -n envoy-gateway-system --create-namespace

이 단계에서는 운영 환경에 바로 적용하기보다는, Dev나 Stage 환경에서 Ingress와 Gateway를 병행 운영하며 차이를 비교하는 것이 좋습니다. 동일한 서비스를 두 방식으로 동시에 테스트해 보고, 트래픽을 점진적으로 전환하는 시나리오가 실제로 문제없이 동작하는지 확인해 볼 필요가 있습니다.

3. 중기 계획

여기서는 중요도가 낮은 서비스부터 Gateway API로 전환하며 경험을 쌓는 것이 바람직합니다. 전환 과정에서는 모니터링과 알람 체계를 미리 구축하고, 롤백 절차를 문서로 정리해 두는 것이 중요합니다. 이러한 준비가 갖춰진 상태에서 점진적으로 핵심 서비스까지 전환해 나가야 합니다.

따라서 이 시기에는 문서화와 표준화 작업도 함께 진행하는 것이 좋습니다. 팀 내부에서 Gateway API 사용 가이드라인을 정리하고, HTTPRoute 템플릿을 표준화해 재사용성을 높일 수 있습니다. CI/CD 파이프라인 역시 업데이트하는 것이 필요합니다.

4. 구현체 선택 가이드

마지막으로, 모든 환경에 맞는 정답은 없습니다. 팀의 기술 스택, 운영 경험, 요구사항에 따라 적합한 구현체가 달라집니다.

다시 한 번 강조하면, Kong과 Traefik은 Ingress Controller로서는 이미 검증된 솔루션이지만, 이번 테스트 기준(2025년 12월)에서는 Gateway API 호환성 이슈가 확인된 만큼 실제 도입 전에는 반드시 최신 버전을 기준으로 추가 검증을 진행하는 것이 바람직합니다.

마치며

지금까지 Gateway API의 개념부터 구현체 비교, 테스트 결과, 그리고 마이그레이션 준비 사항까지 살펴봤습니다.

Ingress NGINX의 은퇴는 쿠버네티스 생태계에서 중요한 전환점이라 할 수 있습니다. 은퇴 시점인 2026년 3월까지는 아직 준비 시간이 남은 지금, Gateway API는 이미 프로덕션 환경에서 사용할 만큼 성숙해 있습니다.

지금 당장 실행할 핵심 권장 사항 4단계입니다.

현재 Ingress 사용 현황을 파악하세요.
PoC 환경에서 2~3개 구현체를 직접 테스트해보세요.
팀 상황에 맞는 구현체를 선택하세요.
점진적 마이그레이션으로 리스크를 최소화하세요.

Gateway API는 Ingress를 단순히 대체하는 기술이 아닙니다. 더 세밀한 트래픽 관리와 확장성을 제공합니다. 이번 테스트에서 정리한 내용이 여러분이 마이그레이션 계획을 세우는 데 도움이 되기를 바랍니다.

이 글은 실제 PoC 테스트 결과를 바탕으로 작성되었습니다. 테스트 환경과 스크립트는 GitHub 저장소에서 확인할 수 있습니다.

작가

조훈(CNCF 앰버서더)

메가존에서 쿠버네티스와 컨테이너 인프라 Tech Evangelist, CoE(Center of Excellence) 역할을 맡고 있다. 클라우드 네이티브 컴퓨팅 재단(CNCF)의 글로벌 앰버서더, ‘IT 인프라 엔지니어 그룹’의 운영진, 오픈소스 컨트리뷰터로도 활동하고 있다. 인프런/유데미에서 앤서블 및 쿠버네티스에 관한 강의를 하고, 『컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커』, 『우아하게 앤서블』, 『시스템/네트워크 관리자를 위한 파이썬 실무 프로그래밍』을 집필하였으며, 요즘IT와 같은 온라인 플랫폼에 글을 기고한다.

심근우

LG유플러스 CTO부문에서 대고객 비즈니스 시스템의 DevOps를 담당하는 UcubeDAX팀의 팀장으로 일하고 있다. 퍼블릭 클라우드와 프라이빗 클라우드에 걸친 쿠버네티스 클러스터를 안정적으로 운영하기 위해 노력하고 있으며, 특히 주니어 DevOps 엔지니어들의 육성에 큰 관심을 가지고 있다.

문성주

글로벌 소셜 플랫폼 기업에서 Site Reliability Engineer로 재직하며, 쿠버네티스 멀티 클러스터 관리와 데이터베이스 플랫폼 운영을 주도하고 있다. 또한 ISMS-P, GDPR, CCPA 등 글로벌 보안 규제에 부합하는 데이터 라이프사이클 파이프라인을 설계·운영한 실무 경험을 가지고 있으며, 쿠버네티스 오픈소스 프로젝트에도 기여하고 있다. 더불어 국내 주요 기업과 국가 기관의 클라우드 전환, 데이터 거버넌스 컨설팅, 보안 컴플라이언스 대응을 지원하고 있다.

이성민

미국 넷플릭스(Netflix) 사의 Data Platform Infrastructure 팀에서 사내 플랫폼 팀들과 데이터 사용자들을 어우르기 위한 가상화 및 도구들을 개발하는 일들을 하고 있다. 과거 컨테이너와 쿠버네티스에 큰 관심을 두고 ingress-nginx를 비롯한 오픈 소스에 참여했으며, 현재는 데이터 분야에 일하게 되면서 stateful 한 서비스들이 컨테이너화에서 겪는 어려움을 보다 근본적으로 해결하기 위한 많은 노력을 하고 있다.