Spring Cloud Gateway(이하 SCG)는 만능 해결책처럼 자주 언급되지만, 실제로는 빛나는 구성과 운영 부담만 늘리는 구성이 꽤 명확하게 갈립니다. API 게이트웨이는 모든 트래픽이 지나는 진입점이라, 잘 맞으면 큰 이득이지만 안 맞으면 단순 리버스 프록시 일을 무겁게 하는 셈이 됩니다. 그래서 이 글의 질문은 “어떻게 쓰나”가 아니라 “언제 쓰고 언제 쓰지 말아야 하나”입니다.
그래서 SCG는 무슨 문제를 푸는가
핵심은 하나입니다. 서비스 코드 안에 흩어진 공통 관심사를 인프라 계층으로 끌어내는 것. 여러 백엔드 앞에 서서 요청을 적절한 서비스로 라우팅하고, 인증·로깅·CORS·트래픽 제어 같은 횡단 관심사를 한 곳에서 처리합니다. 비즈니스 로직과 횡단 관심사가 분리되면 각 서비스는 자기 일에만 집중할 수 있습니다. 클라이언트가 서비스 주소를 직접 관리하던 것, 인증 코드가 모든 서비스에 중복되던 것, 정책 변경마다 전 서비스를 재배포하던 것이 게이트웨이 한 곳으로 모입니다.
언제 도입하면 빛나는가
효과가 분명한 경우는 크게 넷입니다.
MSA 환경이 첫째입니다. 서비스가 5개 이상으로 늘면 가치가 빠르게 드러납니다. 서비스 디스커버리와 연동하면 uri: lb://order-service처럼 논리적 주소로 라우팅되고, 인스턴스가 늘고 줄어도 게이트웨이가 알아서 로드밸런싱합니다.
인증·인가 중앙화가 둘째입니다. JWT 검증을 게이트웨이에서 일괄 처리하고 사용자 정보를 헤더로 변환해 뒷단에 넘기면, 각 서비스는 인증 라이브러리 의존성이 사라집니다. 신규 서비스에서 보안 검증을 누락할 위험도 없어집니다.
@Component
public class JwtAuthFilter implements GlobalFilter, Ordered {
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
String token = resolveToken(exchange.getRequest());
if (!jwtProvider.isValid(token)) {
exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
return exchange.getResponse().setComplete();
}
ServerHttpRequest mutated = exchange.getRequest().mutate()
.header("X-User-Id", jwtProvider.getUserId(token)).build();
return chain.filter(exchange.mutate().request(mutated).build());
}
@Override public int getOrder() { return -100; }
}
횡단 관심사 일원화가 셋째입니다. Rate Limiting, Circuit Breaker, 공통 로깅을 게이트웨이 필터로 모읍니다. Rate Limiter는 Redis와 연동해 분산 환경에서도 정확히 동작하고, Circuit Breaker는 뒷단 장애가 게이트웨이까지 전파되지 않게 막습니다.
트래픽 제어와 점진적 배포가 넷째입니다. 카나리 배포, 버전별 라우팅(v1·v2 동시 운영)을 Weight 술어로 코드 배포 없이 비율만 바꿔 처리합니다. 레거시를 신규로 옮기는 Strangler Fig 패턴도 같은 방식입니다.
언제 도입하면 손해인가
반대로 다음은 오버엔지니어링입니다. 단일 모놀리식 한 개 앞이라면 게이트웨이는 단순 리버스 프록시일 뿐이라 Nginx나 ALB가 낫습니다. 서비스 2~3개 수준이면 클라이언트가 직접 호출해도 관리되고, 매우 낮은 지연이 핵심이면 게이트웨이가 한 홉을 더하는 게 손해입니다. 특히 “우리도 큰 회사처럼 게이트웨이를 두자” 식 도입은 거의 항상 후회로 이어집니다. 게이트웨이는 해결할 횡단 관심사가 실제로 누적됐을 때 꺼내는 도구입니다.
도입 전, 무엇을 반드시 알아야 하나
가장 큰 함정은 SCG가 Netty 기반 리액티브(WebFlux) 스택이라는 점입니다. 게이트웨이 안에서 블로킹 코드를 호출하면 이벤트 루프가 멈춰 전체 성능이 무너집니다. 필터 안에서 JDBC 조회, RestTemplate 외부 호출, .block() 호출은 금지입니다. DB가 필요하면 R2DBC, 외부 호출은 WebClient를 쓰고, 무거운 로직은 뒷단 서비스로 위임합니다. 원칙은 단순합니다. 게이트웨이는 라우팅과 필터만 한다.
또 하나, 모든 트래픽이 게이트웨이를 거치므로 게이트웨이 자체가 단일 장애점(SPOF)이 됩니다. 최소 2대 이상 인스턴스에 앞단 로드밸런서, Health Check 기반 페일오버, 별도 모니터링 대시보드가 거의 필수입니다. 한 대만 띄우는 구성은 도입 안 한 것보다 위험할 수 있습니다.
결국 SCG가 답인가, 다른 게 답인가
| 게이트웨이 | 적합한 경우 |
|---|---|
| Spring Cloud Gateway | Spring MSA, 코드 기반 복잡 필터 |
| Nginx | 정적 라우팅, 단순 프록시 |
| Kong | 다국어 백엔드, 통합 게이트웨이 |
| AWS API Gateway | AWS 중심 서버리스 |
| Netflix Zuul 1 | 유지보수 종료 — 신규 비권장 |
정리하면 이렇습니다. MSA·인증 중앙화·횡단 관심사 일원화·트래픽 제어 중 둘 이상에 해당하고, WebFlux를 운영팀이 다룰 수 있으며, SPOF 회피 인프라가 준비됐다면 SCG는 매우 강력한 선택입니다. 그렇지 않다면 Nginx 한 줄 설정으로 같은 일을 더 빠르게 끝낼 수 있습니다. 도입했다면 p99 응답 시간을 도입 전 베이스라인과 반드시 비교하세요.