2026년 3월, 쿠버네티스에서 가장 널리 사용되던 Ingress NGINX의 지원이 공식적으로 종료됐습니다. 이제는 실제로 대응해야 할 과제가 된 것입니다. 여기에 ingress-nginx의 설정 주입 방식에서 비롯된 IngressNightmare(CVE-2025-1974, CVSS 9.8) 같은 심각한 보안 취약점까지 드러나면서, Gateway API로의 이전은 더 이상 미룰 수 없는 과제가 됐습니다.

사실 작년에 이를 위한 실험기를 한 차례 정리한 적이 있습니다. 특히, 당시에는 Gateway API 구현체 7종을 비교하면서, Kong과 Traefik 두 구현체가 기본 테스트를 통과하지 못한다고 분석했습니다. 그런데 실제 이전 시점이 다가오며 측정 결과를 다시 살펴보니, 측정 방식과 그 결과를 둘러싼 조건을 다시 볼 필요가 있었습니다.

동일한 7개 구현체를 처음부터 다시 측정하기로 했고, 두 구현체 모두 이번에는 테스트를 통과했습니다. 작년 실험 결과는 결국 제품 자체의 한계가 아니라, 제품을 둘러싼 측정 환경과 측정 방식에 문제가 있었습니다.

그래서 이 글은 새로운 순위표를 소개하기보다, 측정 과정을 어떻게 다시 설계했고 그 과정에서 무엇을 확인했는지 기록하는 데 목적이 있습니다. 왜 다시 기술 성능을 측정하게 됐는지, 채점 방식을 어떻게 새롭게 구성했는지, 그리고 그 과정에서 무엇을 배웠는지를 차례대로 살펴보겠습니다.

왜 다시 측정하기로 했나

올해 초 작성한 글(쿠버네티스 7개 주요 게이트웨이 기술 검증하기)에서는 Ingress NGINX의 지원 종료 후에 어떤 Gateway API가 적합한지를 알아보았었습니다. 시장에서 주로 사용되는 7개 구현체에 17개 테스트를 각각 100회씩 실행하고, 통과율을 기준으로 등급을 매겼습니다. 통과율이 높은 구현체는 A를 받았고, 통과하지 못한 구현체는 가장 낮은 F등급으로 기록됐습니다.

특히 눈에 띈 것은 Kong과 Traefik이었습니다. 두 구현체 모두 가장 낮은 F등급을 받았기 때문입니다. Kong은 라우트가 동기화되지 않아 “no Route matched” 오류가 발생했고, Traefik은 “404 page not found”와 “Gateway not ready”를 반환했습니다. 결과만 보면, 둘 다 기본 라우팅조차 통과하지 못한 것입니다.

하지만 볼수록 이 결과를 기술적으로 한 번 더 검토해 볼 필요가 있다고 느껴졌습니다. Kong은 API 게이트웨이 시장에서 오랫동안 검증된 제품이며, Traefik 역시 많은 팀이 프로덕션 환경에서 사용하고 있습니다. 그런 제품이 기본 라우팅조차 통과하지 못했기에, 제품 자체의 결함 외에 설치 방식이나 측정 절차에 문제가 있었을 가능성도 충분했습니다. 실제 이전을 준비해야 하는 시점이 다가온 만큼, 이 가능성을 그대로 둘 수는 없었습니다.

실험을 미룰 수 없었던 3가지 이유

무엇보다 재측정을 결정하게 된 데에는 세 가지 구체적인 이유가 있었습니다.

첫 번째는, 이제 정말로 이전을 결정해야 하는 시기가 왔기 때문입니다.

작년에는 예고에 그쳤던 Ingress NGINX 지원 종료가 2026년 3월 실제로 일어났습니다. 더 이상 마이그레이션을 미룰 수 없는 상황이 된 만큼, 그 판단의 근거가 되는 측정 결과에도 문제가 없는지 다시 점검할 필요가 있었습니다.

두 번째로, 보안 측면에서도 ingress-nginx를 떠날 이유가 분명해졌기 때문입니다.

ingress-nginx의 configuration-snippet, server-snippet 어노테이션은 raw NGINX 지시문을 그대로 주입하는 구조입니다. 그런데 바로 이 설계가 보안 취약점의 근원이 됐습니다. 대표적인 사례가 IngressNightmare(CVE-2025-1974, CVSS 9.8)입니다. 이 취약점은 공격자가 인증 절차 없이도 원격에서 임의의 코드를 실행할 수 있는(unauthenticated RCE, Remote Code Execution) 문제로, 악용될 경우 클러스터 전체가 장악될 수 있는 심각한 등급입니다. 단순히 유지보수가 끝났기 때문이 아니라, 구조적으로 위험한 기능을 안고 있었던 것입니다. 그만큼 옮겨갈 대상을 제대로 고르는 일이 더 중요해졌습니다.

세 번째, 그리고 가장 중요한 핵심으로, 작년 측정 방식 자체에 기술적인 한계를 발견했다는 점입니다.

다시 살펴보니 당시의 통과율 기반 채점에는 구조적인 문제가 세 가지 있었습니다.

미지원 기능이 점수에 거의 반영되지 않은 문제: 당시 통과율을 PASS와 FAIL만으로 계산하고, 지원하지 않는 항목(SKIP)은 제외하다 보니, 기능을 아예 지원하지 않을 때는 감점 대신 계산 대상에서 빠지는 구조로 진행됐습니다. 결국 기능이 적은 구현체가 오히려 유리해지는 채점의 오류가 있었습니다.
필수 기능과 부가 기능을 같은 무게로 측정: 반드시 지원해야 하는 host 라우팅과, 표준에도 없는 rate limiting을 동일한 항목 가중치로 채점했습니다.
100%와 95%를 구분하지 못한 이슈:A/F 중심의 등급 체계로는 “거의 모든 테스트를 통과했지만 하나가 부족한 구현체”와 “기본 기능부터 동작하지 않는 구현체”가 같은 등급으로 묶였습니다.

요즘 업계에서는 ‘Unlearn’, 즉 한 번 익힌 것을 의도적으로 내려놓는다는 표현을 자주 씁니다. 이번 재측정이 제게는 그 말에 딱 맞는 경험이었습니다. 새로운 데이터를 더 모으는 일이 아니라, 먼저 작년에 내렸던 결론을 내려놓는 것에서부터 다시 시작해야 했기 때문입니다.

결론을 내려놓고 다시 측정하기

기존 채점 구조를 버리고 공식 모델로 다시 만들다

그래서 이번에는 점수 체계를 임의로 손보는 대신, Gateway API의 공식 적합성(conformance) 모델에 맞춰 측정을 다시 설계했습니다.

먼저 Gateway API와 공식 적합성의 개념을 간단히 짚고 넘어가겠습니다. Gateway API는 기존 Ingress를 대체하기 위해 쿠버네티스 커뮤니티가 만든 차세대 트래픽 라우팅 표준입니다. 역할을 GatewayClass(인프라 담당), Gateway(클러스터 운영자), HTTPRoute(애플리케이션 개발자)로 나눠, 더 세밀한 제어와 책임 분리를 지원합니다.

실제로 Ingress 시절에는 구현체마다 동작 방식이 제각각이었습니다. 같은 설정이라도 구현체를 바꾸면 다르게 동작하는 일이 흔했습니다. Gateway API는 이런 파편화를 줄이기 위해, 구현체가 스펙을 제대로 구현했는지 검증하는 공식 적합성 테스트를 제공합니다. 이는 다시 기능의 중요도에 따라 Core와 Extended 두 단계로 구분합니다. Core는 모든 구현체가 반드시 지원해야 하는 기능이고, Extended는 표준에는 포함됐지만 선택적으로 지원하는 기능입니다.

이번에는 기존처럼 17개 테스트를 하나의 통과율로 묶지 않았습니다. 대신 각 기능이 표준에서 어떤 위치를 차지하는지에 따라 나눴습니다.

Core(7개): 모든 구현체가 반드시 지원해야 하는 필수 기능입니다. 하나라도 빠지면 적합하지 않습니다. 공식 모델에서는 이를 전부 통과한 상태를 적합(conformant)한 상태로 봅니다.
Extended(13개): 표준에 든 선택 기능입니다. 지원하지 않는다고 감점하지 않고, 지원하는 갯수(기능의 폭)로 비교했습니다.
구현체 고유 기능: rate limiting이나 외부 인증처럼 표준에 포함되지 않은 기능은 등급에 반영하지 않았습니다. 대신 별도의 매트릭스로만 비교했습니다.

등급 기준 역시 임의로 정하지 않았습니다. Gateway API v1.4.0 공식 소스의 Support 표기를 그대로 인용해 확정했습니다.

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

채점 방식의 전환. 통과율 기반 A/F 등급 구조에서, 공식 conformance 기준으로 변경 <출처: 작가>

원인은 제품이 아니라 측정 방법과 조건

새로운 기준으로 7개 구현체를 라이브 클러스터에서 다시 측정했습니다. 그 결과, 작년에 통과하지 못했던 두 구현체의 결과가 달라졌습니다. Kong과 Traefik 모두 이번에는 Core 7개 항목을 모두 통과했습니다. 또한 작년에는 arm64 이미지를 지원하지 않아 제외했던 kgateway도 이제 측정에 포함됐습니다.

전체 결과를 표로 정리하면 다음과 같습니다. 7개 구현체 모두 Core는 통과했고, 차이가 난 부분은 Extended 기능 지원 범위였습니다.

결과가 왜 이렇게 달라졌을까요?

원인은 하나가 아니었습니다. 공교롭게도, 그 어느 것도 제품 자체의 변화 때문은 아니었습니다. 작년 결과만 보면 제품의 문제처럼 보였지만, 제품을 둘러싼 환경과 측정 방식이 바뀌며 결과 역시 달라졌습니다.

우선 가장 먼저, 표준이 성숙했습니다. 작년 측정은 Gateway API v1.2를 기준으로 했고, 이번에는 v1.4를 기준입니다. 그사이 표준이 두 단계 올라가며, 작년에는 실험 단계였거나 구현체마다 제각각이던 기능들이 공식 표준으로 자리 잡았습니다. 대표적으로 백엔드 구간의 TLS를 다루는 BackendTLSPolicy가 v1.4에서 표준 채널로 승격하며, 작년 Traefik에서 backend-tls 기능을 막았던 CRD 버전 불일치 문제가 해소됐습니다. 또한 작년에는 AMD64만 지원해 애플 실리콘(arm64) 기반 측정 환경에서는 실행할 수 없었던 kgateway도, 이번에는 arm64를 지원하면서 측정 대상에 포함됐습니다.

두 번째는 현행 권장 방식으로 설치했다는 점입니다. 작년에는 Kong을 옛 방식 KIC(Unmanaged)로 설치했습니다. 이번에는 현재 Kong이 Gateway API 운영 방식으로 권장하는 KGO Managed 구성을 사용했습니다. 같은 제품이라도 설치 방식이 달라지니 동작 결과 역시 달라졌습니다.

세 번째는 측정 방식을 더 정교하게 설계했다는 점입니다. 이 부분이 가장 결정적인 차이를 만들었습니다. Kong은 설정을 한 덩어리로 묶어 관리하며 한꺼번에 동기화하는 특성이 있습니다. 따라서 지원하지 않는 기능이 하나라도 포함되면 전체 적용이 거부되고, 그 영향으로 정상적인 기본 라우팅까지 함께 실패했습니다. 작년에 발생했던 “no Route matched” 오류가 바로 이 사례였습니다. 이번에는 측정 도구를 기능별로 라우트를 분리해 적용하니 지원하지 않는 기능만 제외되고, Core 기능은 정상적으로 동작했습니다. Traefik의 실패 원인은 더 단순했습니다. Gateway 리스너가 바라보는 포트와 내부 entrypoint 포트가 서로 맞지 않아 Gateway가 Ready 상태로 올라오지 못했고, 그 결과 “Gateway not ready”와 404 오류가 발생했습니다. 포트 구성을 맞추자 정상적으로 동작했습니다.

정리하면, 작년 Kong과 Traefik이 테스트를 통과하지 못했던 이유는 제품의 근본적인 한계 때문은 아니었습니다. 표준이 성숙하고, 설치 경로가 정리됐으며, 측정 방법이 정교해지면서 풀린 문제였습니다.

작년에 통과하지 못했던 Traefik과 Kong에 라우트를 얹고 직접 호출한 결과 <출처: 작가>

이번 재측정으로 가장 크게 배운 점도 여기에 있습니다. 점수가 낮게 나오면 제품부터 의심하기 쉽지만, 그만큼 측정 자체도 함께 의심해 봐야 한다는 사실입니다. 특히 그 결과가 공개돼 누군가의 기술 도입 판단에 활용된다면, 더욱 그렇습니다.

측정하며 맞닥뜨린 문제들

작년의 결론을 내려놓고 다시 측정하는 과정에서는 결과만큼이나 과정에서도 많은 것을 배웠습니다. 그 과정에서 얻은 공통된 교훈은 하나였습니다. 겉으로는 통과한 것처럼 보이는 신호를 그대로 믿어서는 안 된다는 점입니다.

1. 공식 적합성(conformant) 인증을 받아도 기능 구현 수준은 같지 않다

Gateway API의 공식 권고는 “conformant 구현체를 선택하라”입니다. 하지만 실제로 측정해 보니, 공식 인증을 받은 7개 구현체도 Extended 기능 지원 범위는 6개에서 13개까지 크게 차이가 났습니다.

Envoy Gateway와 Istio는 13개 기능을 모두 지원했고, Cilium과 kgateway는 12개, NGINX Gateway Fabric은 11개, Traefik은 10개를 지원했습니다. Kong은 6개만 지원했습니다. 즉, conformant 인증은 합격선일 뿐, 모두 수준이 비슷하다는 보증은 아닙니다. timeout, 응답 헤더 수정, 요청 미러링처럼 실제 운영 환경에서 자주 쓰이는 기능도 구현체에 따라 지원 여부가 달랐습니다.

같은 conformant 인증, 다른 기능 폭. 7종이 6개에서 13개까지 나뉠 수 있음 <출처: 작가>

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

ingress-nginx 설정을 Gateway API로 변환하는 도구(ingress2gateway)는 30개 넘는 어노테이션을 자동으로 변환해 줍니다. 하지만 변환이 성공했다고 해서 실제로 동작하는 것은 아니었습니다.

예를 들어 CORS 관련 어노테이션은 변환 결과가 깔끔하지만, 실측하면 3개 구현체만 테스트를 통과했습니다. 반면 헤더를 추가하는 x-forwarded-prefix 같은 어노테이션은 변환 시 아무런 경고도 없이 조용히 사라졌습니다. 그래서 이번 비교에서는 “변환됨”과 “동작함”을 서로 다른 칸으로 나눴습니다.

3. “TLS 연결됨”을 “인증서 검증됨”으로 착각할 뻔했다

backend-tls 테스트를 처음 구성했을 때는 TLS 연결이 정상적으로 맺어지고 응답이 오는지만 확인하고 있었습니다. 정작 잘못된 인증서를 실제로 거부하는지 보지 않은 셈입니다. 그래서 의도적으로 잘못된 CA 인증서를 적용한 뒤 다시 테스트했습니다. 다행히 통과한 구현체들은 모두 인증서 검증을 제대로 강제하고 있었습니다.

만약 이 검증 단계를 생략했다면, 실제로는 보안 검증이 이뤄지지 않는데도 “보안 기능 통과”라는 잘못된 결론을 내릴 수도 있었습니다.

4. 표준 외부 인증 필터는 아무도 강제하지 못했다

ingress-nginx에서 auth-url을 이용해 외부 인증을 사용하던 사용자라면 가장 궁금해할 부분입니다. Gateway API에는 외부 인증을 위한 표준 필터(GEP-1494)가 실험 단계로 포함돼 있습니다. 하지만 이번 측정에서는 이 표준 필터를 완전하게 강제하는 구현체를 확인하지 못했습니다. 일부 구현체는 필터를 거부하거나 오류를 냈고, Cilium과 kgateway는 해당 표준 필터 자체를 구현하지 않아 인증 절차 없이 트래픽이 그대로 통과했습니다.

즉, 현재 기준으로는 외부 인증을 표준 필터로 옮길 수 없습니다. 실제 운영에서는 여전히 각 구현체가 제공하는 고유 기능에 기대야 합니다.

구현체별 재측정 결과

이제 구현체 7종을 하나씩 짚어 보겠습니다. 작년 글과 같은 순서로, 각 구현체의 한 줄 평과 장단점을 살펴봅니다. 카드의 점수 자리에는 작년의 A/F 등급 대신 이번 기준인 Core와 Extended, 그리고 복구 시간을 넣었습니다. 작년에 통과하지 못했던 Kong과 Traefik, 측정에서 빠졌던 kgateway의 위치 변화가 눈에 띕니다.

1. NGINX Gateway Fabric (NGF)

한 줄 평 검증된 NGINX의 안정성을 Gateway API로 계승. ingress-nginx의 공식 후속 경로

장점과 단점 NGINX Gateway Fabric의 가장 큰 장점은 결국 NGINX입니다. rate-limit, body-size, basic-auth를 모두 네이티브로 지원하고, 풍부한 문서와 대규모 커뮤니티가 존재합니다. ingress-nginx에서 가장 매끄러운 이행 경로라, 기존 운영 경험을 그대로 활용할 수 있습니다. 다만 표준 Extended는 11개로 최상위권은 아니며(timeout 등 일부 미흡), active health check는 상용 버전인 Plus 전용입니다.

테스트에는 v2.4.2 버전을 사용했습니다. ingress-nginx에서 옮겨 오는 팀에게 부담이 가장 적은 선택지입니다.

2. Envoy Gateway

한 줄 평 가장 넓은 기능 폭, CNCF 차세대 표준

장점과 단점 Envoy Gateway의 가장 큰 강점은 Extended 13개를 전부 지원하는 데서 나오는 폭입니다. 실험 채널 기능이 가장 앞서 있고, rate-limit를 네이티브로 지원하며 active health check와 뛰어난 관측성을 갖췄습니다. 다만 body-size 표준 경로는 현재 구현 전이고, 상대적으로 짧은 역사와 Envoy 자체의 복잡성으로 인한 학습 곡선이 존재합니다.

테스트에는 v1.7.3 버전을 사용했습니다. 기능 폭을 최우선으로 본다면 가장 앞서는 구현체입니다.

3. Istio Gateway

한 줄 평 서비스 메시와 게이트웨이 통합, 자동 mTLS

장점과 단점 Istio Gateway의 가장 큰 장점은 서비스 메시와의 통합입니다. 표준 Extended 13개를 전부 지원하고, mTLS가 자동으로 적용되며, 파드 교체 시에도 무중단이었습니다. 다만 rate-limit와 body-size는 낮은 수준의 설정이 필요해 복잡도가 높은 편이고, tls-passthrough는 v1.4에서 동작하지 않았습니다. 서비스 메시 전체 스택을 도입해야 하는 부담도 함께 고려해야 합니다.

테스트에는 v1.30.0 버전을 사용했으며, 복구도 무중단이었습니다. 이미 서비스 메시를 운영 중이라면 괜찮은 선택지입니다.

4. Cilium Gateway

한 줄 평 eBPF 데이터플레인, CNI와 게이트웨이 통합

장점과 단점 Cilium Gateway의 장점은 eBPF 기반의 커널 레벨 패킷 처리 방식입니다. Core를 모두, 표준 Extended를 12개 갖췄고, Cilium 네트워크 정책과 자연스럽게 연동됩니다. 다만 Cilium CNI가 필수이며, rate-limit와 body-size는 표준 경로에서 지원하지 않습니다. 외부 인증 표준 필터를 무방비로 통과시켜 인증 없이 트래픽이 그대로 지나가는 점도 주의해야 합니다.

테스트에는 v1.19.4 버전을 사용했습니다. 다만 복구 측정은 공유 eBPF 데이터플레인 특성상 제외했습니다. 이미 Cilium CNI를 쓰는 환경에 적합합니다.

5. Kong Gateway(작년 미통과 → 올해 통과)

한 줄 평 엔터프라이즈 API 게이트웨이, 풍부한 플러그인

장점과 단점 Kong Gateway는 엔터프라이즈 API 게이트웨이 시장의 선두 주자로, 풍부한 플러그인 생태계와 API 관리 기능을 갖췄고 rate-limit와 body-size를 네이티브로 지원합니다. 무엇보다 작년과 달리 Core 7개 전부 통과로 기준이 바뀌었습니다. 다만 표준 Extended가 6/13으로 7종 중 가장 좁고, 복구가 약 34초로 가장 느립니다. 설정을 일괄 적용하는 구조라 기능 하나가 거부되면 전체에 영향을 주는 점도 유의해야 합니다.

테스트에는 KGO 2.1 버전을 사용했습니다. API 게이트웨이 생태계가 중요하다면 여전히 강력한 선택지이지만, 기능 폭과 복구 속도는 함께 따져야 합니다.

6. Traefik Gateway(작년 미통과 → 올해 통과)

한 줄 평 자동 서비스 디스커버리와 대시보드, 간편한 운영

장점과 단점 Traefik Gateway는 자동 서비스 디스커버리와 대시보드로 유명한 클라우드 네이티브 프록시입니다. rate-limit와 body-size를 네이티브로 지원하고, 작년과 달리 Core 7개 전부 통과로 바뀌었습니다(리스너 포트 교정). 다만 표준 Extended는 10/13으로 중위권이며, request-mirror 등 일부가 미흡합니다.

테스트에는 v3.6.17 버전을 사용했습니다. 간편한 운영을 중시하는 팀에게 적합합니다.

7. kgateway(작년 측정 제외 → 올해 합류)

한 줄 평 Envoy 기반 게이트웨이, arm64 지원으로 측정 환경에 합류

장점과 단점 kgateway는 Envoy 기반의 게이트웨이로, 표준 Extended 12/13과 무중단 복구를 갖췄습니다. 작년 Gateway API Benchmarks의 트래픽 성능 테스트에서 최고 처리량을 기록(작년 벤치마크 기준)한 만큼, 성능 측면에서 강점이 있습니다. Gloo 계보의 전용 마이그레이션 가이드도 제공합니다. 작년 측정 환경(Apple Silicon, arm64)에서는 AMD64 전용이라 제외됐었으나, 이번에는 합류했습니다. 다만, 외부 인증 표준 필터를 무방비로 통과시킵니다. 커뮤니티 역시 아직 성장 중입니다.

테스트에는 v2.2.2 버전을 사용했습니다. AMD64는 물론 arm64 환경에서도 Envoy 기반 구현체를 찾는다면 주목할 만합니다.

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

재측정 결과, 7종 모두 Core는 통과했습니다. 그러니 이제 선택 기준은 확장 기능 수준, 데이터플레인, 그리고 커뮤니티 활성화 등을 함께 고려하는 게 좋겠습니다. 상황별 추천을 정리하면 이렇습니다.

Core, Extended, 벤더 기능, 운영 지표를 한 장에 모은 전체 범위 지도 <출처: 작가>

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

기능 지원 범위와는 별개로, ingress-nginx에서 자주 쓰던 것 가운데 일부는 Gateway API로 그대로 옮길 수 없습니다. 마이그레이션을 검토하고 있다면, 먼저 아래 세 가지가 현재 설정에 들어 있는지부터 확인해 보길 권합니다.

설정 스니펫(configuration-snippet, server-snippet)은 대체 수단이 없습니다.이 기능은 raw NGINX 지시문을 직접 주입하는 방식입니다. 하지만 Gateway API는 이런 주입 경로를 아예 제공하지 않습니다. 공교롭게도 ingress-nginx의 IngressNightmare 취약점 역시 바로 이 구조에서 비롯됐습니다. 헤더 수정이나 타임아웃처럼 흔한 건 이미 표준 기능으로 흡수됐지만, 임의의 지시문 주입에 의존하고 있었다면 다시 설계해야 합니다.
mTLS 클라이언트 인증(auth-tls-*)은 v1.4에 표준 필드가 없습니다.V.15에는 들어갔으니 업그레이드를 기다리거나, 구현체 고유 기능을 활용해야 합니다.
세션 어피니티(쿠키 Sticky)는 스펙은 있지만 설정이 구현체마다 다릅니다.변환 도구도 이 어노테이션은 자동으로 변환하지 못하고 거절합니다.

장애 복구는 얼마나 빠른가

이번 실험에서는 conformance 테스트가 다루지 않는 운영 지표도 함께 측정했습니다. 기본 설치 환경(데이터 플레인 파드 1개)을 기준으로 트래픽을 받는 프록시 파드를 강제로 삭제한 뒤, 2초 간격으로 요청을 보내면서 트래픽이 돌아올때까지 걸린 시간을 측정했습니다. 여러 replica를 둔 HA 환경의 failover를 측정한 것이 아니라, 파드 하나가 죽었을 때 얼마나 빠르게 복구되는지를 확인한 실험입니다.

Istio와 kgateway는 무중단으로 동작했습니다. 실패한 요청이 한 번도 없었습니다.
NGINX Gateway Fabric, Envoy Gateway, Traefik은 약 13초 만에 복구했습니다.
Kong은 약 34초로 가장 늦었습니다.
Cilium은 공유 eBPF 데이터 플레인을 사용하는 구조이므로 이번 측정에서는 제외했습니다. 에이전트 재시작이 클러스터 전체에 영향을 주기 때문입니다.

파드를 삭제했는데도 어떻게 무중단이 가능했을까요? 쿠버네티스에서 파드는 삭제 명령을 받는 즉시 종료되지 않습니다. 종료 신호를 받은 뒤 일정한 유예 시간 동안 살아있으며, 그 사이 새로운 파드가 올라옵니다. 이 과정에서 기존 파드가 받는 트래픽을 끝까지 처리하고, 새 파드와 자연스럽게 교대하면 밖에서 보기에는 끊김이 없습니다.

Istio와 kgateway는 이 교대 과정이 매끄러웠습니다. 반면 13초 또는 34초가 걸린 쪽은 교대가 겹치지 않아 빈 구간이 생겼습니다. 물론 운영에서는 replica를 여럿 두는 것이 기본이라 가려질 테지만, 단일 노드 엣지처럼 replica를 늘리기 어려운 환경이라면 이 공백이 그대로 사용자에게 노출됩니다.

실제로 도입할 때 고려할 것들

마지막으로 수치는 어디까지나 수치입니다. 실제로 옮기려면 국내 운영 환경 특유의 조건도 봐야 합니다. 특히 확인하면 좋을 것들을 정리했습니다.

1. 지금 쓰는 어노테이션부터 목록으로 만듭니다. 앞서 말한 설정 스니펫, mTLS 클라이언트 인증, 세션 어피니티를 사용하고 있다면 표준 기능만으로는 옮길 수 없습니다. 그러니 먼저 어떤 기능을 사용 중인지 목록으로 정리해 두는 것이 좋습니다. 이 목록이 마이그레이션 난이도를 사실상 결정합니다.

2. 변환 도구의 출력은 믿되, 검증합니다. ingress2gateway로 1차 변환을 수행하되, 변환을 마쳤다고 끝내지 말고 옮긴 환경에서 실제로 동작하는지 항목별로 확인해야 합니다. 운영하다 변환은 됐는데 동작하지 않는 요소를 마주치는 것보다 낫습니다.

3. 버전을 함께 고정합니다. 이번 결과는 2026년 6월, Gateway API v1.4 기준 스냅샷입니다. 한 가지 유의할 점은, 측정 이후 상위 버전에서 일부 미지원 기능이 해소됐다는 것입니다. Traefik의 backend-request-header 수정은 v3.7에서, kgateway의 backend-tls는 v2.3.0에서, Cilium의 backend-tls와 자체 외부 인증(구현체 고유 기능)은 v1.20에서, Kong의 TLSRoute는 KGO 2.2.0에서 각각 지원됩니다. 모두 이번 측정에 사용한 버전보다 이후에 추가된 기능입니다. 따라서 이 결과를 참고할 때는 측정 버전과 함께 해석하는 것이 중요합니다.

더해서 구현체마다 지원하는 Gateway API 버전이 서로 다릅니다. 컨트롤러가 지원하는 범위보다 먼저 CRD를 올리면 새로운 리소스가 정상적으로 동작하지 않을 수 있습니다. 따라서 그 전에 각 구현체의 릴리스 노트에서 지원하는 Gateway API 버전을 확인해야 합니다.

마치며

이번 작업에서 가장 의미 있었던 것은 새로운 순위표 그 자체보다는, 작년에 검증한 것들을 다시 확인해야 한다는 사실 자체였습니다. 작년에 기준조차 통과하지 못했던 두 구현체는 올해 모두 Core를 통과했습니다. 이처럼 측정 결과는 언제나 그 시점의 측정 방법과 환경에 영향을 받습니다. 따라서 측정 방법이 개선됐다면, 결과 역시 함께 달라져야 합니다.

앞서 말한 Unlearn이라는 개념이 다소 거창하게 들릴 수도 있습니다. 하지만 실무에서는 오히려 자주 해야하면서도 막상 하기 가장 어려운 일입니다. 스스로 내렸던 결론을 다시 의심하고, 내려놓고, 처음부터 시작한다는 뜻이기 때문입니다. 그래서 1년 뒤에는 지금 내린 결론 역시 달라질 수 있습니다. Gateway API 표준도, 각 구현체도 그만큼 빠르게 발전하고 있기 때문입니다.

그러니 이 글의 순위를 그대로 받아들이기보다는, 여러분의 환경에서 직접 한 번 측정해 보시길 권합니다.결국 그것이 가장 정확하고, 또 가장 정직한 검증 방법입니다.

이번 측정에 사용한 도구와 채점 기준, 구현체별 설치 스크립트, 변환 결과는 모두 GitHub 저장소에 공개해 두었습니다. 이 글에서는 핵심 결과만 간추려 소개했지만, 저장소에서는 각 구현체가 스펙을 얼마나 정확히 구현했는지, ingress-nginx에서 옮길 때 어떤 기능은 그대로 옮겨지고, 어떤 기능은 막히는지를 확인할 수 있는 자료를 확인할 수 있습니다. 또한 회차별 측정 결과, 부하 테스트에서의 성공률, 어노테이션별 변환 결과 등 세부 데이터도 함께 들어 있습니다. 측정을 하게 된 배경과 그 과정에서 알게 된 점을 글로 풀어 둔 후기는 블로그에서도 볼 수 있습니다.

작가

조훈(CNCF 앰버서더)

쿠버네티스와 AI 네이티브 기술 전문가로, 클라우드 네이티브 컴퓨팅 재단(CNCF)의 글로벌 앰버서더이자 Kubestronaut이다. 쿠버네티스랩(kuberneteslab.dev)을 운영하며 인프라 자동화와 AI 네이티브 기술을 연구하고 공유하고 있다. ‘IT 인프라 엔지니어 그룹’ 운영진이자 오픈소스 컨트리뷰터로도 활동하고 있다. 맞춤형 기술 교육, 쿠버네티스 비용 최적화, AI 에이전트 비교 검증 등 다양한 PoC를 진행하고 있다. 『한 걸음 앞선 개발자가 지금 꼭 알아야 할 클로드 코드』, 『컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커』 등을 집필했다.

심근우

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

문성주

체커(CHEQUER) 사의 DevOps Engineer로서 쿠버네티스의 멀티 클러스터 관리 방법론과 쿠버네티스 구현체(CAPI, OCI)에 대한 명세와 컨테이너 리소스 격리 방법에 대한 연구를 병행하고 있다. 이런 연구 활동을 기반으로 쿠버네티스 볼륨 테스트 파트에 컨트리뷰션했다. 본업은 쿠버네티스 오퍼레이터와 같은 CRD(커스텀 리소스)를 개발해 현업에서 쿠버네티스를 좀 더 편리하게 사용할 수 있도록 돕는 일이다. 또한, 페이스북 그룹 ‘코딩이랑 무관합니다만'과 ‘IT 인프라 엔지니어 그룹'의 운영진을 맡고 있다.

이성민

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