자동화의 중심을 어디에 둘 것인가
AX가 진행되면 자동화 조각이 늘어납니다. 메일 처리 하나, 보고서 하나, 알림 하나. 각각은 잘 돌아갑니다.
문제는 그다음입니다. 조각이 열다섯 개가 되면 그중 무엇이 언제 깨지는지 아무도 모르는 상태가 됩니다. 앞선 글에서 짚은 "자동화를 관리하는 것 자체가 일이 되는" 지점이 여기입니다.
이걸 막는 방법은 조각을 줄이는 게 아니라, 조각들이 한곳에서 보이게 만드는 것입니다. n8n을 중심에 둔다는 건 그런 뜻입니다.
n8n이 오케스트레이터로 적합한 이유
n8n은 7년간 개발되어 온 워크플로 도구이고, GitHub 스타 18만을 넘겼습니다. 규모 자체보다 중요한 건 이 도구가 흐름 제어를 일급으로 다룬다는 점입니다.
AI 도구 대부분은 "좋은 답을 만드는 것"을 중심에 둡니다. n8n은 "이 일이 언제 시작하고, 실패하면 어떻게 되고, 지금 어디까지 갔는지"를 중심에 둡니다. AX 운영에서 실제로 사람을 괴롭히는 건 후자입니다.
구체적으로 다음이 기본으로 제공됩니다.
- 트리거 — 스케줄, 웹훅, 파일 변경, 메일 수신
- 분기와 조건 — 앞 글의 핸드오프 조건을 그대로 노드로 표현
- 재시도와 오류 처리 — 실패한 실행만 따로 잡아 처리
- 실행 로그 — 어떤 데이터가 어느 노드에서 어떻게 변했는지 단계별로 남음
마지막 항목이 특히 큽니다. 실행 로그가 없는 자동화는 디버깅이 불가능합니다. 결과만 틀리게 나오고 이유를 알 수 없는 상태가 됩니다.
중심에 둔다는 것의 실제 구조
권장하는 형태는 이렇습니다.
바깥 껍질은 전부 n8n이 담당합니다. 언제 시작할지, 어디서 데이터를 가져올지, 어떤 조건에서 사람에게 넘길지, 실패하면 누구에게 알릴지, 결과를 어디에 기록할지.
안쪽 판단만 외부에 위임합니다. 모델 호출, 문서 검색, 분류. 이 부분은 Dify든 직접 API 호출이든 상관없습니다.
이 구조의 이점은 교체 가능성입니다. 모델을 바꾸거나 지식 도구를 바꿔도 바깥 흐름은 그대로입니다. 반대로 흐름을 각 도구 안에 흩어 두면, 도구를 바꿀 때마다 흐름을 다시 만들어야 합니다.
처음 만들 때 지킬 것
1. 하나의 워크플로는 하나의 업무만
앞선 글에서 다룬 "한 에이전트에 한 역할" 원칙과 같습니다. 편의상 여러 업무를 한 워크플로에 밀어 넣으면, 한 곳이 깨졌을 때 전부 멈춥니다.
2. 입력 검증을 첫 노드로 둔다
들어온 데이터가 예상한 모양인지 먼저 확인합니다. 이 노드 하나가 뒤쪽 열 개 노드의 오류를 막습니다. 예상과 다르면 처리하지 말고 기록하고 알립니다.
3. 사람에게 넘기는 지점을 노드로 명시한다
조건 분기 뒤에 승인 대기 노드를 두고, 대기 시간 초과 시 에스컬레이션 경로를 붙입니다. 앞 글에서 "가장 자주 빠지는 항목"이라고 한 부분이 이것입니다. 도구 안에 그림으로 그려 두면 빠뜨리기 어렵습니다.
4. 실패 알림을 별도 워크플로로 분리한다
각 워크플로마다 알림 로직을 복사해 넣지 마세요. 실패를 받아 처리하는 워크플로 하나를 만들고 전부 그쪽으로 보냅니다. 알림 채널을 바꿀 때 한 곳만 고치면 됩니다.
5. 자격 증명을 노드에 박지 않는다
n8n의 credential 기능을 씁니다. 워크플로를 내보내거나 공유할 때 키가 함께 새어 나가는 사고가 여기서 갈립니다.
자주 겪는 함정
노드가 많아지면 읽을 수 없게 된다
워크플로 하나가 화면을 세 번 스크롤해야 하면 이미 너무 큽니다. 서브 워크플로로 쪼개세요. 읽을 수 없는 자동화는 고칠 수 없는 자동화입니다.
테스트 데이터로만 검증하고 끝낸다
실제 데이터에는 빈 값, 이상한 인코딩, 예상 못 한 길이가 들어옵니다. 앞 글에서 다룬 "한 단계가 빠진 것"이 여기서 나옵니다.
성공만 기록한다
실패한 실행을 지우지 마세요. 실패 로그가 다음 개선의 재료입니다.
중심을 하나 두는 이유는 성능이 아니라 관측 때문입니다.
스크립트 열다섯 개가 각자 돌아가는 조직은 그 열다섯 개가 언제 깨지는지 아무도 모르는 조직이기도 합니다. 한 곳으로 모으면 최소한 어디를 봐야 하는지는 알게 됩니다.
느려지는 구간이 생기더라도 그 대가는 치를 만했습니다.
