Apidog CLI 대 Postman CLI 비교: 최적의 CI/CD 테스트 실행기

노트북에서 실행을 클릭하면 API 테스트가 통과합니다. 하지만 그것으로는 아무것도 증명되지 않습니다. 중요한 테스트는 사람이 아무것도 클릭하지 않은 채 모든 풀 리퀘스트, 모든 병합, 그리고 모든 야간 빌드에서 실행되는 테스트입니다. 테스트를 이러한 루프에 통합하는 작업은 명령줄 러너의 몫입니다. 명령줄 러너는 이미 작성한 테스트를 가져와 파이프라인 내에서 헤드리스 방식으로 실행하고, CI가 읽을 수 있는 상태 코드로 종료하며, 빌드 대시보드에 표시되는 보고서를 작성합니다.

팀이 이 기능을 연동할 때마다 두 가지 러너가 반복해서 언급됩니다: Postman CLI와 Apidog CLI입니다. 이들은 서로 다른 시작점에서 동일한 목표를 지향합니다. Postman CLI는 Postman에서 구축한 컬렉션을 실행합니다. Apidog CLI는 Apidog에서 구축한 시각적 테스트 시나리오를 실행합니다. 두 러너 모두 한 단계로 설치할 수 있고, GitHub Actions, GitLab CI 및 Jenkins에 연결할 수 있으며, 테스트가 실패하면 빌드를 실패(빨간색)로 만듭니다. 진정한 차이점은 실행 명령 상위에 있습니다: 테스트를 작성하는 방법, CI에서 인증하는 방법, 그리고 테스트 정의가 실제로 어디에 저장되는지입니다.

💡

이것은 두 도구의 명령 수준 비교입니다. 허수아비 같은 비교는 없습니다. Postman CLI는 여러 가지 작업을 잘 수행하며, 파이프라인에 통합하기 전에 각 러너가 정확히 어디에 적합한지 알 수 있을 것입니다. Apidog가 처음이라면, Apidog는 설계, 디버깅, 테스트, 모킹, 문서화를 하나의 작업 공간에서 모두 다루는 올인원 API 플랫폼이며, CLI는 테스트를 자동화로 가져가는 핵심 요소입니다.

button

TL;DR

Postman CLI (바이너리 `postman`)는 Postman 작업 공간에 저장된 컬렉션을 실행합니다. Newman을 기반으로 하며, Postman의 서명 및 지원을 받으며, Postman API 키로 인증합니다. 로그인하면 실행 결과를 Postman 클라우드로 자동으로 다시 보냅니다.
Apidog CLI (`apidog-cli`, 바이너리 `apidog`)는 Apidog에서 시각적으로 설계한 테스트 시나리오를 실행합니다. 액세스 토큰과 함께 ID로 시나리오를 지정하면, GUI 없이 해당 시나리오를 헤드리스 방식으로 실행합니다.
두 러너 모두 JUnit, JSON, HTML, 터미널 보고서를 생성합니다. 둘 다 테스트 실패 시 빌드를 실패 처리합니다. 어느 경우든 JUnit XML은 CI 대시보드에 연결되는 형식입니다.
테스트가 이미 Postman 컬렉션에 있고 팀이 보고 및 기록을 위해 Postman 클라우드를 사용하고 있다면 Postman CLI를 선택하세요.
시각적 시나리오 작성, 요청 체이닝, 환경 관리, 그리고 단일 정보원에서 데이터 기반 실행을 원하고, 보고서가 로컬에 유지될지 클라우드로 전송될지에 대한 완전한 제어권을 가지고 싶다면 Apidog CLI를 선택하세요.

진정한 문제: 존재하지만 결코 실행되지 않는 테스트

수동으로 실행하는 테스트는 썩어버리는 테스트입니다. 누군가 작성했고, 한 번 통과한 다음, API가 변경되는 동안 아무도 손대지 않았습니다. 3개월 후 테스트는 잘못되었고 아무도 눈치채지 못했습니다. 왜냐하면 아무도 실행하지 않았기 때문입니다. 해결책은 더 많은 테스트를 작성하는 것이 아닙니다. 가지고 있는 테스트를 모든 변경 사항에 대해 자동으로 실행하도록 만들고, 파이프라인이 조치할 수 있는 합격 또는 불합격 신호를 제공하는 것입니다.

CLI 러너는 이러한 격차를 해소하는 도구입니다. CI에서 제 역할을 하려면 세 가지를 수행해야 합니다. CI 러너에는 화면이 없으므로 GUI 없이 실행되어야 합니다. 무언가 실패하면 0이 아닌 값으로 종료되어야 빌드가 실패(빨간색)로 표시되고 잘못된 병합이 차단됩니다. 그리고 사람이 읽을 수 있는 보고서를 작성해야 검토자가 로컬에서 아무것도 다시 실행하지 않고도 무엇이 문제인지 확인할 수 있습니다. Postman CLI와 Apidog CLI는 모두 이 기준을 깔끔하게 통과합니다. 이들이 갈라지는 지점은 `run` 이전에 발생하는 모든 것입니다: 테스트가 어떻게 작성되었는지, 그리고 CI가 테스트를 찾을 때 테스트가 어디에 있는지입니다.

자동화된 테스트를 처음부터 설정하는 경우, CI/CD에서 API 테스트 자동화에 대한 더 넓은 패턴을 이 글과 함께 읽어볼 가치가 있습니다. 여기서는 두 러너에 초점을 맞춥니다.

Postman CLI의 장점

먼저, 많은 사람들을 혼란스럽게 하는 분명한 점이 있습니다: Postman CLI는 Newman이 아닙니다. Newman은 커뮤니티에서 수년간 사용해 온 오래된 오픈 소스 npm 기반 러너입니다. Postman CLI는 Newman의 기반 위에 구축된 최신 도구이지만, Postman 회사에 의해 서명되고 공식적으로 지원됩니다. Newman을 사용해왔다면 이 둘은 상호 교환될 수 없으며, 그 차이는 CI에서 중요합니다. Postman 측 옵션 두 가지 중에서 결정해야 한다면, Postman CLI와 Newman 비교에서 정확한 차이점을 설명했습니다.

Postman CLI의 가장 큰 강점은 팀이 이미 익숙한 환경 내에 머무른다는 것입니다. 컬렉션, 환경, 공유 변수가 이미 Postman 작업 공간에 있다면, CLI는 거의 변환 없이 이들을 실행합니다. 아무것도 다시 구축할 필요가 없습니다. 인증하고, 컬렉션 이름을 지정하면, 앱이 하던 것과 똑같이 요청과 테스트를 실행합니다.

설치는 단일 명령어로 이루어집니다. macOS 및 Linux에서는 공식 설치 스크립트를 실행합니다:

curl -o- "https://dl-cli.pstmn.io/install/unix.sh" | sh

Windows에서는 서명된 PowerShell 설치 프로그램을 사용하며, 개발 종속성으로 고정하고 싶다면 npm 패키지도 있습니다:

npm install -g postman-cli

바이너리는 `postman`입니다. CI에서는 Postman API 키로 인증하는데, 이는 Postman이 파이프라인에 권장하는 방식입니다:

postman login --with-api-key $POSTMAN_API_KEY

그런 다음 ID로 컬렉션을 실행하거나, 내보냈다면 로컬 파일 경로로 실행합니다:

postman collection run $POSTMAN_COLLECTION_ID -e $POSTMAN_ENV_ID

Postman CLI가 많은 충성도를 얻는 부분은 실행 후에 일어나는 일입니다. 로그인하면 실행 결과가 Postman 클라우드로 바로 전송되어 작업 공간에 컬렉션과 함께 표시됩니다. 테스트 기록, 실행 비교, 팀에 보이는 대시보드가 모두 추가적인 작업 없이 제공됩니다. 이미 Postman 환경에서 작업하는 팀에게 이 왕복은 진정으로 유용하며, 머무를 만한 합당한 이유가 됩니다.

Apidog CLI의 장점

Apidog는 동일한 파이프라인에 다른 경로를 제공합니다. Apidog 앱 내에서 시각적으로 테스트를 구축합니다: 여러 요청을 하나의 테스트 시나리오로 연결하고, 각 응답에 어설션을 추가하고, 한 응답에서 값을 추출하여 다음 요청에 공급하고, 데이터 파일을 통해 전체 시나리오를 반복합니다. CLI는 이러한 시나리오를 위한 헤드리스 실행기입니다. 자체 테스트 형식을 가지고 있지 않습니다. Apidog 프로젝트에 접근하여 ID로 지정한 시나리오를 찾아 앱이 하던 것과 똑같이 실행한 다음 결과를 보고합니다.

그 이점은 아무도 동일한 테스트의 두 가지 복사본을 유지 관리하지 않는다는 것입니다. 시각적 편집기에서 구축한 시나리오가 CI에서 실행되는 테스트입니다. 작동하는 테스트를 스크립트로 다시 표현한 다음 스크립트를 디버깅하는 단계가 없습니다. 빠른 작성 루프와 자동화 루프는 단일 정보원을 공유합니다. 로그인 후 생성, 읽기, 삭제와 같은 다단계 흐름의 경우, 시각적 체이닝은 직접 손으로 작성해야 할 많은 연결 코드를 절약해 줍니다. 이러한 흐름을 구축하는 메커니즘은 API 테스트 자동화를 위한 테스트 시나리오 가이드에 설명되어 있습니다.

설치는 하나의 npm 명령어로 이루어집니다:

npm install -g apidog-cli

바이너리는 `apidog`입니다. 일반적인 실행은 ID로 시나리오를 지정하고, 환경을 선택하고, 반복 횟수를 설정하며, 액세스 토큰으로 인증합니다:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r html,junit

이러한 ID를 수동으로 입력할 필요가 없습니다. Apidog에서 테스트 시나리오를 열고, CI/CD 탭으로 전환하여 액세스 토큰을 생성하면, Apidog가 시나리오 ID와 환경 ID가 이미 채워진 전체 명령을 자동으로 생성해 줍니다. 이를 한 번 복사하여 토큰을 CI 비밀로 옮긴 다음, 워크플로우에서 `$APIDOG_ACCESS_TOKEN`으로 참조하면 됩니다.

토큰 및 ID 모델은 Postman CLI와 가장 분명하게 구분되는 지점입니다. Apidog는 CLI가 네트워크를 통해 가져오는 프로젝트에 저장된 테스트를 토큰으로 인증하여 실행합니다. 보고를 위한 별도의 클라우드 옵트인도 없습니다. 로컬 아티팩트용으로 `--out-dir`을 선택하고, Apidog 클라우드로 개요를 푸시하고 싶을 때만 `--upload-report`를 추가합니다. 보고서는 지정한 위치에 유지됩니다.

비교

차원	Postman CLI (`postman`)	Apidog CLI (`apidog`)
패키지 / 설치	설치 스크립트, 서명된 설치 프로그램, 또는 `npm i -g postman-cli`	`npm i -g apidog-cli`
실행 명령어	`postman collection run <id\|file>`	`apidog run -t <scenarioId>`
테스트 소스	Postman 작업 공간의 컬렉션 (또는 내보낸 파일)	Apidog 프로젝트의 테스트 시나리오, ID로 가져옴
작성	컬렉션 편집기 및 Postman 앱	Apidog 앱의 시각적 시나리오 빌더
CI에서 인증	Postman API 키 (`postman login --with-api-key`)	액세스 토큰 (`--access-token`)
실행 대상 선택	컬렉션 ID 또는 파일 경로	`-t` 시나리오, `-f` 폴더, `--test-suite`
환경	`-e, --environment`	`-e, --environment <environmentId>`
데이터 기반	`-d, --iteration-data` (JSON 또는 CSV)	`-d, --iteration-data` (JSON 또는 CSV)
반복	`-n, --iteration-count`	`-n, --iteration-count`
리포터	`cli`, `json`, `junit`, `html`	`cli`, `html`, `json`, `junit`
즉시 실패	`--bail`	`--on-error end` (기본값은 첫 번째 실패에서 중단)
클라우드 보고	로그인 시 자동으로 결과 전송	`--upload-report`를 통해 선택
기반	Newman	Apidog 자체 엔진

이 표에서 두 가지 사항이 두드러집니다. 첫째, 두 러너 모두 CI의 필수 요소를 거의 동일한 형태로 다룹니다: 환경 선택, 데이터 기반 반복, 중요한 네 가지 보고서 형식, 그리고 실패 시 0이 아닌 종료 코드입니다. 잘못된 병합 시 빌드를 실패(빨간색)로 만드는 러너만 필요하다면, 둘 중 어느 것이든 역할을 수행합니다. 둘째, 진정한 차이점은 테스트가 어디에 저장되고 어떻게 작성되었는지에 있습니다. Postman CLI는 Postman 작업 공간에 있는 컬렉션을 실행합니다. Apidog CLI는 Apidog 프로젝트에 있는 시각적 시나리오를 실행합니다.

리포터 및 종료 코드: CI가 실제로 읽는 부분

러너는 두 가지 동작을 통해 파이프라인에서 그 가치를 증명합니다: 작성하는 보고서와 반환하는 종료 코드입니다. 이 두 가지가 올바르면 나머지는 모두 연결 작업에 불과합니다.

Postman CLI는 쉼표로 구분된 리포터 목록을 받으며, 로그인 시 결과를 Postman 클라우드로도 전송합니다:

postman collection run $POSTMAN_COLLECTION_ID \
  -e $POSTMAN_ENV_ID \
  --reporters cli,junit \
  --bail

`junit` 리포터는 CI 대시보드가 합격 또는 불합격 트리로 파싱하는 리포터입니다. `--bail` 플래그는 첫 번째 실패한 요청, 테스트 또는 어설션에서 실행을 중지하여 스모크 테스트에서 빠른 피드백을 유지합니다. `--bail`을 제거하면 모든 것을 실행한 다음 모든 실패를 한꺼번에 보고합니다. CLI는 어떤 실패든 0이 아닌 값으로 종료되므로 빌드가 자동으로 실패(빨간색)로 표시됩니다.

Apidog CLI는 동일한 `-r` 리포터 아이디어를 사용하며 모든 것을 하나의 출력 디렉토리에 작성합니다:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 \
  -r html,junit --out-dir ./apidog-reports

`--on-error` 플래그는 시나리오 중간 동작을 조절합니다: `end`는 첫 번째 실패에서 중지하며 기본값입니다. `continue`는 모든 단계를 실행하여 하나의 보고서에 모든 실패를 수집합니다. `ignore`는 알려진 불안정한 단계를 건너뛰어 실행을 방해하지 않습니다. 어느 경우든 무언가 실패하면 프로세스는 0이 아닌 값으로 종료되며, JUnit XML은 `./apidog-reports`에 저장되어 대시보드가 가져갈 수 있도록 준비됩니다.

실질적인 결과: 둘 다 JUnit XML을 작성하고, 둘 다 빌드를 올바르게 실패 처리하며, 둘 다 나중에 열어볼 수 있는 HTML 보고서를 보관합니다. 보고의 차이점은 클라우드 왕복입니다. Postman은 인증 시 기본적으로 결과를 클라우드로 푸시합니다. Apidog는 업로드를 요청하지 않는 한 보고서를 로컬에 유지합니다. 추상적으로 어느 쪽이 더 좋다고 할 수는 없습니다. 하나는 호스팅된 기록을 생각 없이 원하는 팀에 적합하고, 다른 하나는 러너에서 무엇을 보낼지 정확히 결정하고 싶은 팀에 적합합니다.

각 러너를 GitHub Actions에 연동하기

GitHub Actions 작업의 형태는 둘 다 동일합니다: 레포를 체크아웃하고, Node를 설정하고, CLI를 설치하고, 테스트를 실행하며, 실패한 종료 코드는 병합을 차단합니다. 비밀은 워크플로우 파일이 아닌 저장소 설정에 저장해야 합니다.

다음은 Postman CLI 버전입니다:

- name: Run API tests (Postman CLI)
  run: |
    curl -o- "https://dl-cli.pstmn.io/install/unix.sh" | sh
    postman login --with-api-key ${{ secrets.POSTMAN_API_KEY }}
    postman collection run $POSTMAN_COLLECTION_ID -e $POSTMAN_ENV_ID --reporters cli,junit --bail

그리고 Apidog CLI 버전입니다:

- name: Run API tests (Apidog CLI)
  run: |
    npm install -g apidog-cli
    apidog run --access-token ${{ secrets.APIDOG_ACCESS_TOKEN }} -t 605067 -e 1629989 -r cli,junit

둘 다 간결하고 읽기 쉬우며, 파이프라인이 중요하게 생각하는 수준에서는 동일하게 작동합니다: 통과된 실행은 0으로 종료되어 병합이 진행되고, 실패한 실행은 0이 아닌 값으로 종료되어 병합이 차단됩니다. GitHub 워크플로우에서 API 테스트 실행에 대한 더 심층적인 안내를 원한다면, GitHub Actions를 이용한 API 테스트 자동화가 단계별로 설명합니다. Jenkins 사용자를 위해 동일한 아이디어가 Jenkins와 Apidog 자동화 테스트 통합에 설명되어 있습니다.

그렇다면 CI에서 누가 승리할까요?

단일한 승자는 없습니다. 올바른 답변은 테스트가 이미 어디에 저장되어 있고 팀이 테스트를 어떻게 작성하고 저장하고 싶은지에 따라 달라지기 때문입니다.

Apidog CLI는 호스팅된 클라우드 기록보다 시각적 작성과 단일 정보원을 더 중요하게 생각할 때 승리합니다. 시각적 편집기에서 요청 체이닝과 어설션이 처리된 시나리오를 한 번 구축하면, 동일한 시나리오가 참조로 CI에서 실행됩니다. 보고서를 로컬에 유지할지 업로드할지 결정합니다. 또한 Apidog는 동일한 작업 공간에서 설계, 모킹, 문서화를 모두 다루므로, 테스트 시나리오는 확인하는 API 계약 옆에 위치하여 테스트와 사양이 멀어지지 않도록 합니다. 플랫폼을 더 넓게 고려하는 팀은 전체 Apidog vs Postman 비교를 읽어볼 수 있습니다.

Postman CLI는 팀이 이미 Postman을 사용하고 있을 때 승리합니다. 컬렉션이 거기에 있고, 환경이 거기에 있으며, 아무것도 설정하지 않고 Postman 클라우드에 실행 기록을 원합니다. 매 실행마다 클라우드 왕복은 해당 설정에 있어 진정한 편리함이며, 이 도구는 공식적으로 서명되고 지원됩니다. 팀이 이러한 경우라면, 러너를 바꾸는 것은 거의 이득이 없습니다.

Postman 클라우드 모델에 갇혀 있다고 느끼거나, 테스트를 한 번 작성하여 모든 곳에서 실행하고 싶다면, 답은 명확합니다. Apidog를 다운로드하고, 시나리오를 구축하고, CI/CD 탭을 열어 생성된 `apidog run` 명령어를 파이프라인에 복사하세요. 이것이 전체 설정입니다.

button

FAQ

Postman CLI는 Newman과 동일한가요? 아닙니다. Newman은 오래된 오픈 소스 npm 러너입니다. Postman CLI는 Newman의 기반 위에 구축된 최신 도구로, Postman에 의해 서명되고 지원되며, Postman 클라우드에 대한 내장 보고 기능을 갖추고 있습니다. Postman 측에서 둘 중 하나를 선택해야 한다면, Postman CLI와 Newman 비교에서 차이점을 자세히 설명합니다.
CI에서 두 CLI 중 하나에 계정 또는 토큰이 필요한가요? 네, 둘 다 필요하지만 형식은 다릅니다. Postman CLI는 `postman login --with-api-key`를 통해 Postman API 키로 인증합니다. Apidog CLI는 `--access-token`으로 전달된 액세스 토큰으로 인증합니다. 둘 중 하나를 CI 비밀로 저장하고, 절대로 워크플로우 파일에 저장하지 마세요.
두 러너 모두 테스트 실패 시 빌드를 실패 처리하나요? 네. 둘 다 실패한 테스트 또는 어설션에 대해 0이 아닌 상태 코드로 종료하는데, 이것이 CI 시스템에 빌드를 실패(빨간색)로 표시하고 병합을 차단하도록 지시하는 것입니다. Postman CLI는 `--bail`을 사용하여 첫 번째 실패에서 중지하고, Apidog CLI는 기본값인 `--on-error end`를 사용합니다.
보고서를 클라우드로 보내지 않고 로컬에 유지할 수 있나요? Apidog CLI는 기본적으로 보고서를 로컬에 유지하고 `--out-dir`에 작성합니다. `--upload-report`를 통해서만 업로드할 수 있습니다. Postman CLI도 로컬 리포터를 작성하지만, 로그인 시 실행 결과를 Postman 클라우드로 자동으로 보냅니다.
내 시나리오에 대한 정확한 Apidog 실행 명령어를 어떻게 얻나요? Apidog에서 테스트 시나리오를 열고, CI/CD 탭으로 전환하여 액세스 토큰을 생성하면, Apidog가 시나리오 ID와 환경 ID가 이미 채워진 전체 `apidog run` 명령어를 자동으로 생성해 줍니다. 이를 복사하여 토큰을 CI 비밀로 옮기면 됩니다. 사용 가능한 모든 플래그를 보려면 `apidog run --help`를 실행하세요.
Postman 클라우드에서 마이그레이션하는 팀은 어떤 것을 선택해야 할까요? 클라우드 중심 모델이나 가격 책정 때문에 떠나는 경우, Apidog CLI가 적합합니다. Apidog CLI는 프로젝트에서 단일 시각적 시나리오를 실행하며 러너에서 무엇을 보낼지 결정할 수 있기 때문입니다. 러너 외에 플랫폼이 어떻게 비교되는지 보려면 Apidog vs Postman 비교를 시작점으로 삼으세요.