# Hurl - 커맨드라인에서 HTTP 요청 및 테스트를 위한 텍스트 기반 도구 > Clean Markdown view of GeekNews topic #21565. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=21565](https://news.hada.io/topic?id=21565) - GeekNews Markdown: [https://news.hada.io/topic/21565.md](https://news.hada.io/topic/21565.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-06-21T09:48:01+09:00 - Updated: 2025-06-21T09:48:01+09:00 - Original source: [github.com/Orange-OpenSource](https://github.com/Orange-OpenSource/hurl) - Points: 27 - Comments: 3 ## Summary **오픈소스 커맨드라인 툴**인 Hurl은 **간결한 텍스트 포맷**으로 각종 HTTP 요청, 체이닝, 값 추출 및 자동화 검증을 지원하여 **REST, SOAP, GraphQL 등 다양한 API 테스트**에 적합합니다. **단일 Rust 바이너리**로 설치가 간편하고, **libcurl 엔진**을 통해 **신속성과 최신 프로토콜 호환성**을 제공합니다. **CI/CD 파이프라인, 리포트 자동화, 플레인 텍스트 기반 협업 및 버전관리**등에서 경쟁 도구 대비 탁월한 장점을 보유합니다. ## Topic Body - **간단한 텍스트 파일 형식으로 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` 명령 실행으로 해당 요청 일괄 실행 - 예시: ```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 등** 다양한 방법으로 설치 가능 - **단일 바이너리라 별도 런타임 필요 없음** - 예: ```shell brew install hurl ``` 또는 ```shell cargo install --locked hurl ``` ### 경쟁 도구 대비 장점 - **Postman, Insomnia 등 GUI 도구보다 텍스트 기반·버전관리·CI/CD 통합에 더 유리** - **curl보다 테스트 및 시나리오 실행, 검증, 리포트 자동화에 특화** - **YAML, JSON 등 복잡한 DSL 대신 직관적인 자체 포맷으로 러닝커브가 낮음** ## Comments ### Comment 40975 - Author: seunggi - Created: 2025-07-04T14:35:54+09:00 - Points: 1 Bruno - 빠르고 Git 친화적인 오픈소스 API 클라이언트(Postman 대체제) https://news.hada.io/topic?id=13730 ### Comment 40460 - Author: xguru - Created: 2025-06-21T10:36:50+09:00 - Points: 1 [Hurl 4.0.0 릴리즈](https://news.hada.io/topic?id=9562) 2년전에 4.0 이었는데 현재는 6.1.1 까지 나와있네요. ### Comment 40449 - Author: neo - Created: 2025-06-21T09:48:03+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=44324592) - 나는 최근 몇 달 간 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](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](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](https://naprun.dev)이라는 도구도 흥미로울 수 있음 - 설정(config) 문법이나 내용이 Hurl과 같은지, 어떤 점이 다른지 궁금함 차이점을 정리해서 보여주는 페이지가 있다면 알려주길 바람 - 흥미롭게 보임 나는 원래 Vscode-restclient를 오래 썼지만 스크립트 및 CLI 용도로 최근엔 httpyac으로 옮기고 있음 Hurl도 내가 원하는 요건에 맞는지 살펴볼 계획임 테스트 도구를 쓰면서 불편한 점 중 하나는 `.http` 파일에서 한 요청의 결과값을 다음 요청의 입력으로 참조하는 표준이 아직 없다는 것임 지금까지 써본 세 도구가 모두 방법이 다름 - hurl은 [Captures] - Vscode-restclient는 변수 선언에서 요청 이름을 참조 - httpyac은 @ref 구문 각각의 구문이 달라서, 한 도구용으로 작성하면 다른 곳에선 깨짐 관련 참고 링크 [hurl capture 문서](https://hurl.dev/docs/capturing-response.html) [Vscode-restclient](https://github.com/Huachao/vscode-restclient) [httpyac ref 문서](https://httpyac.github.io/guide/metaData.html#ref-and-forceref) - 또 다른 파일 포맷을 만들어서 미안함! 이 문제를 조금이나마 줄일 방법으로 `hurlfmt`를 활용할 수 있음 hurlfmt는 Hurl 파일을 JSON으로 내보낼 수 있게 해줌 이 JSON 결과를 사용해 다른 도구와 상호 변환을 만들 수도 있음 마법처럼 완벽한 해결책은 아니지만 Hurl에서 다른 포맷으로 옮길 때 조금 도움이 될 수 있음 - Visual Studio Code와 Visual Studio가 모두 .HTTP 파일 지원하지만, 서로 호환 안 됨 Conway's Law가 실전에서 재현된 사례라며 흥미롭게 보임 - 약간 유사해 보임 [https://marketplace.visualstudio.com/items?itemName=humao.rest-client](https://marketplace.visualstudio.com/items?itemName=humao.rest-client) 이 VS Code 확장은 HTTP 관련 테스팅에 매우 강력함 - 에디터 독립적으로 쓸 수 있다는 점이 정말 큰 차이점임 - IntelliJ도 유사한 기능 있음 [https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html](https://www.jetbrains.com/help/idea/http-client-in-product-c...) - 나도 Hurl을 써봤고 꽤 괜찮다고 느낌 하지만 최근엔 .http 방식을 더 선호하게 됨 IntelliJ엔 내장돼 있고, 위에 링크된 플러그인도 있고, CLI에선 httpYac도 써봄 벤더 락인도 없고, 소스 컨트롤이나 복사&붙여넣기로 공유하기도 매우 쉬움 - JVM에서 나는 Karate로 통합 테스트를 진행함 [https://github.com/karatelabs/karate](https://github.com/karatelabs/karate) JavaScript를 임의로 포함할 수 있기 때문에, 요청/검증을 유연하게 작성할 수 있음