JYP Garden

에이전트 스케줄링 설계 (Agentic Scheduling Design)

Properties1
tagsconcept, agentic-architecture, knowledge

9 min read

에이전트 스케줄링 설계 (Agentic Scheduling Design)

AI 에이전트의 자동 실행을 설계하는 원칙. 하트비트(주기적 순찰)와 크론잡(정시 배달) 두 메커니즘을 목적에 맞게 배치하며, 같은 작업을 양쪽에 배치하면 중복이 발생한다. 하트비트는 “시간을 모르고 기억이 짧다”는 한계를 명시적 조건과 영구 기억(AGENTS.md)으로 보완한다.

두 메커니즘 비교

항목하트비트크론잡
실행 트리거주기적 (예: 1시간마다)정확한 시각 (5-field cron)
담당 작업 수여러 개 (체크리스트)하나씩
시간 정확도낮음 (주기 내 오차)높음 (초 단위 정확)
세션메인 세션 내isolated (독립) 세션
기억컴팩션으로 손실 가능세션이 독립이라 아예 기억 없음
비유집 안 순찰원우유 배달부

(출처: bbojjak-openclaw-scheduling-design-lesson09)

하트비트 — 주기적 순찰

heartbeat-mechanism에서 상세 설명. 요약:

{
  "heartbeat": {
    "every": "1h",
    "activeHours": { "start": "00:00", "end": "24:00" }
  }
}

에이전트가 주기마다 HEARTBEAT.md 체크리스트를 읽고 → 할 일 있으면 처리, 없으면 HEARTBEAT_OK 반환.

하트비트에 적합한 작업:

  • ✅ “혹시 급한 거 있나?” 모니터링 (여러 채널 한 번에)
  • ✅ “새 문의 들어왔나?” 폴링
  • ✅ “긴급 이슈 생겼나?” 체크

공통 특성: 답이 “있다/없다”이고, 시간 정확도가 불필요한 것.

크론잡 — 정시 배달

openclaw cron add \
  --name "<작업명>" \
  --cron "0 9 * * *"       # 5-field 크론 표현식
  --tz "Asia/Seoul"        # 타임존 명시 필수
  --session isolated       # 독립 세션
  --message "<에이전트 지시>"

크론잡에 적합한 작업:

  • ✅ “매일 9시에 매출 리포트 보내” (정확한 시각)
  • ✅ “스터디장들에게 이메일 보내” (외부 발송)
  • ✅ “20분 뒤에 알려줘” (1회성 리마인더)

공통 특성: 정확한 시각이 중요하고, 다른 작업과 섞이면 안 되는 것.

isolated 세션의 의미

크론잡은 --session isolated 옵션으로 메인 세션과 분리된 별도 세션에서 실행된다:

  • 크론잡 실행 중 대화 맥락이 메인 세션에 섞이지 않음
  • 끝나면 결과만 announce로 메인 채널에 전달
  • 별도 모델(Sonnet 등) 지정으로 비용 최적화 가능
  • 세션이 끝나면 완전히 소멸 (메인 세션과 기억 공유 없음)

3가지 실전 사고와 교훈

사고 1: 새벽 0시 아침 브리핑

원인: HEARTBEAT.md에 “오전 9시 — 아침 브리핑”이 텍스트로만 존재. 시간 조건이 코드로 강제되지 않음.

결과: 새벽 0시 하트비트가 “아 이거 해야 하나?” 판단 후 발송.

교훈: 하트비트는 “시간”을 모른다. 텍스트 설명은 판단 기준이 되지만, 명시적 조건이 없으면 실행된다.

해결책:

> **시간 조건**: KST 08:30~09:30 사이 하트비트에서만 실행.
> 이 시간대 밖이면 절대 발송 금지!

또는 더 강력한 해결: 정확한 시각이 필요한 작업은 → 크론잡으로 이전.

사고 2: 매출 리포트 중복 발송

원인: HEARTBEAT.md에 매출 브리핑 항목 + 크론잡도 같은 작업 실행. 하트비트 세션과 크론잡 세션은 서로 독립이라 “이미 보냈다”를 모름.

결과: 이틀 연속 같은 채널에 리포트가 2개씩 올라감.

교훈: 같은 작업은 한 곳에서만 실행해야 한다. 세션 간 독립성은 중복 발송의 근본 원인이 된다.

해결책: 시간 정확도가 필요한 작업 → 크론잡 전담. HEARTBEAT.md에서 해당 항목 삭제.

사고 3: 오류 15건 반복 보고

원인: 카카오톡 앱 오류 → 하트비트마다 순찰 실패 → 매번 오류 보고. 하트비트는 기억이 짧아 (세션 길어지면 컴팩션으로 “이미 보고했다”가 사라짐) 반복 보고.

결과: 하루 15건 이상 같은 오류 알림.

교훈: 하트비트의 기억은 agent-memory-architecture의 1단계(대화 맥락)에만 있다. 컴팩션이 발동되면 상태 기록이 사라진다.

해결책: 중요 상태 기록은 3단계(시스템 파일)에 → AGENTS.md 절대 규칙:

### 시스템 장애 보고는 최초 1회만!
- 같은 오류는 최초 1회만 보고. 이후 하트비트에서는 스킵.
- 닿이 "고쳤다"고 말할 때까지 재보고 금지.

6주 결산형 스케줄링 패턴

yt-bitgapnam-6week-solo-ai-business-challenge-2026는 장기 목표를 유지하기 위해 “고정 주기 리포팅”을 스케줄링 구조로 설계한 사례다.

  • 주차별 목표를 선공개하고 주말 단위로 결산 콘텐츠 발행
  • 일정 고정(매주 1회) + 지표 고정(4개 공약 숫자)으로 추적 단순화
  • 요일 고정보다 “주기 고정”을 우선해 직장인 제약 하에서 지속성 확보

즉, 스케줄링 설계는 정확한 발송 시간만 다루는 것이 아니라, 검증 주기를 유지하는 운영 리듬 설계까지 포함한다.

절대 하면 안 되는 패턴

Warning

스케줄링 설계에서 가장 흔한 실수 3가지

금지 패턴결과
같은 작업 하트비트 + 크론잡 양쪽에중복 발송
하트비트에 시간 조건 없이 발송 작업새벽 발송 사고
하트비트에서 실패 작업 매번 재보고알림 폭탄

권장 자동화 아키텍처

하트비트 (1h 주기) → HEARTBEAT.md 체크리스트
  담당: 모니터링·폴링·순찰 (있다/없다 확인)

크론잡 (정확한 시각) → isolated 세션
  담당: 정기 발송·이메일·리포트·리마인더

분리 원칙: 모니터링은 하트비트, 발송은 크론잡. 역할 경계가 명확해야 한다.

관련 개념

하트비트 모델 선택 — 비용 실증

하트비트가 실제 운영에서 전체 토큰 비용의 27%를 차지한다는 것이 14일 Usage 분석으로 확인됐다. (출처: bbojjak-openclaw-resilience-failover-lesson19)

대부분의 하트비트 응답 = “HEARTBEAT_OK”만 반환 → 복잡한 추론 불필요. Opus 대신 Sonnet(1/5 비용) 사용 → 전체 비용의 약 21.6% 절감.

하트비트 설정의 model 필드만 변경하면 된다. → agent-resilience-design의 작업별 모델 분리 원칙.

소스

그래프 뷰

백링크