지금 시키는 일만 하던 에이전트가 미래의 자기에게 일을 거는 법 — OpenClaw cron 도구

오픈소스 개인 AI 어시스턴트 OpenClaw를 집 서버에 올려 쓰다 보면, 처음엔 "지금 이거 해 줘" 식의 대화만 오간다. 사람이 말을 걸면 그제야 에이전트가 움직인다. 그런데 진짜 비서라면 시키지 않아도 "매일 아침 7시엔 밤사이 변경사항을 요약하고, 15분마다 큐 길이를 확인하고, 금요일 저녁엔 배포 내역을 정리"하는 식으로 스스로 미래 시점에 일을 예약할 줄 알아야 한다. OpenClaw에서 이걸 가능하게 하는 게 cron 도구다. 이 글은 Cron Jobs 관리 화면이 아니라, 에이전트가 직접 손에 쥐고 쓰는 스케줄링 능력 — 무엇을, 언제, 어떻게 실행하고, 그 결과를 어디로(announce / webhook / none) 보낼지 고르는 도구 측면 — 에 집중한다.

배경 — "지금" 요청에만 반응하는 에이전트는 능동성이 없다

대화형 AI의 기본 동작은 요청-응답이다. 사람이 메시지를 보내면 에이전트가 한 턴(turn, 모델이 입력을 받아 답을 내놓는 한 번의 실행 단위)을 돌고 멈춘다. 이 구조에는 "지금 이 순간" 외의 시간축이 없다. 내일 아침에 무언가 하고 싶으면 사람이 내일 아침에 다시 말을 걸어야 한다. 에이전트는 요청과 요청 사이에 그냥 놀고 있다(idle).

OpenClaw는 게이트웨이(Gateway, 메시지를 듣고 작업을 실행하는 OpenClaw의 상주 프로세스) 안에 cron이라는 예약 실행기를 내장하고, 그것을 에이전트가 호출할 수 있는 도구로도 노출한다. 여기서 "도구"란 모델이 대화 중에 함수처럼 불러 쓸 수 있는 능력을 말한다 — 검색 도구, 파일 읽기 도구처럼 cron도 하나의 도구다. 그래서 에이전트는 대화 도중에 "이건 매일 반복할 가치가 있겠다" 싶으면 스스로 cron(action: "add")를 호출해 미래의 자기에게 작업을 걸어 둘 수 있다.

다이어그램 설명. 이 그림은 "지금 반응하는 에이전트"가 "미래를 예약하는 에이전트"로 넘어가는 분기점을 보여준다. 사람의 요청을 받은 에이전트가 그 일을 한 번 쓰고 끝낼지 아니면 반복할 가치가 있는지를 판단하는 갈림길을 지나, 반복 가치가 있다고 판단하면 cron 도구를 불러 미래 시점에 작업을 예약한다. 그 뒤로는 사람이 말을 걸지 않아도 예약 시각이 오면 에이전트가 스스로 깨어나 일하고 결과를 정해진 곳으로 보낸다. 핵심은 판단의 주체가 에이전트라는 점이다 — 사람이 "cron 걸어 줘"라고 명시적으로 지시할 수도 있지만, 에이전트가 대화 맥락에서 "이건 매일 하면 좋겠다"고 먼저 제안해 거는 것도 가능하다. 놓치기 쉬운 함정은 cron이 모델(LLM) 안이 아니라 게이트웨이 프로세스 안에서 돌아간다는 사실이다. 모델은 "예약해 줘"라고 도구를 호출할 뿐이고, 실제로 시각을 지키고 깨우는 일은 게이트웨이가 한다 — 그래서 모델을 바꿔도 예약은 그대로 살아 있고, 게이트웨이가 떠 있는 동안만 작업이 지켜진다. 이 능력이 주는 가치는 분명하다 — 에이전트가 요청과 요청 사이의 빈 시간을 능동적으로 채우는 주체가 된다.

핵심 문제 — 예약만으로는 부족하다: "어떻게 깨우고, 결과를 어디로 보내나"

"미래에 작업을 건다"는 발상 자체는 단순하다. 진짜 어려운 건 그 뒤의 세 가지 결정이다. 구체적인 실패 시나리오로 풀어 보자.

• 깨우는 방식 문제: 예약 작업을 사람이 보던 그 대화 흐름(메인 세션) 안에서 깨울 것인가, 아니면 격리된 새 세션에서 조용히 돌릴 것인가? 메인 세션 안에서 무겁게 돌리면 사람과의 대화 맥락이 자동 리셋되는 타이밍이 어긋나거나, 켜져 있던 채팅 작업이 스케줄 작업에 밀린다.
• 전달 방식 문제: 작업이 돌긴 했는데 결과가 아무 데도 안 가면 "조용한 성공"이라 무의미하다. 반대로 내부 점검용 작업이 매번 채팅방에 알림을 쏘면 소음이 된다.
• 모델·도구 권한 문제: 주간 심층 분석은 비싼 고성능 모델로, 단순 리마인더는 가벼운 모델로 돌리고 싶다. 또 예약 작업이 시스템 명령을 멋대로 실행하면 위험하니, 쓸 수 있는 도구를 좁혀야 한다.

특히 자율 에이전트에서 가장 무서운 건 조용한 실패다. 매일 7시 브리핑이 사흘째 토큰 만료로 깨지고 있어도, 결과가 어디로도 안 가게 설정돼 있으면 사람은 영원히 모른다. 그래서 cron 도구는 단순히 "시각에 깨우기"가 아니라 "어떤 모드로 깨우고, 결과를 어디로 보내고, 실패하면 어떻게 알릴지"까지 한 묶음으로 다뤄야 한다.

다이어그램 설명. 이 그림은 "예약했다"는 한 줄 뒤에 숨은 세 갈래의 결정을 펼쳐 보여준다. '예약했다' 단계에서 갈라지는 첫 갈래는 작업을 어떤 실행 스타일로 깨울지(사람이 보던 대화 흐름 안에서 깨우는 방식, 매번 새 임시 세션에서 격리 실행하는 방식 등), 둘째 갈래는 결과를 채팅으로 알릴지 외부 시스템으로 보낼지 아무 데도 안 보낼지, 셋째 갈래는 어떤 모델과 어떤 도구 권한으로 돌릴지다. 이 세 가지가 따로 노는 게 아니라 한 작업 정의 안에 함께 들어간다는 게 핵심이다. 흔히 cron을 "시각 알람"으로만 생각하지만, 실무에서 막히는 건 시각이 아니라 이 세 결정이다 — 작업이 돌아도 결과가 안 보이거나, 비싼 모델로 단순 작업을 돌려 비용이 새거나, 권한이 넓어 위험해진다. 그래서 진짜 문제는 "예약 + 깨우기 + 전달 + 권한"을 하나의 일관된 도구 호출로 묶는 것이고, OpenClaw cron 도구가 푸는 것이 바로 이 묶음이다.

해결 방법 — 실행 스타일·전달 모드·오버라이드를 한 도구 호출에 묶는다

OpenClaw는 에이전트가 cron 도구를 호출할 때 스케줄(언제)·실행 스타일(어떻게 깨우나)·전달 모드(어디로)·오버라이드(무슨 권한)를 하나의 작업 정의로 받아 게이트웨이의 SQLite(파일 하나로 동작하는 가벼운 관계형 데이터베이스) 상태 DB에 저장한다. 작업 정의·실행 상태·실행 이력이 모두 거기 영속되므로 게이트웨이를 재시작해도 예약이 사라지지 않는다. 하나씩 풀어 보자.

실행 스타일 — 어느 세션에서 깨어날 것인가

다이어그램 설명. 이 그림은 예약 작업이 "어느 세션에서 깨어나는가"의 네 가지 선택지를 보여준다. 메인 세션 방식은 사람이 보던 대화 흐름에 시스템 이벤트를 끼워 깨우는 방식으로 가벼운 리마인더에 맞고, 격리 방식은 매 실행마다 새 대화 기록으로 시작하는 일회용 세션이라 독립 작업에 맞으며, 현재 세션 방식은 작업을 만든 그 순간의 대화에 묶여 맥락을 이어 가고, 명명 세션 방식은 "매일 스탠드업"처럼 어제 요약 위에 오늘 요약을 쌓아 가는 영속 워크플로우에 쓴다. 그래서 가치는 "작업 성격에 맞는 격리 수준을 한 플래그로 고른다"는 데 있다 — 대화 맥락을 더럽히지 않으면서도 필요할 땐 이어 갈 수 있다.

전달 모드 — announce / webhook / none

예약 작업이 돈 뒤 결과를 어디로 보낼지가 전달 모드(delivery)다. 세 가지가 있고, 각각 "에이전트가 직접 못 보냈을 때 시스템이 대신 어떻게 처리하는가"를 정의한다.

다이어그램 설명. 이 그림은 작업이 끝난 뒤 결과가 흐르는 세 갈래를 보여준다. 채팅 알림 방식(announce)은 에이전트가 직접 메시지를 보내지 못한 경우 최종 텍스트를 지정 채널로 시스템이 대신 쏴 주는 대체 전달이고, HTTP 전송 방식은 완료 이벤트를 외부 주소에 POST해 다른 시스템이 받아 처리하게 하며, none은 시스템 차원의 대체 전달 없이 에이전트가 직접 보낸 것만 밖으로 나간다. 그래서 가치는 "결과의 행선지를 작업 성격에 맞게 분리"한다는 데 있다 — 사람이 볼 건 채팅으로, 기계가 받을 건 HTTP로, 내부 점검은 조용히.

에이전트 오버라이드 — 모델·사고 수준·도구 권한을 작업마다 다르게

모든 예약 작업이 같은 모델, 같은 권한으로 돌 필요는 없다. cron 도구는 작업마다 오버라이드(override, 기본값을 그 작업에 한해 덮어쓰는 설정)를 받는다.

다이어그램 설명. 이 그림은 한 예약 작업에 걸 수 있는 네 가지 오버라이드를 보여준다. 모델 지정은 그 작업의 주 모델을 고르는 것이고, 사고 수준은 모델이 답하기 전 얼마나 깊이 추론할지를 조절하며, 도구 제한은 그 작업이 쓸 수 있는 도구를 좁히고, 컨텍스트 경량화는 매 세션 자동 주입되는 워크스페이스 파일을 생략해 가볍게 돌린다. 가치는 "작업의 가치에 비용·권한을 맞춘다"는 데 있다 — 주간 심층 분석엔 고성능 모델과 높은 사고 수준을, 단순 리마인더엔 가벼운 모델과 좁은 도구 권한을.

두 가지 실제 작업을 비교

도구 호출이 실제로 어떻게 다른지, 두 작업을 비교 블록으로 나란히 쌓아 보자.

▲ 작업 1 — 사람에게 보내는 반복 리포트

다이어그램 설명. 이 작업은 매일 아침 7시에 격리 세션에서 깨어나 밤사이 변경사항을 요약하고, 그 결과를 슬랙 채널로 알리는(announce) 전형적인 반복 리포트다. 타임존을 명시한 게 핵심인데, cron 표현식에서 시각은 타임존이 없으면 협정 세계시(UTC) 기준으로 해석되므로 "현지 아침 7시"를 원하면 반드시 타임존을 적어야 한다(안 적으면 게이트웨이 호스트의 타임존을 따른다). 사람이 읽을 결과라 채팅 알림 모드를 골랐고, 격리 세션이라 매일 새 맥락에서 깨끗하게 돈다. 이 작업이 주는 가치는 사람이 매일 아침 "요약해 줘"라고 말하지 않아도 요약이 도착한다는 것이다.

▲ 작업 2 — 기계가 실행하는 결정적 점검

다이어그램 설명. 이 작업은 15분마다 셸 스크립트를 직접 실행해 큐 길이를 재는 명령 페이로드(command payload) 작업이다. 위의 아침 브리핑과 달리 모델(LLM)을 부르지 않는다 — 게이트웨이 호스트에서 스크립트를 그대로 돌려 표준 출력을 결과로 잡고, 그 텍스트를 텔레그램으로 알린다. 표준 출력이 비어 있고 표준 에러만 있으면 에러 내용을, 둘 다 있으면 묶음을 전달하며, 종료 코드가 0이 아니면 실패로 기록한다. 이 패턴이 따로 있는 이유는 "결정적인 스크립트는 모델을 거칠 이유가 없기 때문"이다 — 큐 길이 재기 같은 일에 LLM을 부르면 비용·지연·비결정성만 생긴다.

결과 — 에이전트가 빈 시간을 능동적으로 채운다

cron 도구가 붙으면서, 처음에 본 "지금 요청에만 반응하던" 에이전트가 이렇게 달라진다.

이전 (요청-응답만)	이후 (cron 도구를 쥔 에이전트)
사람이 말을 걸어야만 동작	스스로/지시로 미래 시점에 작업 예약
요청 사이 빈 시간은 idle	예약 시각마다 깨어나 능동적으로 일함
"깨우는 방식" 개념 없음	메인/격리/현재/명명 세션 중 작업 성격에 맞게 선택
결과가 그 자리 대화에만 남음	announce·webhook·none으로 행선지 분리
실패하면 그 턴에서 끝	실패 알림이 별도 경로로 빠져나옴
모든 작업이 같은 모델·권한	작업마다 모델·사고 수준·도구 권한 오버라이드

정리하면, OpenClaw의 cron 도구는 에이전트를 "불러야 오는 비서"에서 "스스로 일정을 짜는 비서"로 바꾼다. 핵심은 단순한 "시각 알람"이 아니라, 예약과 함께 어떤 세션에서 깨우고, 결과를 어디로 보내고, 어떤 모델·권한으로 돌릴지를 하나의 도구 호출로 묶었다는 데 있다. 이 묶음 덕분에 에이전트는 사람의 손이 닿지 않는 시간에도 일하되, 그 일의 격리 수준·전달 행선지·실패 알림을 작업 성격에 맞게 스스로 조율한다. 화려한 모델 능력보다, 이렇게 "미래의 자기에게 일을 거는 능력"이야말로 에이전트가 진짜 비서처럼 능동적으로 느껴지게 하는 조건이다 — 점검과 보고가 자동으로 흐르면, 사람은 예외와 승인에만 개입하면 되기 때문이다. (덧붙이면, 사람이 이 예약 작업들을 브라우저 화면에서 한눈에 보고 끄고 켜는 관리 경험은 별도의 이야기다 — 이 글은 에이전트가 쥐는 도구 측면에 집중했다.)

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.