스케줄은 작업을 반복 주기 — 매일, 매주, 매시간, 또는 사용자 지정 cron — 로 실행하고, 결과를 원하는 곳에 게시합니다.
캘린더 알림은 당신에게 일을 하라고 요청합니다. 스케줄은 일을 직접 하고, 끝났다고 알려줍니다.
작업이 스케줄이 되고 싶어 할 때
머릿속에 있는 거의 모든 반복적인 "내가 해야 하는데..."가 후보입니다. 패턴은 이렇습니다. 그 일이 가치 있고, 예측 가능하며, 건너뛰었을 때의 비용이 실재하지만 쉽게 무시된다는 것.
VM0에서 실제로 쓰이는 예시들입니다.
- 아침 브리핑 평일 매일 오전 8시 — 읽지 않은 Slack 멘션, 열린 PR, 캘린더, 집중 제안
- 주간 지표 요약 매주 월요일 — 지난주 수치 대 전주 대비,
#metrics에 게시 - 받은 편지함 정리 매일 저녁 — 뉴스레터 보관, 발신자별 라벨링, 긴급 답장 초안 작성
- 프로덕션 상태 점검 30분마다 — 대시보드 조회, 지표가 정상 범위를 벗어나면 온콜 호출
- 금요일 콘텐츠 배포 오후 2시 — 블로그 초안 + LinkedIn 게시물 + 소셜 카드를 검토용으로 묶음
- 분기말 이사회 준비 세 번째 달 25일 — 지표 수집, 내러티브 초안 작성, 덱 생성
반복 캘린더 알림에 넣을 법한 것이라면 무엇이든 후보입니다.
스케줄 만들기
두 가지 방법이 있습니다. 맞는 것을 고르세요.
작동하는 채팅에서. 먼저 작업을 일회성으로 실행합니다. 원하는 결과가 나오면 이렇게 말하세요.
"이걸 평일 매일 로스앤젤레스 시간 오전 8시에 실행하고 결과를 나에게 DM으로 보내줘."
Zero가 주기, 작업, 목적지를 확인합니다. 현재 채팅이 스케줄의 본문이 됩니다. 나중에 편집하거나 일시 중지할 수 있습니다.
명시적으로, 처음부터. 워크스페이스에서 Schedules 페이지를 열고 스케줄을 직접 작성합니다. 형태를 미리 알고 있고 시험 실행을 하고 싶지 않을 때 유용합니다.
매번 실행되는 것
각 스케줄은 새로운 채팅을 실행합니다. 그 채팅은 도구에서 최신 컨텍스트를 다시 읽고, 필요한 커넥터를 호출하며, 결과를 생성합니다.
이는 두 가지 이유로 중요합니다.
- 누적된 상태 없음. 지난 월요일의 실행이 이번 월요일로 새어 들어오지 않습니다. 스케줄은 같은 형태이고, 데이터는 새롭습니다.
- 각 실행은 재생 가능. 스케줄의 기록을 열면 마지막 실행이 정확히 무엇을 했고, 어디에 크레딧을 썼으며, 무엇을 생성했는지 볼 수 있습니다.
실행이 실패하면 — 네트워크 끊김, 만료된 토큰, 모호한 입력 — Zero는 그 이유와 함께 실패를 기록하고 소리 없이 넘기지 않고 당신에게 알립니다.
Cron, 평이한 영어, 또는 사람의 주기
세 가지 방식으로 타이밍을 지정할 수 있습니다.
- 평이한 영어. "평일 매일 로스앤젤레스 시간 오전 8시" — Zero가 이를 해석합니다. 시간대, 근무일, "매월 1일", "격주 금요일" 모두 작동합니다.
- Cron 표현식. "0 8 * * 1-5" — 정밀한 제어를 위해.
- 사람의 주기. "매일", "매주", "매월"과 Zero가 선택한 기본 시간(보통 워크스페이스 현지 시간 오전 9시).
평이한 영어 방식이 대부분의 팀이 선택하는 것입니다. Cron은 필요할 때를 위해 있습니다.
목적지
스케줄은 결과가 어디로 가는지 알아야 합니다.
- Slack 채널 또는 DM — 가장 흔함. 결과가 메시지나 스레드로 채널에 도착합니다
- Notion 페이지 또는 데이터베이스 — 방송하기보다 보관해야 할 것들을 위해
- Google Doc 또는 Sheet — 추가되거나 덮어쓰기됨
- GitHub 이슈 또는 PR 댓글 — 엔지니어링 워크플로를 위해
- 워크스페이스 파일 — 아티팩트가 동영상, 이미지, 또는 다운로드 가능한 자산일 때
프롬프트에 목적지를 지정하세요. "#engineering에 게시" 또는 *"나에게 DM"*이 *"어딘가에 보내"*보다 명확합니다.
프로덕션에서 스케줄을 운영하며 얻은 팁
- 첫 세 번의 실행을 지켜보세요. 스케줄은 설정하기 쉽습니다. 당신의 환경에서 Zero가 실제로 무엇을 생성하는지 본 뒤에 다듬기가 더 쉽습니다.
- 각 작업을 작게 유지하세요. 길고 여러 단계로 된 스케줄은 더 취약합니다. 하나의 스케줄이 다섯 개 시스템을 업데이트해야 한다면 둘로 나누는 것을 고려하세요.
- 목적지를 고정하세요. 채널 이름이 바뀌고 사람이 떠납니다. 스케줄 본문에 목적지를 이름으로 언급하세요. 다음 실행에서 찾을 수 없으면 Zero가 경고합니다.
- 오래 실행되는 쿼리에 기간을 명시하세요. 프롬프트가 "지난 30일"을 요구한다면, 창이 항상 최신이도록 매 실행마다 이를 다시 명시하세요.
- 휴가 전에 일시 중지하세요. 특히 당신에게 DM을 보내는 스케줄은 — 돌아와서 14개의 브리핑 DM을 마주하는 것은 유용하지 않습니다. Schedules 페이지에서 일시 중지하고, 돌아오면 재개하세요.
비용
각 실행은 크레딧을 소비합니다. Schedules 페이지는 각 스케줄의 실행당 평균 크레딧 비용을 보여주므로, 비싼 것을 찾아낼 수 있습니다. 아침 브리핑은 보통 저렴합니다(수백 크레딧). 주간 멀티 도구 콘텐츠 묶음은 1~2천 크레딧일 수 있습니다. 이것이 달러로 어떻게 환산되는지는 Credits & billing을 참조하세요.
다음 단계
- 자주 사용하는 패턴을 이름 뒤에 두는 방법은 Skills를 참조하세요.
- 각 실행 중에 무슨 일이 일어나는지는 Chat을 참조하세요.
- 다섯 가지 엔드투엔드 스케줄 + 스킬 조합은 Example workflows를 참조하세요.