하트비트 메커니즘 (Heartbeat Mechanism)
에이전트 프레임워크가 일정 주기(매 시간, 매 분 등)로 LLM 에이전트를 자동 호출하는 패턴. 수동적 챗봇(메시지 수신 시에만 응답)을 능동적 에이전트(주기적 자율 행동)로 전환하는 핵심 메커니즘.
설명
일반 AI 챗봇은 **수동적(reactive)**이다. 사용자가 메시지를 보내야만 응답한다. ChatGPT·Claude 등 모든 챗 인터페이스가 이 모델을 따른다.
하트비트 메커니즘은 이를 뒤집는다. 에이전트 런타임(오케스트레이터)이 크론잡 형태로 주기적으로 에이전트를 깨운다. 에이전트는 깨어나면 자신의 일과표(HEARTBEAT.md 또는 동등한 스케줄 파일)를 확인하고, 해야 할 일이 있으면 수행, 없으면 대기 신호(HEARTBEAT_OK)를 반환한다.
동작 흐름
[크론잡 / 오케스트레이터]
↓ 매 시간 (또는 설정 주기)
[에이전트 호출]
↓
[HEARTBEAT.md(일과표) 확인]
↓
조건 판단:
- 할 일 있음 → 작업 실행 (Slack 알림, 브리핑, 리마인드 등)
- 할 일 없음 → HEARTBEAT_OK 반환 → 대기
실사례: 뽀짝이 (지피터스 AI스터디 운영 에이전트)
OpenClaw 프레임워크 기반 에이전트 뽀짝이가 매 시간 하트비트를 받아 실행하는 루틴 (2026-02 기준):
| 시각 | 트리거 | 동작 |
|---|---|---|
| 매 시간 | Slack 채널 모니터링 | 새 질문 있으면 자동 답변 |
| 매 시간 | Linear 이슈 확인 | 긴급 이슈 알림 발송 |
| 09:00 KST | 고정 스케줄 | 일일 브리핑 발송 |
| 수시 | 예약 리마인드 | 카카오톡방 전송 |
(출처: bbojjak-openclaw-agentic-architecture-lesson01)
수동적 챗봇 vs 능동적 에이전트
| 구분 | 수동적 챗봇 | 능동적 에이전트 (하트비트) |
|---|---|---|
| 응답 조건 | 사용자 메시지 수신 시만 | 주기적 자율 호출 |
| 모니터링 | 불가 | 자율 순찰·체크 |
| 브리핑 | 요청 시만 | 정해진 시각 자동 발송 |
| 리마인드 | 수동 | 예약 자동 실행 |
설계 고려사항
- 주기 설정: 너무 짧으면 LLM 비용 폭증, 너무 길면 응답 지연. 일반적으로 1시간 주기 권장 (실시간성 필요 시 5-15분).
- 일과표 분리: HEARTBEAT.md처럼 별도 파일로 루틴 정의 → 코드 변경 없이 일과 수정 가능.
- HEARTBEAT_OK 패턴: 할 일 없을 때 명시적 신호 반환 → 오케스트레이터가 정상 동작 여부 확인 가능.
- 상태 저장: 하트비트 간 상태는 MEMORY.md 또는 외부 DB에 저장해야 세션 간 연속성 유지.
하트비트의 3가지 한계와 교훈
실전 운영(뽀짝이 2026-02)에서 발견된 하트비트의 구조적 한계. (출처: bbojjak-openclaw-scheduling-design-lesson09)
한계 1: “시간을 모른다”
HEARTBEAT.md에 “오전 9시 — 아침 브리핑”을 텍스트로만 적으면, 새벽 0시 하트비트가 그대로 실행한다. 시간 조건은 명시적으로 강제해야 한다:
> **시간 조건**: KST 08:30~09:30 사이에만 실행.
> 이 시간대 밖이면 절대 발송 금지!더 강력한 해결: 정확한 시각이 필요한 작업은 크론잡으로 이전.
한계 2: “독립 세션 간 무지”
하트비트 세션과 크론잡 세션은 서로 독립이라 “이미 보냈다”를 모른다. 같은 작업을 양쪽에 배치하면 중복 발송이 발생한다. 같은 작업은 한 곳에서만 — 발송·리포트는 크론잡 전담, HEARTBEAT.md에서 삭제.
한계 3: “기억이 짧다”
하트비트의 상태 기록은 agent-memory-architecture의 1단계(대화 맥락)에만 있다. 세션이 길어지면 컴팩션으로 “이미 보고했다”가 사라져 반복 보고가 발생한다. 중요 상태 기록은 AGENTS.md(3단계 영구 기억)에 절대 규칙으로 저장.
상세 선택 기준과 크론잡 대비는 agentic-scheduling-design 참조.
하트비트와 채널 세션 바인딩
하트비트는 특정 채팅 컨텍스트(채널)의 세션에 바인딩되어 실행된다. 하트비트가 발동될 때 에이전트는 해당 채널 세션의 대화 히스토리를 컨텍스트로 받는다.
- 하트비트 루틴과 채널 대화가 같은 세션 히스토리를 공유
- 이것이 하트비트 에이전트가 이전 대화 맥락을 “기억하는” 메커니즘
- 채널 세션이 컴팩션되면 하트비트도 압축된 맥락 위에서 실행
세션 구조 상세는 agent-session-architecture 참조. (출처: bbojjak-openclaw-session-architecture-lesson06)
하트비트 vs 웹훅 — 에이전트 트리거 두 가지 방식
agentic-webhook-integration은 하트비트와 보완 관계를 이루는 트리거 패턴이다.
| 구분 | 하트비트 | 웹훅 |
|---|---|---|
| 트리거 주체 | 오케스트레이터(내부) | 외부 서비스 |
| 시점 | 주기적(시간 기반) | 이벤트 발생 시 즉시 |
| 적합 용도 | 예정된 루틴·브리핑·모니터링 | 실시간 이벤트 대응·CS 자동화 |
| 성격 | 능동적(proactive) | 반응적(reactive) |
실전 에이전트는 두 방식을 함께 사용한다: 하트비트로 정기 루틴을 처리하고, 웹훅으로 즉각적인 외부 이벤트에 반응한다. (출처: bbojjak-openclaw-webhook-pipeline-lesson03)
관련 개념
- agentic-webhook-integration — 이벤트 기반 반응적 트리거 패턴 (웹훅)
- agent-workspace-structure — HEARTBEAT.md 파일이 하트비트 루틴 정의
- harness-engineering — 하트비트는 Stop Hook + CronCreate 조합으로 구현 가능
- agentic-ai-curriculum — 능동적 에이전트 교육 커리큘럼의 핵심 패턴