터미널에서 API를 자주 호출하지만 curl 옵션이 길고 JSON 출력이 읽기 어렵다면 curlie를 사용해 볼 만합니다. curlie는 curl을 래핑하면서 HTTPie 스타일의 간결한 문법과 색상화된 출력을 제공하는 명령줄 HTTP 클라이언트입니다. 이 글에서는 curlie를 설치하고, 요청을 보내고, curl/HTTPie와 비교하며, 일회성 호출을 반복 가능한 API 테스트 워크플로우로 전환하는 방법을 정리합니다.
curlie란 무엇인가요
curlie는 curl의 프런트엔드입니다. HTTP 클라이언트를 새로 구현하는 대신, HTTPie 스타일의 명령을 파싱한 뒤 실제 요청은 시스템에 설치된 curl 바이너리로 전달합니다.
즉, curlie는 다음 두 가지를 결합합니다.
-
curl의 네트워크 처리, TLS, 프록시, 프로토콜 지원 - HTTPie처럼 읽기 쉬운 요청 문법과 색상화된 응답 출력
이 설계 덕분에 curlie에서는 기존 curl 플래그를 그대로 사용할 수 있습니다. 간단한 요청은 짧게 작성하고, 세부 제어가 필요하면 --max-time, --proxy, --insecure, -v 같은 네이티브 curl 옵션을 섞으면 됩니다.
curlie는 단일 Go 바이너리로 배포됩니다. 별도 런타임이나 Python 환경, 플러그인 설치가 필요하지 않습니다. 바이너리를 PATH에 두고 사용하면 됩니다.
정리하면, curlie는 테스트 러너가 아니라 터미널에서 빠르게 API를 탐색하기 위한 대화형 HTTP 클라이언트입니다.
curlie를 사용하는 이유
curl은 거의 모든 환경에 있지만 기본 출력은 개발자가 읽기 편한 형태가 아닙니다. JSON은 한 줄로 출력되고, 헤더와 본문을 구분하려면 추가 옵션이 필요합니다.
HTTPie는 이 문제를 문법과 출력 측면에서 개선했지만, 별도의 Python 기반 도구입니다. curlie는 중간 지점에 있습니다. 내부적으로는 curl을 사용하면서, 표면 문법은 HTTPie처럼 간결합니다.
curlie가 유용한 경우는 다음과 같습니다.
JSON 응답을 바로 읽고 싶을 때
응답이 색상화되고 JSON이 보기 좋게 포맷됩니다.헤더와 본문을 짧게 작성하고 싶을 때
-H,-d를 반복하는 대신Header:value,key=value문법을 사용할 수 있습니다.기존 curl 옵션을 유지하고 싶을 때
curlie는curl을 래핑하므로 네이티브curl플래그를 그대로 전달할 수 있습니다.가벼운 도구를 선호할 때
단일 바이너리로 설치하고 실행할 수 있습니다.요청이 실제로 어떻게 전송되는지 확인하고 싶을 때
-v옵션으로 요청/응답 헤더와 상세 정보를 확인할 수 있습니다.
curlie 설치
curlie는 패키지 매니저 또는 GitHub 릴리스 바이너리로 설치할 수 있습니다.
macOS에서 Homebrew를 사용한다면:
brew install curlie
Go가 설치되어 있다면:
go install github.com/rs/curlie@latest
또는 GitHub 릴리스에서 OS에 맞는 바이너리를 다운로드한 뒤 PATH에 넣습니다.
mv curlie /usr/local/bin/
curlie --version
curlie는 내부적으로 curl을 호출하므로 시스템에 curl이 설치되어 있어야 합니다. macOS와 대부분의 Linux 배포판에는 기본적으로 포함되어 있습니다.
기본 사용법
GET 요청 보내기
가장 간단한 요청은 URL만 입력하면 됩니다.
curlie httpbin.org/get
메서드를 지정하지 않으면 curlie는 GET으로 처리합니다. 스킴을 생략하면 http://를 자동으로 붙입니다.
명시적으로 작성하려면 다음과 같이 입력합니다.
curlie GET httpbin.org/get
JSON 본문 보내기
key=value 형식으로 필드를 지정하면 curlie가 JSON 본문을 생성합니다.
curlie POST httpbin.org/post name=apidog role=platform
위 명령은 다음 JSON을 요청 본문으로 보냅니다.
{
"name": "apidog",
"role": "platform"
}
curlie는 이 경우 Content-Type: application/json 헤더도 함께 설정합니다.
헤더 추가하기
헤더는 Header:value 형식으로 추가합니다.
curlie GET httpbin.org/get Authorization:"Bearer token123"
여러 헤더도 같은 방식으로 이어 붙일 수 있습니다.
curlie GET httpbin.org/get \
Authorization:"Bearer token123" \
Accept:"application/json"
쿼리 파라미터 추가하기
쿼리 파라미터는 param==value 문법을 사용합니다.
curlie GET httpbin.org/get search==apidog page==1
이는 다음 요청과 같습니다.
GET /get?search=apidog&page=1
curl 옵션 함께 사용하기
curlie는 curl을 래핑하므로 네이티브 curl 옵션을 함께 사용할 수 있습니다.
curlie -v --max-time 5 httpbin.org/get
자주 쓰는 옵션 예시는 다음과 같습니다.
# 상세 요청/응답 확인
curlie -v httpbin.org/get
# 타임아웃 지정
curlie --max-time 3 httpbin.org/get
# 리다이렉트 따라가기
curlie -L httpbin.org/redirect/1
# TLS 검증 비활성화
curlie -k https://example.local
특히 -v는 디버깅에 유용합니다. 실제로 어떤 헤더가 전송되었고 어떤 응답이 돌아왔는지 확인할 수 있습니다. 더 낮은 수준의 curl 옵션을 익히고 싶다면 curl REST API 가이드를 참고할 수 있습니다.
curlie vs curl vs HTTPie
세 도구는 모두 터미널에서 HTTP 요청을 보낼 수 있습니다. 차이는 문법, 출력, 실행 엔진에 있습니다.
| 측면 | curl | HTTPie | curlie |
|---|---|---|---|
| 엔진 | libcurl | Python 기반 구현 | curl 래핑 |
| 문법 | 플래그 중심: -X, -H, -d
|
간결한 key=value 문법 |
HTTPie 스타일 문법 |
| 출력 | 원시 출력 | 색상화, 예쁜 JSON | 색상화, 예쁜 JSON |
| 설치 | 대부분의 환경에 기본 설치 | Python 패키지 | 단일 Go 바이너리 |
| 네이티브 curl 플래그 | 지원 | 미지원 | 지원 |
| 종속성 | 거의 없음 | Python 런타임 | curl 바이너리 |
| 적합한 용도 | 스크립팅, 저수준 제어 | 읽기 쉬운 임시 호출 | curl 기반의 읽기 쉬운 임시 호출 |
선택 기준은 간단합니다.
- 이미
curl플래그에 익숙하고 그대로 활용하고 싶다면curlie - 독립적인 HTTP 클라이언트 기능과 HTTPie 생태계를 선호한다면
HTTPie - 최소 의존성과 범용성을 최우선으로 한다면
curl
HTTPie 자체가 궁금하다면 HTTPie 튜토리얼을 참고하세요. curl과 HTTPie 문법 차이는 curl-to-HTTPie 비교에서 확인할 수 있습니다.
터미널 도구와 GUI 기반 API 테스트 도구까지 비교하려면 REST API 테스트를 위한 curl 대안 모음을 참고할 수 있습니다.
curlie가 적합한 경우
curlie는 빠른 탐색과 디버깅에 적합합니다.
예를 들어 다음 작업에 잘 맞습니다.
- 새 엔드포인트가 응답하는지 확인
- JSON 응답 구조를 눈으로 빠르게 확인
- 인증 헤더나 쿠키 문제 디버깅
-
curl명령을 만들기 전에 요청 형태를 실험 - HTTP 요청/응답을 교육하거나 데모
예시:
curlie GET api.example.com/users \
Authorization:"Bearer $TOKEN" \
limit==10
응답 구조를 확인한 뒤 필요한 필드만 jq로 확인할 수도 있습니다.
curlie GET api.example.com/users Authorization:"Bearer $TOKEN" | jq '.data[0]'
curlie가 적합하지 않은 경우
curlie는 저장된 요청, 환경 관리, 테스트 어설션, 리포팅을 제공하는 테스트 플랫폼이 아닙니다.
다음 상황에서는 curlie만으로 부족합니다.
- 같은 요청을 팀원과 공유해야 하는 경우
- 로컬, 스테이징, 프로덕션 환경을 변수로 전환해야 하는 경우
- 상태 코드, 응답 필드, JSON 스키마를 자동 검증해야 하는 경우
- CI/CD 파이프라인에서 API 테스트를 반복 실행해야 하는 경우
- 실패 결과를 리포트로 남겨야 하는 경우
curlie 명령을 문서에 계속 붙여넣거나, grep과 쉘 스크립트로 검증 로직을 만들기 시작했다면 더 구조화된 워크플로우로 옮길 시점입니다.
업그레이드 경로: 일회성 호출에서 반복 가능한 API 워크플로우로
실무에서는 역할을 나누는 것이 좋습니다.
- curlie: 엔드포인트 탐색, 빠른 디버깅, 요청 실험
- API 테스트 플랫폼: 요청 저장, 환경 관리, 어설션, CI 실행, 팀 공유
Apidog는 curlie 이후 단계에서 사용할 수 있는 지속성 및 협업 레이어입니다. curlie를 대체하기보다는, 터미널에서 확인한 요청을 팀이 재사용할 수 있는 형태로 정리하는 데 적합합니다.
Apidog에서는 다음 작업을 할 수 있습니다.
- 요청을 컬렉션으로 저장
- 로컬, 스테이징, 프로덕션 환경 변수 관리
- 상태 코드, 응답 필드, 스키마에 대한 어설션 추가
-
apidog run으로 CI에서 저장된 테스트 실행 - 워크스페이스를 통해 팀과 요청 및 테스트 공유
실용적인 흐름은 다음과 같습니다.
- curlie로 엔드포인트를 빠르게 호출합니다.
curlie POST api.example.com/login email=user@example.com password=secret
- 응답 구조와 인증 방식을 확인합니다.
curlie -v POST api.example.com/login email=user@example.com password=secret
안정화된 요청을 Apidog에 저장합니다.
상태 코드와 응답 필드 어설션을 추가합니다.
예:
status code == 200
response.token exists
response.user.email == user@example.com
- CI에서
apidog run으로 반복 실행합니다.
이 방식이면 탐색은 빠르게 유지하면서, 검증은 자동화할 수 있습니다. API 테스트 설계 방식은 API 테스트 가이드에서 더 자세히 다룹니다.
자주 묻는 질문
curlie가 curl을 대체합니까?
완전한 대체품은 아닙니다. curlie는 curl 위에서 동작하는 프런트엔드입니다. 간결한 문법을 curl 호출로 변환하고 응답 출력을 보기 좋게 포맷합니다. 실제 네트워크 요청은 여전히 curl이 처리합니다.
curlie를 CI/CD 파이프라인에서 사용할 수 있습니까?
스크립트에서 curlie를 호출할 수는 있습니다. 하지만 curlie는 자동화된 테스트 러너로 설계된 도구가 아닙니다. 저장된 테스트 시나리오, 어설션, 구조화된 리포트가 없습니다.
CI/CD에서는 응답을 검증하고 실패 시 빌드를 실패 처리할 수 있는 러너가 필요합니다. Apidog의 apidog run은 이런 용도에 맞는 명령줄 러너입니다. 다른 선택지는 최고의 API 테스트 클라이언트 목록에서 확인할 수 있습니다.
curlie는 HTTPie와 어떻게 다릅니까?
curlie는 HTTPie와 비슷한 문법과 출력 방식을 제공합니다. 차이는 내부 엔진입니다.
- HTTPie: 독립적인 Python 기반 HTTP 클라이언트
- curlie:
curl을 호출하는 Go 기반 래퍼
curl의 동작과 플래그를 그대로 유지하고 싶다면 curlie가 적합합니다. 독립적인 HTTPie 기능을 선호한다면 HTTPie를 선택하면 됩니다.
curlie가 실행하는 실제 요청을 확인할 수 있습니까?
예. -v 옵션을 사용하면 요청/응답 헤더와 상세 정보를 확인할 수 있습니다.
curlie -v GET httpbin.org/get
이는 인증 문제, 리다이렉트, 헤더 누락, 서버 응답 디버깅에 특히 유용합니다.
결론
curlie는 curl의 강력함을 유지하면서 HTTPie처럼 읽기 쉬운 문법과 출력을 제공하는 작은 도구입니다. 터미널에서 엔드포인트를 빠르게 확인하고, JSON 응답을 읽고, 인증과 헤더를 디버깅할 때 유용합니다.
다만 curlie는 대화형 클라이언트입니다. 요청을 저장하고, 공유하고, 어설션을 붙이고, CI에서 반복 실행해야 한다면 별도의 API 테스트 워크플로우가 필요합니다.
Apidog를 다운로드하면 터미널에서 탐색한 요청을 저장된 요청, 환경, 자동화된 테스트로 전환할 수 있습니다. 빠른 실험은 curlie로 처리하고, 반복되어야 하는 검증은 Apidog에서 관리하는 방식이 실무에 적합합니다.


Top comments (0)