n8n에 원하는 서비스용 노드가 없다고 해서 자동화를 포기할 필요는 없습니다. 서비스가 REST API를 제공한다면 HTTP Request 노드로 직접 요청을 보낼 수 있습니다. 다만 API 호출은 단순히 URL을 붙여 넣는 작업이 아닙니다. 어떤 데이터를 읽거나 만들려는지, 인증은 어떻게 하는지, 실패했을 때 무엇을 확인할지를 함께 정해야 합니다.
이 글에서는 실제 업무 데이터나 비밀 키를 쓰지 않고, HTTP Request 노드를 이해하는 안전한 첫 테스트 순서를 정리합니다. 첫 목표는 “API를 연결했다”가 아니라 요청과 응답을 읽을 수 있다가 되는 것입니다.
HTTP Request 노드는 언제 쓰나
n8n의 앱 전용 노드가 필요한 기능을 지원하지 않거나, 특정 서비스의 API를 직접 호출해야 할 때 사용합니다. HTTP Request 노드는 REST API에 요청을 보내고 응답을 받는 범용 노드입니다. 설정은 크게 Method, URL, Authentication, Query Parameters, Headers, Body의 다섯 요소로 나눠 생각하면 됩니다.
| 항목 | 의미 | 처음에 확인할 점 |
|---|---|---|
| Method | 요청의 목적 | 데이터 조회는 보통 GET, 생성은 보통 POST인지 API 문서에서 확인 |
| URL | 호출할 정확한 주소 | 도메인만이 아니라 endpoint 경로까지 일치하는지 확인 |
| Authentication | 요청자 확인 방식 | API 키, OAuth, Basic Auth 등 서비스가 요구하는 방식 확인 |
| Query / Headers | 필터와 요청 정보 | 키 이름과 값의 위치를 API 문서 그대로 맞춤 |
| Body | 전송할 데이터 | POST·PATCH에서 JSON 형식과 필수 필드를 확인 |
가장 안전한 첫 테스트: GET 요청 하나만 만들기
처음에는 데이터를 생성하거나 메일을 보내는 POST 요청보다, 읽기 전용 GET 요청으로 시작하세요. Manual Trigger와 HTTP Request 노드 두 개만 연결하면 됩니다. 테스트할 API의 공식 문서에 공개된 샘플 endpoint가 있다면 그것을 사용하고, 로그인·API 키가 필요한 실제 업무 서비스는 아직 연결하지 않는 편이 좋습니다.
- 새 워크플로우에서 Manual Trigger를 추가합니다.
- 그 뒤에 HTTP Request 노드를 추가합니다.
- Method를 GET으로 선택합니다.
- API 문서에 나온 읽기 전용 endpoint를 URL에 정확히 입력합니다.
- 인증이 필요 없는 공개 테스트 API일 때만 Authentication을 None으로 둡니다.
- Execute step을 누르고 출력 패널에서 응답 내용을 확인합니다.
응답이 JSON으로 보인다면 먼저 필드 이름과 값의 구조를 읽어 보세요. 다음 노드에서 필요한 값이 어느 위치에 있는지 모른 채 표현식부터 만들면 오류 원인을 찾기 어려워집니다. 응답이 길다면 필요한 필드 하나만 후속 노드에 넘기는 방식으로 시작하세요.
GET과 POST의 차이
GET은 보통 기존 데이터를 읽는 요청입니다. 반면 POST는 새 데이터를 만들거나 작업을 시작하는 데 자주 사용됩니다. 하지만 HTTP 메서드의 정확한 의미와 필요한 필드는 서비스마다 다르므로, “POST면 생성”이라고 단정하지 말고 해당 API 문서를 우선해야 합니다.
POST를 처음 테스트할 때는 실제 고객·주문·발송 데이터를 쓰지 마세요. Body가 필요하면 HTTP Request 노드에서 Send Body를 켠 뒤, API 문서가 요구하는 형식에 맞춰 JSON을 선택합니다. 아래처럼 값의 구조를 확인하는 연습은 가능하지만, 필드명은 예시일 뿐 실제 서비스의 필수값은 문서를 따라야 합니다.
{
"title": "테스트 항목",
"status": "draft"
}JSON의 쉼표, 따옴표, 대괄호 하나가 달라도 400 오류가 날 수 있습니다. 설정 화면에서 값 하나를 바꾸기 전에 테스트 응답과 API 문서의 예시를 나란히 보세요.
인증 정보는 URL이나 메모에 넣지 않기
API 키나 토큰은 비밀번호처럼 다뤄야 합니다. 주소에 토큰을 붙이거나, 워크플로우의 일반 텍스트 필드·스크린샷·공유 문서에 복사하지 마세요. n8n에서 해당 서비스용 Predefined Credential Type을 지원한다면 공식 문서도 이 방식을 우선 권장합니다. 지원하지 않는 API는 Header auth, OAuth 등 서비스 요구사항에 맞는 generic credential을 설정합니다.
권한도 최소로 시작하세요. 읽기만 필요한 자동화에 쓰기·삭제 권한을 줄 필요는 없습니다. 테스트 후 사용하지 않는 credential은 남겨 두지 말고, 키가 노출됐다고 의심되면 해당 서비스에서 즉시 폐기·재발급해야 합니다.
응답이 안 올 때 확인할 순서
| 증상 | 먼저 볼 곳 |
|---|---|
| 401 또는 403 | 인증 방식, 키의 권한·만료 여부, 헤더 이름 |
| 404 | URL 경로, API 버전, endpoint 철자 |
| 400 | 필수 Body 필드, JSON 형식, Content-Type |
| 429 | 요청 빈도, 동시에 실행된 워크플로우, Retry-After 안내 |
| 응답은 성공인데 다음 노드가 비어 있음 | 응답 JSON의 실제 필드 위치와 표현식 |
문제를 숨기기 위해 ‘Never Error’를 먼저 켜는 것은 추천하지 않습니다. 기본적으로 n8n은 2xx 응답을 성공으로 처리합니다. 오류 상태와 응답 헤더까지 보고 싶을 때만 응답 옵션을 잠시 켜서 원인을 확인하고, 해결 후에는 필요한 설정만 남기세요.
한 번에 많은 데이터를 호출하기 전
API가 한 번에 제한된 결과만 돌려준다면 pagination 방식을 먼저 확인해야 합니다. 또 입력 항목이 많으면 HTTP Request 노드의 배치 크기와 대기 간격을 조절할 수 있습니다. 그러나 값은 추측으로 정하지 말고 해당 API의 요청 제한을 확인한 다음, 1~5건의 작은 데이터부터 늘리세요. 429 오류가 보이면 무한 재시도보다 처리량과 재시도 방식을 점검하는 글을 먼저 참고하세요.
다음에 읽으면 좋은 글
HTTP Request 노드의 Method, 인증, Query, Headers, Body, 응답·페이지네이션 설정은 n8n 공식 HTTP Request 문서를 기준으로 2026년 9월 9일 확인했습니다. 실제 API의 endpoint·권한·제한은 연결하려는 서비스의 최신 API 문서를 따르세요.