API 게이트웨이 (API Gateway)
쉽게 풀면
큰 회사 건물에 여러 부서(인사팀, 회계팀, 영업팀)가 각각 다른 층에 있다고 해봅시다. 방문객이 층마다 일일이 찾아다니며 신분증을 보여주고 용건을 설명하는 대신, 1층 안내 데스크에서 신분을 한 번 확인받고 "몇 층 어느 부서로 가시면 됩니다"라고 안내받으면 훨씬 편리합니다.
API 게이트웨이는 바로 이 안내 데스크와 같습니다. 마이크로서비스 아키텍처처럼 하나의 서비스가 여러 개의 작은 서버로 쪼개져 있을 때, 사용자의 요청을 게이트웨이가 먼저 받아서 "이 사용자가 맞는지" 인증하고, 요청 내용에 맞는 서버로 전달해줍니다.
덕분에 각 서버는 인증이나 로깅 같은 반복 작업을 따로 처리할 필요 없이 자기 역할에만 집중할 수 있습니다.
왜 중요한가
클라우드 환경에서 서비스를 여러 개의 작은 단위로 쪼개 개발·배포하는 방식이 보편화되면서, 그 서버들을 외부에 어떻게 안전하고 효율적으로 노출할 것인가가 시스템 설계의 핵심 과제가 되었습니다.
API 게이트웨이는 이 문제에 대한 표준적인 해법 중 하나로, 분산 시스템 아키텍처, 클라우드 컴퓨팅, 서비스 메시(service mesh) 같은 연구 주제와 밀접하게 연결됩니다.
그래서 마이크로서비스 기반 시스템의 성능, 보안, 확장성을 다루는 논문에서는 게이트웨이의 구조나 정책을 실험 설계의 일부로 언급하는 경우가 많습니다.
핵심 정리
- API 게이트웨이는 클라이언트(웹, 모바일 앱 등)와 여러 백엔드 서비스 사이에서 단일 진입점 역할을 하는 서버입니다. 마이크로서비스 구조에서 흔한 설계 패턴으로 정리되어 있습니다(Richardson, 2018).
- 흔히 맡는 기능은 요청 라우팅, 인증·권한 확인, 호출 횟수 제한(속도 제한), TLS 종료, 로깅·모니터링, 응답 캐싱, 프로토콜 변환(예: 외부는 REST, 내부는 gRPC), 여러 서비스 응답을 하나로 모으는 집계(aggregation)입니다.
- 트래픽 방향으로 보면 게이트웨이는 외부 클라이언트에서 시스템 안으로 들어오는 ‘남북(north-south)’ 트래픽을 다루고, 서비스끼리 주고받는 ‘동서(east-west)’ 트래픽은 주로 서비스 메시가 다룹니다.
- 클라이언트 종류(웹, 모바일 등)마다 별도의 게이트웨이를 두는 변형을 ‘Backends for Frontends’ 패턴이라 하며, 뉴먼(Newman, 2015)이 소개한 것으로 알려져 있습니다.
- 단점: 모든 요청이 지나가므로 단일 장애점이나 병목이 될 수 있어 이중화가 필요하고, 한 단계가 더 생기는 만큼 지연이 늘며, 비즈니스 로직까지 넣으면 게이트웨이가 또 하나의 거대한 덩어리가 됩니다.
예시로 보기
가상의 예입니다. 모바일 앱의 한 화면이 서비스 4개의 데이터를 필요로 한다고 합니다. 클라이언트와 서버 사이 왕복 시간 80 ms, 서비스당 처리 시간 20 ms, 게이트웨이 처리 5 ms, 게이트웨이와 서비스 사이 내부 왕복 5 ms로 가정했습니다.
- 직접 호출(순차 4회): 4 × (80 + 20) = 400 ms
- 게이트웨이가 4개를 병렬로 집계: 80 + 5 + 5 + 20 = 110 ms
이 차이는 가정에서 나온 값이라 실제와 다를 수 있으나, 외부 왕복 횟수를 줄이는 것이 집계의 핵심 이점임을 보여 줍니다. 반대로 게이트웨이 자체가 느리거나 서비스 하나가 느리면 전체 응답이 그 영향을 받습니다.
자주 하는 오해
| 오해 | 바로잡기 |
|---|---|
| API 게이트웨이는 로드 밸런서의 다른 이름이다. | 로드 밸런서는 요청을 같은 종류의 서버들에 분산합니다. 게이트웨이는 요청 내용을 보고 서로 다른 서비스로 보내고 인증·집계 같은 기능을 얹습니다. 함께 쓰는 경우가 많습니다. |
| 게이트웨이에서 인증하면 보안이 끝난다. | 내부 서비스끼리의 인가, 데이터 보호, 게이트웨이를 우회한 접근 차단은 별도로 설계해야 합니다. |
| 게이트웨이에 업무 로직을 넣어도 된다. | 횡단 관심사(인증, 제한, 로깅)에 두고 업무 규칙은 서비스에 두는 것이 권장됩니다. 그렇지 않으면 게이트웨이가 변경의 병목이 됩니다. |
| 마이크로서비스에는 반드시 있어야 한다. | 필수 요소가 아니라 선택 가능한 패턴입니다. 서비스 수가 적으면 오히려 복잡도만 늘 수 있습니다. |
논문에서는 이렇게 쓰입니다
실제 논문에서
이 용어를 직접 쓴 국내 논문 문장을 아직 수집하지 못했습니다. 수집되는 대로 출처와 함께 싣겠습니다.
예시 문장
아래는 용어의 쓰임을 보여 주려고 만든 예시로, 실제 논문에서 가져온 문장이 아닙니다.
이 문장은 인증이나 트래픽 제한처럼 여러 서버가 공통으로 필요로 하는 기능을 게이트웨이 한곳에 모아 처리해서, 개별 서버는 핵심 기능 개발에만 집중할 수 있게 했다는 뜻입니다.
사물인터넷(IoT)처럼 수많은 소형 기기가 네트워크에 연결되는 환경에서도, 게이트웨이가 각 기기의 요청을 한 번 걸러주는 관문 역할을 해 보안성과 관리 효율을 높인다는 내용입니다.
대규모 서비스 안정성 연구에서는 게이트웨이가 단순 중계를 넘어, 장애가 다른 서비스로 번지지 않도록 막는 방어 계층으로도 활용된다는 것을 보여주는 문장입니다.
조금 더 깊게 보면
실제 논문에서 API 게이트웨이를 다룰 때는 단순 라우팅 기능 외에, 속도 제한(rate limiting), 회로 차단기(circuit breaker), 캐싱, 요청/응답 변환 같은 부가 기능이 함께 논의되는 경우가 많습니다.
이런 기능들은 대체로 게이트웨이가 백엔드 서비스들을 보호하고 전체 시스템의 회복탄력성(resilience)을 높이는 역할을 한다는 공통점이 있습니다.
또한 게이트웨이 자체의 지연 시간(latency)과 처리량(throughput)이 시스템 전체 성능에 영향을 줄 수 있어, 관련 연구에서는 게이트웨이 계층에서 발생하는 오버헤드를 함께 측정·평가하기도 합니다.
쿠버네티스 기반 환경에서는 API 게이트웨이가 인그레스(ingress) 컨트롤러나 서비스 메시의 일부 구성요소와 함께 언급되는 경우도 흔합니다.
주의할 점
API 게이트웨이는 모든 요청이 반드시 거쳐가는 지점이기 때문에, 게이트웨이 자체에 장애가 생기면 그 뒤에 있는 모든 서버로 가는 길이 한꺼번에 막히는 단일 장애점(single point of failure)이 될 수 있습니다. 이는 여러 서버로 트래픽을 단순히 나눠주는 로드밸런싱과 혼동되기도 하지만, 게이트웨이는 인증·라우팅·속도 제한 같은 더 다양한 역할까지 함께 수행한다는 점에서 차이가 있습니다.
헷갈리기 쉬운 용어
| 용어 | 주된 역할 | 트래픽 |
|---|---|---|
| API 게이트웨이 | 외부 요청의 진입점: 라우팅, 인증, 집계 | 외부 → 시스템(남북) |
| 로드 밸런서 | 같은 서비스의 여러 인스턴스에 부하 분산 | 주로 외부 → 시스템, 내부에서도 사용 |
| 서비스 메시 | 서비스 간 통신의 재시도, 보안, 관측 | 서비스 ↔ 서비스(동서) |
| 속도 제한 | 호출 횟수 제한 정책 | 게이트웨이가 수행하는 기능 중 하나 |
참고 문헌
- Newman, S. (2015). Building Microservices: Designing Fine-Grained Systems. O'Reilly Media.
- Richardson, C. (2018). Microservices Patterns: With Examples in Java. Manning Publications.
- Dragoni, N., Giallorenzo, S., Lluch Lafuente, A., Mazzara, M., Montesi, F., Mustafin, R., & Safina, L. (2017). Microservices: Yesterday, today, and tomorrow. In M. Mazzara & B. Meyer (Eds.), Present and Ulterior Software Engineering. Springer.
표의 기준값은 위 문헌에 근거한 관례이며, 분야·학술지마다 다른 기준을 쓸 수 있습니다.