Make vs Zapier: 두 가지 모두에서 동일한 자동화를 실행했습니다.

같은 주에 두 도구 모두에 동일한 3단계 자동화를 구축했습니다. 즉, 양식 제출을 관찰하고 AI 호출로 이를 강화한 다음 결과를 스프레드시트와 Slack 채널에 푸시합니다. Zapier 버전은 20분 정도 걸렸습니다. Make 버전은 3시간이 걸렸고 스파게티처럼 보였습니다. 흥미로운 부분은 그 이후에 두 가지를 모두 한 달 동안 실행했을 때 일어난 일입니다.

설정은 Zapier가 승리하는 곳이며 가깝지 않습니다. 트리거 및 작업 모델은 소스 앱을 선택하고, 대상을 선택하고, 필드를 매핑하면 작동한다는 것을 의미합니다. Make는 시각적 프로그래밍 도구입니다. 모듈, 분기 및 변환을 사용하여 캔버스를 구축합니다. 그 힘은 진짜이며, 이것이 나의 첫 번째 Make 자동화가 찾는 데 오후가 걸린 매핑 버그가 있었던 이유이기도 합니다.

그런 다음 청구서가 도착했습니다. Zapier는 작업당 비용을 청구하며 작업은 대략 자동화가 수행하는 모든 단계이므로 3단계 흐름에서는 실행당 3개의 작업이 소모됩니다. 훨씬 더 미세한 입자로 작업을 계산하지만 넉넉한 작업 수당을 판매하며 몇 단계를 넘어서는 작업의 경우 차이가 미미하지 않습니다. 동일한 로직을 옮기는 것만으로도 월별 자동화 비용이 약 2/3 정도 줄었습니다.

기대하지 않았던 부분은 역으로 신뢰성이었습니다. Zapier의 실패 메시지는 명확하고 앱 연결 라이브러리는 엄청납니다. 저는 결코 직접 통합하지 않았을 도구에 대한 기본 커넥터를 찾았습니다. 내 앱 두 개에 필요한 웹후크와 포맷터 단계를 만듭니다. 즉, 이제 Zapier 사용자가 무료로 얻을 수 있는 코드를 유지관리한다는 의미입니다.

따라서 정직한 대답은 누가 운영하는지에 따라 다릅니다. 기술 전문가가 아닌 사람이 워크플로를 소유하고 그것이 주류 앱에 영향을 미치는 경우 Zapier는 커넥터 라이브러리와 오류 메시지에 대한 프리미엄 가치가 있습니다. 기술 담당자가 이를 소유하고 워크플로에 분기 또는 루프가 있거나 볼륨으로 인해 작업별 가격 책정이 어려워지면 비용과 기능 면에서 유리합니다. 중첩 영역이 작습니다.

아무도 작성하지 않는 마이그레이션 조언: 더 저렴한 도구를 사용하기 위해 작동 중인 Zapier를 이동하지 마십시오. 실제 비용이 들기 시작하거나 흐름에 Zapier가 표현할 수 없는 논리가 필요한 경우 이동하세요. 그때까지는 재건에 들인 시간이 절약한 돈보다 더 가치가 있습니다.

자주 묻는 질문:

Q: Make가 Zapier보다 정말 저렴합니까?

A: 다단계 자동화의 경우 그렇습니다. 복잡성이 높아질수록 격차는 더욱 커집니다. 작업당 Zapier 청구서는 대략 단계당을 의미하며 훨씬 더 많은 수당이 포함된 작업당 청구서를 작성합니다. 간단한 2단계 흐름의 경우 차이는 작습니다. 워크플로우 분기의 경우에는 그렇지 않습니다.

Q: 기술적인 지식이 없는 사용자에게는 어느 것이 더 쉬운가요?

A: 자피어(Zapier)입니다. 트리거 및 작업 빌더에는 시스템의 정신적 모델이 필요하지 않으며 오류 메시지를 통해 무엇이 문제인지 알려줍니다. Make는 당신이 데이터 매핑을 이해하고 있다고 가정하고 불평 없이 오후 11시에 디버깅할 수 있도록 해줄 것입니다.

Q: Zapier를 Make로 마이그레이션할 수 있나요?

A: 네, 하지만 수출이 아닌 재구축입니다. 트리거 이름은 매핑되지만 필드 매핑은 그렇지 않습니다. 한 번에 하나의 워크플로를 마이그레이션하고 이전 워크플로를 한 달 동안 병렬로 실행한 다음 로그를 통해 새 워크플로가 실제로 동일한지 알려줍니다.