cURL 명령어 빌더

cURL 명령어 빌더는 복잡한 다중 플래그 명령어를 안내형 폼으로 변환해 줍니다. HTTP 메서드를 선택하고, URL을 붙여넣고, 헤더와 쿼리 매개변수를 한 줄에 하나씩 나열하고, 요청 본문을 설정하고, 인증 모드를 선택하면 도구가 그에 맞는 curl 명령어를 자동으로 작성해 줍니다. 입력하는 동안 터미널 스타일의 미리보기가 실시간으로 업데이트되므로 복사하기 전에 명령어가 어떻게 형성되는지 확인할 수 있습니다.

이 도구는 전적으로 브라우저에서 실행됩니다. 입력한 URL을 호출하지 않으며 헤더, 토큰 또는 본문을 저장하지 않습니다. 터미널, CI 단계, Makefile, Postman 임포트 또는 버그 리포트에 바로 붙여넣어 실행할 수 있는 명령어가 제공됩니다.

시각적 빌더가 수작업으로 작성하는 cURL보다 좋은 이유

cURL 명령어 빌더 사용 방법

1. 메서드 선택. GET은 조회, POST는 생성, PUT/PATCH는 수정, DELETE는 삭제를 수행하며, HEAD는 헤더만 가져오고, OPTIONS는 리소스에서 지원되는 메서드를 서버에 질의합니다.
2. URL 입력. https://api.example.com/v1/users와 같은 전체 URL을 입력하는 것이 가장 좋습니다. 스키마를 생략하면 빌더가 자동으로 https://로 정규화합니다.
3. 쿼리 매개변수 나열. 한 줄에 하나씩 key=value 형식으로 입력합니다. 플래그 스타일의 매개변수는 값을 비워두세요. 빌더가 ? 뒤에 이를 추가합니다.
4. 헤더 나열. 한 줄에 하나씩 Header-Name: value 형식으로 입력합니다. 빌더가 중복을 제거하며, 사용자가 직접 설정하지 않은 경우 JSON, 폼, XML 본문에 대해 Content-Type을 자동으로 추가합니다.
5. 본문 유형 선택. 객체를 붙여넣으려면 JSON을, application/x-www-form-urlencoded 필드에는 Form을, 파일 업로드에는 Multipart를 (name=@/path/to/file 사용), 바이트를 그대로 보내려면 Raw를, SOAP 및 유사한 API에는 XML을 선택하세요.
6. 인증 설정. user:password의 경우 Basic을, OAuth 및 JWT 토큰의 경우 Bearer를, API 키는 헤더(예: X-API-Key) 또는 쿼리 매개변수(예: ?api_key=...)로 설정합니다.
7. 플래그 추가. 리디렉션 팔로우, gzip 요청, 응답 헤더 표시, 상세(verbose) 모드, 자동(silent) 모드 또는 로컬 디버깅을 위한 TLS 검사 건너뛰기 등 가장 일반적인 cURL 플래그를 토글합니다.
8. 출력 스타일 선택. 백슬래시로 연결되는 다중 행(Multi-line)은 스크립트에서 읽기에 가장 좋고, 단일 행(One-line)은 복사/붙여넣기에 최적입니다. Windows CMD는 이중 인용 부호와 이중 퍼센트 기호를 사용하며, PowerShell은 PowerShell 별칭과 충돌하지 않도록 curl.exe를 호출합니다.
9. 복사 & 실행. 명령어 복사를 클릭하고 터미널에 붙여넣은 뒤 응답을 확인하세요.

출력 스타일 설명

Multi-line (기본값)은 각 플래그를 후행 백슬래시와 함께 별도의 줄에 배치합니다. 위에서 아래로 읽히기 때문에 문서, 블로그 게시물, 쉘 스크립트에서 사용하기 가장 좋은 형식입니다.

curl \
  -X POST \
  -H 'Content-Type: application/json' \
  --data '{"name":"Jesse"}' \
  'https://api.example.com/v1/users'

One-line은 모든 요소를 공백으로 연결합니다. 터미널에 일회성으로 붙여넣거나 로그 메시지, 채팅 스레드에 공유할 때 완벽합니다.

Windows CMD는 bash 스타일의 단일 인용 부호를 이중 인용 부호로 변환하고(CMD는 단일 인용 부호를 파싱하지 않음), 퍼센트 기호를 이중으로 적용하여 이스케이프함으로써 cmd.exe나 .bat file에서 명령어가 그대로 실행되도록 합니다.

PowerShell은 curl.exe를 명시적으로 호출합니다. PowerShell에서 curl은 인자(argument) 구문이 다른 Invoke-WebRequest의 별칭(alias)이기 때문입니다.

인용 부호: 단일 인용 부호 vs 이중 인용 부호

Linux 및 macOS bash에서는 단일 인용 부호가 가장 안전합니다. bash가 그 내부의 변수나 백틱을 확장하지 않기 때문입니다. 빌더는 값 내부의 문자 그대로의 '를 이스케이프 시퀀스인 '\''로 변환하여 양 끝의 단일 인용 부호가 여전히 매칭되도록 유지합니다.

이중 인용 부호는 bash가 이스케이프 규칙을 유지하면서도 다른 방법으로는 이스케이프하기 어려운 인용 부호 문자를 허용하고자 할 때 적합합니다. 빌더는 이중 인용 부호 내부의 $, `, \\, "를 이스케이프 처리하여 값이 변경 없이 전송되도록 합니다.

인증 패턴

Basic 인증은 Authorization: Basic base64(user:password)를 전송합니다. cURL 플래그 -u user:password가 인코딩을 대신 수행해 줍니다. 일반 HTTP 상의 Basic 인증은 쉽게 가로채어질 수 있으므로 반드시 HTTPS를 사용하세요.

Bearer 토큰 (OAuth 2.0, JWT, GitHub 개인 액세스 토큰 등)은 Authorization: Bearer <token>를 추가합니다. 토큰을 비밀번호처럼 취급하세요. 스크린샷, Slack 메시지 또는 CI 로그에 유출된 경우 즉시 토큰을 교체하십시오.

API 키는 헤더(X-API-Key, X-RapidAPI-Key) 또는 쿼리 매개변수(?api_key=...)에 위치할 수 있습니다. 역방향 프록시(reverse proxy) 및 브라우저 기록에 URL이 기록되는 경우가 많으므로 일반적으로 헤더가 더 안전합니다.

자주 사용되는 HTTP 메서드 모아보기

• GET — 리소스를 조회합니다. 안전하고 멱등성(idempotent)을 가져야 합니다.
• POST — 새 리소스를 생성하거나 GET 시맨틱에 맞지 않는 데이터를 제출합니다. 멱등성을 가지지 않습니다.
• PUT — 지정된 URL의 리소스를 대체합니다. 멱등성을 가집니다.
• PATCH — 리소스를 부분 수정합니다. API에 따라 JSON Patch (RFC 6902) 또는 merge patch (RFC 7396)를 사용합니다.
• DELETE — 리소스를 삭제합니다. 멱등성을 가집니다.
• HEAD — GET과 유사하지만 서버가 헤더만 반환합니다. 본문을 다운로드하지 않고 캐시 신선도나 콘텐츠 길이를 테스트할 때 사용합니다.
• OPTIONS — 허용된 메서드를 서버에 질의하고 CORS 메타데이터를 읽습니다.

생성된 명령어 문제 해결하기

• SSL 인증서 오류. 신뢰할 수 있는 호스트나 로컬 서버에 대해서만 --insecure를 활성화하세요. 운영 환경 디버깅 시에는 --cacert를 사용하여 cURL이 올바른 CA 번들을 가리키도록 하는 것이 좋습니다.
• 빈 응답 또는 정지(hang) 현상. 상세 모드인 -v와 함께 실행하여 TLS 핸드셰이크와 헤더를 확인하세요. 연결(connect) 단계에서 멈추는 것은 대개 서버에 도달할 수 없음을 의미하며, 전송(transfer) 단계에서 멈추는 것은 서버가 요청을 수락했으나 처리가 느린 것을 의미합니다.
• 415 Unsupported Media Type. 서버가 다른 Content-Type을 기대하고 있습니다. 빌더는 직접 설정하지 않은 경우 JSON, 폼 및 XML 본문에 맞는 올바른 값을 자동으로 추가합니다.
• 401 vs 403. 401은 자격 증명이 누락되었거나 유효하지 않음을 의미합니다(Bearer 토큰 재확인). 403은 자격 증명은 유효하지만 사용자에게 권한이 없음(스코프 확인)을 의미합니다.
• 413 Payload Too Large. 일부 업스트림 서버는 본문 크기를 1~10 MB로 제한합니다. 청크형(chunked) 업로드 엔드포인트나 스트리밍 사용을 고려해 보세요.

보안 및 개인정보 보호 참고 사항

• 이 빌더는 클라이언트 사이드에서 렌더링됩니다. 입력한 URL로 아무것도 전송되지 않으며 결과는 명령어 텍스트로만 존재합니다.
• 운영 환경의 토큰을 붙여넣지 마십시오. 필요한 경우 생성된 명령어를 민감한 정보로 취급하여 공개 저장소에 커밋하거나, 봇이 있는 채팅방에 붙여넣거나, 공개 이슈(issue)에 첨부하지 않도록 하세요.
• 스크립트에서는 환경 변수를 사용하는 것이 좋습니다. 토큰을 하드코딩하는 대신 -H 'Authorization: Bearer '"$TOKEN"과 같이 작성하세요. 단일 인용 부호를 닫은 후 변수 주변을 이중 인용 부호로 감싸면 bash가 변수를 확장할 수 있습니다.

자주 묻는 질문(FAQ)

Chrome DevTools에서 cURL 명령어를 가져올(import) 수 있나요?

이 빌더는 반대 방향으로 동작합니다. 즉, 폼에서 cURL 명령어를 생성합니다. 반대로 작업하려면 DevTools에서 cURL로 복사한 후 전용 cURL 파서 도구를 사용하세요.

JSON 본문을 미리 이스케이프해야 하나요?

아닙니다. JSON을 표시되어야 하는 형태 그대로 붙여넣으세요. 빌더가 인용 부호 처리를 자동으로 수행하므로 본문이 수정 없이 서버에 도달합니다.

-d와 --data-urlencode의 차이점은 무엇인가요?

-d는 본문 바이트를 그대로 전송합니다. --data-urlencode는 각 필드를 퍼센트 인코딩하며, 이는 브라우저가 HTML 폼을 전송할 때와 동일합니다. 빌더는 Form 본문 유형에는 --data-urlencode를 사용하고, JSON / raw / XML에는 --data를 사용합니다.

파일을 업로드하려면 어떻게 해야 하나요?

Multipart form-data를 선택하고 avatar=@/Users/jesse/photo.png와 같이 한 줄을 추가하세요. @ 기호는 cURL에 파일 내용을 읽도록 지시합니다.

cURL에서 “Argument list too long”이라는 오류가 발생하는 이유는 무엇인가요?

본문이 쉘의 argv 제한에 비해 너무 크기 때문입니다. 대신 --data @body.json을 사용하여 본문을 파일로 전달하세요.

이 도구는 HTTP/2 및 HTTP/3를 지원하나요?

로컬 cURL이 올바른 라이브러리와 함께 컴파일된 경우, cURL 자체적으로 --http2 및 --http3를 모두 지원합니다. 생성된 명령어에 임의로 두 플래그 중 하나를 수동으로 추가할 수 있습니다.