Hurl - 커맨드라인에서 HTTP 요청 및 테스트를 위한 텍스트 기반 도구

(github.com/Orange-OpenSource)

3P by GN⁺ 10시간전 | ★ favorite | 댓글 2개

간단한 텍스트 파일 형식으로 HTTP 요청을 실행하고, 여러 요청을 체이닝하거나 값 추출, 응답 본문 및 헤더에 대한 쿼리/검증이 가능한 오픈소스 커맨드라인 툴
REST, SOAP, GraphQL 등 다양한 API 및 HTML/XML/JSON 기반 요청을 지원하며, 데이터 조회와 HTTP 세션 테스트 모두에 적합함
요청 체이닝, 값 캡처, 상태 코드·헤더·본문 등 다양한 검증이 가능하고, Junit, TAP, HTML, JSON 리포트 등 CI/CD 연동 및 자동화에 유리함
Rust로 구현된 단일 실행 파일로 배포되어 설치가 간편하고, 내부적으로는 libcurl 엔진을 사용해 빠른 속도와 강력한 프로토콜 호환성 제공
경쟁 도구 대비 간결한 문법 및 확장성, 다양한 기능을 갖춘 현대적 HTTP 테스트 자동화 도구로 평가받음
커뮤니티 주도 오픈소스로서, 직관적이고 확장 가능한 텍스트 기반 포맷 덕분에 개발자와 DevOps 양쪽 모두에게 높은 활용도를 보임

What's Hurl?

Hurl은 명확하고 직관적인 텍스트 형식으로 HTTP 요청을 작성하여 커맨드라인에서 실행할 수 있는 도구임
여러 요청을 체인처럼 연결, 응답에서 값을 추출하거나 다양한 쿼리(헤더·본문·상태코드 등)를 활용해 복잡한 HTTP 시나리오 테스트 가능함
libcurl 엔진 기반으로 신뢰성 높고 IPv6, HTTP/3 등 최신 프로토콜 지원
데이터 조회, 시나리오 테스트, 성능 측정(응답시간 등) 모두 지원
리포트(Junit, TAP, HTML 등) 생성 및 CI/CD 파이프라인 연동에 최적화
REST, SOAP, GraphQL, HTML, XML, JSON 등 다양한 API에 대응하고, 본문 파싱(예: XPath, JSONPath) 도 지원함
다음은 다른 HTTP 테스트 도구(예: Postman, curl 등) 대비 Hurl만의 중요한 강점:
- 플레인 텍스트로 작성 가능해 버전 관리 및 협업에 용이함
- Rust로 작성된 단일 경량 바이너리 제공, 별도 런타임 불필요
- curl과 동일한 네트워크 엔진(libcurl) 기반으로 신뢰성 및 다양한 프로토콜 지원
- REST, SOAP, GraphQL, HTML 등 다양한 형식 지원 및 복잡한 시나리오 세팅 가능
- CI/CD, 테스트 자동화, 상세 리포트(JUnit, HTML, TAP 등)와의 손쉬운 통합

주요 기능 요약

기본 동작
- Hurl 파일(.hurl) 안에 여러 HTTP 요청을 순차적으로 작성해 실행
- 각 요청의 응답에서 값 추출, 조건 검증, 다음 요청으로의 데이터 전달 가능
- REST/JSON, SOAP/XML, GraphQL, HTML 등 다양한 형식 대응
체이닝 및 변수 활용
- 여러 요청을 한 파일 내에 체인으로 작성
- Captures 구문으로 응답에서 값 추출, 이후 요청에 변수로 주입
- Xpath, JSONPath, 정규표현식, 바디 구조 등을 통한 데이터 추출 및 활용
다양한 요청 및 검증 방식
- 쿼리파라미터, 헤더, 인증 등 다양한 요청 사양 설정 지원
- [Asserts] 구문 또는 암시적 구문으로 상태코드, 바디, 헤더, 쿠키, 응답시간, 해시 등 검증
- XPath, JSONPath 사용, REST/GraphQL/SOAP 과 HTML 콘텐츠도 테스트 가능
- 다중 값 검증, 응답 본문/해시/인증서 속성, 요청/응답 지연, 바이너리 데이터 처리 지원
테스트 리포트와 자동화 연동
- 실행 결과를 텍스트, HTML, JUnit, TAP, JSON 등 다양한 형식의 리포트로 출력
- CI/CD 파이프라인에 손쉽게 통합 가능함
고급 제어 및 유용 기능
- 요청 간 데이터 전달(캡처·변수화)
- 동적 데이터 생성 함수(newUuid, newDate 등)
- 요청별 옵션 커스터마이즈
- 폴링/재시도, 요청 딜레이, 스킵, 비밀 값 마스킹(redact)
- curl과 동일한 옵션 지원(curl 옵션 그대로 사용 가능)
- AWS Sigv4 인증 등 클라우드 전용 기능 내장

사용 예시

단순한 GET/POST 요청 및 다단계 요청 체이닝을 간단한 텍스트 파일로 정의
- sample.hurl 파일 작성하고 , $ hurl sample.hurl 명령 실행으로 해당 요청 일괄 실행

예시:

  GET https://example.org  
  HTTP 200  
  [Captures]  
  csrf_token: xpath "string(//meta[@name='_csrf_token']/@content)"  

  POST https://example.org/login?user=toto&password=1234  
  X-CSRF-TOKEN: {{csrf_token}}  
  HTTP 302

여러 API 엔드포인트 테스트 및 응답 값 비교, 체이닝된 값 사용(토큰 등), 상태코드·헤더·본문 데이터 등 검증 가능

대표적 활용 예

REST/GraphQL/HTML/JSON/SOAP 등 다양한 API 테스트
CSRF 토큰, 인증·인가 등 값 추출 및 재사용
상태 코드, 헤더, 본문 데이터, 쿠키, SSL 인증서 등 정밀 검증
실제 서비스 시나리오(로그인~업무 동작 등) 자동화 및 모니터링
멀티 플랫폼 및 다양한 설치 방법 지원(Linux, macOS, Windows, Docker, npm, Cargo 등)

CLI 주요 옵션

--test: 테스트 모드(요약 및 리포트 출력)
--report-html, --report-json, --report-junit, --report-tap: 다양한 리포트 형식 지원
--parallel, --jobs N: 병렬 실행
--retry, --retry-interval: 자동 재시도/대기
-u, --user: 인증 정보 입력
--variable, --variables-file: 변수 지정
-o, --output: 응답 파일 저장
--json: 실행 결과를 JSON 형식으로 출력

설치 방법

Homebrew, apt, yum, pacman, cargo, choco, scoop, Docker, npm 등 다양한 방법으로 설치 가능
단일 바이너리라 별도 런타임 필요 없음

예:

brew install hurl

또는

cargo install --locked hurl

경쟁 도구 대비 장점

Postman, Insomnia 등 GUI 도구보다 텍스트 기반·버전관리·CI/CD 통합에 더 유리
curl보다 테스트 및 시나리오 실행, 검증, 리포트 자동화에 특화
YAML, JSON 등 복잡한 DSL 대신 직관적인 자체 포맷으로 러닝커브가 낮음

▲

xguru 10시간전 [-]

Hurl 4.0.0 릴리즈
2년전에 4.0 이었는데 현재는 6.1.1 까지 나와있네요.

답변달기

▲

GN⁺ 10시간전 [-]

Hacker News 의견

나는 최근 몇 달 간 hurl을 사용하기 시작함
테스트 스위트 모드와 개별 호출 모드를 모두 쓸 수 있다는 점이 아주 만족스러움
CI에서 HTTP 요청 테스트 스위트를 실행하는 데 사용함
설정 언어는 블록이 직관적이지 않고, 지원하는 assertion 관련 문서도 약간 부족하다고 느낌
전반적으로 도구 자체가 큰 가치를 제공함
POC 작업할 때 인터페이스 테스트를 시작했고, 이 방식이 LLM 기반 개발을 도울 수 있다는 사실을 알게 됨
테스트를 HTTP 메소드에 직접 작성하니, 프로젝트 진화 과정에서 테스트와 구현이 더 유연하게 분리됨
테스트 분리 덕분에 인터페이스와 구현 간 경계가 더 분명해짐
hurl을 도입하기 전엔 서비스 언어의 테스트 프레임워크로 테스트 코드를 작성했지만, hurl 기반 테스트로 '클라이언트 관점'을 엄격하게 지키게 됨
백도어 데이터 접근 같은 것 없이, 인터페이스, 테스트, 구현이 철저히 분리되어 안심할 수 있음
- hurl의 개발자임
  피드백 고마움
  6~7년 전 첫 개발을 시작할 때는 JSON, 그다음에는 YAML 포맷에 도전했지만 점차 새로운 파일 포맷을 직접 만들기로 확신하게 됨
  이게 사용자 입장에서 어색할 수 있다는 점 충분히 이해함
  더 단순한 사례에 단순한 문법을 적용하려 노력했지만, 완벽하진 않을 수 있음
  문서 관련해서 부족하거나 개선점이 있다면 적극적으로 의견을 받고 향상시키길 희망함
Hurl 정말 멋진 도구임
예전에 Python으로 작성된 웹 서비스를 Rust로 포팅했을 때 엄격한 public API 테스트가 큰 도움이 됨
언어에 독립적인 통합 테스트 환경 덕분에 API나 웹사이트는 그대로 두고, 백엔드만 교체해도 됨
Rust에서 Hurl을 쓸 때만의 특별한 이점 하나 더 있음
cargo test와 연동해서 hurl 라이브러리를 바로 쓸 수 있고, .hurl 파일을 그대로 재사용 가능
데모: https://github.com/perrygeo/axum-hurl-test
나는 Hurl을 2023년 9월부터 사용하기 시작함
Runscope를 통해 테스트 스위트를 돌렸었지만, 변경사항이 버전 관리 안 되는 게 너무 불편했음
기초 작업을 거쳐 Hurl로 전환했고, Runscope는 버림
이제 누가 언제 왜 무엇을 바꿨는지 한눈에 확인 가능해져서 만족 중임
- Runscope에서 변경사항이 버전 관리 안 되는 점 정말 싫었음
  우리 팀도 그 문제를 해결하려다 프로젝트가 속도를 잃었음
개념 자체는 좋다고 생각하지만 ‘왜 써야 하나’ 고민하게 됨
나는 Django에서 개발하는데, 프레임워크 내장 테스트 기능이 이미 굉장히 충실함
나만의 백엔드를 모르고 외부에서만 접근하는 도구 도입이 오히려 동기화 부담만 커질 것 같음
이상하면 디버거로 바로 뛰어드는 것도 못 하게 됨
테스트 코드와 백엔드 코드를 명확히 분리해야 한다는 논리도 있긴 하지만, 실질적으로는 관리 비용이 더 커짐
결국 네이티브 테스트 스위트도 돌려야 할 거라서, 외부 도구를 여러 개 병행하는 게 어색하게 느껴짐
단, API가 얼마나 범용적으로 동작하는지 검증하는 용도라면 쓸만할지도 모르겠음
- 왜 내 백엔드를 모르는 도구를 써서 동기화 수고만 늘려야 하냐는 질문에 나도 고민이 많았음
  hurl은 써본 적 없지만, 언어와 무관하게 API를 테스트하는 도구들은 여러 번 썼고 직접 개발 중이기도 함
  이런 도구들이 좋아 보이는 이유는
  - 내부 구현을 몰라도 돼서 오히려 장점임
    인풋-아웃풋만을 검증하는 구조 덕분에 내부 로직에 의존하지 않음
  - 언어 독립적이라서 다른 팀과 공유할 때 (혹은 OpenAPI 사양을 대신해서) 문서처럼 쓸 수 있음
  - API 계약 자체를 테스트하므로 대규모 마이그레이션 때도 재사용 가능
    예를 들면, Perl에서 Go로 public API를 옮길 때 기존 Perl API를 비-회귀 테스트로 삼고, 같은 테스트를 Go API에서 그대로 써서 신뢰도가 높아짐
  - 개발자가 이런 테스트를 짜면 잠시 직접 API의 소비자 입장으로 관점을 바꿀 수 있어서, 더 품질 높은 테스트를 작성할 수 있었음
- Postman 같은 제품의 대체제로 보면 됨
  그냥 간단히 몇 개 http 요청 테스트하려고 electron 기반 무거운 창을 띄울 필요 없음
  curl 스크립트와 Postman 사이 어딘가에 위치해서, 가벼움과 편의성이 동시에 필요한 사람에겐 최적임
- 우리는 ktor 웹 서버에서 spring boot 기반 코드(Java/Kotlin 스택)로 마이그레이션 할 때 Hurl을 활용함
  서버 스택에 관계없이 명세 수준의 테스트 스위트를 운용할 수 있어서, 전환이 매우 수월했음
  또, 도커 이미지를 프로덕션에 쓰는데, 너무 구현에 종속적인 도구 대신 Hurl을 써 통합 테스트를 매우 가볍고 독립적으로 할 수 있었음
샘플 섹션(https://github.com/Orange-OpenSource/hurl?tab=readme-ov-file#samples)이 도구의 장점을 5분만에 파악하고 싶은 사람, 즉 미리 판단하는 경향이 있는 사람에게 매우 설득력 있게 느껴짐
나도 그 부류일 때가 종종 있는데, 정말 인상적임
Hurl의 관리자임
질문이나 피드백 언제든 환영함
- 나를 포함해 주변 개발자들이 많이 쓰는 패턴인데, VS Code나 IDEA의 IDE 확장으로 실행 가능한 ".http" 파일로 테스트를 씀
  예시 포맷은
```
POST http://localhost:8080/api/foo
Content-Type: application/json
{ "some": "body" }
```
  그런 다음 output을 "expected.json" 파일과 1:1로 비교해서 통합 테스트 진행
  이 파일들을 cURL과 bespoke bash 스크립트로 실행하고, jq로 결과를 비교해서 성공/실패를 콘솔에 로그 남김
  Hurl로도 이런 식으로 IDE에서 예시 HTTP 요청과 JSON 파일 기반 기대 결과를 정의할 수 있는지 궁금함
  그리고 Hurl로 폴더 내 여러 파일을 자동 실행할 수 있나 궁금함
- Hurl은 HTTP 레벨 테스트 스위트를 예쁘게, 유지보수 쉽게 작성할 수 있다는 점에서 저평가되어 있음
  이런 툴을 개발해줘서 고마움
- Hurl이라는 이름 선정이 너무 만족스러움
  개발자 센스에 감탄함
- Hurl을 한동안 쓰다가 직접 기여하기도 함
  "include" 기능을 제공할 가능성은 어떻게 되는지 궁금함
- 지속적으로 관리해줘서 고맙다는 인사
  2년 뒤 Hurl의 비전과 미래는 어떻게 보고 있는지 궁금함
이 프로젝트에서 많은 영감을 얻어 직접 HTTP 테스트 도구를 설계함
우린 수백 개 테스트를 빠르게 병렬로 실행할 필요가 있었는데, Hurl이 마음에 든다면 Nap이라는 도구도 흥미로울 수 있음
- 설정(config) 문법이나 내용이 Hurl과 같은지, 어떤 점이 다른지 궁금함
  차이점을 정리해서 보여주는 페이지가 있다면 알려주길 바람
흥미롭게 보임
나는 원래 Vscode-restclient를 오래 썼지만 스크립트 및 CLI 용도로 최근엔 httpyac으로 옮기고 있음
Hurl도 내가 원하는 요건에 맞는지 살펴볼 계획임
테스트 도구를 쓰면서 불편한 점 중 하나는 .http 파일에서 한 요청의 결과값을 다음 요청의 입력으로 참조하는 표준이 아직 없다는 것임
지금까지 써본 세 도구가 모두 방법이 다름
- hurl은 [Captures]
- Vscode-restclient는 변수 선언에서 요청 이름을 참조
- httpyac은 @ref 구문
  각각의 구문이 달라서, 한 도구용으로 작성하면 다른 곳에선 깨짐
  관련 참고 링크
  hurl capture 문서
  Vscode-restclient
  httpyac ref 문서
- 또 다른 파일 포맷을 만들어서 미안함!
  이 문제를 조금이나마 줄일 방법으로 hurlfmt를 활용할 수 있음
  hurlfmt는 Hurl 파일을 JSON으로 내보낼 수 있게 해줌
  이 JSON 결과를 사용해 다른 도구와 상호 변환을 만들 수도 있음
  마법처럼 완벽한 해결책은 아니지만 Hurl에서 다른 포맷으로 옮길 때 조금 도움이 될 수 있음
- Visual Studio Code와 Visual Studio가 모두 .HTTP 파일 지원하지만, 서로 호환 안 됨
  Conway's Law가 실전에서 재현된 사례라며 흥미롭게 보임
약간 유사해 보임
https://marketplace.visualstudio.com/items?itemName=humao.rest-client
이 VS Code 확장은 HTTP 관련 테스팅에 매우 강력함
- 에디터 독립적으로 쓸 수 있다는 점이 정말 큰 차이점임
- IntelliJ도 유사한 기능 있음
  https://jetbrains.com/help/idea/…
- 나도 Hurl을 써봤고 꽤 괜찮다고 느낌
  하지만 최근엔 .http 방식을 더 선호하게 됨
  IntelliJ엔 내장돼 있고, 위에 링크된 플러그인도 있고, CLI에선 httpYac도 써봄
  벤더 락인도 없고, 소스 컨트롤이나 복사&붙여넣기로 공유하기도 매우 쉬움
JVM에서 나는 Karate로 통합 테스트를 진행함
https://github.com/karatelabs/karate
JavaScript를 임의로 포함할 수 있기 때문에, 요청/검증을 유연하게 작성할 수 있음

답변달기

Hurl - 커맨드라인에서 HTTP 요청 및 테스트를 위한 텍스트 기반 도구

What's Hurl?

주요 기능 요약

기본 동작

체이닝 및 변수 활용

다양한 요청 및 검증 방식

테스트 리포트와 자동화 연동

고급 제어 및 유용 기능

사용 예시

대표적 활용 예

CLI 주요 옵션

설치 방법

경쟁 도구 대비 장점

Hacker News 의견