메일이 오면 도는 자동화와 아침 9시에 도는 자동화는 다른 물건입니다 — 8월 25일 ChatGPT가 연 사건 트리거에서 먼저 정할 세 칸

아침 6시 브리핑, 월요일 9시 리포트.
지금까지 사업자가 붙일 수 있던 예약 자동화는 대개 시각표였습니다.

8월 25일 ChatGPT 예약 작업이 사건으로도 돌기 시작했습니다. 특정 발신자의 Gmail이 오면, 지정한 Slack 채널에 글이 올라오면, GitHub 풀 리퀘스트에 움직임이 있으면.

도구 이름보다 중요한 건 이 둘이 다른 물건이라는 점입니다. 회사에 들이기 전에 대표가 정할 칸이 셋 있습니다.

체인지로그 원문은 다섯 문장입니다. 앞의 둘을 그대로 옮깁니다.

"ChatGPT scheduled tasks can now run when supported events occur in Gmail, Slack, or GitHub. Filter Gmail messages by sender or subject, watch selected Slack channels, or respond to pull request activity such as reviews, comments, commit updates, and merges."

발신자나 제목으로 거른 Gmail, 지정한 Slack 채널의 새 글, 풀 리퀘스트의 리뷰·댓글·커밋·머지.
이 셋이 8월 25일부터 작업을 깨우는 사건입니다.

도움말 문서에는 시각표와 사건형의 관계를 한 줄로 가르는 문장이 있습니다.

"The trigger determines when the task runs; the saved prompt determines what each run does." 이어서 "One task can use multiple event triggers, but it can't combine event triggers with a time-based schedule."

언제 돌지는 방아쇠가 정하고, 돌 때 무엇을 할지는 저장된 지시문이 정합니다. 그리고 한 작업에 사건 방아쇠와 시각표를 같이 걸 수는 없습니다.

이 글은 ChatGPT 화면 조작법을 다루지 않습니다. 어느 요금제에서 열리는지도 원문에 'eligible plans'라고만 적혀 있어 여기서 정하지 않습니다.

시각은 도구가 정해 주지만, 사건은 회사가 정의해야 생깁니다.

시각표 자동화는 정해진 시각에 무조건 돕니다. 확인할 변동이 없으면 빈 보고서가 나오고, 그 빈 보고서가 곧 살아 있다는 증거가 됩니다.

저희가 7월에 상담한 리셀 커머스 대표의 요청이 그 전형입니다.

대표가 원한 건 변동이라는 사건입니다. 그런데 붙인 건 하루 두 번 조회라는 시각표였습니다. 조회 시각을 고르는 대표의 말에 그 이유가 그대로 있습니다.

남들이 10시에 고치니 12시에 보면 잡힌다.
시각표가 사건을 흉내 내는 방식이고, 대부분의 회사가 지금까지 이렇게 해 왔습니다.

이 방식은 변동이 없는 날에도 12시와 24시에 어김없이 돕니다. 빈 결과가 쌓이는 대신, 멈추면 바로 티가 납니다.

사건형은 반대입니다. 조건에 맞는 메일이 안 오면 아무것도 돌지 않습니다. 조용한 하루가 정상인지 고장인지를 화면만 봐서는 알 수 없습니다.

시각표 쪽 설계는 노트북을 닫아도 일이 돌아가게 하는 글에 적어 두었습니다. 이 글은 그 옆 칸입니다.

시각표는 빈 보고서로 살아 있음을 알리고, 사건형은 조용합니다.

Gmail 방아쇠는 발신자와 제목으로 거릅니다. 원문은 이 조건이 선택 사항이라고 적습니다.

"Gmail: New incoming messages, optionally filtered by sender or subject."

조건을 안 걸면 받은 메일 전부가 사건입니다. 뉴스레터와 광고가 작업을 깨우고, 결과 알림은 며칠 안에 안 읽는 알림이 됩니다.

공고 감시 글에서 세운 원칙이 여기에도 그대로 옵니다. 조건 없는 알림은 며칠 만에 안 읽는 알림이 됩니다. 조건이 살아남아야 감시가 삽니다.

반대로 너무 좁히면 놓칩니다. 거래처가 제목을 바꿔 보내면 그 메일은 사건이 아니게 됩니다.

그러니 조건은 한 번에 맞히는 게 아니라 첫 몇 번의 실행을 보고 고치는 칸입니다. 도움말도 같은 순서를 권합니다.

"Review the first few runs, then adjust the prompt, tools, or cadence if the results are too broad or need additional context."

사건이 아닌 것도 원문에 적혀 있습니다. Slack에서는 반응, 수정, 삭제, 다이렉트 메시지가 방아쇠가 되지 않습니다.

"Reactions, edits, deletes, and direct messages aren't supported."

거래처가 DM으로 보내는 회사라면 이 방아쇠는 그 거래처를 못 봅니다. 채널로 받는 규칙이 먼저입니다.

넓으면 스팸이 되어 다시 안 보고, 좁으면 놓칩니다. 조건은 첫 실행을 보고 고치는 칸입니다.

원문이 그대로 말합니다.

"When matching events arrive close together, ChatGPT may combine them in one run."

비슷한 시각에 사건이 여럿 오면 한 번에 묶여 돌 수 있습니다. 메일 다섯 통이 한 번의 실행으로 처리된다는 뜻입니다.

이게 괜찮은 업무가 있고 안 되는 업무가 있습니다.

앞의 리셀 대표가 원한 시세 확인은 괜찮은 쪽입니다. 다섯 사이트의 변동이 한 표에 같이 들어와도 보는 사람은 한 명이고, 보는 목적도 하나입니다.

견적 요청은 반대쪽입니다. 건마다 따로 나가야 할 회신이 한 실행 안에서 처리되므로, 어느 건에 답이 나갔는지는 그 실행을 열어 봐야 압니다.

원문은 대기 중인 사건을 사람이 볼 수 있다고도 적습니다.

"Open Scheduled to review pending events or choose Run now to process them."

묶여도 되는 일은 그대로 두고, 건마다 답이 나가야 하는 일은 사람이 대기 목록을 보고 하나씩 돌리는 자리로 둡니다.
이 구분을 들이기 전에 정해야 나중에 회신이 섞였다는 말을 안 듣습니다.

사람이 언제 들어오는지는 사람을 부르는 트리거 네 가지 글의 축입니다. 여기서는 묶여도 되는가만 가립니다.

합쳐 돌아도 되는 일과 건마다 따로 답이 나가야 하는 일을 먼저 가릅니다.

사건형 자동화는 사건이 없으면 조용하고, 고장 나도 조용합니다. 두 조용함이 화면에서는 같아 보입니다.

저희가 직접 겪었습니다. 8월 24일, 카카오톡 문의를 1분마다 훑어 CRM에 적재하는 저희 파이프라인이 11시 46분부터 다섯 시간 동안 멈춰 있었습니다.

적재는 시각표로 사건을 흉내 내는 구조였고, 멈추면 텔레그램으로 알리는 장치도 있었습니다. 그런데 그 알림 통로가 2주 전부터 죽어 있어 한 번도 나가지 못했습니다.

설계는 옳았고 통로만 막혀 있었습니다. 놓친 사건을 줍는 자리가 따로 없으면 이렇게 됩니다.

상담에서 대표들이 먼저 묻는 것도 이 자리입니다.

원문대로 사건 방아쇠와 시각표는 한 작업에 같이 못 겁니다. 그러니 줍는 자리는 별도 작업으로 세웁니다.

하루 한 번, 어제 온 메일 중 조건에 맞는데 처리 기록이 없는 건이 있는지 훑는 시각형 작업입니다.
사건형이 조용했던 하루가 정상이었는지 그때 확인됩니다.

저희가 Claude로 워크플로우를 지을 때도 이 둘을 한 작업에 넣지 않습니다. 사건형이 하나면 그 옆에 하루 한 번 훑는 시각형이 하나입니다.

사건형 옆에는 하루 한 번 훑는 시각형을 따로 세워야 조용히 새는 걸 막습니다.

정리

경고 신호

• 메일 오면 알아서 돌게 해 달라고만 하고 어떤 메일인지는 정하지 않았다

• 조건 없이 받은 메일 전부를 사건으로 걸어 두었다

• 견적·회신처럼 건마다 답이 나가야 하는 일을 묶여 돌아도 되는 일과 같이 걸었다

• 사건형이 조용한 하루를 정상으로 넘기고, 놓친 건을 줍는 작업이 없다

좋은 신호

• 발신자·제목 조건을 적어 두고 첫 몇 번의 실행을 보고 고쳤다

• 묶여 돌아도 되는 일과 건마다 따로 답이 나가야 하는 일을 갈라 두었다

• 사건형 옆에 하루 한 번 놓친 건을 훑는 시각형 작업을 따로 세웠다

• DM으로 오는 거래처처럼 방아쇠가 못 보는 경로를 알고 있다

들이기 전에 정할 네 가지

1. 어떤 메일이 사건입니까?
   발신자·제목 조건을 적습니다. 넓으면 스팸, 좁으면 놓칩니다.

2. 사건이 몰려오면 한 번에 묶여 돌아도 됩니까?
   시세 확인은 되고 견적 회신은 안 됩니다. 업무별로 가릅니다.

3. 조용한 하루가 정상인지 누가 확인합니까?
   사건형은 고장 나도 조용합니다. 하루 한 번 훑는 시각형을 옆에 세웁니다.

4. 방아쇠가 못 보는 경로는 무엇입니까?
   Slack DM·반응·수정은 원문에서 미지원입니다. 그 경로로 오는 일은 규칙을 바꾸거나 사람이 봅니다.

자주 묻는 질문

Q. 사건 방아쇠와 시각표를 한 작업에 같이 걸 수 있습니까?

없습니다. 체인지로그에 "An event-triggered task can't also use a time-based schedule."라고 적혀 있습니다. 놓친 건을 줍는 시각형 작업은 별도 작업으로 만듭니다.

Q. 어느 요금제에서 쓸 수 있습니까?

원문은 "eligible plans"와 "Availability depends on your plan and workspace settings."라고만 적습니다. 요금제 이름은 문서에 없어 여기서 정하지 않습니다. 관리형 워크스페이스는 관리자가 'Allow event-triggered scheduled tasks' 권한으로 열고 닫습니다.

Q. 데스크톱 앱에서도 됩니까?

원문 기준 웹과 모바일에서만 됩니다. "They aren't available in the ChatGPT desktop app, Codex CLI, or the IDE extension."라고 도움말에 적혀 있습니다.

Q. Slack 채널을 감시하려면 무엇이 필요합니까?

ChatGPT Slack 앱이 감시할 채널마다 멤버로 들어가 있어야 합니다. 원문은 "The ChatGPT Slack app must be a member of each watched channel"이라고 적습니다. GitHub도 연결된 앱이 해당 저장소에 접근 권한이 있어야 합니다.