Ingress NGINX 은퇴 앞둔 상황, 어떻게 준비할까

2026년 4월 26일|Platform Decision|13분 읽기

갑작스럽게 찾아온 변화

최근 Kubernetes 커뮤니티에 꽤 묵직한 발표가 하나 올라왔습니다. 오랫동안 수많은 클러스터에서 사실상 기본 게이트웨이 역할을 해온 Ingress NGINX가 2026년 3월에 공식 지원을 종료한다는 소식이었죠.

사실 이런 날이 언젠가 올 거라는 예감은 있었습니다. 보안 이슈가 주기적으로 터졌고, 유지보수에 손을 보태는 사람은 점점 줄고 있었으니까요. 그래도 막상 공식 종료가 못 박히고 나니 체감이 다르더군요. 클러스터 입구를 지키던 문지기가 어느 날 사표를 낸 셈입니다. 입구는 그대로인데 지킬 사람이 사라지는 거죠.

현장에서 인프라를 다뤄본 사람이라면 이런 상황이 왜 부담스러운지 바로 압니다. Ingress 컨트롤러는 클러스터 안에서 가장 바깥에 서 있는 컴포넌트입니다. 여기가 흔들리면 그 뒤에 있는 모든 서비스가 같이 흔들려요. 교체 대상치고는 위험 부담이 큰 자리입니다.

왜 은퇴하게 됐을까

Ingress NGINX의 가장 큰 문제는 역설적이게도 너무 유연했다는 점이었습니다. 임의의 NGINX 설정을 어노테이션으로 주입할 수 있다는 건 초기엔 분명한 강점이었어요. 어떤 요구사항이 들어와도 설정으로 어떻게든 맞춰줄 수 있었으니까요.

그런데 이 유연함이 시간이 지나면서 보안의 구멍으로 바뀝니다. 사용자가 임의의 설정을 주입할 수 있다는 건, 공격자 입장에서도 임의의 설정을 주입할 통로가 열려 있다는 뜻이거든요. 원인과 결과가 깔끔하게 갈립니다. 유연함이 원인이고, 취약점이 결과입니다.

여기에 구조적인 문제가 겹쳤습니다. 보안 이슈가 계속 발견되는데, 이를 따라잡을 유지보수 인력은 소수였어요. Kubernetes SIG 네트워크팀에서도 더 이상 안전하게 유지하기 어렵다고 판단한 것으로 보입니다. 결국 기술적 결함이라기보다, 사람과 구조가 버티지 못한 쪽에 가깝습니다.

겹쳐서 작동한 문제들:

지속적으로 발견되는 보안 취약점
이를 감당하기엔 부족한 유지보수 인력
오래된 아키텍처에서 누적된 기술 부채
Kubernetes 업데이트 속도를 따라가지 못하는 구조

대안들을 살펴보자

그렇다면 어떤 선택지가 있을까요? 후보들을 하나씩 뜯어봤습니다.

Gateway API (Contour/Envoy)

미래 지향적인 선택입니다. Kubernetes의 차세대 표준으로 자리를 잡아가고 있어서, 장기적으로는 가장 안전한 베팅이라고 봐요. Ingress가 어노테이션에 기능을 욱여넣던 방식에서 벗어나, 라우팅 규칙을 별도 리소스로 명확하게 분리한 게 핵심입니다. 운영자와 개발자의 책임 경계가 스펙 차원에서 나뉜다는 점이 마음에 듭니다.

표준 스펙 기반의 안정성
강력한 커뮤니티 지원
최신 기능 적극 반영
다소 높은 러닝 커브

Traefik Proxy

사용 편의성으로는 단연 위쪽입니다. 설정이 직관적이고 자동 서비스 디스커버리가 잘 동작해서, 손이 덜 가요.

간단한 설정과 관리
우수한 문서화
활발한 커뮤니티
Let's Encrypt 자동 연동

Kong Ingress Controller

단순 라우팅을 넘어 API 게이트웨이 기능까지 필요하다면 Kong이 후보에 들어옵니다. 플러그인 생태계가 풍부해서 인증, 레이트 리밋, 변환 같은 걸 컨트롤러 레이어에서 처리할 수 있어요. 전사 OpenAPI를 다뤄본 입장에서 보면, 게이트웨이에 기능을 얹을지 애플리케이션에 둘지는 늘 고민거리였습니다. Kong은 그 무게중심을 게이트웨이 쪽으로 가져오는 선택입니다.

HAProxy Ingress

성능을 최우선에 둔다면 HAProxy도 볼 만합니다. 오랜 시간 검증된 안정성과 성능이 강점이죠. 화려한 기능보다 묵직하게 트래픽을 받아내는 자리에 어울립니다.

선택 기준은 무엇일까

어떤 걸 고를지는 결국 여러 축을 동시에 놓고 봐야 합니다. 한 가지 지표만 보고 결정하면 나중에 후회하기 쉬워요.

보안 측면

항목	중요도	평가 포인트
취약점 이력	높음	CVE 기록, CVSS 점수
대응 속도	높음	패치 릴리즈 속도
보안 기능	중간	mTLS, OIDC 지원 여부

이번 은퇴의 원인 자체가 보안이었던 만큼, 이 축은 평가에서 가장 먼저 봐야 합니다. 같은 실수를 반복하지 않으려면요.

운영 복잡성

설치와 설정의 난이도
기존 팀의 학습 곡선
CI/CD 파이프라인 통합 복잡도
장애 분석 도구의 품질

도입 시점의 난이도보다, 새벽에 장애가 터졌을 때 원인을 얼마나 빨리 짚을 수 있느냐가 더 중요합니다. 운영을 길게 해보면 도구의 진짜 비용은 평상시가 아니라 사고 났을 때 드러나거든요.

성능과 확장성

실제 워크로드와 비슷한 환경에서 직접 돌려보는 게 가장 확실합니다. RPS 용량, 지연시간, 리소스 사용량을 같이 측정해봐야 해요. 벤치마크 수치는 참고는 되지만, 우리 트래픽 패턴에서의 숫자가 아니면 의미가 반쯤 깎입니다.

마이그레이션 어떻게 할까

실제 전환은 단계적으로 가는 게 안전합니다. 입구를 한 번에 갈아끼우는 건 권하지 않아요.

1단계: 현황 파악

먼저 지금 돌고 있는 Ingress 리소스를 빠짐없이 정리해야 합니다. 특히 어노테이션에 어떤 설정이 박혀 있는지가 핵심이에요. 여기 숨어 있는 커스텀 설정이 마이그레이션의 난이도를 결정합니다.

# 모든 Ingress 리소스 조회
kubectl get ingress --all-namespaces

# 특정 어노테이션 사용 현황 확인
kubectl get ingress -o yaml | grep -A 5 -B 5 "nginx.ingress"

2단계: 대상 솔루션 검증

스테이징에서 충분히 굴려봐야 합니다. 특히 기존에 쓰던 어노테이션이 새 솔루션에서도 대응되는지 확인이 필요해요. NGINX에서만 통하던 설정은 보통 1:1로 옮겨지지 않습니다. 이 단계에서 안 맞는 부분을 미리 발견해두지 않으면, 운영 전환 당일에 발견하게 됩니다.

3단계: 점진적 롤아웃

블루-그린이나 카나리 방식으로 리스크를 잘게 쪼개는 게 좋습니다.

새 Ingress 컨트롤러 설치
일부 서비스만 새 컨트롤러로 라우팅
모니터링하면서 비중을 조금씩 확대
모든 트래픽 이전 후 구 컨트롤러 제거

핵심은 언제든 되돌릴 수 있는 상태를 유지하는 겁니다. 트래픽을 한 번에 넘기는 순간 롤백 카드가 사라집니다.

4단계: 모니터링과 검증

메트릭, 로그, 알림이 새 컨트롤러에서도 제대로 동작하는지 확인해야 합니다. 특히 Prometheus 메트릭 형식이 바뀔 수 있으니 대시보드와 알림 룰도 같이 손봐야 해요. 여기를 놓치면 전환은 끝났는데 정작 클러스터 입구가 보이지 않는 상태가 됩니다. 멀쩡해 보이지만 계기판이 꺼진 차를 모는 셈이죠.

언제까지 준비해야 할까

데드라인은 2026년 3월이지만, 여유를 두고 2025년 말까지 마이그레이션을 끝내두는 편이 안전하다고 봅니다.

특히 대규모 클러스터라면 더 일찍 움직여야 하고요. 도구 교체는 기술 작업만으로 끝나지 않습니다. 팀이 새 도구에 적응하고, 장애 대응 시나리오를 다시 손에 익히는 시간까지 일정에 넣어야 해요. 데드라인에 맞춰 겨우 전환을 끝낸 상태에서 첫 장애를 만나면, 익숙하지 않은 도구로 새벽에 헤매게 됩니다.

마치며

기술 생태계에서 이런 은퇴는 사실 자연스러운 흐름입니다. 그래도 막상 내 클러스터 입구가 걸린 문제로 닥치면 부담스러운 게 당연하죠.

다만 이걸 단순한 강제 교체로만 보면 손해입니다. 그동안 어노테이션에 쌓아둔 설정 부채를 한 번 털어내고, 라우팅 규칙을 표준 스펙 위에서 다시 정리할 기회이기도 하거든요. 어차피 손을 대야 한다면, 다음 은퇴 때 또 같은 고민을 반복하지 않을 구조로 옮겨두는 쪽을 택하겠습니다.

#kubernetes#ingress#nginx#gateway-api#마이그레이션