API Gateway란 무엇인가요?

애플리케이션 프로그래밍 인터페이스(API)는 소프트웨어 애플리케이션이 데이터, 기능 및 기능을 교환할 수 있도록 하는 규칙이나 프로토콜의 집합으로서 기업이 자체 서비스와 타사 서비스를 모두 사용할 수 있도록 도와줍니다. Postman의 2025년 API 현황 보고서에 따르면 기업 10곳 중 8곳 이상이 API 우선 전략을 어느 정도 채택했으며, 25%는 API를 전적으로 우선시한다고 생각합니다.

API 게이트웨이는 API 상호 작용을 간소화하고 클라이언트 애플리케이션이 다양한 서비스(해당 서비스의 API 각각을 통해)에 액세스할 수 있도록 지원함으로써 최신 IT 환경에서 핵심적인 역할을 담당하며, 다른 프로그래밍 언어로 개발되었거나 다양한 플랫폼에서 호스팅되는 서비스, 클라우드와 엣지, 온프레미스 환경에 배포되는 서비스까지 포괄합니다.

API 게이트웨이는 자사 또는 타사 애플리케이션에 액세스하는 내부 사용자와 고객 또는 비즈니스 파트너와 같은 외부 사용자 모두에게 서비스를 제공할 수 있습니다. 연합 시스템에서 기업은 여러 게이트웨이를 사용하여 API 그룹 또는 사용자 유형에 따라 서로 다른 보안 프로토콜 및 표준을 적용합니다.

API 게이트웨이에는 주로 두 가지 주요 아키텍처 계층이 있습니다.

• 컨트롤 플레인은 보안 정책 설정, API 요청 로깅 및 모니터링, 라우팅 규칙 정의 등 구성과 관리를 처리합니다.
   

• 데이터 플레인은 컨트롤 플레인에서 설정한 라우팅 지침, 보안 프로토콜 및 데이터 제약 조건을 적용하면서 API 요청을 실시간으로 라우팅합니다.

클라이언트에서 API로 데이터를 요청하는 것을 API 호출이라고 합니다. API 게이트웨이는 API 호출(API 요청이라고도 함)을 수신하여 하나 이상의 백엔드 서비스로 라우팅하고, 요청된 데이터를 수집하여 단일 결합 응답으로 클라이언트에 전달합니다. 그렇게 하지 않으면 클라이언트가 관련 서비스 또는 데이터 소스에 액세스하기 위해 여러 API에 직접 접속해야 합니다.주

예를 들어 의료 시스템은 API 게이트웨이를 사용하여 환자가 사용자 대면 애플리케이션을 통해 여러 백엔드 서비스에 접속하도록 지원할 수 있습니다. 환자는 노트북이나 전화를 사용하여 의료 기록 검토, 진료 예약, 결제, 메시지 전송을 할 수 있습니다. API 게이트웨이가 단일 진입점(또는 엔드포인트) 역할을 하므로 사용자는 여러 플랫폼 사이를 돌아다니지 않고도 모든 서비스를 이용할 수 있습니다. 또한 암호화, 권한 부여를 비롯한 보안 조치를 통해 민감한 환자 데이터를 보호합니다.

API 게이트웨이가 구현되는 방식을 살펴보기 전에, 이것이 API 자체와 어떻게 다른지 알아봅시다. API는 규칙과 프로토콜 집합이며 다른 소프트웨어 애플리케이션과의 통신을 지원하고, 웹 기반 프로토콜 HTTP나 HTTPS를 이용하는 경우가 많습니다. 회사 건물을 이루는 여러 층이라고 볼 수 있고, 각 층은 특정 서비스를 나타냅니다. 데이터를 검색하려면 클라이언트가 해당 층에 올라가 내부 서비스에 입장해야 합니다.

한편 API 게이트웨이는 회사 건물의 정문으로, 클라이언트가 어떤 층에 올라가기 위해 통과해야 하는 단일 지점입니다. 많은 구성에서 게이트웨이는 리셉션 역할도 합니다. 방문자의 신원을 확인하여 어느 층에 입장할 수 있는지 판단하는 것입니다. 또한 클라이언트가 각 층을 혼자서 돌아다니게 하지 않고, 이들에게 요청 받은 정보나 서비스를 대신 조회해서 단일 패키지로 반환합니다.

API 게이트웨이는 조직이 사용자에게 일관성 있고 안전하며 효율적인 API 경험을 제공하는 데 도움이 됩니다. 주요 기능과 책임은 다음과 같습니다.

통합 API 엔드포인트 역할을 하는 게이트웨이는 호출을 수신해서 인증하고, 조직 정책에 따라 처리하고, 적절한 백엔드 서비스로 라우팅합니다. 그런 다음 결과를 집계하여 복합 형식으로 API 클라이언트(주로 사용자 대면 앱이나 웹 사이트)에 반환합니다. 이 프로세스를 통해 사용자는 단일 API 호출로 여러 가지 요청을 하고, 하나의 종합적인 응답을 받을 수 있습니다. 일부 구성에서는 게이트웨이가 비즈니스 기능을 간소화하기 위해 여러 단계의 자동화된 작업을 조정할 수 있는 워크플로 오케스트레이션 계층과 함께 작동합니다.

API 관리는 기업 내에서 API를 생성, 게시 및 관리하는 확장가능한 프로세스입니다. 멀티 클라우드 기업 f5에 따르면 요즘 기업들은 수천 개의 API를 동시에 관리하는 경우가 많다 보니 가시성, 제어 및 거버넌스에 관련해 계속 어려움을 겪고 있습니다. API 게이트웨이는 요청 라우팅, 버전 관리, 로드 밸런싱, 트래픽 관리와 같은 관리 작업을 중앙으로 집중시켜 이러한 복잡성을 단순화합니다. 또한 API 호출 로그를 생성하고 분석과 통합하여 API 관측 가능성을 개선하고, 팀에 API 사용 패턴에 대해 더 깊은 인사이트를 제공합니다.

API 보안이란 오용, 악의적인 공격 및 기타 사이버 보안 위협으로부터 API를 보호하는 관행과 절차를 말합니다. API 게이트웨이는 인증, 권한 부여 및 기타 권한 및 액세스 제어를 관리하여 API 보안 프로토콜을 시행하는 데 도움이 됩니다. TLS(전송 계층 보안) 및 OAuth(개방형 권한 부여)와 같은 암호화 프로토콜을 사용하여 보안 네트워크를 유지하고 안전한 연결을 촉진합니다.

속도를 제한하거나 사용자별로 허용되는 요청 건수를 지정해 두면 분산 서비스 거부(DDoS) 공격을 방지할 수 있습니다. 마지막으로 API 게이트웨이는 시스템의 모든 API에 대한 거버넌스 및 감독을 처리하여 정렬 불량, 섀도우 API 및 기타 보안 취약성으로부터 보호합니다.

API 게이트웨이는 API 요청, 응답 및 오류를 모니터링하고 기록할 수 있습니다. 그러면 기업은 이 분석 데이터를 사용하여 API 트래픽과 성능을 더 잘 이해하고 문제를 해결하며 보안을 강화합니다. 로그와 지표는 가시성을 개선하여 팀이 오류와 보안 위협을 신속하게 식별하는 데 도움이 될 뿐만 아니라 오류가 발생하는 방식과 이유에 대한 맥락을 제공하여 장기적으로 시스템 건전성에 기여합니다.

API 게이트웨이는 기업 내 효율성을 개선하여 백엔드 서비스가 성능을 높이고 고가용성을 달성하며, 사용자에게 보다 안정적이고 응답성이 뛰어난 경험을 제공하도록 지원합니다. 응답 압축을 통해 게이트웨이는 큰 응답을 더 작은 파일로 변환하여 대역폭 소비와 로드 시간을 줄일 수 있습니다. 캐싱은 기업이 일반적으로 참조되는 데이터를 로컬에 저장하여 비용과 서버 부하를 최소화하는 동시에 성능을 향상시키는 데 도움이 됩니다. 마지막으로, 기업은 보안을 위해 속도를 제한하는 경우가 많지만, 이 전술은 안정성을 높이고 서버 과부하를 방지하며 API 액세스가 공정하게 분산되게 하는 데도 도움이 됩니다.

API 게이트웨이 배포는 핵심 기능이 동일하더라도 아키텍처 및 구현에 따라 차이가 있을 수 있습니다. 일반적인 프레임워크는 다음과 같이 구성됩니다.

마이크로서비스 아키텍처는 높은 수준의 소프트웨어 개발 접근 방식이며 독립적으로 작동하는 더 작은 부분들로 구성됩니다. 마이크로서비스 각각은 하나의 기능을 담당하며 자율적으로 배포 및 확장할 수 있습니다. 이와 동시에, 서비스들이 API를 통해 쉽게 통신하며 대규모 프로그램을 위한 모듈식 빌딩 블록 역할을 할 수 있습니다. 2023년 Gartner 보고서에 따르면 조직의 약 4분의 3이 마이크로서비스를 사용하고 있으며, 23%는 앞으로 프레임워크를 도입할 계획이라고 합니다.

마이크로서비스 환경에서 API 게이트웨이는 종종 남북 트래픽을 처리하여 외부 클라이언트에서 적절한 백엔드 서비스로 API 호출을 라우팅합니다. 주로 동서 트래픽 또는 마이크로서비스 환경 내의 서비스 간 통신을 처리하는 서비스 메시와 함께 작동하지만, 예외적으로, 특히 최신 설정에서 내부 트래픽을 라우팅하도록 구성되는 API 게이트웨이도 있습니다. 그러나 게이트웨이는 별도의 아키텍처 계층에 배치될 때가 많고, 반대로 서비스 메시는 내부 연결을 촉진하고 관리하기 위해 각 서비스와 함께 배포되거나 통합됩니다.  

마이크로서비스 환경에서 API 게이트웨이는 조직이 단일 API 호출을 통해 요청된 리소스를 반환하는 데 핵심 역할을 합니다. 예를 들어 전자 상거래 회사가 제품 정보, 가격 책정 및 재고에 대해 각기 다른 서비스를 이용한다면 API 게이트웨이를 통해 하나의 요청만으로 각 서비스의 정보를 가져오거나 기능에 접근할 수 있습니다. 이 워크플로는 마이크로서비스 환경이 더욱 복잡해지고 기업이 새로운 서비스와 API를 추가할 때 특히 유용합니다.

Kubernetes는 기업이 컨테이너화된 환경 안에서 서비스를 배포, 확장, 관리하는 데 도움이 되는 오픈 소스 오케스트레이션 시스템입니다. 이때 애플리케이션은 종속성이 있는 가벼운 컨테이너 패키지로 제공됩니다. Kubernetes는 마이크로서비스 아키텍처에서 자주 사용되지만 모놀리식, 서버리스와 기타 프레임워크도 지원할 수 있습니다. 오케스트레이션 플랫폼은 최신 클라우드 인프라에서 중요한 역할을 하며, 개발자는 이를 활용해 애플리케이션을 한 번 구축해 두고 어디에나 배포할 수 있습니다.

API 게이트웨이는 다양한 방식으로 컨테이너화된 Kubernetes 클러스터와 상호 작용할 수 있습니다.

• 둘 이상의 Kubernetes 클러스터 앞에 배포되는 경우, API 게이트웨이는 로드 밸런서 역할을 할 수 있으며, 어떤 인스턴스도 오버로드되지 않도록 트래픽을 올바른 클러스터로 전달할 수 있습니다.
   

• Kubernetes 클러스터의 엣지에 배포되는 경우, API 게이트웨이가 인그레스 컨트롤러 역할을 할 수 있습니다. 인그레스 컨트롤러는 트래픽을 Kubernetes 클러스터로, 요청된 서비스로 보낸 다음 다시 되돌려 보냅니다.
   

• Kubernetes 클러스터 내에서 배포되면 API 게이트웨이는 내부 컨테이너화된 서비스 간 통신을 처리하는 서비스 메시와 함께 작동하여 서로를 보완할 수 있습니다. 이 통합은 로드 밸런싱, 서비스 검색, 트래픽 라우팅 및 종단 간 암호화를 개선할 수 있습니다.

서버리스 모델에서 개발자는 애플리케이션을 구동하는 서버에 직접 접속하지 않습니다. 대신 클라우드 공급자가 서버 프로비저닝과 관리를 도맡기 때문에, 개발자는 코드 작성과 배포에만 집중할 수 있습니다.

서버리스 환경에서 API 게이트웨이는 마이크로서비스 환경의 게이트웨이와 유사하게 작동합니다. 그러나 장기 실행 서비스에서 데이터를 검색하는 대신, 클라이언트 요청에 따라 이벤트(특정 작업을 시작하는 지침)를 트리거합니다. 이 방식은 애플리케이션이 필요할 때만 실행되도록 하여 보안과 효율성을 향상시키는 데 도움이 됩니다.

서버리스와 마이크로서비스를 결합하여 각 서비스가 컨테이너형 또는 가상 머신 배포가 아닌 서버리스 배포로 작동하는 하이브리드 아키텍처를 형성할 수 있습니다. 특히 가변적인 워크로드의 경우 비용을 절감하고 확장성을 개선할 가능성이 생깁니다.

모든 API 관리 구현이 똑같지는 않습니다. 구성 요소는 시스템 복잡성, 아키텍처 접근 방식, 사용 목적에 따라 다를 수 있지만, 역할과 기능이 겹치는 요소들도 있어서 차이점이 늘 명확하지는 않습니다.

인그레스 컨트롤러는 Kubernetes 기반 소프트웨어 구성 요소로, 리버스 프록시 역할을 하며 일련의 인그레스 규칙에 따라 Kubernetes 클러스터 내부 서비스로 외부 HTTP 트래픽을 라우팅합니다. 인그레스 컨트롤러는 네트워크 안정성을 보장하기 위해 트래픽을 다양한 서비스로 지능적으로 전달하는 로드 밸런싱 기능을 제공하는 경우가 많습니다. 또한 라우팅 동작을 동적으로 조정하여 새로운 배포와 구성 업데이트를 수용할 수 있습니다.

Kubernetes 인그레스 컨트롤러가 수행하는 기능 중에는 API 게이트웨이와 겹치는 부분도 있지만, API 게이트웨이는 일반적으로 감사, 로깅, 액세스 제어 및 보안과 같은 더 높은 수준의 관리 도구를 통합하여 범위가 더 넓습니다. 또한 API 게이트웨이는 다양한 구성을 지원할 수 있지만 인그레스 컨트롤러는 Kubernetes 환경에만 해당됩니다.

서비스 메시는 내부 서비스 간의 통신을 원활하게 하여 데이터와 기능을 효율적으로 공유할 수 있도록 하는 인프라 계층입니다. 컨트롤 플레인(구성과 정책을 설정하는 곳)은 중앙에 집중되어 있는 반면, 데이터 플레인은 경량 사이드카 프록시를 통해 모든 서비스에 분산됩니다. 각 서비스 인스턴스와 함께 배치되는 이러한 프록시는 보안, 로깅, 라우팅 및 암호화를 포함한 제어 영역 정책을 실행합니다. 반면 API 게이트웨이는 일반적으로 네트워크의 엣지에 존재하며, 클라이언트 및 해당 클라이언트가 관리하는 API와는 다른 별도의 아키텍처 계층에 자리합니다.

서비스 메시를 사용해 내부 서비스가 데이터와 정보를 교환하더라도, 외부 트래픽과 상호 작용하는 수단은 여전히 필요합니다. 이때 인그레스 게이트웨이라는 특수 구성 요소가 메시의 진입점 역할을 하여 보안 및 성능 정책을 유지하면서 외부 트래픽 라우팅을 처리합니다. API 게이트웨이와 서비스 메시는 공용 상호 작용을 처리하는 API 게이트웨이, 서비스 간 연결을 용이하게 하는 서비스 메시와 함께 사용되는 경우가 많습니다.

API 환경이 복잡하고 API가 수신하는 트래픽이 많을수록 API 게이트웨이는 더 많은 가치를 제공할 수 있습니다. API 게이트웨이는 백엔드 서비스로 트래픽을 라우팅하는 것 외에도 다음을 수행할 수 있습니다.

API 게이트웨이는 트래픽 라우팅을 최적화하여 지연 시간을 줄이고 사용자 경험을 향상시킬 수 있습니다. 속도 제한은 클라이언트에게 허용되는 요청에 상한선을 설정해서 과도한 요청을 차단합니다. 요청 제한은 요청을 느리게 하거나 지연시키거나 대기열에 넣어서 트래픽 급증을 관리합니다. 로드 밸런싱은 기업이 실시간 지표를 기반으로 서버의 상황을 확인하고 그에 따라 라우팅 경로를 조정하는 데 도움이 됩니다. 이러한 전략은 백엔드 서비스가 과부하되거나 손상되는 것을 방지하고 응답 시간을 최소화하며, 서비스가 더 빠르게 안정적으로 운영되도록 도움을 줍니다.

API 게이트웨이는 조직이 확장됨에 따라 API 트래픽과 작업량의 균형을 맞추는 데 도움이 됩니다. 게이트웨이는 자동화 시스템과 통합되어 트래픽 수요에 따라 실시간으로 인스턴스를 추가하거나 제거할 수 있으므로 개발자는 관리 대신 핵심 비즈니스 로직 및 API 개발에 집중할 수 있습니다.

API 게이트웨이는 일관된 보안 및 정책을 정의하고 적용하며 네트워크 전체에 트래픽을 프로비저닝하여 DevOps 배포를 가속화할 수도 있습니다. 이러한 중앙 집중식 제어는 팀이 더 넓은 에코시스템에 영향을 주지 않고 독립적으로 서비스를 확장하거나 업데이트하도록 자율성을 제공하여 리소스 할당과 혁신 속도를 향상시킵니다.

마지막으로, 게이트웨이는 여러 버전의 API를 효과적으로 관리할 수 있기 때문에 개발자는 배포 전에 여러 가지 반복된 버전을 테스트하거나 특정 사용 사례에 대해 이전 API 버전의 인스턴스를 유지 관리할 수 있습니다.

API는 고유의 역할과 책임을 가지면서도 몇 가지 공통된 워크플로를 공유하는 경우가 많습니다. 예를 들어 많은 API 호출이 보안 프로토콜을 준수하기 위해 동일한 권한 부여 및 검증 프로세스를 거칩니다. 사용량과 트래픽 관련 인사이트를 얻는 데 사용되는 동일한 로깅 및 모니터링 정책이 API마다 적용될 수 있습니다. 하지막으로, API로 수익을 창출하는 경우 모든 호출을 청구 서비스로 라우팅해야 할 수 있습니다. API 게이트웨이는 이러한 각 작업을 오케스트레이션하고 자동화할 수 있으므로 개발자는 각 API 호출 중에 수동으로 작업을 수행할 필요가 없습니다.

또한 API 게이트웨이는 게이트웨이에서 비밀번호 및 신용카드 번호와 같은 민감한 데이터를 해독하는 데 사용되는 방법인 보안 소켓 계층(SSL) 종료를 지원합니다. 그래서 개별 API에서 성능 집약적인 작업의 부담을 덜 수 있습니다. 또한 API 게이트웨이는 보안 소켓 계층(SSL) 종료(게이트웨이에서 비밀번호 및 신용카드 번호와 같은 민감한 데이터를 해독하는 데 사용되는 방법)를 지원하여, 성능 집약적인 이 작업을 개별 API에서 분리하여 처리할 수 있습니다.

API는 최신 IT 인프라에서 중요한 역할을 하다 보니 DDoS 공격, 매개변수 변조, 주입 공격을 비롯해 위험한 각종 사이버 공격에 노출되는 경우가 많습니다. API 게이트웨이는 속도 제한, API 인증, 요청 권한 부여 등의 기술을 통해 이러한 위협을 피하는 데 도움이 될 수 있습니다.

API 게이트웨이에는 누가 어떤 서비스와 상호 작용을 시도하는지 보여주는 통합 ID 및 액세스 관리(IAM) 시스템이 있는 경우가 많습니다. 또한 API 사용량을 모니터링하고, 트래픽을 기록하고, 지표를 분석하여 공격이 발생하기 전에 의심스러운 동작이나 취약점을 식별할 수 있습니다. 마지막으로, API 게이트웨이는 악성 HTTP 트래픽을 모니터링, 필터링, 차단하는 애플리케이션 방화벽(WAF)과 같은 도구와 함께 사용할 수 있습니다.

API 게이트웨이는 하이브리드 클라우드 아키텍처를 지원해서 사용자가 REST API(Representational State Transfer), SOAP, gRPC, WebSocket과 같은 다양한 프로토콜 및 데이터 형식을 사용하는 백엔드 서비스와 상호 작용할 수 있게 합니다.

API 게이트웨이가 없으면 API는 API 호출을 접근 가능한 형식으로 수동 변환하는 데 어려움을 겪을 수 있습니다. 게이트웨이는 데이터 및 프로토콜 변환을 수행하고 요청과 응답을 클라이언트와 서비스 모두가 이해할 수 있는 형식으로 자동 변환하여 이 문제를 완화합니다.

또한 기업은 API 게이트웨이와 개발자 포털(개발자가 새로운 API를 발견하고 구현할 수 있는 중앙 리포지토리) 사이의 문서와 액세스 키를 동기화합니다. 그래서 개발 환경에 최신 API 롤아웃과 업데이트가 정확하게 반영됩니다.

레거시 애플리케이션은 특히 SaaS 또는 IoT와 같은 최신 API 구현과 호환되지 않으면 발전에 장애물이 될 수 있습니다. 그러나 레거시 앱은 쉽게 교체할 수 없는 필수 데이터와 기능을 가지고 있어 보존할 가치가 있는 경우가 많습니다.

API 게이트웨이를 사용하면 기업은 기존 애플리케이션을 폐기하거나 처음부터 다시 구축하지 않고도 최신 클라우드 환경에 맞게 기존 애플리케이션을 재사용하고 재활용할 수 있습니다. 게이트웨이의 변환 기능을 통해 기업은 회사의 나머지 부분이 최신 시스템으로 이동한 경우에도 레거시 앱의 원래 코드와 형식을 보존할 수 있습니다.

서비스를 더 작은 부분으로 나누는 분리 작업을 하면 API 게이트웨이가 레거시 앱에 속도 제한, 스로틀링 및 기타 도구를 적용하여 기능을 현대화하고 수명 주기를 연장할 수 있습니다. 이 전략은 또한 기업이 백그라운드에서 서비스를 업데이트하는 동안에도 서비스를 온라인 상태로 유지하는 데 도움이 됩니다.

API 게이트웨이는 애플리케이션 인바운드 트래픽을 제어하는 센터로서 API 사용량 및 성능을 포괄적으로 보여줄 수 있습니다. 맞춤형 차트와 대시보드는 기업이 트래픽 패턴, 처리량, 응답 시간 및 기타 지표를 시각화하는 데 유용합니다. 알림은 애플리케이션 성능이나 보안에 영향을 미칠 수도 있는 오류나 위반 사항을 팀에 사전 경고합니다.

API 게이트웨이는 복잡한 라우팅 문제를 해결하는 데 도움이 되는 한편 새로운 문제를 일으킬 수도 있습니다. 일반적으로 해결해야 할 문제는 다음과 같습니다.

API 게이트웨이는 일반적으로 API 통신, 리소스 할당 및 라우팅 요청을 간소화하는 데 도움이 됩니다. 그러나 구성이 잘못되거나 용량이 부족하면 병목 현상의 위험이 커지고 시스템에 추가적인 부담을 안기는 역효과가 생길 수 있습니다. 서비스 중단 및 속도 저하를 방지하기 위해, 기업은 새로운 고객을 유치하고 서비스 제공을 확장할 때 더 많은 리소스를 프로비저닝하기도 합니다.

API 게이트웨이는 기업의 API 에코시스템에 추가 계층을 도입하기 때문에 추가 유지 관리 작업과 컴퓨팅, 전문 지식이 필요해 집니다. 개발자는 새 배포를 테스트하기가 더 어려워질 수 있습니다. 가상환경에서 API 게이트웨이를 정확하게 다시 생성하는 게 어렵기 때문입니다. 이러한 제약으로 인해 팀은 롤아웃이 시스템에 어떤 영향을 미칠 수 있는지 미리 알기 어렵습니다.

코드형 인프라(IaC)라는 DevOps 사례는 구성 파일을 사용하여 인프라 관리 및 표준화를 자동화함으로써 이러한 문제를 해결하는 데 도움이 될 수 있습니다. 이 방식은 유지 관리 및 프로비저닝을 단순화하여 IT 팀이 아키텍처 복잡성을 줄이면서 API 게이트웨이 효율성을 극대화하도록 지원합니다.

API 게이트웨이는 단일 진입점 역할을 하기 때문에 게이트웨이 자체가 사이버 공격이나 침투의 벡터가 될 가능성이 있습니다. 위협과 오류가 여러 백엔드 서비스를 통해 연쇄적으로 발생하고, API 트래픽을 차단하고 애플리케이션의 건전성을 손상시킬 수도 있는 것입니다.

환경과 가용성 영역 전반에 걸쳐 여러 게이트웨이 인스턴스를 유지 관리하면, 오프라인 상태가 되었을 때 다른 게이트웨이 인스턴스가 일시적으로 그 자리를 대신하게 해서 위험을 줄일 수 있습니다. 마찬가지로 조직은 엣지 게이트웨이와 서비스 메시를 포함한 다양한 게이트웨이 유형을 사용하여 라우팅과 관리 책임을 여러 진입점에 분산할 수 있습니다.

조직이 특정 요구 사항을 충족하는 API 게이트웨이를 선택하고 해당 게이트웨이를 중심으로 API 환경을 구축한 후에는 다른 공급업체로 이동하는 데 비용과 시간이 많이 소요될 수 있습니다. 다양한 구성을 더욱 세밀하게 제어하기 위해, 관리형 서비스를 사용하지 않고 오픈 소스 게이트웨이를 자체 호스팅하는 조직도 있습니다. 그러나 이렇게 자체 호스팅을 하면 개발 팀 입장에서 비용이 더 많이 들 수 있습니다.