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로 이 문제를 해결했습니다.
