Hoppscotch CLI는 터미널에서 API 컬렉션을 실행할 수 있는 무료 오픈 소스 방법입니다. 웹 또는 데스크톱에서 Hoppscotch를 이미 사용하고 있다면, hopp test를 통해 비용을 지불하지 않고도 동일한 요청을 CI 파이프라인에 푸시할 수 있습니다. 이는 진정한 강점이며, 이 글은 이 점을 외면하지 않을 것입니다.
하지만 Hoppscotch CLI는 의도적으로 기능이 제한적입니다. 컬렉션을 실행하고 결과를 보고할 뿐입니다. API를 설계하거나, 모의 테스트하거나, 문서화하거나, 코드로 관리하지 않습니다. 그래서 많은 팀이 JSON 파일 실행 이상의 기능을 수행하는 단일 도구를 원하거나, Node v22 요구 사항과 같은 마찰 지점에 부딪혀 다른 대안을 찾기 시작합니다.
Hoppscotch CLI가 실제로 하는 일
Hoppscotch CLI는 @hoppscotch/cli npm 패키지로 제공됩니다. 전역으로 설치합니다:
npm i -g @hoppscotch/cli
미리 알아두어야 할 점이 하나 있습니다: Node.js v22 이상이 필요합니다. Node 20에 머물러 있다면, CLI v0.26.0을 사용해야 하는데, 이는 다른 작업이 이전 Node 버전을 고정하는 공유 CI 이미지에서는 복잡해질 수 있습니다.
핵심 명령어는 hopp test입니다. 컬렉션 파일(또는 클라우드 컬렉션 ID)을 지정하면 모든 요청을 순서대로 실행합니다:
hopp test ./collection.json -e ./environment.json -d 500
클라우드 또는 자체 호스팅 인스턴스의 경우, ID와 자격 증명을 전달합니다:
hopp test <collection-id> -e <environment-id> --token <access_token> --server <server-url>
사전 요청 스크립트 및 테스트 스크립트(pw.test() 스위트, pw.expect() 케이스)를 실행하고, 응답을 검증하며, 어떠한 어설션이라도 실패하면 0이 아닌 값으로 종료합니다. 또한 JUnit XML을 위한 --reporter-junit <path>와 데이터 기반 실행을 위한 --iteration-count 및 --iteration-data <csv>를 지원합니다. 이는 진정으로 유능한 무료 실행기입니다.
팀이 Hopp Test 대안을 찾는 이유
사람들이 Hoppscotch CLI 대체를 찾는 이유는 보통 이념적인 것이 아니라 실용적인 이유입니다:
- 단지 컬렉션 실행기일 뿐입니다. 설계, 모킹, 문서화는 다른 곳에서 이루어집니다. 결국 여러 도구를 조합하게 됩니다.
- 먼저 JSON을 내보내야 합니다. 스펙과 환경은 내보낸 컬렉션/환경 파일(또는 클라우드 ID)로 들어옵니다. CLI 자체에는 스펙 린팅이나 설계 레이어가 없습니다.
- Node v22 하한선. 많은 빌드 이미지의 기본값보다 최신 버전이라 추가적인 버전 관리가 필요합니다.
- 코드형 스펙 워크플로우가 없습니다. CLI에서 엔드포인트, 스키마 또는 브랜치를 관리할 수 없습니다. CLI는 API를 정의한 곳의 하위 단계에 있습니다.
이러한 이유가 Hoppscotch를 나쁘게 만드는 것은 아닙니다. 단지 집중된 도구일 뿐입니다. 더 넓은 범위의 기능을 원한다면, 시간을 들일 가치가 있는 대안들이 있습니다.
1. Apidog CLI (최고의 올인원 대안)
Apidog는 설계, 디버깅, 모킹, 문서화 및 테스트를 포괄하는 올인원 API 플랫폼입니다. Apidog CLI는 테스트 및 리소스 관리 측면을 터미널 및 CI/CD로 가져오며, 이것이 독립형 컬렉션 실행기에 대한 강력한 대안이 되는 이유입니다.
apidog run을 사용하여 명령줄에서 테스트 시나리오와 컬렉션을 실행합니다. -d(CSV 또는 JSON 데이터셋)를 통한 데이터 기반 테스트, -e를 통한 환경, CLI, HTML 및 JSON 형식의 리포터, 그리고 --upload-report를 통한 클라우드 테스트 보고서를 지원합니다. 테스트 실행 외에도, CLI는 OpenAPI를 가져오고 API 리소스, 엔드포인트, 스키마, 환경, 브랜치 및 병합 요청을 코드로 관리할 수 있습니다. 따라서 API 정의와 테스트가 별도로 내보내고 가져올 필요 없이 동일한 시스템에 존재합니다.
범위를 정확히 말하자면: Apidog는 가져올 때 스펙의 유효성을 검사하지만, 독립형 OpenAPI 린터 또는 split/join/bundle 명령어를 제공하지 않습니다. 순수한 CI 내 스펙 린팅이 목표라면 inso(아래 참조)가 더 적합합니다. Apidog의 강점은 통합입니다. 한 곳에서 설계, 모의 테스트, 문서화 및 테스트를 수행한 다음, CLI에서 테스트 및 리소스 레이어를 구동합니다.
장점:
- 도구 체인 대신 설계, 모킹, 문서화, 테스트를 위한 하나의 플랫폼
- CSV/JSON 데이터셋을 사용한 데이터 기반 실행
- CLI, HTML 및 JSON 리포터, 업로드 가능한 클라우드 보고서
- 코드형 리소스: CLI에서 엔드포인트, 스키마, 브랜치 및 병합 요청 관리
- OpenAPI 직접 가져오기
단점:
- 독립형 스펙 린터 명령어가 없습니다 (Spectral 스타일 린팅을 위해 inso 또는 Redocly 사용)
- 하나의 컬렉션만 실행하는 경우 전체 플랫폼은 필요 이상일 수 있습니다.
두 도구를 직접 비교하려면 Apidog CLI vs Hoppscotch CLI 및 실용적인 Hoppscotch CLI를 Apidog CLI로 마이그레이션하는 방법 워크스루를 참조하세요. 더 넓은 범위의 Apidog CLI 전체 가이드는 설치, 인증 및 전체 명령어 세트를 다룹니다. 사용해 보려면 Apidog를 다운로드하세요.
2. Newman (Postman 실행기)
Newman은 Postman의 공식 명령줄 컬렉션 실행기입니다. 팀이 이미 Postman을 사용하고 있다면, Newman은 가장 저항이 적은 방법입니다: 컬렉션과 환경을 내보낸 다음 CI에서 실행하세요.
newman run collection.json -e env.json -r cli,json
여러 리포터(CLI, JSON, JUnit, 플러그인을 통한 HTML), 반복을 위한 데이터 파일, 파이프라인을 위한 안정적인 종료 코드 계약을 지원합니다.
장점:
- 성숙하고 광범위하게 문서화되어 있으며 거대한 생태계
- 최고 수준의 Postman 호환성
- 유연한 리포터 및 데이터 기반 반복
단점:
- Hoppscotch CLI와 마찬가지로 실행기일 뿐, 설계 또는 문서화 레이어 없음
- Postman 컬렉션 형식 및 스크립팅 모델에 종속됨
- 여전히 JSON을 내보내야 사용 가능
Apidog 접근 방식과의 직접적인 비교는 Apidog CLI vs Newman을 참조하세요.
3. inso (Kong의 Insomnia CLI)
inso는 Kong의 오픈 소스 Insomnia 클라이언트의 명령줄 동반자입니다. Hoppscotch CLI가 하지 않는 일을 합니다: OpenAPI 스펙을 린트합니다. 린팅은 Stoplight OpenAPI 린터인 Spectral에서 실행되므로, CI에서 스펙 품질 게이트가 중요하다면 inso는 진정한 경쟁자입니다.
inso run test "My Test Suite" --env "Staging"
inso lint spec "My API Design"
inso export spec "My API Design" --output output.yaml
inso는 .insomnia 디렉토리(Insomnia의 Git Sync으로 생성됨) 또는 앱 데이터 디렉토리에서 읽어 들이고, 스위트와 스펙을 이름으로 참조합니다. brew install inso 또는 docker pull kong/inso:latest로 설치할 수 있습니다.
장점:
- Spectral을 통한 실제 OpenAPI 린팅
- 터미널에서 테스트 및 컬렉션 실행, 스펙 내보내기
- Brew 및 Docker 설치 경로
단점:
- 스크립트에서 취약할 수 있는 이름으로 리소스 참조
- Insomnia 8은 2023년에 필수 클라우드/로그인 계정을 도입하여 반발을 샀으며, 이 변경 사항으로 인한 마이그레이션 및 데이터 손실 사고가 있었습니다. 새로 생태계를 도입한다면 알아둘 가치가 있습니다.
Insomnia를 더 광범위하게 평가하고 있다면, Apidog vs Insomnia 및 최고의 Insomnia 앱 대안이 다음 읽을거리로 좋습니다. 또한 Apidog CLI vs inso (Insomnia CLI) 비교 자료도 있습니다.
4. Step CI (YAML로 오픈 소스 API 테스트)
Step CI는 스크립트 기반 JS 대신 선언적 YAML로 테스트를 정의하는 오픈 소스 API 품질 도구입니다. 요청과 예상 응답을 설명하면, 이를 확인합니다. REST, GraphQL 및 gRPC를 지원하며, 이는 대부분의 컬렉션 실행기보다 넓은 프로토콜 범위입니다.
npx stepci run workflow.yml
장점:
- 선언적 YAML, 버전 관리에서 읽기 쉬움
- 다중 프로토콜 (REST, GraphQL, gRPC)
- GUI 의존성 없음, 구성은 전적으로 리포지토리에 저장
단점:
- 작은 커뮤니티 및 생태계
- 설계, 모킹 또는 문서화 계층 없음
- 테스트를 기록하는 대신 YAML로 수동으로 작성해야 함
Step CI는 git-native하고 사람이 읽기 쉬운 테스트를 원하고 UI가 전혀 필요하지 않은 경우에 적합합니다.
5. Hurl (일반 텍스트 HTTP 테스트)
Hurl은 간단한 일반 텍스트 형식으로 작성된 HTTP 요청을 실행하고 응답을 검증합니다. libcurl을 기반으로 구축되었으며, 빠르고 깨끗한 출력을 생성합니다. 스크립트나 JSON 컬렉션 없이, pull request에서 diff할 수 있는 .hurl 파일만 있으면 됩니다.
GET https://api.example.com/health
HTTP 200
[Asserts]
jsonpath "$.status" == "up"
다음과 같이 실행합니다:
hurl --test health.hurl
장점:
- 매우 가볍고, 단일 바이너리이며 빠름
- 문서처럼 읽히는 일반 텍스트 파일
- CI에서 스모크 테스트 및 헬스 체크에 매우 적합
단점:
- 완전한 테스트 프레임워크보다 낮은 수준
- 설계, 모킹 또는 문서화 기능 없음
- 복잡하고 연쇄적이며 데이터 기반 시나리오에는 덜 편리함
Hurl은 빠르고 읽기 쉬운 계약 및 스모크 체크에 탁월합니다. 플랫폼이 되려고 하지 않습니다.
비교표
| 도구 | 라이선스 | 핵심 기능 | 데이터 기반 | Spec 린팅 | 설계/모킹/문서화 | 보고서 형식 |
|---|---|---|---|---|---|---|
| Apidog CLI | 상업용 (무료 티어) | 풀 플랫폼 + CLI 테스트 | 예 (CSV/JSON) | 아니요 (가져올 때 유효성 검사) | 예 | CLI, HTML, JSON, 클라우드 |
| Hoppscotch CLI | 오픈 소스 | 컬렉션 실행기 | 예 (CSV 반복) | 아니요 | 아니요 | CLI, JUnit |
| Newman | 오픈 소스 | Postman 실행기 | 예 (데이터 파일) | 아니요 | 아니요 | CLI, JSON, JUnit, HTML |
| inso | 오픈 소스 | Insomnia 실행기 + 린터 | 제한적 | 예 (Spectral) | 부분적 (설계 문서) | CLI, JUnit |
| Step CI | 오픈 소스 | YAML API 테스트 | 예 | 아니요 | 아니요 | CLI, JUnit |
| Hurl | 오픈 소스 | 일반 텍스트 HTTP 테스트 | 템플릿을 통해 | 아니요 | 아니요 | CLI, JUnit, HTML |
선택 방법
- 설계부터 테스트까지 하나의 도구를 원한다면: Apidog CLI. JSON 내보내기 후 실행하는 번거로움을 없애고 API 리소스와 테스트를 동일 시스템에 유지합니다.
- 팀이 이미 Postman을 사용한다면: Newman. 전환 비용이 가장 적습니다.
- CI에서 OpenAPI 린팅이 필요하다면: Spectral을 사용하는 inso.
- git-native하고 선언적인 테스트를 원한다면: Step CI (YAML) 또는 Hurl (일반 텍스트).
- 무료 오픈 소스 실행기에 만족하고 Node 22 문제만 해결하고 싶다면: Newman, Step CI, Hurl은 해당 요구 사항을 공유하지 않으므로 위 도구 중 어느 것이든 좋습니다.
단순한 불만 사항이 아니라 컬렉션 실행기의 한계 때문에 떠나는 것이 주된 이유라면, 통합된 경로를 먼저 살펴보는 것이 좋습니다. 테스트 측면이 실제 파이프라인에 어떻게 적용되는지는 Apidog CLI vs Postman CLI 및 Apidog CLI CI/CD 파이프라인을 참조하고, 리포터 옵션은 Apidog CLI 테스트 보고서를 참조하세요.
자주 묻는 질문
Hoppscotch CLI는 무료인가요? 예. @hoppscotch/cli는 오픈 소스이며 무료로 사용할 수 있습니다. 컬렉션을 실행하고 테스트 스크립트를 실행하며 JUnit 보고서를 출력합니다. 여기에 제시된 대안들은 Hoppscotch가 비싸서가 아니라, 실행기 이상의 것을 원하기 때문입니다.
Node v22를 원하지 않는 경우 Hoppscotch CLI의 가장 간단한 대안은 무엇인가요? Hurl은 Node 의존성이 전혀 없는 단일 바이너리입니다. inso는 Homebrew 또는 Docker를 통해 설치됩니다. Step CI는 npx를 통해 실행되지만, 현재 Hoppscotch CLI처럼 Node 22에 고정되어 있지는 않습니다.
기존 Hoppscotch 컬렉션을 다른 도구로 옮길 수 있나요? 예. 대부분의 도구는 내보낸 컬렉션이나 OpenAPI를 받아들입니다. 통합 경로의 경우, Hoppscotch CLI를 Apidog CLI로 마이그레이션하는 방법 가이드가 스위트 가져오기 및 재실행 방법을 안내합니다.
Apidog CLI는 inso처럼 OpenAPI 스펙을 린트하나요? 아니요. Apidog는 가져올 때 스펙의 유효성을 검사하지만, 독립형 린터 명령어는 없습니다. CI에서 Spectral 스타일의 스타일 가이드 적용이 필수 요구 사항이라면, Apidog를 inso와 함께 사용하거나 Apidog CLI vs Redocly CLI를 통해 린팅에 특화된 옵션을 비교해 보세요.
CI 파이프라인에 가장 적합한 대안은 무엇인가요? 모든 도구는 실패 시 0이 아닌 종료 코드를 반환하므로 CI에서 모두 작동합니다. 결정 요인은 필요한 다른 기능입니다: 순수한 실행은 Newman 또는 Hurl이 유리하고, 설계와 테스트를 위한 단일 소스는 Apidog CLI가 유리하며, 스펙 게이트는 inso가 유리합니다.
Hoppscotch CLI는 자신의 한 가지 작업을 잘 수행합니다. 그 한 가지 작업만 필요하다면 계속 사용하세요. 실행기들을 연결하는 대신 설계, 모킹, 문서화, 테스트를 단일 워크플로우로 통합하고 싶다면, 통합 플랫폼이 적절한 선택입니다. Apidog CLI 전체 가이드를 시작으로, Apidog를 다운로드하여 첫 번째 시나리오를 실행해 보세요.