대부분의 API 테스트 튜토리얼은 GUI를 지향합니다. 하지만 터미널 환경에서 작업하고, CI에서 테스트를 실행하거나, 소스 코드를 읽을 수 있는 도구를 원한다면, 명령줄이야말로 API 테스트가 흥미로워지는 지점입니다. 오픈소스 CLI 도구는 호스팅 제품이 제공할 수 없는 것을 제공합니다: 감사 가능한 라이선스, 직접 호스팅할 수 있는 바이너리, 그리고 코드 옆에 커밋할 수 있는 구성 파일입니다.
이는 "가장 빠른 도구는 무엇인가" 또는 "가장 작은 바이너리는 무엇인가"와는 다른 질문입니다. 여기서 중요한 관점은 라이선스와 제어입니다. 계정 없이 자체 네트워크 내에서 실행할 수 있습니까? GitHub에 있는 소스가 실제 OSI 승인 라이선스를 따르고 있습니까? 공급업체가 다음 분기에 가격을 변경해도 계속 작동할까요? 이 목록은 이러한 질문에 답합니다.
아래에는 REST, GraphQL, HTTP API 테스트를 위한 여덟 가지 무료 소스 사용 가능 CLI 도구가 각각 정확한 라이선스, 실제 설치 명령, 그리고 작동 방식을 보여주는 단일 명령과 함께 소개되어 있습니다. 호스팅 도구를 포함하는 더 넓은 조사를 원하시면 최고의 무료 API 테스트 도구 요약을 참조하세요. 엔드포인트를 수동으로 호출하는 순수 터미널 우선 방식에 대해서는 REST API 테스트를 위한 curl 대안 가이드에서 상호작용적 측면을 다룹니다.
API 테스트를 위한 CLI 도구가 "오픈소스"인 이유
많은 도구가 무료로 다운로드할 수 있습니다. 하지만 이는 오픈소스와는 다릅니다. 이 목록에서는 다음 세 가지 기준에 따라 도구를 선정했습니다:
- 실제 라이선스. 소스가 OSI 승인 라이선스(MIT, Apache-2.0, MPL-2.0, AGPL-3.0, BSD) 하에 공개되어 있습니다. 소스를 읽고, 포크하고, 무엇을 할 수 있는지 알 수 있습니다.
- 자체 호스팅 가능, 계정 불필요. 아무것도 가입할 필요 없이 자신의 머신이나 CI 러너에서 전체를 실행할 수 있습니다. 좌석 비용이 없고, 외부 서버에 연결해야 하는 요구사항도 없습니다.
- 유지보수 및 검사 가능. 저장소가 GitHub에 있으며 커밋 기록과 이슈가 공개되어 있어, 파이프라인을 구축하기 전에 활발하게 관리되는지 판단할 수 있습니다.
아래의 모든 도구는 처음 두 가지 기준을 충족합니다. 세 번째 기준을 더 이상 충족하지 않는 도구는 표시했습니다. 라이선스 선택은 보이는 것보다 중요합니다: AGPL-3.0(k6)은 이를 기반으로 서비스를 구축할 경우 카피레프트 의무가 있는 반면, MIT와 Apache-2.0은 허용적인 라이선스입니다. 제품에 도구를 포함하기 전에 라이선스를 읽어보십시오.
Hurl: 플레인 텍스트 HTTP 테스트, 단일 Rust 바이너리
Hurl은 플레인 텍스트 형식으로 작성된 HTTP 요청을 실행하고 응답에 대해 단언합니다. Orange-OpenSource가 Rust로 구축했으며, 내부적으로 libcurl을 기반으로 하고 단일 바이너리로 제공됩니다. 테스트는 요청 자체와 거의 유사하게 읽히므로 풀 리퀘스트에서 검토하기 쉽습니다.
라이선스: Apache-2.0. 소스: github.com/Orange-OpenSource/hurl.
brew install hurl # or: cargo install --locked hurl
# login.hurl
cat > login.hurl <<'EOF'
POST https://api.example.com/login
{ "user": "acme", "pass": "s3cret" }
HTTP 200
[Asserts]
jsonpath "$.token" exists
EOF
hurl --test login.hurl
가장 적합한 용도: 읽기 쉬운 텍스트로 버전 관리하려는 계약 스타일 검사 및 스모크 테스트. 솔직한 한계: HTTP에 중점을 두므로 gRPC를 구동하거나 부하를 생성하지 않습니다. 간단한 단언 체인 이상의 기능을 위해서는 스크립팅 언어를 사용하는 대신 더 많은 .hurl 파일을 작성해야 합니다.
Step CI: CI를 위해 구축된 YAML API 워크플로우
Step CI는 지속적인 통합을 위해 제작된 YAML 구성 워크플로우 러너입니다. 단일 워크플로우 파일에서 REST, GraphQL, gRPC, tRPC, SOAP를 다루며, OpenAPI 스키마에 대해 부하 테스트 및 유효성 검사를 수행할 수 있습니다. 러너와 CLI는 영원히 무료입니다.
라이선스: MPL-2.0. 소스: github.com/stepci/stepci.
npm install -g stepci
# workflow.yml describes steps, checks, and captures
stepci run workflow.yml
가장 적합한 용도: 다단계 API 흐름을 설명하는 하나의 선언적 파일을 원하고 로컬 및 CI에서 동일한 방식으로 실행하려는 팀. 솔직한 한계: MPL-2.0은 약한 카피레프트이므로 Step CI 자체 파일을 수정하면 해당 변경 사항을 공유해야 합니다. 앱 테스트에 사용하는 경우에는 그러한 의무가 없습니다.
Schemathesis: 스키마를 기반으로 한 속성 기반 테스팅
Schemathesis는 OpenAPI 또는 GraphQL 스키마를 읽고 Python의 Hypothesis 라이브러리를 기반으로 하는 속성 기반 테스팅을 사용하여 수천 개의 테스트 케이스를 생성합니다. 각 케이스를 직접 작성하는 대신, 입력값을 퍼징하여 500 오류, 스키마 위반, 문서에서 약속한 내용과 일치하지 않는 응답을 찾아냅니다.
라이선스: MIT. 소스: github.com/schemathesis/schemathesis.
uv pip install schemathesis # or: pip install schemathesis
schemathesis run https://api.example.com/openapi.json
가장 적합한 용도: 특히 릴리스 전에 테스트를 작성할 생각조차 하지 못했던 엣지 케이스 버그를 잡는 데 유용합니다. 정확한 스키마를 유지해야 하는 가장 강력한 이유 중 하나입니다. 솔직한 한계: 작동하려면 실제 스키마가 필요하며, 큰 API는 훅 및 옵션을 사용하여 필터링해야 하는 많은 노이즈를 생성할 수 있습니다.
Dredd: API 설명에 대한 계약 테스트
Dredd는 라이브 API가 실제 설명 문서와 일치하는지 확인합니다. OpenAPI(또는 API Blueprint) 파일과 실행 중인 백엔드를 지정하면, 문서화된 모든 요청을 재생하고 실제 응답을 사양과 비교합니다. 언어에 구애받지 않으며 설정 및 해체를 위한 훅을 지원합니다.
라이선스: MIT. 소스: github.com/apiaryio/dredd.
npm install -g dredd
dredd apiary.apib http://127.0.0.1:3000
가장 적합한 용도: 문서와 구현이 서로 멀어지지 않았음을 입증하는 데 유용합니다. 솔직하고 실제적인 한계: Dredd 저장소는 2024년 11월에 보관되었으며 읽기 전용입니다. 여전히 실행되지만 더 이상 유지보수되지 않으므로, 향후 수정 사항이 없는 안정적인 도구로 간주해야 합니다. 활발하게 유지보수되는 스키마 기반 검사 도구를 원한다면 Schemathesis가 더 안전한 선택입니다.
k6: JavaScript로 스크립트화된 부하 테스트
k6는 Grafana의 부하 및 성능 테스트 도구입니다. JavaScript 또는 TypeScript로 테스트를 스크립트화하면 빠른 Go 엔진이 이를 대규모로 구동합니다. 단일 요청이 통과하는지 여부뿐만 아니라 수백 또는 수천 명의 가상 사용자 환경에서 API가 어떻게 동작하는지 알아야 할 때 가장 적합한 오픈소스 옵션입니다.
라이선스: AGPL-3.0. 소스: github.com/grafana/k6.
brew install k6
k6 new script.js # generates a starter test
k6 run script.js
가장 적합한 용도: 기능 테스트와 동일한 저장소에 있는 성능 및 부하 테스트. 솔직한 한계: AGPL-3.0은 강력한 카피레프트입니다. 테스트 실행에는 문제가 없지만, k6의 코드를 기반으로 서비스를 구축하고 배포하는 경우 라이선스에 실제 의무가 있으므로 먼저 읽어보십시오. k6는 또한 세분화된 계약 단언이 아닌 부하에 중점을 둡니다.
Newman: GUI 없이 Postman 컬렉션 실행
Newman은 Postman 자체의 명령줄 컬렉션 러너입니다. 팀에 이미 Postman 컬렉션으로 저장된 API 요청 및 테스트가 있다면, Newman은 터미널 또는 CI에서 데스크톱 앱 없이 해당 컬렉션을 정확히 실행합니다. Postman 워크플로우를 파이프라인에 통합하는 표준적인 방법입니다.
라이선스: Apache-2.0. 소스: github.com/postmanlabs/newman.
npm install -g newman
newman run my-collection.json -e staging-environment.json
가장 적합한 용도: 기존 Postman 컬렉션을 가지고 있으며 추가 Postman 좌석 비용 없이 CI 실행을 원하는 팀. 솔직한 한계: Postman 컬렉션 형식에 묶여 있으므로, 일반 구성 파일이 아닌 Postman UI(또는 JSON)에서 테스트를 작성해야 합니다. 컬렉션을 실행하지만 API를 설계하거나 목킹하지는 않습니다.
Tavern: pytest 플러그인으로서의 API 테스트
Tavern은 YAML로 API 테스트를 기술하는 Python 라이브러리, CLI 및 pytest 플러그인입니다. pytest에 연결되므로, 이미 사용하고 있을 수 있는 픽스처, 보고, 병렬 처리, CI 통합 등 pytest 생태계 전체를 무료로 사용할 수 있습니다. REST, MQTT, gRPC를 처리합니다.
라이선스: MIT. 소스: github.com/taverntesting/tavern.
pip install tavern
# test_login.tavern.yaml sits next to your other tests
pytest test_login.tavern.yaml
가장 적합한 용도: 이미 pytest를 실행하고 있으며 API 테스트가 단위 테스트와 함께 존재하기를 원하는 Python 환경의 개발팀. 솔직한 한계: Python 테스트 설정에 익숙하다고 가정합니다. 스택이 Python이 아니라면 pytest 종속성은 기능이라기보다는 마찰 요인이 될 수 있습니다.
Venom: OVHcloud의 다중 실행기 통합 테스트
OVHcloud의 Venom은 HTTP 요청, 셸 스크립트, IMAP, 웹, 데이터베이스 등 다양한 실행기 유형에 걸쳐 통합 테스트를 실행합니다. Go로 작성되었으며 YAML 테스트 스위트를 사용하고 CI 시스템이 기본적으로 읽을 수 있는 xUnit 결과 파일을 내보냅니다. 단일 테스트가 HTTP 엔드포인트 이상을 다루어야 할 때 특히 빛을 발합니다.
라이선스: BSD (수정됨). 소스: github.com/ovh/venom.
# download the binary from GitHub releases, then:
venom run testsuite.yml
가장 적합한 용도: 하나의 테스트 스위트에서 API 호출과 데이터베이스 확인 또는 스크립트 단계를 혼합하는 엔드투엔드 흐름. 솔직한 한계: 너무 많은 실행기 때문에 YAML이 장황해지며, 문서는 저장소의 예시들을 조합하여 사용할 것이라고 가정합니다.
Apidog의 위치 (및 솔직한 참고사항)
솔직하게 말씀드리자면, Apidog은 오픈소스가 아닙니다. 무료 티어가 있는 상업용 제품이므로 소스 사용 가능한 도구 목록에 속하지 않습니다. 하지만 한 가지 이유 때문에 알아둘 가치가 있습니다. 위 도구들은 각각 하나의 작업만 수행하며, Hurl과 Schemathesis, Newman, 그리고 목 서버를 하나의 일관된 워크플로우로 연결하는 것은 스스로 유지보수해야 하는 실제 작업입니다.
Apidog은 설계, 테스트, 목킹, 문서화를 하나의 플랫폼으로 통합하며, apidog-cli는 테스트 기능을 터미널로 가져옵니다. 테스트 시나리오를 한 번 작성한 다음, 단일 명령으로 CI에서 실행할 수 있습니다:
npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run --access-token <TOKEN> # exits 0 on all-pass, non-zero on failure
출력은 `agentHints.nextSteps`가 포함된 구조화된 JSON으로, 스크립팅하거나 AI 에이전트에 전달하기 쉽습니다. 전체 apidog-cli 가이드는 모든 명령 세트를 설명합니다. 따라서 오픈소스는 아니지만, 무료 티어와 CLI는 여러 단일 목적 도구를 함께 연결하는 통합된 대안을 제공합니다. 감사 가능한 라이선스가 필수 요구사항이라면 위의 여덟 가지 중 하나를 선택하십시오. 통합된 워크플로우가 더 중요하다면, 이것이 절충점입니다.
선택 방법
| 도구 | 가장 적합한 용도 | 설치 | 오픈소스? | 라이선스 |
|---|---|---|---|---|
| Hurl | Git에 저장된 플레인 텍스트 HTTP 단언 | brew install hurl |
예 | Apache-2.0 |
| Step CI | 선언적 CI 워크플로우 | npm i -g stepci |
예 | MPL-2.0 |
| Schemathesis | 스키마 기반 속성 퍼징 | pip install schemathesis |
예 | MIT |
| Dredd | 문서-구현 간 계약 테스트 | npm i -g dredd |
예 (보관됨) | MIT |
| k6 | 부하 및 성능 테스트 | brew install k6 |
예 | AGPL-3.0 |
| Newman | CI에서 Postman 컬렉션 실행 | npm i -g newman |
예 | Apache-2.0 |
| Tavern | pytest 내부의 API 테스트 | pip install tavern |
예 | MIT |
| Venom | 다중 실행기 통합 스위트 | GitHub 릴리스 | 예 | BSD |
| apidog-cli | 설계-테스트 통합 워크플로우 | npm i -g apidog-cli |
아니요 (무료 티어) | 상업용 |
작업에 맞는 도구를 선택하세요. 빠르고 읽기 쉬운 요청 확인을 원한다면 Hurl 또는 Newman을, 스키마가 있고 버그를 찾아내고 싶다면 Schemathesis를, 규모가 문제라면 k6를, 테스트가 더 큰 스위트 안에 있어야 한다면 Tavern 또는 Venom을 선택하세요. 이러한 도구를 더 큰 프로세스와 비교한다면, API 테스트 전략 가이드는 각 유형이 어디에 적합한지 다루고, 헤드리스 API 테스트 도구 문서는 UI 없이 테스트를 실행하는 방법을 살펴봅니다.
마무리
오픈소스 CLI 도구는 직접 읽고, 포크하고, 원하는 방식으로 실행할 수 있는 API 테스트 환경을 제공합니다. Hurl과 Newman은 일상적인 요청 확인을 처리하고, Schemathesis와 Dredd는 계약을 강제하며, k6는 성능을 향상시키고, Tavern과 Venom은 API 테스트를 더 넓은 스위트에 통합합니다. 라이선스와 수행해야 할 한 가지 작업을 기준으로 선택하십시오. 두 가지 이상을 실행하는 데는 아무런 문제가 없습니다.
툴체인을 유지보수하는 대신 한곳에서 설계, 테스트, 목킹, 문서화를 수행하고 싶다면, Apidog은 전체 라이프사이클을 다루며 CI를 위한 apidog-cli를 제공합니다. Apidog을 다운로드하여 위 도구들과 함께 CLI를 사용해보고 어떤 조합이 파이프라인에 가장 적합한지 확인해 보세요.