API Gateway를 제거하고 공인 LoadBalancer로 직접 노출하기

진행 기간: 2026.06 ~ 2026.08

OCR API 서비스가 API Gateway 뒤에 있었는데, 그걸 제거하고 쿠버네티스 앞에 공인 LoadBalancer를 직접 붙이는 작업을 맡았다. 시작할 때 나는 Ingress가 뭔지도 제대로 몰랐다. "요청이 들어오면 서버가 응답한다" 정도로 알고 있었고, 그 사이에 몇 겹이 끼어 있는지는 감이 없었다.

세 달 걸렸다. 예상보다 오래 걸린 이유는 Gateway가 조용히 해주던 일이 생각보다 많았고, 제거한 자리를 하나씩 채우다 보니 매번 처음 보는 계층에 걸렸기 때문이다. 이 글은 그 과정의 기록이다. 개별 기술 내용은 따로 정리해 뒀으니 여기서는 무엇을 왜 했고 어디서 막혔는지에 집중한다.

왜 제거했나

이유는 단순했다. 요청 크기 5MB 제한이 OCR 서비스에 맞지 않았다.

OCR은 이미지를 받는 서비스다. 고화질 스캔본이나 여러 장짜리 문서는 10MB를 넘는 일이 흔한데, Gateway 단에서 먼저 잘려서 413이 났다. 앱은 요청을 구경도 못 하고, 고객에게는 우리 표준 응답 형식이 아닌 Gateway의 에러가 나갔다.

Gateway 설정으로 늘릴 수 없는 제약이라 앞단을 바꾸는 수밖에 없었다. 그래서 nginx Ingress Controller를 공인 LoadBalancer 뒤에 직접 두는 방향으로 정했다.

Gateway가 대신 해주던 것들

막상 옮기려니 Gateway가 맡고 있던 일이 드러났다.

경로 변환이 23건 있었다. 고객이 호출하는 짧은 경로와 내부 서비스의 실제 경로가 달랐고, Gateway가 그 사이를 매핑하고 있었다. 예를 들어 고객은 /v1.0/appkeys/{key}/general로 부르지만 실제 백엔드는 /api/general-recognizer/api/v1.0/... 이런 식이다.

이걸 nginx로 옮기면서 23건을 그대로 옮기지 않고 정규식 4패턴에 catch-all 하나로 수렴시켰다. 경로에 규칙성이 있어서 가능했고, 항목이 23개에서 5개로 줄면서 유지보수 대상도 줄었다. catch-all을 둔 이유는 매칭 안 된 요청이 nginx 기본 404 HTML을 받는 대신 우리 표준 응답 형식으로 나가게 하기 위해서다.

요청 크기 제한이 한 겹이 아니었다. Gateway를 제거하면 5MB 문제가 풀릴 줄 알았는데, 크기를 제한하는 지점이 네 군데였다. 어느 하나만 낮아도 거기서 잘린다. 하나씩 찾아 올렸다.

HTTPS를 누가 끝내느냐도 정해야 했다. Gateway가 하던 일이라 신경 쓴 적이 없었는데, 이제 우리가 정해야 했다. 인증서 관리를 한곳에 모으려고 nginx에서 종료하기로 했는데, 이 결정이 나중에 예상 못 한 문제를 만들었다. 뒤에 다시 나온다.

이 세 가지의 상세는 API Gateway를 제거한 자리 채우기에 정리했다.

막혔던 지점들

LoadBalancer를 선언했는데 안 만들어졌다

Service를 type: LoadBalancer로 선언하면 클라우드가 LB를 만들어준다고 배웠다. 그런데 EXTERNAL-IP가 <pending>에서 며칠을 움직이지 않았다.

파고들어 보니 원인이 두 개였다. 하나는 클라우드 설정에 서브넷 정보가 없어서 LB를 어디에 만들지 자동으로 못 찾는 것이었고, 이건 명시해서 우회했다.

나머지 하나가 진짜였다. 클러스터를 만든 사람이 퇴사하면서 그 사람의 권한으로 동작하던 인증 경로가 끊겨 있었다. 관리형 쿠버네티스가 클라우드 자원을 만들 때 누구의 권한을 쓰는지 그때 처음 알았다. LB 발급뿐 아니라 볼륨 생성, 클러스터 업그레이드까지 몇 달에 걸쳐 하나씩 죽어 가고 있던 상태였다.

코드도 네트워크도 아닌 사람에 묶인 인프라 의존성이었다. 이건 예상 밖이었고, 배운 것도 가장 많았다.

선언한 LoadBalancer가 안 만들어질 때: 어디서부터 격리해 들어갔는지
관리형 클러스터는 누구의 권한으로 클라우드를 만지는가: 원인과 구조

IP 접근 제한이 조용히 뚫려 있었다

개발·검증 환경은 사내에서만 접근돼야 해서 nginx에 IP 허용 목록을 걸어 뒀다. 설정은 정상으로 보였다. 애노테이션도 붙어 있고 kubectl로 봐도 IP 목록이 멀쩡히 들어 있었다.

그런데 허용 목록에 없는 IP로 HTTPS 호출을 했더니 200이 왔다.

원인은 앞서 내린 결정에서 왔다. 인증서 관리를 편하게 하려고 TLS를 nginx에서 끝내기로 했고, 그러려면 LB가 암호화된 트래픽을 열어보지 않고 그대로 넘겨야 한다. 그런데 그렇게 하면 LB가 실제 클라이언트 IP를 헤더에 적어줄 수 없다. 거기에 요청이 노드를 거치며 출발지 주소가 내부 대역으로 바뀌는 동작이 겹쳤고, 하필 그 내부 대역이 허용 목록에 들어 있었다.

결국 모든 외부 요청이 내부 주소로 위장해서 통과하고 있었다. 애플리케이션 계층의 편의를 위한 결정이 네트워크 계층의 전제를 깬 사례다.

두 가지를 크게 배웠다.

• 보안 설정은 적용 여부가 아니라 차단 동작으로 확인해야 한다. 설정 파일은 의도대로 작성돼 있었지만 실제 요청은 차단되지 않았다.
• 자기 IP로 테스트하면 아무것도 증명되지 않는다. 처음엔 한 환경에서 접속이 되길래 "열려 있구나" 판단했는데, 알고 보니 내 IP가 그 환경 허용 목록에 있었다. 목록에 없는 다른 환경과 비교해서야 진짜 문제가 드러났다.

고칠 때는 방어 지점을 LB 계층으로 올렸다. LB는 주소가 바뀌기 전 단계라 진짜 클라이언트 IP를 보고, HTTP·HTTPS 양쪽에서 동작한다.

IP whitelist가 조용히 뚫려 있었다: 클라이언트 IP가 사라지는 구간

컨트롤러 하나 추가하는 게 간단하지 않았다

기존에 사내용 nginx 컨트롤러가 있었고 거기에 외부용을 하나 더 붙이는 작업이었다. "차트 만들고 배포하면 끝"일 줄 알았는데 아니었다.

가장 아찔했던 건 admission webhook이다. 새 Ingress를 만들면 검증하는 장치인데, 이게 네임스페이스나 클래스로 격리되지 않고 클러스터 전체의 요청을 가로챈다. 외부용 컨트롤러의 webhook이 잘못되면 사내용 Ingress 적용까지 막히는 구조였다. 그래서 외부용은 webhook을 끄는 선택을 했다.

ingress-nginx 운영에서 부딪힌 디테일들: webhook, 배치, 리소스 사양
쿠버네티스 Admission 단계: 왜 하필 저장 직전인가

검증을 어떻게 했나

경로를 통째로 바꾸는 작업이라 "되는 것 같다"로 넘길 수 없었다. 두 가지를 만들었다.

등가성 비교 스크립트. 같은 요청을 Gateway 경로와 새 경로 양쪽에 보내 응답을 비교한다. 전수 확인은 인증 단계에서 실패하도록 더미 키를 써서 모델 서버에 부작용 없이 라우팅과 응답 형식만 본다. 실제 성공 응답까지 보는 깊은 비교는 부작용 없는 두 건만 유효한 자격증명으로 돌린다.

부하 테스트. 크기 한도를 올렸으니 큰 요청이 몰릴 때 메모리가 버티는지 봐야 했다. 단발 요청 동시 실행으로는 지속 부하와 메모리 추이를 볼 수 없어서 k6로 단계적으로 동시성을 올리며 유지하는 시나리오를 만들었다. 이 과정에서 실패는 없지만 응답 시간이 크게 늘어나는 구간을 찾았다: 클라이언트 타임아웃 설정에 따라 체감 장애가 될 수 있는 수준이었다.

내 기여와 협업

인프라 변경은 대부분 내가 진행했다. 외부 전용 컨트롤러 추가, LB 발급과 IP 고정, 경로 변환 이전, HTTPS 적용, 환경별 확대, IP 접근 제어 이관까지다. 검증 도구도 직접 만들었다.

혼자 한 건 아니다. 클러스터 신원 문제는 플랫폼 팀 문의로 넘겨서 답을 받았다: 내가 격리할 수 있는 범위는 "클러스터 내부 인증 경로가 죽었다"까지였고, 그 너머는 플랫폼 쪽 영역이었다. 어디까지가 내 몫이고 어디부터 넘겨야 하는지 판단하는 것도 이번에 배운 것 중 하나다.

인증서는 다른 팀이 이미 발급받아 쓰던 와일드카드 인증서를 담당자 확인 후 재사용했다. OCR용으로 새로 발급받는 대신 기존 자산을 쓰는 쪽이 관리 지점을 늘리지 않는다고 판단했다.

회고

계층을 모르면 디버깅이 안 된다. 시작할 때 나는 Ingress도 몰랐는데, 결국 L4와 L7의 차이, TLS를 어디서 끝내는지, 출발지 주소가 어디서 바뀌는지까지 알아야 문제를 풀 수 있었다. 추상화 위에서만 일하다가 아래를 봐야 하는 순간이 왔고, 그때 밑천이 드러났다.

한 계층의 결정이 다른 계층의 전제를 깬다. 인증서 관리를 편하게 하려는 선택이 IP 기반 접근 제어를 무너뜨렸다. 결정할 때는 그 계층 안에서만 생각했고, 부작용은 두 달 뒤에 나타났다. 지금은 "이 변경이 다른 계층에서 무엇을 전제하고 있었나"를 한 번 더 묻는다.

작업 순서를 무중단 구간과 순단 구간으로 나눈 게 도움이 됐다. LB 발급이나 DNS 연결처럼 기존 트래픽에 영향 없는 것을 먼저 몰아서 진행하고, 순단이 따르는 작업은 분리했다. 운영 중인 서비스를 건드리는 작업에서는 이 구분이 진행 속도를 좌우한다.

운영 환경까지 전환을 마쳤다. 기존 경로는 의도적으로 함께 열어 두었다. 고객이 호출 주소를 바꿔야 하는 변경이라 충분한 유예를 두기로 했다.

이번에 배운 개념들

작업하면서 처음 제대로 본 것들을 따로 정리해 뒀다. 순서대로 읽으면 이 글의 배경이 채워진다.

네트워크

• L4와 VIP: L4가 왜 헤더를 못 만지는지
• HTTPS는 어떻게 안전한가: TLS를 어디서 끝내느냐의 의미

쿠버네티스

• 외부 트래픽은 어떻게 Pod까지 닿는가: 전체 경로
• Helm과 ArgoCD로 GitOps 하기: 새 컴포넌트를 추가하는 흐름
• Graceful Shutdown: 배포 중 요청이 끊기지 않으려면

devops/k8s 폴더에 이 작업을 순서대로 따라가는 연재로 묶어 뒀다.