[IT-정보] 인그레스 운영 사례 분석: 실무 적용기와 개선 포인트 – 백엔드 개발자를 위한 실제 구축 경험과 설정 노하우

클라우드 비용 폭탄을 마주한 어느 개발자의 이야기

마이크로서비스 아키텍처(MSA)로 전환하면서 서비스 개수는 기하급수적으로 늘어났어요. 처음에는 단순하게 각 서비스마다 LoadBalancer 타입의 서비스를 생성해서 외부로 노출했어요. 서비스가 5개일 때까지만 해도 비용 부담이 크지 않았어요. 하지만 서비스가 20개가 넘어가자 상황이 달라졌어요. 클라우드 콘솔의 청구서를 확인했을 때 눈을 의심할 수밖에 없었죠. 각 서비스마다 할당된 로드밸런서의 비용이 합쳐지니 예상 범위를 훨씬 초과해 버렸거든요.

단순히 비용 문제뿐만이 아니었어요. 서비스마다 고유한 공인 IP를 관리해야 했고, 도메인을 연결할 때마다 DNS 설정을 일일이 변경해야 하는 번거로움이 따랐어요. 보안 인증서(SSL/TLS)를 각 서비스에 개별적으로 적용하는 과정도 정말 고역이었죠. 인프라를 관리하는 시간이 개발 시간보다 길어지는 기분이 들었어요. 이런 상황에서 우리가 찾은 돌파구가 바로 인그레스(Ingress)였어요.

인그레스를 도입하면서 우리는 단 하나의 로드밸런서만으로 수십 개의 서비스를 효율적으로 관리할 수 있게 되었어요. 도메인 주소에 따라, 혹은 경로(Path)에 따라 트래픽을 분산하는 규칙을 정교하게 설계할 수 있었죠. 이번 글에서는 제가 실제 운영 환경에서 인그레스를 도입하며 겪었던 과정과 시행착오를 가감 없이 공유하려고 해요.

인그레스 도입 전 반드시 체크해야 할 핵심 요소

무턱대고 인그레스를 설치한다고 모든 문제가 해결되지는 않아요. 먼저 우리 서비스의 트래픽 패턴과 네트워크 요구사항을 정확히 파악해야 해요. 단순히 비용을 아끼기 위해 도입했다가, 오히려 설정의 복잡함 때문에 트래픽 제어에 실패하는 경우를 많이 봤거든요. 인그레스는 단순한 로드밸런서가 아니라 L7 계층의 규칙 기반 라우터라는 점을 명심해야 해요.

가장 먼저 고민해야 할 부분은 어떤 인그레스 컨트롤러를 사용할 것인가예요. 가장 대중적인 것은 Nginx 인그레스 컨트롤러이지만, 클라우드 환경에 따라 AWS ALB Controller나 Google Cloud Load Balancer를 사용하는 것이 더 유리할 수도 있어요. 인프라 운영팀의 성향과 우리가 관리해야 할 도메인의 개수, 그리고 요구되는 기능(예: Canary 배포, Rate Limiting)을 기준으로 선택해야 해요.

위 표에서 볼 수 있듯이, 인그레스는 비용과 기능 면에서 압도적인 우위에 있지만 설정의 복잡도를 관리할 수 있는 역량이 전제되어야 해요. 특히 경로(Path)를 어떻게 설계할지에 따라 애플리케이션 내부의 API 호출 경로까지 영향을 미칠 수 있다는 점을 꼭 기억하세요. 설계를 잘못하면 나중에 모든 마이크로서비스의 코드를 수정해야 하는 대참사가 벌어질 수도 있어요.

실무 적용을 위한 인그레스 구축 5단계

이제 실제 환경에서 인그레스를 어떻게 구축하고 운영하는지 단계별로 살펴볼게요. 저는 가장 범용성이 높고 커뮤니티가 활성화된 Nginx Ingress Controller를 기준으로 설명할게요. 이 과정은 단순한 설치를 넘어, 실무에서 바로 동작 가능한 수준의 구성을 목표로 해요.

STEP 1. 인그레스 컨트롤러 설치하기

가장 먼저 해야 할 일은 트래픽을 받아줄 실제 엔진인 ‘인그레스 컨트롤러’를 클러스터에 배포하는 것이에요. 수동으로 YAML 파일을 작성하는 것보다 Helm을 사용하는 것이 훨씬 안전하고 관리하기 편해요. Helm을 이용하면 컨트롤러가 사용할 설정값들을 미리 정의한 차트(Chart)를 통해 손쉽게 설치할 수 있거든요.

설치할 때는 반드시 `controller.service.type`을 `LoadBalancer`로 설정해야 해요. 그래야 클라우드 업체로부터 하나의 공인 IP를 할당받아 인그레스 컨트롤러가 외부 트래픽을 받을 수 있는 통로가 생기기 때문이에요. 설치가 완료되면 `kubectl get svc` 명령어를 통해 외부 IP가 정상적으로 할당되었는지 꼭 확인하세요.

STEP 2. 호스트 기반 라우팅 설계하기

컨트롤러가 준비되었다면 이제 트래픽을 어디로 보낼지 규칙을 정해야 해요. 가장 많이 사용하는 방식은 도메인 이름(Host)에 따라 서비스를 나누는 방식이에요. 예를 들어, `api.example.com`으로 들어오는 요청은 API 서비스로, `web.example.com`으로 들어오는 요청은 프론트엔드 서비스로 보내는 식이죠.

이때 주의할 점은 Ingress 리소스의 Host 필드를 정확히 기입해야 한다는 거예요. 만약 실수로 오타가 나면 클라우드 로드밸런서는 트래픽을 받지만, 컨트롤러 내부에서 매칭되는 규칙을 찾지 못해 404 에러를 뱉어내게 돼요. 하나의 Ingress 리소스 안에 여러 개의 호스트를 정의할 수도 있지만, 관리 편의성을 위해 서비스 그룹별로 Ingress 리소스를 분리하는 것을 추천해요.

STEP 3. 경로(Path) 기반 라우팅과 Rewrite 설정

도메인은 하나인데 뒤에 붙는 경로에 따라 다른 서비스로 보내고 싶을 때가 있어요. 예를 들어 `example.com/user`는 유저 서비스로, `example.com/order`는 주문 서비스로 보내는 경우죠. 이때 가장 빈번하게 발생하는 문제가 바로 경로 불일치 문제예요.

대부분의 마이크로서비스는 `/` 경로를 기준으로 API를 설계해요. 하지만 인그레스 규칙에서 `/user` 경로를 지정하면, 컨트롤러는 실제 서비스에 `/user/profile` 같은 요청을 그대로 전달해요. 서비스 입장에서는 `/user`라는 경로가 없기 때문에 404 에러가 발생하게 되죠. 이를 해결하기 위해 Nginx Rewrite Annotation을 사용해야 해요. `nginx.ingress.kubernetes.io/rewrite-target: /` 설정을 추가하면, 인그레스가 경로를 재작성하여 서비스에는 `/` 경로로 깔끔하게 전달해 줍니다.

STEP 4. SSL/TLS 인증서 자동화 적용하기

실무에서 인증서를 수동으로 관리하는 것은 불가능에 가까워요. 만료 날짜를 놓치는 순간 서비스 전체가 중단될 수 있기 때문이죠. 그래서 우리는 Cert-manager를 활용해 Let’s Encrypt 인증서를 자동으로 발급받고 갱신하는 구조를 구축했어요.

설정 순서는 다음과 같아요. 먼저 Cert-manager를 설치하고, Let’s Encrypt와 통신할 `ClusterIssuer`를 생성해요. 그 다음, Ingress 리소스의 `tls` 섹션에 사용할 Secret 이름을 지정하기만 하면 돼요. 그러면 Cert-manager가 알아서 도메인 소유권을 확인하고 인증서를 발급받아 Kubernetes Secret으로 저장해 줍니다. 이 과정이 완료되면 모든 트래픽은 HTTPS로 안전하게 보호됩니다.

STEP 5. 모니터링 및 트래픽 제어 고도화

인그레스가 안정화되었다면 이제 운영의 묘미를 살릴 차례예요. Nginx Ingress는 매우 강력한 Annotation 기능을 제공해요. 특정 IP의 요청을 차단하거나(Allow/Deny), 초당 요청 수를 제한하여 서비스 폭주를 막는(Rate Limiting) 기능이 대표적이죠.

또한, 새로운 버전을 배포할 때 사용자 일부에게만 트래픽을 흘려보내는 **Canary 배포**도 가능해요. `nginx.ingress.kubernetes.io/canary: “true”`와 같은 설정을 통해 트래픽의 10%만 새 버전으로 보내며 안정성을 검증할 수 있어요. 이런 기능들은 서비스 중단 없는 운영을 위한 필수적인 도구들이에요.

자주 하는 실수와 해결법 및 FAQ

자주 하는 실수와 해결법

❌ 실수: Ingress 리소스를 만들었는데 404 Not Found가 떠요.
왜 발생하는가: 대부분 인그레스 컨트롤러가 설치되지 않았거나, Ingress 리소스의 `ingressClassName`이 컨트롤러의 설정과 일치하지 않기 때문이에요.
✅ 해결법: `kubectl get ingressclass`로 사용 가능한 클래스 명을 확인하고, Ingress 리소스 설정에 이를 정확히 명시하세요.

❌ 실수: 경로(Path) 설정을 했는데 애플리케이션에서 API를 못 찾아요.
왜 발생하는가: 앞서 언급했듯이 `/api` 경로로 들어온 요청이 서비스에 `/api` 그대로 전달되기 때문이에요.
✅ 해결법: Nginx의 `rewrite-target` 어노테이션을 사용하여 경로를 재작성해 주세요.

❌ 실수: SSL 인증서를 적용했는데 브라우저에서 보안 경고가 떠요.
왜 발생하는가: 인증서가 정상적으로 발급되지 않았거나, Ingress 설정에서 `tls` 섹션의 `secretName`이 실제 생성된 Secret 이름과 다를 수 있어요.
✅ 해결법: `kubectl get secret`으로 인증서가 있는지 확인하고, Cert-manager의 로그를 살펴 인증서 발급 과정을 추적하세요.

❌ 실수: 특정 서비스로 가는 트래픽이 너무 느리거나 끊겨요.
왜 발생하는가: 인그레스 컨트롤러의 리소스(CPU/Memory)가 부족하거나, 컨트롤러 노드에 네트워크 병목이 생겼을 가능성이 커요.
✅ 해결법: 컨트롤러 포드의 리소스 제한(Limit)을 높이고, 모니터링 도구를 통해 CPU 사용률을 확인하세요.

❌ 실수: 서비스가 여러 개인데 하나만 접속이 안 돼요.
왜 발생하는가: 해당 서비스의 `Service` 이름이나 포트(Port) 번호가 Ingress 설정과 일치하지 않을 확률이 높아요.
✅ 해결법: Ingress 리소스의 `backend` 설정에 적힌 서비스 이름과 포트가 `kubectl get svc` 결과와 정확히 일치하는지 대조하세요.

자주 묻는 질문

Q. 인그레스와 API 게이트웨이의 차이점은 무엇인가요?

인그레스는 주로 L7 계층에서의 단순한 라우팅과 SSL 종단점에 집중하는 반면, API 게이트웨이는 인증/인가, 요청 변환, 복잡한 트래픽 제어 등 훨씬 더 고도화된 기능을 제공해요. 단순한 서비스 노출이 목적이라면 인그레스로 충분하지만, 복잡한 API 생태계를 관리해야 한다면 API 게이트웨이를 고려하는 것이 좋아요.

Q. 인그레스 컨트롤러를 여러 개 운영해도 되나요?

네, 가능해요. 예를 들어, 외부 트래픽용 Nginx 컨트롤러와 내부 망 전용 컨트롤러를 별도로 운영하여 보안 계층을 분리할 수 있어요. 다만, 관리 포인트가 늘어나므로 운영 효율성을 잘 따져봐야 해요.

Q. 클라우드 제공업체의 로드밸런서(ALB 등)를 쓰는 게 더 좋지 않나요?

클라우드 네이티브한 환경에서는 매우 편리하고 관리가 쉽다는 장점이 있어요. 하지만 커스텀 설정(특정 헤더 조작, 복잡한 Rewrite 규칙 등)이 필요할 때는 오픈소스 기반의 Nginx 컨트롤러가 훨씬 유연하고 강력한 기능을 제공해요.

Q. 인그레스 설정이 변경되면 서비스에 영향이 가나요?

인그레스 리소스만 수정하는 경우에는 트래픽이 잠시 끊기지는 않지만, 설정 오류(오타 등)가 포함된 상태로 적용되면 즉시 해당 경로로의 접속이 실패하게 돼요. 따라서 반드시 검증 과정을 거친 후 적용해야 해요.

성공적인 인그레스 운영을 위한 마지막 점검

인그레스 도입은 단순히 비용을 아끼는 수단을 넘어, 우리 클러스터의 트래격 관리 체계를 한 단계 업그레이드하는 과정이에요. 처음에는 설정 하나하나가 어렵고 실수도 많겠지만, 한 번 구조를 잘 잡아두면 운영의 피로도가 획기적으로 줄어드는 것을 경험할 수 있을 거예요.

오늘 배운 내용을 바탕으로 지금 바로 실습 환경에서 인그레스 컨트롤러를 설치해 보세요. 작은 규모의 클러스터에서 직접 경로를 나누고 인증서를 적용해 보는 경험이 실무에서의 실수를 줄여줄 거예요.

만약 설정을 적용하다가 예상치 못한 404 에러나 인증서 오류를 만난다면, 주저하지 말고 댓글로 질문을 남겨 주세요. 함께 고민하면 해결책을 찾을 수 있을 거예요. 여러분의 안정적인 쿠버네티스 운영을 응원해요!

관련해서 더 공부하고 싶다면 아래 글들도 함께 읽어보시는 것을 추천드려요.
– 쿠버네티스 인그레스 기본 개념 정리
– 클러스터 구축 입문: 네트워크부터 시작하기