쿠버네티스 Gateway API v1.4 재측정으로 본 7개 게이트웨이 선택 기준

쿠버네티스 Gateway API v1.4 재측정으로 본 7개 게이트웨이 선택 기준

2026년 3월, 쿠버네티스에서 널리 사용되던 Ingress NGINX의 지원이 종료되면서 Gateway API 이전은 더 이상 미룰 수 없는 과제가 됐다. 여기에 ingress-nginx의 설정 주입 방식에서 비롯된 IngressNightmare 취약점까지 드러나며, 다음 게이트웨이를 무엇으로 선택할지 다시 검증해야 할 필요성이 커졌다.

지난해에는 Gateway API 구현체 7종을 비교하며 Kong과 Traefik이 기본 테스트를 통과하지 못한다고 판단했다. 하지만 실제 이전 시점이 다가오면서 당시 결과를 다시 살펴보니, 제품 자체보다 측정 환경과 측정 방식에 문제가 있었을 가능성이 보였다.

그래서 동일한 7개 구현체를 Gateway API v1.4 기준으로 처음부터 다시 측정했다. 이번에는 Kong과 Traefik 모두 Core 테스트를 통과했고, 작년 결과는 제품의 근본적인 한계라기보다 측정 조건과 설계의 문제였다는 점을 확인했다.

왜 다시 측정하기로 했나

지난해 작성한 쿠버네티스 게이트웨이 기술 검증에서는 Ingress NGINX 지원 종료 이후 어떤 Gateway API 구현체가 적합한지 확인하기 위해 7개 구현체에 17개 테스트를 각각 100회씩 실행했다. 당시에는 통과율을 기준으로 등급을 매겼고, Kong과 Traefik은 가장 낮은 등급으로 기록됐다.

Kong은 라우트가 동기화되지 않아 no Route matched 오류가 발생했고, Traefik은 404 page not found와 Gateway not ready를 반환했다. 결과만 보면 두 구현체 모두 기본 라우팅조차 통과하지 못한 셈이었다.

하지만 Kong은 API 게이트웨이 시장에서 오래 검증된 제품이고, Traefik 역시 많은 팀이 프로덕션 환경에서 사용하고 있다. 그런 제품이 기본 라우팅을 통과하지 못했다면, 제품 결함 외에도 설치 방식이나 측정 절차의 문제를 함께 의심해야 했다. 운영 환경에서는 측정 결과 하나가 실제 도입 판단으로 이어질 수 있기 때문이다.

재측정을 결정한 핵심 이유
Ingress NGINX 지원 종료가 실제로 발생해 이전 판단이 필요해졌다.
IngressNightmare 같은 심각한 보안 취약점으로 기존 구조의 위험성이 커졌다.
기존 통과율 기반 채점 방식에 기술적 한계가 있었다.

기존 채점 방식의 한계

다시 살펴보니 지난해의 통과율 기반 평가는 세 가지 구조적 문제를 가지고 있었다.

• 미지원 기능이 점수에 거의 반영되지 않았다.
  PASS와 FAIL만 계산하고 SKIP 항목을 제외하다 보니, 기능을 아예 지원하지 않는 구현체가 감점 대신 계산 대상에서 빠졌다.
• 필수 기능과 부가 기능을 같은 무게로 측정했다.
  반드시 지원해야 하는 host 라우팅과 표준에도 없는 rate limiting을 같은 가중치로 평가했다.
• 100%와 95%를 구분하지 못했다.
  A/F 중심의 등급 체계에서는 거의 모든 테스트를 통과한 구현체와 기본 기능부터 실패한 구현체가 같은 등급으로 묶일 수 있었다.

이번 재측정은 새 데이터를 더 모으는 작업이기 전에, 작년에 내렸던 결론을 내려놓는 일에서 시작했다. 기술 검증에서 중요한 것은 결과를 방어하는 것이 아니라, 결과가 나온 조건까지 함께 검증하는 일이다.

Gateway API 공식 적합성 모델로 다시 설계하다

이번에는 임의의 점수 체계를 만들지 않고 Gateway API의 공식 적합성 모델에 맞춰 측정 구조를 다시 설계했다. Gateway API는 기존 Ingress를 대체하기 위해 쿠버네티스 커뮤니티가 만든 차세대 트래픽 라우팅 표준이다.

Gateway API는 역할을 GatewayClass, Gateway, HTTPRoute로 나눠 인프라 담당자, 클러스터 운영자, 애플리케이션 개발자 사이의 책임을 분리한다. Ingress 시절에는 같은 설정이라도 구현체에 따라 동작이 달라지는 일이 많았지만, Gateway API는 이러한 파편화를 줄이기 위해 공식 적합성 테스트를 제공한다.

구분	의미	이번 평가 방식
Core	모든 구현체가 반드시 지원해야 하는 필수 기능	7개 항목을 모두 통과해야 적합한 상태로 판단
Extended	표준에 포함됐지만 선택적으로 지원하는 기능	감점이 아니라 지원 범위로 비교
구현체 고유 기능	rate limiting, 외부 인증 등 표준 밖 기능	등급에는 반영하지 않고 별도 매트릭스로 비교

결과적으로 이번 평가는 하나의 통과율이 아니라 세 가지 질문으로 나뉘었다. Core를 모두 통과했는가, Extended 기능을 얼마나 지원하는가, 구현체 고유 기능은 무엇을 제공하는가. 이전 A/F 등급보다 훨씬 많은 정보를 담을 수 있는 방식이다.

원인은 제품보다 측정 방법과 조건에 가까웠다

Gateway API v1.4 기준으로 7개 구현체를 라이브 클러스터에서 다시 측정한 결과, 지난해 통과하지 못했던 Kong과 Traefik 모두 Core 7개 항목을 통과했다. 또한 지난해 arm64 이미지 지원 문제로 제외했던 kgateway도 이번에는 측정 대상에 포함됐다.

결과가 달라진 이유는 하나가 아니었다. 가장 먼저 표준이 성숙했다. 지난해 측정은 Gateway API v1.2 기준이었고, 이번 측정은 v1.4 기준이었다. 그 사이 실험 단계였거나 구현체마다 다르게 처리되던 기능들이 공식 표준으로 정리됐다.

설치 방식도 달라졌다. 지난해 Kong은 오래된 KIC(Unmanaged) 방식으로 설치했지만, 이번에는 Gateway API 운영 방식에 맞는 KGO Managed 구성을 사용했다. 같은 제품이라도 현재 권장되는 설치 경로를 따르자 결과가 달라졌다.

측정 방식의 변화도 결정적이었다. Kong은 설정을 한 덩어리로 묶어 동기화하는 특성이 있어, 지원하지 않는 기능이 하나라도 포함되면 전체 적용이 거부될 수 있다. 지난해의 no Route matched 오류는 이 영향으로 기본 라우팅까지 함께 실패한 사례였다. 이번에는 기능별로 라우트를 분리해 적용했고, 지원하지 않는 기능만 제외한 상태에서 Core 기능은 정상 동작했다.

Traefik은 Gateway 리스너가 바라보는 포트와 내부 entrypoint 포트가 맞지 않아 Ready 상태로 올라오지 못했다. 포트 구성을 맞추자 Gateway not ready와 404 오류가 해소됐다.

이번 재측정의 핵심 교훈
점수가 낮게 나오면 제품부터 의심하기 쉽다.
하지만 기술 검증에서는 제품만큼 측정 조건과 테스트 설계도 함께 의심해야 한다.
특히 공개된 결과가 누군가의 도입 판단에 쓰인다면 더 엄격해야 한다.

측정하며 확인한 네 가지 문제

1. 공식 적합성 인증이 기능 수준의 동일함을 뜻하지는 않는다

Gateway API의 공식 권고는 conformant 구현체를 선택하라는 것이다. 하지만 실제 측정 결과, 공식 인증을 받은 7개 구현체도 Extended 기능 지원 범위는 6개에서 13개까지 차이가 컸다.

Envoy Gateway와 Istio는 Extended 13개 기능을 모두 지원했고, Cilium과 kgateway는 12개, NGINX Gateway Fabric은 11개, Traefik은 10개, Kong은 6개를 지원했다. conformant 인증은 합격선이지, 모든 구현체가 같은 수준이라는 보증은 아니다.

2. 변환된다는 것과 동작한다는 것은 다르다

ingress-nginx 설정을 Gateway API로 변환하는 ingress2gateway는 30개가 넘는 어노테이션을 자동 변환할 수 있다. 그러나 변환이 성공했다고 해서 실제 트래픽에서 동작한다는 뜻은 아니었다.

예를 들어 CORS 관련 어노테이션은 변환 결과가 깔끔했지만, 실측에서는 일부 구현체만 테스트를 통과했다. 반면 x-forwarded-prefix처럼 헤더를 추가하는 어노테이션은 변환 시 경고 없이 사라졌다. 그래서 이번 비교에서는 변환 여부와 실제 동작 여부를 분리했다.

3. TLS 연결과 인증서 검증은 다르다

backend-tls 테스트를 처음 구성했을 때는 TLS 연결이 맺어지고 응답이 오는지만 확인하고 있었다. 하지만 이것만으로는 잘못된 인증서를 거부하는지 알 수 없다.

이후 의도적으로 잘못된 CA 인증서를 적용해 다시 테스트했고, 통과한 구현체들이 인증서 검증을 제대로 강제하는지 확인했다. 이 단계를 생략했다면 실제로는 보안 검증이 되지 않는데도 보안 기능이 통과했다는 잘못된 결론을 낼 수 있었다.

4. 표준 외부 인증 필터는 아직 운영 전환 기준으로 보기 어렵다

ingress-nginx에서 auth-url을 사용하던 환경이라면 외부 인증 이전 가능성이 가장 궁금할 것이다. Gateway API에는 외부 인증을 위한 표준 필터가 실험 단계로 포함돼 있지만, 이번 측정에서는 이 표준 필터를 완전하게 강제하는 구현체를 확인하지 못했다.

일부 구현체는 필터를 거부하거나 오류를 냈고, 일부 구현체는 표준 필터 자체를 구현하지 않아 인증 절차 없이 트래픽이 그대로 통과했다. 실제 사용 시 외부 인증은 아직 표준 필터만 믿기보다 각 구현체의 고유 기능을 함께 검토해야 한다.

7개 구현체별 재측정 결과

구현체	한 줄 평가	Core	Extended	특징
NGINX Gateway Fabric	검증된 NGINX의 안정성을 Gateway API로 계승	7/7	11/13	ingress-nginx에서 가장 매끄러운 이행 경로
Envoy Gateway	가장 넓은 기능 폭을 가진 CNCF 차세대 표준 후보	7/7	13/13	확장 기능과 관측성에서 강점
Istio Gateway	서비스 메시와 게이트웨이를 통합	7/7	13/13	자동 mTLS와 무중단 복구가 강점
Cilium Gateway	eBPF 데이터플레인과 CNI 통합	7/7	12/13	Cilium CNI 사용 환경에 적합
Kong Gateway	엔터프라이즈 API 게이트웨이와 플러그인 생태계	7/7	6/13	Core는 통과했지만 Extended 폭과 복구 시간은 확인 필요
Traefik Gateway	자동 서비스 디스커버리와 간편한 운영	7/7	10/13	포트 구성 교정 후 Core 통과
kgateway	Envoy 기반 게이트웨이, arm64 환경까지 합류	7/7	12/13	무중단 복구와 성능 측면에서 주목할 만함

NGINX Gateway Fabric

NGINX Gateway Fabric의 가장 큰 장점은 결국 NGINX라는 점이다. rate-limit, body-size, basic-auth를 네이티브로 지원하고 문서와 커뮤니티도 풍부하다. ingress-nginx에서 Gateway API로 이동하는 팀에게 부담이 가장 적은 선택지다. 다만 Extended는 11개로 최상위권은 아니며, active health check는 상용 버전인 Plus 전용이라는 점을 고려해야 한다.

Envoy Gateway

Envoy Gateway는 Extended 13개를 모두 지원하며 기능 폭에서 가장 앞선다. 실험 채널 기능도 빠르게 따라가고, rate-limit를 네이티브로 지원하며 관측성도 뛰어나다. 다만 Envoy 자체의 복잡성으로 인한 학습 곡선과 상대적으로 짧은 운영 역사는 감안해야 한다.

Istio Gateway

Istio Gateway는 서비스 메시와의 통합이 가장 큰 장점이다. Extended 13개를 모두 지원하고 mTLS가 자동 적용되며, 파드 교체 시에도 무중단으로 동작했다. 다만 전체 서비스 메시 스택을 함께 고려해야 하므로 단순 게이트웨이 도입보다 운영 복잡도가 높을 수 있다.

Cilium Gateway

Cilium Gateway는 eBPF 기반 데이터플레인을 활용하고 Cilium 네트워크 정책과 자연스럽게 연동된다. Core를 모두 통과했고 Extended도 12개를 지원했다. 다만 Cilium CNI가 필수이며, rate-limit와 body-size는 표준 경로에서 지원하지 않는다.

Kong Gateway

Kong Gateway는 엔터프라이즈 API 게이트웨이 시장에서 강력한 플러그인 생태계와 API 관리 기능을 갖춘 제품이다. 지난해와 달리 이번에는 Core 7개를 모두 통과했다. 다만 Extended는 6개로 가장 좁고, 복구 시간도 약 34초로 가장 느렸다. 설정을 일괄 적용하는 구조가 테스트 설계에 영향을 줄 수 있다는 점도 유의해야 한다.

Traefik Gateway

Traefik Gateway는 자동 서비스 디스커버리와 대시보드로 유명한 클라우드 네이티브 프록시다. 지난해에는 포트 구성 문제로 Core 테스트를 통과하지 못했지만, 이번에는 리스너 포트를 교정한 뒤 Core 7개를 모두 통과했다. 간편한 운영을 중시하는 팀에게 적합하다.

kgateway

kgateway는 Envoy 기반 게이트웨이로 Extended 12개와 무중단 복구 결과를 보여줬다. 지난해에는 arm64 지원 문제로 측정에서 제외됐지만, 이번에는 Apple Silicon 기반 환경에서도 측정 대상에 포함됐다. 다만 외부 인증 표준 필터와 커뮤니티 성숙도는 계속 확인해야 한다.

그래서 어떤 구현체를 골라야 할까

이번 재측정 결과, 7개 구현체 모두 Core는 통과했다. 이제 선택 기준은 단순한 합격 여부가 아니라 확장 기능의 폭, 데이터플레인 구조, 운영 경험, 커뮤니티, 기존 환경과의 궁합으로 옮겨간다.

상황	우선 검토할 구현체	판단 이유
ingress-nginx에서 가장 부담 없이 이전	NGINX Gateway Fabric	기존 NGINX 운영 경험을 활용하기 쉽고 이행 경로가 자연스럽다.
Gateway API 기능 폭 최우선	Envoy Gateway, Istio Gateway	Extended 13개를 모두 지원해 표준 기능 범위가 가장 넓다.
서비스 메시와 함께 운영	Istio Gateway	mTLS와 메시 기능을 게이트웨이와 통합할 수 있다.
Cilium CNI를 이미 사용	Cilium Gateway	네트워크 정책과 eBPF 데이터플레인을 자연스럽게 활용할 수 있다.
API 관리와 플러그인 생태계 중요	Kong Gateway	엔터프라이즈 API 게이트웨이 기능이 강하다.
간편한 운영과 자동 디스커버리 중시	Traefik Gateway	운영 편의성과 대시보드 경험이 좋다.
Envoy 기반 고성능 게이트웨이 검토	kgateway	무중단 복구와 Envoy 기반 구조가 강점이다.

ingress-nginx에서 옮길 때 가장 막히는 것들

기능 지원 범위와 별개로, ingress-nginx에서 자주 쓰던 일부 기능은 Gateway API로 그대로 옮기기 어렵다. 마이그레이션을 검토한다면 먼저 현재 Ingress 설정에서 어떤 어노테이션을 사용 중인지 목록화해야 한다.

• configuration-snippet, server-snippet은 대체 수단이 없다.
  이 기능은 raw NGINX 지시문을 직접 주입하는 방식이다. Gateway API는 이런 주입 경로를 제공하지 않는다. 헤더 수정이나 타임아웃처럼 흔한 기능은 표준 기능으로 옮겨갈 수 있지만, 임의 지시문 주입에 의존했다면 구조를 다시 설계해야 한다.
• mTLS 클라이언트 인증은 Gateway API v1.4에 표준 필드가 없다.
  업그레이드된 스펙을 기다리거나 구현체 고유 기능을 활용해야 한다.
• 세션 어피니티는 구현체별 차이가 크다.
  쿠키 기반 Sticky 설정은 스펙과 구현 방식의 차이를 함께 확인해야 하며, 변환 도구가 자동으로 처리하지 못할 수 있다.

장애 복구는 얼마나 빨랐나

이번 실험에서는 conformance 테스트가 다루지 않는 운영 지표도 함께 측정했다. 기본 설치 환경에서 트래픽을 받는 프록시 파드를 강제로 삭제한 뒤, 2초 간격으로 요청을 보내며 트래픽이 돌아올 때까지 걸린 시간을 확인했다.

구현체	복구 결과	해석
Istio Gateway	무중단	파드 교대 과정이 매끄럽게 처리됐다.
kgateway	무중단	실패 요청 없이 새 파드로 전환됐다.
NGINX Gateway Fabric	약 13초	단일 파드 환경에서는 짧은 공백이 발생했다.
Envoy Gateway	약 13초	기본 구성 기준 복구 시간이 관측됐다.
Traefik Gateway	약 13초	파드 교체 중 일부 공백이 있었다.
Kong Gateway	약 34초	이번 측정에서 가장 긴 복구 시간이 나왔다.
Cilium Gateway	측정 제외	공유 eBPF 데이터플레인 특성상 동일 조건 비교에서 제외했다.

파드를 삭제했는데도 무중단이 가능했던 이유는 쿠버네티스의 종료 유예 시간 때문이다. 파드는 삭제 명령을 받자마자 사라지지 않고 일정 시간 살아 있으며, 그 사이 새 파드가 올라온다. 기존 파드가 남은 트래픽을 처리하고 새 파드와 자연스럽게 교대하면 외부에서는 끊김이 보이지 않는다.

물론 실제 프로덕션에서는 replica를 여러 개 두는 것이 일반적이다. 하지만 단일 노드 엣지 환경처럼 replica를 늘리기 어려운 곳에서는 이 복구 공백이 그대로 사용자에게 노출될 수 있다.

실제로 도입할 때 확인해야 할 것들

수치는 어디까지나 수치다. 실제 이전에서는 현재 사용 중인 기능, 운영 환경, 지원 버전, 장애 대응 방식까지 함께 봐야 한다. 관리자 입장에서 보면 다음 세 가지를 먼저 확인하는 것이 안전하다.

1. 현재 사용하는 어노테이션 목록을 만든다.
   configuration-snippet, server-snippet, mTLS 클라이언트 인증, 세션 어피니티를 사용 중이라면 표준 기능만으로는 바로 옮기기 어렵다.
2. 변환 도구의 출력은 검증까지 완료한다.
   ingress2gateway로 1차 변환을 수행하되, 변환 성공을 실제 동작 성공으로 보지 말고 항목별로 호출 테스트를 해야 한다.
3. Gateway API 버전과 컨트롤러 버전을 함께 고정한다.
   컨트롤러가 지원하는 범위보다 먼저 CRD를 올리면 새로운 리소스가 정상적으로 동작하지 않을 수 있다. 릴리스 노트에서 지원 Gateway API 버전을 확인한 뒤 업그레이드해야 한다.

버전 해석 주의
이번 결과는 2026년 6월, Gateway API v1.4 기준의 스냅샷이다.
측정 이후 상위 버전에서 일부 미지원 기능이 해소됐을 수 있다.
따라서 결과를 볼 때는 반드시 측정 버전과 현재 사용하려는 버전을 함께 비교해야 한다.

마무리

이번 재측정의 결론은 특정 구현체 하나를 무조건 추천하는 데 있지 않다. 더 중요한 결론은 Gateway API 선택에서 Core 통과 여부만으로는 충분하지 않다는 점이다. 7개 구현체 모두 Core를 통과했지만 Extended 기능 폭, 외부 인증 처리, 복구 시간, 설치 방식, 데이터플레인 구조는 크게 달랐다.

또한 지난해 Kong과 Traefik의 결과가 바뀐 것처럼, 측정 결과는 제품만이 아니라 표준 버전, 설치 방식, 테스트 설계에 따라 달라질 수 있다. Gateway API로 이전하려는 팀이라면 먼저 현재 ingress-nginx 설정을 목록화하고, 변환 결과를 실제 트래픽으로 검증한 뒤, 도입 후보의 Gateway API 지원 버전을 고정해 비교하는 과정이 필요하다.

Ingress NGINX 이후의 선택지는 하나가 아니다. 이제 중요한 것은 어떤 구현체가 가장 유명한지가 아니라, 우리 환경에서 필요한 기능을 표준으로 제공하는지, 표준 밖 기능은 어떻게 보완하는지, 장애 상황에서 얼마나 예측 가능하게 동작하는지를 확인하는 일이다.