🌀 cURL ⇄ fetch / axios / wget 변환
cURL 명령을 다양한 언어 및 라이브러리의 HTTP 요청 코드로 변환합니다. 헤더, 쿠키, 본문 모두 유지.
지원되는 cURL 옵션
🔗 관련 도구
📖 자주 걸리는 지점
cURL 명령을 fetch / axios / Python requests / PHP / Go / Rust / wget / HTTPie 등 13 종류의 코드로 변환합니다. 헤더·쿠키·본문을 그대로 유지하며 처리는 브라우저 안에서 끝납니다. 「그대로 유지한다」는 것이 이 도구의 가치이자 동시에 최대의 주의점입니다 — 브라우저의 DevTools 에서 복사한 cURL 에는 당신의 로그인 세션이 그대로 들어 있습니다. 그리고 브라우저가 보내던 헤더의 상당수는 코드에서 보내야 할 것이 아닙니다. 변환은 성공하는데 그대로 붙이면 동작하지 않는 것은 대개 이 둘이 원인입니다.
| 사례 | 무슨 일이 일어나는가 | 어떻게 하면 되는가 |
|---|---|---|
| 복사한 cURL 에 인증 정보가 그대로 들어 있다 | DevTools 의 Copy as cURL 은 그 요청이 실제로 보낸 모든 헤더를 써 냅니다 — Cookie 헤더에는 세션 ID 가, Authorization 에는 액세스 토큰이 그대로 평문으로 들어 있습니다. 이것은 「당신으로 로그인할 수 있는 문자열」입니다. 위험한 것은 이 cURL 이 공유되기 쉬운 형태를 하고 있다는 점입니다 — 재현 절차로 티켓에 붙이고, Slack 으로 동료에게 보내고, 블로그 글에 싣고, AI 에게 「왜 안 되냐」고 묻기 위해 붙여 넣습니다. 그 어느 것이든 유효한 세션을 밖으로 내보내는 행위입니다. 게다가 겉보기에는 긴 명령의 일부로만 보이므로 붙이는 쪽이 알아채지 못합니다. |
공유하기 전에 Cookie 와 Authorization 행을 지우세요. 이 페이지의 처리는 브라우저 안에서 끝나므로 여기에 붙이는 것 자체는 안전하지만 생성된 코드에도 같은 값이 그대로 포함됩니다 — 복사해서 다른 곳에 붙이는 순간 같은 문제가 되살아납니다. 실무로는 API 를 호출하는 코드를 쓴다면 우선 인증만 스스로 다시 구성하세요 — 브라우저의 세션 쿠키가 아니라 그 API 용으로 발급한 API 키나 서비스 계정을 쓰는 것이 올바른 형태입니다. 이미 공유해 버렸다면 그 세션을 무효화 (로그아웃 또는 토큰 로테이션) 하세요 — 「아마 아무도 안 봤겠지」는 대처가 되지 않습니다. |
| 브라우저의 헤더를 그대로 코드에 가져온다 | DevTools 가 복사하는 헤더에는 API 와 무관한 브라우저 사정의 것이 많이 포함됩니다 — sec-ch-ua·sec-fetch-mode·Accept-Encoding·Connection·Content-Length·Host·Referer 등. 이것들은 HTTP 클라이언트가 자동으로 관리하는 영역이라 손으로 지정하면 망가집니다 — Content-Length 를 고정값으로 가져오면 본문을 바꾼 순간 불일치가 되고, Accept-Encoding: gzip 을 명시하면 라이브러리에 따라 압축을 풀지 않고 날 바이트열이 돌아옵니다. 브라우저에서 돌리는 경우에는 나아가 Origin·Referer·Cookie 등은 금지 헤더이므로 fetch 가 조용히 버립니다 — 오류가 되지 않으므로 지정한 셈인 채로 동작이 달라집니다. |
변환한 뒤 헤더를 깎아 최소 구성으로 만드세요. 실제로 필요한 것은 대개 메서드·URL·Content-Type·인증·본문 다섯 가지뿐입니다. 깎고 나서 돌려 보고, 안 되는 것만 되돌린다 — 이 순서로 하면 어느 헤더가 정말 필요한지 알 수 있습니다. User-Agent 만은 예외적으로 필요할 때가 있습니다 (기본값을 튕겨 내는 API 가 있기 때문). 그리고 브라우저에서 돌린다면 CORS 를 먼저 확인하세요 — cURL 은 동일 출처 정책 바깥에 있으므로 cURL 로 성공한 요청이 fetch 에서 실패하는 것은 정상입니다. 이것은 코드의 문제가 아니라 서버 쪽 Access-Control-Allow-Origin 의 문제라 변환을 아무리 고쳐도 해결되지 않습니다. |
| 셸의 따옴표 때문에 본문이 달라진다 | cURL 명령은 셸의 구문 위에 얹혀 있으므로 같은 명령이라도 셸에 따라 도착하는 내용이 달라집니다. Windows 의 cmd.exe 는 작은따옴표를 인용부호로 다루지 않으므로 -d '{"a":1}' 는 따옴표 기호까지 서버에 도착합니다. PowerShell 5.1 에서는 curl 이 Invoke-WebRequest 의 별칭이라 애초에 cURL 의 옵션이 통하지 않습니다. 비 ASCII 텍스트를 포함한 본문은 더 까다로워서 Windows 의 bash 에서 보내면 환경에 따라 UTF-8 이 아니라 로컬 코드페이지로 보내집니다 — 서버 쪽에서는 글자 깨짐으로 나타나지만 명령은 성공합니다. 또 하나, -d 는 값의 첫 글자가 @ 이면 파일명으로 해석하고 게다가 줄바꿈을 제거합니다 — 정형된 JSON 을 붙이면 한 줄로 뭉개집니다. |
본문은 파일에 두고 --data-binary @body.json 으로 보내세요. --data-binary 는 줄바꿈도 문자 인코딩도 그대로 보내므로 셸의 해석이 끼어들 여지가 없습니다 — 비 ASCII 텍스트를 포함한 JSON 을 테스트할 때는 이것이 유일하게 확실한 방법입니다. Windows 에서는 PowerShell 에서도 curl.exe 라고 확장자까지 쓰면 진짜 cURL 이 기동합니다. 애초에 cURL 은 「한 번 돌려서 확인하기」 위한 도구이지 반복 실행하는 절차서에는 맞지 않습니다 — 절차로 남긴다면 변환한 코드 쪽을 리포지터리에 두세요. 코드라면 차분을 읽을 수 있고 리뷰할 수 있고 테스트할 수 있습니다. |
변환되는 것은 「한 번의 요청」뿐입니다. 실제 API 이용에 필요한 것의 상당수는 cURL 명령에 찍혀 있지 않습니다 — 재시도, 타임아웃, 레이트 리밋 대응, 페이징, 오류 처리, 커넥션 재사용. 생성된 코드를 그대로 프로덕션에 두면 이것들이 전부 빠진 상태가 됩니다. 특히 타임아웃은 기본값이 언어마다 크게 다르고 무한히 기다리는 것도 있으므로 반드시 명시적으로 설정하세요. 또 하나, cURL 은 기본적으로 리다이렉트를 따르지 않습니다 (-L 이 필요) 만 많은 HTTP 라이브러리는 기본적으로 따릅니다 — 같은 URL 인데 거동이 달라 보이는 단골 원인입니다. 그리고 -k / --insecure 가 붙은 cURL 을 변환한 경우에는 주의가 필요합니다 — 이것은 TLS 인증서 검증을 무효화하는 옵션이며 그 상태의 코드를 프로덕션에 가져가면 중간자 공격에 무방비가 됩니다. 인증서 오류는 검증을 끄지 말고 원인을 고치세요.
📖 사용법
-
1
DevTools에서 복사Chrome/Firefox DevTools의 Network 탭에서 요청을 우클릭 → Copy as cURL 선택.
-
2
cURL 붙여넣기cURL 명령을 붙여넣습니다.
-
3
대상 언어 선택13가지 대상 중에서 선택하면 헤더·쿠키·본문이 유지된 채 변환됩니다.
❓ 자주 묻는 질문
DevTools의 Copy as cURL과 호환되나요?
Python에서 urllib로 출력하고 싶어요
-F 옵션은 어떻게 처리되나요?
Authorization 토큰은 어떻게 관리해야 하나요?
🐛 이 도구에서 문제가 발생했나요?
무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.
보고 감사합니다!
운영자에게 전달되었습니다. 개선에 사용됩니다.