[쿠버네티스] Nginx vs Traefik Ingress Controller 선택 가이드: 13년차 엔지니어의 경험담

안녕하세요, 13년차 서버실을 지키는 인프라 엔지니어입니다. 쿠버네티스(Kubernetes) 환경에서 애플리케이션을 운영하다 보면, 외부 트래픽을 어떻게 효율적으로 서비스에 연결할지가 항상 큰 고민이 됩니다. 특히 여러 서비스를 운영할수록 이 문제는 더욱 복잡해지죠. 처음엔 저도 단순히 <code>NodePort나 LoadBalancer 서비스를 사용했었는데, 점점 더 많은 도메인과 복잡한 라우팅 규칙을 관리해야 하는 상황에 부딪히더라고요. 이럴 때 필요한 것이 바로 Ingress Controller(인그레스 컨트롤러)입니다.

오늘은 제가 홈랩(Homelab)에서 Nginx Ingress Controller와 Traefik Ingress Controller를 모두 사용해보면서 겪었던 경험과 두 솔루션의 장단점을 솔직하게 비교해드릴게요. 어떤 상황에서 어떤 Ingress Controller를 선택하는 것이 좋을지 제 경험을 토대로 멘토처럼 알려드리겠습니다. 이 글이 여러분의 쿠버네티스 트래픽 관리 고민을 덜어주면 정말 좋겠어요.

쿠버네티스 클러스터 내에서 Ingress Controller가 외부 트래픽을 서비스로 라우팅하는 전체 아키텍처를 보여주는 다이어그램입니다. 외부 로드밸런서에서 Ingress Controller로, 다시 Ingress Rule에 따라 내부 서비스로 트래픽이 흐르는 과정을 시각화합니다.

Ingress Controller, 대체 뭘까요?

쿠버네티스에서 Ingress(인그레스, 외부 트래픽 진입점)는 클러스터 내부의 서비스(Service)로 외부 트래픽을 라우팅하는 규칙들을 정의하는 API 오브젝트죠. 쉽게 말해, example.com으로 들어온 요청은 web-service로 보내고, api.example.com/v1으로 들어온 요청은 api-service로 보내는 것과 같은 규칙을 정의하는 거예요. 하지만 Ingress 오브젝트 자체는 단순히 규칙을 정의할 뿐, 실제로 그 규칙에 따라 트래픽을 처리하는 역할을 하지는 않습니다. 바로 이걸 실제로 처리하는 게 Ingress Controller(인그레스 컨트롤러)입니다.

Ingress Controller는 클러스터 내부에서 실행되는 일종의 역방향 프록시(Reverse Proxy) 또는 로드 밸런서(Load Balancer)로, Ingress 리소스에 정의된 규칙을 읽어 실제 트래픽 라우팅을 수행합니다. 대표적으로 Nginx, Traefik, HAProxy, Envoy 등의 솔루션들이 Ingress Controller로 활용될 수 있습니다. 이 중에서 가장 널리 사용되고 제가 직접 많이 써본 Nginx와 Traefik을 중심으로 이야기해볼게요.

Nginx Ingress Controller 파헤치기

Nginx Ingress Controller는 이름에서 알 수 있듯이, 인기 있는 웹 서버이자 역방향 프록시인 Nginx를 기반으로 만들어졌습니다. 오랫동안 인프라 엔지니어들에게 사랑받아온 Nginx의 안정성과 성능을 쿠버네티스 환경에서도 활용할 수 있다는 게 가장 큰 장점이죠. 저도 예전부터 Nginx를 많이 써왔던 터라, 처음 쿠버네티스 Ingress를 접했을 때 가장 먼저 선택하게 된 솔루션입니다.

✅ Nginx Ingress Controller의 주요 장점

• 높은 안정성과 성능: Nginx 자체가 워낙 안정적이고 고성능이어서, 대규모 트래픽 처리에도 강합니다.
• 광범위한 사용처와 커뮤니티: 가장 널리 사용되는 Ingress Controller 중 하나인 만큼, 자료가 풍부하고 문제가 생겼을 때 도움을 받기 쉽습니다.
• 풍부한 기능: Nginx의 강력한 기능을 annotation(어노테이션)을 통해 활용할 수 있습니다. (예: 리다이렉트, 인증, 로드밸런싱 알고리즘 등)

⚠️ Nginx Ingress Controller의 아쉬운 점

• 설정의 복잡성: Nginx 설정 파일(nginx.conf)을 직접 다루지 않고 ConfigMap(컨피그맵)이나 annotation으로 간접적으로 설정하다 보니, 특정 고급 기능을 사용하려면 Nginx 설정 문법을 이해하고 annotation을 정확히 알아야 합니다.
• 동적 업데이트의 한계: 새로운 Ingress 규칙을 적용하거나 기존 규칙을 변경할 때, Nginx 프로세스를 리로드(reload)하는 과정이 필요합니다. 컨트롤러가 자동으로 처리하지만, Traefik에 비해서는 동적이라는 느낌이 덜합니다.

간단한 Nginx Ingress 리소스 예시를 볼까요? example.com으로 들어오는 요청을 my-service로 라우팅하는 설정입니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-nginx-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

Traefik Ingress Controller 만나보기

Traefik Proxy(트래픽 프록시)는 클라우드 네이티브 환경에 최적화된 최신 역방향 프록시 및 로드 밸런서입니다. 특히 쿠버네티스 Ingress Controller로서의 강점이 두드러지죠. 처음엔 이게 뭔가 싶었는데, 써보니 동적인 설정 관리가 정말 신세계더라고요.

✅ Traefik Ingress Controller의 주요 장점

• 뛰어난 동적 설정: 쿠버네티스의 CRD(Custom Resource Definition, 사용자 정의 리소스 정의)를 적극 활용하여 Ingress 규칙을 실시간으로 업데이트합니다. Nginx처럼 리로딩 과정 없이 즉시 반영돼요.
• 쉬운 설정 및 대시보드: IngressRoute와 같은 CRD를 통해 직관적인 설정이 가능하고, 웹 대시보드를 기본으로 제공하여 현재 라우팅 상태를 한눈에 파악하기 좋습니다. 저는 홈랩에서 여러 서비스를 띄울 때 이 대시보드가 정말 편하더라고요.
• 자동 HTTPS (Let’s Encrypt): Let’s Encrypt(렛츠 인크립트)를 내장하여 도메인에 대한 HTTPS 인증서를 자동으로 발급하고 갱신해줍니다. 이거 진짜 편합니다!
• 간결한 설정: Nginx의 복잡한 annotation 대신, 자체 CRD를 사용해 더 명확하고 간결하게 설정을 정의할 수 있습니다.

⚠️ Traefik Ingress Controller의 아쉬운 점

• Nginx 대비 상대적으로 작은 커뮤니티: Nginx만큼 오랜 역사를 가진 건 아니어서, 자료나 커뮤니티 규모가 상대적으로 작을 수 있습니다. 하지만 성장세가 빠르고 공식 문서가 잘 되어 있습니다.
• 특정 고급 기능의 복잡성: Nginx가 가진 다양한 모듈만큼의 유연성은 아닐 수 있습니다. 특정 시나리오에서는 Nginx의 annotation이 더 직관적일 때도 있습니다.

Traefik의 IngressRoute CRD 예시입니다. Nginx Ingress와 동일하게 example.com을 my-service로 라우팅합니다.

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: my-traefik-ingressroute
spec:
  entryPoints:
    - web
    - websecure
  routes:
    - match: Host(`example.com`)
      kind: Rule
      services:
        - name: my-service
          port: 80
  tls:
    certResolver: myresolver # Let's Encrypt를 사용하는 경우

실전 비교: Nginx vs Traefik, 어떤 걸 선택해야 할까?

이제 두 Ingress Controller의 특징을 알았으니, 어떤 상황에서 어떤 것을 선택하는 것이 좋을지 제 경험을 토대로 비교해드릴게요. 사실 정답은 없습니다. 여러분의 환경과 요구사항에 따라 달라지는 거죠.

Nginx Ingress Controller와 Traefik Ingress Controller의 핵심적인 기능, 설정 방식, 성능, 커뮤니티 지원, 자동화 기능 등을 비교하는 표입니다. 사용자가 두 Ingress Controller 중 하나를 선택하는 데 필요한 정보를 요약하여 제공합니다.

Nginx Ingress Controller 추천하는 경우

• 레거시 시스템과의 연동: 이미 Nginx 설정을 잘 다루는 팀이 있거나, 기존 Nginx 설정에 익숙하다면 Nginx Ingress Controller가 더 자연스럽게 느껴질 겁니다.
• 최고의 안정성과 성능이 요구될 때: 미션 크리티컬한 서비스로, 수년간 검증된 Nginx의 안정성과 성능이 절대적으로 필요하다면 좋은 선택입니다.
• 복잡하고 세밀한 트래픽 제어: Nginx의 다양한 모듈과 세밀한 설정을 통해 고도로 커스터마이징된 트래픽 제어가 필요할 때 유용합니다.

Traefik Ingress Controller 추천하는 경우

• 클라우드 네이티브 환경에 대한 높은 이해도와 선호: 쿠버네티스의 CRD를 활용한 동적인 설정에 강점이 있습니다.
• 빠른 개발 및 배포 주기: 새로운 서비스를 자주 배포하거나 Ingress 규칙이 자주 변경되어야 하는 환경에서 실시간 업데이트는 큰 장점입니다.
• 간편한 Let’s Encrypt 자동화: 수많은 서비스에 HTTPS를 쉽게 적용하고 싶다면 Traefik이 제공하는 자동화 기능은 정말 강력합니다. 저도 홈랩에서 이 기능 덕분에 HTTPS 적용이 너무 쉬웠어요.
• 초보자나 소규모 환경: 대시보드와 쉬운 설정 덕분에 초보자도 빠르게 시작하고 관리할 수 있습니다.

제가 겪었던 삽질과 해결 과정 ⚠️

저도 처음부터 모든 걸 다 알았던 건 아니죠. 두 Ingress Controller를 사용하면서 꽤나 삽질을 많이 했습니다. 특히 몇 가지 기억에 남는 경험을 공유해볼게요.

Nginx Ingress Controller 삽질: Annotation 지옥과 ConfigMap 캐싱

Nginx Ingress Controller를 사용하면서 가장 많이 헷갈렸던 부분은 annotation이었습니다. Nginx의 모든 기능을 annotation으로 매핑하는 게 아니다 보니, 특정 기능(예: 커스텀 에러 페이지, 특정 헤더 추가)을 넣으려 할 때 어떤 annotation을 써야 할지, 아니면 ConfigMap을 수정해야 할지 찾는 데 시간을 많이 썼습니다. 특히 ConfigMap을 수정했을 때 바로 반영이 안 되고 캐싱 때문에 고생했던 기억도 있네요. ConfigMap을 업데이트하면 Nginx Ingress Controller Pod가 재시작되거나 설정이 리로드되는데, 이 과정에서 찰나의 순간 서비스에 영향을 줄까 봐 조마조마했던 적도 많았습니다.

💡 해결 팁: Nginx Ingress Controller의 공식 문서에 있는 annotation 목록을 즐겨찾기에 등록해두고, ConfigMap 수정 후에는 항상 컨트롤러 로그를 확인하며 제대로 리로드되었는지 확인하는 습관을 들였습니다.

Traefik Ingress Controller 삽질: CRD 이해와 EntryPoint 설정

Traefik은 Nginx와는 다르게 IngressRoute라는 자체 CRD를 사용합니다. 처음엔 이 개념이 좀 낯설었어요. 특히 entryPoints와 middlewares 같은 개념들을 이해하는 데 시간이 걸렸죠. 예를 들어, 특정 포트(entryPoint)로 들어오는 요청에만 적용되는 규칙을 만들거나, 인증(middleware)을 추가하는 설정을 하려다가 몇 번이나 실패했는지 모릅니다. 특히 tls 설정에서 certResolver를 제대로 지정하지 않아서 Let’s Encrypt 자동 발급이 안 되는 문제도 겪었고요.

# 잘못된 IngressRoute 설정 예시 (entryPoints 누락)
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: my-broken-route
spec:
  routes:
    - match: Host(`broken.example.com`)
      kind: Rule
      services:
        - name: my-service
          port: 80
# 이 경우, Traefik이 어떤 entryPoint로 트래픽을 받을지 몰라 동작하지 않습니다.

💡 해결 팁: Traefik 공식 문서를 정독하고, 특히 entryPoints와 middlewares 개념을 확실히 이해하는 것이 중요했습니다. 그리고 IngressRoute를 배포하기 전에 항상 Traefik 대시보드를 통해 현재 설정이 어떻게 반영될지 미리 확인하는 습관을 들였어요. 대시보드만큼 직관적인 디버깅 도구가 없더라고요!

Traefik Ingress Controller의 웹 대시보드 스크린샷으로, 현재 활성화된 서비스와 라우팅 규칙(IngressRoutes)이 명확하게 표시되어 트래픽 흐름을 시각적으로 파악할 수 있는 화면입니다.

결론: 당신의 환경에 맞는 Ingress Controller는?

제가 Nginx와 Traefik을 모두 써보면서 느낀 점은, 두 Ingress Controller 모두 훌륭한 솔루션이라는 것입니다. 다만 각자의 강점과 약점이 뚜렷하다는 것이죠. Nginx는 전통적인 인프라 환경에서 익숙한 안정성과 고성능을 제공하며, 복잡한 설정에 대한 유연성을 가집니다. 반면 Traefik은 클라우드 네이티브 환경의 동적인 특성에 완벽하게 부합하며, 자동화와 사용 편의성에서 큰 강점을 보입니다.

저의 홈랩 환경에서는 새로운 서비스를 빠르게 올리고 내리며, Let’s Encrypt로 HTTPS를 쉽게 적용해야 하는 경우가 많아서 최종적으로는 Traefik Ingress Controller를 선택하여 운영하고 있습니다. 대시보드를 통해 현재 라우팅 상황을 한눈에 볼 수 있고, 새로운 IngressRoute를 배포하면 바로 적용되는 그 편리함이 정말 매력적이었거든요. 물론 Nginx도 여전히 중요한 역할을 하는 곳이 많습니다. 여러분의 팀 문화, 기존 인프라 스택, 그리고 프로젝트의 요구사항을 신중하게 고려하여 쿠버네티스 트래픽 관리에 최적의 선택을 하시길 바랍니다.

Nginx Ingress Controller와 Traefik Ingress Controller의 주요 특징, 장단점, 추천 사용 사례를 한눈에 비교할 수 있도록 시각적으로 요약한 인포그래픽입니다.

마무리하며

쿠버네티스 환경에서 Ingress Controller는 외부와 내부를 연결하는 중요한 다리 역할을 합니다. Nginx와 Traefik 모두 각자의 방식으로 이 역할을 훌륭하게 수행하죠. 어떤 것을 선택하든, 중요한 것은 해당 솔루션의 작동 방식을 이해하고 여러분의 환경에 맞게 최적화하는 것입니다. 제가 겪었던 삽질 경험들이 여러분의 시간과 노력을 아끼는 데 조금이나마 도움이 되었기를 바랍니다.

다음 글에서는 Traefik을 이용한 Let’s Encrypt 자동화 설정에 대해 좀 더 자세히 다뤄볼까 합니다. 긴 글 읽어주셔서 감사합니다! 궁금한 점이 있다면 언제든지 댓글로 남겨주세요. 제가 아는 선에서는 성심성의껏 답변해드리겠습니다. 🎉