[IT-정보] 인그레스 운영 사례 분석: 실제 서비스 적용기와 개선 포인트 – 실무 엔지니어가 겪은 문제와 해결 과정

트래픽 폭증과 비용 폭탄, 인그레스가 필요했던 순간

신규 마이크로서비스가 하나씩 추가될 때마다 클라우드 비용 고지서를 보는 마음이 무거워졌던 기억이 있어요. 처음에는 서비스마다 로드밸런서(LoadBalancer)를 하나씩 할당하며 아주 편하게 운영했거든요. 서비스가 5개일 때는 아무런 문제가 없었지만, 서비스가 20개가 넘어가면서 상황이 완전히 달라졌어요.

매달 청구되는 클라우드 비용은 기하급수적으로 늘어났고, 각 로드밸런서마다 설정해야 하는 도메인과 인증서 관리도 엉망이 되어버렸어요. 인프라 팀은 쏟아지는 요청에 대응하느라 정신이 없었고, 개발팀은 서비스 하나를 배포할 때마다 네트워크 설정을 기다려야 하는 답답한 상황이었죠. 단순히 서비스를 노출하는 것만으로도 관리 비용과 운영 복잡도가 감당할 수 없는 수준에 도달한 거예요.

이런 혼란 속에서 저희 팀이 선택한 돌파구가 바로 인그레스(Ingress) 운영이었어요. 인그레스를 도입하면 하나의 공인 IP와 하나의 로드밸런서만으로도 수많은 서비스를 도메인과 경로에 따라 깔끔하게 나누어 관리할 수 있거든요. 비용은 획기적으로 줄이면서도, 운영 효율성은 극대화할 수 있는 아주 강력한 도구예요.

이번 글에서는 저희 팀이 실제로 인그레스를 어떻게 도입했고, 어떤 기술적 결정들을 내렸는지 아주 생생하게 들려드릴게요. 단순히 이론적인 설명이 아니라, 실무에서 마주쳤던 날 것 그대로의 경험담을 담았어요.

이번 글에서 함께 살펴볼 내용들

• 로드밸런서 방식에서 인그레스 방식으로 전환하게 된 결정적 계기
• 인그레스 컨트롤러 선택 기준과 실제 구성 과정
• 도입 후 비용 절감 수치와 트래픽 관리의 변화
• 실무에서 가장 많이 겪는 설정 오류와 해결 방법

인그레스 도입 전, 반드시 짚고 넘어가야 할 기초 지식

인그레스를 무작정 설치한다고 해서 모든 문제가 해결되지는 않아요. 오히려 잘못된 설계는 트래픽 병목 현상을 일으키거나 보안 취약점을 만들 수도 있죠. 그래서 본격적인 적용에 앞서, 현재 우리 클러스터의 네트워크 구조를 정확히 파악하는 것이 무엇보다 중요해요.

가장 먼저 결정해야 할 것은 어떤 방식으로 외부 트래픽을 내부 서비스로 전달할 것인가에 대한 기준이에요. 쿠버네티스에는 크게 세 가지 방식이 있는데, 각각의 장단점이 뚜렷해요. 무조건 인그레스가 정답이라고 생각하기보다, 현재 서비스의 규모와 예산을 고려해서 선택해야 해요.

저희 팀의 경우, 서비스가 급격히 늘어나는 시점이었기 때문에 비용 효율성과 경로 기반 라우팅(Path-based routing)이 가능한 인그레스 방식을 선택하기로 했어요. 단순히 IP 하나를 공유하는 것을 넘어, api.example.com은 API 서비스로, web.example.com은 프론트엔드 서비스로 아주 정교하게 나누고 싶었거든요.

도입을 결정했다면 다음 단계로 인그레스 컨트롤러를 골라야 해요. 가장 대중적인 것은 Nginx Ingress Controller이지만, 최근에는 트래픽 제어 기능이 강력한 Traefik이나 대규모 환경에 적합한 Kong 같은 대안들도 많이 쓰이고 있어요. 각 컨트롤러가 제공하는 기능과 우리 팀의 운영 역량을 비교해 보는 과정이 반드시 선행되어야 해요.

인그레스 구축부터 실제 운영까지의 5단계 여정

준비가 끝났다면 이제 실제로 인그레스를 클러스터에 올리고 운영할 차례예요. 저희 팀은 가장 안정적이고 커뮤니티가 활발한 Nginx Ingress Controller를 기반으로 구축을 진행했어요. 단순히 설치만 하는 게 아니라, 실제 트래픽을 견딜 수 있는 구조를 만드는 것이 핵심이었죠.

STEP 1. 인그레스 컨트롤러 설치와 초기 설정

가장 먼저 한 일은 Helm을 사용하여 Nginx Ingress Controller를 설치하는 것이었어요. 단순히 기본값으로 설치하기보다는, 우리 클러스터의 환경에 맞춰 리소스 제한(Resources Limit)과 수평 확장(HPA) 설정을 꼼꼼하게 맞췄어요. 트래픽이 갑자기 몰릴 때 컨트롤러 자체가 죽어버리면 모든 서비스가 중단되는 대참사가 발생할 수 있기 때문이에요.

특히 클라우드 환경에서는 컨트롤러를 띄울 때 로드밸런서 타입을 지정해야 하는데, 저희는 하나의 로드밸런서가 컨트롤러의 입구 역할을 하도록 설정했어요. 이렇게 하면 클라우드 비용을 최소한으로 유지하면서 수많은 서비스로 트래픽을 뿌려줄 수 있는 기반이 마련돼요. 설치 직후에는 반드시 kubectl get pods와 kubectl get svc를 통해 컨트롤러가 정상적으로 외부 IP를 할당받았는지 확인하는 절차를 거쳤어요.

STEP 2. 호스트 및 경로 기반 라우팅 설계

이제 본격적으로 서비스들을 연결하는 인그레스 리소스(Ingress Resource)를 작성해야 해요. 저희는 크게 두 가지 전략을 섞어서 사용했어요. 첫 번째는 호스트 기반 라우팅이에요. api.myapp.com과 admin.myapp.com처럼 도메인 자체를 분리하여 관리하는 방식이죠. 이렇게 하면 보안 정책을 적용하기가 훨씬 수월해요. API 서버에는 엄격한 인증을 걸고, 관리자 페이지에는 특정 IP 대역만 접속할 수 있도록 제한할 수 있거든요.

두 번째는 경로 기반 라우팅이에요. 하나의 도메인 안에서 /v1/users, /v1/orders 같은 경로에 따라 서로 다른 백엔드 서비스로 연결해 주는 방식이죠. 이때 가장 주의해야 할 점은 경로 매칭(Path Matching) 규칙이에요. 예를 들어, 경로를 `/api`로 설정했을 때 백엔드 서비스가 `/api`를 포함한 요청을 처리할 수 있는지, 아니면 앞의 `/api`를 떼어내고(Rewrite) 전달해야 하는지를 명확히 결정해야 해요. 저희는 Nginx의 `rewrite-target` 어노테이션을 적극적으로 활용해서 이 문제를 해결했어요.

STEP 3. SSL/TLS 인증서 자동화 적용

서비스가 운영 단계로 넘어가면 HTTPS 적용은 선택이 아닌 필수예요. 하지만 수십 개의 서비스마다 인증서를 수동으로 발급하고 갱신하는 건 불가능에 가까운 일이죠. 그래서 저희는 Cert-manager를 도입했어요. Let’s Encrypt를 사용하여 인증서를 자동으로 발급받고, 만료되기 전에 알아서 갱신해 주는 시스템을 구축한 거예요.

인그레스 설정 파일에 `tls` 섹션을 추가하고, Cert-manager가 관리하는 Secret 이름을 적어주기만 하면 모든 과정이 끝나요. 이렇게 자동화를 해두니 인증서 만료로 서비스가 끊기는 사고를 원천 차단할 수 있었어요. 보안팀에서도 수동 관리 방식보다 훨씬 신뢰할 수 있다고 만족해하셨죠.

STEP 4. 어노테이션을 활용한 고급 트래픽 제어

단순한 라우팅만으로는 실제 운영 환경의 다양한 요구사항을 충족하기 어려워요. 그래서 Nginx Ingress가 제공하는 다양한 어노테이션(Annotations) 기능을 적극적으로 사용했어요. 대표적으로 클라이언트의 요청이 너무 길거나 느릴 때를 대비한 타임아웃 설정, 그리고 초당 요청 수를 제한하는 Rate Limiting 기능이 있어요.

예를 들어, 특정 API 서비스가 과부하에 걸리지 않도록 초당 요청 횟수를 제한하는 설정을 인그레스 레벨에서 적용할 수 있어요. 이는 백엔드 서비스의 코드를 수정하지 않고도 인프라 단에서 즉시 대응할 수 있다는 점에서 엄청난 메리트가 있어요. 또한, 특정 경로에 대해서만 커스텀 헤더를 추가하거나 쿠키를 제어하는 등의 정교한 작업도 가능해졌어요.

STEP 5. 관측성(Observability) 확보와 모니터링

마지막 단계는 인그레스가 트래픽을 잘 전달하고 있는지 감시하는 거예요. 인그레스가 블랙박스가 되면 문제가 생겼을 때 어디가 고장 났는지 찾기가 너무 힘들거든요. 저희는 Prometheus와 Grafana를 연동하여 인그레스 컨트롤러의 주요 지표를 시각화했어요.

요청 성공률(2xx), 클라이언트 오류(4xx), 서버 오류(5xx)의 비율을 실시간으로 모니터링하고, 특정 임계치를 넘으면 슬랙(Slack)으로 알람이 오도록 설정했어요. 특히 502 Bad Gateway나 504 Gateway Timeout이 급증하는 상황을 즉각적으로 인지할 수 있게 되어, 장애 대응 시간이 이전보다 훨씬 단축되었어요. 이제는 트래픽의 흐름이 눈에 보이기 시작한 거죠.

자주 하는 실수와 해결법 및 자주 묻는 질문

인그레스를 운영하다 보면 이론과 실제 사이의 괴리 때문에 당황스러운 순간이 정말 많아요. 저희 팀이 직접 겪으며 정리한 실무 실수 사례들을 공유해 드릴게요. 이 내용만 숙지해도 삽질 시간을 절반 이상 줄이실 수 있을 거예요.

자주 하는 실수와 해결법

• ❌ 실수: 404 Not Found 에러가 발생하는데 경로는 맞게 설정했어요.
  왜: 인그레스의 경로 규칙과 백엔드 서비스가 기대하는 경로가 일치하지 않기 때문이에요. 예를 들어, 인그레스에는 /api로 설정했는데, 백엔드 서비스는 /부터 시작하는 경로를 기다리고 있다면 404가 발생해요.
  ✅ 해결법: Nginx의 nginx.ingress.kubernetes.io/rewrite-target 어노테이션을 사용해서 경로를 재작성해 보세요.
• ❌ 실수: 502 Bad Gateway 에러가 계속 떠요.
  왜: 인그레스 컨트롤러가 요청을 보낼 백엔드 포드가 준비되지 않았거나, 서비스의 Selector가 포드와 일치하지 않을 때 발생해요.
  ✅ 해결법: kubectl get endpoints 명령어로 해당 서비스에 연결된 IP 주소가 제대로 떠 있는지 반드시 확인해 보세요.
• ❌ 실수: SSL 인증서를 적용했는데 브라우저에서 경고가 떠요.
  왜: TLS Secret 이름이 인그레스 설정의 secretName과 다르거나, 인증서 체인이 불완전하기 때문이에요.
  ✅ 해결법: Cert-manager가 생성한 Secret이 정확한 네임스페이스에 있는지, 그리고 이름이 일치하는지 다시 한번 대조해 보세요.
• ❌ 실수: 특정 서비스에만 트래픽이 몰리는데 컨트롤러 전체가 느려져요.
  왜: 인그레스 컨트롤러가 하나의 거대한 리소스를 공유하고 있기 때문이에요.
  ✅ 해결법: 트래픽이 매우 많은 서비스는 별도의 인그레스 컨트롤러(두 번째 컨트롤러)를 띄워서 물리적으로 분리하는 것을 고려해 보세요.
• ❌ 실수: 설정 파일을 수정했는데 반영이 안 돼요.
  왜: YAML 문법 오류로 인해 인그레스 리소스가 업데이트되지 않았을 가능성이 커요.
  ✅ 해결법: kubectl describe ingress [이름] 명령어를 통해 이벤트 로그를 확인해서 어떤 부분에서 에러가 났는지 파악하세요.

자주 묻는 질문

Q. 인그레스와 인그레스 컨트롤러의 차이점이 정확히 무엇인가요?

인그레스는 ‘어떤 규칙으로 트래픽을 보낼 것인가’를 적어놓은 설계도(Rule)이고, 인그레스 컨트롤러는 그 설계도를 보고 실제로 트래픽을 배달하는 집행관(Executor)이라고 생각하시면 돼요. 설계도만 있다고 배달이 되는 건 아니니까요.

Q. 서비스마다 로드밸런서를 쓰는 게 더 안전하지 않을까요?
보안 측면에서는 서비스마다 개별 로드밸런서를 두는 것이 격리 수준이 높지만, 관리 포인트가 너무 많아진다는 단점이 있어요. 인그레스는 컨트롤러 수준에서 화이트리스트 IP 설정이나 WAF(Web Application Firewall) 연동을 통해 충분히 높은 수준의 보안을 유지할 수 있어요.

Q. 인그레스 컨트롤러를 여러 개 운영할 수 있나요?
네, 가능해요! 예를 들어, 일반 서비스용 컨트롤러와 결제/인증 같은 민감한 서비스용 컨트롤러를 별도로 운영하여 자원을 분리하고 보안을 강화할 수 있어요.

Q. Nginx 외에 추천할 만한 컨트롤러가 있을까요?
클라우드 네이티브한 환경을 선호하신다면 Traefik을 추천해요. 설정이 매우 유연하고 서비스 디스커버리 기능이 뛰어나거든요. 만약 매우 거대한 규모의 엔터프라이즈 환경이라면 Kong이 강력한 기능을 제공할 거예요.

성공적인 인그레스 운영을 위한 마지막 체크리스트

인그레스를 도입하는 것은 단순히 기술 하나를 추가하는 것이 아니라, 우리 서비스의 네트워크 관점을 완전히 바꾸는 과정이에요. 처음에는 복잡해 보일 수 있지만, 한 번 제대로 구축해 놓으면 운영의 질이 차원이 달라지는 것을 느끼실 거예요. 지금까지 다룬 내용들을 바탕으로, 여러분의 클러스터에 적용하기 전 마지막으로 점검해야 할 사항들을 정리해 드릴게요.

오늘 당장 할 수 있는 일은 무엇일까요? 먼저 현재 운영 중인 클러스터에서 사용 중인 로드밸런서의 개수와 비용을 리스트업해 보세요. 그리고 어떤 서비스들을 하나로 묶을 수 있을지 그룹화하는 작업부터 시작해 보시길 바라요. 이번 주 안에는 테스트 환경에 Nginx Ingress Controller를 설치하고, 간단한 서비스 하나를 연결해 보는 실습을 진행해 보세요.

인그레스 적용 과정에서 예상치 못한 설정 오류나 네트워크 이슈로 막히는 부분이 있다면, 혼자 고민하지 마시고 댓글로 질문을 남겨 주세요. 제가 경험한 범위 내에서 최대한 상세히 답변해 드릴게요. 여러분의 성공적인 클러스터 운영을 응원합니다!

함께 읽으면 좋은 글:
👉 쿠버네티스 인그레스 기본 개념 완벽 정리
👉 클러스터 구축 입문: 네트워크 설계부터 시작하기