3부·12장 HEARTBEAT.md — 능동적인 AI 만들기

어시스턴트가 똑똑하다는 말과, 어시스턴트가 일을 한다는 말은 다릅니다. 전자는 물어보면 잘 답하는 상태이고, 후자는 묻지 않아도 먼저 살펴보고 먼저 알려주는 상태입니다. OpenClaw가 정말로 에이전트처럼 느껴지는 순간은 대개 여기서 옵니다. 내가 텔레그램을 열어 "무슨 일 있어?"라고 묻기 전에, 에이전트가 먼저 "오늘 오전 일정이 겹칩니다" 또는 "긴급 메일이 하나 들어왔습니다"라고 말해주는 순간 말입니다.

그 능동성의 중심에 있는 파일이 바로 HEARTBEAT.md입니다. 이름 그대로 심장박동입니다. 에이전트는 일정 간격으로 깨어나 이 파일을 읽고, 지금 챙겨야 할 것이 있는지 확인합니다. 할 일이 없으면 조용히 넘어가고, 정말 중요한 것만 사용자에게 꺼내 놓습니다. OpenClaw 공식 문서도 Heartbeat를 "주기적으로 메인 세션에서 도는 에이전트 턴"으로 설명합니다. 즉, 백그라운드에서 무언가를 막 만들어내는 별도 작업 관리자가 아니라, 현재 에이전트가 정기적으로 눈을 뜨고 세상을 훑는 구조에 가깝습니다.¹

HEARTBEAT.md는 무엇을 바꾸는가

일반적인 챗봇은 문이 닫힌 가게와 비슷합니다. 손님이 문을 두드리면 열어줍니다. 하지만 Heartbeat가 켜진 OpenClaw는 편의점 야간 매니저에 가깝습니다. 손님이 오지 않아도 재고를 보고, 냉장고를 확인하고, 바닥이 미끄럽지 않은지 둘러봅니다. 그 덕분에 문제가 커지기 전에 먼저 움직일 수 있습니다.

이 차이는 생각보다 큽니다. 예를 들어 당신이 1인 창업가라고 해봅시다. 고객 메일, 오늘 일정, 새벽에 터진 서버 알림, 결제 실패, 미답변 문의, 경쟁사 뉴스까지 모두 직접 확인하려면 아침 30분이 순식간에 증발합니다. 그런데 Heartbeat가 있으면 에이전트가 일정 간격으로 이 신호들을 훑고, 그중 정말로 당신이 지금 알아야 할 것만 추려서 건넵니다. 반응형 도구가 능동형 동료로 변하는 지점이 바로 여기입니다.²

OpenClaw 공식 문서가 Heartbeat를 Cron과 구분해 설명하는 이유도 같습니다. Heartbeat는 "지금 확인할 게 있나?"를 묻는 느슨한 순찰이고, Cron은 "정해진 시각이 됐으니 정확히 실행해"라는 알람입니다.¹ 이 둘을 구분하지 못하면, 에이전트는 멋지기보다 시끄러워집니다.

Heartbeat와 Cron의 차이부터 잡고 가자

이 장의 핵심은 HEARTBEAT.md이지만, 시작점은 오히려 "무엇을 Heartbeat에 넣지 말아야 하는가"입니다. 실전에서 가장 많은 사고가 여기서 납니다.

Heartbeat는 상태 확인과 문맥 기반 판단에 강합니다. 최근 대화 맥락을 참고할 수 있고, 이메일·캘린더·메모리·알림처럼 여러 가벼운 점검을 한 번에 묶어 처리할 수 있습니다. 반면 정확히 오전 9시에 보내야 하는 보고서, 매주 월요일 10시에 생성해야 하는 주간 리포트처럼 시각이 중요한 일은 Cron이 더 적합합니다.³

쉽게 외우면 됩니다. "있나?"로 끝나는 일은 Heartbeat, "해라"로 끝나는 일은 Cron입니다.

• "긴급 메일 있나?"

• "오늘 일정 충돌 있나?"

• "미해결 오류가 새로 생겼나?"

이런 질문은 Heartbeat에 어울립니다.

반대로 아래처럼 정확한 시점이 핵심인 일은 Cron에 넘겨야 합니다.

• 매일 오전 9시 브리핑 보내기

• 매주 월요일 주간 보고서 생성하기

• 매월 1일 정산 요약 보내기

이 원칙을 지키면 에이전트가 부지런해지고, 지키지 않으면 새벽 3시에 "좋은 아침입니다"라는 메시지를 받을 수 있습니다. 상상만 해도 기분이 묘해집니다.

Heartbeat는 실제로 어떻게 동작할까

OpenClaw에서 Heartbeat는 일정 주기마다 메인 세션에서 한 번의 에이전트 턴을 실행합니다. 기본 간격은 보통 30분이며, Anthropic OAuth나 setup-token 계열 인증을 쓰는 경우 1시간으로 잡히기도 합니다.¹ 이때 시스템은 에이전트에게 HEARTBEAT.md를 읽으라고 지시하고, 할 일이 없다면 HEARTBEAT_OK로 끝내라고 요구합니다.¹

이 구조가 중요한 이유는 두 가지입니다.

첫째, Heartbeat는 "정기적인 대화 한 턴"에 가깝습니다. 즉, 최근 세션 문맥을 활용해 지금 무엇이 중요한지 판단할 수 있습니다. 둘째, 할 일이 없을 때는 조용히 사라질 수 있습니다. HEARTBEAT_OK는 일종의 "이상 없음" 신호이고, OpenClaw는 이 응답을 받아 짧은 무의미한 메시지는 외부로 보내지 않고 드롭합니다.¹

이 덕분에 Heartbeat는 두 얼굴을 동시에 가질 수 있습니다. 겉으로는 조용하지만, 속으로는 꾸준히 순찰합니다. 잘 만든 Heartbeat는 부지런한데 시끄럽지 않습니다.

왜 HEARTBEAT.md가 따로 필요한가

그냥 설정 파일에 하트비트 간격만 넣으면 되는 것 아닐까 싶을 수 있습니다. 하지만 Heartbeat를 진짜 유용하게 만드는 것은 주기가 아니라 체크리스트입니다. 주기는 심장박동의 속도이고, HEARTBEAT.md는 에이전트가 눈을 떴을 때 읽는 오늘의 순찰표입니다.

공식 문서도 작은 HEARTBEAT.md를 권장합니다.¹ 이유는 단순합니다. Heartbeat는 자주 실행되기 때문입니다. 파일이 길고 복잡할수록 매번 더 많은 토큰을 태웁니다. 실전 운영 사례에서도 HEARTBEAT.md가 점점 "잡동사니 서랍"이 되면 비용이 급격히 늘고, 실제로는 아무 일도 안 하는 하트비트가 하루 종일 반복된다는 점이 지적됩니다.⁴

즉, HEARTBEAT.md는 길수록 좋은 문서가 아닙니다. 오히려 짧고 날카로울수록 좋습니다. 체크리스트는 가볍게, 판단 기준은 명확하게, 알림 조건은 좁게 잡아야 합니다.

좋은 HEARTBEAT.md의 기본 원칙

좋은 HEARTBEAT.md는 문학 작품이 아닙니다. 에이전트가 오해 없이 읽고 행동할 수 있는 운영 문서입니다. 다음 네 가지 원칙을 기억하면 대부분의 사고를 줄일 수 있습니다.

첫째, "조건 → 행동" 구조로 씁니다. 막연하게 "중요한 메일을 잘 확인해"라고 쓰면 중요의 기준이 흔들립니다. 대신 "VIP 발신자 또는 제목에 urgent가 포함된 읽지 않은 메일이 있으면, 한 줄 요약과 권장 액션을 보낸다"처럼 써야 합니다.

둘째, "할 일 없으면 침묵"을 분명하게 적습니다. 공식 기본 프롬프트가 HEARTBEAT_OK를 요구하는 이유가 바로 이것입니다.¹ 에이전트는 빈칸을 채우려는 경향이 있어서, 할 일 없을 때도 무언가 말하고 싶어 합니다. 침묵 규칙을 명시해야 합니다.

셋째, 알림에는 반드시 중복 방지 규칙을 둡니다. 같은 오류를 매시간 반복 보고하기 시작하면, 처음에는 든든하지만 곧 귀찮고, 나중에는 완전히 무시하게 됩니다. 실전 플레이북에서도 "이미 보고한 항목은 다시 보내지 말 것"과 최대 빈도 제한을 꼭 넣으라고 권합니다.⁵

넷째, 시간 조건이 필요한 항목은 범위로 씁니다. Heartbeat는 정확히 9시 0분 0초에 뛰는 시계가 아닙니다. 8시 47분, 9시 16분처럼 약간 흔들릴 수 있습니다.³ 그래서 "오전 9시에 브리핑 보내기"보다 "KST 08:30~09:30 사이에만 브리핑 준비 여부를 점검"처럼 써야 합니다. 아니면 아예 그 작업을 Cron으로 옮기는 편이 낫습니다.

가장 먼저 만들어볼 HEARTBEAT.md

처음부터 거창하게 시작할 필요는 없습니다. 오히려 너무 의욕이 넘치면 실패합니다. 가장 좋은 첫 버전은 "내 하루를 망칠 수 있는 것 3개만 본다" 수준입니다.

아래는 초보자에게 무난한 예시입니다.

# HEARTBEAT.md

에이전트는 각 하트비트마다 아래 항목을 순서대로 확인한다.
실행할 일이 없으면 반드시 HEARTBEAT_OK를 응답하고 종료한다.
불필요한 메시지는 보내지 않는다.

## 1. 긴급 메일 확인
- 지난 확인 이후 새로 도착한 읽지 않은 메일 중 VIP 발신자 또는 긴급 키워드가 있는지 확인한다.
- 있으면 발신자, 핵심 한 줄, 지금 필요한 행동 한 줄만 요약해서 보낸다.
- 이미 같은 메일을 알린 적이 있으면 다시 보내지 않는다.

## 2. 일정 충돌 확인
- 앞으로 24시간 안의 일정 중 겹치거나 준비 시간이 15분 미만인 항목이 있는지 확인한다.
- 있으면 충돌 원인과 추천 조정안을 보낸다.
- 같은 충돌에 대해서는 6시간 이내 재알림하지 않는다.

## 3. 인간 체크인
- 현지 시간 기준 09:00~18:00 사이에만 실행한다.
- 최근 4시간 동안 중요한 알림도 없고 사용자의 메시지도 없었다면, 짧게 "도와줄 일 있나요?"라고 한 번만 묻는다.
- 같은 날 1회 이상 반복하지 않는다.

이 정도면 충분합니다. 벌써 에이전트가 "물어보면 답하는 존재"에서 "가끔 먼저 살펴보는 존재"로 바뀝니다.

설정 파일에서 켜야 하는 것들

HEARTBEAT.md만 써두면 끝은 아닙니다. Heartbeat의 리듬은 설정에서 잡습니다. 공식 문서 기준으로 핵심은 agents.defaults.heartbeat 블록입니다.¹

가장 무난한 시작 설정은 아래와 같습니다.

{
  "agents": {
    "defaults": {
      "heartbeat": {
        "every": "30m",
        "target": "last",
        "activeHours": {
          "start": "09:00",
          "end": "22:00",
          "timezone": "Asia/Seoul"
        }
      }
    }
  }
}

여기서 중요한 항목만 쉬운 말로 풀어보겠습니다.

every는 심장박동 간격입니다. 너무 짧으면 과민한 비서가 되고, 너무 길면 둔한 감시자가 됩니다. 처음에는 30분이나 1시간이 적당합니다.¹

target은 메시지를 어디로 보낼지 정합니다. 기본값은 none이라서 외부로 보내지 않고 내부에서만 돌 수 있습니다. 실제로 나에게 먼저 말 걸기를 원하면 last로 두는 편이 편합니다. 그러면 최근 대화한 채널로 결과를 보냅니다.¹

activeHours는 야간 소음 방지 장치입니다. 공식 문서도 사용자의 로컬 시간대 기준 활동 시간 창을 둘 수 있다고 설명합니다.¹ 이걸 켜두면 새벽 2시에 우산 챙기라는 말을 듣지 않아도 됩니다.

activeHours는 선택이 아니라 예의다

초기 사용자는 종종 이 기능을 빼먹습니다. 그 결과 에이전트는 아주 열심히, 그리고 아주 나쁜 타이밍에 일합니다. Heartbeat는 피곤함을 모릅니다. 그러니 사람이 대신 "이 시간에는 깨우지 마"를 설정해줘야 합니다.

한국 사용자라면 보통 아래 두 패턴이 무난합니다.

• 개인용 비서: 08:00~22:00, Asia/Seoul

• 업무용 운영 봇: 09:00~19:00, Asia/Seoul

• 24시간 모니터링용: activeHours를 생략하거나 00:00~24:00

주의할 점도 있습니다. 공식 문서에 따르면 시작 시간과 종료 시간을 똑같이 두면 하루 종일 켜지는 것이 아니라, 폭이 0인 창으로 해석되어 하트비트가 계속 스킵됩니다.¹ 08:00~08:00은 "24시간"이 아니라 "영원히 자라"에 가깝습니다.

조용하지만 똑똑하게 만드는 옵션들

Heartbeat를 오래 운영하다 보면 두 가지 고민이 생깁니다. 하나는 비용, 다른 하나는 맥락입니다. 공식 문서는 이 둘을 조절할 수 있는 옵션을 제공합니다.¹

lightContext: true는 Heartbeat가 실행될 때 작업 문맥을 가볍게 줄이는 옵션입니다. HEARTBEAT.md만 있으면 충분한 경우 토큰 낭비를 줄일 수 있습니다.¹

isolatedSession: true는 매번 새로운 세션에서 Heartbeat를 실행하는 옵션입니다. 이전 대화 기록을 통째로 다시 싣지 않기 때문에 비용 절감에 효과적입니다.¹ 특히 HEARTBEAT.md가 "정적 체크리스트"에 가까울수록 잘 맞습니다.

실제 운영 사례에서도 크론을 갖춘 뒤에는 Heartbeat 주기를 30분에서 60분으로 늘리고, HEARTBEAT.md를 크게 줄이는 것만으로 비용을 절반 이상 줄였다는 보고가 있습니다.⁴ 핵심은 간단합니다. Heartbeat가 정말 잘하는 일만 남기고, 나머지는 Cron이나 별도 작업으로 보내는 것입니다.

다만 비용 최적화만 보고 lightContext와 isolatedSession을 무조건 켜면 안 됩니다. 최근 대화 맥락이 정말 중요한 Heartbeat라면, 너무 가볍게 만들수록 눈치가 둔해질 수 있습니다. 예를 들어 "어제 이야기한 투자자 미팅 후속 조치를 떠올려줘" 같은 일은 맥락이 필요합니다. 에이전트도 사람처럼, 너무 많은 걸 잊으면 열심히 일해도 엉뚱한 말을 합니다.

"먼저 보고하는 에이전트"를 만드는 설계법

좋은 Heartbeat는 단순히 체크리스트를 도는 것이 아니라, 언제 말을 걸어야 하는지를 압니다. 이 기준이 없으면 에이전트는 두 극단으로 갑니다. 지나치게 말이 많거나, 지나치게 조용하거나.

커뮤니티에서 많이 공유되는 운영 원칙은 꽤 상식적입니다. 변화가 있을 때만 말하고, 사용자의 결정이 필요한 순간에만 말하고, 추천안이나 초안이 준비됐을 때만 말하라는 것입니다.⁶ 바꿔 말하면 "그냥 보고했다"는 이유만으로는 메시지를 보내지 말라는 뜻입니다.

이 기준을 HEARTBEAT.md 문장으로 바꾸면 대략 이렇게 됩니다.

- 변화가 없으면 알리지 않는다.
- 이전에 보낸 정보의 반복이면 알리지 않는다.
- 사용자의 결정을 기다리는 항목이 생겼을 때만 알린다.
- 내가 바로 쓸 수 있는 초안, 제안, 우선순위가 있을 때만 보낸다.

이 네 줄만으로도 하트비트의 품질이 크게 좋아집니다. 에이전트가 "나 일했어요"를 보고하는 대신 "당신이 지금 아셔야 할 것"만 말하게 되기 때문입니다.

아침 9시 브리핑을 Heartbeat로 만들면 안 되는 이유

많은 사람이 처음에는 이렇게 쓰고 싶어 합니다.

## 아침 브리핑
- 오늘 일정과 메일을 요약해서 보낸다.

문제는 에이전트가 사람처럼 "아침 느낌"을 읽지 못한다는 점입니다. 새벽 3시의 Heartbeat에서 이 항목을 보고, "브리핑을 보내야 하나 보다"라고 판단할 수도 있습니다. 실전 플레이북에서 실제로 비슷한 사고가 반복됐고, 그래서 발송·알림 항목에는 반드시 시간 조건을 명시하라고 강조합니다.⁵

Heartbeat로 꼭 해야 한다면 최소한 아래 정도는 필요합니다.

## 아침 체크인
- KST 08:30~09:30 사이 Heartbeat에서만 실행한다.
- 이 시간대 밖에서는 절대 발송하지 않는다.
- 오늘 일정, VIP 메일, 우선순위 3개를 한 메시지로 정리한다.
- 같은 날 한 번 보냈다면 다시 보내지 않는다.

하지만 솔직히 말해, 이런 일은 Cron이 더 잘합니다. Heartbeat는 "오늘 아침 브리핑에 넣을 만한 새 변동이 있나"를 보는 쪽에 가깝고, "정확히 오전 9시에 브리핑을 보낸다"는 Cron의 일입니다.³

이 구분만 이해해도 OpenClaw 운영 난이도가 한 단계 내려갑니다.

추천하는 첫 운영 패턴

초보자에게 가장 안정적인 구조는 Heartbeat와 Cron을 분업시키는 것입니다. 실무 글들에서도 같은 패턴을 추천합니다. Heartbeat는 준비와 점검, Cron은 정시 실행을 맡는 방식입니다.³

예를 들어 이렇게 나눌 수 있습니다.

• Heartbeat: 새 메일 변화, 오늘 일정 충돌, 미해결 이슈 존재 여부 점검

• Cron: 오전 9시 데일리 브리핑 발송

• Heartbeat: 브리핑 이후 새로 생긴 급한 일만 추가 보고

이 구조의 장점은 명확합니다. 먼저, 역할이 분리되어 디버깅이 쉽습니다. 둘째, 중복 발송 사고가 줄어듭니다. 셋째, Heartbeat는 가볍고 똑똑하게 남고, Cron은 정확하고 예측 가능하게 남습니다.

반대로 같은 일을 두 곳에 다 넣으면 거의 반드시 중복이 발생합니다. 9시에 Cron이 브리핑을 보내고, 9시 무렵 Heartbeat도 "아, 브리핑 시간이네" 하고 한 번 더 보내는 식입니다. 사람보다 AI가 더 성실할 때 벌어지는 참사입니다.⁵

비용을 아끼는 HEARTBEAT.md 작성법

Heartbeat는 자주 돌기 때문에, 조금만 비대해져도 비용이 누적됩니다. 그래서 좋은 Heartbeat는 똑똑할 뿐 아니라 다이어트도 잘해야 합니다.

가장 먼저 줄여야 하는 것은 중복입니다. 이미 Cron이 처리하는 정시 보고를 Heartbeat가 다시 확인할 필요는 없습니다.⁴ 다음으로 줄여야 하는 것은 과한 설명입니다. Heartbeat가 매번 읽어야 하는 문서는 소설이 아니라 체크리스트입니다. 길고 아름다운 문장보다 짧고 명확한 규칙이 낫습니다.

다음 세 가지 습관이 특히 효과적입니다.

• 확인 항목을 3~5개 수준으로 유지하기

• "언제 알릴지"보다 "언제 알리지 않을지"를 분명히 쓰기

• 최근에 본 항목은 state 파일이나 메모리 기준으로 건너뛰게 만들기

커뮤니티 가이드에서는 memory/heartbeat-state.json 같은 상태 파일을 두고 마지막 확인 시각, 마지막 알림 시각을 기록해 중복 호출을 줄이는 방식을 소개합니다.⁷ 꼭 JSON 파일을 직접 다루지 않더라도, HEARTBEAT.md에 "같은 항목은 6시간 이내 재알림 금지" 같은 규칙을 써두면 실전 품질이 확 올라갑니다.

한국 사용자에게 특히 중요한 시간대와 메시지 톤

Heartbeat는 기술 설정이지만, 체감은 결국 생활 리듬에서 옵니다. 한국 사용자는 메신저 알림 민감도가 꽤 높습니다. 특히 텔레그램이나 카카오 계열 메신저를 개인 생활과 함께 쓰는 경우, 야간 알림 한 번이면 바로 꺼버립니다.

그래서 한국어 에이전트의 HEARTBEAT.md에는 단순한 작업 규칙뿐 아니라 말투 규칙도 넣어두는 편이 좋습니다. 예를 들어 "중요하지 않으면 밤에는 보내지 않는다", "긴급이 아니면 다음 활동 시간 첫 하트비트로 미룬다", "메시지는 두세 문장 안에 요약한다" 같은 규칙입니다. 능동적이라는 말은 말을 많이 한다는 뜻이 아니라, 적절한 순간에 적절한 압축률로 말한다는 뜻입니다.

특히 아침 브리핑이나 일정 알림은 한국 표준시를 명시하는 습관이 좋습니다. 서버가 해외 VPS에 올라가 있거나 WSL 환경의 시간대가 어긋나 있으면, 사용자는 틀린 알림을 받았다고 느끼고 에이전트 전체를 불신하게 됩니다. Heartbeat 품질의 절반은 시간대에서 시작합니다.¹

실전용 HEARTBEAT.md 템플릿

이 장을 읽고 바로 쓸 수 있도록, 지나치게 크지 않으면서도 실전에 바로 투입 가능한 템플릿을 하나 남겨두겠습니다.

# HEARTBEAT.md

에이전트는 매 하트비트마다 아래 항목을 순서대로 확인한다.
모든 항목에서 실행 조건이 충족되지 않으면 HEARTBEAT_OK를 응답하고 종료한다.
불필요한 메시지, 반복 메시지, 야간 잡담은 금지한다.

## 1. 긴급 신호 확인
- 새로 들어온 읽지 않은 메시지, 메일, 알림 중 긴급도가 높은 항목이 있는지 확인한다.
- 긴급 기준: VIP 발신자, 마감 임박, 장애/결제 실패/캘린더 충돌.
- 있으면 요약 3줄 이내로 보고한다.
- 이미 보고한 동일 항목은 재전송하지 않는다.

## 2. 일정/마감 점검
- 앞으로 24시간 안의 일정과 마감 중 충돌, 준비 부족, 이동 시간 부족이 있는지 본다.
- 있으면 원인과 추천 대응 1개를 함께 보낸다.
- 같은 사안은 6시간 이내 반복 보고하지 않는다.

## 3. 작업 정체 감지
- 진행 중인 중요 작업 중 다음 행동이 비어 있거나, 사람의 결정 대기 상태가 오래 지속된 항목이 있는지 확인한다.
- 있으면 지금 필요한 결정 사항만 짧게 묻는다.
- 변화가 없으면 침묵한다.

## 4. 인간 체크인
- Asia/Seoul 기준 10:00~18:00 사이에만 실행한다.
- 최근 4시간 동안 대화가 없고, 중요한 알림도 없고, 도와줄 만한 다음 행동이 있을 때만 한 번 묻는다.
- 같은 날 1회 이상 보내지 않는다.

## 5. 침묵 규칙
- 변화 없음
- 중복 정보
- 애매한 신호
- 아직 행동 제안이 준비되지 않음

위 경우에는 HEARTBEAT_OK를 응답하고 종료한다.

이 템플릿의 핵심은 화려함이 아니라 억제력입니다. 무엇을 할지보다, 무엇을 하지 않을지를 많이 적어둔 점이 중요합니다.

디버깅할 때 꼭 봐야 할 체크포인트

Heartbeat가 기대처럼 안 움직일 때는 대개 세 부류로 나뉩니다. 너무 자주 말하거나, 전혀 말하지 않거나, 엉뚱한 시간에 말하는 경우입니다.

너무 자주 말한다면 먼저 HEARTBEAT.md가 과하게 넓은지 보세요. "중요한 것 있으면 알려줘" 같은 문장은 거의 모든 것을 중요하게 만들 수 있습니다. 알림 기준, 중복 방지, 최대 빈도를 좁혀야 합니다.

전혀 말하지 않는다면 target이 none인지, activeHours가 현재 시간대를 막고 있는지, 그리고 에이전트가 매번 HEARTBEAT_OK만 내놓는 구조인지 점검해야 합니다. 공식 문서상 기본 target은 none이므로, 내부 실행만 되고 외부로는 아무것도 안 올 수 있습니다.¹

엉뚱한 시간에 말한다면 거의 항상 시간대 문제입니다. Asia/Seoul을 명시했는지, 서버 로컬 시간과 사용자 시간대가 섞이지 않았는지 확인하세요. 그리고 시작/종료 시간을 같은 값으로 넣는 실수도 의외로 흔합니다.¹

이 장의 결론: 능동성은 빈도가 아니라 설계다

HEARTBEAT.md는 OpenClaw를 살아 있는 에이전트처럼 보이게 만드는 작은 문서입니다. 하지만 진짜 힘은 "자주 깨운다"가 아니라 "무엇을, 언제, 얼마나 조용하게 하게 만들 것인가"에 있습니다.

잘 만든 Heartbeat는 다음을 해냅니다.

• 중요한 변화만 먼저 알려준다.

• 사용자의 수면과 집중을 방해하지 않는다.

• 최근 맥락을 이용해 지금 필요한 행동을 제안한다.

• 할 일이 없을 때는 깨끗하게 침묵한다.

이 네 가지가 갖춰지는 순간, OpenClaw는 더 이상 메신저 속 챗봇이 아닙니다. 당신의 워크플로를 주기적으로 순찰하는 작은 운영체제가 됩니다. 그리고 그 시작점이 거대한 코드가 아니라 HEARTBEAT.md 한 장이라는 사실이 꽤 매력적입니다.

다음 부에서는 이 능동성을 더 밀어붙입니다. 이제 에이전트가 먼저 살펴보는 수준을 넘어, 스킬을 통해 아예 새로운 능력을 붙이게 됩니다. 심장이 뛰기 시작했다면, 이제 손발을 달 차례입니다.

참고

¹Heartbeat - OpenClaw

²The OpenClaw Heartbeat: Your AI That Acts Without Being Asked

³3. OpenClaw 실전편 - Heartbeat + Cron으로 아침 자동화 루틴 만들기

⁴OpenClaw Heartbeat Optimization: How I Cut Costs 50% by Rethinking the Default Interval

⁵openclaw-playbook/manual/ch05-heartbeat-cron.md at main · aisyncclub/openclaw-playbook · GitHub

⁶openclaw-workspace/skills/self-improving-proactive-agent/heartbeat-rules.md at master · xionghouyuan/openclaw-workspace · GitHub

⁷OpenClaw Heartbeats — CopyPasteLearn