n8n을 처음 시작한다면 첫 워크플로우 → 웹훅 첫 테스트 → Schedule Trigger 순서로 읽어 보세요. 데이터 매핑·조건 분기·오류 해결도 함께 다룹니다. 이후에는 데이터 매핑 → IF 조건 분기 → Webhook 오류 해결 순서로 범위를 넓혀 보세요.
Edit Fields는 단순히 이름을 예쁘게 바꾸는 노드가 아닙니다. 다음 노드가 받을 데이터 계약을 만드는 곳입니다. 여기서 원본 ID를 빼거나 이메일을 잘못된 필드에 매핑하면, 뒤의 Google Sheets·API·분기 노드가 성공 표시를 보여도 업무 결과는 틀릴 수 있습니다. 이 글의 범위: 공식 문서를 바탕으로 한 입력·출력 설계와 가상 데이터 시험표입니다. 이 예제는 실제 n8n 실행 기록이나 외부 스프레드시트 … 더 읽기
Error Trigger를 붙였는데 알림이 오지 않는다면, 먼저 원본 워크플로우가 어떤 방식으로 실패했는지와 오류 처리 워크플로우가 지정됐는지를 나눠 확인하세요. 알림 노드의 연결 문제와 Error Trigger의 호출 조건은 다른 문제입니다. 검증 범위: 이 글은 공식 문서에 따른 설정 설명과 가상 오류 데이터로 만드는 설계 예제입니다. 이번 개편에서는 실제 Error Trigger 호출·메일 발송·Slack 전송을 실행하지 않았습니다. 아래 예제는 … 더 읽기
자동화를 만들다 보면 한 흐름에서 고객 정보를 가져오고, 다른 흐름에서 주문·문의·AI 분석 결과를 가져온 뒤 한 건의 데이터로 묶어야 하는 순간이 옵니다. 이때 쓰는 노드가 n8n의 Merge입니다. Merge 노드는 두 개 이상의 입력 흐름이 모두 준비된 뒤 데이터를 결합합니다. 단순히 데이터를 이어 붙이는 방식부터, 같은 이메일 주소나 주문번호를 기준으로 맞춰 합치는 방식까지 선택할 수 있습니다. … 더 읽기
Wait는 실행을 잠시 멈추고 조건에 따라 이어 가는 노드입니다. 실행이 재개됐다는 사실과 사람이 승인했다는 사실은 다릅니다. 특히 제한 시간이 지나도 재개될 수 있는 흐름에서 Wait 바로 다음에 발송 노드를 연결하면, 승인 없이 작업이 진행될 수 있습니다. 이 글의 범위: 공식 문서를 바탕으로 시간 대기 시험 계획과 승인 판단 설계를 제공합니다. 이번 개편에서 실제 n8n 대기·재개·승인 … 더 읽기
자동화 흐름이 단순할 때는 “조건이 맞으면 실행, 아니면 종료”만으로 충분합니다. 하지만 문의 상태가 신규·검토중·완료로 나뉘거나, 우선순위에 따라 담당자와 알림 채널을 다르게 보내야 하면 두 갈래만 있는 IF 노드로는 구조가 복잡해집니다. 이때 Switch 노드를 쓰면 하나의 입력을 여러 조건별 경로로 정리할 수 있습니다. 이 글은 n8n에서 상태값, 숫자, 날짜 등 여러 조건을 기준으로 자동화를 분기하는 기본 … 더 읽기
n8n에 원하는 서비스용 노드가 없다고 해서 자동화를 포기할 필요는 없습니다. 서비스가 REST API를 제공한다면 HTTP Request 노드로 직접 요청을 보낼 수 있습니다. 다만 API 호출은 단순히 URL을 붙여 넣는 작업이 아닙니다. 어떤 데이터를 읽거나 만들려는지, 인증은 어떻게 하는지, 실패했을 때 무엇을 확인할지를 함께 정해야 합니다. 이 글에서는 실제 업무 데이터나 비밀 키를 쓰지 않고, HTTP … 더 읽기
n8n 워크플로우가 실패했다고 해서 바로 재시도를 누르는 것이 항상 정답은 아닙니다. 이미 이메일을 보냈거나 데이터베이스에 항목을 만든 뒤 마지막 단계에서만 실패했다면, 같은 실행을 다시 돌릴 때 중복 작업이 생길 수 있습니다. 가장 안전한 순서는 실행 기록 확인 → 실패 지점 분류 → 외부 작업 여부 점검 → 작은 범위에서 재시도입니다. 이 글은 n8n Cloud와 일반적인 … 더 읽기
n8n 웹훅(Webhook)은 폼 제출, 결제 완료, 새 문의처럼 어떤 일이 발생한 순간 데이터를 워크플로우로 보내는 시작점입니다. 이 글에서는 외부 서비스 연결 없이도 웹훅을 직접 호출해, 데이터 수신부터 응답 반환까지 한 번에 확인합니다. 웹훅이 필요한 순간 웹훅은 n8n이 주기적으로 데이터를 확인하는 방식이 아니라, 외부 서비스가 이벤트 발생 시 n8n 주소로 HTTP 요청을 보내는 방식입니다. 예를 들어 … 더 읽기
n8n 워크플로우는 수동 실행으로 결과를 확인한 뒤에만 정기 실행으로 바꾸는 편이 안전합니다. 이 글은 Manual Trigger로 검증한 흐름을 Schedule Trigger로 넘길 때 확인할 순서를 정리합니다. 전환 전에 수동 실행으로 확인할 세 가지 정상 데이터가 원하는 마지막 단계까지 도착하는지 확인합니다. 조건에 맞지 않는 데이터가 잘못된 외부 앱으로 전달되지 않는지 확인합니다. 같은 입력을 다시 실행했을 때 중복 … 더 읽기
n8n 자동화에서 조건 분기는 “이 데이터를 계속 처리할지, 여기서 멈출지”를 정하는 안전장치입니다. 처음에는 외부 앱을 연결하지 않고 Manual Trigger → Edit Fields → If 세 단계만으로 흐름을 검증하는 편이 좋습니다. 먼저 확인할 기본 구조 Manual Trigger로 실행 시점을 직접 통제합니다. Edit Fields에서 가짜 테스트 값을 만듭니다. If에서 조건에 따라 true·false 경로를 나눕니다. 왜 수동 실행부터 … 더 읽기