현대 소프트웨어 아키텍처의 패러다임은 거대한 단일 애플리케이션, 즉 모놀리식(Monolithic) 구조에서 작고 독립적으로 배포 가능한 서비스들의 집합인 마이크로서비스 아키텍처(Microservices Architecture, MSA)로 빠르게 전환되고 있다. MSA는 개별 서비스의 독립적인 개발, 배포, 확장을 가능하게 하여 개발 팀의 자율성을 높이고 전체 시스템의 유연성과 회복탄력성을 향상시키는 강력한 이점을 제공한다. 하지만 이러한 분산 환경은 필연적으로 서비스 간의 통신 복잡성 증가라는 새로운 과제를 낳았다. 수십, 수백 개의 마이크로서비스가 서로 통신하는 환경에서는 인증, 인가, 트래픽 제어, 로깅, 모니터링과 같은 공통 기능, 즉 횡단 관심사(cross-cutting concerns)를 어떻게 효율적으로 관리할 것인가가 핵심적인 문제로 부상했다.1
API 게이트웨이는 이러한 MSA의 복잡성을 해결하기 위한 표준화된 아키텍처 패턴으로 등장했다. 이는 모든 클라이언트 요청에 대한 단일 진입점(Single Point of Entry) 역할을 수행하며, 백엔드의 복잡한 마이크로서비스 구조를 외부로부터 은닉하고 횡단 관심사를 중앙에서 일관되게 처리한다.2 이를 통해 개별 마이크로서비스 개발팀은 비즈니스 로직 구현에만 집중할 수 있게 되어 생산성을 극대화할 수 있다.3
이러한 배경 속에서 2015년 오픈소스로 공개된 Kong은 API 게이트웨이 시장의 핵심 플레이어로 빠르게 자리매김했다. Kong의 설계 철학은 명확하다. 수십 년간 검증된 안정성과 압도적인 성능을 자랑하는 Nginx를 핵심 엔진으로 삼고, 그 위에 OpenResty의 Lua 스크립팅 환경을 결합하여 극강의 유연성과 확장성을 확보하는 것이다.5 이 아키텍처는 Nginx의 성능을 그대로 유지하면서도, 동적인 라우팅, 정교한 정책 제어, 그리고 무한한 기능 확장을 가능하게 하는 강력한 플러그인 생태계의 기반이 되었다.
흥미롭게도 Kong의 설계 철학은 단순한 기술적 이상에서 비롯된 것이 아니다. 이는 Kong의 전신인 Mashape가 겪었던 실제 경험에 깊이 뿌리내리고 있다. Mashape는 세계 최대 API 마켓플레이스를 운영하며 거대한 모놀리식 애플리케이션을 마이크로서비스로 전환하는 고통스러운 과정을 직접 겪었다.8 이 과정에서 마주한 배포의 어려움, 서비스 간의 강한 결합, 그리고 분산 시스템의 운영 복잡성은 API 트래픽을 중앙에서 관리하고 공통 기능을 분리해야 한다는 절실한 필요성으로 이어졌다. 즉, Kong의 핵심 기능들은 MSA로의 전환 여정에서 발생하는 실질적인 문제들을 해결하기 위해 탄생한 실용주의적 아키텍처의 산물이다.2 Kong은 단순한 기술적 프록시를 넘어, MSA 전환 과정의 복잡성을 이해하고 해결책을 제시하는 실질적인 동반자로서 설계된 것이다.
본 보고서는 Kong API 게이트웨이의 기술적 근간을 이루는 Nginx와 OpenResty의 역할부터 시작하여, Kong의 핵심 기능과 설계 사상을 심층적으로 분석한다. 나아가 Kong의 가장 큰 자산인 플러그인 생태계의 아키텍처와 개발 방법을 상세히 다루고, 다양한 환경에 맞는 배포 및 운영 전략을 비교 분석한다. 마지막으로 Kong Mesh와의 통합, AI 게이트웨이로의 진화 등 확장되는 생태계와 미래 전망을 조망하고, 경쟁 환경 속에서 Kong의 전략적 위치를 평가함으로써 Kong API 게이트웨이에 대한 다각적이고 깊이 있는 고찰을 제공하고자 한다.
Kong의 고성능과 유연성은 결코 우연의 산물이 아니다. 이는 수십 년간 웹 기술의 최전선에서 검증된 Nginx, 그리고 Nginx에 동적인 날개를 달아준 OpenResty와 Lua라는 견고한 기술적 토대 위에 세워져 있다. Kong의 아키텍처를 이해하기 위해서는 이 세 가지 핵심 구성 요소의 역할과 상호작용을 먼저 파악해야 한다.
Kong의 심장에는 Nginx가 자리 잡고 있다.10 Nginx는 C10K 문제(하나의 서버에서 1만 개 이상의 동시 접속을 처리하는 문제)를 해결하기 위해 탄생한 웹 서버로, 뛰어난 성능과 안정성으로 전 세계 웹 트래픽의 상당 부분을 처리하고 있다. Kong이 Nginx를 채택한 이유는 그것이 제공하는 근본적인 아키텍처의 우수성 때문이다.
Nginx의 핵심은 이벤트 기반 비동기 논블로킹(Event-driven, Asynchronous, Non-blocking) I/O 모델에 있다. 전통적인 스레드 기반 서버가 클라이언트 연결마다 하나의 스레드를 할당하여 컨텍스트 스위칭 오버헤드가 큰 것과 달리, Nginx는 단일 스레드 또는 소수의 스레드 내에서 이벤트 루프(Event Loop)를 사용하여 수많은 연결을 효율적으로 관리한다. 이를 통해 적은 메모리와 CPU 자원만으로도 대규모 동시 연결을 처리할 수 있으며, 이는 Kong이 낮은 지연 시간(latency)과 높은 처리량(throughput)을 달성할 수 있는 가장 근본적인 이유가 된다.12
또한 Nginx의 Master/Worker 프로세스 아키텍처는 안정성과 자원 활용률을 극대화한다. Master 프로세스는 설정 파일을 읽고, 권한이 필요한 포트를 바인딩하며, 실제 요청 처리를 담당하는 여러 개의 Worker 프로세스를 생성하고 관리하는 역할을 한다. 클라이언트의 모든 요청은 Worker 프로세스에 의해 직접 처리되므로, Master 프로세스는 안정적으로 시스템을 감독할 수 있다. 각 Worker 프로세스는 독립적으로 동작하며, 일반적으로 CPU 코어 수만큼 생성되어 시스템의 모든 CPU 자원을 효율적으로 활용한다. 이 구조는 수직적 확장(vertical scaling)에 매우 유리하며, Kong 클러스터의 개별 노드가 최대 성능을 발휘할 수 있도록 보장한다.12
만약 Kong이 순수한 Nginx만을 사용했다면, 정적인 설정 파일에 기반한 리버스 프록시 이상의 역할을 하기 어려웠을 것이다. Kong의 모든 동적 기능, 즉 플러그인을 통한 유연한 정책 적용과 런타임 설정 변경은 OpenResty 덕분에 가능하다.
OpenResty는 Nginx의 공식적인 포크(fork)가 아니라, Nginx 코어에 lua-nginx-module을 비롯한 강력한 Lua 라이브러리와 서드파티 모듈들을 통합하여 패키징한 웹 플랫폼이다.7 OpenResty의 핵심은
lua-nginx-module인데, 이는 Nginx의 요청 처리 생명주기(request processing lifecycle)의 여러 단계에 Lua 스크립트를 주입하여 실행할 수 있게 해준다. 중요한 점은 이 Lua 코드가 Nginx의 이벤트 루프 내에서 협력적 멀티태스킹(cooperative multitasking) 방식으로, 즉 논블로킹(non-blocking) 방식으로 실행된다는 것이다. 이 덕분에 복잡한 로직을 수행하는 Lua 스크립트가 실행되더라도 Nginx의 이벤트 루프를 막지 않아 고성능을 유지할 수 있다. Kong의 모든 플러그인과 핵심 프록시 로직은 바로 이 OpenResty의 Lua 스크립팅 환경 위에서 동작한다.6
더 나아가 Kong은 Nginx의 동작을 런타임에 더욱 세밀하게 제어하기 위해 자체적으로 개발한 Nginx C 모듈인 lua-kong-nginx-module을 사용한다.15 과거에는 Nginx의 특정 기능을 수정하기 위해 코어에 직접 패치(patch)를 적용하는 방식이 사용되었으나, 이는 Nginx 버전 업그레이드 시 유지보수를 어렵게 만드는 요인이었다.
lua-kong-nginx-module은 TLS 동작 변경, 업스트림 관리, 동적 로깅 레벨 설정 등 Kong에 필요한 저수준(low-level) 제어 기능을 Lua API 형태로 노출시킨다. 이를 통해 Nginx 코어 변경을 최소화하면서도 필요한 기능을 구현하여, 향후 유지보수성과 안정성을 크게 향상시켰다.15
Kong의 아키텍처는 Nginx의 견고한 기반 위에 OpenResty의 동적 스크립팅 능력을 결합한 정교한 구조를 가진다. 요청 처리 흐름, 설정 전파 방식, 그리고 워커 프로세스 간 통신 메커니즘을 통해 그 내부 동작을 깊이 있게 이해할 수 있다.
클라이언트로부터 API 요청이 들어오면, 먼저 Kong 노드의 Nginx Worker 프로세스 중 하나가 해당 요청을 수신한다. 그 후 요청은 OpenResty의 컨텍스트로 넘어가며, Kong의 핵심 Lua 코드가 실행된다. 이 과정은 다음과 같은 단계로 이루어진다.1
Route 규칙과 일치하는 항목을 찾는다.Route와 그에 연결된 Service에 설정된 플러그인들이 특정 순서에 따라 실행된다. 이 과정에서 인증, 인가, 속도 제한, 로깅 등 다양한 정책이 요청에 적용된다. 이 플러그인 실행은 Nginx의 요청 처리 라이프사이클 단계(예: access, header_filter, log)에 맞추어 이루어진다.Route에 연결된 Service가 가리키는 업스트림(Upstream) 서비스로 프록시한다.DB-backed 모드에서 Kong의 설정 관리 방식은 성능과 일관성 사이의 균형을 맞추기 위해 설계되었다. 사용자가 Admin API(:8001)를 통해 Service를 생성하거나 Plugin을 적용하는 등 설정을 변경하면, 이 정보는 먼저 중앙 데이터베이스(PostgreSQL 또는 Cassandra)에 저장된다.4
하지만 클러스터 내의 각 Kong 노드는 매 요청마다 데이터베이스에 접근하지 않는다. 이는 성능에 심각한 병목을 유발할 수 있기 때문이다. 대신, 각 노드의 Worker 프로세스는 데이터베이스로부터 읽어온 설정을 자체적인 인메모리 캐시(LMDB 기반)에 저장하고, 실제 요청 처리 시에는 이 캐시를 사용한다.10 이 캐싱 메커니즘은 데이터베이스 접근으로 인한 오버헤드를 제거하여 Kong의 낮은 지연 시간을 유지하는 핵심적인 역할을 한다.
설정 변경이 데이터베이스에 적용되었을 때, 이 변경 사항이 각 노드의 캐시에 전파되는 데에는 약간의 시간이 소요된다. 각 노드는 주기적으로 데이터베이스의 변경 사항을 확인하여 캐시를 갱신하거나, Admin API를 통해 특정 노드에 캐시 무효화 신호를 보내 즉시 갱신을 유도할 수 있다. 이 ‘결과적 일관성(eventual consistency)’ 모델은 대규모 클러스터 환경에서 설정 전파의 부하를 줄이고 각 노드의 독립적인 운영을 보장한다.
Kong 클러스터의 각 노드 내에서는 여러 Worker 프로세스가 병렬로 동작한다. 이들 Worker 간에 상태를 동기화해야 할 필요가 있는데(예: 업스트림 서비스의 Health Check 결과 공유, 설정 캐시 무효화 신호 전파 등), 이를 위한 통신 메커니즘은 Kong 3.0을 기점으로 중요한 기술적 진화를 겪었다.
기존 방식 (lua-resty-worker-events): Kong 3.0 이전 버전에서는 lua-resty-worker-events라는 라이브러리를 사용했다. 이 방식의 핵심은 Nginx의 공유 메모리(shared memory)와 타이머 기반 폴링(polling)이다.12 한 Worker 프로세스가 다른 Worker들에게 알리고 싶은 이벤트가 발생하면, 해당 이벤트 데이터를 공유 메모리 영역에 기록한다. 그러면 다른 모든 Worker 프로세스들은 정해진 시간 간격(예: 1초)마다 타이머를 통해 깨어나 공유 메모리를 확인하고, 새로운 이벤트가 있으면 가져와서 처리하는 방식이다. 이 접근법은 구현이 비교적 간단하다는 장점이 있지만, 명백한 한계를 가지고 있었다. 첫째, 폴링 방식은 이벤트가 없을 때도 주기적으로 CPU 자원을 소모하여 비효율적이다. 둘째, 이벤트 발생과 감지 사이에 최대 폴링 주기만큼의 지연이 발생하여 실시간성이 떨어진다. 셋째, 공유 메모리의 크기가 제한되어 있어 짧은 시간에 대량의 이벤트가 발생하면 메모리가 가득 차 후속 이벤트가 유실될 위험이 있었다.12
개선된 방식 (lua-resty-events): 이러한 한계를 극복하기 위해 Kong 3.0부터는 lua-resty-events라는 새로운 라이브러리가 도입되었다. 이는 단순한 라이브러리 교체를 넘어, Kong의 내부 통신 패러다임을 ‘주기적 확인’에서 ‘실시간 알림’으로 바꾼 근본적인 아키텍처 전환이었다. 이 새로운 메커니즘은 Pub/Sub(발행/구독) 모델과 UNIX 도메인 소켓을 기반으로 한다.12 클러스터 내의 Nginx Worker 프로세스 중 단 하나가 ‘이벤트 브로커(event-broker)’ 역할을 맡는다. 이 브로커는 UNIX 도메인 소켓을 열고 다른 워커들의 연결을 기다린다. 이벤트를 발행(publish)하려는 다른 워커(‘publisher’)는 이 소켓을 통해 브로커에게 이벤트를 전송하고, 이벤트를 구독(subscribe)하려는 워커(‘subscriber’)들은 브로커에 연결하여 이벤트를 수신한다. 이 방식은 Nginx의 핵심인 이벤트 루프와 리눅스의
epoll과 같은 고성능 I/O 이벤트 알림 기능을 직접 활용하기 때문에, 폴링으로 인한 불필요한 CPU 낭비가 전혀 없다. 이벤트가 발생했을 때만 동작하므로 매우 효율적이며, 지연 시간도 거의 없다. 실제 벤치마크 결과, 대량의 이벤트가 발생하는 시나리오에서 lua-resty-events는 기존 방식에 비해 RPS(초당 요청 수)가 약 50% 향상되고 지연 시간이 개선되었으며, CPU 사용률은 70-90%에서 50% 수준으로 현저히 낮아지는 성능 향상을 보였다.12
이러한 기술적 진화는 Kong이 단순한 API 게이트웨이를 넘어, 실시간 정책 동기화와 빠른 이벤트 전파가 필수적인 서비스 메시(Kong Mesh)나 동적인 AI 라우팅과 같은 고도화된 기능을 안정적으로 지원할 수 있는 견고한 기반을 마련했다. 즉, 이 내부 통신 아키텍처의 혁신은 Kong의 제품 로드맵과 미래 전략적 확장을 가능하게 한 핵심 동력이라고 평가할 수 있다.
Kong은 마이크로서비스 아키텍처에서 발생하는 공통적인 문제들을 해결하기 위해 설계된 다양한 핵심 기능들을 제공한다. 이러한 기능들은 단순히 나열된 도구의 집합이 아니라, ‘추상화’와 ‘위임’이라는 일관된 설계 사상 아래 유기적으로 결합되어 있다. 이 장에서는 라우팅부터 관측 가능성에 이르는 Kong의 핵심 기능들을 살펴보고, 그 기저에 깔린 설계 철학을 분석한다.
Kong의 라우팅 시스템은 요청을 적절한 백엔드 서비스로 전달하는 역할을 하며, 이는 Service, Route, Upstream, Target이라는 네 가지 핵심 객체(Entity)의 조합을 통해 매우 유연하게 구성된다.
Service와 Route의 분리: Kong의 라우팅 설계에서 가장 중요한 특징은 Service와 Route의 개념적 분리다.
Service는 업스트림 API 또는 마이크로서비스에 대한 논리적 추상화다. 여기에는 업스트림의 호스트 주소, 포트, 프로토콜 등의 정보가 포함된다.6Route는 클라이언트로부터 들어오는 요청을 특정 Service로 매핑하는 규칙의 집합이다. 라우팅 규칙은 요청의 호스트명, 경로, HTTP 메서드, 헤더 등 다양한 조건을 조합하여 정의할 수 있다.1이러한 분리 구조는 엄청난 유연성을 제공한다. 예를 들어, 하나의 Service에 /v1/orders와 /v2/orders라는 두 개의 다른 Route를 연결하여 버전 관리를 할 수 있다. 반대로, 백엔드 서비스의 물리적 위치가 변경되더라도 Service 객체의 호스트 정보만 수정하면, 해당 Service에 연결된 모든 Route는 아무런 변경 없이 새로운 백엔드 주소로 트래픽을 전달하게 된다. 이는 인프라의 물리적 배포와 API의 논리적 엔드포인트를 분리하는 강력한 추상화 계층을 제공하며, MSA의 핵심 가치인 ‘독립적 배포’를 게이트웨이 수준에서 실현시켜 준다.
Upstream과 Target을 통한 로드 밸런싱: Upstream과 Target 객체는 로드 밸런싱과 서비스 가용성 관리를 담당한다.
Upstream은 로드 밸런싱 대상이 되는 백엔드 서버들의 논리적인 그룹을 정의한다.Target은 Upstream에 속한 개별 백엔드 서버 인스턴스(IP 주소와 포트)를 나타낸다.17하나의 Service가 Upstream을 가리키도록 설정하고, 해당 Upstream에 여러 개의 Target을 등록하면, Kong은 이 Target들 사이에서 자동으로 트래픽을 분산시킨다. Kong은 다양한 로드 밸런싱 알고리즘을 지원한다 3:
Target 목록에 순차적으로 분배한다.Target으로 일관되게 요청을 보낸다. 이는 세션 지속성(Session Persistence 또는 Sticky Session)이 필요한 경우에 유용하다.3또한, Kong은 Active 및 Passive Health Check 기능을 통해 Target의 상태를 지속적으로 모니터링한다. Active Health Check는 Kong이 주기적으로 Target에 상태 확인 요청을 보내 응답을 확인하는 방식이며, Passive Health Check는 실제 클라이언트 요청 처리 중 발생하는 실패(예: TCP 연결 실패, HTTP 5xx 에러)를 감지하는 방식이다. 비정상으로 판단된 Target은 로드 밸런싱 풀에서 자동으로 제외되며, 이후 다시 정상 상태로 복구되면 자동으로 풀에 포함된다. 이 기능은 시스템의 회복탄력성을 높이고 서비스 중단을 방지하는 데 필수적이다.2
분산된 마이크로서비스 환경에서 각 서비스가 개별적으로 인증 및 인가 로직을 구현하는 것은 매우 비효율적이고 일관성을 해칠 수 있다. Kong은 이러한 보안 관련 횡단 관심사를 게이트웨이에서 중앙 집중적으로 처리할 수 있도록 강력한 인증/인가 플러그인 생태계를 제공한다.2
API 사용자는 Kong에서 Consumer라는 객체로 표현된다. 이 Consumer 객체에 다양한 인증 플러그인의 자격증명(credential)을 연결하여 사용자별로 인증 정책을 적용할 수 있다.18 Kong이 제공하는 주요 인증 플러그인은 다음과 같다.
Authorization 헤더에 담아 전송한다. 간단하지만 자격증명이 암호화되지 않으므로 반드시 HTTPS와 함께 사용해야 한다.3이러한 기능들은 모두 ‘위임’이라는 Kong의 핵심 설계 철학을 보여준다. Kong 코어는 인증 로직을 직접 수행하지 않고, 프록시와 플러그인 실행 환경만을 제공한다. 실제 인증 정책의 구현은 각 플러그인에 위임됨으로써, Kong의 코어는 가볍고 고성능을 유지하면서도 새로운 인증 표준이나 기술이 등장했을 때 유연하게 대응할 수 있는 확장성을 확보하게 된다.
서비스의 안정성을 보장하고 악의적인 공격으로부터 시스템을 보호하기 위해, Kong은 다양한 트래픽 제어 및 보안 플러그인을 제공한다.
Consumer, 클라이언트 IP 주소, 특정 서비스 등 다양하게 설정할 수 있다.3 이는 과도한 트래픽으로 인한 서비스 다운을 방지하고, 특정 사용자의 API 남용을 막으며, 서비스 거부(Denial of Service, DoS) 공격에 대한 기본적인 방어선을 구축하는 데 매우 효과적이다.3Consumer를 특정 그룹으로 묶고, 이 그룹에 특정 Service나 Route에 대한 접근 권한을 부여하거나 거부하는 방식으로 세밀한 접근 제어를 가능하게 한다.19 예를 들어, ‘프리미엄 사용자’ 그룹에게만 특정 유료 API에 대한 접근을 허용하는 정책을 쉽게 구현할 수 있다.Access-Control-Allow-Origin 등)를 자동으로 추가하고 관리하여, 프론트엔드 개발의 복잡성을 줄여준다.19분산된 MSA 환경에서는 시스템의 현재 상태를 파악하고 문제가 발생했을 때 신속하게 원인을 추적하는 능력, 즉 관측 가능성(Observability)이 매우 중요하다. Kong은 API 트래픽의 중심에 위치하기 때문에, 관측 가능성 데이터를 수집하는 데 이상적인 지점이다. Kong은 다양한 로깅 및 모니터링 플러그인을 통해 이를 지원한다.2
로깅: Kong은 요청 및 응답에 대한 상세한 데이터를 다양한 목적지로 전송할 수 있는 플러그인들을 제공한다. File Log는 로그를 로컬 파일에 저장하고, HTTP Log는 지정된 HTTP 엔드포인트로 로그 데이터를 POST 방식으로 전송한다. 또한 TCP Log, UDP Log, Syslog 플러그인을 통해 표준적인 로그 수집 시스템과 쉽게 연동할 수 있다.19 대규모 트래픽 환경에서는
Kafka Log 플러그인(Enterprise)을 사용하여 로그를 Apache Kafka 클러스터로 안정적으로 스트리밍할 수 있다.19
모니터링 및 추적:
Prometheus 플러그인은 Kong의 상태와 트래픽에 대한 핵심 메트릭(예: API 지연 시간, 요청 수, HTTP 상태 코드 분포, Nginx 연결 상태 등)을 Prometheus가 수집할 수 있는 형식으로 노출한다. 이 데이터를 Grafana와 같은 시각화 도구와 결합하면 시스템 상태를 한눈에 파악할 수 있는 강력한 대시보드를 구축할 수 있다.19결론적으로, Kong의 핵심 기능들은 MSA가 요구하는 공통적인 요구사항들을 해결하기 위해 정교하게 설계되었다. ‘추상화’를 통해 인프라의 복잡성을 숨기고 개발 유연성을 제공하며, ‘위임’을 통해 코어의 성능을 유지하면서 무한한 기능 확장을 가능하게 하는 설계 철학은 Kong이 현대적인 API 관리 솔루션으로서 성공할 수 있었던 핵심적인 이유라 할 수 있다.
Kong의 가장 강력한 특징은 단연코 플러그인 아키텍처다. Kong의 핵심(Core)은 고성능 프록시와 플러그인을 실행하기 위한 최소한의 기능만을 제공하며, 인증, 보안, 트래픽 제어, 로깅 등 거의 모든 부가 기능은 플러그인을 통해 구현된다. 이러한 설계는 Kong에 무한한 확장성과 유연성을 부여하며, 사용자는 필요한 기능을 마치 레고 블록처럼 조립하여 자신만의 API 게이트웨이를 구축할 수 있다. 이 장에서는 Kong 플러그인의 내부 구조, 실행 메커니즘, 그리고 직접 플러그인을 개발하는 방법을 심층적으로 탐구한다.
Kong 플러그인은 본질적으로 특정 구조를 따르는 Lua 모듈의 집합이다.14 Kong이 플러그인을 인식하고 로드하기 위해서는 kong.plugins.<플러그인_이름>.<모듈_이름>이라는 명명 규칙을 따라야 한다. 가장 단순한 형태의 플러그인은 두 개의 필수 파일로 구성된다.14
handler.lua: 플러그인의 심장부로, 실제 로직이 구현되는 곳이다. 이 파일은 Kong의 요청 처리 라이프사이클의 각 단계(phase)에 해당하는 이름의 함수들을 포함하는 테이블을 반환해야 한다. 예를 들어, 요청이 업스트림으로 전달되기 전에 실행될 로직은 access 함수 내에 구현한다. Kong은 요청 처리 과정에서 적절한 시점에 이 함수들을 자동으로 호출한다.14schema.lua: 플러그인의 설정 스키마를 정의하는 파일이다. 사용자가 Admin API나 설정 파일을 통해 플러그인을 구성할 때 입력할 수 있는 필드들의 명세서 역할을 한다. 각 필드의 데이터 타입(문자열, 숫자, 불리언 등), 필수 여부, 기본값, 그리고 커스텀 유효성 검증 로직 등을 정의할 수 있다. 이 스키마 덕분에 Kong은 사용자가 유효하지 않은 설정을 입력하는 것을 사전에 방지하고, 일관된 방식으로 플러그인 설정을 관리할 수 있다.14단순한 기능의 플러그인은 이 두 파일만으로 충분하지만, 더 복잡한 요구사항을 충족하기 위해 추가적인 모듈을 포함할 수 있다.14
daos.lua: 플러그인이 고유의 데이터를 데이터베이스에 영속적으로 저장해야 할 때 사용된다. 이 파일은 플러그인과 관련된 커스텀 엔티티(entity)와 데이터베이스 테이블 간의 매핑을 정의하는 데이터 접근 객체(Data Access Object, DAO)의 스키마를 정의한다. 예를 들어, key-auth 플러그인은 API 키 정보를 저장하기 위해 이 모듈을 사용한다.api.lua: daos.lua를 통해 정의된 커스텀 엔티티를 외부에서 관리할 수 있도록 Kong의 Admin API에 새로운 엔드포인트를 추가한다. 예를 들어, /consumers/{consumer_id}/key-auth와 같은 엔드포인트를 정의하여 특정 소비자의 API 키를 생성하고 관리할 수 있게 해준다.migrations/\*.lua: daos.lua에서 정의한 데이터 모델에 필요한 데이터베이스 스키마 변경 사항을 관리한다. 테이블 생성, 컬럼 추가 등 데이터베이스 마이그레이션 로직을 담고 있으며, Kong이 시작되거나 마이그레이션 명령이 실행될 때 순차적으로 적용된다.Kong 플러그인이 강력한 이유는 요청이 들어와서 응답이 나가기까지의 전 과정, 즉 라이프사이클의 여러 단계에 정밀하게 개입할 수 있기 때문이다. 플러그인의 실행 여부와 순서는 범위(Scope), 우선순위(Precedence), 그리고 우선도(Priority)라는 다층적인 규칙에 의해 결정된다. 이 메커니즘을 이해하는 것은 여러 플러그인을 조합하여 복잡한 정책을 구현할 때 필수적이다.
Kong은 Nginx의 내부 처리 단계를 추상화하여, 플러그인이 로직을 실행할 수 있는 명확한 진입점(entry point)들을 제공한다. 주요 실행 단계는 아래 표와 같다.23
| 함수명 (Phase) | Kong Gateway 단계 | Nginx 지시어 | 지원 프로토콜 | 설명 및 주요 사용 사례 | 관련 Snippets |
|---|---|---|---|---|---|
init_worker |
init_worker |
init_worker_by_* |
HTTP(S), Stream | Nginx 워커 프로세스 시작 시 실행. 플러그인 초기화, 타이머 설정. | 23 |
certificate |
certificate |
ssl_certificate_by_* |
HTTP(S), Stream | SSL 핸드셰이크 중 동적으로 SSL 인증서 선택. | 23 |
rewrite |
rewrite |
rewrite_by_* |
HTTP(S) | 라우팅 전 요청 URI 수정. 전역 플러그인만 실행 가능. | 23 |
access |
access |
access_by_* |
HTTP(S), gRPC(S), WS(S) | 업스트림으로 요청 전송 직전 실행. 인증, 인가, 속도 제한 등 대부분의 정책 실행. | 23 |
response |
response |
header_filter_by_*, body_filter_by_* |
HTTP(S), gRPC(S) | 업스트림에서 전체 응답 수신 후, 클라이언트로 전송 전 실행. 응답 전체를 버퍼링 후 변환. | 23 |
header_filter |
header_filter |
header_filter_by_* |
HTTP(S), gRPC(S) | 업스트림에서 응답 헤더 수신 시 실행. 헤더 수정. | 23 |
body_filter |
body_filter |
body_filter_by_* |
HTTP(S), gRPC(S) | 업스트림에서 응답 바디 청크 수신 시마다 실행. 스트리밍 데이터 변환. | 23 |
log |
log |
log_by_* |
HTTP(S), gRPC(S), Stream | 클라이언트로 최종 응답 전송 후 실행. 로깅, 메트릭 전송. | 23 |
preread |
preread |
preread_by_* |
Stream | TCP/UDP 연결 수립 시 실행. L4 수준의 정책 적용. | 23 |
플러그인은 특정 컨텍스트에만 적용되도록 범위를 지정할 수 있다. 적용 가능한 범위는 전역(Global), Service, Route, Consumer, Consumer Group 및 이들의 조합이다.23 하나의 요청에 대해 여러 범위의 플러그인 설정이 동시에 적용될 수 있을 때, Kong은
가장 구체적인(most specific) 범위의 설정을 단 하나만 선택하여 적용한다. 이를 우선순위(Precedence) 규칙이라 한다. 우선순위는 다음과 같이 결정된다.23
Consumer + Route + Service (가장 높음)Consumer group + Service + RouteRouteServiceGlobal (가장 낮음)예를 들어, 어떤 요청이 특정 Route와 Consumer에 모두 매칭되고, 해당 Route에 적용된 rate-limiting 플러그인과 해당 Consumer에 적용된 rate-limiting 플러그인이 모두 존재한다면, Consumer + Route 조합이 더 구체적이므로 해당 조합에 대한 플러그인 설정이 있다면 그것이 적용된다. 만약 없다면 그 다음 순위인 Consumer에 대한 설정이 적용된다. 중요한 점은 하나의 플러그인은 요청당 단 한 번, 가장 우선순위가 높은 설정으로 실행된다는 것이다.23
우선순위(Precedence)가 어떤 플러그인 설정을 사용할지 결정한다면, 우선도(Priority)는 동일한 실행 단계(access 등)에서 실행되어야 하는 서로 다른 플러그인들의 실행 순서를 결정한다. 이 순서는 각 플러그인의 handler.lua 파일에 상수로 정의된 PRIORITY 값에 의해 결정되며, 숫자가 높을수록 먼저 실행된다.21 예를 들어, 분산 추적을 위한
zipkin 플러그인(PRIORITY: 100000)은 인증을 수행하는 oauth2 플러그인(PRIORITY: 1004)보다 항상 먼저 실행되어야 인증 실패 요청까지도 추적할 수 있다.21 이 정적 우선도 시스템은 예측 가능한 실행 순서를 보장하지만, 유연성이 부족하다는 단점이 있었다. 이 때문에 최근 버전에서는
access 단계에 한해 설정 파일에서 플러그인 실행 순서를 동적으로 지정할 수 있는 기능(Dynamic Plugin Ordering)이 도입되었다.24
이처럼 Kong의 플러그인 실행 메커니즘은 다층적이고 결정론적인 규칙을 따르는 정교한 상태 기계(Deterministic State Machine)와 같다. 하나의 요청은 정해진 상태(Phase)를 순차적으로 거치며, 각 상태에서 어떤 플러그인이 어떤 설정으로, 어떤 순서로 실행될지가 Scope, Precedence, Priority 규칙에 의해 명확하게 결정된다. 이 예측 가능성은 복잡한 정책 조합을 안정적으로 운영할 수 있게 해주지만, 동시에 플러그인이 예상대로 동작하지 않을 때 이 세 가지 차원을 모두 고려해야 하는 디버깅의 복잡성을 야기하기도 한다. 이는 Kong을 효과적으로 운영하기 위해 반드시 이해해야 할 핵심적인 기술적 깊이다.
Kong의 방대한 공식 플러그인 허브로도 해결할 수 없는 고유한 비즈니스 로직이나 내부 시스템 연동이 필요할 때, 사용자는 직접 플러그인을 개발할 수 있다. Kong은 전통적인 Lua 뿐만 아니라 Go, Python, JavaScript 등 더 널리 사용되는 언어로도 플러그인을 개발할 수 있도록 지원한다.5
PDK (Plugin Development Kit): 언어에 상관없이 플러그인 개발을 용이하게 하기 위해 Kong은 PDK(플러그인 개발 키트)를 제공한다. PDK는 플러그인 코드 내에서 Kong의 핵심 기능과 상호작용할 수 있도록 미리 정의된 함수와 변수들의 집합이다.14 예를 들어,
kong.request.get_header() 함수로 요청 헤더를 읽거나, kong.response.set_header() 함수로 응답 헤더를 설정하고, kong.log.err() 함수로 에러 로그를 남기는 등의 작업을 간단하게 수행할 수 있다.26 PDK는 플러그인 개발자가 Nginx나 OpenResty의 저수준 API를 직접 다루지 않고도 강력한 기능을 구현할 수 있도록 추상화 계층을 제공한다.
Go를 이용한 플러그인 개발: Go는 강력한 동시성 모델과 정적 타입 시스템 덕분에 서버 사이드 개발에서 인기가 높다. Kong은 Go로 플러그인을 개발할 수 있도록 go-pdk 라이브러리를 제공한다.26 Go 플러그인은 독립적인 실행 파일로 컴파일되어 ‘플러그인 서버’로 동작한다. Kong은 이 플러그인 서버와 RPC(Remote Procedure Call)를 통해 통신하며, 요청 처리의 각 단계마다 해당 핸들러 함수를 호출한다.
Go 플러그인 개발 과정은 일반적으로 다음과 같다 27:
go-pdk 라이브러리를 임포트하여 프로젝트를 설정한다.Config 구조체를 정의한다.Access, Response 등 필요한 라이프사이클 단계에 해당하는 메서드를 구현한다. 이 메서드들은 *pdk.PDK 객체를 인자로 받아 PDK 함수들을 호출할 수 있다.main 함수에서 server.StartServer를 호출하여 플러그인 서버를 실행하는 코드를 작성한다.KONG_PLUGINS, KONG_PLUGINSERVER_NAMES, KONG_PLUGINSERVER_<plugin_name>_START_CMD)를 설정하여 Kong이 플러그인 서버를 인식하고 실행할 수 있도록 구성한다.이처럼 Kong은 다양한 언어를 지원하는 PDK를 통해 개발자들이 자신에게 익숙한 기술 스택을 활용하여 Kong의 기능을 자유롭게 확장할 수 있는 강력하고 개방적인 개발 생태계를 제공한다.
Kong API 게이트웨이의 강력한 기능을 실제 운영 환경에서 안정적으로 활용하기 위해서는 조직의 아키텍처, 운영 모델, 확장성 요구사항에 맞는 최적의 배포 및 운영 전략을 선택하는 것이 매우 중요하다. Kong은 전통적인 데이터베이스 기반 모드부터 클라우드 네이티브 환경에 최적화된 DB-less 모드, 그리고 대규모 분산 환경을 위한 하이브리드 모드까지 다양한 배포 옵션을 제공한다.
Kong의 배포 모드는 단순히 설정 데이터를 어디에 저장하느냐의 문제를 넘어, 인프라 관리 철학과 운영 패러다임의 선택을 의미한다. 각 모드의 특성을 이해하는 것은 성공적인 Kong 도입의 첫걸음이다.
DB-backed Mode (전통 모드): 이 모드는 Kong의 모든 설정(Services, Routes, Plugins, Consumers 등)을 PostgreSQL이나 Cassandra와 같은 외부 데이터베이스에 저장한다.4 가장 큰 장점은 유연성이다. 운영 중인 Kong 클러스터에 Admin API(
:8001)를 통해 실시간으로 설정을 동적으로 변경하고 즉시 적용할 수 있다.11 클러스터의 모든 노드는 동일한 데이터베이스를 바라보므로 설정의 일관성이 보장된다. 하지만 이는 데이터베이스라는 추가적인 의존성을 만들어내며, 데이터베이스의 설치, 관리, 백업, 고가용성 구성에 대한 운영 부담이 발생한다는 단점이 있다.32 이 모드는 전통적인 IT 환경의 ‘가변 인프라(Mutable Infrastructure)’ 모델, 즉 배포된 시스템을 런타임에 변경하는 방식에 적합하다.
DB-less Mode (선언적 모드): 클라우드 네이티브와 CI/CD 환경의 부상에 발맞춰 등장한 모드다. 이 모드에서는 데이터베이스 없이, YAML이나 JSON 형태의 선언적 설정 파일 하나로 Kong의 모든 상태를 정의한다.33 Kong 프로세스는 시작 시 이 파일을 읽어 모든 설정을 메모리에 로드하여 동작한다. 설정 파일이 ‘단일 진실 공급원(Single Source of Truth)’이 되므로, Git과 같은 버전 관리 시스템으로 설정을 관리하고 변경 이력을 추적하는 GitOps 워크플로우를 구현하기에 이상적이다.33 데이터베이스 의존성이 사라져 배포가 단순해지고 운영이 가벼워지는 큰 장점이 있다. 그러나 런타임에 동적으로 설정을 변경하는 것이 제한되며, Admin API는 사실상 읽기 전용(read-only)으로 동작한다.31 또한, 데이터베이스에 상태를 저장해야 하는 일부 플러그인(예: Rate Limiting의 클러스터링 모드)은 사용이 제한될 수 있다.36 이 모드는 ‘불변 인프라(Immutable Infrastructure)’ 패러다임, 즉 설정 변경 시 새로운 버전의 이미지를 빌드하여 재배포하는 방식에 최적화되어 있다.
Hybrid Mode (하이브리드 모드): 이 모드는 대규모 분산 환경의 요구사항을 충족하기 위해 제어 평면(Control Plane, CP)과 데이터 평면(Data Plane, DP)을 물리적으로 분리한 아키텍처다.37
Control Plane (CP): 데이터베이스에 연결되어 있으며, Admin API를 통해 모든 설정을 중앙에서 관리하는 역할을 한다. 실제 클라이언트 트래픽은 처리하지 않는다.
Data Plane (DP): 데이터베이스에 직접 연결되지 않으며, CP로부터 설정 정보를 받아와 메모리에 캐싱한 후 오직 클라이언트 트래픽을 프록시하는 역할만 수행한다.39
이 구조를 통해 관리 지점(CP)은 중앙 데이터 센터에 안전하게 위치시키고, 가볍고 상태 비저장(stateless)인 DP 노드들은 전 세계 여러 지역이나 엣지(edge)에 분산 배포하여 사용자와 가까운 곳에서 트래픽을 처리할 수 있다. 이를 통해 지연 시간을 줄이고, DP 노드만 독립적으로 확장할 수 있어 뛰어난 확장성과 유연성을 제공한다. CP와 DP 간의 통신은 mTLS를 통해 안전하게 암호화된다.40 Hybrid 모드는 ‘중앙 집중식 제어, 분산 실행’이라는 현대적인 대규모 시스템 운영 모델을 구현한 것이다.
이처럼 Kong의 배포 모드를 선택하는 것은 단순히 기술적 선호의 문제가 아니라, 조직의 인프라 관리 철학, 자동화 수준, 그리고 애플리케이션의 아키텍처적 요구사항을 종합적으로 고려해야 하는 전략적 결정이다.
| 특성 | DB-backed Mode (전통 모드) | DB-less Mode (선언적 모드) | Hybrid Mode (하이브리드 모드) |
|---|---|---|---|
| 구성 데이터 저장소 | PostgreSQL 또는 Cassandra | 인메모리 (YAML/JSON 파일에서 로드) | Control Plane: PostgreSQL, Data Plane: 인메모리 |
| 구성 관리 방식 | 동적 (Admin API를 통한 실시간 변경) | 정적/선언적 (설정 파일 기반, 재시작/리로드 필요) | Control Plane에서 동적 관리, Data Plane으로 전파 |
| Admin API 기능 | 전체 CRUD (읽기/쓰기) | 제한적 (주로 읽기 전용, 설정 리로드) | CP: 전체 CRUD, DP: 없음 (상태 보고만 가능) |
| 주요 장점 | 높은 유연성, 동적 런타임 구성 | GitOps 친화적, CI/CD 통합 용이, 의존성 감소, 운영 단순화 | 대규모 분산 환경, 중앙 집중식 제어, 데이터 플레인의 독립적 확장 |
| 주요 단점 | 데이터베이스 의존성 및 관리 부담, 설정 변경의 비결정성 | 런타임 유연성 부족, 일부 DB 의존 플러그인 사용 불가 | 아키텍처 복잡도 증가, CP와 DP 간 통신 관리 필요 |
| 적합한 사용 사례 | 소규모 또는 동적 환경, GUI(Kong Manager) 활용이 중요한 경우 | Kubernetes 네이티브 환경, 자동화된 배포 파이프라인, 불변 인프라 | 멀티 클라우드/리전, 엣지 컴퓨팅, 엄격한 관리/실행 평면 분리 요구 |
| 관련 Snippets | 4 | 33 | 37 |
배포 모드에 따라 Kong의 설정을 관리하는 방식도 달라진다.
Admin API: DB-backed 모드의 기본 설정 관리 방법이다. RESTful API를 통해 curl과 같은 HTTP 클라이언트를 사용하여 프로그래밍 방식으로 Kong의 모든 객체를 생성, 조회, 수정, 삭제(CRUD)할 수 있다.6 이는 스크립트를 통한 자동화나 Konga와 같은 GUI 도구와의 연동을 가능하게 한다.
선언적 설정 파일: DB-less 모드의 유일한 설정 관리 방법이다. kong.yml 또는 kong.json 파일에 모든 Service, Route, Plugin 등의 구성을 선언적으로 기술한다.10 Kong은 시작 시
declarative_config 속성이나 KONG_DECLARATIVE_CONFIG 환경 변수로 지정된 이 파일을 읽어 자신의 상태를 구성한다.41
decK: decK(Declarative configuration for Kong)는 선언적 설정 파일을 사용하여 Kong의 상태를 관리하는 CLI 도구다. DB-backed 모드에서도 선언적 관리 방식을 적용할 수 있게 해준다. deck sync 명령어를 사용하면 로컬 설정 파일의 내용과 실행 중인 Kong 클러스터의 상태를 비교하여 차이점(drift)을 감지하고 동기화할 수 있다. 이는 GitOps 워크플로우를 DB-backed 환경에서도 구현할 수 있게 해주는 강력한 도구다.42
Kong은 클라우드 네이티브 철학에 따라 설계되었으며, Docker와 Kubernetes와 같은 컨테이너 환경에서의 배포가 표준으로 여겨진다.
Docker: Kong은 공식 Docker 이미지를 제공하여 배포를 매우 간단하게 만든다. docker run 명령어를 사용하거나, docker-compose.yml 파일을 작성하여 Kong과 데이터베이스(DB-backed 모드의 경우) 컨테이너를 함께 띄우고 네트워크로 연결하는 것이 일반적인 방식이다.4
Kubernetes: Kubernetes 환경에서 Kong은 주로 인그레스 컨트롤러(Ingress Controller)로서의 역할을 수행한다. Kong Ingress Controller(KIC)는 Kubernetes API 서버를 감시하다가 Ingress 리소스나 Kong 고유의 CRD(Custom Resource Definitions)의 변경 사항을 감지하고, 이를 Kong Admin API 호출로 자동 변환하여 Kong의 라우팅 설정을 동적으로 업데이트한다.30 KIC는
KongIngress, KongPlugin, KongConsumer와 같은 CRD를 제공하여, Kubernetes의 네이티브 방식(kubectl apply -f...)으로 Kong의 모든 기능을 선언적으로 관리할 수 있게 해준다.9
Helm Chart: Kubernetes에 Kong을 배포하는 가장 권장되는 방법은 공식 Helm Chart를 사용하는 것이다.30 Helm은 Kubernetes의 패키지 관리자로, 복잡한 애플리케이션 배포를 차트(Chart)라는 단위로 표준화한다. Kong Helm Chart를 사용하면
values.yaml 파일에 원하는 설정을 정의하는 것만으로 KIC, Kong 프록시, 데이터베이스 등 필요한 모든 컴포넌트를 일관되고 재현 가능하게 배포할 수 있다.40
운영 환경에서 API 게이트웨이는 시스템 전체의 단일 장애점(Single Point of Failure, SPOF)이 될 수 있으므로, 고가용성(HA) 구성은 필수적이다.
Kong의 HA 아키텍처의 핵심은 여러 개의 Kong 노드를 클러스터로 구성하고, 그 앞단에 로드 밸런서(L4 또는 L7)를 배치하는 것이다.10 로드 밸런서는 들어오는 트래픽을 여러 Kong 노드에 분산시키고, 특정 노드에 장애가 발생하면 이를 감지하여 트래픽을 건강한(healthy) 노드들로만 전달한다.17 이를 통해 개별 Kong 노드의 장애가 전체 서비스의 중단으로 이어지는 것을 방지한다.
DB-backed 모드에서는 Kong 노드뿐만 아니라 데이터베이스 자체의 고가용성도 반드시 확보해야 한다. PostgreSQL의 스트리밍 복제(Streaming Replication)나 Patroni와 같은 클러스터링 솔루션을 사용하여 데이터베이스의 이중화를 구성해야 한다.45
반면, Hybrid 모드는 HA 구성에 구조적으로 더 유리하다. 데이터 평면(DP) 노드들은 상태를 가지지 않으므로(stateless), 단순히 노드 수를 늘리는 것만으로 쉽게 수평적 확장이 가능하며, 각 노드가 독립적으로 동작하여 장애 전파의 위험이 적다.37
Kong은 더 이상 단순한 오픈소스 API 게이트웨이에 머무르지 않는다. Kong Inc.는 Enterprise 제품과 클라우드 서비스를 통해 강력한 상업적 생태계를 구축하고 있으며, 서비스 메시와 AI라는 현대 애플리케이션 아키텍처의 핵심 트렌드를 적극적으로 수용하며 기술적 리더십을 확장하고 있다. 이는 Kong의 전략적 비전이 ‘API 게이트웨이’를 넘어, 모든 유형의 애플리케이션 트래픽을 아우르는 ‘통합 서비스 연결 플랫폼(Unified Service Connectivity Platform)’으로 진화하고 있음을 명확히 보여준다.
Kong은 오픈소스(OSS) 버전의 성공을 기반으로, 대규모 기업 환경의 요구사항을 충족하기 위한 상용 제품군을 제공한다.
마이크로서비스 아키텍처가 성숙함에 따라, 외부에서 서비스로 들어오는 남-북(North-South) 트래픽뿐만 아니라, 서비스와 서비스 간의 내부 통신인 동-서(East-West) 트래픽을 관리하는 것의 중요성이 커졌다. 서비스 메시는 바로 이 동-서 트래픽을 관리하기 위한 전용 인프라 계층이다.
Kong은 CNCF(Cloud Native Computing Foundation)의 인큐베이팅 프로젝트인 오픈소스 서비스 메시 Kuma를 인수하고, 이를 기반으로 엔터프라이즈 제품인 Kong Mesh를 출시했다.51 Kong Mesh는 서비스와 함께 배포되는 사이드카 프록시(Sidecar Proxy)로 Envoy를 사용하며, 서비스 간의 모든 트래픽을 가로채어 제어한다.53
Kong Gateway와 Kong Mesh의 통합은 애플리케이션 내외부를 흐르는 모든 L4-L7 트래픽에 대한 포괄적인 관리 능력을 제공한다.
이러한 통합은 Kong을 단순한 ‘API 관리’ 솔루션에서 ‘서비스 연결성(Service Connectivity)’ 전반을 책임지는 플랫폼으로 한 단계 격상시켰다.
생성형 AI와 대규모 언어 모델(LLM)의 부상은 LLM API 호출이라는 새로운 형태의 트래픽을 폭발적으로 증가시켰다. 이 트래픽 역시 기존 API 트래픽과 마찬가지로 인증, 속도 제한, 로깅, 비용 관리, 보안 등 유사한 관리 요구사항을 가진다.
Kong은 이러한 시대적 변화에 발빠르게 대응하여, 기존의 강력한 게이트웨이 인프라와 플러그인 아키텍처를 활용해 AI Gateway로서의 기능을 확장하고 있다.5 Kong은 다양한 LLM 제공업체(OpenAI, Anthropic, Azure AI 등)에 대한 접근을 중앙에서 관리하고 추상화하는 여러 AI 관련 플러그인을 출시했다.19
AI Proxy: 여러 다른 LLM API의 요청/응답 형식을 표준화된 인터페이스로 통합하여, 백엔드 LLM을 쉽게 교체할 수 있게 해준다.AI Prompt 관련 플러그인: AI Prompt Template, AI Prompt Decorator, AI Prompt Guard 등을 통해 프롬프트에 동적으로 정보를 주입하거나, 특정 패턴을 검사하고, 민감 정보를 제거하는 등 정교한 프롬프트 엔지니어링을 게이트웨이 단에서 수행할 수 있다.AI Rate Limiting 및 AI Semantic Cache: 토큰(token) 사용량을 기준으로 속도를 제한하여 LLM API 비용을 제어하고, 의미적으로 유사한 프롬프트에 대한 응답을 캐싱하여 비용을 절감하고 응답 속도를 향상시킨다.이러한 기능들은 개발자들이 LLM을 애플리케이션에 통합할 때 겪는 공통적인 문제들을 게이트웨이 수준에서 해결해 줌으로써, AI 기반 애플리케이션의 개발과 운영을 가속화한다. 이는 Kong의 핵심 비전인 ‘모든 서비스 간의 연결을 중개하고 제어한다’는 철학이 새로운 기술 패러다임에도 일관되게 적용되고 있음을 보여주는 사례다.
Kong은 고성능을 핵심 가치로 삼고 있으며, 이를 객관적인 데이터로 입증하기 위해 정기적으로 성능 벤치마크를 수행하고 결과를 공개한다.58 최근 수행된 AI Gateway 성능 벤치마크에서는 경쟁 솔루션으로 꼽히는 Portkey, LiteLLM과 비교했을 때, 동일한 하드웨어 자원 조건에서 월등히 높은 처리량(RPS)과 낮은 지연 시간을 기록하며 기술적 우위를 입증했다.60
Kong Gateway의 성능을 최적화하기 위한 몇 가지 권장 사항은 다음과 같다 59:
access 단계에서 실행되는 플러그인의 수를 최소화하여 요청당 처리 오버헤드를 줄인다.proxy-cache 플러그인을 적극적으로 사용하여 반복적인 요청에 대한 업스트림 호출을 줄인다.결론적으로, Kong의 생태계는 오픈소스 커뮤니티의 힘과 엔터프라이즈 솔루션의 안정성을 결합하여 빠르게 확장하고 있다. API 게이트웨이라는 본연의 역할을 넘어 서비스 메시와 AI라는 미래 기술 트렌드를 선도하며, 모든 유형의 서비스 연결을 위한 통합 플랫폼으로 진화하려는 Kong의 전략적 방향성은 매우 명확하다.
API 게이트웨이 시장은 클라우드 네이티브 기술의 확산과 함께 빠르게 성장했으며, 다양한 철학과 강점을 가진 솔루션들이 치열하게 경쟁하고 있다. Kong의 시장 내 위치와 경쟁력을 이해하기 위해서는 주요 경쟁 제품들과의 다각적인 비교 분석이 필수적이다. 이 장에서는 Google의 Apigee, 오픈소스 기반의 Tyk, 그리고 AWS 생태계의 강자인 AWS API Gateway를 중심으로 기능, 아키텍처, 가격 모델, 개발자 경험을 비교하고, 사용 사례별 최적의 솔루션 선택 가이드를 제시한다.
시장에서 Kong과 직접적으로 비교되는 주요 API 게이트웨이는 다음과 같다.61
이러한 경쟁 구도는 단순히 개별 기능의 우위를 다투는 것을 넘어, 각 솔루션이 지향하는 근본적인 ‘플랫폼 철학’과 ‘생태계 전략’의 대결로 심화되고 있다. AWS API Gateway는 ‘통합 생태계’를, Apigee는 ‘비즈니스 플랫폼’을, 그리고 Kong은 ‘개방형 연결 플랫폼’을 지향한다. 이 철학의 차이는 각 솔루션의 아키텍처, 가격 모델, 그리고 개발자 경험 전반에 깊은 영향을 미친다.
각 게이트웨이는 서로 다른 기술 스택을 기반으로 하며, 이는 성능과 운영 특성에 직접적인 영향을 미친다. Kong은 검증된 Nginx/OpenResty 기반으로 낮은 지연 시간과 높은 처리량을 자랑한다. Tyk은 현대적인 클라우드 환경에 적합한 Go 언어를 기반으로 하여 높은 동시성 처리 능력을 강점으로 내세운다. Apigee는 Java 기반으로 추정되며, 엔터프라이즈급 안정성과 기능성에 초점을 맞춘다. AWS API Gateway는 내부 아키텍처가 공개되지 않은 관리형 서비스로, 사용자는 성능 튜닝보다는 AWS가 보장하는 SLA에 의존하게 된다.
가격 모델은 솔루션 선택에 있어 중요한 고려사항이다. Kong과 Tyk은 오픈소스 코어를 무료로 제공하고, 추가 기능과 기술 지원을 포함한 Enterprise 버전을 구독(subscription) 모델로 판매한다.49 이는 초기 도입 비용을 낮추고, 필요에 따라 상용 버전으로 전환할 수 있는 유연성을 제공한다. 반면, Apigee와 AWS API Gateway는 기본적으로 API 호출 수, 데이터 전송량, 활성 환경 수 등을 기반으로 하는 종량제(pay-as-you-go) 모델을 채택하고 있다.67 이 모델은 사용량이 적을 때는 비용 효율적일 수 있으나, 트래픽이 많은 대규모 서비스의 경우 비용이 급격히 증가하고 월별 비용을 예측하기 어렵다는 단점이 있다.6
개발자 경험(Developer Experience, DX)은 API 게이트웨이의 채택과 활용도에 큰 영향을 미친다. Kong은 선언적 설정(DB-less mode)과 decK을 통한 GitOps 지원, 그리고 다양한 언어로 플러그인을 직접 개발할 수 있는 높은 수준의 제어권과 유연성을 제공하여 개발자들에게 좋은 평가를 받는다. 다만, 그만큼 학습 곡선이 존재한다.61 Apigee는 잘 구성된 GUI 대시보드와 강력한 개발자 포털 기능을 통해 API 관리자와 API 소비자 모두에게 직관적인 경험을 제공하지만, 개발자가 직접 시스템을 제어할 수 있는 여지는 적다.63 Tyk은 사용 편의성과 빠른 시작을 강조하며, AWS API Gateway는 AWS 콘솔 및 CLI와의 완벽한 통합을 통해 기존 AWS 사용자에게 익숙하고 일관된 개발 경험을 제공한다.
어떤 API 게이트웨이가 ‘최고’라고 단정하기는 어렵다. 최적의 솔루션은 조직의 기술적 성숙도, 비즈니스 목표, 그리고 인프라 환경에 따라 달라진다.
결론적으로, API 게이트웨이를 선택하는 것은 단순히 기술 스펙을 비교하는 것을 넘어, 조직의 장기적인 기술 전략과 비즈니스 철학에 부합하는 플랫폼을 선택하는 과정이다.
| 기준 | Kong | Apigee | Tyk | AWS API Gateway |
|---|---|---|---|---|
| 오픈소스 코어 | 예 (Kong Gateway) | 아니요 | 예 (Tyk Gateway) | 아니요 |
| 주요 기반 기술 | Nginx + Lua/OpenResty | (Proprietary, Java 기반 추정) | Go | AWS 관리형 서비스 |
| 배포 옵션 | 자체 관리(On-prem), 하이브리드, 클라우드(Konnect) | SaaS(Apigee X), 하이브리드, 프라이빗 클라우드 | 자체 관리, 하이브리드, 클라우드 | 완전 관리형 SaaS |
| 핵심 강점 (플랫폼 철학) | 개방형 연결 플랫폼: 고성능, 플러그인 기반 확장성, 플랫폼 독립성 | 비즈니스 플랫폼: 풀 API 라이프사이클 관리, 수익화, 고급 분석 | 개발자 중심 플랫폼: Go 기반 고성능, 다양한 언어 확장, 풍부한 OSS 기능 | 통합 생태계: AWS 서비스와의 완벽한 통합, 서버리스 최적화 |
| 플러그인/확장성 | 매우 높음 (Lua, Go, JS, Python) | 정책 기반 구성, 제한적 확장 | 높음 (Go, Python, JS, Lua 등) | 제한적 (AWS 서비스 통합 위주) |
| 가격 모델 | OSS 무료, Enterprise 구독 | API 호출 기반 종량제, 구독 | OSS 무료, Enterprise 구독 | API 호출/데이터 전송 기반 종량제 |
| 적합한 조직/환경 | DevOps/GitOps 문화, 멀티/하이브리드 클라우드, 높은 커스터마이징 요구 | 대규모 엔터프라이즈, API 제품화 및 수익화 전략 | Go 생태계, 오픈소스 선호, 빠른 시작 요구 | AWS 중심 인프라, 서버리스 아키텍처, 관리 부담 최소화 |
| 관련 Snippets | 5 | 61 | 62 | 61 |
본 보고서는 Kong API 게이트웨이에 대한 다각적이고 심층적인 기술적 고찰을 제공했다. 분석을 통해 Kong은 단순한 리버스 프록시를 넘어, 현대적인 마이크로서비스 및 클라우드 네이티브 환경의 복잡성을 해결하기 위해 정교하게 설계된 강력한 플랫폼임이 명확해졌다.
Kong의 핵심 경쟁력은 세 가지 축으로 요약할 수 있다. 첫째, 탁월한 성능과 안정성이다. 수십 년간 검증된 Nginx를 기반으로 한 이벤트 기반 비동기 아키텍처는 대규모 트래픽을 낮은 지연 시간으로 처리할 수 있는 견고한 토대를 제공한다. 둘째, 압도적인 유연성과 확장성이다. OpenResty와 Lua를 통해 구현된 플러그인 아키텍처는 Kong의 기능을 무한히 확장할 수 있게 해주며, Go, Python 등 다양한 언어를 지원하는 PDK는 개발자 생태계를 풍성하게 만든다. 셋째, 플랫폼 독립성과 클라우드 네이티브 친화성이다. DB-less, Hybrid 모드와 같은 다양한 배포 옵션은 특정 인프라나 운영 모델에 종속되지 않고, GitOps와 CI/CD 파이프라인에 완벽하게 통합될 수 있는 유연성을 보장한다.
특히 Kong의 진화 과정은 주목할 만하다. 초기 API 게이트웨이로서 남-북 트래픽 관리에 집중했던 것을 넘어, Kong Mesh를 통해 서비스 간 동-서 트래픽까지 아우르고, 나아가 AI Gateway로서 새로운 유형의 트래픽을 포용하는 모습은 Kong의 전략적 비전이 ‘모든 서비스 간의 연결을 중개하고 제어하는 통합 서비스 연결 플랫폼’으로 확장되고 있음을 보여준다. 이는 기술 트렌드에 기민하게 대응하며 지속적으로 발전하려는 Kong의 의지를 명확히 드러내는 부분이다.
물론 Kong을 성공적으로 도입하고 운영하기 위해서는 몇 가지 핵심적인 고려사항이 수반된다. 조직의 운영 철학과 기술 성숙도에 맞는 최적의 배포 모드(DB-backed, DB-less, Hybrid)를 신중하게 선택해야 하며, 플러그인의 실행 순서를 결정하는 다층적인 규칙(Scope, Precedence, Priority)에 대한 깊은 이해는 복잡한 정책을 설계하고 문제를 해결하는 데 필수적이다.
경쟁 환경 속에서 Kong은 플랫폼 독립성과 개발자 중심의 높은 유연성을 무기로, 특정 벤더 생태계에 종속되기를 원치 않거나, 고도의 커스터마이징을 통해 시스템을 완벽하게 제어하고자 하는 기술 중심 조직에게 가장 매력적인 선택지로 자리매김하고 있다.
결론적으로 Kong API 게이트웨이는 기술적 깊이, 강력한 생태계, 그리고 미래지향적 비전을 모두 갖춘 성숙한 솔루션이다. 마이크로서비스, 멀티 클라우드, 그리고 AI가 주도하는 현대 IT 환경에서 안정적이고 유연하며 확장 가능한 서비스 연결의 허브를 구축하고자 하는 모든 조직에게 Kong은 가장 먼저 고려해야 할 강력한 선택지 중 하나임이 틀림없다.
| KONG - The Microservice API Gateway | by faren - Medium, 8월 3, 2025에 액세스, https://medium.com/@far3ns/kong-the-microservice-api-gateway-526c4ca0cfa6 |
| NGINX/OpenResty Event Handling Strategy for CPU Efficiency | Kong Inc., 8월 3, 2025에 액세스, https://konghq.com/blog/engineering/nginx-openresty-event-handling-strategy-for-cpu-efficiency |
| Custom plugin reference - Kong Gateway | Kong Docs, 8월 3, 2025에 액세스, https://developer.konghq.com/custom-plugins/reference/ |
| Load Balancing with Kong API Gateway using Docker | Moesif Blog, 8월 3, 2025에 액세스, https://www.moesif.com/blog/technical/kong/Load-Balancing-using-Kong-API-Gateway-with-Docker/ |
| Deep Dive into Kong Authentication Plugin | by Himank Batra - Medium, 8월 3, 2025에 액세스, https://medium.com/@himank.batra/deep-dive-into-kong-authentication-plugin-be6f3bf040d5 |
| Kong Plugin Hub | Kong Docs, 8월 3, 2025에 액세스, https://developer.konghq.com/plugins/ |
| Simplifying Kong Plugin Development: A Comprehensive Guide | by Or Sahar - Medium, 8월 3, 2025에 액세스, https://orsahar.medium.com/simplifying-kong-plugin-development-a-comprehensive-guide-b09f21f075d8 |
| Plugins - Kong Gateway | Kong Docs, 8월 3, 2025에 액세스, https://developer.konghq.com/gateway/entities/plugin/ |
| Deploying Kong DB less and Konga via Ready to Use Yaml files | by Nikhil YN - Medium, 8월 3, 2025에 액세스, https://medium.com/@nikhil.nagarajappa/deploying-kong-db-less-and-konga-via-raedy-to-use-yaml-files-38dce989674d |
| Kong Gateway: Helm Deployment in Kubernetes (Hybrid Mode) | by Ambidextrous - Medium, 8월 3, 2025에 액세스, https://ambidextrous-dev.medium.com/kong-gateway-helm-deployment-in-kubernetes-hybrid-mode-9c9ca9a76308 |
| Installing Kong Gateway on Kubernetes using Helm | by Onebitgod - Medium, 8월 3, 2025에 액세스, https://medium.com/@onebitgod/installing-kong-gateway-on-kubernetes-using-helm-30999582ecc3 |
| Building a Highly Available API Gateway with Kong | by Mostafa …, 8월 3, 2025에 액세스, https://medium.com/@mostafa.rabieian.ramezanpoor/building-a-highly-available-api-gateway-with-kong-42f6393066f3 |
| Kong’s New Developer Portal: Modern UX Meets Developer Self-Service | Kong Inc., 8월 3, 2025에 액세스, https://konghq.com/blog/product-releases/new-dev-portal-deep-dive |
| Architecture | Kuma, 8월 3, 2025에 액세스, https://kuma.io/docs/2.11.x/introduction/architecture/ |
| AI Gateway Benchmark: Kong AI Gateway, Portkey, and LiteLLM | Kong Inc., 8월 3, 2025에 액세스, https://konghq.com/blog/engineering/ai-gateway-benchmark-kong-ai-gateway-portkey-litellm |