팟캐스트 n8n HTTP Request 노드, 인증 방식 뭘 골라야 할까? — 삽질 끝에 정리한 표 하나
🎙️ 오늘의 팟캐스트
n8n HTTP Request 노드, 인증 방식 뭘 골라야 할까? — 삽질 끝에 정리한 표 하나
📌 에피소드 주요 내용
- n8n HTTP Request 노드의 인증 방식은 None, Predefined Credential Type, Generic Credential Type (Header Auth, API Key, Basic Auth, OAuth)으로 나뉘며, 각 서비스가 요구하는 방식에 따라 선택해야 함
- 같은 파이프라인 내에서도 호출하는 서비스마다 인증 방식이 달라지는데 이는 각 서비스의 원래 요구사항을 반영한 것
- 새 노드를 만들 때는 처음부터 설정하기보다는 정상 작동하는 기존 노드를 복사하고 URL과 Body만 수정하는 것이 인증 설정 누락을 방지하는 안전한 방법
🎧 전체 대본
지혜: 안녕하세요, 팟캐스트 ‘코딩 일상’ 입니다. 오늘은 노교수님과 함께 n8n 자동화 도구의 인증 방식에 대해 이야기해보려고 해요. 교수님, 최근에 API 인증으로 꽤 고생하셨다고 들었는데, 어떤 일이 있으셨어요?
박교수: 네, 정말 그렇습니다. 제 자동화 파이프라인을 디버깅하다가 새로운 노드를 추가했는데 갑자기 ‘Forbidden’ 에러가 나는 거예요. 번역하면 ‘너 누구세요?’라는 뜻인데, API에 인증 정보를 보내지 않은 탓이었어요. 문제는 그 과정에서 n8n의 Authentication 드롭다운에 있는 선택지들이 각각 뭘 의미하는지 제대로 이해하지 못했다는 걸 깨달았다는 것이었습니다.
지혜: 아, 그럼 인증 방식이 여러 개가 있다는 거군요? 어떤 종류들이 있나요?
박교수: 크게 네 가지입니다. 먼저 ‘None’은 인증이 아예 필요 없는 공개 API를 부를 때 쓰죠. 그리고 ‘Predefined Credential Type’은 n8n이 이미 Google, YouTube 같은 유명 서비스를 위해 미리 인증 흐름을 다 만들어둔 경우입니다. ‘Sign in with Google’ 버튼 한 번 누르면 토큰 관리까지 자동으로 해주는 거죠. 하지만 n8n이 모르는 서비스라면 ‘Generic Credential Type’을 써야 하는데, 여기서 또 세부 타입이 나뉩니다.
지혜: 세부 타입이라니, 또 뭐가 있어요?
박교수: Header Auth, API Key, Basic Auth, OAuth 같은 것들이죠. 예를 들어 Gemini API 같은 경우, 요청 헤더에 API 키를 실어 보내야 하니까 Header Auth를 선택해야 합니다. 반대로 쿼리 파라미터에 키를 넣어야 하는 서비스라면 API Key를 고르면 되는 거예요. 결국 각 서비스가 원래 요구하는 방식을 n8n이 그대로 반영한 것뿐입니다.
지혜: 그럼 교수님이 실수하신 부분은 뭐였어요?
박교수: 이미 잘 되던 노드를 복사하지 않고, 새로운 노드를 처음부터 직접 만들었어요. HTTP Request 노드의 기본값이 Authentication ‘None’으로 설정되어 있는데, URL과 Body만 채우고 이 부분을 그냥 지나쳤던 겁니다. 그래서 교훈은 단순합니다. 같은 API를 부르는 노드를 새로 만들 때는 처음부터 설정하지 말고, 이미 정상 작동하는 노드를 복사해서 URL과 Body만 바꾸는 게 훨씬 안전하다는 것이죠. 눈에 잘 안 띄는 인증 설정을 빠뜨릴 위험이 확 줄어듭니다.
지혜: 정말 유용한 팁이네요! 그럼 새로운 API를 붙일 때 어떻게 하면 좋을까요?
박교수: 그 서비스의 공식 문서에서 Authentication이나 API Key 섹션을 먼저 찾아서, 거기 적힌 방식이 뭔지 확인하는 거예요. 그다음 Header Auth인지 API Key인지 판단해서 선택하면 됩니다. 이런 식으로 접근하면 헤매는 시간을 훨씬 줄일 수 있죠.
지혜: 알겠습니다! 더 자세한 내용과 실전 예시들, 그리고 교수님이 정리해두신 선택 기준표는 블로그 원문에서 확인하실 수 있어요. 오늘 말씀 감사합니다, 노교수님!
박교수: 감사합니다.
🔑 핵심 키워드
n8n, HTTP Request, API 인증, Header Auth, API Key, 자동화