매일 보는 일이 아니라, 조건이 같은 일을 고릅니다
루틴은 같은 웹 확인을 되풀이하는 기능입니다. 하지만 반복해서 본다는 이유만으로 모두 루틴에 맞지는 않습니다. 예를 들어 매주 월요일 광고 대시보드에서 비용과 전환을 같은 기준으로 비교하는 일, 배포 뒤 오류율이 특정 값 아래로 내려왔는지 점검하는 일, 매달 청구서 폴더의 새 파일을 확인하는 일은 후보가 됩니다. 입력 위치와 결과 형식이 거의 변하지 않고, 이상일 때의 다음 행동도 정할 수 있기 때문입니다.
반대로 오늘 무엇을 조사할지부터 매번 새로 정하는 리서치, 사람의 맥락 판단이 결론을 좌우하는 채용·평가, 발송·결제처럼 즉시 외부 상태를 바꾸는 일은 정기 실행 전에 사람이 범위를 다시 확인하는 편이 안전합니다. “알아서 중요한 것을 알려줘”는 루틴 지시가 아닙니다. 무엇을 봐야 하는지와 중요하다고 판단할 기준이 빠져 있기 때문입니다.
같은 URL 또는 같은 서비스에서 시작하는가? 결과를 같은 표나 짧은 보고서로 받을 수 있는가? 이상을 숫자나 상태값으로 표현할 수 있는가? 이상일 때 사람이 바로 확인할 수 있는가? 네 질문 중 하나라도 답이 모호하면 일반 작업으로 먼저 몇 번 실행해 보는 편이 낫습니다.
크론은 새 점검, 하트비트는 이어서 확인할 때 씁니다
Aside 공식 도움말은 루틴을 크론과 하트비트 두 유형으로 나눕니다. 크론 루틴은 정한 일정마다 새 작업을 시작합니다. 지난 결과를 이어갈 필요 없이 매주 현황을 요약하거나, 매일 같은 체크리스트를 처음부터 확인할 때 맞습니다. 하트비트 루틴은 이미 진행 중인 같은 채팅을 깨워서 이어갑니다. 긴 작업이 사람 승인이나 외부 응답을 기다리다 멈췄고, 나중에 같은 맥락으로 재확인해야 할 때 사용할 수 있습니다.
크론 루틴
매주 월요일 09:00, 광고 대시보드의 지난주 성과를 새로 확인해 요약한다.
하트비트 루틴
입사 지원자에게 보낸 확인 메일의 답장이 왔는지 같은 작업 맥락에서 다시 확인한다.첫 사례는 매번 독립된 주간 보고서가 결과물이라 크론이 맞습니다. 두 번째는 기존 대화·조건·후속 조치를 이어야 하므로 하트비트가 적합할 수 있습니다.
공식 문서는 실행 시간이 겹치는 루틴은 건너뛰고, 연결된 채팅을 사용할 수 없으면 루틴을 일시 정지한다고 안내합니다. 이 동작을 기다리는 시간이 긴 점검의 안전장치로 과신하면 안 됩니다. 한 번의 점검이 예상보다 오래 걸릴 때 어떤 결과를 남길지, 다음 실행을 건너뛰어도 되는지까지 지시문에 넣어야 합니다.

일정 앞에 확인 대상과 결과 형식을 씁니다
루틴 이름을 “주간 점검”이라고 정하는 것만으로는 부족합니다. 작업 지시에는 어느 사이트의 어느 범위를 읽을지, 어떤 기간과 기준값을 적용할지, 어떤 형식으로 요약할지를 넣습니다. 그리고 반드시 금지 행동을 적습니다. 루틴은 사람이 옆에 있지 않은 시간에 실행될 수 있으므로 “설정 변경·메시지 전송·예산 변경은 하지 마” 같은 제한이 특히 중요합니다.
Google Ads와 Meta Ads에서 지난 월요일 00:00부터 일요일 23:59까지의 캠페인별 비용·전환·전환당 비용을 읽어라.
전주 같은 기간과 비교해 전환당 비용이 20% 이상 상승했거나 전환이 0인 캠페인만 표로 보고하라. 캠페인, 예산, 입찰, 광고 소재는 수정하지 마. 로그인이 막히거나 날짜 범위를 확정할 수 없으면 추정하지 말고 막힌 화면과 필요한 확인 사항만 남겨라.기간, 지표, 비교 기준, 보고 대상, 변경 금지, 실패 시 행동까지 적었습니다. 이것이 없으면 매번 다른 기준의 보고서가 나오거나, 오류를 메우려고 예상 밖의 행동을 할 수 있습니다.
첫 루틴은 정식 일정 전에 수동 실행으로 한 번 확인하세요. Aside의 루틴 관리 화면에서는 즉시 실행이 가능하므로, 같은 조건에서 어떤 탭을 읽고 결과가 어떤 형식으로 나오는지 먼저 봅니다. 결과가 길다면 보고할 예외를 더 좁히고, 숫자가 부족하다면 원본 링크나 화면 캡처를 함께 남기도록 요청합니다.
‘이상’은 숫자와 비교 대상을 같이 적습니다
“성과가 나쁘면 알려줘”는 사람에게도 애매한 지시입니다. 기준은 하나 이상의 숫자와 비교 기간으로 표현합니다. 예를 들어 전환당 비용이 전주보다 20% 올랐을 때, 오류율이 2%를 넘었을 때, 신규 문의가 24시간 동안 한 건도 없을 때처럼 적습니다. 단, 숫자 하나만으로 원인을 확정하지는 않습니다. 지표가 나빠졌다는 관찰과 원인 추정은 분리해서 보고하게 합니다.
알림이 너무 자주 오면 결국 보지 않게 됩니다. 처음에는 놓치면 비용이 큰 조건 한두 개만 둡니다. 예외가 발생한 항목만 보고하게 하고, 정상 상태를 전부 나열하지 않게 하면 보고서도 짧아집니다. 예를 들어 “정상이면 한 줄로 이상 없음만 남기고, 문제가 있으면 캠페인명·현재값·전주값·원본 링크를 적어라”처럼 결과 형식을 제한합니다.
개발 업무라면 배포 직후의 오류율·배포 상태·스테이징 화면 확인처럼 실제 화면 근거가 중요한 점검에 활용할 수 있습니다. Aside 공식 개발자 안내도 릴리스 뒤 대시보드의 오류율을 확인하고, 기준값이 이상하면 멈추도록 하는 예를 듭니다. 코드 변경 자체는 기존 개발 도구에서 검토하고, 루틴은 브라우저 밖에 있던 증거를 모으는 데 쓰는 편이 역할이 분명합니다.

루틴은 등록보다 중단 기준을 정하는 일이 더 중요합니다
루틴이 정상 보고만 계속한다면 일정이 맞는지, 기준이 너무 넓지 않은지 한 달에 한 번은 확인합니다. 지표 정의나 대시보드 UI가 바뀌었는데 기존 지시를 그대로 두면, “이상 없음”이라는 결과도 신뢰하기 어렵습니다. 공식 도움말에서 안내하는 수정·일시 정지·재개 기능은 결과가 어색할 때 단순히 시간을 바꾸는 기능이 아니라, 지시와 범위를 다시 검토하는 기회로 써야 합니다.
다음 중 하나가 생기면 중단하거나 일반 작업으로 되돌립니다. 로그인이 반복해서 실패할 때, 같은 경고가 계속되지만 원본 화면에서 확인할 수 없을 때, 결과에 고객정보나 비밀값이 불필요하게 포함될 때, 보고서를 읽는 사람이 더 이상 행동하지 않을 때입니다. 매일 실행되는 루틴 하나가 쓸모없어지는 순간은 대개 오류가 날 때가 아니라, 결과가 쌓여도 아무도 보지 않을 때입니다.
루틴 제안 기능을 쓴다면 초안 상태에서 곧바로 활성화하지 않습니다. 공식 도움말도 제안을 검토하고 지시·일정·대상 채팅을 고친 다음 활성화하는 순서를 안내합니다. 반복 행위는 관성으로 계속되기 쉬우므로, 처음 한 번의 검토보다 다음 달에도 계속 돌릴 이유가 있는지 확인하는 검토가 더 중요합니다.
첫 루틴은 한 주 동안만 시험합니다
처음에는 매일 여러 사이트를 훑는 복잡한 보고서보다, 일주일 동안 한 대시보드의 이상값만 찾는 루틴이 낫습니다. 수동 실행 결과와 루틴 결과가 같은지 보고, 경고가 실제 조치로 이어졌는지도 기록합니다. 필요 없는 경고는 기준을 좁히고, 놓친 문제는 확인 대상을 추가합니다. 이렇게 한 가지 확인 업무를 다듬은 뒤에야 루틴 수를 늘려도 알림 피로 없이 관리할 수 있습니다.
Aside의 Use routines, Run tasks, Aside for Developers 안내를 2026년 8월 31일 확인했습니다. 루틴 유형, 관리 기능, 요금제별 활성 루틴 수는 제품 업데이트에 따라 달라질 수 있으니 실제 설정 화면과 최신 도움말을 우선하세요.
Aside Use routines 공식 도움말 ↗ · Aside Run tasks 공식 도움말 ↗ · Aside for Developers, 반복 점검 사례 ↗