이 기사에 대하여

Claude Code에는 정해진 스케줄에 따라 세션을 자동으로 구동하는 Routines(스케줄 트리거)라는 기능이 있습니다. "매일 아침 리포지토리 상태를 확인하게 한다", "매주 월요일에 리포트를 정리하게 한다"와 같은 정기적인 태스크를 cron과 같은 감각으로 구성할 수 있습니다.

필자는 개인 개발에서 이 기능을 일상적으로 사용하고 있으며(정기 실행으로 콘텐츠 제작이나 진척도 리포트를 돌리는 운용을 하고 있습니다), 실제로 직접 조작하며 알게 된 설정의 요령과 함정을 정리합니다. 공식 문서에 나와 있는 1차 정보에 더해, 빠지기 쉬운 포인트를 중심으로 작성합니다.

Routines의 3가지 구동 모드

Routine을 만들 때 가장 먼저 결정해야 할 것은 "발화했을 때 어느 세션으로 착지시킬 것인가"입니다. 3가지 패턴이 있습니다.

기존 세션으로의 자기 바인딩 (Self-binding to existing session): 발화할 때마다 "같은 대화"가 재개됩니다. 문맥을 이어받은 지속 태스크(예: 리마인더, 진행 중인 프로젝트의 정기 체크)에 적합합니다 -
지정한 별도 세션으로 바인딩 (Binding to a specified different session): 자신이 만든 "형제 세션"을 다른 세션에서 정기적으로 깨웁니다. 감시 역할 세션과 작업 세션을 나누고 싶을 때 사용합니다 -
매번 새로운 세션 생성 (Create a fresh session every time): 발화할 때마다 문맥이 없는 새로운 세션이 생성됩니다. 이전 대화에 의존하지 않는 독립 태스크(예: 일간 배치, 정형 리포트)에 적합합니다

여기서 가장 흔히 발생하는 사고는, 지속 태스크를 의도하면서 「매번 새로운 세션」을 선택해 버리는 것입니다. 프레시(Fresh) 모드는 대화의 기억을 전혀 가지지 않기 때문에, 프롬프트 측에 「무엇을 전제로 움직일지」를 매번 자기 완결적으로 적어두어야 합니다. 반대로 자기 바인딩형은 대화가 쌓이는 만큼 장기 운용 시 컨텍스트 (Context)가 비대해지기 쉽다는 점에 주의가 필요합니다.

cron 설정의 함정

Routine의 스케줄은 cron 형식의 5개 필드(분·시·일·월·요일)로 지정하지만, 몇 가지 놓치기 쉬운 사양이 있습니다.

모두 UTC 기준으로 평가됩니다. 일본 시간의 "매일 아침 8시"는 0 23 * * * (전날 23시 UTC)와 같이 변환하여 설정해야 합니다. 날짜가 바뀌는 변환을 할 때는 요일·날짜 필드도 어긋날 수 있다는 점을 잊기 쉽습니다 -
최소 간격은 1시간입니다. 분 단위의 세밀한 실행은 불가능합니다 -
「매시」, 「N시간마다」를 0분으로 구성하면, 생성한 순간의 분을 기점으로 균등화되는 사양이 있습니다. 이는 여러 Routine을 일시에 0분으로 집중시키지 않기 위한 동작이므로, "왜 지정한 분에 딱 맞춰 움직이지 않지?"라고 생각하더라도 고장 난 것이 아닙

한번 만든 Routine의 cron이나 프롬프트를 수정하고 싶을 때는, 삭제하고 다시 만드는 것이 아니라 업데이트 계열의 도구로 그 자리에서 수정하는 것이 무난합니다. 실행 이력(run history)을 유지한 채 변경할 수 있으므로, 과거의 실행 로그를 추적해야 하는 케이스에서는 특히 유효합니다.

알림 설계: 「동작했다는 사실」보다 「알아야 할 내용」을 전달하기

프레시 세션형 Routine에는 완료 시에 알림(푸시/메일)을 보내는 설정이 있습니다. 여기서 중요한 것은, 「실행이 끝났다」는 것을 매번 알리는 것이 아니라, 「인간이 지금 알아야 할 것이 있을 때만」 알리는 것이라는 설계 방침입니다.

• 순회 결과 이상 없음 → 알림하지 않음 (사일런트하게 종료)
• 이상을 감지함, 판단이 필요함, 실행 자체를 할 수 없었음 → 알림함

이를 철저히 지키지 않으면, "정기 실행이 돌아가고 있다"라는 당연한 사실의 알림이 쌓여서 정말 중요한 알림이 묻히게 됩니다. 개인의 알림 수용량은 유한하므로, Routine 설계 초기 단계에서 「매번 알림」을 기본값으로 설정하지 않는 것을 권장합니다.

세션 횟수 자체가 비용이 되는 경우의 궁리

Claude Code의 이용 한도(메시지 수·토큰 수)가 다른 용도와 공유되고 있는 경우, Routine을 생각나는 대로 늘리면 한도를 압박하게 됩니다. 필자가 실제로 하고 있는 궁리는 다음 두 가지입니다.

관련 태스크는 하나의 Routine으로 통합한다. 「집필」, 「리뷰」, 「공개」를 별개의 Routine으로 나누지 않고, 1회의 세션에서 일괄적으로 처리하게 한 뒤, 공개만 일시를 지정하여 분산시킵니다 -
Routine의 수를 용도별로 고정하고, 늘리기 전에 기존 것의 통합을 검토한다. 요일별로 역할을 하나로 압축하면, 나중에 보았을 때 어떤 Routine이 무엇을 하는 것인지 파악하기 쉬워집니다

요약

Routines를 구성할 때 가장 먼저 결정해야 할 것은 "발화 대상 세션의 모드 (mode)", 그다음 주의해야 할 점은 "cron은 UTC 기준으로 평가되며 최소 간격은 1시간"이라는 점, 그리고 운영 기간이 길어질수록 중요해지는 설계 원칙은 "알림은 정말로 필요할 때만"입니다. 정기 실행 태스크를 이제 막 구성하려는 분들에게 도움이 되기를 바랍니다.

Discussion