Rihpig

Posted on Jul 10 • Originally published at apidog.com

무료 오픈 소스 API 관리 CLI 도구

API 관리는 예전에는 GUI 콘솔과 벤더 인보이스를 의미했습니다. 지금도 그렇지만, 실제 운영 작업의 상당 부분은 터미널에서 이뤄집니다. 구성 파일에서 라우트, 플러그인, 속도 제한을 정의하고 Git에 커밋한 뒤 CLI로 게이트웨이에 반영합니다. 대시보드를 직접 클릭할 필요가 없고, 검토된 구성과 배포된 구성의 불일치도 줄일 수 있습니다.

지금 Apidog 사용해 보기

자체 게이트웨이를 운영한다면 라이선스도 구현 선택의 핵심입니다. 라이선스는 좌석당 비용 없이 자체 호스팅, 포크, 배포할 수 있는 범위를 결정합니다. 이 글에서 다루는 대부분의 도구는 Apache 2.0 또는 MPL 2.0 라이선스를 사용합니다. 즉, 소스를 확인하고 원하는 인프라에서 실행하며 사용자별 비용 없이 운영할 수 있습니다.

이 글은 실제 명령줄 워크플로우를 제공하는 오픈소스 게이트웨이에 집중합니다.

Kong Gateway OSS + decK
Tyk
KrakenD Community Edition
Apache APISIX
Gravitee

각 도구의 라이선스, CLI 역할, 바로 실행할 수 있는 명령을 살펴봅니다. 더 넓은 플랫폼 비교는 오픈소스 API 관리 도구 글을 참고하세요. 라이선스 조건을 직접 확인하려면 Apache 2.0 라이선스 원문도 읽어보는 것이 좋습니다.

먼저 분명히 하겠습니다. Apidog는 이 글의 마지막에 다루지만 오픈소스 도구는 아닙니다. 무료 티어를 제공하는 상용 제품이며, OSS 게이트웨이를 대체하는 제품으로 설명하지 않습니다.

API 관리 CLI를 “오픈소스”로 분류하는 기준

무료 체험판 제품과 실제 오픈소스 옵션을 구분하려면 다음 세 가지를 확인하세요.

1. 코어 게이트웨이 라이선스 확인

클라이언트 SDK만이 아니라 게이트웨이 코어의 LICENSE 파일을 확인하세요.

Apache 2.0: 자체 호스팅, 수정, 재배포에 유연합니다.
MIT: 사용과 재배포 조건이 단순합니다.
MPL 2.0: 파일 수준 카피레프트입니다. MPL 파일을 수정했다면 해당 파일의 소스 공개 의무가 있지만, 별도 파일의 독점 코드와 결합할 수 있습니다.

“소스 제공(Source Available)”이나 BSL은 Apache 2.0, MIT, MPL 2.0과 같지 않습니다. 마케팅 페이지가 아니라 저장소의 실제 라이선스 파일을 기준으로 판단하세요.

2. 라이선스 서버 없이 자체 호스팅 가능한지 확인

게이트웨이가 외부 라이선스 서버에 의존하지 않고 자체 인프라에서 실행되어야 합니다. 데이터 플레인과 운영 환경을 직접 제어할 수 있어야 하며, 커뮤니티 에디션이 데모 수준 기능으로 제한되어 있지 않은지도 확인해야 합니다.

3. 선언적 구성과 자동화 경로가 있는지 확인

GitHub 별표 수보다 다음을 확인하는 편이 실용적입니다.

구성을 파일로 선언할 수 있는가?
Git으로 변경 이력을 관리할 수 있는가?
CI에서 검증과 배포를 실행할 수 있는가?
CLI 또는 관리 API를 자동화할 수 있는가?

API 관리가 다루는 범위를 더 자세히 알고 싶다면 API 관리가 실제로 다루는 것을 참고하세요.

Kong Gateway OSS + decK

Kong Gateway OSS는 Apache 2.0 라이선스를 따르는 Kong 빌드입니다. 게이트웨이는 Admin API로 구성할 수 있지만, Git 기반 구성 관리에는 일반적으로 decK를 사용합니다.

decK는 Kong의 선언적 구성 CLI입니다. 실행 중인 게이트웨이 상태를 YAML 파일로 내보내고, 파일을 수정한 뒤, 차이를 검토하고 다시 동기화할 수 있습니다.

# 현재 Kong 구성을 파일로 내보내기
deck gateway dump -o kong.yaml

# 선언형 구성을 게이트웨이에 반영하기
deck gateway sync kong.yaml

실제 CI에서는 sync 전에 변경 사항을 검토하는 단계를 두는 것이 좋습니다. 예를 들어 PR에서 kong.yaml 변경을 검토하고, 승인 후 배포 파이프라인에서 동기화를 실행할 수 있습니다.

적합한 경우

이미 Kong을 운영하고 있다.
라우트와 플러그인을 Git에서 검토하고 싶다.
Kong 구성을 IaC 방식으로 관리하고 싶다.

한계

decK는 Kong 전용입니다.
API 문서화나 테스트가 아니라 게이트웨이 구성 관리에 초점이 맞춰져 있습니다.
Kong 전체 스택은 단일 바이너리 게이트웨이보다 무거울 수 있습니다.

Tyk

Tyk Gateway는 Mozilla Public License 2.0(MPL 2.0)으로 공개되어 있습니다. Go로 작성된 코어 게이트웨이는 REST, GraphQL, TCP, gRPC를 지원합니다.

명령줄에서 주로 사용하는 기능은 게이트웨이 바이너리에 포함된 번들러입니다. 사용자 정의 미들웨어 플러그인을 게이트웨이가 로드할 수 있는 서명된 번들로 패키징합니다.

# 매니페스트와 미들웨어 파일에서 플러그인 번들 생성
tyk bundle build -o bundle.zip

플러그인 코드를 배포 가능한 산출물로 만들고 싶다면, 번들 생성 과정을 CI에 넣으세요. 예를 들어 플러그인 테스트를 통과한 경우에만 bundle.zip을 생성하고 배포 단계로 전달할 수 있습니다.

적합한 경우

사용자 정의 인증, 변환, 미들웨어 플러그인이 필요하다.
플러그인을 반복 가능한 방식으로 패키징하고 배포하고 싶다.
여러 프로토콜을 처리해야 한다.

한계

CLI는 게이트웨이 전체를 선언적으로 구성하기보다 플러그인 번들링에 집중합니다.
많은 관리 작업은 대시보드 또는 Gateway API를 통해 수행됩니다.

KrakenD Community Edition

KrakenD Community Edition은 Apache 2.0 라이선스의 스테이트리스 고성능 게이트웨이입니다. 데이터베이스 없이 구성 파일을 기준으로 동작하므로 Git과 CI에 자연스럽게 통합할 수 있습니다.

krakend 바이너리 자체가 CLI입니다. 배포 전에 구성 파일을 검증하고, 같은 파일로 게이트웨이를 실행할 수 있습니다.

# 배포 전 구성 검증 및 린트
krakend check -c krakend.json --lint

# 구성 파일로 게이트웨이 실행
krakend run -c krakend.json

CI 파이프라인에서는 최소한 다음 순서를 권장합니다.

krakend.json 변경을 PR로 검토합니다.
krakend check --lint로 구성을 검증합니다.
검증된 구성 파일만 배포 환경에 전달합니다.
krakend run으로 해당 구성을 실행합니다.

유연한 구성 기능을 사용하려면 FC_ENABLE=1을 설정할 수 있습니다. 하나의 큰 구성 파일 대신 변수와 템플릿을 사용해 환경별 구성을 분리하는 방식입니다.

FC_ENABLE=1 krakend check -c krakend.json --lint

적합한 경우

구성 파일을 단일 진실 공급원으로 사용하고 싶다.
데이터베이스 없는 스테이트리스 게이트웨이가 필요하다.
Git 기반의 선언적 배포 방식을 선호한다.

한계

CE에는 내장 영속성이나 관리 UI가 없습니다.
UI에서 옵션을 클릭하는 대신 구성 파일에서 동작을 조합해야 합니다.

Apache APISIX

Apache APISIX는 Apache Software Foundation의 최상위 프로젝트이며 Apache 2.0 라이선스를 따릅니다. 단일 벤더의 기능 제한 커뮤니티 에디션이 아니라 재단이 관리하는 오픈소스 프로젝트라는 점이 중요합니다.

APISIX는 게이트웨이 라이프사이클을 위한 제어 CLI와 라우트·플러그인 관리를 위한 REST Admin API를 제공합니다. Admin API는 기본적으로 127.0.0.1에 바인딩됩니다.

# 사용 가능한 제어 명령 확인
apisix help

# 게이트웨이 시작
apisix start

# 연결을 끊지 않고 구성 변경 반영
apisix reload

apisix reload는 구성 변경을 반영할 때 연결을 끊지 않는 데 사용할 수 있습니다. 런타임 라우팅 변경이 필요한 경우에는 Admin API 호출을 배포 스크립트나 CI 작업으로 관리하세요.

적합한 경우

런타임에 라우트와 플러그인을 동적으로 변경해야 한다.
고성능 동적 라우팅이 필요하다.
REST Admin API 기반 자동화를 구축할 수 있다.

한계

라우팅 구성은 단일 CLI 동기화 명령이 아니라 Admin API에서 관리됩니다.
Git 기반 워크플로우를 만들려면 Admin API 호출을 스크립트화하거나 APISIX ADC 같은 도구를 추가해야 합니다.

Gravitee

Gravitee의 핵심 API 관리 플랫폼은 Apache 2.0 라이선스로 공개되어 있습니다. 커뮤니티 에디션에는 다음 구성 요소가 포함됩니다.

APIM Gateway: 런타임 게이트웨이
APIM API: REST 관리 인터페이스
APIM Console: 관리 콘솔

이벤트 기반 비동기 API 같은 일부 엔터프라이즈 기능은 유료 에디션에 속하지만, REST 중심의 핵심 플랫폼은 자체 호스팅 가능한 OSS입니다.

Gravitee의 일상적인 관리는 관리 REST API와 콘솔을 중심으로 이뤄집니다. 자체 호스팅 환경에서는 Docker CLI를 사용해 구성 요소를 실행할 수 있습니다.

# Gravitee APIM Gateway 컨테이너 실행
docker run --name gravitee-gateway -p 8082:8082 graviteeio/apim-gateway:latest

GitHub에는 관리 API를 래핑해 모듈 간 작업을 자동화하는 커뮤니티 도구 graviteeio-cli도 있습니다. 다만 공식 바이너리가 아닌 커뮤니티 프로젝트이므로, 운영 의존성을 추가하기 전 유지 관리 상태를 확인하세요.

적합한 경우

프록시뿐 아니라 게이트웨이, 콘솔, 관리 API를 포함한 관리 계층이 필요하다.
REST 관리 API를 스크립트와 CI로 자동화할 수 있다.
자체 호스팅 API 관리 플랫폼을 운영하고 싶다.

한계

공식 자동화 인터페이스는 단일 CLI가 아니라 REST 관리 API입니다.
커뮤니티 CLI를 사용하면 자동화 범위는 넓어질 수 있지만 유지 관리 위험도 함께 평가해야 합니다.

Apidog가 적합한 위치

Apidog는 오픈소스가 아닙니다. 무료 티어를 제공하는 상용 제품이므로 Apache 2.0 기반 OSS 게이트웨이와 같은 범주로 분류하면 안 됩니다.

위에서 소개한 도구는 게이트웨이입니다. 트래픽, 라우트, 플러그인 같은 런타임 동작을 관리합니다. 반면 API 설계, 엔드포인트 테스트, 문서 생성, 백엔드 구현 전 응답 모의는 별도 도구 조합이 필요한 경우가 많습니다.

Apidog은 설계, 테스트, 모의, 문서를 하나의 작업 공간으로 통합하며, apidog-cli를 통해 터미널에서도 작업할 수 있습니다.

# Apidog CLI 설치 및 인증
npm install -g apidog-cli
apidog login --with-token <TOKEN>

# CI에서 테스트 시나리오 실행
# 실패 시 non-zero 종료 코드 반환
apidog run

CLI는 agentHints.nextSteps가 포함된 구조화된 JSON을 출력하므로 CI와 AI 에이전트 워크플로우에 연결할 수 있습니다. Claude Code 같은 도구로 API 작업을 자동화한다면 AI 에이전트를 벗어나지 않고 API 관리하기를 참고하세요.

Apidog CLI는 OpenAPI 가져오기·내보내기, 시나리오 실행, 명령줄 기반 모의도 지원합니다. 명령 그룹별 사용법은 완전한 Apidog CLI 가이드에서 확인할 수 있습니다.

핵심은 역할 분리입니다. Apidog를 자체 호스팅 OSS 게이트웨이의 대체재가 아니라, 게이트웨이 앞뒤의 설계·테스트·문서화 작업을 보완하는 통합 옵션으로 보세요.

선택 방법

도구	가장 적합한 용도	라이선스	오픈소스 여부	CLI/명령
Kong Gateway OSS + decK	Git에서 Kong을 위한 IaC 구성	Apache 2.0	예	`deck gateway sync`
Tyk	사용자 정의 플러그인 번들링, 다중 프로토콜	MPL 2.0	예	`tyk bundle build`
KrakenD CE	스테이트리스, 코드형 구성 게이트웨이	Apache 2.0	예	`krakend run`
Apache APISIX	동적 고성능 라우팅	Apache 2.0	예, ASF 프로젝트	`apisix start`, `apisix reload`
Gravitee	전체 OSS 관리 계층과 콘솔	Apache 2.0	예, 코어 기준	Docker CLI / REST API
Apidog CLI	설계, 테스트, 모의, 문서 통합	프리미엄	아니요	`apidog run`

별점 수보다 현재 워크플로우를 기준으로 선택하세요.

이미 Kong을 운영 중이라면: decK로 구성 동기화와 Git 기반 검토를 시작하세요.
파일 기반 스테이트리스 게이트웨이가 필요하다면: KrakenD가 적합합니다.
런타임 라우팅을 동적으로 바꿔야 한다면: APISIX의 Admin API 중심 모델을 검토하세요.
콘솔을 포함한 전체 관리 계층이 필요하다면: Gravitee를 고려하세요.
게이트웨이 외에 설계·테스트·모의·문서화도 묶어야 한다면: Apidog CLI를 보완 도구로 사용할 수 있습니다.

상용 플랫폼까지 포함한 더 넓은 비교는 2026년 최고의 API 관리 도구를 참고하세요. API 우선 스택을 설계 중이라면 헤드리스 API 관리 관점도 유용합니다.

마무리

CLI 기반 오픈소스 API 관리는 충분히 성숙했습니다. Kong Gateway OSS + decK, Tyk, KrakenD CE, Apache APISIX, Gravitee는 모두 자체 호스팅이 가능하며 터미널 기반 운영 경로를 제공합니다.

구성 변경을 Git으로 관리하고, PR에서 검토하고, CI에서 검증한 뒤 배포하세요. 도구 선택은 기능 목록보다 현재 배포 방식과 운영 모델에 맞춰야 합니다.

게이트웨이가 직접 처리하지 않는 API 설계, 테스트, 모의, 문서화가 필요하다면 Apidog를 다운로드한 뒤 파이프라인에서 apidog run을 실행해 볼 수 있습니다. 선택한 OSS 게이트웨이와 함께 CI에 연결해 역할을 분리하세요.

DEV Community

무료 오픈 소스 API 관리 CLI 도구

API 관리 CLI를 “오픈소스”로 분류하는 기준

1. 코어 게이트웨이 라이선스 확인

2. 라이선스 서버 없이 자체 호스팅 가능한지 확인

3. 선언적 구성과 자동화 경로가 있는지 확인

Kong Gateway OSS + decK

Tyk

KrakenD Community Edition

Apache APISIX

Gravitee

Apidog가 적합한 위치

선택 방법

마무리

Top comments (0)