노코드로 파이프라인 연결하기: 트리거→액션

6장 "팔로업·딜 관리 자동화: 시퀀스·리마인더·제안서"에서 각 단계의 규칙을 세웠습니다. 문제는 그 규칙들이 아직 도구마다 따로 논다는 데 있습니다. 폼은 폼대로, CRM은 CRM대로, 슬랙은 슬랙대로. 이걸 손으로 옮기는 순간 자동화는 절반만 완성된 셈입니다. 이번 장에서는 노코드 도구로 흩어진 단계를 하나의 파이프라인으로 잇습니다. 코드는 거의 쓰지 않습니다.

노코드 자동화 3종을 먼저 고른다

도구를 이어 붙이는 접착제 역할을 하는 노코드 플랫폼은 사실상 세 가지로 좁혀집니다. 셋 다 "트리거(이벤트) → 액션(후속 처리)" 구조는 같지만, 로직 표현력과 과금 방식이 갈립니다. 아래 표의 통합 수는 업계에서 흔히 인용되는 추정 범위이며, 요금·플랜은 결제주기·지역·제품군에 따라 자주 바뀌므로 계약 전에 각 공식 요금표에서 최신 조건을 반드시 확인하는 편이 안전합니다.

세 플랫폼 비교

Zapier는 통합 수가 압도적이라 "일단 붙는다"가 강점입니다. 반대로 n8n은 소스 공개형 Community Edition을 자체 서버에 올려 셀프호스팅할 수 있어, 플랫폼이 실행 횟수로 과금하지는 않고 PII·규제 데이터를 자사 인프라 안에서 처리하기 좋습니다. 다만 이는 공인 OSI 오픈소스와는 라이선스 성격이 다르고, 서버 자원·라이선스 조건이라는 제약이 남는다는 점을 함께 봐야 합니다. Make는 그 중간에서 시각적 분기 제어가 세밀합니다.

통합 수만 보고 고르지 않는다

"앱 몇 개 연결되나"는 함정입니다. 실제로는 자신이 쓸 통합의 API 커버리지 깊이가 훨씬 중요합니다. HubSpot 연동이 있다고 해도 딜 단계 변경 트리거까지 지원하는지는 별개입니다. 표에 적힌 통합 수는 어디까지나 카탈로그 규모일 뿐, 내 업무에 필요한 이벤트·필드가 실제로 잡히는지는 무료 플랜이나 체험 기간에 직접 붙여 봐야 확실해집니다.

2026년 AI 에이전트 기능

세 플랫폼 모두 최근 AI 에이전트 기능을 붙이는 흐름입니다. Zapier는 목표를 지시하면 연결된 앱을 활용해 후속 단계를 판단하는 에이전트 기능을 제공하는데, 여기서 카탈로그의 전체 통합 앱 수와 에이전트가 실제로 조작할 수 있는 앱 범위는 별개이니 공식 문서로 지원 범위를 확인하는 편이 좋습니다. 함께 제공되는 가드레일류 기능도 민감정보·프롬프트 인젝션 위험을 "완화"하는 보조 장치일 뿐 보편적으로 차단한다고 보기는 어렵고, 탐지·차단 한계는 문서 기준으로 따로 확인해야 합니다. Make도 AI 에이전트 제품을 별도로 내놓았으며 제품 상태·출시 시점은 공식 발표로 확인하는 것이 정확합니다. n8n은 LangChain 기반 에이전트 노드로 OpenAI·Anthropic·Mistral·로컬 Ollama 등을 연결합니다.

트리거→액션→필터로 생각한다

노코드 워크플로우는 문장 하나로 요약됩니다. "무언가 일어나면(트리거), 조건에 맞을 때만(필터), 이걸 한다(액션)."

세 요소의 역할

트리거는 시작점입니다. 신규 폼 제출, 새 리드 생성, 딜 단계 변경 같은 이벤트가 여기 해당합니다. 필터는 관문입니다. "회사 이메일인 경우에만" "예산 필드가 채워진 경우에만" 통과시켜 불필요한 실행을 막습니다. 액션은 실제 작업입니다. CRM 레코드 생성, 슬랙 알림, 이메일 발송이 이어집니다.

필터가 비용을 좌우한다

필터를 잘 걸면 태스크 소모가 줄어듭니다. 참고로 Zapier는 트리거·필터·Paths 조건 단계에는 과금하지 않고 성공한 액션에만 과금하는 구조로 알려져 있으므로, 앞단에서 걸러낼수록 청구서가 가벼워지는 경향이 있습니다. 이런 과금 단위는 플랫폼마다 다르니 자신이 쓰는 제품의 최신 정책을 확인해 두는 편이 좋습니다.

세일즈 엔드투엔드 워크플로 만들기

개념을 실제 파이프라인 세 개로 옮겨 봅니다. 모두 실무에서 흔히 쓰는 템플릿 구성입니다.

워크플로 1 — 폼 → CRM

1. 웹폼 제출 → Webhooks가 페이로드 캡처
2. Formatter로 전화번호·우편번호·이름 포맷 표준화
3. CRM에 연락처/딜 레코드 생성(담당자·파이프라인·단계 매핑)

가장 기본이면서 손이 제일 많이 가던 일입니다. 여기까지만 자동화해도 데이터 입력이 크게 줄어듭니다.

워크플로 2 — 신규 리드 → enrich → 슬랙 알림

1. 인바운드 리드 웹훅 수신
2. 리드 enrichment로 정보 보강
3. CRM에서 Find or Create(기존 리드 확인 후 없으면 생성 — 중복 방지)
4. 캠페인 출처를 담아 슬랙에 요약 알림

영업 담당자가 새 리드를 놓치지 않고 빠르게 반응하도록 돕는 흐름입니다.

워크플로 3 — 미팅 종료 → 요약 → CRM → 팔로업 태스크

1. 미팅 요약 업데이트 감지
2. CRM 노트 생성 + 연락처 매칭
3. 후속 태스크 자동 스케줄
4. 액션아이템 링크와 함께 슬랙 게시

n8n에서는 회의녹음·트랜스크립트 서비스를 노드로 연결해 요약→액션아이템 추출 후 CRM 갱신과 태스크 생성까지 한 번에 묶는 구성도 만들 수 있습니다. 설치 난이도와 소요 시간은 대상 서비스·환경에 따라 다르니, 실제로 붙여 보며 확인하는 편이 정확합니다.

웹훅·에러 처리·비용을 관리한다

이 세 가지를 놓치면 파이프라인은 조용히 멈추는 경우가 많습니다. 실전에서 제일 자주 사고가 나는 지점입니다.

웹훅이란 무엇인가

웹훅은 이벤트가 일어날 때 소스 시스템이 목적지로 보내는 HTTP 요청입니다. 클라이언트가 계속 물어보는 API(pull)와 달리 웹훅은 이벤트 발생 즉시 데이터를 밀어주는(push) 방식이라 실시간 트리거로 씁니다. 보안은 비밀 토큰이나 HMAC-SHA256 서명으로 스푸핑을 막는 것이 일반적입니다.

재시도와 중복 실행 방지

상당수 플랫폼은 일시적 오류가 나면 일부 요청을 자동으로 재시도합니다. 다만 재시도 횟수·간격·대상은 오류 유형과 앱·플랜에 따라 달라지므로, 구체 정책은 각 플랫폼 공식 문서에서 확인하는 편이 안전합니다.

중복은 더 까다롭습니다. A→B와 B→A로 양방향 동기화하면 무한루프가 생기기 쉽습니다. 각 방향에 "이미 처리됨" 플래그를 남기고, Create 대신 Find or Create를 써서 존재 여부부터 확인하는 것이 정석입니다. 세밀한 에러 라우팅이 필요하면 Make의 전역 에러 핸들러나 n8n의 전용 Error Workflow가 Zapier보다 유리한 경우가 많습니다.

비용과 노코드의 한계

진짜 비용은 구독료가 아니라 디버깅 시간과 우회 작업입니다. 유료 플랜에 서명하기 전에 월간 사용량을 먼저 모델링하는 것을 권합니다. 사용량 알림 기능이 지원되면 한도 근처에서 알림이 오도록 설정하고, 없으면 별도 모니터링을 구성해 두면 청구서 사고를 줄일 수 있습니다. 규모가 커지면 과금 차이가 극명해집니다. 10단계 × 월 5,000회 실행이면 Zapier는 5만 태스크로 계산되지만 n8n은 5,000 execution으로 끝납니다. 거래량이 폭증하거나, 상태 유지·복잡한 분기가 필요하거나, 엄격한 저지연·실시간 응답 SLA가 요구되면 노코드의 한계에 부딪힐 수 있습니다. 그럴 때는 실제 지연을 측정한 뒤 커스텀 코드로 넘어갈지 판단하는 것이 좋습니다.

흔한 실수 세 가지

• 에러 무음화: 조용한 실패로 몇 주간 리드가 새어나갑니다. 첫 달은 매주, 안정화 후엔 매월 에러율을 리뷰하세요.
• 비용 폭탄: 청구서가 오기 전까지 실행 한도를 무시하는 것. 사전 모델링 + 사용량 알림·모니터링이 답입니다.
• PII 노출: 민감 데이터가 벤더 서버를 경유합니다. 비즈니스 등급 DPA를 쓰거나 셀프호스팅 n8n으로 자사 인프라 안에서 처리하세요.

여기까지가 파이프라인을 실제로 잇는 방법입니다. 트리거→필터→액션으로 흐름을 그리고, 웹훅·재시도·중복 방지·비용 알림이라는 안전장치를 함께 걸면 손을 떼도 도는 시스템이 됩니다. 완성한 워크플로는 모켓 꿀조합에서 유사 조합과 비교해 다듬어도 좋습니다.

다음 챕터에서는 '실전 구축·측정·주의: 1인 스택과 지표, 규정'을 다룹니다. 예산별로 도구 스택을 짜고, 무엇을 측정하며, 한국의 개인정보 규정에서 무엇을 조심해야 하는지 정리하겠습니다.