서브워크플로우 — 재사용 가능한 모듈 설계

🎯 학습 목표

이 강을 마치면 다음을 할 수 있습니다.

• Execute Workflow 노드로 다른 워크플로우를 서브루틴처럼 호출합니다.
• 입력 파라미터를 서브워크플로우에 전달하고 출력값을 반환받습니다.
• 슬랙 알림, 오류 로깅 같은 공통 로직을 별도 서브워크플로우로 모듈화합니다.
• 대형 자동화 시스템을 역할 기반으로 분리하는 구조화 전략을 이해합니다.

💡 서브워크플로우가 필요한 이유 — 코드의 함수처럼

이 섹션에서는 서브워크플로우 개념이 왜 필요한지, 소프트웨어 설계 원칙과 연결해 살펴보겠습니다.

처음 n8n을 배울 때는 하나의 워크플로우 안에 모든 로직을 넣습니다. 이 방식은 단순할 때는 문제없지만, 자동화 규모가 커지면 다음 문제들이 발생합니다. 첫째, 중복입니다. 10개의 워크플로우에서 각각 슬랙 알림을 보내는 로직을 넣으면, 슬랙 채널 이름이 바뀔 때 10곳을 모두 수정해야 합니다. 둘째, 복잡도입니다. 하나의 워크플로우에 50개, 100개의 노드가 있으면 캔버스가 엉키고 이해하기 어려워집니다. 셋째, 테스트 어려움입니다. 긴 워크플로우의 특정 부분만 테스트하기 어렵습니다.

프로그래밍에서는 이 문제를 함수(Function)로 해결합니다. 반복되는 로직을 함수로 분리하고, 필요할 때 호출합니다. n8n에서는 이에 해당하는 것이 서브워크플로우입니다. 반복되는 로직을 별도의 워크플로우로 만들고, "Execute Workflow" 노드로 호출합니다. 입력값을 전달하고 출력값을 받는 방식도 함수와 동일합니다.

🔧 서브워크플로우 설계 — 구조와 트리거

이 섹션에서는 서브워크플로우로 사용할 워크플로우를 만드는 방법을 살펴보겠습니다.

서브워크플로우로 사용할 워크플로우는 트리거로 Execute Workflow Trigger를 사용합니다. 이 트리거는 다른 워크플로우에서 Execute Workflow 노드로 호출될 때 실행됩니다. 일반 트리거(Schedule, Webhook 등)와 달리 외부에서 직접 호출되는 전용 트리거입니다.

서브워크플로우의 기본 구조는 세 부분으로 나뉩니다. 첫 번째는 입력 수신(Execute Workflow Trigger)입니다. 호출자가 전달한 데이터가 이 노드를 통해 들어옵니다. 두 번째는 로직 처리입니다. 핵심 작업(알림 발송, 데이터 처리 등)을 수행합니다. 세 번째는 출력 반환입니다. 마지막 노드의 출력이 호출자에게 반환됩니다. 호출자는 이 데이터를 다음 노드에서 사용할 수 있습니다.

중요한 점은 서브워크플로우도 n8n에서 활성화된 워크플로우여야 한다는 것입니다. 비활성 상태면 Execute Workflow 노드가 오류를 냅니다. 서브워크플로우는 활성화해 두되, Schedule·Webhook 같은 자동 실행 트리거가 없으므로 스스로 실행되지는 않습니다.

📞 Execute Workflow 노드 — 호출하기

이 섹션에서는 메인 워크플로우에서 서브워크플로우를 호출하는 Execute Workflow 노드 설정을 살펴보겠습니다.

Execute Workflow 노드를 메인 워크플로우에 추가합니다. "Workflow" 필드에서 호출할 서브워크플로우를 선택합니다(워크플로우 이름으로 검색 가능). 이것만으로도 기본 호출은 완성됩니다.

입력 파라미터 전달은 두 가지 방법으로 합니다. 첫 번째는 자동 전달입니다. Execute Workflow 노드의 "Pass Input To Subworkflow" 옵션을 활성화하면, 현재 아이템이 그대로 서브워크플로우에 전달됩니다. 두 번째는 필드 매핑입니다. "Fields" 옵션에서 전달할 필드를 명시적으로 정의합니다. 예를 들어 message 필드에 {{ $json.errorMessage }}를, channel 필드에 #alerts를 전달하는 방식입니다.

서브워크플로우의 반환값은 Execute Workflow 노드의 출력으로 나옵니다. 이후 노드에서 {{ $json.result }}처럼 서브워크플로우가 반환한 필드에 접근할 수 있습니다. 이를 통해 서브워크플로우에서 처리 결과(성공 여부, 생성된 ID 등)를 메인 워크플로우로 전달할 수 있습니다.

📦 공통 로직 모듈화 — 실전 패턴

이 섹션에서는 여러 워크플로우에서 반복되는 공통 작업을 서브워크플로우로 분리하는 실전 패턴을 살펴보겠습니다.

패턴 1: 알림 서브워크플로우. 슬랙 알림을 보내는 로직을 별도 워크플로우로 분리합니다. 서브워크플로우는 message(알림 내용), channel(대상 채널), level(info/warning/error)을 입력으로 받습니다. 내부에서 level에 따라 이모지와 색상을 다르게 설정해 슬랙으로 발송합니다. 이제 모든 워크플로우에서 슬랙 알림이 필요할 때 이 서브워크플로우를 Execute Workflow 노드로 호출하기만 하면 됩니다. 슬랙 채널 변경 등 수정 사항이 생기면 서브워크플로우 한 곳만 수정합니다.

패턴 2: 로깅 서브워크플로우. 워크플로우 실행 이력을 DB나 Google Sheets에 기록하는 로직을 모듈화합니다. 서브워크플로우는 workflowName, status(success/failure), details, timestamp를 받아 지정된 시트나 DB 테이블에 행을 추가합니다. 모든 워크플로우 실행 이력이 한 곳에 집계됩니다.

패턴 3: 데이터 변환 서브워크플로우. 복잡한 데이터 정제·변환 로직을 분리합니다. 예를 들어 주소 형식 정규화, 전화번호 포맷 통일, 이름 대소문자 처리 같은 공통 데이터 정제 로직을 서브워크플로우로 만들면, 다양한 소스의 데이터가 항상 일관된 형식으로 정제됩니다.

🏗️ 대형 워크플로우 구조화 전략

이 섹션에서는 수십 개의 워크플로우로 구성된 자동화 시스템을 체계적으로 관리하는 방법을 살펴보겠습니다.

자동화가 확장되면 워크플로우가 수십, 수백 개가 됩니다. 이를 관리하는 효과적인 전략을 세 가지 소개합니다.

첫 번째는 역할 기반 분리입니다. 워크플로우를 역할에 따라 그룹화합니다. 트리거 워크플로우(이벤트 수신, 스케줄 실행), 비즈니스 로직 워크플로우(핵심 처리), 서비스 서브워크플로우(알림, 로깅, 공통 처리)로 나눕니다. n8n의 "Tags" 기능을 활용해 각 워크플로우에 역할 태그를 붙이면 관리가 쉬워집니다.

두 번째는 이름 규칙(Naming Convention)입니다. 워크플로우 이름만 보고 역할을 알 수 있게 합니다. 예를 들어 [TRIGGER] 주문 완료 이벤트, [MAIN] 결제 처리, [SUB] 슬랙 알림 발송처럼 접두사를 붙입니다. 수십 개의 워크플로우 목록에서 원하는 것을 빠르게 찾을 수 있습니다.

세 번째는 의존성 문서화입니다. 어떤 워크플로우가 어떤 서브워크플로우를 호출하는지를 문서화합니다. n8n에는 이를 자동으로 시각화하는 기능이 없으므로, 노션이나 구글 독스에 의존성 맵을 관리합니다. 서브워크플로우를 수정할 때 영향 범위를 파악하는 데 필수입니다.

📝 핵심 요약

개념	핵심 내용
서브워크플로우 트리거	Execute Workflow Trigger. 외부 호출로만 실행됨
호출 노드	Execute Workflow. 워크플로우 선택 + 파라미터 전달
입출력	아이템 자동 전달 또는 필드 매핑. 반환값은 출력 아이템으로
모듈화 패턴	알림·로깅·데이터 정제 공통 로직 분리
구조화 전략	역할 기반 분리 + 이름 규칙 + 의존성 문서화

다음 강이 이 시리즈의 마지막 강입니다. 지금까지 배운 모든 것을 통합해 AI 뉴스레터 완전 자동화 시스템을 처음부터 끝까지 직접 구현합니다. 트리거부터 RSS 수집, AI 요약, 이메일 발송, 결과 기록까지 전체 파이프라인을 완성하며 n8n AI 자동화 역량을 마무리합니다.