대부분의 OpenClaw 설정은 이런 식으로 테스트됩니다: 시작하고, 메시지를 몇 개 보내고, 괜찮다고 판단하는 것이죠. 처음 5분 동안 응답이 온다면, 프로덕션(production) 준비가 된 것입니다.

저도 그렇게 했습니다. 그러고 나서 주말 동안 자리를 비웠습니다.

돌아왔을 때, 저는 세 가지의 조용한 실패(silent failures), 움찔하게 만드는 토큰 비용 청구서, 그리고 당신이 지켜보고 있지 않을 때 무엇이 고장 나는지에 대한 건강한 경외심을 갖게 되었습니다.

OpenClaw 에이전트를 48시간 동안 연속으로 실행하며 배운 점, 그리고 문서에서 경고하지 않는 방식으로 실패한 세 가지 요소에 대해 말씀드리겠습니다.

설정 (The Setup)

저는 15분마다 실행되는 cron job, 모델 체인 (MiniMax M3 → OpenRouter fallback), 그리고 브라우저 도구(browser tool)가 활성화된 새로운 OpenClaw 인스턴스를 구동했습니다. 또한 모든 실행 내용을 로컬 파일에 기록하는 간단한 상태 확인(health-check) 스크립트도 연결했습니다.

# 상태 확인 — 15분마다 cron으로 실행
curl -s http://localhost:18789/status | \
  jq -r '.sessionActive or .gatewayOk' > /tmp/oc-health.log
...

특별한 것은 없습니다. 이는 24/7로 실행하는 사람을 위한 꽤 표준적인 OpenClaw 설정입니다.

실패 #1: 컨텍스트 윈도우(Context Window)의 느린 누수

저는 모델이 결국 컨텍스트(context)를 다 써버릴 것이라고 예상했습니다. 제가 예상하지 못한 것은 그것이 얼마나 느리게, 그리고 얼마나 조용하게 일어나는가였습니다.

약 18시간이 지난 후, 응답이... 빈약하다는 느낌을 받기 시작했습니다. 더 짧아졌고, 덜 상세해졌습니다. 모델은 에러를 내지도 않았고, 거부하지도 않았습니다. 그저 줄어든 컨텍스트 공간에 조용히 적응하고 있었을 뿐입니다.

로그를 확인했습니다. cron은 잘 작동하고 있었습니다. 모델도 응답하고 있었습니다. 하지만 명시적인 세션 삭제 정책(session-purge policy)을 설정하지 않았기 때문에 세션 히스토리(session history)가 계속 쌓이고 있었습니다. 모델은 실패하는 것이 아니라, 남은 컨텍스트에 맞춰 응답을 경제적으로 조절하며 적응하고 있었던 것입니다.

해결책:

{
  "session": {
    "maxHistoryMessages": 50,
...

maxHistoryMessages를 50으로, maxAgeHours를 12로 설정하면 문제가 되기 전에 세션이 스스로 초기화됩니다. 모델은 여전히 유용할 만큼 충분한 컨텍스트를 유지하면서도, 긴 주말 동안 스스로를 서서히 질식시키지 않게 됩니다.

실패 사례 #2: 크론(Cron)이 에이전트가 작업 중임을 인지하지 못함

저의 15분 주기 크론(cron)은 이전 에이전트 실행이 여전히 활성 상태일 때도 계속 실행되었습니다. 저는 데이터 수집, 요약, 저장을 수행하는 연구 작업을 실행하는 표준 크론(cron)으로 이를 설정해 두었습니다.

하지만 이전 실행이 15분 이상 걸릴 경우(가끔 느린 외부 API를 호출할 때가 있었습니다), 마지막 실행이 끝나기 전에 다음 실행이 시작되었습니다. OpenClaw는 이를 우아하게 처리하여 작업을 큐(queue)에 쌓아두었지만, 큐가 예상보다 빠르게 늘어났습니다.

24시간이 지난 후, 6개의 작업이 큐에 쌓여 있었고 40분의 백로그(backlog)가 발생했습니다.

문서만 봐서는 해결책이 명확하지 않았습니다. 저는 뮤텍스 가드(mutex guard)를 추가해야 했습니다:

# 래퍼 스크립트(Wrapper script) — 크론(cron)의 동시 실행 방지
LOCKFILE="/tmp/openclaw-cron.lock"

...

15분이 임계값입니다. 만약 잠금 파일(lock file)이 생성된 지 900초(15분) 미만이라면, 이번 실행을 건너뜁니다. 만약 그보다 오래되었다면, 이전 실행이 충돌(crash)했다고 가정하고 작업을 진행합니다.

이런 문제는 모든 응답이 3초 안에 이루어지는 테스트 환경에서는 괜찮아 보입니다. 하지만 실제 API와 실제 지연 시간(latency)이 존재하는 운영(production) 환경에서는 매우 중요합니다.

실패 사례 #3: 모델 폴백(Fallback)이 성공처럼 보임

31시간째에 MiniMax M3가 속도 제한(rate limit)에 걸렸을 때, OpenClaw는 OpenRouter로 폴백(fallback)했습니다. 폴백은 작동했습니다. 작업도 완료되었습니다.

문제는 토큰당 비용이 4배 더 들고, 시간은 3배 더 걸렸다는 점입니다.

로그에는 "OK"라고 찍혔습니다. 크론(cron)도 "OK"라고 했습니다. 작업도 완료되었습니다. 하지만 폴백(fallback)이 기본 로그에서는 보이지 않았기 때문에, 저는 비싼 토큰을 사용하며 예산을 낭비하고 있었습니다.

저는 명시적인 비용 추적(cost tracking) 기능을 추가해야 했습니다:

# 각 실행 후 토큰 사용량 로그 기록
curl -s http://localhost:18789/status | \
  jq '.model, .lastRunTokens, .lastRunCost' >> /tmp/oc-cost.log

그 다음 빠른 주간 검토를 수행했습니다:

# 모델별 비용 요약
cat /tmp/oc-cost.log | \
  awk -F'"' '{print $2}' | \
...

이 시스템을 처음 실행한 첫 주에, OpenRouter 사용으로 인해 14.23달러의 토큰 비용이 발생했습니다. 저는 이를 계획에 넣지 않았었습니다.

배운 점

48시간이 지난 후, 실패 사례들은 극적이지 않았습니다. 에이전트 (Agent)가 폭주하거나 데이터를 손상시키지는 않았습니다. 그저... 제 돈과 시간을 낭비하는 방식으로 조용히 잘못된 일을 수행했을 뿐입니다.

진정한 교훈은 이것입니다: OpenClaw는 신뢰할 수 있지만, 신뢰할 수 없는 순간이 오며, 그 "순간"은 보통 업무 시간 외에 발생한다는 것입니다.

제가 적용한 세 가지 수정 사항 — 세션 재설정 정책 (session reset policy), cron 뮤텍스 가드 (cron mutex guard), 비용 추적 (cost tracking) — 을 구현하는 데는 약 2시간이 걸렸습니다. 48시간 동안의 테스트 비용은 API 토큰 약 20달러와 약간 스트레스가 쌓였던 일요일 오전 한 번이었습니다.

이는 괜찮은 거래입니다. 이제 저는 제 주의를 기울이지 않아도 며칠 동안 실행되는 설정을 갖게 되었습니다. 세션은 신선하게 유지됩니다. cron은 쌓이지 않습니다. 그리고 저는 제가 실제로 무엇에 대해 비용을 지불하고 있는지 알고 있습니다.

만약 여러분이 OpenClaw를 프로덕션 (production) 환경에서 운영하면서 최소 하루 이상 스트레스 테스트를 하지 않고 있다면, 여러분은 주말을 한 번도 겪어보지 못한 설정을 배포하고 있는 것입니다.