기존 Kong이나 Apigee를 쓰고 있는데, 옮길 이유가 있나요?

셋 다 좋은 게이트웨이입니다. 다른 점은 둘입니다. 라이선스를 코어 수가 아니라 프로젝트로 세고, AI 모델과 MCP 도구를 API와 같은 정책으로 다룹니다. 이 둘이 필요 없으면 옮길 이유가 없습니다.

Extension을 만들면 업그레이드 때 깨지나요?

SDK는 Core보다 먼저 1.0으로 동결했고, Spring이나 Reactor 타입을 노출하지 않습니다. 비동기는 JDK 표준 CompletionStage만 씁니다. 프레임워크를 올려도 Extension은 그대로입니다. japicmp로 이진 호환성을 CI에서 검사합니다.

완전 폐쇄망에서 됩니까?

됩니다. 폐쇄망 번들이 릴리스 산출물에 포함됩니다. 외부 저장소 접근 없이 설치합니다.

← 홈으로

Agentic Gateway

API, AI 모델, MCP 도구를
게이트웨이 하나로

금융과 공공 API 게이트웨이 구축에서 매번 다시 만들던 것들을 제품으로 만들었습니다. 전문 변환, 인증 연계, 감사, 폐쇄망 배포. 필요한 것만 골라 넣고, 노드는 마음껏 늘리세요.

REST · gRPC

LLM

MCP

레거시 전문

→

Agentic Gateway

sdkschemacorepack

→

라우팅

정책 집행

감사 로그

마스킹

PoC / BMT 신청 도입 문의

노드를 늘려도 청구서는 그대로입니다

대부분의 API 게이트웨이는 CPU나 코어 수로 라이선스를 셉니다. 트래픽이 늘어 노드를 붙이면 라이선스도 다시 삽니다. Agentic Gateway는 도입 시스템 하나에 라이선스 하나입니다.

상황	CPU · 코어 라이선스	프로젝트 라이선스
노드 2대 → 6대 증설	3배 재계약	변화 없음
Blue-Green 배포 (일시 2배)	2배 확보 또는 위반	변화 없음
HA 대기 노드	과금	변화 없음
성수기 스케일아웃	리밸런싱 협의	변화 없음
청구 기준	코어 수	시스템 1건

다 넣지 않습니다. 필요한 것만 넣습니다.

게이트웨이 하나에 모든 기능을 담으면 시작이 느리고, 메모리를 먹고, 장애 표면이 넓어집니다. Agentic Gateway는 Pack 단위로 조립합니다. 라우팅만 필요하면 라우팅만. 전문 변환이 필요해지면 그때 추가합니다.

Pack	하는 일	언제 넣나
라우팅	URL, 헤더, 가중치 라우팅. 재시도, 서킷 브레이커	항상
인증	OAuth 2.0, JWT, API Key 회전, mTLS	외부 노출 시
전문 변환	JSON, XML, 고정길이 전문 상호 변환	레거시 연계 시
속도 제한	IP, 앱, API 단위 Rate Limit과 Quota	대외 API 시
AI 모델	LLM 프로바이더 추상화, 토큰 계량	AI 노출 시
MCP 도구	MCP 서버 등록, 도구 단위 권한	에이전트 연계 시
암복호화	필드 마스킹, 페이로드 암복호화	개인정보 전문 시

관례가 아닙니다. 위반하면 빌드가 실패합니다.

고객 Extension이 Core 내부를 건드리면 컴파일이 안 됩니다. SDK가 Spring 타입을 노출하면 빌드가 실패합니다. 자격증명을 String으로 들고 있으면 빌드가 실패합니다. 문서에 적어두는 게 아니라 게이트로 막습니다.

$ tools/verify-arch-gates.sh
G-B: verifying architecture gates reject real violations
  ok    ARCH-01b (pack -> core, build graph) rejected the violation
  ok    ARCH-01b (pack -> core, bytecode) rejected the violation
  ok    ARCH-05b (join() on request path) rejected the violation
  ok    extension-manifest.yaml required rejected the violation

gates enforcing: 4   not enforcing: 0

게이트 자체도 검증합니다. 조용히 작동을 멈춘 규칙은 통과하는 규칙과 겉보기가 같기 때문입니다. 실제로 한 번 겪었습니다. ArchUnit importer가 jar를 제외하도록 설정되어 9개 규칙 전부가 0개 클래스를 검사하며 통과했습니다. 그래서 위반을 일부러 주입해 거부되는지 확인하는 스크립트를 CI에 넣었습니다.

구성	버전	비고
JDK	21 LTS	고객 Extension 링크 호환을 위해 --release 21로 발행
Spring Boot	4.0.8	최신 GA는 4.1.1. Spring Cloud 2025.1.3이 4.0.8을 고정
Spring Cloud Gateway	5.0.3
Jackson	3.x	Jackson 2는 제품 코드에서 import 금지

관제가 끊겨도 트래픽은 흐릅니다

Control Plane이 죽어도 Data Plane은 마지막으로 승인된 설정으로 계속 돕니다. 거부된 설정이 동작 중인 설정을 밀어내지 못하게 테스트로 못 박았습니다. 금융 실운영에서 관제 장애가 서비스 장애로 번지는 걸 막는 원칙입니다.

폐쇄망이 기본값입니다

Docker 이미지, Helm 차트, VM 패키지, 폐쇄망 번들. 네 가지를 매 릴리스 동시에 만듭니다. Air-Gapped 환경에서 재현 가능한 빌드가 첫 요구사항이었습니다.

이렇게 시작합니다

01
PoC / BMT
대상 시스템 하나, 필요한 Pack 조합, 성능 기준을 정합니다. 2~4주.
02
파일럿
실트래픽 일부를 흘립니다. 감사 로그와 Fail Static을 실환경에서 봅니다.
03
계약
프로젝트 라이선스 견적. 노드 수는 묻지 않습니다.

궁금한 것들

기존 Kong이나 Apigee를 쓰고 있는데, 옮길 이유가 있나요?: 셋 다 좋은 게이트웨이입니다. 다른 점은 둘입니다. 라이선스를 코어 수가 아니라 프로젝트로 세고, AI 모델과 MCP 도구를 API와 같은 정책으로 다룹니다. 이 둘이 필요 없으면 옮길 이유가 없습니다.
Extension을 만들면 업그레이드 때 깨지나요?: SDK는 Core보다 먼저 1.0으로 동결했고, Spring이나 Reactor 타입을 노출하지 않습니다. 비동기는 JDK 표준 CompletionStage만 씁니다. 프레임워크를 올려도 Extension은 그대로입니다. japicmp로 이진 호환성을 CI에서 검사합니다.
완전 폐쇄망에서 됩니까?: 됩니다. 폐쇄망 번들이 릴리스 산출물에 포함됩니다. 외부 저장소 접근 없이 설치합니다.

대상 시스템 하나로 시작해 보시죠.