재피어 필터와 Paths 차이: 자동화가 중단될 때와 분기할 때 설계표

제휴 및 광고 고지: 이 글은 자동화 도구의 기능과 설계 판단을 설명하는 정보성 글입니다. 일부 링크에는 제휴 또는 광고 성격이 포함될 수 있으며, 실제 플랜·화면·지원 범위는 도입 전에 공식 문서에서 다시 확인해야 합니다.

마지막 검토일: 2026-08-04

먼저 정리하는 결론

재피어 필터와 Paths 차이는 조건식을 얼마나 복잡하게 쓰느냐가 아니라, 조건에 맞지 않는 데이터를 멈출 것인지, 아니면 다른 행동으로 보낼 것인지에 있습니다. 특정 조건을 통과한 건만 다음 단계로 보내면 Filter를 선택하고, 조건별로 서로 다른 작업을 실행해야 하면 Paths를 선택합니다. 실제 오류가 난 경우에는 데이터 분기용 Paths보다 error handler와 오류 기록을 먼저 검토합니다.

이 구분은 재피어 메일 자동 분류처럼 특정 앱을 연결하는 방법과는 다른 주제입니다. 기존의 재피어 메일 자동 분류 글가 업무 사례라면, 이 글은 그 사례에서 조건과 결과를 나누는 제어 흐름을 다룹니다.

이 글에서 분리하는 세 가지 상태

1. 통과하지 않은 데이터

예를 들어 Gmail에서 들어온 메일 중 제목에 ‘견적’이 있는 건만 담당자 시트에 저장한다고 가정합니다. 견적이 아닌 메일을 다른 앱으로 보낼 필요가 없다면 Filter가 자연스럽습니다. Filter는 조건을 통과한 데이터만 다음 action으로 보내고, 통과하지 않은 실행은 그 지점에서 더 진행하지 않습니다.

2. 결과가 여러 갈래인 데이터

검색 단계에서 고객을 찾았으면 기존 레코드를 업데이트하고, 찾지 못했으면 새 레코드를 만드는 식이라면 한 가지 중단 조건으로는 부족합니다. 이때는 Paths로 ‘찾음’과 ‘찾지 못함’을 각각 action에 연결합니다. 여러 결과를 모두 운영해야 하므로, 각 경로의 이름·조건·최종 행동을 별도로 기록해야 합니다.

3. 조건이 아니라 실행 자체가 실패한 상태

필수 입력값이 비었거나 연결 계정의 권한이 없거나 외부 앱이 429를 반환한 것은 ‘어느 고객 유형인가’와 다른 문제입니다. Zapier 공식 도움말은 오류가 발생한 action에 error handler를 붙여 대체 흐름을 만들 수 있다고 설명합니다. 따라서 정상 데이터의 분기는 Paths로, 실행 실패의 복구·알림은 error handler로 분리하는 편이 원인을 추적하기 쉽습니다.

Filter를 선택하는 기준

Zapier 공식 Filter 설정 안내는 trigger 다음에 Filter 단계를 추가하고, 확인할 field·규칙·비교값을 지정하는 흐름을 설명합니다. 하나의 Filter에 여러 조건을 넣을 수도 있지만, 조건을 늘리기 전에 ‘탈락한 데이터에 할 일이 정말 없는가’를 먼저 적어야 합니다.

Filter 설계표

Filter는 ‘통과하지 않은 항목을 삭제하는 기능’이 아닙니다. 특히 line items를 다룰 때는 이후 단계에 원래 목록을 매핑할 수 있으므로, Filter가 목록 자체에서 탈락 항목을 제거한다고 가정하면 안 됩니다. Filter와 path 규칙 공식 문서는 line items에서 양·음 조건에 따라 계속 진행되는 방식이 달라질 수 있고, Filter가 line items를 제거하지 않는다고 안내합니다.

AND와 OR를 적는 순서

Filter에 ‘제목에 견적 포함’과 ‘보낸 사람 주소가 존재함’을 함께 넣는다면 두 조건이 모두 필요한 경우 AND를 씁니다. 제목에 견적 또는 상담이 들어오면 통과시키려면 OR 그룹을 씁니다. 다만 OR로 넓혀 놓고 이후 action에서 같은 데이터를 다시 제한하면, 어느 단계에서 탈락했는지 확인하기 어려워집니다.

날짜나 요일 필터는 원본 field에 실제로 어떤 형식이 들어오는지부터 봐야 합니다. Zapier의 요일·시간 Filter 공식 안내도 날짜 값에 요일 문자열이 포함되는지 확인한 뒤 조건을 설계하도록 설명합니다. 화면에서 보이는 값과 실제 field 값이 다르면 ‘Exactly matches’ 대신 다른 규칙이 필요할 수 있습니다.

Paths를 선택하는 기준

Paths는 하나의 입력을 여러 결과 중 하나 이상으로 보낼 때 쓰는 구조입니다. Zapier의 Paths 공식 안내는 각 branch에 조건을 만들고, Custom rules·Always run·Fallback 같은 방식으로 실행 조건을 정할 수 있다고 설명합니다.

경로를 만들기 전 적는 네 칸

1. 입력에서 반드시 확인할 field는 무엇인가? 2. 정상적인 결과의 종류는 몇 개인가? 3. 어느 조건에도 맞지 않을 때 보낼 Fallback이 필요한가? 4. 각 경로의 마지막 action과 사람이 확인할 지점은 무엇인가?

예를 들어 고객 검색 결과에 이메일이 있으면 이메일 업데이트를 하고, 이메일이 없고 전화번호만 있으면 전화 확인 목록에 넣고, 둘 다 없으면 Fallback으로 보류 목록에 기록할 수 있습니다. 이 구조는 ‘조건이 안 맞으면 끝’이 아니라 ‘맞는 결과에 맞는 작업’을 남겨야 할 때 유리합니다.

Paths의 실행 순서도 설계 대상

Paths의 branch는 동시에 실행된다고 가정하면 안 됩니다. 공식 문서에 따르면 branch는 편집기에서 왼쪽에서 오른쪽 순서로 순차 평가·실행되고, 앞쪽 branch에 Delay 같은 느린 action이 있으면 뒤쪽 branch가 기다릴 수 있습니다. 시간에 민감한 알림이라면 branch 순서, Delay 위치, 분리할 Sub-Zap 여부를 기록합니다.

두 경로가 동시에 맞을 수 있다면 조건을 더 구체적으로 만들어야 합니다. 예를 들어 ‘이메일이 존재하면 A’, ‘전화번호가 존재하면 B’만 적으면 이메일과 전화번호가 모두 있는 레코드가 두 경로로 갈 수 있습니다. B에 ‘전화번호 존재 AND 이메일 미존재’를 추가하면 서로 배타적인 경로가 됩니다.

Filter와 Paths를 한 표에서 고르는 법

질문을 결과로 바꾸는 판단표

여기서 ‘Paths가 더 고급이므로 항상 좋다’고 판단하면 안 됩니다. 결과가 하나뿐인데 Paths를 만들면 분기 구조와 테스트 지점만 늘어납니다. 반대로 여러 결과를 Filter 하나로 억지로 줄이면, 탈락한 데이터의 다음 행동과 누락 원인이 사라집니다.

세 가지 실무 예시

#### 예시 A: 견적 문의만 저장

Gmail trigger에서 제목과 본문을 확인한 뒤 ‘견적’ 또는 ‘제안’이 포함된 메일만 Google Sheets에 저장한다고 합시다. 상담 일반 문의도 같은 시트에 넣어야 한다면 Filter 하나로 끝내지 말고, 유형별로 기록할지 Paths를 검토합니다. 현재 autopickgo의 재피어 메일 자동 분류 글는 이 사례의 업무 흐름을, 이 글은 그 안의 분기 선택을 보완합니다.

메일 라벨과 회신 초안의 역할을 함께 보고 싶다면 지메일 견적 문의 자동 분류 글에서 입력·긴급도·회신 초안의 경계를 먼저 확인한 뒤, 이 글의 Filter와 Paths 판단표를 적용할 수 있습니다.

#### 예시 B: 고객 검색 결과에 따른 업데이트·생성

검색 단계가 `found=true`를 반환하면 기존 고객을 업데이트하고, `found=false`면 새 고객을 생성합니다. 이때 Search 결과가 비어도 다음 Paths 단계로 전달될 수 있도록 검색 단계의 ‘찾지 못했을 때 계속’ 설정을 먼저 확인합니다. 이후 Paths A와 B가 서로 겹치지 않는지 샘플 데이터 두 종류로 각각 확인합니다.

#### 예시 C: action에서 권한 오류가 난 경우

CRM action에서 403이 발생했다면 ‘고객 유형 A와 B 중 어느 쪽인가’를 분기할 일이 아닙니다. 연결 계정, 필요한 권한, field 값, 앱의 상태를 확인하고, 필요하면 해당 action에 error handler를 붙여 담당자에게 오류 메시지를 기록합니다. 오류가 난 이전 step의 출력이 다음 단계에 그대로 전달된다고 가정하지 않는 것도 중요합니다.

설정 순서: 작은 샘플로 시작하기

1. 입력과 결과를 문장으로 고정

먼저 “새 폼 응답이 들어오면 어떤 조건으로 어떤 action을 실행한다”를 한 줄로 씁니다. ‘문의 자동화’처럼 넓은 문장 대신 “이메일이 있고 동의가 true인 신청만 CRM 리드로 만든다”처럼 field와 결과를 함께 적습니다.

2. Filter·Paths·error handler의 경계를 표시

아래처럼 정상 흐름과 실패 흐름을 다른 색 또는 다른 문서 행으로 기록합니다.

3. 샘플 데이터 네 종류를 준비

• 조건을 모두 만족하는 정상 데이터
• 조건 하나가 빠진 데이터
• 두 branch가 모두 맞을 수 있는 경계 데이터
• 권한·필수값·형식 오류를 재현할 수 있는 안전한 테스트 데이터

실제 고객이나 결제·계약 데이터로 처음부터 테스트하지 않습니다. Zapier 공식 Zap 단계 테스트 안내는 action 테스트가 연결된 앱에 실제 변경을 만들 수 있다고 설명합니다. 테스트 버튼을 눌렀다는 사실만으로 안전한 검증이 끝났다고 보지 말고, 샘플 계정·더미 레코드·삭제 가능한 테스트 대상부터 사용합니다.

4. Filter와 모든 Paths를 따로 테스트

Filter는 통과·중단 케이스를 각각 확인하고, Paths는 각 branch와 Fallback을 한 번씩 확인합니다. 테스트 결과에는 다음 네 항목을 남깁니다.

태스크와 요금제를 기록하는 방법

Filter와 Paths를 선택할 때 ‘단계를 추가하면 모두 같은 비용이 든다’고 계산하면 안 됩니다. Zapier의 태스크 사용량 공식 안내는 trigger와 Filter·Paths 단계는 태스크로 계산하지 않고, 성공한 action 단계 등을 기준으로 사용량을 설명합니다. 다만 계정의 플랜 한도와 청구 방식은 변할 수 있으므로, 이 글에서 특정 금액을 고정하지 않습니다.

한 번 실행할 때 적는 계산표

Filter가 task를 쓰지 않는다는 점만 보고 action을 늘려도 된다는 뜻은 아닙니다. Paths의 각 branch에 action을 여러 개 넣으면 성공 실행 때마다 실제 사용량과 처리 복잡도가 함께 커질 수 있습니다. 먼저 사람이 검수해야 하는 단계 하나를 남기고, 한 주의 샘플 실행으로 예상치와 실제 사용량을 비교합니다.

오류는 분기와 다르게 복구하기

조건 분기와 오류 복구의 차이

Filter와 Paths는 정상 입력을 어느 다음 행동으로 보낼지 결정합니다. 반면 error handler는 action이 실패했을 때 대체 흐름을 실행하는 장치입니다. Zapier error handler 공식 안내는 오류가 난 action의 오류 메시지를 이후 handler 단계에서 매핑할 수 있다고 설명하지만, trigger나 Paths 단계 자체에는 error handler를 붙일 수 없다고 안내합니다.

Zapier의 오류 troubleshooting 공식 안내도 Errored, Safely halted, Handled error, On hold를 구분해 보도록 설명합니다. 모든 비정상 상태를 Filter 탈락으로 뭉뚱그리면, 실제로는 권한을 고쳐야 하는 오류를 조용히 놓칠 수 있습니다.

발행 전 10분 점검표

아래 항목에 답하지 못하면 Zap을 켜기보다 조건과 샘플을 다시 정리합니다.

• [ ] 이 자동화가 처리하는 독자·업무 순간을 한 문장으로 적었는가?
• [ ] 조건에 맞지 않은 데이터는 정말 다른 action이 필요 없는가?
• [ ] 다른 action이 필요하다면 Paths의 branch와 Fallback을 만들었는가?
• [ ] 두 branch가 동시에 맞는 경계 샘플을 테스트했는가?
• [ ] AND와 OR의 의미를 실제 field 값으로 재현했는가?
• [ ] Text·Number·Date/time·Boolean 규칙을 올바른 field type에 적용했는가?
• [ ] line items가 Filter 통과 여부 때문에 삭제된다고 잘못 가정하지 않았는가?
• [ ] action 테스트가 외부 앱에 실제 변경을 만들 수 있음을 확인했는가?
• [ ] 권한·필수값·429·422 같은 오류를 정상 데이터 분기와 분리했는가?
• [ ] 성공 action 수와 계정 태스크 한도를 기록했는가?
• [ ] 고객·결제·계약·개인정보가 포함되면 사람의 최종 확인 지점을 남겼는가?

자주 묻는 질문

Filter와 Paths를 함께 써도 되나요?

가능합니다. 먼저 Filter로 처리 대상이 아닌 입력을 걸러낸 뒤, 통과한 데이터만 Paths로 여러 결과에 보낼 수 있습니다. 다만 Filter 뒤에 Paths를 둘 때는 어떤 데이터가 어느 단계에서 사라졌는지 run 기록에서 구분할 수 있도록 단계 이름을 구체적으로 적습니다. Paths를 추가한 뒤의 action 배치와 마지막 단계 제한은 현재 편집기의 공식 안내를 확인해야 합니다.

Filter 대신 Paths를 쓰면 더 많은 데이터를 보존하나요?

반드시 그렇지는 않습니다. Filter는 조건 밖 실행을 더 진행하지 않고, Paths는 조건에 맞는 branch의 action을 실행합니다. 원본 데이터를 보존하려면 별도의 로그 action이나 입력 저장소를 설계해야 하며, Paths를 선택하는 것만으로 탈락 데이터가 자동 저장되지는 않습니다.

Paths branch는 동시에 실행되나요?

공식 안내 기준으로 branch는 순차적으로 평가·실행됩니다. 앞쪽에 지연이 있거나 실행 시점이 중요한 action이 있다면 순서가 결과에 영향을 줄 수 있습니다. 병렬 처리가 필요한 경우에는 여러 Zap으로 나눌지, Sub-Zap 구조가 맞는지 따로 검토합니다.

오류가 났을 때 Paths로 오류 branch를 만들면 되나요?

조건 field가 정상적으로 전달된 상태에서 ‘성공 유형’을 나누는 것이라면 Paths가 맞을 수 있습니다. 그러나 action이 실패해 다음 field 자체가 나오지 않는 상황은 error handler, 오류 알림, 연결 권한 점검으로 먼저 다룹니다. 두 문제를 같은 branch로 합치면 원인과 복구 기록이 흐려집니다.

Filter와 Paths는 태스크를 사용하나요?

Zapier 공식 태스크 문서에서는 Filter와 Paths 자체를 태스크로 계산하지 않는다고 안내합니다. 하지만 경로 안의 성공 action은 사용량에 포함될 수 있고, 플랜 한도·청구 방식은 계정과 시점에 따라 달라질 수 있습니다. 실제 계정의 사용량 화면과 최신 공식 문서를 함께 확인하세요.

다음 행동

새 자동화를 만들기 전에 최근 반복 업무 10건을 모아 ‘멈출 데이터’와 ‘다른 행동이 필요한 데이터’를 나눠 보세요. 전자가 대부분이면 Filter 하나로 시작하고, 후자가 실제 운영의 핵심이면 Paths와 Fallback을 설계합니다. 어느 쪽이든 고객에게 나가는 메시지·금액·계약·개인정보가 포함되면 더미 데이터로 테스트한 뒤 사람이 최종 결과를 확인합니다.

앱을 연결하는 큰 구조가 필요하면 메이크 자동화 시나리오 초보 구조 글를, 알림을 실제 업무에 연결할 때는 슬랙 견적 알림 자동화 글과 함께 비교할 수 있습니다. 기존 시나리오를 그대로 복사하기보다, 입력·조건·결과·오류·사람 확인 지점을 표로 먼저 적는 것이 다음 수정의 기준이 됩니다.

공식 자료 확인 링크

• Zapier 공식 Filter 설정 안내
• Zapier 공식 Paths 설정 안내
• Zapier 공식 Filter와 path 규칙 안내
• Zapier 공식 요일·시간 Filter 안내
• Zapier 공식 Zap 단계 테스트 안내
• Zapier 공식 태스크 사용량 안내
• Zapier 공식 error handler 설정 안내
• Zapier 공식 오류 troubleshooting 안내

이 글은 기능 선택과 테스트 기록을 돕는 일반 안내입니다. 특정 계정의 자동화 성공, 비용 절감, 검색 노출, 매출 또는 업무 결과를 보장하지 않으며, 실제 운영 전에는 연결 앱의 권한·약관·개인정보 처리·최신 요금제와 공식 도움말을 확인해야 합니다.