API 응답이 이상할 때? curl 명령어 실전 디버깅

분명 `curl`로 API 요청을 보냈고 응답 코드는 200 OK인데, 기대했던 JSON 데이터 대신 엉뚱한 HTML 페이지가 오거나, `-d` 옵션으로 JSON 데이터를 분명히 넘겼는데 서버에서는 아무것도 받지 못했다고 하소연할 때가 있죠.

이런 문제는 요청 헤더, 데이터 형식, 혹은 서버의 응답 처리 방식에 대한 오해에서 비롯됩니다.

이 글에서는 `curl` 명령어를 활용해 이러한 API 통신 문제를 정확히 진단하고 해결하는 실질적인 디버깅 노하우를 단계별로 제시합니다.

이 글의 핵심

– `curl` 디버깅은 정확한 요청 헤더와 데이터 형식을 이해하는 것부터 시작합니다.
– `Content-Type`과 데이터 직렬화 방식이 서버 응답을 결정하는 핵심 요소입니다.
– `-v`, `–trace-ascii` 옵션을 통해 `curl` 요청의 모든 과정을 투명하게 확인할 수 있습니다.

💡 한 줄 답변

API 응답이 예상과 다를 때, `curl` 명령어를 활용해 실제 API 요청을 분석하고 문제를 진단하는 실전 디버깅 팁을 알아보세요.

📅 2026년 05월 29일·⏱ 11분 읽기·✏️ Mebys Blog

200 OK, 하지만 엉뚱한 응답: 문제를 진단하는 첫걸음

API 테스트 중에 `curl`이 200 OK를 반환했지만 실제 응답 본문이 예상과 전혀 다른 HTML인 경우가 종종 발생합니다. 이는 서버가 요청을 성공적으로 ‘처리’했다고 판단했을 뿐, 우리가 의도한 API 엔드포인트가 아닌 다른 곳으로 라우팅되었거나, 인증 실패 등으로 인해 로그인 페이지 같은 HTML을 반환했을 가능성이 큽니다. 서버 입장에서는 “페이지를 성공적으로 보여줬다”는 의미로 200 OK를 보낸 것이죠.

이러한 상황에서는 먼저 요청을 보낸 URL이 정확한지 확인해야 합니다. 개발 환경과 운영 환경의 API 엔드포인트가 다르거나, 오타가 있을 수 있습니다. 다음으로, 서버가 특정 API 호출에 필요한 인증 토큰이나 세션 정보를 요구하는지 점검해야 합니다. 인증되지 않은 요청은 기본 HTML 페이지로 리디렉션되거나 오류 페이지를 반환하는 경우가 많기 때문입니다.

주의
200 OK는 “요청이 성공했다”는 일반적인 응답일 뿐, “데이터가 예상대로 도착했다”는 의미는 아닙니다. 항상 응답 본문을 면밀히 분석하여 실제 데이터가 맞는지 확인해야 합니다. 특히 웹 애플리케이션 프레임워크는 인증 실패 시 로그인 페이지를 200 OK와 함께 반환하기도 합니다.

`curl` 요청 헤더: 서버가 당신의 요청을 이해하게 하는 방법

API 통신에서 요청 헤더는 매우 중요합니다. 서버에게 어떤 형식의 데이터를 보내고 있는지, 어떤 형식의 응답을 기대하는지 알려주는 역할을 합니다. 가장 흔한 실수는 `Content-Type` 헤더를 누락하거나 잘못 지정하는 것입니다. 예를 들어, JSON 데이터를 보내면서 `Content-Type: application/json`을 설정하지 않으면 서버는 데이터를 일반 텍스트나 알 수 없는 형식으로 인식하여 처리하지 못할 수 있습니다.

인증이 필요한 API의 경우 `Authorization` 헤더를 통해 토큰을 전달해야 합니다. `curl` 명령어에서 헤더를 추가할 때는 `-H` (또는 `–header`) 옵션을 사용합니다. 여러 개의 헤더를 보낼 때는 `-H` 옵션을 여러 번 사용하면 됩니다. 예를 들어, 인증 토큰과 JSON 콘텐츠 타입을 동시에 보내려면 두 개의 `-H` 옵션을 명령줄에 추가합니다.

  1. 인증 토큰 추가 — `curl -H “Authorization: Bearer YOUR_TOKEN” …`와 같이 Bearer 토큰을 포함하여 요청을 보냅니다. 대소문자에 유의하며 정확한 토큰 값을 사용해야 합니다.
  2. 콘텐츠 타입 지정 — `curl -H “Content-Type: application/json” -d ‘{“key”:”value”}’ …`처럼 데이터 형식에 맞는 `Content-Type`을 지정하여 서버가 데이터를 올바르게 파싱하도록 돕습니다.
  3. 다른 헤더 확인 — 때로는 `Accept` 헤더를 통해 서버가 특정 응답 형식을 강제하거나, 사용자 에이전트(`User-Agent`) 같은 다른 헤더가 필요할 수 있습니다. API 문서에서 요구하는 헤더를 꼼꼼히 확인하세요.

JSON 데이터 전송: `-d` 옵션의 오해와 올바른 사용법

`curl`로 JSON 데이터를 전송할 때 `-d` (또는 `–data`) 옵션을 자주 사용합니다. 하지만 이 옵션의 동작 방식에 대한 오해가 많습니다. 기본적으로 `-d` 옵션은 `Content-Type`을 `application/x-www-form-urlencoded`로 설정하고 데이터를 URL 인코딩하여 전송합니다. 따라서 JSON 데이터를 보낼 때는 이 기본 동작을 재정의해야 합니다.

JSON 데이터를 정확히 보내기 위해서는 `-H “Content-Type: application/json”` 헤더를 명시적으로 추가하고, `-d` 옵션으로 JSON 문자열을 전달해야 합니다. 이때 JSON 문자열은 작은따옴표로 감싸는 것이 일반적입니다. 작은따옴표 안에 큰따옴표가 포함된 JSON 구조를 그대로 유지하기 위해서입니다. 예를 들어, `{“name”: “test”, “age”: 30}` 같은 JSON 데이터는 `'{“name”: “test”, “age”: 30}’` 형태로 전달해야 합니다.

구분 잘못된 사용 (흔한 실수) 올바른 사용 (JSON 전송)
명령어 예시 curl -X POST -d '{"user":"john"}' https://api.example.com/data curl -X POST -H "Content-Type: application/json" -d '{"user":"john"}' https://api.example.com/data
Content-Type application/x-www-form-urlencoded (기본값) application/json (명시적 지정)
서버 인식 `user=john`과 같은 폼 데이터로 인식하거나, JSON 파싱 실패 정상적인 JSON 데이터로 인식 및 처리

`curl` 디버깅 심화: 트레이스 옵션으로 통신 과정 파헤치기

`curl`은 강력한 디버깅 옵션을 제공하여 HTTP 요청과 응답의 모든 세부 사항을 확인할 수 있게 해줍니다. `-v` (또는 `–verbose`) 옵션은 `curl`이 수행하는 모든 단계, 즉 DNS 확인, TCP 연결, SSL 핸드셰이크, 요청 헤더, 서버 응답 헤더 등을 상세하게 출력합니다. 이 정보는 API 요청이 어느 단계에서 실패했는지, 또는 예상치 못한 응답이 오는 이유를 파악하는 데 결정적인 단서를 제공합니다.

더 심층적인 디버깅이 필요하다면 `–trace` 또는 `–trace-ascii` 옵션을 사용할 수 있습니다. 이 옵션들은 전체 통신 내용을 파일로 저장하여 후속 분석을 가능하게 합니다. `–trace`는 바이너리 형식으로, `–trace-ascii`는 사람이 읽을 수 있는 아스키 형식으로 저장합니다. 특히 `–trace-ascii`는 HTTP 헤더는 물론, 요청 본문과 응답 본문까지 정확히 확인할 수 있어 `curl`이 실제로 어떤 데이터를 서버로 보냈고, 서버가 어떤 데이터를 반환했는지 한눈에 파악하는 데 매우 유용합니다. 복잡한 문제를 해결할 때 10분 이상 시간을 절약해 줄 수 있습니다.

참고
`-v` 옵션을 사용하면 요청과 응답 헤더 앞에 `>` (요청) 또는 `<` (응답) 기호가 붙어 쉽게 구분할 수 있습니다. 예를 들어, 요청 헤더 `Content-Type: application/json`은 `> Content-Type: application/json`으로 표시됩니다. `–trace-ascii debug.log`처럼 사용하면 `debug.log` 파일에 모든 통신 기록이 남습니다. 이 로그를 분석하면 요청 데이터의 오작동, 응답 데이터의 불일치 등 80% 이상의 문제를 해결할 수 있습니다.
정리

`curl` API 테스트에서 예상치 못한 응답을 만났을 때, 당황하지 말고 요청 URL, 헤더, 데이터 형식을 꼼꼼히 점검해야 합니다. 특히 `Content-Type` 헤더와 `-d` 옵션의 올바른 사용법을 숙지하는 것이 중요합니다. `-v` 및 `–trace-ascii` 옵션을 활용하면 `curl`이 전송하고 수신하는 모든 데이터를 명확히 파악하여 문제의 원인을 신속하게 찾아낼 수 있습니다.

지금 바로 적용해 보세요.

참고 자료

  • curl man page — curl 명령어의 모든 옵션과 자세한 설명이 담긴 공식 문서입니다.
  • HTTP/1.1 Header Field Definitions — HTTP 헤더 필드에 대한 표준 정의를 확인할 수 있습니다.
  • JSON 소개 — JSON 데이터 형식에 대한 기본적인 이해를 돕습니다.

동영상으로 보는 curl 명령어 API 테스트

글로 충분하지 않다면 관련 영상을 함께 보세요. 클릭하면 YouTube에서 검색 결과로 이동합니다.

▶ YouTube에서 “curl 명령어 API 테스트” 영상 보기

자주 묻는 질문

Q. API 응답이 이상할 때, curl로 응답의 모든 상세 정보(HTTP 상태 코드, 헤더, 본문)를 어떻게 확인할 수 있나요?

A. `curl -v ` 명령어를 사용하면 HTTP 요청 및 응답의 상세 헤더, 본문은 물론 HTTP 상태 코드까지 포함한 모든 통신 과정을 자세히 볼 수 있습니다. 이를 통해 응답이 왜 이상한지, 예를 들어 4xx나 5xx 에러가 발생하는지 명확히 파악할 수 있습니다.

Q. 특정 데이터를 JSON이나 폼 데이터 형식으로 API에 전송해야 할 때, curl 명령어는 어떻게 사용하나요?

A. JSON 데이터는 `-H “Content-Type: application/json” -d ‘{“key”: “value”}’` 형태로, 폼 데이터는 `-d “param1=value1&param2=value2″` 형태로 `curl -X POST`와 함께 사용합니다. 이렇게 명시적으로 요청 본문과 헤더를 설정하여 API가 기대하는 형식에 맞춰 정확한 데이터를 보낼 수 있습니다.

Q. 인증 토큰이나 특정 커스텀 헤더를 포함하여 API 요청을 보내려면 curl 명령어를 어떻게 구성해야 하나요?

A. `-H “Header-Name: Header-Value”` 옵션을 사용하여 사용자 정의 헤더를 쉽게 추가할 수 있습니다. 예를 들어, 인증 토큰을 포함하려면 `-H “Authorization: Bearer YOUR_TOKEN”`과 같이 명령어를 구성하여 안전하게 API에 인증 정보를 전달할 수 있습니다.

Q. API 요청 시 예상치 못한 리다이렉트가 발생하거나 타임아웃 문제를 겪을 때, curl로 어떻게 디버깅할 수 있나요?

A. 예상치 못한 리다이렉트는 `-L` 옵션을 사용하여 curl이 리다이렉트를 자동으로 따라가도록 하여 최종 응답을 확인할 수 있습니다. 또한, `–max-time <초>` 옵션으로 최대 대기 시간을 설정하여 API 호출이 너무 오래 걸리거나 응답이 없는 타임아웃 문제를 진단하고 방지할 수 있습니다.


댓글 남기기

Mebys Blog에서 더 알아보기

지금 구독하여 계속 읽고 전체 아카이브에 액세스하세요.

계속 읽기