n8n 이전이나 Make 대체를 윈디플로로 진행할 때는 흐름을 통째로 다시 짓기보다 판단이 든 단계부터 떼어 옮깁니다. 흐름 목록은 짧게 적고, 무게는 지난 실행 입력으로 하는 재현, 새 쪽의 쓰기를 막은 병행, 병행 전에 정해 둔 전환 기준에 둡니다. 가져오기 기능은 공개 안내서에서 확인되지 않아 다시 짓는 것을 전제로 합니다.

Make나 n8n으로 흐름 여러 개를 돌려 온 담당자가 윈디플로 체험 계정을 만들고 나면, 다음 질문은 지금 켜 둔 흐름을 어떻게 넘기느냐입니다. 캔버스에 노드를 잇는 화면이 비슷해 보이니 파일 하나를 올리면 끝날 것처럼 느껴지기도 합니다.

실제로 옮겨지는 단위는 파일이 아니라 결과입니다. 옛 흐름이 내던 결과를 새 쪽이 같은 입력에서 똑같이, 또는 더 낫게 내는지 맞춰 본 뒤에야 입구를 바꿀 수 있습니다.

켜 둔 흐름을 윈디플로로 바로 가져올 수 있나요?

윈디플로의 한국어 안내서(2026년 10월 1일 확인)에서는 n8n·Make 흐름을 가져오거나 변환하는 기능을 찾지 못했습니다. 그래서 이전 계획은 다시 만드는 것을 전제로 세우고, 가져오기 지원 여부는 상담에서 따로 확인하시는 편이 일정이 덜 흔들립니다.

그렇다고 옛 도구에서 받을 것이 없지는 않습니다. n8n은 흐름을 JSON 파일로 내려받게 하고, 공식 문서는 그 파일에 자격 증명(외부 서비스에 접속하는 계정 정보)의 이름과 ID가 함께 담긴다고 적습니다. Make 쪽은 시나리오를 블루프린트라는 JSON 파일로 내보내며, 여기에 모듈·모듈 설정·매핑된 값이 들어가고 연결은 가져온 뒤 계정마다 다시 만들어야 한다고 안내합니다.

두 파일은 새 도구에 올리는 짐이라기보다 옛 흐름의 설계도로 읽는 자료입니다. 특히 매핑된 값에는 어느 필드를 어느 필드로 넘겼는지가 남아 있어서, 재현 단계에서 비교할 칸을 정하는 기준이 됩니다. 파일을 외부와 주고받을 때는 자격 증명 이름부터 지우시길 권하는 n8n 문서의 주의도 함께 챙기셔야 합니다.

흐름 전체를 옮겨야 하나요, 일부만 옮겨도 되나요?

첫 전환이라면 일부만 옮기는 구성이 무난합니다. 필드를 짝지어 옮기고 정해진 시각에 도는 구간은 n8n·Make에 두고, 문서를 읽거나 분류해야 하는 단계만 윈디플로 파이프라인으로 떼어 내는 방식입니다.

흐름 하나가 갈 수 있는 곳은 세 군데입니다.

• 그대로 둔다: 판단이 없는 흐름입니다. 옮겨도 결과가 달라지지 않고 옮기는 수고만 생깁니다.
• 판단 단계만 뗀다: 앞뒤 단계는 옛 흐름이 맡고, 가운데 한 단계만 윈디플로 파이프라인을 불러 처리합니다.
• 흐름 전체를 옮긴다: 입구부터 판단이 중심인 흐름입니다. 사내 규정을 찾아보고 회신하는 문의 응대처럼 대화가 입구인 경우가 여기에 가깝습니다.

셋째 경우에는 입구를 무엇으로 둘지가 먼저 정해져야 합니다. 윈디플로 안내서의 「Share Chatbot」은 별도 연동 없이 챗봇 링크로 공유하는 기능인데, 챗봇으로 작동하는 파이프라인에서만 쓸 수 있고 데이터 처리용 파이프라인은 지원하지 않을 수 있다고 적혀 있습니다.

둘째 구성에는 따져 볼 점이 하나 있습니다. 옛 도구를 계속 쓰니 그 도구의 청구서도 남습니다.

이전을 생각한 이유가 청구액이었다면, 판단 단계만 떼는 구성은 그 문제를 풀지 못할 수 있습니다. 과금 단위로 청구액이 어디서 튀는지는 과금 단위와 한국어 지원 층으로 대안을 좁히는 기준에서 먼저 확인하시길 권합니다.

흐름 목록에는 무엇을 적어 두나요?

흐름마다 네 가지를 한 줄에 적습니다. 흐름이 무엇으로 시작하는지, 밖으로 무엇을 쓰는지, 판단 단계가 어디 있는지, 자격 증명이 누구 명의인지입니다.

• 입구: 웹훅(상대 시스템이 사건이 생긴 순간 정해 둔 주소로 데이터를 보내오는 방식), 예약 실행, 앱 이벤트 가운데 무엇인가
• 쓰는 동작: 메일 발송, 레코드 생성·수정, 메신저 알림처럼 흐름 밖에 흔적을 남기는 단계
• 판단 단계: 조건 분기가 길게 이어지거나 AI 노드가 들어간 자리
• 자격 증명: 개인 계정인지 팀 계정인지

넷째 항목까지 채우면 목록은 끝입니다. 입구 칸은 나중에 전환 방법을 정하고, 쓰는 동작 칸은 병행 방법을 정합니다. 목록에 들인 시간이 가장 먼저 돌아오는 곳이 이 두 칸입니다.

재현이 됐는지는 무엇으로 확인하나요?

옛 흐름이 실제로 받았던 입력을 새 파이프라인에 그대로 넣어 보고, 결과를 필드 단위로 맞대 봅니다. 새로 지어낸 시험 문장으로 확인하면 옛 흐름이 몇 달 동안 받아 온 까다로운 입력을 건너뛰게 됩니다.

지난 입력은 옛 도구의 실행 기록에서 꺼냅니다. n8n 문서에 따르면 운영 중인 웹훅으로 들어온 데이터는 편집 화면에 표시되지 않지만, 흐름의 Executions 탭에서 실행을 골라 볼 수 있습니다. 여기서 평범한 건과 분기가 갈렸던 건, 결과를 사람이 나중에 고쳤던 건을 섞어 비교 묶음을 만듭니다.

윈디플로 쪽은 한국어 안내서의 순서대로 짓습니다. 메뉴에서 새 파이프라인을 만들고, 작업 공간에서 「Add Node」로 노드를 끌어다 놓은 뒤 입력과 출력 유형이 맞는 점끼리 잇습니다. 「Save」를 누르고 실행한 다음 명령어를 입력해 시험하는 방식입니다.

POC 범위를 정할 때 제가 비교 묶음에서 빼지 않는 것이 셋째 부류입니다. 조건 분기가 걸러 내지 못해 담당자가 손으로 바로잡아 온 건이 이전을 검토하게 만든 이유였다면, 새 파이프라인이 이 건들에서 옛 흐름과 같은 결과를 낼 때 옮긴 보람이 없습니다.

비교 열은 내보낸 파일의 매핑된 값에서 칸 이름을 그대로 가져와 만듭니다. 블루프린트나 JSON에 「양식의 사유 필드 → ERP 반품 유형 필드」처럼 남은 대응을 한 줄씩 옮기면 시트의 열 이름이 정해지고, 옛 흐름이 실제로 채우던 칸만 비교에 들어갑니다. 새 파이프라인이 매핑에 없던 칸을 더 내놓는다면 그 칸은 비교 열이 아니라 다음 노드가 받아 줄 수 있는지 따로 볼 항목입니다.

옛 흐름의 AI 노드가 쓰던 언어 모델과 새 파이프라인에 붙일 모델이 다르다면 한 가지를 더 챙깁니다. 같은 지시문이라도 모델이 바뀌면 분류 경계가 달라질 수 있어서, 차이가 났을 때 원인이 파이프라인 구성인지 모델인지 가려내기 어려워집니다.

처음 비교할 때는 옛 흐름과 같은 모델을 붙여 구성만 맞춰 보고, 모델 교체는 그다음 비교로 따로 떼는 편이 원인을 좁히기 쉽습니다. 윈디플로 한국어 사이트는 클릭 몇 번으로 AI 모델을 바꿀 수 있다고 소개하지만, 옛 흐름이 쓰던 모델이 선택지에 있는지는 계정 화면에서 봐야 압니다.

요금제도 이 비교에 걸립니다. 윈디플로 요금 안내의 무료(Public) 요금제 항목에는 「No ChatGPT & Claude API calls」라고 적혀 있습니다. 옛 흐름이 ChatGPT나 Claude 모델을 써 왔다면 같은 모델로 하는 첫 비교는 무료 계정으로 할 수 없으니, 비교를 어느 요금제 계정에서 할지부터 정해야 합니다.

판단 단계만 떼면 기존 흐름에서는 무엇이 바뀌나요?

조건 분기나 AI 노드가 있던 한 칸이 윈디플로 파이프라인을 부르는 요청 단계로 바뀝니다. 이때 맞춰야 할 것은 요청 단계가 돌려주는 필드 이름이 다음 노드가 읽던 이름과 같은지이고, 다르다면 이름을 바꿔 넘기는 단계를 하나 더 둡니다.

윈디플로 안내서는 저장한 파이프라인에서 「Embed as API」를 눌러 API로 접근하거나 웹사이트에 붙일 수 있다고 설명합니다. 호출 코드는 HTML·React·Python·JavaScript·CURL 가운데 고른 언어로 만들어 줍니다.

n8n 쪽에서는 HTTP Request 노드가 REST API를 가진 서비스라면 어디든 부를 수 있고, 문서에 CURL 예시가 있으면 그것을 붙여 노드를 설정할 수 있다고 안내합니다.

두 안내를 이으면 옛 흐름이 윈디플로 파이프라인을 부르는 구성이 나옵니다. 윈디플로가 만들어 준 CURL 코드를 HTTP Request 노드에 붙이면 요청 주소와 보낼 값의 틀이 채워지는 방식입니다. 두 문서는 각 기능을 따로 설명할 뿐, 둘을 잇는 방식은 어느 문서에도 없습니다.

붙이는 순간 챙길 것이 하나 있습니다. n8n의 내보내기 문서는 cURL로 가져온 HTTP Request 노드에 인증 헤더가 들어 있을 수 있다고 경고합니다. 윈디플로 호출 키가 노드 안에 적힌 채로 흐름을 JSON으로 내려받으면 그 키도 파일에 실리니, 붙인 뒤에는 헤더의 키를 지우고 n8n 자격 증명(HTTP Request 노드의 인증 설정)으로 옮겨 두십시오.

연결하기 전에 확인할 것은 넷입니다.

• 요청에 붙이는 인증 방식과 그 키를 누구 명의로 발급하는지
• 파이프라인이 응답을 돌려주기까지 걸리는 시간과, 옛 도구가 그 시간을 기다려 주는지
• 파이프라인이 실패했을 때 어떤 형태의 응답이 오는지
• 호출이 무엇을 기준으로 청구되는지

셋째 항목의 답에 따라 옛 흐름의 오류 처리를 살리는 방법이 갈립니다. 윈디플로가 실패 때 오류 상태 코드를 돌려준다면 요청 단계가 실패로 끝나고, 그 뒤는 지금까지 쓰던 오류 경로가 받습니다. 성공 응답(200)에 오류 내용을 담아 돌려주는 방식이라면 요청 단계는 성공으로 기록되므로, 응답 값을 읽어 실패를 가르는 분기를 요청 단계 바로 뒤에 따로 두어야 합니다.

병행 운영 중에 메일이 두 번 나가지 않게 하려면 어떻게 하나요?

새 쪽의 쓰는 동작을 끈 채로 병행합니다. 새 파이프라인은 결과를 실제 메일이나 레코드로 내보내지 않고 비교용 시트에만 적게 하고, 실제 발송과 기록은 끝까지 옛 흐름이 맡습니다.

자동화 흐름은 사람을 거치지 않고 곧장 흔적을 남깁니다. 두 흐름이 같은 입력을 받아 둘 다 쓰는 동작을 실행하면 고객은 같은 안내 메일을 두 번 받고, CRM에는 같은 거래처가 두 줄로 생깁니다. 목록에서 쓰는 동작 칸을 채워 둔 이유가 여기서 드러납니다.

입력을 두 곳에 흘리는 방법도 입구 종류에 따라 다릅니다. 입구가 웹훅인 흐름은 보내는 쪽이 주소 하나만 알고 있어서, 새 쪽도 같은 입력을 받게 하려면 옛 흐름 안에서 입력을 복사해 넘기는 단계를 하나 둡니다. 예약 실행으로 도는 흐름은 옛 흐름이 가져온 목록을 그대로 새 쪽에 넘기면 두 쪽이 같은 묶음을 봅니다.

비교용 시트에는 한 건마다 네 칸을 둡니다.

칸	적는 것
입력 식별값	주문번호·문의 번호처럼 옛 기록과 짝지을 수 있는 값
옛 결과	옛 흐름이 실제로 쓴 값
새 결과	새 파이프라인이 시트에 적은 값
입력 형식 표시	다를 때만, 그 건의 옛 입력에 빠진 필드나 바뀐 형식이 있었는지

넷째 칸을 따로 둔 것은 이전에서만 생기는 차이가 있어서입니다. 거래처 양식이 바뀐 뒤 웹훅 페이로드(보내 온 데이터 묶음)에서 필드 하나가 빠졌는데 옛 흐름은 매핑의 기본값으로 메워 왔다면, 새 파이프라인은 같은 건에서 빈칸을 냅니다.

날짜나 금액을 옛 흐름의 표현식이 형식을 바꿔 넘기던 경우도 같은 모양의 차이를 만듭니다. 이런 차이는 판단의 차이가 아니라 옛 흐름에 숨어 있던 전처리를 새 쪽이 모르는 것이라, 파이프라인 앞에 그 전처리를 옮겨 두면 사라집니다.

입력 형식으로도 판단 차이로도 설명되지 않는 건이 쌓이면 병행을 멈추고 원인부터 찾습니다. 이유를 모르는 차이를 둔 채 건수만 늘리면, 전환 뒤에 같은 차이가 실제 발송으로 나갑니다.

옛 흐름에서 손을 떼도 된다는 기준은 무엇인가요?

병행을 시작하기 전에 적어 둔 조건이 모두 채워졌을 때입니다. 기간이나 건수보다 설명되지 않는 차이가 남았는지, 쓰기를 켰을 때 사고를 막을 장치가 있는지, 입구를 되돌리는 연습을 했는지가 판단을 가릅니다.

적어 둘 기준은 다음 넷입니다.

1. 설명 안 된 차이 0건: 비교용 시트의 차이 건이 입력 형식 문제인지 판단 차이인지 모두 갈렸고, 새 쪽이 틀린 건은 고친 뒤 같은 입력으로 다시 맞췄다.

1. 중복 방지 확인: 새 쪽이 쓰는 동작을 켜기 전에 주문번호 같은 식별값으로 이미 처리한 건인지 확인하는 단계가 들어 있다.

1. 되돌리는 연습: 전환 지점(판단만 뗀 구성이면 흐름 안의 연결, 흐름 전체를 옮기면 입구 주소)을 새 쪽으로 돌렸다가 옛 쪽으로 되돌리는 절차를 시험 입력으로 한 번 해 봤다.

1. 명의 이전: 새 쪽의 자격 증명과 API 키가 떠날 수 있는 개인이 아니라 팀이 관리하는 계정으로 등록돼 있다.

전환 첫날에는 새 쪽이 실제로 쓴 건을 몇 건 골라 비교용 시트와 같은 칸으로 한 번 더 대조합니다. 쓰기를 켠 뒤에만 드러나는 차이, 예를 들어 ERP가 받아 주지 않는 값 형식은 병행 기간의 시트에는 나타나지 않기 때문입니다.

둘째 기준이 필요한 까닭은 전환 순간에 있습니다. 입구를 바꾸는 그때 옛 흐름이 막 처리한 건이 새 쪽에 다시 들어올 수 있습니다. 식별값 확인이 없으면 병행 기간 내내 막아 둔 중복이 전환 당일에 생깁니다.

흐름 전체를 옮길 때 셋째 기준은 입구 종류마다 할 일이 다릅니다. 웹훅이라면 보내는 쪽 시스템의 주소 설정을 바꾸는 일이고, 그 설정을 누가 바꿀 수 있는지부터 확인해야 합니다.

예약 실행이라면 새 쪽의 시간표를 켜고 옛 쪽을 끄는 일인데, 윈디플로 공개 안내서에서는 예약 실행 기능을 확인하지 못했습니다. 이 경우 시간표는 옛 도구에 두고 판단만 윈디플로가 맡는 구성을 먼저 검토하시고, 윈디플로 쪽 예약 기능은 상담에서 확인하시는 순서가 무난합니다.

입구를 바꾼 뒤 옛 흐름은 언제 지우나요?

바로 지우지 않습니다. 끄되 남겨 두고, 새 쪽의 실제 쓰기 기록으로 되돌릴 일이 없다고 판단한 뒤에 정리합니다. 그 전에 옛 흐름의 JSON 파일이나 블루프린트를 날짜를 붙여 한 번 더 내려받아 둡니다. n8n 파일에는 자격 증명 이름과, 정리하지 못한 인증 헤더가 들어 있을 수 있으니, 보관하는 폴더는 흐름을 관리하는 팀만 열 수 있게 둡니다.

Make를 쓰셨다면 날짜 하나를 챙기셔야 합니다. Make 도움말은 어느 시나리오에도 연결되지 않은 웹훅을 5일(120시간)이 지나면 자동으로 비활성화하고, 그 뒤로는 410 Gone 응답을 돌려준다고 적습니다. 옛 시나리오를 지우거나 웹훅을 떼어 낸 채 두면, 되돌아갈 입구가 닷새 뒤에 닫히는 셈입니다.

n8n 문서는 운영용 웹훅을 흐름을 게시할 때 등록한다고 적습니다. 게시를 거둔 뒤 그 주소가 어떻게 응답하는지는 그 문서에 나와 있지 않으니, 보내는 쪽 설정을 새 주소로 먼저 바꾸고 옛 흐름은 그다음에 끄는 순서를 지키십시오. 끄는 쪽이 먼저면 그 사이에 들어온 입력이 어느 쪽에서도 처리되지 않을 수 있습니다.

반품 요청 흐름 하나에 네 단계를 대 보면 어떻게 흘러가나요?

이 흐름은 설명을 돕고자 지어낸 가상 예시이고, 어느 회사의 실제 운영 흐름도 아닙니다. 한 유통사가 n8n으로 거래처 반품 요청을 처리하고 있습니다. 거래처가 웹 양식을 제출하면 웹훅으로 흐름이 시작되고, 자유롭게 적힌 반품 사유를 조건 분기 열두 줄이 「파손」·「오배송」·「단순 변심」 가운데 하나로 나눈 뒤, ERP에 반품 건을 만들고 담당자에게 메일을 보냅니다.

목록에 적으면 한 줄입니다. 입구는 웹훅, 쓰는 동작은 ERP 기록과 메일 둘, 판단 단계는 사유 분류, 자격 증명은 퇴사한 전임자 명의의 ERP 계정입니다. 넷째 칸 덕분에 전환 기준 4번이 첫 할 일로 올라옵니다.

재현에서는 Executions 탭에서 지난 두 달 치 요청을 꺼내, 담당자가 분류를 고쳐 적었던 건을 따로 표시합니다. 이 예시에서 분기 열두 줄이 놓친 사유는 「포장은 멀쩡한데 내용물이 다르다」처럼 두 분류에 걸친 문장으로 설정했습니다.

윈디플로에서는 분류 한 단계만 파이프라인으로 짓습니다. 플랫폼 소개 페이지(hamadalabs.com)에 윈디플로 기능으로 올라 있는 벡터 데이터베이스·지식 베이스 연결을 쓰면, 반품 규정 문서를 찾아 근거와 함께 분류를 돌려받는 구성을 짤 수 있습니다.

병행에서는 n8n 흐름의 분기 자리 옆에 파이프라인을 부르는 요청 단계를 나란히 두고, 그 결과는 비교용 시트에만 적습니다. ERP 기록과 메일은 여전히 옛 분기 결과를 따릅니다.

설명 안 된 차이가 사라지고 반품 번호로 중복을 막는 확인이 들어가면, 옛 분기를 빼고 파이프라인 결과를 ERP 단계에 잇습니다. 거래처 양식이 보내는 웹훅 주소는 그대로이므로, 셋째 기준의 되돌리기 연습은 거래처와 일정을 맞출 필요 없이 n8n 흐름 안에서 끝납니다.

윈디플로로 옮기지 않는 편이 나은 경우는 언제인가요?

판단 단계 칸이 비어 있는 흐름은 처음부터 이전 목록에서 뺍니다. 그런 흐름을 어느 부류의 도구에 두는 편이 맞는지는 판단이 필요한 업무를 가려내는 세 가지 물음에서 다뤘습니다.

판단 단계가 있어도 비교용 시트가 이전을 말리는 경우가 있습니다. 담당자가 바로잡아 온 건을 넣었는데도 옛 흐름과 새 파이프라인의 결과가 갈리지 않는다면, 옮긴 뒤에 달라지는 것은 결과가 아니라 관리할 도구의 수뿐입니다.

지난 입력을 꺼낼 실행 기록이 없는 흐름도 당장은 미루는 편이 낫습니다. 재현을 확인할 재료가 없으면 병행 기간의 비교가 첫 기준이 되고, 그만큼 전환 판단이 늦어집니다. 이런 흐름은 옛 흐름의 입력과 결과를 한동안 모으는 일이 첫 단계입니다.

사내 시스템과 연결을 새로 발급받아야 하는 흐름이 섞여 있다면 발급 대기부터 계산에 넣으셔야 합니다. 연결 대상별로 대기가 생기는 구간은 연결 대상마다 계정 발급 대기가 달라지는 구간표에서 다뤘습니다.

첫 전환 대상은 어떤 흐름으로 고르나요?

판단 단계가 한 곳에 있고 쓰는 동작이 하나뿐인 흐름을 골라, 그 판단 단계만 떼는 구성으로 시작합니다. 판단 단계가 하나면 재현할 범위가 좁고, 쓰는 동작이 하나면 병행 중 막을 곳도 하나이며, 입구가 그대로라 보내는 쪽 시스템의 담당자와 전환 일정을 맞출 일이 없습니다.

두 번째 흐름에서 입구 종류가 바뀌면 할 일도 바뀝니다. 예약 실행으로 도는 흐름이라면 옛 흐름이 가져온 목록을 새 쪽에 넘기는 단계를 병행용으로 새로 두고, 흐름 전체를 옮길 생각이라면 윈디플로 쪽 예약 기능 확인이 전환 기준보다 앞에 옵니다. 웹훅 입구의 흐름 전체를 옮길 때는 보내는 쪽 설정을 누가 바꾸는지와 Make의 닷새 기한이 일정에 들어옵니다.

확인 항목 가운데 앞의 셋(인증·응답 시간·실패 응답)은 판단 단계 하나를 파이프라인으로 지어 옛 흐름에서 불러 보는 시험으로 가늠할 수 있습니다. 호출 코드는 안내서 절차대로 저장한 파이프라인의 Embed as API에서 받고, 이 기능을 무료 계정에서 쓸 수 있는지는 시험 전에 확인합니다.

넷째인 청구 기준과 사내망 배포 조건은 무료 상담에서 이어서 다룹니다.

자주 묻는 질문

n8n을 사내 서버에 설치해 쓰고 있으면 무엇이 달라지나요?

윈디플로를 어디에 둘지부터 정해야 합니다. 옛 흐름이 사내망 안의 시스템을 부르고 있었다면, 새 파이프라인도 그 시스템에 닿는 위치에 있어야 합니다. 하마다랩스는 클라우드와 사내 설치(온프레미스), 둘을 섞는 하이브리드 가운데 고르는 배포를 안내하고 있어, 사내망 요건이 이 셋 가운데 어느 쪽인지를 정합니다.

Make 시나리오에 데이터 스토어를 쓰고 있었다면요?

블루프린트 안내는 모듈·설정·매핑된 값을 담는다고만 적고 있어, 데이터 스토어에 쌓인 행이 함께 옮겨진다고 보기 어렵습니다. 저장된 행은 따로 내보내고, 새 쪽에서 그 데이터를 어디에 둘지 정하는 일을 이전 계획에 넣으셔야 합니다.

n8n 코드 노드에 넣어 둔 스크립트는 어떻게 옮기나요?

스크립트가 하던 일을 먼저 글로 적어 둡니다. 날짜 형식 변환처럼 판단이 없는 처리라면 옛 흐름에 그대로 두는 편이 간단합니다. 판단 단계 안에 섞여 있다면 윈디플로에서 같은 처리를 어떤 노드로 할 수 있는지 노드 목록에서 확인하셔야 합니다.

병행 기간에는 비용이 두 번 드나요?

그 기간에는 옛 도구 요금과 새 쪽 사용량이 겹칩니다. 새 쪽이 쓰는 동작을 끈 채 돌더라도 파이프라인 호출은 일어나기 때문입니다. 청구 기준은 앞의 확인 항목 넷째이니, 병행 기간의 길이는 그 답을 받은 뒤에 정합니다.

흐름 여러 개를 한꺼번에 옮겨도 되나요?

입구가 서로 다른 흐름이라면 동시에 병행할 수는 있습니다. 다만 비교용 시트를 흐름마다 따로 두고, 전환은 한 번에 하나씩 진행합니다. 같은 날 여러 입구를 바꾸면 문제가 생겼을 때 어느 전환이 원인인지 가르기 어렵습니다.

흐름 전체를 옮기면 옛 도구에서 알림을 받던 사람들은 어떻게 정리하나요?

옛 흐름의 오류 알림이 누구에게, 어느 채널로 가고 있었는지부터 흐름 목록 옆에 적어 둡니다. 개인 메일로 가던 알림이라면 이번에 팀 채널로 바꿀 기회입니다. 윈디플로 쪽 알림 방식은 공개 안내서에 나와 있지 않아, 전환 전에 수신자 목록과 함께 맞춰 둘 항목으로 남깁니다.

참고 자료

• n8n Docs, 「Export and import」 — 흐름을 JSON 파일로 내려받기·가져오기, 내보낸 JSON에 자격 증명 이름과 ID 포함, 공유 전 제거 권고(2026-10-01 확인): https://docs.n8n.io/build/manage-workflows/export-and-import
• n8n Docs, 「Webhook node」 — 시험용·운영용 URL, 운영용 웹훅은 흐름 게시 시 등록, 운영 실행 데이터는 Executions 탭에서 확인(2026-10-01 확인): https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook
• n8n Docs, 「HTTP Request node」 — REST API를 가진 서비스에 요청, CURL 예시로 노드 설정(2026-10-01 확인): https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest
• Make Help Center, 「Scenario blueprints」 — 모듈·모듈 설정·매핑된 값 포함, JSON 내보내기·가져오기, 가져온 뒤 연결 재생성(2026-10-01 확인): https://help.make.com/blueprints
• Make Help Center, 「Webhooks」 — 처리 대기열, 시나리오에 연결되지 않은 웹훅은 5일(120시간) 뒤 비활성화·410 Gone 응답(2026-10-01 확인): https://help.make.com/webhooks
• 윈디플로 한국어 사용 안내서, 「코딩없이 AI 파이프라인 만들기」 — 파이프라인 생성·Add Node·노드 연결·Save 뒤 실행과 명령어 시험, Embed as API와 언어별 호출 코드, Share Chatbot의 적용 범위(2026-10-01 확인): https://www.windyflo.com/kr/user-guide/how-to-build-pipelines
• 윈디플로 한국어 사이트 — 「클릭 몇 번으로 AI 모델 변경」 소개(2026-10-01 확인): https://www.windyflo.com/kr
• hamadalabs.com 플랫폼 페이지 — 벡터 데이터베이스·지식 베이스 연결(RAG), 전문화된 에이전트 팀 구성, 클라우드·온프레미스·하이브리드 배포 문구(2026-10-01 확인): https://www.hamadalabs.com/platform
• 윈디플로 가격 정책 페이지 — 무료(Public) 요금제 항목 「No ChatGPT & Claude API calls」(2026-10-01 확인): https://www.windyflo.com/kr/pricing

작성자

안효준 — 하마다랩스 윈디플로 프로덕트 매니저. 윈디플로와 n8n·Dify 등 노코드 빌더를 같은 선택 기준으로 비교하고, 소규모 POC·파일럿으로 도입을 검증하는 절차를 다룹니다. 회사 소개: https://www.hamadalabs.com/