API 테스팅은 GUI를 벗어났습니다. 이제 테스트는 디스플레이가 연결되지 않은 CI 컨테이너, SSH로만 접근 가능한 스테이징 박스, 셸 외에는 아무것도 말하지 않는 AI 에이전트 환경에서 실행됩니다. 이 세 가지 환경 모두에서 터미널은 사람이 지켜보지 않아도 테스트의 통과 또는 실패를 판별하는 곳입니다.
이 글은 셸 프롬프트에서 실제 테스팅 작업을 수행하는 도구들을 순위별로 정리합니다. 여기서 "터미널 기반"이란 전체 루프가 셸에서 실행됨을 의미합니다: 패키지 관리자에서 설치하고, 하나의 명령을 실행하고, 종료 코드를 읽는 것입니다. 순위는 내장된 어설션, 다단계 흐름, CI 준비된 보고서, 그리고 유지 보수 상태를 고려합니다. curl과 같은 수동 클라이언트들도 테스트 실행 사이에 모든 터미널 워크플로우에서 사용되기 때문에 끝 부분에 자리를 차지하고 있습니다. GUI 및 호스팅된 도구를 포함하는 더 넓은 조사를 보려면 최고의 무료 API 테스팅 도구 목록을 참조하세요.
테스팅 도구와 클라이언트의 차이점
터미널 클라이언트는 요청을 보내고 응답을 보여줍니다. 터미널 테스팅 도구는 응답을 판단하고, 파이프라인에서 제어할 수 있는 종료 코드로 판결을 보고합니다. 두 번째 그룹이 이 목록의 핵심이며, 네 가지 특징으로 정의됩니다:
- 내장된 어설션. 상태, 헤더, 본문 검사는
jq조각 대신 도구 자체에 있어야 합니다. - 의미 있는 종료 코드. 성공 시 0, 실패 시 0이 아닌 코드이므로 CI가 빌드를 실패시킵니다.
- 반복성. 테스트는 셸 기록이 아닌 버전 관리 및 재실행이 가능한 파일 또는 프로젝트에 존재합니다.
- 보고서. 사람이 터미널에서 읽을 수 있고, 대시보드가 JSON, JUnit 또는 HTML로 파싱할 수 있는 출력을 제공합니다.
기준이 설정되었으니, 2026년에 여러분의 시간을 투자할 가치가 있는 10가지 도구를 소개합니다.
1. Apidog CLI: 시각적으로 작성하고, 어디서든 헤드리스로 실행
Apidog은 디자인, 테스트, 목업, 문서화를 포괄하는 올인원 API 플랫폼입니다. Apidog CLI (npm에서 apidog-cli)는 이 플랫폼의 터미널 버전입니다. 시각적 편집기에서 요청 연결, 변수 추출, 어설션 등을 통해 테스트 시나리오를 구축한 다음, apidog run 명령어로 어떤 셸에서도 실행하고 파이프라인에 깔끔한 종료 코드를 전달합니다.
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 탭으로 이동하여 생성된 명령어를 복사하세요. 리포터는 cli, html, json, junit를 지원하며, apidog-reports/에 작성되므로 동일한 실행이 터미널, 대시보드 및 아티팩트 저장소를 공급합니다. 데이터 기반 실행은 CSV 또는 JSON 파일에서 반복을 가져옵니다. 출력은 agentHints.nextSteps를 포함하는 구조화된 JSON으로, AI 코딩 에이전트가 스크린 스크래핑 없이 스위트를 실행하고 다음 동작을 결정할 수 있게 합니다. Node.js 16 이상이 필요합니다.
가장 적합한 경우: 복잡하고 다단계 시나리오를 편집기에서 작성하고 노트북, CI 및 에이전트에서 동일하게 실행하기를 원하는 팀. 솔직한 한계: 오픈 소스가 아니며 임시 발송기가 아닙니다. 시나리오는 Apidog 프로젝트에 존재하므로, 이는 단순한 HTTP 도구라기보다는 통합 플랫폼 옵션입니다. Apidog CLI 전체 가이드는 전체 명령어 세트를 다룹니다.
2. Hurl: 하나의 Rust 바이너리로 된 일반 텍스트 테스트
Hurl은 일반 텍스트 형식으로 작성된 HTTP 요청을 실행하고 응답에 대한 어설션을 수행합니다. libcurl 위에 Rust로 구축되었으며 단일 바이너리로 제공되므로 런타임을 설치할 필요가 없습니다. 테스트는 거의 원시 HTTP처럼 읽히므로 풀 리퀘스트에서 검토하기 쉽습니다.
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 # 어설션 실패 시 0이 아닌 종료 코드 반환
가장 적합한 경우: 버전 관리에서 읽기 쉬운 텍스트로 유지하는 계약 스타일 검사 및 스모크 테스트. --test 플래그는 자연스러운 CI 게이트웨이 역할을 합니다. 솔직한 한계: HTTP에 중점을 두므로 gRPC를 구동하거나 부하를 생성하지 않으며, 복잡한 로직은 스크립팅 언어 대신 더 많은 .hurl 파일을 의미합니다.
3. Newman: Postman 컬렉션을 헤드리스로 실행
Newman은 Postman 컬렉션을 위한 오픈 소스 커맨드라인 러너입니다 (Apache-2.0). 팀이 이미 Postman에서 요청과 테스트를 작성한다면, Newman은 GUI 없이 터미널에서 정확히 그 컬렉션을 실행합니다. 컬렉션과 환경을 JSON으로 내보내고 Newman에게 해당 파일을 지정합니다.
npm install -g newman
newman run collection.json -e staging.json
가장 적합한 경우: Postman에 투자한 팀이 추가적인 인력 없이 파이프라인에서 기존 컬렉션을 실행하고 싶을 때. 테스트 실패 시 0이 아닌 값으로 종료하므로 CI가 깔끔하게 게이트합니다. 솔직한 한계: Postman 형식 컬렉션만 실행하며, 작성은 여전히 Postman GUI에서 이루어집니다. 테스트를 실행할 뿐, 작성하는 데 도움을 주지는 않습니다.
4. Postman CLI: Newman의 공식 대안
Postman CLI는 Postman 자체의 비공개 소스 러너입니다. Newman과 달리 Postman 계정에 로그인하며, ID로 컬렉션을 직접 워크스페이스에서 실행하고 결과를 Postman 클라우드에 보고할 수 있습니다.
postman login --with-api-key <YOUR_API_KEY>
postman collection run <collection_id> -e <environment_id>
가장 적합한 경우: JSON 파일을 내보내지 않고 클라우드 연결 실행을 원하는 Postman 팀. 솔직한 한계: 비공개 소스이며 Postman 계정에 연결되어 있으며, 두 개의 공식 러너가 있어 어떤 것을 채택해야 할지 혼란을 야기합니다. Postman CLI vs Newman 비교는 각자의 사용 시기를 명확히 설명합니다.
5. Bruno CLI: Git-네이티브 컬렉션, bru로 실행
Bruno는 컬렉션을 일반 폴더에 일반 텍스트 .bru 파일로 저장하므로, 요청은 다른 코드처럼 저장소에 저장됩니다. CLI인 @usebruno/cli는 클라우드 계정 없이 bru 명령어를 사용하여 터미널에서 이 컬렉션을 실행합니다.
npm install -g @usebruno/cli
# 현재 컬렉션 폴더의 모든 요청 실행
bru run --env staging
가장 적합한 경우: 풀 리퀘스트에서 컬렉션을 검토하고 오프라인에서 실행하며, 어설션 및 스크립팅이 동일한 파일 내에서 처리되기를 원하는 팀. JSON, JUnit 및 HTML 보고서를 CI용으로 작성합니다. 솔직한 한계: 일반 텍스트로 작성하는 것은 혼합 팀보다 개발자에게 더 적합하며, 생태계는 Postman보다 젊습니다. Bruno CLI vs Apidog CLI에서 Apidog의 러너와 어떻게 비교되는지 확인하세요.
6. Schemathesis: 스키마가 테스트를 작성합니다
Schemathesis는 다른 경로를 택합니다: OpenAPI 또는 GraphQL 스키마를 읽고 Python의 Hypothesis를 기반으로 하는 속성 기반 테스트를 사용하여 수천 개의 테스트 케이스를 생성합니다. 각 케이스를 작성하는 대신, 입력에 퍼징을 적용하여 500 오류, 스키마 위반, 문서에서 약속한 계약을 위반하는 응답을 찾도록 합니다.
pip install schemathesis
schemathesis run https://api.example.com/openapi.json
가장 적합한 경우: 아무도 테스트할 생각을 하지 못했던 엣지 케이스 버그를 잡는 데, 특히 릴리스 전에 유용합니다. 정확한 스키마를 유지해야 하는 가장 강력한 주장 중 하나입니다. 솔직한 한계: 작동하려면 실제 스키마가 필요하며, 큰 API는 훅과 옵션으로 필터링해야 할 노이즈를 생성할 수 있습니다.
7. Step CI: 다단계 흐름당 하나의 YAML 파일
Step CI는 단일 YAML 파일에 API 워크플로우를 기술합니다: 단계, 캡처된 값, 검사. 하나의 워크플로우로 REST, GraphQL, gRPC, tRPC, SOAP를 커버하며 OpenAPI 스키마에 대해 검증합니다. 동일한 파일이 노트북과 파이프라인에서 실행됩니다.
npm install -g stepci
stepci run workflow.yml
가장 적합한 경우: 스크립팅 없이 선언적으로 기술된 로그인-토큰 사용 시퀀스. 솔직한 한계: Node 런타임을 사용하며, 릴리스 주기가 느려졌으므로, 이를 기반으로 파이프라인을 구축하기 전에 저장소의 최근 활동을 확인하세요.
8. curl: 이미 설치된 기준선
curl은 macOS, 대부분의 Linux 배포판, 최신 Windows에 함께 제공되므로 가장 가벼운 설치는 설치가 없는 것입니다. 다른 모든 도구가 자신을 측정하는 기준 클라이언트이며, -w 및 셸 연결을 통해 최소한의 테스트 하네스 역할을 할 수 있습니다.
# 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}'
가장 적합한 경우: 일회성 요청, 스크립트, 그리고 새로운 것을 설치할 수 없는 잠긴 환경. 솔직한 한계: 어설션은 전적으로 DIY입니다. jq로 파이프하고, 직접 값을 비교하며, 종료 코드를 수동으로 관리해야 합니다. 요청을 보내고 보여줄 뿐, 테스트하지는 않습니다. REST API 테스트를 위한 curl 대안 가이드는 curl만으로는 부족할 때 무엇을 사용해야 하는지 다룹니다.
9. HTTPie 및 xh: 손으로 읽을 수 있는 요청
HTTPie는 터미널 요청을 읽기 쉽게 만들었습니다: 명령어는 http, JSON 필드는 key=value 쌍이며, 응답은 색상화되고 형식화되어 돌아옵니다. xh는 동일한 구문을 Rust로 단일 정적 바이너리로 재구현하여 더 빠른 시작과 해당 curl 명령을 출력하는 --curl 플래그를 제공합니다.
http POST api.example.com/users name=acme plan=pro # HTTPie
xh POST api.example.com/users name=acme plan=pro # 동일한 구문, 하나의 바이너리
가장 적합한 경우: 다른 곳에서 실제 테스트를 구축하는 동안 API를 수동으로 탐색할 때. 솔직한 한계: 둘 다 클라이언트이지 러너가 아닙니다. HTTPie는 Python 런타임을 사용하며, xh는 더 적은 기능 세트를 속도와 교환합니다. 둘 다 응답에 대한 어설션을 수행하지 않습니다.
10. k6: 부하가 문제일 때
k6는 다른 질문에 답합니다: "이 응답이 올바른가"가 아니라 "트래픽 하에서 버틸 수 있는가"입니다. Grafana의 단일 Go 바이너리로, JavaScript로 스크립팅되며, 부하 테스트를 통과/실패 게이트로 바꾸는 임계값을 가지고 있습니다. 임계값을 위반하면 k6는 0이 아닌 값으로 종료되며, CI는 이를 실패로 간주합니다.
brew install k6
k6 run load.js # 스크립트에서 정의된 vus, duration, 및 thresholds
가장 적합한 경우: 기능 테스트와 동일한 저장소에 존재하고 노트북 또는 파이프라인에서 실행되는 성능 검사. 솔직한 한계: 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가 내일 바로 실행할 수 있습니다. 저장소에 검토 가능한 텍스트로 테스트를 원한다면 Hurl과 Bruno CLI가 가장 강력한 선택입니다. 견고한 OpenAPI 스키마가 있다면 Schemathesis를 추가하여 예상하지 못한 버그를 찾도록 하세요. 수동 계층을 위해 curl과 xh를 유지하고, 정확성에서 용량으로 질문이 바뀌는 날 k6를 도입하세요.
시나리오를 시각적 편집기에서 작성하고 다른 모든 곳에서 실행하고 싶다면 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 파이프라인에서 실행되는 것은 무엇인가요? 모든 러너들: apidog run, hurl --test, newman run, postman collection run, bru run, schemathesis run, stepci run, k6 run 모두 실패 시 0이 아닌 값으로 종료합니다. 작동하는 파이프라인 예제를 보려면 GitHub Actions에서 Apidog CLI 테스트를 실행하는 방법을 참조하세요.
이들 중 부하 테스트를 처리하는 것이 있나요? k6가 여기서는 부하 전문 도구이며, 임계값을 통과/실패 게이트로 사용합니다. 다른 도구들은 정확성을 확인하며 용량을 확인하지 않으므로, 많은 팀이 기능 러너와 k6를 함께 사용합니다.
이 도구들을 사용하려면 OpenAPI 사양이 필요한가요? Schemathesis만 스키마에서 테스트를 생성하므로 필요합니다. 다른 모든 곳에서는 사양이 게이트 역할을 하기보다는 도움이 됩니다: Apidog은 OpenAPI 3.x, Swagger 2.0 및 Postman 컬렉션을 가져오고, Step CI는 스키마에 대해 응답을 검증할 수 있습니다.
이 열 가지 도구의 공통적인 패턴은 동일합니다: 작성은 편안함을 원하고, 실행은 셸을 원합니다. 테스트를 작성할 곳을 선택한 다음, 러너가 파이프라인에 종료 코드를 전달하는지 확인하세요. 한 플랫폼에서 두 가지 모두를 원한다면 Apidog을 다운로드하고, 편집기에서 시나리오를 하나 만들고, 해당 apidog run 명령어를 CI에 넣어 루프를 완성하세요.