그것은 운이 아니었습니다. 제가 6개월 동안 다듬어 온 Cron 아키텍처이며, 현재는 스위스 시계처럼 정확하게 작동하고 있습니다.

만약 여러분이 OpenClaw를 사용하면서 여전히 수동으로 작업을 실행하고 있다면, 가장 좋은 부분을 놓치고 있는 것입니다. 인간의 감독 없이 밤샘 인력을 구축한 정확한 방법을 소개합니다.

핵심 통찰: 에이전트(Agents)는 당신이 쉬는 동안 일할 때 더 강력하다

근본적인 변화는 제가 OpenClaw 에이전트를 '대화하는 챗봇 (chatbot)'으로 생각하는 것을 멈추고, 잠을 자지 않는 직원처럼 취급하기 시작했을 때 일어났습니다.

직원들은 새벽 2시에 일상적인 업무를 수행하기 전에 허락을 구하지 않습니다. 그들에게는 일정, 명확한 지침, 그리고 실행할 도구가 있습니다. 저는 제 에이전트에게도 동일한 구조를 구축했습니다.

제 Cron 작업은 세 가지 범주로 나뉩니다:

1. 데이터 수집 (Data collection) — 지표를 가져오고, 상태를 확인하며, 콘텐츠를 수집합니다.
2. 콘텐츠 생성 (Content generation) — 템플릿과 최신 데이터를 기반으로 초안을 작성합니다.
3. 전달 (Delivery) — 결과에 따라 게시, 이메일 발송 또는 알림을 수행합니다.

마법 같은 점은 각 작업이 다음 작업의 입력값이 된다는 것입니다. 아침 요약본(morning digest)은 스스로 작성되지 않습니다. 밤사이의 데이터 수집이 먼저 완료될 때까지 기다립니다.

아키텍처: 4개의 레이어, 변수 없음

제가 매일 밤 실행하는 스택을 단순화하면 다음과 같습니다:

Layer 1: 상태 확인 (Health Checks) (매시간, 24/7)
  └── MC API 상태 확인 → 장애 발생 시 Slack 알림

...

핵심 제약 조건: Layer 3는 Layer 2가 완료될 때까지 절대 시작되지 않습니다. 저는 간단한 파일 잠금 (file lock) 패턴을 사용하여 이를 강제합니다.

코드: 기다려야 할 때를 아는 자가 치유형 Cron

다음은 제가 아침 요약본을 위해 사용하는 Cron 정의입니다. 이는 밤사이 데이터가 준비되어 있는지에 의존합니다:

{
  "name": "Morning Digest — Wait for Data",
  "schedule": { "kind": "cron", "expr": "30 7 * * 1-5", "tz": "America/New_York" },
...

제가 무엇을 했는지 주목하십시오: Cron은 단순히 실행되는 것이 아니라, 먼저 전제 조건 (preconditions)을 확인합니다. 이를 통해 대부분의 자동화된 아침 보고서를 망치는 "Cron은 실행되었지만 작업할 데이터가 없는" 문제를 제거합니다.

DEV.to 게시용 Cron의 경우, 저는 건너뛰기 패턴 (skip pattern)을 사용합니다:

# my devto-post.py에서 오늘 날짜를 확인합니다
today = datetime.now().strftime("%Y-%m-%d")
posted_log = f"data/devoto-pm-posted-today.json"
...

이러한 멱등성 (Idempotency)은 타협할 수 없는 요소입니다. 동일한 콘텐츠를 다시 게시하는 고장 난 Cron은 아예 Cron이 없는 것보다 더 나쁩니다.

무엇이 잘못되는가 (그리고 어떻게 처리하는가)

6개월이 지난 후, 실제로 발생하는 문제들은 다음과 같습니다:

문제 1: 데이터 소스 다운
해결책: 모든 수집기 (Collector)에 5분 타임아웃 (Timeout)을 설정하고 타임스탬프가 포함된 부분 파일을 작성하도록 했습니다. 다운스트림 작업 (Downstream jobs)은 타임스탬프를 확인하여 데이터가 오래된 경우 유연하게 건너뜁니다.

문제 2: 야간 시간대 모델 API 속도 제한 (Rate limits)
해결책: 지수 백오프 (Exponential backoff)를 적용한 재시도 큐 (Retry queue)를 구축했습니다. 새벽 1시 실행이 실패하면 새벽 2시, 그다음엔 3시에 다시 시도합니다. 아침이 되면 실패했던 작업의 90%가 성공해 있습니다.

문제 3: Cron은 실행되었으나 이전 실행이 아직 진행 중인 경우
해결책: ~/.openclaw/cron-runner.lock에 PID 파일을 사용합니다. 새로운 실행이 10분 이상 된 오래된 잠금 파일 (Lock file)을 발견하면, 오래된 프로세스를 종료하고 제어권을 가져옵니다.

# 모든 Cron 작업 실행 전에 실행하는 잠금 확인 래퍼 (Lock-check wrapper)
LOCKFILE="$HOME/.openclaw/cron-runner.lock"
if [ -f "$LOCKFILE" ]; then
...

6개월 후의 결과

• 평일 평균 47개 작업 수행: 수동으로 실행하던 시절의 약 5개에서 증가
• 아침 시간대 개입 제로 — 요청 사항이 아닌 완료된 작업과 함께 아침을 맞이합니다
• DEV.to 게시 성공률: 98% (6개월 동안 두 번 건너뜀, 둘 다 API 문제로 인한 것)
• 예상 절약 시간: 수동 작업 실행 시간 주당 3~4시간

가장 어려운 부분은 기술적인 설정이 아니었습니다. 그것은 사고방식 (Mental model)을 바꾸는 것이었습니다. 자동화를 자동화한다는 것은 첫날부터 실패 모드 (Failure modes)를 고려하며 생각한다는 것을 의미합니다.

내가 배운 것

1. 멱등성 (Idempotency)이 전부입니다. 만약 당신의 cron이 안전하게 두 번 실행될 수 없다면, 결국 최악의 타이밍에 두 번 실행될 것입니다.

2. 성공을 가정하는 것보다 전제 조건 확인 (Precondition checks)이 더 중요합니다. 데이터가 거기 있다고 가정하지 마세요. 확인하세요. 이전 작업이 완료되었다고 가정하지 마세요. 검증하세요.

3. 야간 근무 (The night shift)는 과소평가되어 있습니다. 모델 API는 밤사이에 지연 시간 (Latency)이 더 낮습니다. 속도 제한 (Rate limits) 관리도 더 쉽습니다. 당신의 실제 사용자들은 지켜보고 있지 않습니다. 누군가를 방해할 수 있는 문제가 발생할 가능성이 없는 시간에 무거운 작업을 실행하세요.

4. 파일 기반 상태 (File-based state) > 메모리 (Memory). cron 실행 간에 제 에이전트가 유지하는 "메모리"는 단순히 JSON 파일들입니다. 단순하고, 디버깅이 가능하며, 버전 관리가 가능합니다. 저는 에이전트가 재시작 후에도 상태를 기억할 것이라고 절대 믿지 않습니다. 저는 그것을 명시적으로 만듭니다.

5. 작게 시작해서 계층을 추가하세요. 저의 첫 번째 cron은 단 하나의 상태 확인 (Health check)이었습니다. 6개월 후, 그것은 12개의 작업으로 구성된 파이프라인 (Pipeline)이 되었습니다. 처음부터 전체 시스템을 설계할 필요는 없습니다. 실제 작동하는 무언가를 먼저 실행하고, 잘 작동하는 것을 바탕으로 구축해 나가면 됩니다.

만약 당신이 OpenClaw를 실행하고 있는데 아직 cron 열차에 올라타지 않았다면, 오늘 밤 바로 시작하세요. 작업 하나만요. 딱 하나만요. 당신이 하는 가장 지루하고 반복적인 일을 골라 자동화하세요. 그러면 다시는 수동으로 작업하는 과거로 돌아가지 못할 것입니다.