대부분의 개발자 워크플로우는 여전히 터미널에서 실행됩니다. 오래 유지되는 도구들은 대개 오픈 소스라는 공통점이 있습니다. 코드를 직접 검토하고, 필요한 구성 요소를 자체 호스팅하며, 좌석 라이선스나 “영업팀 문의” 절차 없이 사용할 수 있습니다. MIT나 Apache 같은 라이선스와 공개 GitHub 저장소는 유지보수 상태를 확인하고, 프로젝트가 멈췄을 때 포크할 수 있는 선택권을 제공합니다.
이 글에서는 일상적인 API 개발과 백엔드 작업에 바로 적용할 수 있는 무료 오픈 소스 CLI 도구 7가지를 정리합니다. 각 도구는 공개 라이선스와 소스 저장소를 제공하며, 요청 생성, JSON 처리, HTTP 테스트, GitHub 자동화, 로컬 서버 공개, 버전 관리 같은 핵심 작업을 다룹니다.
CLI 도구를 오픈 소스로 판단하는 기준
무료 다운로드가 가능하다고 해서 모두 오픈 소스인 것은 아닙니다. 이 글에서는 다음 기준을 충족하는 도구만 오픈 소스 도구로 봅니다.
- OSI 승인 라이선스: MIT, Apache 2.0, BSD, GPL 등 상업적 사용, 수정, 포크, 자체 호스팅을 허용하는 라이선스여야 합니다.
- 공개 소스 코드: GitHub 또는 동등한 공개 저장소에서 코드, 이슈, 커밋, 릴리스를 확인할 수 있어야 합니다.
- 필수 서비스 종속성 없음: 계정 생성, 강제 원격 측정, 외부 서버 임대가 필수가 아니어야 합니다. 서버 구성 요소가 있다면 직접 실행할 수 있어야 합니다.
도입 전에는 별점보다 LICENSE 파일을 먼저 확인하세요. 안정적인 MIT 도구가 사용 제한이 있는 소스-어베일러블 도구보다 장기적으로 더 적합할 수 있습니다.
1. curl: 범용 HTTP 클라이언트
curl은 HTTP 요청을 스크립트와 CI에서 실행할 때 가장 기본이 되는 도구입니다. 다양한 프로토콜을 지원하고 대부분의 OS에 기본 설치되어 있습니다. curl 라이선스는 MIT/X 계열이며, 소스는 github.com/curl/curl에서 확인할 수 있습니다.
GitHub API에 이슈를 생성하는 예시는 다음과 같습니다.
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","body":"Filed from curl"}'
실전 사용 팁
- 응답 본문만 필요하면
-s를 사용합니다. - 실패한 HTTP 상태 코드도 CI 실패로 처리하려면
--fail-with-body를 추가합니다. - 인증 토큰은 명령어에 직접 쓰지 말고 환경 변수로 전달합니다.
curl -sS --fail-with-body \
-H "Authorization: Bearer $TOKEN" \
https://api.example.com/health
적합한 작업: 이식성 있는 스크립트, CI, 간단한 API 호출
한계: 헤더 처리와 JSON 가공이 장황합니다. 보통 jq와 함께 사용합니다.
2. HTTPie: 사람이 읽기 쉬운 HTTP 클라이언트
HTTPie는 수동 API 탐색과 디버깅에 적합한 HTTP 클라이언트입니다. JSON 요청을 간결하게 작성할 수 있고, 응답을 읽기 쉬운 형태로 출력합니다. BSD-3-Clause 라이선스를 사용하며, 소스는 github.com/httpie/cli에 공개되어 있습니다.
설치 후 http 명령어를 사용합니다.
pip install httpie
http POST httpbin.org/post name=apidog role=platform
위 명령에서 name=apidog, role=platform은 JSON 필드로 처리됩니다. 직접 JSON을 작성할 수도 있습니다.
http POST https://api.example.com/users \
Authorization:"Bearer $TOKEN" \
name="Kim" \
role="developer"
실전 사용 팁
응답 헤더까지 확인하려면 -v를 사용합니다.
http -v GET https://api.example.com/users/1
적합한 작업: 로컬 개발 중 수동 API 디버깅, 응답 구조 확인
한계: Python 패키지 기반이므로 매우 제한적인 CI 이미지에서는 curl보다 설치 부담이 있을 수 있습니다.
3. jq: JSON 응답 가공
API 응답이 JSON이라면 jq는 거의 필수입니다. 필드 추출, 배열 필터링, 객체 재구성 등을 명령줄에서 처리할 수 있습니다. jq는 MIT 라이선스이며, 소스는 github.com/jqlang/jq에서 유지보수됩니다.
curl 응답에서 필요한 필드만 추출해 보겠습니다.
curl -s https://api.github.com/repos/jqlang/jq \
| jq '{name: .name, stars: .stargazers_count, license: .license.spdx_id}'
출력 예시는 다음과 같은 구조입니다.
{
"name": "jq",
"stars": 0,
"license": "MIT"
}
자주 쓰는 jq 패턴
배열에서 특정 필드만 추출:
curl -s https://api.example.com/users \
| jq '.[] | {id, name}'
조건에 맞는 항목 필터링:
curl -s https://api.example.com/users \
| jq '.[] | select(.active == true)'
다음 단계에서 사용할 값만 변수로 추출:
USER_ID=$(curl -s https://api.example.com/users/1 | jq -r '.id')
적합한 작업: API 응답을 후속 셸 명령이나 CI 단계에 맞는 형태로 변환
한계: 복잡한 필터는 가독성이 떨어질 수 있습니다. 하지만 일상적인 필드 추출과 필터링은 빠르게 익힐 수 있습니다.
4. gh: GitHub CLI
gh는 GitHub 작업을 터미널에서 자동화할 수 있게 해 줍니다. 풀 리퀘스트, 이슈, 릴리스, GitHub Actions, REST API, GraphQL API를 브라우저 없이 다룰 수 있습니다. Go로 작성되었고 MIT 라이선스를 사용합니다. 소스는 github.com/cli/cli에 있습니다.
먼저 인증합니다.
gh auth login
최신 릴리스 태그를 가져오는 예시입니다.
gh api repos/cli/cli/releases --jq '.[0].tag_name'
이슈 생성도 가능합니다.
gh issue create \
--repo owner/repository \
--title "API 테스트 실패" \
--body "CI에서 Hurl 테스트가 실패했습니다."
실전 사용 팁
CI에서 GitHub API를 호출할 때는 토큰 헤더를 직접 구성하는 curl보다 gh api가 간결할 수 있습니다.
gh api repos/owner/repository/actions/runs \
--jq '.workflow_runs[0].status'
적합한 작업: GitHub 릴리스 자동화, 이슈/PR 관리, Actions 상태 조회
한계: GitHub 전용입니다. GitLab이나 Gitea에는 각 플랫폼의 CLI 또는 curl을 사용해야 합니다.
5. Hurl: Git에 커밋하는 HTTP 테스트
Hurl은 일반 텍스트 파일로 HTTP 요청과 검증 조건을 작성하는 테스트 도구입니다. 상태 코드, 헤더, JSON 본문을 검증하고, 응답 값을 다음 요청에 연결할 수 있습니다. Rust로 작성되었으며 Apache 2.0 라이선스를 사용합니다. 소스는 github.com/Orange-OpenSource/hurl에 있습니다.
repo.hurl 파일을 만듭니다.
GET https://api.github.com/repos/Orange-OpenSource/hurl
HTTP 200
[Asserts]
jsonpath "$.name" == "hurl"
jsonpath "$.stargazers_count" > 1000
테스트를 실행합니다.
hurl --test repo.hurl
Hurl은 모든 검증이 통과하면 종료 코드 0을 반환하고, 하나라도 실패하면 0이 아닌 값을 반환합니다. 따라서 CI 단계에 바로 추가할 수 있습니다.
- name: Run API tests
run: hurl --test tests/*.hurl
적합한 작업: 버전 관리 가능한 API 통합 테스트, 팀 공유용 HTTP 시나리오
한계: HTTP 요청/응답 테스트에 집중합니다. 전체 계약 테스트나 부하 테스트 도구는 아닙니다.
Hurl 파일은 스펙 우선 API 개발 워크플로우에서 OpenAPI 명세와 함께 관리하기 좋습니다.
6. cloudflared: 로컬 서버를 공개 URL로 노출
웹훅 콜백, 모바일 기기 테스트, 데모를 위해 로컬 API에 외부에서 접근해야 할 때가 있습니다. cloudflared는 Cloudflare Tunnel 클라이언트입니다. 빠른 터널 모드에서는 계정 없이 임시 *.trycloudflare.com URL을 만들 수 있습니다.
cloudflared는 Go로 작성되었고 Apache 2.0 라이선스를 사용합니다. 소스는 github.com/cloudflare/cloudflared에서 확인할 수 있습니다.
로컬 포트 3000을 공개하려면 다음을 실행합니다.
cloudflared tunnel --url http://localhost:3000
명령 실행 후 출력되는 HTTPS URL로 들어오는 요청은 localhost:3000으로 전달됩니다.
실전 사용 팁
웹훅 URL이 필요한 경우, 터널 URL을 환경 변수에 저장해 두면 테스트 스크립트에서 재사용하기 쉽습니다.
export WEBHOOK_BASE_URL="https://random-name.trycloudflare.com"
npm 환경에만 머물고 싶다면 localtunnel도 사용할 수 있습니다.
npx localtunnel --port 3000
적합한 작업: 가입 없이 임시 웹훅 URL 생성, 로컬 데모 공유
한계: 빠른 터널 URL은 무작위이며 일시적입니다. 안정적인 고정 도메인 터널에는 계정과 추가 구성이 필요합니다.
7. git: API 자산을 버전 관리하는 기반
git은 GUI 도구가 아니라 강력한 CLI 도구입니다. OpenAPI 명세, Hurl 테스트, 환경 예시 파일, 배포 스크립트는 모두 Git 저장소에서 관리해야 합니다. git은 GPLv2 라이선스를 사용하며, github.com/git/git에서 공개 개발됩니다.
API 테스트를 커밋 전에 실행하려면 pre-commit 훅을 추가할 수 있습니다.
echo 'hurl --test *.hurl' > .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit
이제 .hurl 테스트가 실패하면 커밋도 실패합니다.
권장 저장소 구조
api-project/
├── openapi/
│ └── openapi.yaml
├── tests/
│ ├── health.hurl
│ └── users.hurl
├── scripts/
│ └── smoke-test.sh
└── .git/hooks/
적합한 작업: API 명세, 테스트, 스크립트, 설정의 버전 관리
한계: git은 버전 관리 도구이며 호스팅 플랫폼은 아닙니다. GitHub, GitLab, Gitea 같은 호스팅 계층은 별도로 선택해야 합니다.
솔직한 여담: Apidog이 적합한 경우
Apidog은 오픈 소스가 아니므로 위 목록의 OSS 도구로 분류하지 않습니다. 무료 티어를 제공하는 상용 제품입니다. 다만 curl, jq, Hurl, 목 서버, 문서 생성기, 환경 변수 관리 등을 각각 연결하고 유지보수하는 부담을 줄이고 싶을 때는 통합 도구가 유용할 수 있습니다.
Apidog은 API 설계, 테스트, 모킹, 문서를 하나의 워크스페이스에서 다루며, apidog-cli는 이를 터미널 작업으로 확장합니다.
npm install -g apidog-cli
CLI는 테스트 시나리오 실행, 엔드포인트와 스키마 관리, OpenAPI 가져오기/내보내기 등을 구조화된 JSON 출력으로 처리합니다. apidog run 역시 성공 시 0, 실패 시 0이 아닌 종료 코드를 반환하므로 CI에 통합할 수 있습니다.
오픈 소스 도구 체인을 직접 구성하고 완전한 소스 접근성을 확보하려면 이 글의 CLI 조합이 적합합니다. 반대로 여러 기능을 하나의 워크플로우로 관리하고 싶다면 Apidog의 무료 티어와 CLI를 고려할 수 있습니다. CLI 시작 방법은 설치 가이드에서 확인할 수 있습니다.
선택 방법
대부분의 개발자는 하나의 도구만 사용하지 않습니다. 일반적인 조합은 다음과 같습니다.
curl 또는 HTTPie → jq → Hurl → git
-
curl또는HTTPie로 API를 호출합니다. -
jq로 응답에서 필요한 값을 추출합니다. -
Hurl로 반복 가능한 API 테스트를 작성합니다. -
git으로 명세, 테스트, 스크립트를 버전 관리합니다. - 외부 웹훅 테스트가 필요하면
cloudflared를 추가합니다. - GitHub 자동화가 많다면
gh를 추가합니다.
| 도구 | 최적의 용도 | 설치 | 오픈 소스 여부 | 참고 |
|---|---|---|---|---|
| curl | 이식성 있는 요청, 스크립팅 | 대부분 사전 설치 | 예 (curl/MIT 스타일) | 거의 모든 시스템에서 사용 가능 |
| HTTPie | 사람이 읽기 쉬운 디버깅 | pip install httpie |
예 (BSD-3-Clause) | 컬러 출력, JSON 친화적 |
| jq | JSON 응답 파싱 | 패키지 관리자 / 바이너리 | 예 (MIT) | 파이프라인 연결에 적합 |
| gh | GitHub 자동화 | 패키지 관리자 / 바이너리 | 예 (MIT) | GitHub 전용 |
| Hurl | 커밋 가능한 HTTP 테스트 | 단일 바이너리 | 예 (Apache 2.0) | 실패 시 0이 아닌 값 반환 |
| cloudflared | 임시 공개 터널 | 단일 바이너리 | 예 (Apache 2.0) | 빠른 터널은 계정 불필요 |
| git | 버전 관리 | 대부분 사전 설치 | 예 (GPLv2) | 전체 워크플로우의 기반 |
| apidog-cli | 통합 API 워크플로우 | npm i -g apidog-cli |
아니요 (무료 티어) | 설계 + 테스트 + 모킹 + 문서 |
직접 연결한 도구 체인을 소유하고 싶다면 단일 목적의 오픈 소스 도구를 선택하세요. 통합 플랫폼이 대체하는 범위를 확인하려면 종합 API 개발 플랫폼으로서의 Apidog도 참고할 수 있습니다.
마무리
curl, HTTPie, jq, gh, Hurl, cloudflared, git은 API와 백엔드 개발의 핵심 작업을 다룹니다. 모두 공개 라이선스와 확인 가능한 소스 저장소를 제공하며, 필요에 따라 조합할 수 있습니다.
처음에는 현재 워크플로우에서 가장 부족한 작업 하나만 선택하세요.
- API 요청을 자동화해야 한다면
curl - JSON을 처리해야 한다면
jq - HTTP 테스트를 Git에 저장해야 한다면
Hurl - GitHub 작업을 자동화해야 한다면
gh - 웹훅을 로컬에서 테스트해야 한다면
cloudflared
에이전트 기반 워크플로우를 구축한다면 터미널 우선 원칙과 구조화된 JSON 출력이 특히 중요합니다. 자세한 내용은 API 개발을 위한 AI 코딩 어시스턴트에서 확인할 수 있습니다. 여러 도구를 직접 유지보수하는 비용이 커진다면 Apidog 다운로드와 Apidog CLI를 통해 통합 워크플로우도 검토해 보세요.





Top comments (0)