최고의 경량 CLI 개발 도구

백엔드 개발자의 하루 대부분은 작고 빠른 반복 작업으로 이루어집니다. 엔드포인트에 요청을 보내고, JSON을 읽고, 수정하고, 반복하는 식이죠. 이를 위해 무거운 GUI를 사용하면 실제 작업을 하는 시간보다 로딩을 기다리는 데 더 많은 시간을 낭비하게 됩니다.

경량 CLI 도구는 이러한 방식을 뒤집습니다. 단일 바이너리 또는 `npx`로 실행 가능한 패키지로 제공되며, 1초도 안 되는 시간에 시작하고, 설정 마법사 없이 한 가지 작업만 수행합니다. 이 도구들을 셸 스크립트 및 CI 작업에 연결하면 방해받지 않고 작업을 진행할 수 있습니다. API 및 백엔드 작업의 경우, 이러한 작은 도구 세트만으로 요청 전송, 응답 파싱, 로컬 포트 노출, 테스트 스위트 실행과 같은 대부분의 반복 작업을 처리할 수 있습니다.

이 가이드에서는 백엔드 개발자의 `PATH`에 추가할 만한 10가지 도구를 선정했습니다. 각 섹션에서는 해당 도구가 작동함을 증명하는 하나의 명령어를 보여줍니다. 핵심은 '발자취(footprint)'입니다. 즉, 빠르게 설치되고, 빠르게 시작하며, 유용하게 사용되기까지 거의 아무것도 요구하지 않는 도구들을 다룹니다. 이 도구들이 어떻게 어우러지는지에 대한 더 큰 그림은 API 개발 가이드에서 문맥을 제공합니다.

button

CLI 도구를 개발용으로 "경량"으로 만드는 요소

경량이라는 것은 도구가 얼마나 많은 기능을 담고 있는지가 아니라, '발자취(footprint)'와 '마찰(friction)'에 관한 것입니다. 도구 세트에 무엇을 포함할지 결정할 때, 다음 네 가지를 고려하세요:

설치 크기와 형태. 단일 정적 바이너리 또는 작은 `npx` 패키지는 런타임과 록 파일을 함께 가져오는 모든 것보다 낫습니다.
시작 속도. 도구는 편집기로 다시 전환하기 전에 실행되어야 합니다. Rust 및 Go 바이너리는 밀리초 단위로 콜드 스타트되는데, 반복적으로 호출할 때 이 점이 중요합니다.
설정 없이 첫 결과. 유용한 기본값으로 제로 설정이 기준입니다. 프로젝트 파일, 계정, 대시보드가 먼저 필요하다면 경량이 아닙니다.
조합 가능성. 표준 입력(stdin)을 읽고, 표준 출력(stdout)에 쓰고, 실제 종료 코드를 설정하며, 다음 도구로 파이프 연결됩니다. 이것이 작은 도구가 크기 이상의 가치를 갖게 하는 이유입니다.

아래 도구들은 대체로 가장 작고 단일 목적의 도구부터 더 완전한 도구 순으로 나열됩니다. curl은 이미 여러분의 머신에 설치되어 있을 것이며, 나머지는 빠르게 설치할 수 있습니다.

curl

curl은 다른 모든 HTTP 도구들이 비교하는 기준점입니다. 거의 모든 머신에 이미 설치되어 있으며, 여러분이 다룰 모든 프로토콜을 지원하고, 시키는 대로 정확히 수행합니다. 엔드포인트가 살아있는지 빠르게 확인하는 데 이보다 빠른 것은 없습니다.

curl -s -X POST https://api.github.com/repos/curl/curl/issues \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"Test issue"}'

`-s`는 진행 표시를 숨겨 응답이 깔끔하게 파이프되도록 합니다. 헤더를 보려면 `-i`를 추가하고, 상태 코드만 출력하려면 `-w '%{http_code}'`를, 4xx 또는 5xx 오류 시 curl이 0이 아닌 종료 코드를 반환하게 하려면 `--fail`을 추가합니다. 이는 CI 검사 내에서 원하는 동작입니다.

가장 적합한 용도: 스크립트 작성, CI 상태 확인, 복사-붙여넣기하여 공유하고 싶은 모든 요청. curl 명령어는 모든 팀원의 머신에서 작동합니다.

솔직한 한계: 플래그 문법이 복잡하고 JSON 본문 처리가 수동적입니다. 빠른 상호작용 요청의 경우, 다음 두 도구가 더 편리합니다.

HTTPie

HTTPie (`http`)는 날카로운 모서리를 다듬고 사람이 수동으로 요청을 입력하도록 만들어진 curl입니다. JSON이 기본이며, 출력은 색상화되고 서식이 지정되며, 플래그를 외우는 대신 간단한 `key=value` 항목으로 요청을 구성합니다.

http POST httpbin.org/post name=apidog role=api-tool active:=true

이는 `{"name": "apidog", "role": "api-tool", "active": true}`라는 JSON 본문을 보냅니다. `=`는 문자열을 설정하고, `:=`는 원시 JSON 값을 설정하며, `header:value`는 헤더를 설정합니다. JSON 덩어리를 인용 부호로 감싸거나 `-H` 및 `-d`를 신경 쓸 필요가 없습니다. 응답은 예쁘게 출력되어 돌아옵니다.

가장 적합한 용도: 가독성이 중요한 대화형 API 탐색.

솔직한 한계: Python 패키지이므로 네이티브 바이너리보다 콜드 스타트가 느리고 머신에 Python이 필요합니다. 시작 속도가 중요하다면 xh를 사용하세요.

xh

xh는 단일 Rust 바이너리로 구현된 HTTPie의 문법입니다. HTTPie의 요청 항목 스타일을 재구현하여 `name=value` 및 `:=`가 동일하게 작동하지만, 런타임 없이 하나의 정적으로 링크된 파일로 제공되며 약 30% 더 빠르게 시작합니다. 또한 HTTP/2 및 HTTP/3을 지원합니다.

xh POST httpbin.org/post name=apidog age:=24

HTTPie와 동일한 사용 편의성, 거의 즉각적인 시작. 의존성이 없는 단일 바이너리이므로 Python을 함께 가져올 필요 없이 슬림한 CI 이미지나 컨테이너에 쉽게 포함될 수 있습니다. GitHub의 xh 프로젝트는 Linux, macOS, Windows용 사전 빌드된 바이너리를 제공합니다.

가장 적합한 용도: HTTPie의 사용감을 좋아하지만, 스크립트와 컨테이너를 위한 네이티브 속도와 제로 의존성 설치를 원하는 개발자.

솔직한 한계: 일반적인 HTTPie 기능을 다루지만, 모든 플러그인을 지원하지는 않습니다. 거의 모든 요청 작업에서 이러한 차이는 나타나지 않습니다.

jq

jq는 다른 모든 HTTP 도구를 더 유용하게 만듭니다. 명령줄에서 JSON을 필터링하고 재구성하는 단일 바이너리이므로, 전체 JSON 덩어리를 직접 살펴보는 대신 API 응답에서 특정 필드 하나만 추출할 수 있습니다.

curl -s https://api.github.com/repos/stedolan/jq | jq '.stargazers_count'

이는 별점 개수만 출력합니다. jq는 `.items[] | .name`이 배열을 매핑하고, `select(.active)`가 필터링하며, `-r`이 인용 부호 없는 원시 출력을 제공하여 셸 변수로 파이프할 수 있도록 하는 완전한 쿼리 언어를 가지고 있습니다. 이는 API 호출과 나머지 스크립트 사이의 접착제 역할을 합니다.

가장 적합한 용도: 스크립트 및 CI에서 JSON 응답에서 필드를 추출하고 변환하는 작업.

솔직한 한계: 쿼리 문법은 학습 곡선이 있으며, 깊게 중첩된 변환은 이해하기 어려울 수 있습니다. 간단한 필드 접근에는 사소한 작업입니다.

gh (GitHub CLI)

gh는 GitHub의 API를 터미널로 가져와, 단 하나의 curl 호출도 작성할 필요 없이 사용할 수 있게 합니다. `gh auth login`을 통해 한 번 인증을 처리한 다음, 풀 리퀘스트, 이슈, 릴리스, 리포지토리를 간단한 명령어로 감싸줍니다. 배포 및 검토 흐름이 GitHub에 있는 백엔드 팀에게는 브라우저 탭을 하나 줄여주는 효과가 있습니다.

gh pr create --title "Add rate limiting" --body "Closes #42" --base main

이는 현재 브랜치에서 PR을 엽니다. `gh pr checks`는 CI를 모니터링하고, `gh run watch`는 워크플로를 실시간으로 추적하며, `gh api`는 래핑된 명령으로 다루지 않는 모든 엔드포인트에 대해 인증된 페이지네이션 클라이언트를 제공합니다.

가장 적합한 용도: GitHub 자체 스크립트 작성: CI에서 PR 열기, 릴리스 생성, 토큰을 수동으로 관리하지 않고 API 쿼리.

솔직한 한계: GitHub 전용이므로 GitLab 또는 Bitbucket 사용자는 이 도구에서 얻을 것이 없습니다.

ngrok

ngrok은 보안 터널을 통해 로컬 포트를 공개 URL로 노출합니다. 웹훅 핸들러를 구축하거나, 외부 네트워크에서 개발 서버에 접속해야 할 때가 있나요? ngrok은 `localhost`를 하나의 명령어로 공유 가능한 링크로 바꿔줍니다. 에이전트는 어디서든 실행되는 의존성 없는 바이너리입니다.

ngrok http 8080

이는 공개 `https://` URL을 로컬 포트 8080으로 포워딩하고 터미널에 출력합니다. 또한 `http://127.0.0.1:4040`에서 트래픽 검사기를 실행하여 들어온 모든 요청을 재생할 수 있는데, 이는 제어할 수 없는 결제 또는 Git 웹훅을 디버깅할 때 시간을 크게 절약해 줍니다.

가장 적합한 용도: 웹훅 개발, 팀원과 진행 중인 작업 공유, 로컬 코드에 대한 타사 콜백 테스트.

솔직한 한계: 무료 등급이 있는 상업 서비스입니다. 무료 플랜은 세션마다 URL을 변경하고 속도 제한을 둡니다. 고정된 이름으로 안정적인 로컬 HTTPS를 원한다면 mkcert를 대신 사용하세요.

mkcert

mkcert는 설정 없이 로컬에서 신뢰할 수 있는 HTTPS 인증서를 만듭니다. Filippo Valsorda가 Go로 작성했으며, 로컬 인증 기관을 생성하고 시스템 신뢰 저장소에 설치하며, 브라우저가 경고 없이 받아들이는 인증서를 발급하는 단일 바이너리입니다. 이를 통해 무서운 빨간 자물쇠 없이 로컬에서 `https://localhost`를 실행할 수 있습니다.

mkcert -install
mkcert localhost 127.0.0.1 myapp.local

첫 번째 줄은 로컬 CA를 한 번 설정합니다. 두 번째 줄은 나열된 이름에 대한 인증서와 키를 발급하며, 개발 서버 또는 리버스 프록시에 바로 사용할 수 있습니다. OpenSSL 명령어나 매번 새로고침할 때마다 클릭해야 하는 자체 서명 인증서가 필요 없습니다. OAuth 리다이렉트, 보안 쿠키 또는 HTTPS에서 다르게 작동하는 모든 것을 테스트하는 것이 훨씬 쉬워집니다.

가장 적합한 용도: 프로덕션과 일치하도록 로컬 개발 환경에서 실제적이고 신뢰할 수 있는 HTTPS를 얻는 것.

솔직한 한계: 개발 전용입니다. mkcert 인증서를 프로덕션에 절대 사용하지 마세요. 그리고 생성된 루트 CA 키를 보호해야 합니다. 이 키는 머신의 모든 이름에 서명할 수 있습니다.

watchexec

watchexec은 파일이 변경될 때마다 명령을 다시 실행합니다. 디렉토리를 감시하고 저장하는 순간 서버를 다시 시작하거나 테스트를 다시 실행하는 단일 Rust 바이너리입니다. 기본적으로 `.gitignore`를 존중하므로 빌드 아티팩트에 대해서는 실행되지 않습니다.

watchexec -e py -r 'pytest tests/'

`-e py`는 Python 파일로 필터링하고, `-r`은 새로운 프로세스를 쌓는 대신 장시간 실행되는 프로세스를 다시 시작합니다. 어떤 명령에도 사용할 수 있습니다: Go 서버의 경우 `watchexec -r 'go run .'`을, JS 스위트의 경우 `watchexec 'npm test'`를 사용합니다. 언어에 구애받지 않으므로, 스택별 감시자 대신 하나의 도구로 모든 프로젝트를 처리할 수 있습니다.

가장 적합한 용도: 프레임워크별 감시 모드 없이 로컬 서버나 테스트 스위트에서 긴밀한 편집-실행 루프를 수행하는 것.

솔직한 한계: 파일을 감시하고 다시 실행할 뿐, 핫 모듈 리로드(hot-module reload)를 수행하거나 프로세스 내 상태를 보존하지는 않습니다.

Docker CLI

Docker CLI는 여기에 있는 도구 중 가장 무겁지만, 그 자리를 차지할 만합니다. 로컬 개발을 위해 실제 Postgres, Redis 또는 전체 의존성이 필요할 때, 한 번의 `docker run` 명령으로 작업이 끝나면 버릴 수 있는 임시 인스턴스를 얻을 수 있습니다. 시스템 수준의 설치도, 남아있는 서비스도 없습니다.

docker run --rm -e POSTGRES_PASSWORD=dev -p 5432:5432 postgres:16

`--rm`은 종료 시 컨테이너를 삭제하고, `-e`는 비밀번호를 설정하며, `-p`는 포트를 호스트에 매핑합니다. 앱은 `localhost:5432`에 연결하고 실행할 때마다 깨끗한 데이터베이스를 얻습니다. `postgres:16`을 `redis:7` 또는 다른 이미지로 바꾸면 패턴은 동일하게 유지됩니다.

가장 적합한 용도: 로컬 개발 및 통합 테스트를 위한 백엔드 서비스를 재현 가능하게, 그리고 머신을 오염시키지 않고 빠르게 구축하는 것.

솔직한 한계: 바이너리 의미에서 경량은 아닙니다. 실행 중인 데몬과 실제 디스크 및 메모리가 필요합니다. 하지만 CLI는 스크립트 작성이 가능하고 터미널 우선이며, 재현 가능한 로컬 인프라를 구축하는 데 이만한 것은 없습니다.

apidog-cli

명령줄에서 API 작업을 하다 보면, 빠진 부분이 실제 API 프로젝트입니다: 엔드포인트, 스키마, 환경, 테스트 시나리오 등이죠. Apidog은 터미널을 해당 프로젝트에 연결하는 경량 CLI인 `apidog-cli`를 제공합니다. 하나의 npm 패키지로 설치되며, 데스크톱 앱을 열지 않고도 리소스를 설계하고, 가져오고, 모킹하고, 테스트할 수 있는 스크립트 가능한 경로를 제공합니다.

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run -t <scenario_id> -e <env_id> -r cli

`apidog run`은 저장된 테스트 시나리오를 특정 환경에 대해 실행하고 터미널에 단계별 결과를 출력합니다. 모든 어설션이 통과하면 0으로 종료하고 실패하면 0이 아닌 값으로 종료하므로, CI 게이트에 바로 통합될 수 있습니다. 테스트 외에도 CLI는 실제 명령 그룹을 다룹니다: 설계용 `endpoint` 및 `schema`, 스펙(OpenAPI, Swagger, Postman)을 가져오고 내보내는 `import` 및 `export`, 모의 예상(mock expectations)을 위한 `mock`, 설정용 `environment` 및 `variables`입니다. 출력은 `agentHints.nextSteps`와 함께 구조화된 JSON 형식이므로 API 개발을 수행하는 AI 코딩 어시스턴트에도 적합합니다. 전체 명령어 참조는 완벽한 Apidog CLI 가이드를 참조하고, Apidog CLI 설치 가이드는 첫 실행 과정을 안내합니다.

가장 적합한 용도: CI에서 테스트 시나리오를 실행하고 스크립트에서 프로젝트 리소스를 관리하는 것, 특히 계약이 모든 것을 주도하는 스펙 우선 API 개발 워크플로에서 유용합니다.

솔직한 참고: Apidog은 오픈소스가 아닙니다. 무료 등급이 있는 상업 제품입니다. 하지만 이 무료 등급과 CLI를 사용하면, 요청 클라이언트, 모의 서버, 테스트 러너를 직접 조합하는 대신, 하나의 프로젝트에서 모든 것을 통합적으로 처리할 수 있는 대안을 얻게 됩니다. 경량 부분은 `apidog-cli` 바이너리이며, 전체 Apidog 플랫폼은 동일한 프로젝트 위에 GUI를 제공합니다.

선택 방법

이들 대부분은 경쟁 관계가 아니라 상호 보완적입니다. 아마도 HTTP 클라이언트, jq, 터널, 감시자, 테스트 러너 등 여러 도구를 함께 사용하게 될 것입니다.

도구	가장 적합한 용도	설치	오픈소스 여부
curl	스크립트 요청, CI 상태 확인	사전 설치됨	예 (curl 라이선스)
HTTPie	가독성 좋은 대화형 요청	`pip install httpie`	예 (BSD)
xh	HTTPie 느낌, 네이티브 속도	`cargo install xh` / 바이너리	예 (MIT)
jq	JSON 응답 필터링	`brew install jq` / 바이너리	예 (MIT)
gh	GitHub PR 및 CI 스크립트 작성	`brew install gh` / 바이너리	예 (MIT)
ngrok	로컬호스트 노출, 웹훅	바이너리 다운로드	아니오 (프리미엄)
mkcert	신뢰할 수 있는 로컬 HTTPS 인증서	`brew install mkcert` / 바이너리	예 (BSD)
watchexec	파일 변경 시 재실행	`cargo install watchexec-cli`	예 (Apache-2.0)
Docker CLI	임시 백엔드 서비스	Docker 설치	예 (Apache-2.0)
apidog-cli	테스트 시나리오 실행, 프로젝트 관리	`npm install -g apidog-cli`	아니오 (프리미엄)

작업에 따라 선택하세요. 요청 전송: 대화형 작업에는 xh 또는 HTTPie, 스크립트에는 curl. 응답 읽기: 항상 jq. 포트 노출: ngrok. 로컬 HTTPS: mkcert. 저장 시 재실행: watchexec. 백엔드 서비스: Docker. API 테스트 실행 및 프로젝트 관리: apidog-cli.

마무리하며

좋은 경량 도구 세트는 각각 한 가지 일을 하고 다음 도구로 파이프 연결되는 작고 빠른 도구들입니다. curl과 xh는 요청을 보내고, jq는 이를 읽으며, ngrok과 mkcert는 로컬 접근을 처리하고, watchexec은 편집-실행 루프를 닫아주며, Docker는 일회용 인프라를 제공합니다. 이들 중 어느 것도 유용해지기 전에 많은 것을 요구하지 않습니다.

`apidog-cli`는 이 루프를 실제 API 프로젝트로 다시 연결하는 부분으로, 터미널에서 실행하는 엔드포인트와 테스트가 팀에서 설계하고 배포하는 것과 동일하게 합니다. 프로젝트를 설정하려면 Apidog을 다운로드한 다음, CI 파이프라인에서 CLI를 사용하여 명령줄에서 프로젝트를 관리하세요. 한 번에 하나의 요청이 아니라 전체 API 수명 주기에 동일한 속도와 발자취 아이디어가 적용됩니다.