자동화는 몇 시에 돌릴지가 절반입니다
업무 자동화를 만들 때 대부분의 시간은 무엇을 시킬지에 들어갑니다. 그런데 실제로 돌려 보면 결과를 가르는 것은 다른 두 가지입니다.
몇 시에 돌릴 것인가. 그리고 그 시간에 못 돌았으면 어떻게 할 것인가.
이 둘은 대개 기본값으로 남습니다. 저도 그랬고, 그래서 한 번 크게 헛돌았습니다.
사고 하나: 시간대를 잘못 골라서 결과물이 0건
글을 쓰는 자동화를 오후 2시에 걸어 두었습니다. 점심 지나 한가한 시간이니 적당해 보였습니다.
첫 정상 실행 날, 결과물이 하나도 나오지 않았습니다. 이유는 코드가 아니었습니다. 그날 오전에 제가 같은 도구를 이미 많이 썼기 때문입니다. 오후 2시에 자동화가 시작될 무렵에는 쓸 수 있는 양이 남아 있지 않았고, 작업은 아무것도 만들지 못한 채 40분을 버티다 끝났습니다.
저녁 8시로 옮기고 나서는 같은 문제가 없습니다. 하루 작업이 끝난 뒤라 도구가 비어 있고, 다른 자동화와도 겹치지 않습니다.
여기서 얻은 기준은 이렇습니다.
> 자동화 시간을 정할 때는 내 일정만 보지 말고, 그 자동화가 쓰는 도구의 사정까지 본다.
사용량 제한이 있는 도구, 밤에만 한가한 서버, 낮에 사람이 붙잡고 있는 프로그램 — 전부 같은 이야기입니다.
놓친 실행을 따라잡게 할 것인가
컴퓨터가 꺼져 있었거나 다른 작업이 물고 있으면 예약 시각을 그냥 지나갑니다. 이때 선택지가 둘입니다.
대부분 이걸 안 건드리고 기본값으로 둡니다. 그런데 자동화 성격에 따라 정답이 정반대입니다.
따라잡아야 하는 것 — 결과물이 남는 일
글쓰기, 정리, 백업처럼 늦게라도 해 두면 남는 일은 따라잡기를 켭니다. 아침에 못 돌았으면 저녁에라도 도는 편이 낫습니다. 제 경우 주 5회 글쓰기, 주 4회 글쓰기, 주 2회 정리 작업이 전부 여기에 속합니다.
따라잡으면 안 되는 것 — 시간이 의미인 일
아침 브리핑을 오후 4시에 받으면 그건 브리핑이 아닙니다. 이미 지나간 오전 일정을 알려주는 꼴이 됩니다. 밤에 하루를 정리하는 기록도 마찬가지입니다. 다음 날 아침에 뒤늦게 뜨면 맥락이 어긋납니다.
이런 작업은 따라잡기를 끕니다. 그 회차는 없던 일로 하는 것이 맞습니다.
그런데 아침 브리핑을 아예 놓치는 것도 곤란하다면
여기서 한 단계가 더 필요합니다. 제가 실제로 쓰는 방법입니다.
아침 브리핑은 따라잡기를 끄되, 오후에 '복구 실행'을 하나 더 등록했습니다.
이렇게 하면 평소에는 아침에만 돌고, 컴퓨터가 꺼져 있어 아침을 통째로 놓친 날에만 오후에 한 번 만회합니다. 뒤늦은 알림이 매일 쌓이지 않으면서, 아예 없는 날도 없어집니다.
"놓치면 안 되지만 늦게 오면 곤란한 일"은 한 작업으로 해결되지 않습니다. 두 개로 나누고, 뒤쪽에 "이미 했으면 그만두기"를 넣으면 됩니다.
나머지 세 가지 설정
시간대와 따라잡기를 정했으면 나머지는 금방입니다.
1. 겹치지 않게 벌려 둔다. 같은 시각에 여러 개를 몰아 두면 서로 자원을 뺏습니다. 아침·오후·저녁·밤으로 흩어 두고, 주간 점검은 주말 직전 저녁에, 월간 점검은 새벽에 둡니다.
2. 분 단위를 어중간하게 잡는다. 정각은 다른 프로그램의 업데이트·백업이 몰리는 시각입니다. 19시 00분 대신 19시 07분처럼 어긋나게 두면 충돌이 줄어듭니다.
3. 앞 실행이 안 끝났을 때를 정해 둔다. 이전 회차가 아직 돌고 있는데 다음 회차가 시작되면 같은 작업이 둘 돌면서 결과물이 중복되거나 서로를 덮어씁니다. 새 실행을 무시하도록 두는 편이 안전합니다.
노트북이라면 하나 더 있습니다. 배터리로 돌아갈 때 작업을 시작하지 않거나 도중에 멈추는 것이 기본값인 경우가 많습니다. 전원이 빠졌다고 자동화가 조용히 멎는 상황을 원치 않으면 이 조건도 풀어 둡니다.
정리 — 새 자동화를 걸 때 확인할 다섯 줄
자동화를 처음 만들 때는 기능이 전부처럼 보입니다. 하지만 몇 달 돌려 보면 고장은 대부분 기능이 아니라 시간과 조건에서 납니다.
저장까지 끝난 자동화가 정말 끝난 것인지 확인하는 순서는 공개 결과까지 확인하는 4단계에, 어떤 자동화를 남기고 어떤 것을 껐는지는 자동화를 끄면서 배운 것에 따로 적어 두었습니다.
보통리가 만드는 서비스