MSA 초기 단계, 굳이 클라우드 API Gateway가 필요할까?

Nginx vs AWS API Gateway vs GCP API Gateway — 우리 팀이 Nginx를 선택한 이유

최근 물류 센터 자동화 프로젝트를 진행하면서, AI 추론(Inference) 서버와 일반 백엔드(Data Ops/Orchestrator) 서버를 물리적으로 분리하는 작업을 진행했습니다. GPU가 필요한 무거운 작업과 일반적인 CPU 작업을 나누어 자원 효율을 극대화하기 위함입니다.

하지만 이렇게 서버를 분리하고 나니 진입점(Entry Point) 문제가 발생했습니다.

---

1. 직면한 문제: 클라이언트가 너무 많은 주소를 알아야 한다

서버를 기능별로 분리하니 네트워크 구성이 아래와 같이 되었습니다.

서버	역할	주소
GPU 서버	Inference	192.168.1.101:8001
CPU 서버	Data Ops	192.168.1.100:8002
CPU 서버	Orchestrator	192.168.1.100:8003

이 상태로 백엔드(WMS)나 프론트엔드가 각 서버에 직접 요청을 보내게 되면 다음과 같은 문제들이 생깁니다.

• CORS Hell — 포트가 다르니 브라우저는 다른 출처로 인식합니다.
• 보안 인증서 관리 — 각 포트/서버마다 SSL 인증서를 따로 관리해야 합니다.
• 결합도 증가 — 서버 IP가 바뀌거나 구조가 변경되면 클라이언트 코드도 전부 수정해야 합니다.

결국 단일 진입점(Single Entry Point) 이 필요했습니다. 이때 고민하게 되는 것이 *"Nginx로 직접 구축할 것이냐, 클라우드 벤더의 API Gateway를 쓸 것이냐"* 입니다.

---

2. 선택지 비교: Nginx vs AWS API Gateway vs GCP API Gateway

단일 진입점 역할을 수행할 수 있는 대표적인 3가지 방법을 비교해 보았습니다.

① Nginx (Reverse Proxy)

가장 전통적이고 강력한 웹 서버이자 프록시 서버입니다.

• 장점: 가볍고 빠르며 무료(오픈소스). 설정 파일(nginx.conf) 하나로 라우팅, 로드밸런싱, SSL 종료 처리가 가능합니다.
• 단점: 직접 서버에 설치하고 관리해야 합니다. 인증이나 복잡한 트래픽 제어(Throttling)를 구현하려면 손이 많이 갑니다.

② AWS API Gateway

AWS의 완전 관리형 서비스입니다.

• 장점: 서버 관리가 필요 없음(Serverless). AWS Lambda와 찰떡궁합이며, API 키 발급·요청량 제한(Throttling)·모니터링 대시보드 등을 클릭 몇 번으로 구성할 수 있습니다.
• 단점: 트래픽이 많아지면 비용이 꽤 나옵니다. Nginx에 비해 단순 프록시 속도는 미세하게 느릴 수 있습니다(Latency).

③ GCP API Gateway

구글 클라우드의 관리형 서비스입니다. 내부적으로는 Envoy Proxy 기반입니다.

• 장점: Cloud Run, App Engine, Cloud Functions와 연동이 매우 쉽습니다. OpenAPI 사양(Swagger)을 업로드하여 설정을 관리하므로 문서화와 설정이 일원화됩니다.
• 단점: AWS API Gateway에 비해 기능적 성숙도가 조금 낮고 커뮤니티 레퍼런스가 적은 편입니다. 엔터프라이즈 급에서는 Apigee를 쓰라고 유도하는 경향이 있습니다.

---

3. 한눈에 보는 비교표

특징	Nginx	AWS API Gateway	GCP API Gateway
유형	Self-Hosted (직접 설치)	Fully Managed (완전 관리형)	Fully Managed (완전 관리형)
주요 역할	Reverse Proxy, Load Balancer	API 관리, 인증, 트래픽 제어	API 관리, Serverless 게이트웨이
비용	무료 (기존 서버 자원 사용)	호출 횟수당 과금 (은근 비쌈)	호출 횟수당 과금
인증 처리	직접 구현 필요	Cognito, Lambda Authorizer 연동	Firebase Auth, Service Account 연동
설정 방식	conf 파일 수정	AWS 콘솔 / Terraform	OpenAPI Spec (YAML)
추천 대상	초기 스타트업, 비용 민감, 단순 라우팅	Serverless 중심, 복잡한 API 관리	GCP 생태계, Cloud Run 중심

---

4. 우리의 선택: "일단 Nginx로 충분하다"

저희 팀은 현재 단계에서 Nginx를 선택했습니다. 이유는 명확합니다.

• Over-Engineering 방지 — 현재 우리에게 필요한 건 거창한 API 관리(키 발급, 사용량 제한)가 아니라, 단순히 요청 경로에 따라 다른 포트로 넘겨주는 라우팅 기능뿐입니다.
• 비용 효율 — 이미 ECS 인스턴스가 떠 있는 상태에서 Nginx 컨테이너 하나 더 띄우는 건 추가 비용이 0원입니다.
• 속도 — 내부망에서의 단순 프록시 처리는 Nginx가 가장 빠르고 효율적입니다.

적용한 아키텍처

경로(Path) 기반 라우팅을 아래와 같이 구성했습니다.

https://api.xxx.com/api/v1/inspection/*  → GPU 서버 (8001)
https://api.xxx.com/api/v1/images/*      → Data Ops (8002)
https://api.xxx.com/api/v1/jobs/*        → Orchestrator (8003)

실제 적용한 Nginx 설정

server {
    listen 443 ssl;
    server_name api.cv-inspection.example.com;

    # SSL 설정 생략...

    # 1. AI 추론 요청 → GPU 서버
    location /api/v1/inspection {
        proxy_pass http://192.168.1.101:8001;
        proxy_read_timeout 300s;  # AI 모델 추론 시간 고려
    }

    # 2. 이미지 데이터 조회 → Data Ops 서버
    location /api/v1/images {
        proxy_pass http://127.0.0.1:8002;
    }

    # 3. 작업 상태 관리 → Orchestrator 서버
    location /api/v1/jobs {
        proxy_pass http://127.0.0.1:8003;
    }
}

---

5. 결론

*"AWS나 GCP의 API Gateway가 더 최신 기술 아니야?"* 라고 생각할 수 있지만, 기술 선택의 기준은 언제나 "현재 우리의 문제 해결에 적합한가?" 여야 합니다.

상황	추천
서버리스(Lambda/Cloud Functions)를 적극적으로 쓴다면	☁️ Cloud API Gateway
외부 파트너에게 API를 유료로 제공하고 트래픽 제한이 필요하다면	☁️ Cloud API Gateway
내부 서비스 간 라우팅과 단일 진입점이 목적이라면	🟢 Nginx

기술 부채는 나쁜 코드를 짤 때만 쌓이는 게 아닙니다. 필요 이상으로 복잡한 인프라를 도입하는 것 또한 미래의 부채가 될 수 있습니다. 우리는 가장 심플하고 확실한 방법인 Nginx로 이 문제를 해결했습니다.