n8n 같은 워크플로 도구의 장점은 빨리 자란다는 것이고 단점도 빨리 자란다는 것입니다. 기능을 붙일 때마다 노드가 늘어나 어느새 화면 가득한 모놀리스가 됩니다. 해외 매장의 왓츠앱 자동화도 처음엔 워크플로 하나였습니다. 번역, 스케줄, 정산, 영수증이 전부 그 안에 있었고 어느 시점부터 수정이 무서워졌습니다. 그것을 역할별 모듈 일곱 개로 분해한 과정과 기준을 정리합니다.
모놀리스의 한계 신호
워크플로 하나가 너무 커졌다는 신호는 뚜렷합니다.
- 한 기능을 고치는데 다른 기능이 걱정된다 (변경 반경을 모름)
- 실행 이력에서 어느 기능이 실패했는지 한눈에 안 보인다
- 새 기능을 붙일 자리를 찾는 데 시간이 걸린다
- 부분 테스트가 안 되고 전체를 돌려야 확인된다
이 신호들이 겹치면 분해할 때입니다. 우리 경우 번역 로직 수정이 영수증 처리를 건드릴까 봐 배포를 미루는 지경이 분기점이었습니다.
n8n 모듈화 구조: 게이트웨이 + 역할별 하위 워크플로
n8n 워크플로 모듈화의 뼈대는 "얇은 게이트웨이, 두꺼운 모듈"입니다.
- 게이트웨이(인그레스) 워크플로: 웹훅으로 메시지를 받아 정규화하고, 방별 역할 설정을 조회해 해당 하위 워크플로를 호출합니다. 판단은 라우팅뿐, 업무 로직은 없습니다.
- 역할별 하위 워크플로 6종: 번역, 영수증·인보이스, 스케줄, 일일정산, 설정 동기화, 질의응답. 각자 자기 일만 알고, 서로를 모릅니다.
이 구조에서 기능 수정의 반경은 하위 워크플로 하나로 좁혀집니다. 번역 프롬프트를 바꿔도 영수증 흐름은 문자 그대로 다른 워크플로라 영향이 없습니다. 실행 이력도 워크플로 단위로 갈라져 어느 기능이 실패했는지 목록에서 바로 보입니다.
분해 기준은 기술 단위가 아니라 역할(업무) 단위였습니다. "LLM 호출 모듈, 시트 기록 모듈"처럼 기술로 자르면 한 업무의 수정이 다시 여러 모듈을 건드립니다. "영수증 처리"처럼 업무로 자르면 그 업무의 요구 변경이 그 모듈 하나로 끝납니다.
분해를 안전하게 만드는 두 가지
구조 전환은 그 자체가 리스크라, 두 장치를 함께 뒀습니다.
첫째, 구 모놀리스의 롤백 보존입니다. 분해 후에도 원래 워크플로를 비활성 상태의 아카이브로 남겨 신 구조에 문제가 생기면 즉시 되돌릴 수 있게 했습니다. 대체하는 것과 지우는 것은 다른 결정이고 지우는 것은 훨씬 나중에 해도 됩니다.
둘째, 회귀 검증 스크립트입니다. 각 워크플로의 핵심 경로(라우팅 응답, 설정 캐시, 발송 게이트 등)를 확인하는 검증 스크립트를 열여덟 종까지 쌓아 배포 전 게이트로 돌렸습니다. 노코드·로우코드 도구라고 테스트가 없어도 되는 것이 아니라, 오히려 코드 리뷰가 없는 만큼 실행 가능한 검증이 더 필요합니다.
모듈 사이의 공유 상태는 한 곳에
분해하면 공유 데이터의 문제가 따라옵니다. 방별 역할, 은어사전 같은 설정을 모듈마다 제각기 읽으면 불일치가 생깁니다. 우리는 설정 동기화 워크플로 하나만 원본(구글 시트)을 읽고 그 결과를 브리지의 캐시에 원자적으로 쓰게 해 단일 기록자(single writer)를 유지했습니다. 다른 모듈은 캐시만 읽습니다. 모듈화의 성패는 모듈 수가 아니라 공유 상태의 규율에서 갈립니다.
| 설계 요소 | 선택 | 효과 |
|---|---|---|
| 분해 축 | 역할(업무) 단위 | 요구 변경의 반경 = 모듈 1개 |
| 게이트웨이 | 라우팅만, 로직 없음 | 진입점 단순 · 안전 기본값 |
| 구 버전 | 비활성 아카이브 보존 | 즉시 롤백 가능 |
| 검증 | 배포 전 회귀 스크립트 | 노코드의 테스트 공백 보완 |
| 공유 상태 | 단일 기록자 + 캐시 | 모듈 간 불일치 차단 |
이 구조가 실제로 굴러가는 시스템은 왓츠앱 번역 자동화 사례에서 볼 수 있습니다. 단계 분리의 같은 원리를 코드 기반 파이프라인에 적용한 사례는 GitHub Actions 무인 배치에서, 노코드와 맞춤 개발 사이의 선택 기준은 콘텐츠 자동화 노코드 vs 맞춤에서 다룹니다.
자주 묻는 질문
n8n 워크플로는 언제 나눠야 하나요?
수정의 공포가 신호입니다. 한 기능을 고치며 다른 기능의 오작동을 걱정하게 되면, 실행 이력에서 기능별 실패가 구분되지 않으면 나눌 때입니다. 노드 수 자체보다 변경 반경을 아는가가 기준입니다.
어떤 기준으로 나누는 게 좋나요?
기술 단위가 아니라 업무 역할 단위를 권합니다. "번역", "영수증 처리"처럼 요구사항이 변하는 단위로 나눠야 변경이 모듈 하나로 끝납니다. 진입점에는 라우팅만 하는 얇은 게이트웨이를 두고 업무 로직은 하위 워크플로에 담는 구조가 안정적입니다.
나눈 뒤 워크플로끼리 데이터는 어떻게 공유하나요?
공유 설정은 단일 기록자 원칙으로 다룹니다. 한 워크플로만 원본을 읽어 캐시에 쓰고 나머지는 캐시를 읽게 하면, 모듈마다 원본을 제각기 읽어 생기는 불일치와 동시 쓰기 충돌이 사라집니다.
노코드 도구에도 테스트가 필요한가요?
필요합니다. 코드 리뷰와 타입 검사가 없는 환경일수록 실행 가능한 검증이 유일한 안전망입니다. 핵심 경로를 확인하는 스크립트를 배포 전 게이트로 두면, 워크플로 수정이 코드 수준의 규율로 관리됩니다.