OpenClaw가 일일 저널(daily journals)을 계속 놓치는 이유를 드디어 이해했습니다

r/openclaw의 일일 저널링(daily journaling)에 관한 스레드가 제목에서 암시하는 것보다 훨씬 더 흥미로워졌습니다.

설정은 매우 현실적이었습니다:

OpenClaw 2026.6.8
Linux 미니 PC
Telegram 프론트엔드 (front end)
단일 에이전트 (single agent)
OpenRouter를 통한 DeepSeek
daily-notes/YYYY/MM/YYYY-MM-DD.md 경로의 Obsidian 일일 노트 (daily notes)

목표는 "귀여운 일기를 써줘"가 아니었습니다.

그것은 에이전트가 압축(compaction), 리셋(resets), 그리고 일반적인 세션의 이상 현상(session weirdness) 속에서도 살아남을 수 있도록, 하루 종일 지속 가능하고 타임스탬프가 찍힌 복구 로그(recovery log)를 유지하는 것이었습니다.

그것은 문제를 완전히 바꿉니다.

이것은 프롬프트(prompt) 문제가 아닙니다.
신뢰성(reliability) 문제입니다.

실수: 하트비트(heartbeat)를 저널링 데몬(journaling daemon)처럼 취급하는 것

많은 사람들이 OpenClaw의 하트비트(heartbeat)를 사용하면서 그것이 일일 저널링을 처리해야 한다고 가정합니다.

하트비트가 실제로 무엇인지 확인하기 전까지는 그렇게 들릴 수 있습니다.

OpenClaw의 문서에서는 하트비트를 메인 세션(main session) 내의 예정된 턴(scheduled turn)으로 설명합니다. 이는 그것이 컨텍스트(context)를 인식할 수 있음을 의미합니다. 하지만 그것은 지속 가능한 백그라운드 작업 시스템(background task system)이 아니며, 확실히 보장된 파일 추가(append-to-file) 서비스도 아닙니다.

기본 설정(default config)이 이 상황을 꽤 명확하게 보여줍니다:

{
  "agents": {
    "defaults": {
...

신뢰할 수 있는 저널링이 목표라면, 이러한 기본 설정 중 몇 가지는 가혹합니다:

every: "30m"은 주기적(periodic)인 것이지, 정확한(exact) 것이 아닙니다.
isolatedSession: true는 각 실행이 새로 시작될 수 있음을 의미합니다.
lightContext: true는 제한된 컨텍스트(limited context)를 의미합니다.
skipWhenBusy: true는 아예 실행되지 않을 수도 있음을 의미합니다.

이것은 가벼운 체크인(check-ins)을 위한 괜찮은 설계입니다.

하지만 "매번 신뢰할 수 있는 로그 항목을 추가한다"는 목적에는 나쁜 설계입니다.

진짜 트레이드오프(tradeoff): 연속성 vs 신뢰성

이 부분이 사람들이 계속해서 맞닥뜨리는 지점입니다.

만약 하트비트가 메인 세션에서 실행된다면, OpenClaw는 연속성(continuity)을 갖습니다. 그것은 종종 방금 무슨 일이 일어났는지 알고 있으며 더 나은 저널 항목을 작성할 수 있습니다.

만약 하트비트가 격리된 세션(isolated session)에서 실행된다면, 자동화(automation)는 더 깔끔해지지만 컨텍스트(context)는 나빠집니다.

그 트레이드오프(tradeoff)는 우연이 아닙니다. 그것은 아키텍처(architecture)입니다.

따라서 만약 당신의 저널(journal)이 복구(recovery)에 중요하다면, 연속성(continuity)만으로는 충분하지 않습니다.
당신에게는 결정론적 실행(deterministic execution) 또한 필요합니다.

그것은 신뢰성(reliability)을 모델 외부로 옮겨야 함을 의미합니다.

스레드에서 나온 최고의 답변: 하드 트리거(hard triggers) + 아티팩트 게이트(artifact gates)

해당 Reddit 스레드에서 가장 유용한 댓글은 기본적으로 다음과 같이 말했습니다:

모델에게 스케줄러(scheduler) 역할을 맡기지 마세요

그것이 정답입니다.

저널링(journaling)이 반드시 안정적으로 수행되어야 한다면, 제어 평면(control plane)은 지루해야 합니다:

cron
systemd timers
셸 스크립트(shell script)
Python 워커(worker)
당신의 스택이 n8n, Make, 또는 Zapier라면 그것을 사용하세요

OpenClaw가 콘텐츠를 생성하게 하세요.
OpenClaw가 보장(guarantee)을 책임지게 두지는 마세요.

그렇게 프레임을 짜고 나면, 설계는 훨씬 단순해집니다.

신뢰할 수 있는 저널링 파이프라인(journaling pipeline)이 해야 할 일

만약 제가 Obsidian을 위해 이것을 구축한다면, 다섯 가지를 원할 것입니다:

결정론적 트리거(deterministic trigger)
오늘의 노트가 존재하는지 확인하는 체크(check)
추가 전용 쓰기(Append-only writes)
동일한 이벤트가 두 번 기록되지 않도록 하는 멱등성(idempotency)
컨텍스트(context)가 부족할 때를 대비한 폴백(fallback)

이것이 엔지니어링(engineering)입니다.
프롬프팅(prompting)이 아닙니다.

실제로 작동하는 실용적인 패턴

제가 사용할 아키텍처(architecture)는 다음과 같습니다.

구성 요소 (Component)	역할 (Job)
`cron` 또는 `systemd`	저널링 실행 시점을 결정
...

예시: 파일 레이아웃(file layout)

vault/
  daily-notes/
    2026/
...

예시: 노트가 없는 경우 오늘의 노트 생성

#!/usr/bin/env bash
set -euo pipefail

...

이것은 지루합니다.
그렇기 때문에 좋은 것입니다.

예시: 마커(marker)를 사용한 추가 전용 쓰기(append-only write)

트리거가 재시도될 때 중복 항목이 생기는 것을 원치 않을 것입니다.

간단한 접근 방식은 이벤트 ID(event ID)를 생성하고 이를 저장하는 것입니다.

EVENT_ID=$(date +%Y%m%dT%H%M)
STATE_DIR="$HOME/journal-state"
MARKER="$STATE_DIR/$EVENT_ID.done"
...

이 마커 파일 하나가 "내 에이전트(agent)가 일관적이지 않다"는 수많은 불만 사항을 해결해 줍니다.

그러한 불만 사항의 상당수는 사실 멱등성(idempotency) 버그입니다.

예시: OpenClaw가 텍스트는 생성하되, 일정은 관리하지 않게 하기

스크립트는 작은 컨텍스트 번들(context bundle)을 수집하여 OpenClaw에게 하나의 마크다운(markdown) 블록을 요청할 수 있습니다.

예를 들어:

PROMPT=$(cat <<EOF
Obsidian 데일리 노트(daily note)를 위한 짧은 추가 전용(append-only) 저널 항목을 작성하세요.

...

만약 OpenAI 호환 엔드포인트(endpoint)를 사용 중이라면, 이 패턴은 이미 연결되어 있는 어떤 백엔드(backend)와도 작동합니다.

이 점이 중요한 이유는, 저널링(journaling) 작업은 여러 에이전트(agent)를 통해 매일 하루 종일 실행될 경우 비용이 조용히 누적될 수 있는 바로 그런 종류의 작업이기 때문입니다.

이러한 자동화(automation)를 지속적으로 실행하고 있다면, 토큰(token) 소비를 일일이 감시하는 것보다 예측 가능한 정액제 API 사용이 훨씬 더 낫습니다.

이것이 바로 여기서 Standard Compute가 흥미로운 이유 중 하나입니다. 이는 월간 정액제로 무제한 컴퓨팅(compute)을 제공하며 OpenAI API를 즉시 대체할 수 있는 솔루션입니다. 이는 예약된 작업, 재시도(retries), 요약(summaries), 그리고 하루 종일 실행되는 백그라운드 자동화(background automations)가 있는 에이전트 중심의 워크플로(workflow)에 토큰당 과금 방식보다 훨씬 더 잘 맞습니다.

예시: 더 나은 제어 기능을 갖춘 Python 버전

셸(shell) 스크립트가 복잡해지기 시작한다면, Python이 더 깔끔합니다.

from pathlib import Path
from datetime import datetime

...

이 단계에서 다음과 같은 기능들을 추가할 수 있습니다:

해시 기반 중복 제거 (hash-based dedupe)
JSON 상태 추적 (JSON state tracking)
지수 백오프를 포함한 재시도 (retries with backoff)
마크다운(markdown) 형식 검증 (validation of markdown format)
Telegram, OpenClaw 세션 파일 또는 작업 로그로부터의 아티팩트(artifact) 수집

Heartbeat는 여전히 유용하지만, 핵심 보증을 위한 것은 아닙니다

여기서 Heartbeat가 쓸모없다고 생각하지는 않습니다.

사람들이 Heartbeat에 잘못된 역할을 부여하고 있다고 생각합니다.

Heartbeat는 다음과 같은 용도로 좋습니다:

"저널링할 내용이 있는지 확인"
"컨텍스트(context)가 신선할 때 빠르게 상태 캡처"
"압축(compaction) 전 에이전트에게 요약을 유도"

Heartbeat는 다음과 같은 용도로는 좋지 않습니다:

정확한 시간 실행 (exact-time execution)
보장된 쓰기 (guaranteed writes)
내구성이 있는 추가 전용 로깅 (durable append-only logging)
유일한 진실의 원천 (source of truth) 역할

이것은 중요한 차이점입니다.

각 사례별 권장 사용법

옵션	최적의 용도
Heartbeat	컨텍스트 인지형 주기적 체크인
...

제 의견은 이렇습니다: 압축(compaction), 리셋(resets) 또는 모델 교체(model swaps) 이후에도 신뢰할 수 있는 저널을 원한다면, Heartbeat를 주요 메커니즘으로 사용해서는 안 됩니다.

보조 도구로 사용하세요.
기반(foundation)으로 사용하지 마십시오.

사람들을 방해하는 교묘한 기본값들

몇 가지 기본값(defaults)이 상황을 처음 보이는 것보다 더 악화시킵니다:

하트비트(heartbeat) 주기는 정확한 타이밍이 아니라 종종 30분 단위입니다
일부 인증(auth) 설정이 실제 기본 동작을 변경할 수 있습니다
타임아웃(timeouts)이 하트비트 주기로 대체될 수 있습니다
활성 시간(active hours)이 실행을 억제할 수 있습니다
target: "last"가 라우팅(routing) 동작을 변경할 수 있습니다
lightContext는 에이전트가 보는 정보량을 줄입니다
skipWhenBusy는 놓친 시간대(windows)가 발생할 것을 전제로 합니다

이러한 설정들을 그대로 둔 채 내구성이 있는 저널(durable journal)을 기대한다면, 당신은 기본적으로 모래 위에 집을 짓고 있는 것과 같습니다.

그러고 나서 사람들은 DeepSeek, OpenRouter, 또는 프롬프트(prompt)를 탓합니다.

대개 그것은 잘못된 범인입니다.

에이전트 자동화를 위한 더 나은 멘탈 모델 (Mental Model)

이 모든 문제는 더 넓은 규칙의 좋은 예시입니다:

결정론적 인프라(deterministic infrastructure)와 확률론적 추론(probabilistic reasoning)을 분리하십시오.

다음과 같은 작업에는 지루한 시스템(boring systems)을 사용하세요:

스케줄링 (scheduling)
파일 생성 (file creation)
추가 전용 쓰기 (append-only writes)
재시도 (retries)
상태 추적 (state tracking)
중복 제거 (dedupe)

모델은 다음과 같은 작업에 사용하세요:

요약 (summarization)
압축 (compression)
해석 (interpretation)
최근 컨텍스트(context)에서 무엇이 중요한지 결정하기

이러한 분업은 하나의 에이전트에게 이 모든 것을 요구하는 것보다 훨씬 더 잘 작동합니다.

제가 실제로 출시할 만한 최소한의 워크플로우 (Workflow)

만약 제가 이것을 빠르게 신뢰할 수 있게 만들어야 한다면, 다음과 같이 하겠습니다:

cron을 사용하여 15분 또는 30분마다 트리거합니다
Telegram, 세션 로그, 그리고 현재 작업 파일에서 새로운 아티팩트(artifacts)를 가져옵니다
OpenClaw 또는 다른 모델을 사용하여 하나의 작은 마크다운(markdown) 블록을 생성합니다
출력 형식을 검증(validate)합니다
오늘의 Obsidian 파일에 추가(append)합니다
성공 마커(success marker)를 작성합니다
추가 작업이 두 번 실패하면 알림을 보냅니다

이 방식은 테스트 가능합니다.
이 방식은 디버깅(debuggable)이 가능합니다.
이 방식은 모델의 기이한 동작(model weirdness)으로부터 훨씬 더 잘 살아남습니다.

최종 결론

Reddit의 작성자(OP)는 그 고통에 대해 옳았습니다.

하지만 해결책은 "완벽한 하트비트 프롬프트를 찾는 것"이 아닙니다.
해결책은 신뢰성(reliability)을 모델 외부로 옮기는 것입니다.

저널이 중요하다면, cron, bash, Python, systemd, n8n, 또는 당신이 이미 신뢰하고 있는 어떤 결정론적 계층(deterministic layer)을 사용하여 쓰기 경로(write path)를 직접 제어하십시오.

그다음 OpenClaw가 실제로 잘하는 부분, 즉 지저분한 최근 컨텍스트(recent context)를 유용한 노트로 변환하는 작업을 수행하게 하십시오.

그것은 덜 마법적입니다.

또한 그것은 오후 2시 30분을 놓치지 않을 것이라고 제가 신뢰할 수 있는 첫 번째 접근 방식입니다.