하트비트 메커니즘 (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)

관련 개념

소스