대부분의 API 테스트 도구는 단일 요청을 보내기 전에 창을 열고, 로그인하고, 작업 공간을 클릭하도록 요구합니다. 첫인상으로는 괜찮지만, 한 줄을 입력하고 응답을 읽은 다음 다음으로 넘어가는 터미널 환경에서는 적합하지 않습니다. 경량 명령줄 도구는 순서를 바꿉니다. 즉, 도구는 뒤로 물러나고 요청이 전체 상호 작용이 됩니다.
여기서 "경량"이라는 단어는 특정 의미를 가집니다. 작은 설치 공간, 종종 단일 바이너리 또는 빠른 npx 실행. 빠른 시작 시간 덕분에 엔드포인트에 접속하는 것이 즉각적으로 느껴집니다. 첫 요청을 실행하기 위한 설정이 거의 없거나 아예 없습니다. jq나 grep으로 파이프할 수 있는 터미널 우선 출력. 이것은 "어떤 도구가 오픈 소스인가" 또는 "어떤 도구가 가장 많은 기능을 가지고 있는가"라는 질문과는 다릅니다. 이는 점유 공간과 마찰에 관한 것입니다. 호스팅된 GUI도 다루는 더 광범위한 조사를 원하시면 최고의 무료 API 테스트 도구 요약본을 참조하세요.
아래는 REST 및 HTTP API 테스트를 위한 여덟 가지 경량 CLI 도구이며, 대략적으로 가장 작고 수동적인 것부터 CI에서 전체 테스트 스위트를 실행하는 도구까지 순서대로 나열되어 있습니다. 각 항목에는 실제 설치 명령, 작동 방식을 보여주는 하나의 명령, 가장 적합한 용도, 그리고 솔직한 한계가 포함되어 있습니다. 마지막으로, Apidog CLI는 시각적으로 구축한 시나리오를 실행하고 종료 코드를 통해 파이프라인을 제어하는 경량 바이너리입니다.
API 테스트에서 CLI 도구를 "경량"으로 만드는 요소
많은 도구가 터미널에서 실행됩니다. 그러나 모든 도구가 가볍게 느껴지는 것은 아닙니다. 이 목록에서 도구가 자격을 갖추는 네 가지 기준은 다음과 같습니다.
- 작은 설치 공간. 단일 바이너리,
pip/npm설치 또는npx한 줄 명령. 먼저 설정해야 하는 런타임이 없으며, 이상적으로는 데몬도 없습니다. - 빠른 시작. 도구가 워밍업 없이 실행되어 요청을 보냅니다. Rust 및 Go 바이너리가 여기서 강점을 보이며, 무거운 런타임을 부팅하는 모든 것은 약점을 보입니다.
- 낮은 또는 제로 설정. 프로젝트 파일, 계정, 로그인 없이 첫 요청을 보낼 수 있습니다. 설정은 선택 사항이며, 저장하고 반복하고 싶을 때 사용합니다.
- 터미널 친화적 출력. 결과를 한눈에 읽고 다른 명령으로 파이프할 수 있는 형태로 출력합니다. 종료 코드는 의미가 있어서 CI에서 이를 통해 게이트를 설정할 수 있습니다.
이 도구들은 처음 세 가지를 최우선으로 하며, 마지막 두 가지는 네 번째에 의존합니다. 이는 경량 바이너리가 파이프라인에서 제 역할을 하는 부분이기 때문입니다. 대화형으로 수동으로 엔드포인트를 호출하는 측면을 더 깊이 살펴보고 싶다면 REST API 테스트를 위한 curl 대안 가이드가 수동 클라이언트에 대해 더 자세히 다룹니다.
curl: 이미 설치된 기준 도구
curl은 거의 확실하게 이미 가지고 있는 도구입니다. macOS, 대부분의 Linux 배포판, 그리고 최신 Windows에 포함되어 있으므로 가장 가벼운 설치는 "설치 없음"입니다. HTTP, HTTPS 및 기타 여러 프로토콜을 지원하며, 다른 모든 클라이언트가 스스로를 측정하는 기준입니다.
# 이미 머신에 있습니다; 버전을 확인하세요
curl --version
# JSON을 POST하고 HTTP 상태만 출력합니다
curl -s -o /dev/null -w "%{http_code}\n" \
-X POST https://httpbin.org/post \
-H "Content-Type: application/json" \
-d '{"user":"acme","plan":"pro"}'
최고의 용도: 빠르고 일회성 요청, 스크립트, 그리고 새로운 것을 설치할 수 없는 모든 환경. 솔직한 한계: 사용 편의성이 구식입니다. 헤더를 수동으로 설정해야 하고, JSON은 예쁘게 출력되지 않으며, 응답을 검증하려면 jq로 파이프하고 종료 코드를 직접 확인해야 합니다. 요청을 보내고 보여줄 뿐, 테스트하지는 않습니다.
HTTPie: 인간을 위한 curl
HTTPie는 curl과 동일한 요청을 보내지만, 사람을 위해 만들어진 문법을 사용합니다. 명령은 http이며, 헤더와 JSON 필드는 간단한 key=value 쌍이고, 출력은 기본적으로 색상화되고 포맷됩니다. Python으로 작성되었으므로 Python 런타임이 필요하여 단일 바이너리보다 무겁지만, 여전히 한 줄로 설치할 수 있습니다.
python -m pip install httpie # 또는: brew install httpie
# JSON POST: age:=24는 숫자를 보내고, name=는 문자열을 보냅니다
http POST httpbin.org/post name=acme age:=24 plan=pro
최고의 용도: 플래그 없이 읽기 쉬운 출력을 원할 때 수동으로 API를 탐색할 때. 솔직한 한계: Python 시작은 컴파일된 바이너리보다 눈에 띄게 느리며, 깨끗한 시스템에 설치하려면 Python이 없으면 Python을 가져와야 합니다. curl과 마찬가지로, 테스트 실행기가 아닌 클라이언트입니다. 응답을 읽을 뿐, 검증하지는 않습니다.
xh: 단일 바이너리로 구현된 HTTPie의 속도
xh는 HTTPie의 친숙한 문법을 Rust로 재구현하고, 단일 정적 링크 바이너리로 제공됩니다. 동일한 key=value 사용 편의성과 색상 출력을 얻을 수 있으며, 더 빠른 시작과 바이너리 자체 외에는 설치할 것이 없습니다. HTTP/2를 지원하며 --curl 옵션으로 해당 curl 명령을 출력할 수도 있습니다.
brew install xh # 또는: cargo install xh --locked
# HTTPie와 동일한 문법, 더 빠른 시작
xh POST httpbin.org/post name=acme age:=24 plan=pro
최고의 용도: HTTPie의 느낌을 좋아하지만 런타임 없는 빠르고 단일한 바이너리를 원하는 개발자. 솔직한 한계: 모든 HTTPie 기능을 구현하지는 않으며 플러그인 시스템도 없습니다. HTTPie보다 역사가 짧아서 주변 생태계가 작습니다. 여전히 클라이언트일 뿐, 검증 엔진은 아닙니다.
Hurl: CI에서 실행되는 일반 텍스트 테스트
Hurl은 이 목록이 "요청 보내기"에서 "응답 테스트"로 넘어가는 지점입니다. 일반 텍스트 .hurl 파일에 작성된 HTTP 요청을 실행하고 결과에 대해 검증합니다. Rust로 작성되었으며 내부적으로 libcurl을 기반으로 하며, 런타임 없이 단일 바이너리로 제공됩니다. 테스트는 요청 자체와 거의 비슷하게 읽혀서 풀 리퀘스트에서 검토하기 쉽습니다.
brew install hurl # 또는: cargo install --locked hurl
cat > login.hurl <<'EOF'
POST https://httpbin.org/post
{ "user": "acme", "plan": "pro" }
HTTP 200
[Asserts]
jsonpath "$.json.user" == "acme"
EOF
hurl --test login.hurl # 검증 실패 시 0이 아닌 종료 코드 반환
최고의 용도: 읽기 쉬운 텍스트로 버전 관리에 보관하는 계약 방식 검사 및 스모크 테스트. --test 플래그는 깔끔한 CI 게이트 역할을 합니다. 검증 실패 시 0이 아닌 종료 코드를 반환합니다. 솔직한 한계: HTTP 중심이므로 gRPC를 구동하거나 실제 부하를 생성하지 않습니다. 복잡한 흐름은 스크립팅 언어 대신 더 많은 .hurl 파일을 의미합니다.
Step CI: 다단계 흐름을 위한 하나의 YAML 파일
Step CI는 단일 YAML 파일에 설명된 API 워크플로우를 실행합니다. REST, GraphQL, gRPC, tRPC 및 SOAP를 하나의 워크플로우에서 다루며, OpenAPI 스키마에 대해 유효성을 검사할 수 있습니다. npm에서 설치하고 동일한 파일을 로컬 및 CI에서 실행합니다. 테스트가 실제로 시퀀스일 때 잘 읽힙니다. 예를 들어, 로그인하고 토큰을 캡처한 다음 다음 호출에 사용하고 결과를 확인하는 것과 같습니다.
npm install -g stepci
# workflow.yml은 단계, 캡처, 검사를 설명합니다
stepci run workflow.yml
최고의 용도: 랩톱과 파이프라인에서 동일하게 실행되는 다단계 API 흐름을 설명하는 하나의 선언적 파일을 원하는 팀. 솔직한 한계: Node 패키지이므로 Rust 또는 Go 바이너리보다 무겁고 런타임을 포함합니다. 릴리스 주기가 느려졌으므로, 이를 기반으로 파이프라인을 구축하기 전에 저장소의 최근 활동을 확인하세요. 이러한 구성 요소가 완전한 테스트 계획에 어떻게 들어맞는지는 API 테스트 전략을 참조하세요.
k6: 터미널에서 실행되는 경량 부하 테스트
k6는 다른 질문에 답합니다. "이 응답이 정확한가"가 아니라 "부하를 견딜 수 있는가"입니다. Go로 작성되었으며 단일 정적 바이너리로 제공되고, 스크립트는 일반 JavaScript입니다. 최소한의 리소스 사용을 위해 설계되어 랩톱에서도 실제 트래픽을 보낼 수 있습니다. 임계값은 부하 테스트를 통과/실패 게이트로 만듭니다. 하나라도 위반하면 k6는 코드 99로 종료하며, 파이프라인은 이를 실패로 읽습니다.
brew install k6 # 또는 Docker를 통해 실행: docker run grafana/k6
cat > load.js <<'EOF'
import http from 'k6/http';
import { check } from 'k6';
export const options = {
vus: 10, duration: '30s',
thresholds: { http_req_duration: ['p(95)<500'] },
};
export default function () {
const res = http.get('https://httpbin.org/get');
check(res, { 'status is 200': (r) => r.status === 200 });
}
EOF
k6 run load.js
최고의 용도: 클러스터를 설정하지 않고도 CI에서 스크립팅하고 실행할 수 있는 성능 및 부하 검사. 솔직한 한계: 부하 도구이지 기능 테스트 클라이언트가 아닙니다. 단일 응답을 눈으로 확인하기 위해 사용하지는 않을 것입니다. 의미 있는 시나리오를 작성하려면 JavaScript API를 배워야 합니다.
Newman: Postman 컬렉션을 헤드리스로 실행
Newman은 Postman 컬렉션을 위한 명령줄 실행기입니다. 팀이 이미 Postman에서 요청 및 테스트를 구축하고 있다면, Newman은 GUI 없이 터미널에서 해당 컬렉션을 정확하게 실행하며, 이는 CI에서 필요한 것입니다. 컬렉션(및 선택적으로 환경)을 JSON으로 내보내고 Newman이 이를 가리키도록 합니다.
npm install -g newman
# Postman에서 내보낸 collection.json; -e는 환경을 전달합니다
newman run collection.json -e staging.json
최고의 용도: Postman에 투자했으며 기존 컬렉션을 파이프라인에서 헤드리스로 실행하기를 원하는 팀. Newman은 테스트 실패 시 0이 아닌 종료 코드를 반환하므로 CI 게이트를 깔끔하게 처리합니다. 솔직한 한계: Node 패키지이며 Postman 형식 컬렉션만 실행하므로, 이미 해당 생태계에 속해 있는 경우에 가장 유용합니다. 누군가 GUI에서 구축한 테스트를 실행하는 것이며, 작성은 여전히 GUI에서 이루어집니다.
Apidog CLI: 구축한 시나리오 실행, 종료 코드로 CI 제어
Apidog CLI는 Apidog의 경량 끝점입니다. apidog-cli라는 npm 패키지로, Apidog에서 시각적으로 설계한 테스트 시나리오를 터미널에서 바로 실행합니다. 테스트 구축 부분은 GUI에 남아 있으며, 요청 연결, 변수 추출, 검증 작성은 빠릅니다. CLI는 해당 시나리오 중 하나를 헤드리스로 실행하고 종료 코드를 반환하는 작은 부분입니다. Apidog는 오픈 소스가 아니지만, 무료 등급과 이 CLI는 별도의 클라이언트, 실행기, 부하 도구를 함께 엮는 것에 대한 통합 대안을 제공합니다.
npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
# 시나리오의 CI/CD 탭에서 정확한 명령을 복사합니다
apidog run -t <scenario_id> -e <env_id> -r cli
시나리오 및 환경 ID를 추측할 필요가 없습니다. Apidog에서 테스트 시나리오를 열고 CI/CD 탭으로 이동하여 ID가 이미 채워진 생성된 apidog run 명령을 복사하세요. -r cli 리포터는 터미널에 단계별 결과와 요약을 출력합니다. CI 대시보드에서 결과를 구문 분석해야 할 때는 -r cli,junit를 추가하세요. 위에 나열된 도구와 마찬가지로, apidog run은 모든 검증이 통과하면 0으로 종료하고, 실패하는 것이 있으면 0이 아닌 코드로 종료하므로 파이프라인은 이를 깔끔한 게이트로 처리합니다. 그 출력은 agentHints.nextSteps를 포함하는 구조화된 JSON이므로, AI 코딩 에이전트가 실행하고 읽기에도 쉽습니다.
최고의 용도: 시각적 편집기에서 복잡하고 다단계 시나리오를 작성하지만, CI 또는 에이전트에서 헤드리스로 실행하기를 원하는 팀. 솔직한 한계: curl 또는 xh와 달리, Apidog 프로젝트에 보관하는 시나리오에 묶여 있으므로, 순수한 HTTP 클라이언트가 아닌 통합 플랫폼 옵션입니다. 전체 명령 세트는 Apidog CLI 완전 가이드, apidog run 명령 참조, 그리고 Apidog CLI로 명령줄에서 REST API 테스트하는 방법 가이드를 참조하세요.
선택 방법
올바른 도구는 "하나의 요청 보내기"를 얼마나 넘어서야 하는지에 따라 달라집니다.
| 도구 | 최고의 용도 | 설치 | 오픈 소스? | 참고 |
|---|---|---|---|---|
| curl | 일회성 요청, 스크립트 | 사전 설치됨 | 예 (MIT/curl) | 보편적; 검증은 DIY |
| HTTPie | 읽기 쉬운 수동 요청 | pip install httpie |
예 (BSD-3) | 친숙한 문법; Python 런타임 |
| xh | HTTPie 느낌, 더 빠름 | brew install xh |
예 (MIT) | 단일 Rust 바이너리 |
| Hurl | 일반 텍스트 HTTP 테스트 | brew install hurl |
예 (Apache-2.0) | --test로 CI 게이트 설정 |
| Step CI | 다단계 YAML 흐름 | npm i -g stepci |
예 (MPL-2.0) | REST/GraphQL/gRPC; Node 런타임 |
| k6 | 부하 및 성능 | brew install k6 |
예 (AGPL-3.0) | JS 스크립트; 임계값 초과 시 실행 실패 |
| Newman | CI에서 Postman 컬렉션 | npm i -g newman |
예 (Apache-2.0) | Postman JSON을 헤드리스로 실행 |
| Apidog CLI | 시각적으로 구축된 시나리오, 헤드리스 실행 | npm i -g apidog-cli |
아니요 (무료 등급) | 종료 코드 게이트; 에이전트 친화적 JSON |
수동 작업을 위해 상단부터 시작하세요. 엔드포인트를 찔러보기 위해서는 curl 또는 xh를 사용하세요. 검사를 버전 제어에서 실행하고 싶을 때는 Hurl로 내려가세요. 부하 문제가 생기면 k6를 사용하고, 테스트가 이미 Postman에 있다면 Newman을 사용하세요. 복잡한 시나리오를 편집기에서 구축하고 다른 곳에서 헤드리스로 실행하고 싶다면 Apidog CLI를 선택하세요. 이러한 도구들을 전체 GUI 없는 워크플로우와 비교해보고 있다면, 헤드리스 API 테스트 도구 가이드가 인터페이스 없이 테스트를 실행하는 방법을 다룹니다.
경량 도구가 빛을 발하는 곳
경량 CLI 도구는 GUI가 속도를 늦추는 날에 위력을 발휘합니다. 즉, 터미널 깊이 몰입해 있을 때, 인간의 개입 없이 CI에서 테스트를 실행해야 할 때, 그리고 점점 더 AI 에이전트가 검사를 실행할 때입니다. curl과 xh는 수동 루프를 간결하게 유지합니다. Hurl과 Step CI는 임시 요청을 반복 가능한 테스트로 전환합니다. k6는 부하 질문에 답합니다. Newman은 Postman에서 이미 구축한 것을 실행합니다.
Apidog CLI는 테스트 구축과 어디서든 실행하는 것 사이의 간극을 메웁니다. Apidog에서 시나리오를 한 번 설계한 다음, apidog run 명령으로 터미널, 파이프라인 또는 에이전트에서 실행하고, 종료 코드가 빌드의 성공 여부를 결정합니다. Apidog를 다운로드하여 하나의 시나리오를 구축하고, 해당 apidog run 명령을 CI 설정에 추가하여 전체 루프가 닫히는 것을 확인하세요.