대부분의 개발자 워크플로우는 여전히 터미널을 통해 실행되며, 수년간 견고하게 유지되는 도구들은 한 가지 특징을 공유하는 경향이 있습니다: 바로 오픈 소스라는 점입니다. 코드를 읽을 수 있고, 서버를 실행하는 모든 것을 자체 호스팅할 수 있으며, 좌석 라이선스나 "영업팀 문의" 장벽에 부딪힐 일이 없습니다. 도구가 MIT 또는 Apache 라이선스를 가지고 GitHub에 있다면, 스스로 확인할 수 있는 유지보수 신호를 얻을 수 있을 뿐만 아니라, 프로젝트가 정체될 경우 포크할 자유도 주어집니다.
이 글은 일상적인 API 개발 및 백엔드 작업에 적합한 무료의 진정한 오픈 소스 CLI 도구들을 엄선하여 정리한 목록입니다. 여기에 있는 모든 도구는 허용적 또는 카피레프트 라이선스 하에 제공되며, 소스는 GitHub에 보관되고, 실행 비용은 전혀 들지 않습니다. 중요하게 고려된 것은 라이선스와 종속성이지, 순수 크기나 시작 속도가 아닙니다.
핵심 루프를 위한 7가지 도구를 소개합니다: 요청 만들기, JSON 파싱, HTTP 흐름 테스트, GitHub 작업, 로컬 서버를 인터넷에 노출하는 것 등입니다. 각 항목은 라이선스를 명시하고, 저장소 링크를 제공하며, 실제 명령어를 하나씩 보여주어 작동 방식을 확인할 수 있습니다. 또한, 무료 티어 상용 도구가 적합한 위치에 대한 솔직한 언급도 명확하게 표시되어 있으므로, 오픈 소스 항목과 혼동할 일이 없습니다.
CLI 도구가 개발을 위한 "오픈 소스"가 되는 기준은 무엇인가요?
많은 도구들이 무료로 다운로드할 수 있지만 내부적으로는 폐쇄적이거나, 핵심은 개방되어 있지만 유용한 부분은 유료 기능 뒤에 숨겨져 있습니다. 이 목록에서는 다음 세 가지 확인 사항을 통과해야 도구로 인정됩니다.
- 라이선스. OSI 승인 라이선스(MIT, Apache 2.0, BSD 또는 GPL) 하에 제공됩니다. 이를 통해 상업적으로 사용하고, 자체 호스팅하며, 허락 없이 포크할 수 있습니다.
- GitHub (또는 동등한 저장소)에 소스 코드 공개. 모든 코드를 읽고, 이슈를 제기하며, 커밋 기록과 릴리스 주기를 통해 유지보수 상태를 판단할 수 있습니다.
- 종속성 없음. 필수 계정, 끌 수 없는 원격 측정 기능, 강제로 임대해야 하는 서버 구성 요소가 없습니다. 서비스를 실행하는 경우, 해당 서비스를 직접 실행할 수 있습니다.
별점과 최근 커밋도 중요하지만, 이는 부차적인 요소입니다. 상업적 사용을 제한하는 소스-어베일러블 라이선스를 가진 유행하는 도구보다 조용하고 안정적인 MIT 도구가 더 낫습니다. 어떤 것을 표준으로 삼기 전에 LICENSE 파일을 확인하세요.
curl: 범용 HTTP 클라이언트
curl은 거의 모든 다른 HTTP 도구들이 비교되는 기준이 되는 도구입니다. 수십 가지 프로토콜을 지원하고, 거의 모든 OS에 기본적으로 포함되어 있으며, 1996년부터 지속적으로 유지보수되어 왔습니다. 허용적인 curl 라이선스(MIT/X 파생) 하에 라이선스되어 있으며, 소스는 github.com/curl/curl에 있습니다.
API 작업의 경우, curl은 가장 기본적인 요청 도구입니다. 이미 설치되어 있으므로 어떤 스크립트나 CI 작업에서도 이를 사용할 수 있습니다.
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"}'
최적의 용도: 이식성과 스크립팅. 쉘이 실행되는 곳이라면 어디든 curl도 실행됩니다. 솔직한 한계점은 사용 편의성입니다. 원시 curl 출력은 밀도가 높고, 헤더 처리는 장황하며, JSON 본문을 읽으려면 다른 곳으로 파이프해야 합니다. 이것이 바로 다음 두 도구가 존재하는 이유입니다.
HTTPie: 사용자 친화적인 출력을 제공하는 curl
HTTPie는 스크립트뿐만 아니라 사람들을 위해 만들어진 현대적인 HTTP 클라이언트입니다. 요청은 평범한 영어처럼 읽히고, JSON이 기본 본문 유형이며, 응답은 색상으로 표시되고 형식이 지정되어 돌아옵니다. BSD-3-Clause 라이선스 하에 라이선스되어 있으며, github.com/httpie/cli에서 오픈 소스로 제공됩니다.
pip로 설치한 다음, http 명령어를 사용하세요:
pip install httpie
http POST httpbin.org/post name=apidog role=platform
이것이 전체 요청입니다. name=apidog은 자동으로 JSON 필드가 되고, 헤더와 상태는 색상과 함께 출력되며, 본문은 다른 도구 없이 예쁘게 출력됩니다. 최적의 용도: 수동 상호작용 탐색 및 디버깅. 솔직한 한계는 파이썬 패키지라는 점입니다. 따라서 단일 정적 바이너리보다 설치가 무겁고, 제한적인 CI 이미지에서는 여전히 curl을 찾게 될 수 있습니다.
jq: 모든 파이프라인에 필요한 JSON 프로세서
API는 JSON을 반환하며, jq는 명령줄에서 이를 처리하는 방법입니다. 작은 쿼리 언어로 필드를 필터링, 재구성, 추출하며, 파이프에서 curl 또는 HTTPie와 깔끔하게 구성됩니다. jq는 MIT 라이선스이며, github.com/jqlang/jq에서 커뮤니티에 의해 유지보수됩니다.
API 응답을 바로 파이프하세요:
curl -s https://api.github.com/repos/jqlang/jq \
| jq '{name: .name, stars: .stargazers_count, license: .license.spdx_id}'
이것은 큰 응답에서 세 가지 필드를 추출하여 깔끔한 객체를 만듭니다. 최적의 용도: 복잡한 JSON을 스크립트의 다음 단계에 필요한 정확한 형태로 변환하는 것. 솔직한 한계는 학습 곡선입니다. jq의 문법은 강력하지만 간결하며, 복잡한 변환은 빠르게 이해하기 어려워질 수 있습니다. 하지만 일상적인 필드 추출의 경우, 오후 한나절이면 필요한 것의 90%를 배울 수 있습니다.
gh: GitHub CLI
gh는 GitHub를 터미널로 가져옵니다: 브라우저를 열지 않고도 풀 리퀘스트, 이슈, 릴리스, Actions 실행, API 호출 등 모든 것을 처리할 수 있습니다. Go로 작성되었으며, MIT 라이선스를 가지고 있고, github.com/cli/cli에 있습니다. 많은 API 및 백엔드 작업이 GitHub 저장소에서 이루어지므로, 핵심 도구 키트에 포함되어야 합니다.
한 가지 유용한 팁: gh api는 GitHub REST 및 GraphQL API 위에 인증되고 페이지네이션된 래퍼를 제공하므로, curl에 토큰을 수동으로 입력할 필요가 없습니다.
gh api repos/cli/cli/releases --jq '.[0].tag_name'
이는 gh의 내장 jq 필터를 사용하여 최신 릴리스 태그를 출력합니다. 최적의 용도: CI 워크플로우부터 릴리스 자동화까지 GitHub 자체를 스크립트화하는 것. 솔직한 한계는 범위입니다; 설계상 GitHub 전용입니다. GitLab 또는 Gitea의 경우 해당 CLI 또는 API에 대한 일반 curl을 사용해야 합니다.
Hurl: 커밋 가능한 일반 텍스트 HTTP 테스트
Hurl은 간단한 일반 텍스트 파일에 정의된 HTTP 요청을 실행하고 테스트합니다. 요청을 작성하고, 상태 코드, 헤더, JSON 본문에 대한 어설션을 수행하며, 한 응답에서 다음 응답으로 값을 캡처하여 호출을 연결합니다. 이는 "API 테스트"를 Git에 체크인할 수 있는 파일로 만듭니다. Hurl은 Rust로 작성되었으며, Apache 2.0 라이선스를 가지고 있고, github.com/Orange-OpenSource/hurl에서 Orange에 의해 유지보수됩니다.
.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에 바로 통합될 수 있습니다. 최적의 용도: 팀 전체가 프레임워크를 배우지 않고도 편집할 수 있는 가독성 있고 버전 관리되는 통합 테스트. 솔직한 한계는 HTTP 요청/응답 테스트에 초점을 맞추고 있다는 점입니다. 완전한 계약 테스트 또는 부하 테스트 도구는 아닙니다. CLI 테스트가 스펙 우선 API 개발 워크플로우에 어떻게 통합되는지에 대한 더 넓은 시야를 원한다면, 어설션 파일은 OpenAPI 진실의 원천과 잘 어울립니다.
cloudflared: 유료 터널 없이 로컬 서버 노출하기
때로는 노트북에서 실행 중인 API를 위한 공개 URL이 필요할 때가 있습니다: 웹훅 콜백, 데모, 실제 호스트를 대상으로 하는 모바일 테스트 등. cloudflared는 Cloudflare의 터널 클라이언트로, 빠른 터널 모드를 통해 단일 명령으로 계정 없이 임시 공개 *.trycloudflare.com URL을 제공합니다. Go로 작성되었으며, Apache 2.0 라이선스를 가지고 있고, github.com/cloudflare/cloudflared에서 오픈 소스로 제공됩니다.
로컬 포트를 가리키세요:
cloudflared tunnel --url http://localhost:3000
이를 중지할 때까지 localhost:3000으로 전달되는 공개 HTTPS URL을 출력합니다. 최적의 용도: 아무것도 가입하고 싶지 않을 때 빠르고 무료로 임시 터널을 생성하는 것. npm 생태계에 완전히 머무르고 싶다면, localtunnel(MIT)이 npx localtunnel --port 3000 명령으로 동일한 작업을 수행합니다. 빠른 터널의 솔직한 한계: URL이 무작위적이고 일시적이며, 안정적인 명명된 터널의 경우 Cloudflare 계정과 구성을 생성해야 하지만, 클라이언트는 어떤 경우든 오픈 소스로 유지됩니다.
git: GUI가 아닌 CLI로서의 버전 관리
git이 기본적으로 명령줄 도구라는 사실을 잊기 쉽습니다. 위에 언급된 모든 API 사양, 테스트 파일 및 Hurl 시나리오는 Git 저장소에 속하며, 진정한 힘은 CLI에 있습니다: 정확한 스테이징, 바이섹트, 리베이스, 그리고 커밋이 반영되기 전에 API 테스트를 실행하는 훅 등입니다. git은 GPLv2 라이선스이며, github.com/git/git에서 공개적으로 개발되고 있습니다.
키트를 하나로 묶는 작은 예시: 코드가 반영되기 전에 Hurl 테스트를 실행하는 pre-commit 훅입니다.
echo 'hurl --test *.hurl' > .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit
최적의 용도: 다른 모든 것의 기반이 되는 것. 처음부터 자체 호스팅 가능하며, 서버가 필요 없고, 모든 면에서 포크(forge) 가능합니다. 솔직한 한계는 git이 버전 관리이지 프로젝트 호스팅은 아니라는 점입니다. 호스팅 레이어(GitHub, GitLab, Gitea)는 별개의 선택이며, 그중 일부만이 오픈 소스 자체입니다.
솔직한 여담: Apidog이 적합한 곳
Apidog은 오픈 소스가 아니므로, 이 목록에 OSS 항목으로 포함되지 않습니다. 무료 티어가 있는 상용 제품이며, 여기에 언급할 가치가 있는 한 가지 이유는 다음과 같습니다: 위에 언급된 도구들은 개별적으로 훌륭하지만, 결국에는 수동으로 연결해야 합니다. 요청을 위한 curl, 파싱을 위한 jq, 테스트를 위한 Hurl, 별도의 목(mock) 서버, 문서 생성기, 쉘 프로필에서 관리되는 환경 변수 등입니다.
Apidog은 디자인, 테스트, 모킹, 문서를 하나의 워크스페이스에 통합하며, apidog-cli는 이 모든 기능을 터미널로 가져옵니다. 이는 npm 패키지(npm install -g apidog-cli)이며, 테스트 시나리오를 실행하고, 엔드포인트와 스키마를 관리하며, 목(mock) 기대를 생성하고, OpenAPI를 가져오거나 내보내는 등 모든 작업을 스크립트와 AI 에이전트가 읽을 수 있는 구조화된 JSON 출력으로 처리합니다. apidog run은 모든 테스트 통과 시 0을 반환하고 실패 시 0이 아닌 값을 반환하므로, Hurl과 마찬가지로 CI에 통합될 수 있습니다.
솔직한 관점: 종속성 없이 완전한 소스 코드 접근을 원한다면 오픈 소스 키트가 올바른 선택이며, 이 글의 주제도 바로 그것입니다. 만약 7가지 도구를 직접 연결하고 유지보수하는 것을 원치 않는다면, Apidog의 무료 티어와 CLI가 통합된 대안을 제공합니다. 둘 다 유효하며, 서로 다른 것을 최적화합니다. CLI 경로를 선택한다면, 설치 가이드에서 인증 및 첫 명령어를 안내합니다.
선택 방법
작업에 맞는 도구를 선택하세요. 대부분의 개발자는 이들 중 여러 개를 함께 사용합니다. curl 또는 HTTPie로 데이터를 가져오고, jq로 파싱하며, Hurl로 테스트하고, git으로 모든 것을 버전 관리합니다.
| 도구 | 최적의 용도 | 설치 | 오픈 소스 여부? | 참고 |
|---|---|---|---|---|
| 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 및 백엔드 개발의 핵심을 다루며, 이들 모두는 읽을 수 있는 라이선스와 포크할 수 있는 저장소를 가지고 있습니다. 현재 워크플로우에 맞는 두세 가지 도구로 시작하고, 필요에 따라 나머지를 추가하세요.
이러한 도구들을 기반으로 에이전트 기반 워크플로우를 구축한다면, 동일한 터미널 우선 원칙이 적용되며, 구조화된 JSON 출력이 연결 조직이 됩니다. API 개발을 위한 AI 코딩 어시스턴트에 대한 글에서 더 깊이 다룹니다. 그리고 7가지 개별 도구를 유지보수하는 것이 그 자체로 하나의 작업처럼 느껴지기 시작한다면, Apidog을 다운로드하고 Apidog CLI를 사용해 보면서 통합 경로가 어떤 모습인지 직접 확인해 보세요.