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 프롬프트에서는 퍼센트 기호 하나를 사용하세요.

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를 모두 지원합니다. 생성된 명령어에 임의로 두 플래그 중 하나를 수동으로 추가할 수 있습니다.