자동화는 워크플로(스킬)에 붙인 트리거입니다. 워크플로는 무엇을 할지를, 자동화는 언제 할지를 정합니다. 둘이 합쳐지면, 예전에 직접 타이핑하던 요청이 손을 대지 않아도 돌아가는 일이 됩니다.
캘린더 알림은 일을 하라고 재촉합니다. 자동화는 일을 끝낸 다음 끝났다고 알려줍니다.
모든 자동화는 세 가지를 지정합니다.
- 실행할 워크플로
- 그것을 실행하는 에이전트 — 어조, 모델, 사용할 커넥터를 결정합니다
- 트리거 — 스케줄, 도구에서 일어나는 이벤트, 또는 들어오는 웹훅
실행마다 일어나는 일
트리거가 발동할 때마다 새로운 채팅이 시작됩니다. 채팅은 도구에서 최신 컨텍스트를 다시 읽고, 필요한 커넥터를 호출해 결과를 만듭니다.
이것이 중요한 이유는 두 가지입니다.
- 누적된 상태가 없습니다. 지난 월요일의 실행이 이번 월요일로 새어 들어가지 않습니다. 절차는 같고, 데이터는 최신입니다.
- 모든 실행을 다시 볼 수 있습니다. 자동화의 실행 기록을 열면 마지막 실행이 무엇을 했는지, 어디에 크레딧을 썼는지, 무엇을 만들었는지 정확히 확인할 수 있습니다.
실행이 실패하면 — 네트워크 끊김, 만료된 토큰, 모호한 입력 — Zero는 이유와 함께 실패를 기록하고, 조용히 넘기지 않고 알려줍니다.
트리거 종류
스케줄
가장 흔한 계열입니다. 자동화가 일정한 주기로 실행됩니다 — 매일, 매주, 매시간, 직접 쓴 cron 식, 고정 간격, 또는 지정한 시각에 한 번.
| 트리거 | 발동 시점 |
|---|---|
cron | 지정한 시간대의 cron 식에 따라 — 0 8 * * 1-5 |
once | 지정한 날짜와 시각에 딱 한 번 |
loop | 고정 간격마다 — 15m, 1h, 90s |
시점을 말하는 네 가지 방법. cron을 쓸 필요는 없습니다.
- 자연어. "평일 오전 8시, 로스앤젤레스 시간" — Zero가 해석합니다. 시간대, 근무일, "매월 1일", "격주 금요일" 모두 동작합니다. 대부분의 팀이 이 방식을 씁니다.
- cron 식.
0 8 * * 1-5. 정밀한 제어가 필요할 때 씁니다. 옆에 IANA 시간대(Asia/Seoul,America/Los_Angeles)를 함께 지정하세요. - 간격.
15m,1h,90s마다 —loop입니다. 벽시계에 맞출 필요가 없는 헬스 체크와 폴러에 적합합니다. - 일회성. 지정한 날짜와 시각에 한 번만 발동하는
once. 출시, 엠바고, 마감에 묶인 알림에 유용합니다.
시간대를 지정하지 않은 스케줄은 UTC로 실행됩니다. 읽는 사람에게 "오전 9시"가 뜻하는 것과는 거의 다르니, 시간대를 반드시 지정하세요.
머릿속에 남아 있는 반복적인 "해야 하는데…"는 거의 다 후보입니다. 평일 오전 8시 모닝 브리프, 매주 월요일 주간 지표 다이제스트, 매일 저녁 받은편지함 정리, 30분마다 프로덕션 헬스 체크, 분기 마지막 달 25일의 이사회 준비 등.
시계가 아니라 이벤트에서 시작해야 하는 일이라면 — 메일 도착, PR 승인, 페이지 게시 — 아래 트리거들이 더 잘 맞고, 폴링으로 실행을 낭비하지 않습니다.
이메일
| 트리거 | 발동 시점 |
|---|---|
gmail-new-message | 새 메시지가 도착할 때 |
gmail-label-applied | 지정한 라벨이 메시지에 붙을 때 |
둘 다 보낸사람, 받는사람, 참조, 제목, 본문에 대한 텍스트 규칙으로 좁힐 수 있고, 각각 포함과 포함하지 않음을 지원합니다. 규칙이 없으면 Gmail 자동화는 들어오는 모든 메시지에 걸리므로, 좁게 시작하세요.
받은편지함을 지켜보지 않고 지원 메일을 분류하기:
from-contains: @고객-도메인.com으로 거른gmail-new-message가 검토용 초안을 준비하는customer-reply-draft워크플로를 실행합니다.
GitHub
| 트리거 | 발동 시점 |
|---|---|
github-label-applied | 이슈나 PR에 라벨이 붙을 때 — 라벨, 저장소, 이슈/PR/둘 다, 행위자가 본인인지 누구든인지로 필터링 |
github-workflow-run-completed | Actions 실행이 끝날 때 — 저장소, 워크플로, 결과, 브랜치, 트리거 이벤트, 행위자로 필터링 |
github-workflow-job-completed | 개별 잡이 끝날 때 — 추가로 잡 이름, 러너 라벨, 러너 그룹으로 필터링 |
github-pull-request-review-submitted | 리뷰가 제출될 때 — 리뷰 상태(승인, 변경 요청, 코멘트), base·head 브랜치, 신뢰 작성자로 필터링 |
github-deployment-status-created | 배포 상태가 바뀔 때 — 환경, 상태, ref, 생성자, 앱, 프로덕션 전용 여부로 필터링 |
github-issue-comment-created | 댓글이 달릴 때 — 저장소, 이슈/PR/둘 다, 행위자, 필수 댓글 접두사로 필터링 |
GitHub 트리거는 워크스페이스에 GitHub App이 설치되어 있어야 합니다. 필터는 쉼표로 구분한 값을 받고, 생략하면 모두와 일치합니다.
CI 루프를 닫기:
main의conclusion: failure에 대한github-workflow-run-completed가 로그를 읽고 실패한 단계를 찾아 Slack에 진단을 올리는 워크플로를 실행합니다.
캘린더
| 트리거 | 발동 시점 |
|---|---|
google-calendar-event-created | 새 일정이 생길 때 |
google-calendar-event-updated | 일정이 바뀔 때 |
google-calendar-event-cancelled | 일정이 취소될 때 |
각각 하나의 캘린더를 감시하며, 기본값은 기본 캘린더입니다.
회의에 맨몸으로 들어가지 않기:
google-calendar-event-created가 외부 참석자와 그들의 회사를 조사해 회의 전 브리프를 보내는 워크플로를 실행합니다.
Notion
| 트리거 | 발동 시점 |
|---|---|
notion-child-page-created | 지정한 상위 페이지 아래에 페이지가 추가될 때 |
notion-database-item-created | 지정한 데이터베이스에 행이 추가될 때 |
notion-page-content-updated | 페이지 내용이 바뀔 때. 페이지 단위 또는 데이터베이스 단위로 감시 |
CMS
| 트리거 | 발동 시점 |
|---|---|
strapi-entry-published | 항목이 게시될 때 — 특정 콘텐츠 타입과 로케일로 좁힐 수 있음 |
웹훅과 채팅
| 트리거 | 발동 시점 |
|---|---|
webhook | 외부 시스템이 서명된 웹훅 URL을 호출할 때. 서명 시크릿은 생성 시 한 번만 표시되므로 그때 복사하세요. Team과 Enterprise에서 사용 가능. |
chat-run-finished | 지정한 채팅 스레드에서 실행이 끝날 때 — 종료 상태(완료, 실패, 취소)와 실행의 마지막 메시지에 대한 와일드카드 패턴으로 필터링 가능 |
chat-run-finished는 일을 이어 붙이는 방법입니다. 한 자동화의 결과가 다음 자동화의 출발 신호가 됩니다.
자동화 만들기
잘 돌아간 채팅에서 만들기. 먼저 일회성으로 작업을 실행해 보세요. 원하는 결과가 나오면 이렇게 말합니다.
"이걸 평일 오전 8시 로스앤젤레스 시간에 실행하고 결과를 DM으로 보내줘."
Zero가 워크플로, 주기, 전달 대상을 확인하고, 워크플로가 아직 없으면 저장한 뒤 자동화를 붙입니다.
명시적으로 만들기. 워크스페이스에서 워크플로를 열고 트리거 종류와 필터를 골라 자동화를 추가합니다. 형태를 미리 알고 있고 드라이런이 필요 없을 때 편합니다.
자동화는 삭제하지 않고 개별로 활성화·비활성화할 수 있습니다. 휴가 전이나 시끄러운 트리거를 디버깅하는 동안 쓰기 좋습니다.
전달 대상
자동화는 결과가 어디로 갈지 알아야 합니다. 워크플로 지시문에 적어 두세요.
- Slack 채널 또는 DM — 가장 흔하며, 채널에 메시지나 스레드로 도착합니다
- Feishu 또는 Microsoft Teams — 그곳에서 일하는 팀을 위한 같은 방식
- Telegram 또는 문자 메시지 — 모바일 우선의 개인 알림용
- Notion 페이지나 데이터베이스 — 널리 알리기보다 보관해야 할 것들
- Google 문서나 스프레드시트 — 덧붙이거나 덮어쓰기
- GitHub 이슈나 PR 댓글 — 엔지니어링 워크플로용
- Gmail 초안 — 계정에 준비되어, 검토 후 보내면 됩니다
- 호스팅된 페이지 — 공개 URL로 공유할 결과물용
- 워크스페이스 파일 — 결과물이 영상, 이미지, 다운로드 가능한 자산일 때
"#engineering에 올려줘" 나 "DM으로 보내줘" 가 "어딘가로 보내줘" 보다 명확합니다.
운영 팁
프로덕션에서 자동화를 돌리며 얻은 것들입니다.
- 처음 세 번의 실행을 지켜보세요. 자동화는 설정이 쉽지만, 내 환경에서 Zero가 실제로 무엇을 내놓는지 본 뒤에 다듬으면 훨씬 단단해집니다.
- 작업을 작게 유지하세요. 길고 여러 단계인 자동화일수록 잘 깨집니다. 하나가 다섯 개 시스템을 갱신해야 한다면 둘로 나누는 편을 고려하세요.
- 전달 대상을 고정하세요. 채널은 이름이 바뀌고 사람은 떠납니다. 워크플로 지시문에 대상을 이름으로 명시해 두면, 다음 실행에서 찾지 못할 때 Zero가 경고합니다.
- 긴 조회에는 기간을 못 박으세요. 프롬프트가 "최근 30일"을 요구한다면 매 실행마다 다시 적어야 기간이 최신으로 유지됩니다.
- 시간대를 신경 쓰세요. 시간대가 없는 스케줄은 UTC로 실행됩니다.
- 휴가 전에는 일시 중지하세요. 특히 DM을 보내는 자동화라면, 돌아와서 브리프 DM 14개를 마주해도 쓸모가 없습니다. 자동화를 비활성화했다가 복귀 후 다시 켜세요. 워크플로는 그대로 남습니다.
비용
실행마다 크레딧이 들고, 모든 실행은 그것을 돌린 에이전트에 귀속됩니다. 실행 기록에 실행당 크레딧 비용이 표시되므로 비싼 것을 찾아낼 수 있습니다. 모닝 브리프는 보통 저렴해서 수백 크레딧, 여러 도구를 쓰는 주간 콘텐츠 묶음은 1~2천 크레딧 정도입니다. 달러 환산은 크레딧 및 청구를 참고하세요.
짧은 loop 간격은 금세 불어납니다. 15분마다면 하루 96회입니다.
이벤트 트리거는 생각보다 수다스러울 수 있습니다. 필터 없는 Gmail 자동화나 활발한 모노레포 전체를 대상으로 한 GitHub 자동화는 예상보다 훨씬 자주 발동합니다. 먼저 좁게 거르고, 그다음 넓히세요.