n8n Sub-workflow를 부를 때 완료 대기와 비동기 분기를 먼저 나눠보세요

창가 오크 책상 위 꺼진 노트북, 이단 원목 서류 정리함에 담긴 무지 카드 묶음과 나무 클립, 세이지색 머그

완료 대기 옵션은 어떤 기준으로 켜거나 끄나요?

자식 워크플로의 최종 결과가 부모 워크플로의 다음 노드 판단에 직접 쓰이는지에 따라 결정하면 돼요. Execute Sub-workflow 노드는 기본적으로 완료 대기 옵션(Wait for Sub-Workflow Completion)이 켜진 상태로 동작해요. 이 상태에서는 부모 워크플로가 자식의 실행이 끝날 때까지 멈춰 서서 기다려요. 자식 워크플로의 마지막 노드가 반환한 데이터가 그대로 부모 노드의 출력으로 들어오므로, 후속 분기 노드나 API 호출에서 자식의 계산 결과를 곧바로 활용할 수 있어요.

반대로 대기 옵션을 끄면 비동기 방식으로 전환돼요. 부모 워크플로는 자식 워크플로의 실행 신호만 보낸 뒤 자식이 끝나기를 기다리지 않고 다음 노드로 바로 넘어가요. 긴 시간이 걸리는 데이터 백업, 외부 슬랙이나 이메일 통지, 대용량 로그 적재처럼 부모가 결과를 알 필요가 없는 부가 업무는 이 옵션을 끄는 편이 효율적이에요. 다만 대기 옵션을 끄면 부모 워크플로 안에서는 자식의 실행 성공 여부나 반환 데이터를 전혀 읽을 수 없어요.

부모와 자식 사이에 데이터는 어떻게 오고 가나요?

부모와 자식 워크플로의 연결 흐름은 부모 입력 데이터 → Execute Sub-workflow 노드 → Execute Sub-workflow Trigger 노드 → 자식 실행 → 자식 최종 노드 출력 → 부모 후속 노드 순서로 이어져요.

부모 워크플로가 넘긴 데이터는 자식 워크플로의 시작점인 Execute Sub-workflow Trigger 노드가 받아서 내부 노드들에 제공해요. 이때 부모 노드에서 호출 모드를 어떻게 설정하느냐에 따라 처리 방식이 달라져요. Run Once With All Items를 고르면 부모로 들어온 모든 입력 배열을 한 묶음으로 자식에게 넘겨 1회만 실행해요. 목록 일괄 조회나 데이터 집계 처리에 적합해요.

입력 항목마다 개별 처리가 필요하다면 Run Once For Each Item을 선택해요. 입력 배열의 항목 수만큼 자식 워크플로가 독립적으로 반복 호출돼요. 개별 건마다 세부 유효성 검사나 독립 API 호출을 돌릴 수 있지만, 항목 수가 수백 건 이상으로 늘어나면 자식 워크플로 호출이 폭증해 시스템 자원을 많이 소모해요. 대규모 데이터는 /workflow/n8n-agents-workflow-tools-preview/에서 워크플로를 도구로 붙일 때처럼 입출력 단위를 사전에 좁혀두어야 해요.

자식 워크플로가 멈추면 부모 실행은 어떻게 되나요?

완료 대기 옵션의 설정에 따라 오류의 전파 범위가 완전히 달라져요. 기본 대기 모드에서는 자식 워크플로의 어느 한 노드라도 실패하여 실행이 중단되면 부모의 Execute Sub-workflow 노드 역시 오류를 내며 전체 실행이 멈춰요. 핵심 결제 검증이나 재고 차감처럼 하위 단계 실패 시 전체 프로세스가 중단되어야 하는 업무에는 이 기본 동작이 안전해요. 부모가 실패하더라도 후속 조치를 취하고 싶다면 부모 노드 설정에서 Continue On Fail을 켜두어야 해요.

대기 옵션을 끈 비동기 모드에서는 자식 워크플로 내부에서 심각한 오류가 발생해도 부모 워크플로는 영향을 받지 않아요. 부모는 이미 다음 노드로 넘어가 정상 완료 상태로 끝나기 때문이에요. 부모 프로세스를 안전하게 보호하는 격리 효과가 있지만, 자식의 실패 사실을 부모가 감지하지 못한다는 단점이 있어요. 자식 워크플로의 실패를 방치하지 않으려면 자식 쪽에 별도의 Error Trigger 워크플로를 연결해 두거나 /safe-ops/n8n-failed-execution-retry-workflow-choice/에서 다룬 것처럼 실패 실행에 대한 재시도 기준을 미리 세워두어야 해요.

운영 환경에서 실행 쿼터와 지연 시간은 어떻게 달라지나요?

n8n Cloud 환경에서는 부모 워크플로가 트리거한 Sub-workflow 실행이 월별 프로덕션 실행 횟수(Production Executions)에 중복으로 계산되지 않아요. 상위 부모 워크플로의 실행 1건만 카운트되므로 모듈화된 하위 워크플로를 분리해도 요금제 쿼터 부담이 커지지 않아요.

다만 지연 시간과 서버 메모리 점유 측면에서는 차이가 커요. 대기 모드를 쓰면 자식의 작업이 끝날 때까지 부모의 실행 컨텍스트가 워커 프로세스 메모리에 그대로 머물러요. 외부 웹훅으로 부모를 호출한 상황에서 자식이 수십 초 이상 지연되면 호출자 쪽에 HTTP 타임아웃이 발생할 수 있어요.

구분	완료 대기 활성화 (기본)	비동기 실행 (대기 비활성화)
실행 방식	동기식 대기	비동기식 즉시 진행
자식 결과 참조	최종 노드 출력 데이터를 부모가 사용 가능	부모 노드의 출력이 비어 참조 불가
오류 전파	자식 실패 시 부모 노드도 오류 중단	자식 실패가 부모로 전파되지 않음
부모 지연 시간	자식 워크플로 실행 시간에 비례해 증가	호출 직후 즉시 종료되어 지연 최소화
권장 업무	데이터 변환, 조회 결과 기반 분기	알림 발송, 비동기 로그 저장, 파일 백업

확인일: 2026-10-25 KST (출처: n8n 공식 문서 Execute Sub-workflow 사양)

실무 워크플로에 적용하기 전에 무엇을 점검하나요?

운영 중인 파이프라인에 Execute Sub-workflow 노드를 넣기 전에 다음 조건을 차례대로 점검해보세요.

자식 워크플로의 결과값이 부모 후속 노드의 조건문이나 파라미터로 꼭 필요한지 확인해요.
자식 워크플로의 시작 노드가 Webhook이 아니라 Execute Sub-workflow Trigger 노드로 연결되었는지 살펴봐요.
자식 워크플로 실패 시 전체 작업을 즉시 중단해야 하는지, 아니면 격리하고 부모를 마쳐야 하는지 결정해요.
비동기 대기 해제 방식을 택했다면 자식 실패를 추적할 Error Trigger 워크플로를 등록해 두었는지 확인해요.

먼저 테스트용 부모 워크플로와 자식 워크플로를 각각 만들고, 정상 데이터와 강제 오류 데이터를 번갈아 흘려보내며 부모 실행 기록에 어떤 상태가 남는지 확인해보세요.

자주 묻는 질문

자식 워크플로에서 대기 옵션을 끄면 반환 데이터를 아예 못 받나요?

네, 부모의 Execute Sub-workflow 노드는 자식의 실행 완료를 기다리지 않으므로 출력 데이터가 비어 있어요. 자식의 처리 결과가 필요하면 대기 옵션을 켜야 해요.

Sub-workflow를 여러 번 호출하면 n8n Cloud 실행 횟수가 각각 차감되나요?

아니에요, n8n Cloud 공식 정책에서 부모 워크플로가 호출한 Sub-workflow 실행은 월별 프로덕션 실행 쿼터에 중복으로 계산되지 않아요.

자식 워크플로의 오류가 부모로 번지는 것을 막으려면 어떻게 하나요?

완료 대기 옵션을 끄거나, 부모의 Execute Sub-workflow 노드 설정에서 Continue On Fail을 활성화하면 돼요.

--- 공식 출처: n8n Docs (확인일 2026-10-25 KST) - Execute Sub-workflow Node: https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.executeworkflow/ - Execute Sub-workflow Trigger Node: https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.executeworkflowtrigger/ - Sub-workflows Architecture: https://docs.n8n.io/workflows/subworkflows/