API 관리는 예전에는 GUI 콘솔과 벤더 인보이스를 의미했습니다. 여전히 그렇지만, 이제 실제 작업의 상당 부분은 터미널에서 이루어집니다. 구성 파일에서 라우트, 플러그인, 속도 제한을 정의하고, Git에 커밋한 다음, CLI를 통해 게이트웨이에 푸시합니다. 대시보드를 클릭할 필요도 없고, 배포된 것과 검토된 것 사이에 불일치도 없습니다.
여기서는 오픈소스 관점이 중요합니다. 자체 게이트웨이를 운영하는 경우, 라이선스가 좌석당 비용을 지불하지 않고도 자체 호스팅, 포크, 배포할 수 있는 것을 결정합니다. 아래 도구의 대부분은 Apache 2.0 또는 MPL 2.0 라이선스를 따르는데, 이는 소스가 제공되고, 어디서든 실행할 수 있으며, 사용자당 비용이 부과되지 않는다는 의미입니다. 이것은 가장 작은 바이너리를 선택하는 것과는 다른 관점입니다. 여기서는 라이선스, 자체 호스팅, GitHub 저장소의 활성도가 중요한 질문입니다.
이것은 실제 명령줄 스토리가 있는 진정한 오픈소스 게이트웨이 목록입니다: decK가 포함된 Kong Gateway OSS, Tyk, KrakenD Community Edition, Apache APISIX, Gravitee. 각 게이트웨이에 대해 라이선스, CLI가 실제로 하는 일, 그리고 붙여넣어 실행할 수 있는 실제 설치 및 실행 명령을 제공할 것입니다. 더 넓은 분야를 원한다면 오픈소스 API 관리 도구 총정리 글이 플랫폼을 다룹니다. 이 글은 그 중 터미널 우선 관점에서 잘라낸 것입니다. 의존하는 조건을 읽어본 적이 없다면 공식 Apache 2.0 라이선스 텍스트를 훑어볼 가치가 있습니다.
솔직한 말씀을 먼저 드립니다. Apidog는 마지막에 등장하지만 오픈소스 항목이 아닙니다. 오픈소스가 아니기 때문입니다. 이는 무료 티어가 있는 상용 제품입니다. 실제와 다르게 가장하지 않고 Apidog가 어디에 적합한지 설명하겠습니다.
API 관리를 위한 CLI 도구를 "오픈소스"로 만드는 요소
진짜 오픈소스 옵션과 카운트다운이 있는 무료 체험판을 구분하는 세 가지 요소가 있습니다.
라이선스. 클라이언트 SDK뿐만 아니라 코어 게이트웨이에서 Apache 2.0, MIT 또는 MPL 2.0을 찾으세요. Apache 2.0은 자유롭게 자체 호스팅하고 수정할 수 있도록 합니다. MPL 2.0 (Tyk의 선택)은 파일 수준의 카피레프트입니다. MPL 파일이 오픈 상태로 유지되는 한 독점 코드와 결합할 수 있습니다. "소스 제공" 또는 BSL로 표시된 것은 같은 것이 아니므로, 저장소의 실제 LICENSE 파일을 읽으세요.
자체 호스팅. 게이트웨이는 라이선스 서버가 외부와 통신하지 않고 자체 인프라에서 실행됩니다. 데이터 플레인을 제어합니다. "커뮤니티 에디션"이 데모 수준으로 기능이 제한되어 있다면 인정되지 않습니다.
관리되는 저장소와 작동하는 CLI. GitHub 별표를 확인하는 것도 좋지만, 커밋 이력을 더 자세히 확인하세요. 명령줄에서 선언적으로 구성하고, Git으로 버전을 관리하고, CI에서 실행할 수 있는 게이트웨이가 이 목록의 핵심입니다. 이 모든 것의 배후에 있는 일반적인 관리 개념에 대해서는 API 관리가 실제로 다루는 것을 참조하세요.
Kong Gateway OSS (decK 포함)
Kong Gateway OSS는 Apache 2.0 라이선스를 따르는 Kong 빌드입니다. Kong Inc.는 엔터프라이즈 에디션과 별도로 Apache 2.0 코드만을 원하는 사람들을 위해 OSS 빌드를 계속 제공합니다. 게이트웨이 자체는 Admin API를 통해 구성되지만, 실제로 사용하는 도구는 decK입니다.
decK는 Kong의 선언적 구성 CLI입니다. 실행 중인 게이트웨이의 상태를 YAML 파일로 덤프하고, 편집한 다음 다시 동기화합니다. 먼저 차이점을 보여주므로, 변경되기 전에 정확히 무엇이 바뀔지 볼 수 있어 구성 불일치가 자동으로 해결되는 대신 명확하게 드러납니다.
# Export the current Kong config to a file
deck gateway dump -o kong.yaml
# Push a declarative config back to the gateway
deck gateway sync kong.yaml
가장 적합한 용도: Kong을 위한 Infrastructure-as-Code. 이미 Kong을 실행 중이고 Git에 검토 및 CI를 통해 라우트와 플러그인을 관리하고 싶다면 decK가 답입니다. 솔직한 한계: Kong에 특화되어 있으며, 문서화나 테스트 대신 구성을 관리합니다. 또한 Kong의 전체 스택을 실행하게 되는데, 이는 단일 바이너리 게이트웨이보다 무겁습니다.
Tyk
Tyk의 게이트웨이는 Mozilla Public License 2.0에 따라 오픈소스입니다. MPL은 파일 수준의 카피레프트입니다. MPL 라이선스 파일에 대한 변경 사항은 오픈 상태로 유지되어야 하지만, 독점 플러그인이 별도의 파일에 존재하는 한 게이트웨이와 함께 묶을 수 있습니다. Go로 작성된 코어 게이트웨이는 REST, GraphQL, TCP, gRPC를 지원합니다.
대부분의 사람들이 사용하는 명령줄 구성 요소는 v2.8부터 게이트웨이 바이너리 내에 포함된 번들러입니다. 이는 사용자 정의 미들웨어 플러그인을 게이트웨이가 로드할 수 있는 서명된 번들로 패키징합니다.
# Build a plugin bundle from your manifest and middleware files
tyk bundle build -o bundle.zip
가장 적합한 용도: 사용자 정의 인증 또는 변환 플러그인으로 게이트웨이를 확장하고 이를 반복 가능한 방식으로 패키징해야 하는 팀. 솔직한 한계: CLI는 전체 게이트웨이의 완전한 선언적 구성이 아니라 번들링에만 초점을 맞춥니다. Tyk 관리의 많은 부분은 여전히 대시보드(유료 부분) 또는 게이트웨이 API를 통해 직접 실행됩니다.
KrakenD Community Edition
KrakenD는 스테이트리스(Stateless) 고성능 게이트웨이이며, 커뮤니티 에디션은 Apache 2.0 라이선스 하에 모든 핵심 기능을 제공합니다. 스테이트리스라는 점이 흥미로운데, 데이터베이스가 없습니다. 게이트웨이는 전적으로 구성 파일로 정의되며, 이는 Git 및 CI에 자연스럽게 통합될 수 있도록 합니다.
krakend 바이너리가 CLI입니다. check 명령으로 구성을 검증하고 run 명령으로 게이트웨이를 실행합니다. 단일 Go 바이너리이기 때문에 설치는 한 번의 다운로드로 끝납니다.
# Validate and lint your config before deploying
krakend check -c krakend.json --lint
# Run the gateway with that config
krakend run -c krakend.json
유연한 구성 기능(FC_ENABLE=1)을 사용하면 하나의 큰 구성을 변수가 있는 템플릿 파일로 분할하여 환경을 DRY하게 유지할 수 있습니다. 가장 적합한 용도: 구성 파일이 단일 진실 공급원인 선언적, 스테이트리스 게이트웨이. 솔직한 한계: CE에는 내장된 영속성 또는 관리 UI가 없습니다. 토글을 클릭하는 대신 구성에서 동작을 조합하는데, 이는 IaC를 좋아한다면 기능이고 그렇지 않다면 마찰입니다.
Apache APISIX
Apache APISIX는 Apache Software Foundation의 최고 수준 프로젝트이며, Apache 2.0 라이선스를 따릅니다. 이러한 거버넌스는 오픈소스 문제에 중요합니다. 이는 단일 벤더의 커뮤니티 에디션이 아닌 재단 프로젝트이므로, OSS 빌드가 기능이 축소된 티저가 아닌 실제 프로젝트입니다.
APISIX는 라이프사이클 작업을 위한 제어 CLI와 라우트 및 플러그인을 관리하기 위한 REST Admin API(기본적으로 127.0.0.1에 바인딩됨)를 제공합니다. CLI는 게이트웨이를 시작, 중지, 재로드하며, apisix reload는 연결을 끊지 않고 구성 변경 사항을 반영합니다.
# See the available control commands
apisix help
# Start the gateway, then hot-reload after a config change
apisix start
apisix reload
가장 적합한 용도: Admin API에 의해 구동되는, 재시작 없이 런타임에 라우트와 플러그인을 변경하고자 하는 동적 고성능 라우팅. 솔직한 한계: 라우팅 구성은 단일 선언적 CLI 푸시 대신 Admin API에 존재하므로, "Git의 구성" 워크플로우는 일반적으로 Admin API 호출을 스크립팅하거나 APISIX의 ADC와 같은 도구를 추가하는 것을 의미합니다.
Gravitee
Gravitee의 핵심 API 관리 플랫폼은 Apache 2.0에 따라 오픈소스입니다. 이는 게이트웨이 이상입니다. 커뮤니티 에디션에는 APIM 게이트웨이(런타임), APIM API(REST 관리 인터페이스), APIM 콘솔이 포함되어 있습니다. 이벤트 기반 비동기 API와 같은 엔터프라이즈 기능은 유료 에디션에 있지만, REST 중심의 코어는 자체 호스팅할 수 있는 진정한 OSS입니다.
명령줄 스토리에 대한 솔직한 주의사항이 필요합니다. Gravitee의 일상적인 관리는 관리 REST API 및 콘솔을 통해 이루어지며, 공식 자체 호스팅 설치는 종종 Docker CLI로 구동됩니다. GitHub에는 관리 API를 래핑하여 모듈 간 작업을 자동화하는 커뮤니티 관리 graviteeio-cli가 있지만, 이는 공식 바이너리가 아닌 커뮤니티 도구이므로, 이에 의존하기 전에 다른 커뮤니티 프로젝트와 마찬가지로 유지 관리 상태를 평가해야 합니다.
# Run the Gravitee APIM gateway container (self-hosted, OSS)
docker run --name gravitee-gateway -p 8082:8082 graviteeio/apim-gateway:latest
가장 적합한 용도: 단순히 프록시가 아닌 완전한 오픈소스 관리 계층(게이트웨이, 콘솔, 스크립트화할 수 있는 관리 API)을 원하는 팀. 솔직한 한계: 공식 자동화 인터페이스는 다듬어진 단일 CLI가 아닌 REST 관리 API입니다. 커뮤니티 CLI가 이 간극을 채워주지만, 그 유지 관리 위험은 감수해야 합니다.
Apidog가 적합한 위치 (그리고 오픈소스 목록에 없는 이유)
Apidog는 오픈소스가 아니므로 위에 있는 항목으로 적합하지 않습니다. 이는 무료 티어가 있는 상용 제품이며, 이를 Apache 2.0 아래에 분류하면 독자들을 오도하게 될 것입니다.
어쨌든 솔직한 제안입니다. 위의 도구들은 게이트웨이입니다. 트래픽, 라우트, 플러그인을 관리합니다. API 스키마를 설계하거나, 엔드포인트 테스트를 실행하거나, 문서를 생성하거나, 백엔드가 존재하기 전에 응답을 모의하지 않습니다. 이러한 작업들을 함께 연결하는 것은 보통 Spectral, openapi-generator, 모의 서버, Newman을 각각 자체 구성과 함께 사용하는 것을 의미합니다. Apidog는 설계, 테스트, 모의, 문서를 하나의 작업 공간으로 통합하며, apidog-cli는 이 모든 것에 대한 터미널 경로를 제공합니다.
# Install and authenticate the Apidog CLI
npm install -g apidog-cli
apidog login --with-token <TOKEN>
# Run a test scenario in CI (exits non-zero on failure)
apidog run
CLI는 agentHints.nextSteps가 포함된 구조화된 JSON을 출력하므로 CI 및 AI 에이전트 워크플로우에 깔끔하게 통합됩니다. Claude Code 또는 유사한 도구를 통해 API 작업을 라우팅하는 경우 AI 에이전트를 벗어나지 않고 API 관리하기가 해당 패턴을 다룹니다. 또한 OpenAPI 가져오기 및 내보내기, 시나리오 실행, 명령줄에서 모의를 구동하는 것을 지원합니다. 완전한 Apidog CLI 가이드는 명령 그룹을 자세히 설명합니다. 이를 자체 호스팅되는 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/reload |
| Gravitee | 완전한 OSS 관리 계층 + 콘솔 | Apache 2.0 | 예 (코어) | Docker CLI / REST API |
| Apidog CLI | 설계 + 테스트 + 모의 + 문서 통합 | 프리미엄 | 아니요 | apidog run |
별점 개수보다는 워크플로우를 기준으로 선택하세요. 이미 Kong을 실행 중이라면 decK가 가장 빠른 해결책입니다. 파일로만 정의되는 스테이트리스 게이트웨이를 원한다면 KrakenD가 적합합니다. APISIX는 동적 런타임 라우팅 변경에서 유리하며, Gravitee는 콘솔을 포함한 전체 관리 계층을 제공합니다. 상용 플랫폼을 포함한 더 넓은 비교를 원한다면 2026년 최고의 API 관리 도구를 참조하고, API 우선 스택을 구축 중이라면 헤드리스 API 관리 관점을 확인하세요.
마무리
CLI를 통한 오픈소스 API 관리는 성숙했습니다. decK가 포함된 Kong Gateway OSS, Tyk, KrakenD CE, Apache APISIX, Gravitee는 모두 Apache 2.0 또는 MPL 2.0 라이선스를 따르며, 모두 자체 호스팅 가능하고, 터미널에서 제어할 수 있습니다. 이는 대시보드 클릭 대신 Git, 검토, CI를 의미합니다. 배포 방식과 일치하는 모델을 선택하세요.
게이트웨이가 처리하지 않는 설계, 테스트, 모의, 문서 작업을 위해서는 통합 도구가 그 간극을 메웁니다. Apidog를 다운로드하여 파이프라인에서 apidog run을 실행하여 CLI 경로를 확인한 다음, 선택한 OSS 게이트웨이 옆에 CI에 연결하세요.