2026년 최고의 CLI 기반 API 테스트 도구 추천

API 테스트는 더 이상 GUI에 묶여 있지 않습니다. 디스플레이가 없는 CI 컨테이너, SSH로만 접속하는 스테이징 서버, 셸 명령만 실행하는 AI 에이전트에서도 테스트는 실행되어야 합니다. 이 환경에서는 사람이 결과를 확인하지 않아도, 명령의 종료 코드만으로 테스트 통과와 실패를 판별할 수 있어야 합니다.

지금 Apidog 사용해 보기

이 글에서는 셸 프롬프트에서 설치하고, 명령 하나로 실행하며, 종료 코드로 결과를 CI에 전달할 수 있는 API 테스트 도구 10가지를 정리합니다. 순위는 내장 어설션, 다단계 흐름 지원, CI용 보고서, 유지 보수 상태를 기준으로 합니다. curl처럼 수동 요청에 유용한 클라이언트도 포함했지만, 이들은 테스트 러너와는 구분해야 합니다. GUI와 호스팅 도구까지 포함한 목록은 최고의 무료 API 테스팅 도구를 참고하세요.

테스팅 도구와 클라이언트의 차이점

터미널 클라이언트는 요청을 보내고 응답을 출력합니다. 반면 터미널 테스팅 도구는 응답이 기대값을 충족하는지 판정하고, 실패 시 0이 아닌 종료 코드로 CI 파이프라인을 중단시킵니다.

테스트 러너를 선택할 때는 다음 네 가지를 확인하세요.

• 내장 어설션: 상태 코드, 헤더, 응답 본문을 jq 조합 없이 검사할 수 있어야 합니다.
• 의미 있는 종료 코드: 성공은 0, 실패는 0이 아닌 값으로 반환해야 합니다.
• 반복 가능성: 셸 히스토리가 아니라 Git으로 관리하는 파일 또는 프로젝트에 테스트가 있어야 합니다.
• 보고서 출력: 사람이 읽을 수 있는 콘솔 출력과 JSON, JUnit, HTML 같은 CI용 결과물을 지원해야 합니다.

이 기준을 바탕으로, 2026년에 터미널 기반 API 테스트에 사용할 수 있는 도구를 살펴보겠습니다.

1. Apidog CLI: 시각적으로 작성하고 어디서나 헤드리스로 실행

Apidog은 API 설계, 테스트, 목업, 문서화를 하나의 프로젝트에서 처리하는 API 플랫폼입니다. apidog-cli는 Apidog에서 만든 테스트 시나리오를 터미널과 CI에서 실행하는 CLI입니다.

시각적 편집기에서 요청 연결, 변수 추출, 어설션을 구성한 뒤 apidog run으로 실행할 수 있습니다.

npm install -g apidog-cli

apidog login --with-token <YOUR_TOKEN>

# Apidog 시나리오의 CI/CD 탭에서 생성된 명령어를 복사합니다.
apidog run -t <scenario_id> -e <env_id> -r cli

구현 순서는 다음과 같습니다.

1. Apidog에서 테스트 시나리오를 만듭니다.
2. 환경 변수와 응답 어설션을 구성합니다.
3. 시나리오의 CI/CD 탭으로 이동합니다.
4. 생성된 apidog run 명령을 CI 설정에 붙여 넣습니다.
5. 필요한 리포터를 선택합니다.

cli, html, json, junit 리포터를 지원하며 결과는 apidog-reports/에 저장됩니다. 따라서 동일한 실행 결과를 터미널 로그, CI 대시보드, 아티팩트 저장소에서 활용할 수 있습니다. CSV 또는 JSON 파일을 사용한 데이터 기반 실행도 지원합니다.

구조화된 JSON 출력에는 agentHints.nextSteps가 포함될 수 있으므로, AI 코딩 에이전트도 화면을 스크래핑하지 않고 실행 결과를 읽고 다음 작업을 판단할 수 있습니다. Node.js 16 이상이 필요합니다.

적합한 경우

• 다단계 API 시나리오를 시각적으로 만들고 싶을 때
• 로컬, CI, 에이전트 환경에서 같은 시나리오를 실행할 때
• HTML, JSON, JUnit 결과물을 함께 남겨야 할 때

한계

• 오픈 소스가 아닙니다.
• 단순한 임시 HTTP 요청 도구가 아니라 Apidog 프로젝트에 저장된 시나리오를 실행하는 통합 플랫폼 방식입니다.

전체 명령어는 Apidog CLI 전체 가이드에서 확인할 수 있습니다.

2. Hurl: 일반 텍스트로 작성하는 HTTP 테스트

Hurl은 일반 텍스트 파일로 HTTP 요청과 응답 어설션을 작성하는 도구입니다. Rust와 libcurl 기반의 단일 바이너리로 제공되므로 별도의 런타임 설치 없이 사용할 수 있습니다.

brew install hurl
# 또는
cargo install --locked 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

hurl --test는 어설션 실패 시 0이 아닌 종료 코드를 반환하므로 CI에서 바로 게이트로 사용할 수 있습니다.

적합한 경우

• Git에서 검토하기 쉬운 테스트 파일이 필요할 때
• 계약 테스트와 스모크 테스트를 텍스트로 관리할 때
• 런타임 의존성을 최소화하고 싶을 때

한계

• HTTP 중심 도구입니다.
• gRPC 실행이나 부하 생성이 목적은 아닙니다.
• 복잡한 분기 로직은 스크립트보다 여러 .hurl 파일로 분리하게 될 수 있습니다.

3. Newman: Postman 컬렉션을 헤드리스로 실행

Newman은 Postman 컬렉션을 실행하는 오픈 소스 CLI 러너이며 Apache-2.0 라이선스를 사용합니다. 이미 Postman에서 요청과 테스트를 작성했다면 컬렉션과 환경 파일을 내보내 CI에서 실행할 수 있습니다.

npm install -g newman

newman run collection.json -e staging.json

CI에서는 다음처럼 사용할 수 있습니다.

newman run collection.json \
  -e staging.json \
  --reporters cli,json

테스트 실패 시 Newman은 0이 아닌 종료 코드로 종료합니다.

적합한 경우

• 기존 Postman 컬렉션을 바로 CI에서 실행할 때
• 컬렉션과 환경을 JSON 파일로 관리할 때
• 오픈 소스 CLI 러너가 필요할 때

한계

• Postman 형식 컬렉션만 실행합니다.
• 테스트 작성은 일반적으로 Postman GUI에서 수행합니다.
• 컬렉션을 실행하는 도구이지, 테스트 작성 방식을 바꾸는 도구는 아닙니다.

4. Postman CLI: Postman 워크스페이스에서 직접 실행

Postman CLI는 Postman의 비공개 소스 CLI 러너입니다. JSON 파일을 내보내는 대신 Postman 계정으로 로그인한 뒤 워크스페이스의 컬렉션 ID와 환경 ID를 사용해 실행할 수 있습니다.

postman login --with-api-key <YOUR_API_KEY>

postman collection run <collection_id> -e <environment_id>

적합한 경우

• Postman 클라우드와 연결된 실행 결과가 필요할 때
• 컬렉션 JSON을 별도로 내보내지 않으려 할 때
• Postman 워크스페이스 중심으로 테스트를 운영할 때

한계

• 비공개 소스입니다.
• Postman 계정과 연결됩니다.
• Newman과 Postman CLI 중 어떤 러너를 표준으로 삼을지 팀에서 결정해야 합니다.

두 도구의 선택 기준은 Postman CLI vs Newman 비교에서 확인할 수 있습니다.

5. Bruno CLI: Git 네이티브 .bru 컬렉션 실행

Bruno는 API 컬렉션을 일반 폴더와 텍스트 기반 .bru 파일로 저장합니다. 요청, 어설션, 스크립트를 코드처럼 Git 저장소에서 관리할 수 있습니다.

CLI는 @usebruno/cli 패키지로 설치합니다.

npm install -g @usebruno/cli

# 현재 컬렉션 폴더의 요청 실행
bru run --env staging

CI 결과가 필요하다면 JSON, JUnit, HTML 형식의 보고서를 생성할 수 있습니다.

적합한 경우

• API 컬렉션 변경을 풀 리퀘스트에서 코드 리뷰할 때
• 클라우드 계정 없이 오프라인 실행을 원할 때
• 요청 정의와 어설션을 같은 파일에 두고 싶을 때

한계

• 텍스트 기반 작성 방식은 개발자 중심 팀에 더 잘 맞습니다.
• 생태계는 Postman보다 젊습니다.

Bruno CLI vs Apidog CLI에서 두 실행 모델을 비교할 수 있습니다.

6. Schemathesis: OpenAPI 스키마에서 테스트 케이스 생성

Schemathesis는 OpenAPI 또는 GraphQL 스키마를 읽고, Python Hypothesis 기반의 속성 기반 테스트로 많은 입력 조합을 생성합니다.

개별 테스트 케이스를 직접 모두 작성하는 대신, 스키마를 기준으로 퍼징을 수행해 다음 문제를 찾습니다.

• 서버의 500 오류
• 응답 스키마 위반
• 문서화된 계약을 지키지 않는 응답

pip install schemathesis

schemathesis run https://api.example.com/openapi.json

적합한 경우

• 릴리스 전에 예상하지 못한 엣지 케이스를 찾을 때
• OpenAPI 스키마의 정확성을 검증할 때
• 수동으로 작성한 테스트의 빈틈을 보완할 때

한계

• 실제로 사용할 수 있는 스키마가 필요합니다.
• API 규모가 크면 훅과 옵션으로 범위를 제한하지 않을 경우 많은 결과가 나올 수 있습니다.

7. Step CI: 다단계 API 흐름을 YAML로 정의

Step CI는 하나의 YAML 파일에 API 워크플로우, 변수 캡처, 검증 규칙을 선언하는 도구입니다. REST, GraphQL, gRPC, tRPC, SOAP 흐름을 다루며 OpenAPI 스키마에 대한 검증도 지원합니다.

npm install -g stepci

stepci run workflow.yml

다단계 로그인 흐름처럼 앞선 응답에서 토큰을 가져와 다음 요청에 전달하는 시나리오에 적합합니다.

# workflow.yml의 구조 예시
name: 로그인 후 보호된 API 호출
steps:
  - name: 로그인
    # 요청 및 토큰 캡처 정의
  - name: 프로필 조회
    # 캡처한 토큰 사용 및 응답 검증 정의

적합한 경우

• 로그인 → 토큰 추출 → 보호된 API 호출 같은 흐름이 있을 때
• 스크립트보다 선언형 YAML 구성을 선호할 때
• 하나의 파일로 워크플로우를 관리할 때

한계

• Node 런타임을 사용합니다.
• 릴리스 주기가 느려졌으므로 도입 전 저장소의 최근 활동을 확인하는 것이 좋습니다.

8. curl: 이미 설치된 기본 클라이언트

curl은 macOS, 대부분의 Linux 배포판, 최신 Windows 환경에서 기본 제공되는 경우가 많습니다. 설치할 수 없는 잠긴 환경에서도 사용할 수 있는 가장 기본적인 HTTP 클라이언트입니다.

# JSON POST 요청 후 HTTP 상태 코드만 출력
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://api.example.com/orders \
  -H "Content-Type: application/json" \
  -d '{"sku":"A-102","qty":2}'

간단한 상태 코드 검사는 셸 조건문으로 연결할 수 있습니다.

status=$(
  curl -s -o /dev/null -w "%{http_code}" \
    https://api.example.com/health
)

test "$status" = "200"

적합한 경우

• 일회성 요청을 보낼 때
• 설치가 제한된 환경에서 HTTP 호출을 해야 할 때
• 셸 스크립트에 간단한 API 호출을 넣을 때

한계

• 어설션은 전적으로 직접 구현해야 합니다.
• JSON 본문 검사는 jq, 상태 비교, 오류 처리 등을 별도로 조합해야 합니다.
• 요청을 보내고 결과를 보여주는 도구이지, 완성된 테스트 프레임워크는 아닙니다.

curl만으로 부족한 시점은 REST API 테스트를 위한 curl 대안에서 확인할 수 있습니다.

9. HTTPie 및 xh: 읽기 쉬운 수동 요청

HTTPie는 터미널 HTTP 요청을 읽기 쉬운 문법으로 제공합니다. JSON 필드는 key=value 형식으로 작성하고, 응답은 형식화된 출력으로 확인할 수 있습니다.

xh는 유사한 문법을 Rust 단일 바이너리로 구현한 도구입니다. 빠른 시작과 --curl 옵션을 통한 curl 명령 출력이 특징입니다.

# HTTPie
http POST api.example.com/users name=acme plan=pro

# xh
xh POST api.example.com/users name=acme plan=pro

적합한 경우

• 실제 테스트를 작성하기 전에 API를 수동으로 탐색할 때
• curl보다 읽기 쉬운 요청 문법이 필요할 때
• API 응답을 빠르게 확인할 때

한계

• 둘 다 테스트 러너가 아니라 HTTP 클라이언트입니다.
• 응답에 대한 내장 어설션을 제공하지 않습니다.
• HTTPie는 Python 런타임을 사용하며, xh는 기능 범위를 줄이는 대신 단일 바이너리와 빠른 실행에 초점을 둡니다.

10. k6: 성능과 부하가 문제일 때

k6는 “응답이 올바른가?”가 아니라 “트래픽이 증가해도 서비스가 버티는가?”를 검증하는 부하 테스트 도구입니다.

Grafana의 단일 Go 바이너리이며 JavaScript로 시나리오를 작성합니다. 임계값(threshold)을 설정하면 성능 기준을 통과/실패 게이트로 만들 수 있고, 위반 시 k6는 0이 아닌 종료 코드로 종료합니다.

brew install k6

k6 run load.js

load.js에서는 가상 사용자 수, 실행 시간, 임계값을 정의합니다.

import http from "k6/http";
import { check } from "k6";

export const options = {
  vus: 10,
  duration: "30s",
  thresholds: {
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  const response = http.get("https://api.example.com/health");

  check(response, {
    "상태 코드가 200이다": (res) => res.status === 200,
  });
}

적합한 경우

• 기능 테스트와 함께 성능 기준을 CI에서 검증할 때
• API의 응답 시간과 오류율을 임계값으로 관리할 때
• 로컬과 파이프라인에서 같은 부하 시나리오를 실행할 때

한계

• 기능 테스트 도구가 아니라 부하 테스트 도구입니다.
• AGPL-3.0 라이선스를 사용합니다.
• 의미 있는 성능 시나리오를 만들려면 JavaScript API를 익혀야 합니다.

대화형 도구를 선호한다면

셸을 벗어나지 않으면서 Postman과 유사한 인터페이스를 원한다면, atac, posting 같은 TUI 클라이언트가 별도 선택지가 될 수 있습니다. 이 도구들은 터미널 안에서 요청 편집기를 제공해 API 탐색에 유용합니다.

다만 이들은 일반적으로 파이프라인을 제어하는 테스트 러너가 아니라 대화형 클라이언트에 가깝습니다. 자세한 목록은 최고의 터미널 및 TUI REST API 클라이언트를 참고하세요.

비교표

도구	작업	내장 어설션	설치	오픈 소스
Apidog CLI	시각적으로 작성된 시나리오를 CI에서 실행	예	npm i -g apidog-cli	아니요 (무료 등급)
Hurl	일반 텍스트 HTTP 테스트	예	brew install hurl	Apache-2.0
Newman	Postman 컬렉션 헤드리스 실행	예	npm i -g newman	Apache-2.0
Postman CLI	클라우드 연결 Postman 실행	예	Postman 설치 프로그램	아니요
Bruno CLI	Git 네이티브 .bru 컬렉션	예	npm i -g @usebruno/cli	MIT
Schemathesis	스키마에서 퍼징	생성됨	pip install schemathesis	MIT
Step CI	다단계 YAML 흐름	예	npm i -g stepci	MPL-2.0
curl	원시 요청, 스크립팅	DIY	사전 설치됨	예
HTTPie / xh	읽기 쉬운 수동 요청	아니요	brew install httpie / xh	예
k6	통과/실패 임계값을 포함한 부하 테스트	임계값	brew install k6	AGPL-3.0

선택 방법

도구 이름보다 현재 해결해야 할 작업에서 시작하세요.

• Postman 컬렉션이 이미 있다면: Newman 또는 Postman CLI로 기존 테스트를 CI에 연결하세요.
• Git에서 검토 가능한 텍스트 테스트가 필요하다면: Hurl 또는 Bruno CLI를 선택하세요.
• 정확한 OpenAPI 스키마가 있다면: Schemathesis를 추가해 수동 테스트가 놓친 입력 조합을 찾으세요.
• 다단계 선언형 흐름이 필요하다면: Step CI를 검토하세요.
• 수동 요청과 긴급 점검이 필요하다면: curl 또는 xh를 유지하세요.
• 성능과 용량을 검증해야 한다면: 기능 테스트와 별도로 k6를 도입하세요.
• 시각적 편집기에서 시나리오를 작성하고 여러 환경에서 실행하려면: Apidog CLI가 적합합니다.

Apidog CLI는 API 설계, 목업 데이터, 문서화, 테스트 시나리오를 같은 프로젝트에서 다룬다는 점이 특징입니다. 자세한 실행 모델은 Apidog CLI: 터미널에 사는 API 클라이언트에서 확인할 수 있습니다. 더 넓은 테스트 계층 설계는 API 테스팅 전략 가이드를 참고하세요.

FAQ

터미널에서만 API 테스트를 할 수 있나요?

네. Hurl, Bruno, Step CI처럼 파일 기반으로 테스트를 작성할 수 있고, Apidog이나 Postman에서 시각적으로 작성한 뒤 CLI로 헤드리스 실행할 수도 있습니다. 이 목록의 테스트 러너는 CI에서 사용할 수 있는 종료 코드를 반환합니다.

터미널 API 클라이언트와 테스팅 도구의 차이점은 무엇인가요?

클라이언트인 curl, HTTPie, xh는 요청을 보내고 응답을 보여줍니다. Apidog CLI, Hurl, Newman 같은 테스트 도구는 응답에 어설션을 적용하고, 실패 시 0이 아닌 종료 코드로 결과를 보고합니다. 클라이언트는 탐색용이고, 테스트 도구는 CI 게이트용입니다.

CI 파이프라인에서 실행할 수 있는 도구는 무엇인가요?

apidog run, hurl --test, newman run, postman collection run, bru run, schemathesis run, stepci run, k6 run은 모두 실패 시 0이 아닌 종료 코드로 끝납니다. GitHub Actions 설정 예시는 GitHub Actions에서 Apidog CLI 테스트를 실행하는 방법을 참고하세요.

부하 테스트를 처리하는 도구가 있나요?

이 목록에서는 k6가 부하 테스트 전문 도구입니다. 임계값을 사용해 성능 기준을 통과/실패 게이트로 설정할 수 있습니다. 나머지 도구는 주로 응답의 정확성을 검증하므로, 많은 팀이 기능 테스트 러너와 k6를 함께 사용합니다.

OpenAPI 사양이 반드시 필요한가요?

Schemathesis는 스키마에서 테스트를 생성하므로 OpenAPI 또는 GraphQL 스키마가 필요합니다. 다른 도구에서는 사양이 필수는 아닙니다. Apidog은 OpenAPI 3.x, Swagger 2.0, Postman 컬렉션을 가져올 수 있으며, Step CI는 스키마에 대해 응답을 검증할 수 있습니다.

핵심은 간단합니다. 테스트 작성 방식은 팀에 맞게 선택하되, 실행 결과가 셸에서 명확한 종료 코드로 반환되는지 확인하세요. 시각적 시나리오 작성과 헤드리스 실행을 한 플랫폼에서 처리하려면 Apidog을 다운로드한 뒤 시나리오를 만들고, 생성된 apidog run 명령을 CI에 추가하면 됩니다.