Skip to content
주제
AICoding
Claude Code 루틴 사용법: AI 에이전트 cron 작업과 자동 트리거

Claude Code 루틴 사용법: AI 에이전트 cron 작업과 자동 트리거

업데이트

Claude Code 루틴이 무엇인지, 스케줄·API·GitHub 트리거를 어떻게 쓰는지, Codex 앱 Automations와 OpenClaw cron jobs와 어떻게 다른지 한국어로 정리했습니다.

Claude Code 루틴의 핵심은 에이전트 모델을 “사람이 프롬프트를 넣을 때만 움직이는 구조”에서 “세계가 바뀌거나 시간이 되면 스스로 실행되는 구조”로 바꾼다는 데 있습니다. 여기서 진짜 변화가 생깁니다. cron은 단순한 예약 기능이 아닙니다. 에이전트를 운영 시스템으로 바꾸는 장치입니다.

2026년 4월 15일 기준으로 Anthropic은 Claude Code 루틴을 Claude Code 웹의 research preview 기능으로 안내하고 있습니다. 루틴은 한마디로 말하면 프롬프트, 저장소, 환경, 커넥터에 더해 트리거까지 묶인 클라우드 에이전트 설정입니다. 정확한 UI 절차와 현재 제한은 공식 Claude Code routines 문서 (opens in a new tab)를 먼저 확인하는 것이 좋습니다. 이 글은 그 위에 얹는 실전 설명입니다. 루틴이 실제로 무엇인지, 왜 중요한지, 그리고 Codex 앱 AutomationsOpenClaw cron jobs와 어떻게 다른지 정리합니다.

AI 에이전트 전반의 맥락을 먼저 보고 싶다면 AI Coding 토픽 허브, 병렬 코드 에이전트 가이드, Codex 사용법 가이드를 함께 보면 좋습니다.

빠른 답변: Claude Code 루틴이란 무엇인가

Claude Code 루틴은 자동으로 시작되는 클라우드 실행 Claude Code 세션입니다.

사람이 매번 Claude를 열고 "열린 PR을 검토해 줘" 또는 "프로덕션 알림을 확인해 줘"라고 말하는 대신, 한 번 설정해 두고 다음과 같은 트리거를 붙입니다.

  • 스케줄
  • API 호출
  • GitHub 이벤트

즉, 루틴은 단순한 타이머가 아닙니다. 실제 코딩 에이전트 세션을 시작하는 트리거 계층입니다.

필요한 것더 잘 맞는 선택이유
노트북이 꺼져 있어도 계속 도는 클라우드 에이전트Claude Code 루틴Anthropic이 세션을 자체 클라우드 인프라에서 실행함
코딩 데스크톱 앱 안에서 돌아가는 예약 작업Codex 앱 Automations반복 작업을 review queue로 넘기는 데 잘 맞음
정밀한 cron, heartbeat, hooks, webhook 전달까지 직접 통제하는 자가 호스팅 에이전트OpenClaw자동화 스택을 직접 소유하려는 경우 가장 강함

중요한 것은 브랜드가 아닙니다. 핵심은 채팅 우선 에이전트에서 시간 또는 이벤트 우선 에이전트로 바뀐다는 점입니다.

루틴이 해결하는 문제

대부분의 AI 에이전트는 아직도 반응형 루프에 머뭅니다.

  1. 사람이 문제를 알아차린다
  2. 사람이 에이전트를 연다
  3. 사람이 문제를 설명한다
  4. 사람이 결과를 기다린다

한 번성 작업에는 충분하지만, 반복 작업에는 잘 맞지 않습니다.

반복 작업은 보통 이런 특징을 가집니다.

  • 지루하다
  • 잊기 쉽다
  • 놓치면 중요하다
  • 매번 새 프롬프트보다 정책으로 표현하는 편이 명확하다

그래서 에이전트에서 cron이 중요합니다. 진짜 가치는 "매일 아침 실행된다"가 아닙니다. 진짜 가치는 아래에 있습니다.

  • 작업이 신뢰 가능해진다
  • 트리거가 명시적이 된다
  • 사람이 기억하지 않아도 에이전트가 자율적으로 움직인다
  • 사람이 직접 시작하기 전에, 실행 후 결과를 검토할 수 있다

AI 에이전트에 있어 이는 가장 큰 실용적 업그레이드 중 하나입니다. 에이전트를 assistant 모드에서 operations 모드로 옮겨 줍니다.

Claude Code 루틴은 어떻게 동작하나

Anthropic의 현재 문서에 따르면 루틴은 다음 요소로 구성된 저장된 Claude Code 설정입니다.

  • 프롬프트
  • 하나 이상의 저장소
  • 환경
  • 선택적 커넥터
  • 하나 이상의 트리거

실행 자체는 장난감 작업 실행기가 아니라, 완전한 Claude Code 클라우드 세션입니다.

즉 루틴은 다음을 할 수 있습니다.

  • 저장소를 clone한다
  • shell command를 실행한다
  • repo에 커밋된 skills를 사용한다
  • Slack 또는 Linear 같은 연결 서비스에 connector를 통해 접근한다
  • 나중에 확인할 수 있는 세션을 연다

실전에서의 사고방식은 이렇습니다.

루틴은 트리거가 붙은 재사용 가능한 에이전트 runbook이다

실제로 루틴을 만드는 방법

Anthropic은 현재 모든 루틴 surface가 동일한 cloud account에 기록되므로, 웹이나 CLI에서 만든 루틴이 같은 곳에 나타난다고 안내합니다.

다음 경로로 만들 수 있습니다.

  • 웹 UI
  • Desktop appremote task
  • CLI/schedule

가장 빠른 CLI 예시는 다음과 같습니다.

/schedule daily PR review at 9am

이 방식이 유용한 이유는 가장 흔한 사용 사례인 반복 예약 작업의 진입 장벽을 낮춰 주기 때문입니다.

하지만 현재 문서에는 중요한 제한이 하나 있습니다.

  • CLIscheduled routine만 생성한다
  • APIGitHub 트리거는 아직 웹 UI에서 추가해야 한다

Anthropic은 또 각 루틴이 팀 공간이 아니라 개인 계정에 속한다고 설명합니다.

세 가지 트리거 타입

1. 스케줄 트리거

가장 먼저 떠올릴 부분입니다. 정해진 주기로 반복 실행되는 방식입니다.

공식 문서에 따르면 루틴은 다음과 같은 preset schedule을 지원합니다.

  • hourly
  • daily
  • weekdays
  • weekly

커스텀 간격은 CLI의 /schedule update로 cron expression을 설정할 수 있습니다. 현재 최소 간격은 1시간이므로, 매분 폴링 루프용으로 설계된 기능은 아닙니다.

운영상 중요한 두 가지는 다음입니다.

  • 시간은 로컬 타임존으로 입력한다
  • Anthropic이 일관된 stagger를 적용하므로 실행이 몇 분 늦게 시작될 수 있다

즉, cron과 비슷하지만 agent-aware한 스케줄 규칙이 얹혀 있습니다.

2. API 트리거

여기서부터 루틴은 단순한 반복 작업처럼 느껴지지 않습니다.

Anthropic은 루틴이 인증된 전용 HTTP endpoint를 노출하도록 허용합니다. 외부 시스템이 그 endpoint로 POST 요청을 보내면 Claude가 새 실행을 시작하고, text 필드에 추가 자유형 컨텍스트를 받을 수 있습니다.

이렇게 하면 루틴을 다음과 연결할 수 있습니다.

  • 배포 파이프라인
  • 오류 알림
  • 내부 도구
  • 다른 시스템의 수동 버튼

이 기능이 중요한 이유는 에이전트가 시간뿐 아니라 외부 상태 변화에도 반응할 수 있게 해 주기 때문입니다.

3. GitHub 트리거

Anthropic 문서는 루틴이 GitHub 이벤트로도 시작될 수 있다고 설명합니다. 현재 문서 기준으로 지원되는 이벤트 범주는 pull requestrelease이며, author, title, base branch, labels, draft state, merge state, fork 여부 같은 필드로 필터링할 수 있습니다.

이 기능은 Claude를 저장소 네이티브 자동화 계층으로 바꿉니다.

  • PR이 열린다
  • Claude가 리뷰한다
  • 새 release가 게시된다
  • Claude가 검증 또는 backport 로직을 실행한다

이것은 "채팅을 열고 리뷰해 달라고 요청한다"와는 완전히 다른 운영 모델입니다.

왜 이것이 일반적인 cron job보다 흥미로운가

일반적인 cron job은 한 가지를 잘합니다. 정해진 시간에 코드를 시작하는 것입니다.

에이전트 루틴은 더 야심적입니다. 다음을 결합합니다.

  • 스케줄 또는 이벤트
  • 저장소 context
  • 도구와 커넥터
  • 성공 기준을 정의하는 프롬프트
  • 나중에 점검할 수 있는 출력 surface

즉 cron expression은 스택의 한 조각일 뿐입니다.

이 카테고리에 사람들이 주목하는 더 깊은 이유는 다음과 같은 작업을 열어 주기 때문입니다.

  • 누구도 기억하지 않아도 되는 아침 PR 리뷰
  • 머지된 코드 변경 이후의 야간 docs drift 점검
  • release 종료 뒤 자동 follow-up
  • 라벨, 요약, 담당자 제안이 포함된 주간 backlog triage

이 일들은 shell script로도 가능했습니다. 하지만 agent routine에서 달라지는 점은, 예약 실행 안에서 훨씬 더 많은 비정형 추론을 맡길 수 있다는 것입니다.

Claude routines vs Claude desktop scheduled tasks

이 구분은 쉽게 놓치기 쉽습니다.

Anthropic은 현재 다음과 같은 여러 scheduling layer를 제공합니다.

  • Routines는 Anthropic 관리 클라우드 인프라에서 실행된다
  • Desktop scheduled tasks는 내 컴퓨터에서 실행된다
  • /loop scheduled prompts는 세션 범위에 묶이며 세션이 끝나면 중단된다

이 차이는 작업이 무엇에 접근할 수 있고 언제 실행될 수 있는지를 바꾸기 때문에 중요합니다.

옵션실행 위치가장 적합한 경우
RoutinesAnthropic cloud컴퓨터가 꺼져 있어도 계속 돌아야 하는 작업
Desktop scheduled tasks내 머신로컬 파일, 도구, 커밋되지 않은 변경이 필요한 작업
/loop현재 세션이미 사람이 붙어 있는 상태에서 가볍게 반복 확인할 때

Claude에 "cron이 추가됐다"고만 생각하면 너무 얕습니다. 실제로는 서로 다른 runtime boundary를 가진 여러 자동화 surface가 추가된 것입니다.

Claude 루틴에서 중요한 가드레일

현재 routines 문서는 실행 중 permission prompt를 기대하는 흐름이 아니라는 점도 분명히 합니다.

Anthropic은 루틴 실행이 자율적인 클라우드 세션이라고 설명합니다.

  • 실행 중 permission picker가 없다
  • 실행 중 approval prompt가 없다
  • 접근 범위는 사전에 설정한 저장소, branch 설정, 환경, 커넥터로 통제된다

저장소 동작도 중요합니다. Anthropic은 루틴이 매 실행 시 선택된 저장소를 기본 branch에서 clone하며, 저장소에 대해 제한을 풀지 않는 한 기본적으로 Claude가 claude/ 접두사 브랜치에만 push할 수 있다고 설명합니다.

즉 설정 품질이 일반 interactive session보다 훨씬 중요합니다.

실무적으로는 세 가지 함의가 있습니다.

루틴의 범위를 좁게 잡아라

연결 가능한 커넥터와 저장소를 모두 붙일 수 있다고 해서 그렇게 할 필요는 없습니다. 문서에 따르면 연결된 커넥터는 기본으로 모두 포함되므로, access pruning도 작업의 일부입니다.

프롬프트는 대화문이 아니라 운영 절차처럼 써라

루틴 프롬프트는 일회성 질문처럼 읽히면 안 됩니다. 다음을 정의해야 합니다.

  • 무엇을 점검할지
  • 무엇을 할지
  • 무엇을 건드리지 않을지
  • 성공 기준은 무엇인지
  • 결과는 어디로 갈지

제한과 이벤트 누락을 예상하라

Anthropic은 현재 루틴에 daily run cap이 있고, preview 기간의 GitHub-triggered event에도 hourly cap이 있다고 문서화합니다. 이것을 무제한 daemon framework로 생각하면 설계가 틀어집니다.

Codex 앱 Automations는 어디에 놓이나

여기서 비교가 흥미로워집니다.

OpenAI의 2026년 2월 2일 Codex 앱 발표는 앱이 일정에 따라 실행되는 Automations를 지원한다고 설명합니다. OpenAI는 이를 끝나면 review queue로 들어가는 background work로 설명하며, 미래 버전에서 cloud-based triggers를 계속 구축 중이라고도 밝힙니다.

즉 Codex 앱 Automations는 Claude 루틴과 인접하지만 동일하지는 않습니다.

현재 공개 포지셔닝은 다음에 가깝습니다.

  • 예약된 background work
  • review-oriented handoff
  • desktop-app-centered orchestration

반대로 Claude 루틴은 이미 다음으로 프레이밍됩니다.

  • cloud sessions
  • multi-trigger automations
  • API-callable runs
  • GitHub-event-aware runs

깔끔한 비교는 다음과 같습니다.

차원Claude Code 루틴Codex 앱 Automations
실행 위치클라우드앱 중심의 예약 background work
트리거 모델스케줄, API, GitHub현재는 스케줄 중심, 더 넓은 trigger story는 확장 중
주요 출력 형태나중에 점검 가능한 새 Claude Code 세션앱 안의 review queue와 후속 workflow
가장 적합한 용도무인 클라우드 자동화Codex 제어면 안에서의 반복적 supervised work

Codex를 많이 쓴다면 중요한 결론은 Claude가 "이겼다"가 아닙니다. 시장이 같은 필요를 향해 수렴하고 있다는 점입니다. 에이전트는 스케줄 가능해야 합니다.

OpenClaw 사용자가 cron jobs에 주목하는 이유

OpenClaw는 scheduling을 UI 뒤에 숨은 기능이 아니라 일급 시스템 surface로 다룬다는 점에서 좋은 대비군입니다.

공식 OpenClaw 문서는 더 넓은 자동화 스택을 설명합니다.

  • cron은 정확한 스케줄링과 1회성 리마인더용
  • heartbeat는 약간 느슨한 주기 점검과 전체 세션 context용
  • hooks는 이벤트 기반 스크립트용
  • standing orders는 지속적인 운영 권한용

이것이 autonomy를 중시하는 사용자들이 OpenClaw에 관심을 갖는 큰 이유입니다.

OpenClaw 문서는 특히 다음 구분을 명확히 합니다.

  • 타이밍이 정확해야 하거나 작업이 독립적으로 실행되어야 하면 cron
  • 대략적인 타이밍이면 충분하고 메인 세션 context를 그대로 써야 하면 heartbeat

이것은 단순 구현 세부가 아닙니다. 강한 자동화 설계 패턴입니다.

왜 이 점이 중요한가

많은 사람이 "agent cron jobs"를 원한다고 말하지만, 실제로는 서로 다른 두 가지를 원합니다.

  1. 정확한 예약 실행
  2. 주변적인 주기 인식

OpenClaw는 이것을 깔끔하게 분리합니다.

Claude 루틴은 오늘 기준으로 첫 번째 범주, 즉 클라우드에서의 명시적 스케줄 또는 이벤트 트리거 실행을 주로 담당합니다.

Codex 앱 Automations도 오늘 기준으로는 주로 예약 작업 쪽에 있습니다.

OpenClaw는 여러 자동화 계층을 더 노골적으로 드러내므로, 자율성을 중시하는 사용자들이 더 선호합니다.

AI 에이전트의 미래에서 cron jobs가 중요한 이유

에이전트가 사람이 물어볼 때만 움직인다면 여전히 반응형 도구입니다.

에이전트가 다음처럼 실행될 수 있다면 상황이 바뀝니다.

  • 매일 아침
  • PR이 열릴 때
  • 배포가 끝날 때
  • 알림이 울릴 때
  • 주간 유지보수 창이 시작될 때

그 순간 에이전트는 시스템의 운영 리듬 안으로 들어갑니다.

이것이 루틴과 자동화 프레임워크의 진짜 의미입니다. 다음 네 가지를 정의할 수 있게 해 줍니다.

  • 에이전트가 언제 깨어나는지
  • 어떤 context를 받는지
  • 어떤 권한을 가지는지
  • 결과가 어디로 가는지

이 네 가지가 안정되면, 반복 작업에서 에이전트를 훨씬 더 신뢰하기 쉬워집니다.

흔한 함정

1. 스케줄링과 자율성을 같은 것으로 생각하기

cron trigger는 "언제"만 해결합니다. 정확성, permission scope, review quality까지 해결해 주지는 않습니다.

2. 모호한 프롬프트를 쓰기

"repo를 확인하고 알아서 도와줘"는 자동화 프롬프트가 아닙니다. drift를 초대하는 문장입니다.

3. 런타임 경계를 무시하기

클라우드 루틴, desktop task, self-hosted scheduler는 서로 바꿔 쓸 수 없습니다. 적합한 선택은 작업이 다음 중 무엇을 필요로 하는지에 달려 있습니다.

  • 로컬 파일
  • 클라우드 가용성
  • 이벤트 통합
  • 엄격한 감사 가능성

4. 실패 처리를 잊기

가장 좋은 자동화는 보고할 것이 없을 때, 처리량이 너무 많을 때, 외부 시스템이 이용 불가할 때 무엇을 할지까지 정의합니다.

이 범주를 실용적으로 생각하는 법

간단한 프레임워크가 필요하다면 다음을 쓰면 됩니다.

  • Claude Code 루틴은 스케줄, API 호출, 지원되는 GitHub 이벤트로 깨어날 수 있는 클라우드 에이전트가 필요할 때
  • Codex 앱 Automations는 review-driven workflow가 있는 코딩 앱 안에서 반복 작업을 하고 싶을 때
  • OpenClaw는 cron, heartbeat, hooks, 지속 권한을 별도 구성요소로 다루는 가장 명시적인 자가 호스팅 자동화 surface가 필요할 때

이 범주가 중요한 이유는 cron syntax 때문이 아닙니다. AI 에이전트가 채팅창에 갇혀 있을지, 아니면 믿을 수 있는 background worker가 될지에 관한 문제이기 때문입니다.

Related Guides

📚