OpenClaw 텔레그램 봇이 응답 없을 때 — 진단과 복구 완전 가이드 | AI SSAPABLE

텔레그램 봇이 답을 안 한다
5분 안에 살리는 법

OPENCLAW TROUBLESHOOTING 2026-05-27 예상 소요 15분

TL;DR

OpenClaw 텔레그램 봇이 답이 없는 이유는 거의 3가지 중 하나다.

먼저 openclaw status로 세션 토큰 %를 확인하라. 70%에 가까우면 컨텍스트 누적 문제, Gateway가 unreachable이면 event loop가 막힌 상태, state=processing이 5분 이상 유지되면 Stalled session이다.

CAUSE 01

세션 컨텍스트 70%+ 누적 → Codex compaction hang

CAUSE 02

IPv6 라우팅 실패 → Node.js event loop starvation

CAUSE 03

Stalled session이 heartbeat보다 짧게 방치

목차 / TABLE OF CONTENTS

01증상과 케이스 스터디
023가지 근본 원인
03진단 절차 (5분)
04복구 절차 (10분)
05재발 방지 설정
06FAQ

01 — CASE STUDY

실제 사례: 작업 중 답이 끊긴 순간

OpenClaw 텔레그램 봇을 사용해 작업하던 중, 봇이 갑자기 응답을 멈췄다. 로그를 끝부분부터 거꾸로 읽으며 원인을 추적한 과정이다.

증상 — 로그가 말해준 것

먼저 로그 끝부분을 보면 3가지 다른 종류의 에러가 시간순으로 쌓여 있었다.

17:40:43

fetch timeout after 10000ms (elapsed 24952ms)
timer delayed 14952ms, likely event-loop starvation
→ Node.js의 타이머가 약 15초 지연됐다. 이벤트 루프가 막힌 상태.

17:42:41

[agent/embedded] started codex app-server compaction
→ 컨텍스트 압축 작업이 시작됨. 이게 어디서도 끝나지 않는다.

17:44:01 ~ 17:48:04

stalled session 반복 감지 (age 128s → 371s)
state=processing reason=active_work_without_progress
→ 6분 11초 동안 진행이 없다가 결국 action=abort_embedded_run로 강제 중단.

17:48:04

codex app-server compaction could not use thread binding
thread not found: 019e683b-f796-7e61-be79-1a07df620cc0
→ 강제 abort 결과 스레드 바인딩 손실. 사용자는 답변을 받지 못했다.

최초 진단 — 무엇이 보였나

openclaw status를 실행하자 핵심 단서가 한눈에 보였다.

Gateway : unreachable (timeout) Heartbeat : 30m (main) Sessions : agent:main:telegram:direct:<USER_ID> 190k / 272k (70%) · 100% cached

텔레그램 세션이 컨텍스트 윈도우의 70%를 점유하고 있었다. Heartbeat는 30분 주기 — Stalled session이 발생해도 다음 점검까지 한참 걸리는 구조. Gateway는 도달 불가 상태.

이후 openclaw channels status를 추가로 확인하니 결정적인 한 줄이 나왔다.

Gateway event loop degraded: reasons=event_loop_utilization,cpu eventLoopDelayMaxMs=753 eventLoopUtilization=1 cpuCoreRatio=0.984

이벤트 루프 활용도 100%, CPU 코어 점유 98.4%. Node.js 프로세스 자체가 작업 처리를 못 하고 있는 상태였다.

02 — ROOT CAUSES

3가지 원인은 서로 엮여 있다

증상은 "봇이 답을 안 함" 하나지만, 원인은 셋이 동시에 작용했다.

원인	관찰된 증상	메커니즘
① 컨텍스트 70% 누적	190k / 272k 토큰	임계점 도달 시 Codex가 compaction 시도. 압축할 토큰이 많을수록 시간이 길어지고 hang 위험.
② IPv6 라우팅 실패	fetch timeout, DNS-resolved IP unreachable	Node.js가 RFC 6724에 따라 IPv6 주소를 먼저 시도. IPv6 라우팅이 죽어있으면 OS 타임아웃까지 수십 초 동기 대기. 그 동안 event loop가 막힘.
③ Stalled 방치	Heartbeat 30분	봇 자체의 자기 점검이 30분 간격. 외부 watchdog 없음. 사용자가 자거나 부재 시 stalled가 길게 방치됨.

왜 셋이 동시에 작용했나

장시간 사용으로 컨텍스트가 70%까지 차오름 — 평소 워크스페이스 파일로 외부화하지 않았다면 누구나 도달 가능.
새 메시지 도착 → Codex가 compaction 시작 — 자동 트리거 메커니즘.
compaction이 외부 API(Telegram, 모델 제공자) 호출 필요 — IPv6 라우팅이 막혀 있어 fetch가 수십 초 hang.
event loop가 막힘 → compaction 진행 불가 — 모든 비동기 작업이 정지.
Stalled session 감지가 6분 후 발생 — 30분 heartbeat로는 빠른 복구 불가.

즉, 하나만 해결해도 부분적 개선이고, 셋을 모두 손봐야 근본 해결이 된다.

03 — DIAGNOSIS

진단 절차 — 5분 안에 원인 좁히기

봇이 응답하지 않을 때 가장 먼저 실행할 명령어 순서다. 위에서부터 차례로 실행하면 어느 원인인지 빠르게 좁혀진다.

▸ 이 가이드에서 사용하는 변수

<USER_HOME>: 홈 디렉토리 경로 (Windows: C:\Users\<USERNAME>, macOS/Linux: ~)
<AGENT>: 에이전트 이름 (기본값: main)
<CHANNEL>: 채널 이름 (예: telegram, slack, whatsapp)
<USER_ID>: 채널 사용자 ID (텔레그램 숫자 ID 등)
<SESSION_KEY>: 세션 키 (예: agent:<AGENT>:<CHANNEL>:direct:<USER_ID>)
<SESSION_ID>: 세션 UUID (sessions list 출력의 id: 값)

D1. 전체 상태 한눈에

openclaw status

출력에서 다음을 본다.

항목	이상 신호	의심 원인
Gateway	`unreachable (timeout)`	CAUSE 02 event loop 막힘
Sessions Tokens	60% 이상	CAUSE 01 컨텍스트 누적
Channel State	`disconnected`	하위 문제 채널 폴링 끊김

D2. Gateway 이벤트 루프 상태

openclaw channels status

정상이면 단순한 채널 목록만 나온다. 비정상이면 Gateway event loop degraded 줄과 함께 다음 값이 표시된다.

지표	정상	위험
`eventLoopDelayMaxMs`	< 100	500 이상
`eventLoopUtilization`	< 0.7	0.9 이상
`cpuCoreRatio`	< 0.5	0.85 이상

D3. Stalled session 여부

openclaw logs --follow

로그에 다음 패턴이 반복되면 Stalled.

# Stalled session 시그니처 [diagnostic] stalled session: sessionId=<SESSION_ID> state=processing age=<N>s reason=active_work_without_progress classification=stalled_agent_run

age 값이 30초 간격으로 계속 증가하면 멈춘 상태가 확실하다. 360초(6분)를 넘으면 시스템이 자동 abort를 시도한다.

D4. 네트워크 단 IPv6 확인

로그에 fetch fallback: DNS-resolved IP unreachable이 보이면 IPv6 의심.

Windows PowerShell:

Test-NetConnection api.telegram.org -Port 443 Resolve-DnsName api.telegram.org

macOS/Linux:

curl -v -4 https://api.telegram.org/ curl -v -6 https://api.telegram.org/

IPv4 연결은 성공하는데 IPv6 연결만 실패한다면 CAUSE 02 확정.

▸ NOTE DNS 응답에 AAAA 레코드(IPv6)와 A 레코드(IPv4)가 모두 나오는 게 정상이다. 문제는 Node.js가 AAAA를 먼저 시도한다는 점이다. IPv6 자체를 끄는 게 아니라 우선순위만 바꾸면 된다.

04 — RECOVERY

복구 절차 — 10분 안에 정상화

진단에서 원인이 확인됐으면 다음 7단계를 차례로 실행한다. 데이터 손실을 막기 위해 백업 단계가 포함되어 있다.

STATUS / 진단 확정

현재 상태 확인

복구 시작 전 마지막으로 상태를 본다. 이미 정상화됐을 수도 있다.

openclaw status openclaw channels status

STOP / Gateway 안전 중지

세션 파일 편집 전 Gateway 정지

Gateway가 실행 중이면 세션 파일을 점유하고 있어 충돌이 난다. 반드시 먼저 멈춘다.

openclaw gateway stop

Stopped Scheduled Task 메시지가 나오면 OK.

BACKUP / 안전망 구축

문제 세션 파일 백업

편집 실패 시 원복할 수 있도록 별도 폴더에 복사한다. 백업 폴더 이름에 타임스탬프를 포함해 추적 가능하게 만든다.

# Windows PowerShell $ts = Get-Date -Format "yyyyMMdd-HHmmss" $src = "<USER_HOME>\.openclaw\agents\<AGENT>\sessions" $dst = "$src\backup-$ts" New-Item -ItemType Directory -Path $dst -Force | Out-Null Copy-Item "$src\<SESSION_ID>.*" $dst Copy-Item "$src\sessions.json" $dst

DELETE / 트랜스크립트 제거

문제 세션의 트랜스크립트 파일 삭제

세션의 메시지 본문을 담은 3개 파일만 삭제한다. sessions.json은 건드리지 않는다 — 다음 단계에서 자동 정리한다.

# Windows PowerShell $base = "<USER_HOME>\.openclaw\agents\<AGENT>\sessions" Remove-Item "$base\<SESSION_ID>.jsonl" Remove-Item "$base\<SESSION_ID>.trajectory.jsonl" Remove-Item "$base\<SESSION_ID>.trajectory-path.json"

▸ 보존되는 것 memory-core 플러그인의 장기 기억과 <USER_HOME>\.openclaw\workspace의 마크다운 파일(MEMORY.md, USER.md, 프로젝트 폴더)은 그대로 유지된다. 평소 작업 결과를 파일로 외부화하는 습관이 있다면 손실은 마지막 대화 흐름에 한정된다.

INDEX / 인덱스 정리

sessions.json에서 missing 항목 자동 제거

트랜스크립트가 사라진 세션 항목을 sessions cleanup이 자동으로 정리해준다. 먼저 dry-run으로 확인한다.

openclaw sessions cleanup --fix-missing --dry-run

출력에 Would prune missing transcripts: 1이 보이면 적용.

openclaw sessions cleanup --fix-missing --enforce

NETWORK / IPv4 우선

IPv6 라우팅 실패 예방 (선택)

IPv6 문제가 진단된 경우만 적용. Gateway 시작 스크립트에 환경변수를 추가한다.

방법 A — gateway.cmd 직접 수정 (권장)

Gateway 시작 스크립트의 맨 위에 환경변수를 추가한다.

# <USER_HOME>\.openclaw\gateway.cmd 상단에 추가 set NODE_OPTIONS=--dns-result-order=ipv4first

방법 B — 사용자 환경변수 영구 설정

# Windows PowerShell [Environment]::SetEnvironmentVariable( "NODE_OPTIONS", "--dns-result-order=ipv4first", "User" )

방법 C — hosts 파일 (최후 수단)

관리자 권한 필요. Telegram이 IP를 바꾸면 수동 업데이트 필요해 비권장.

# 관리자 PowerShell Add-Content -Path "C:\Windows\System32\drivers\etc\hosts" ` -Value "`n149.154.166.110 api.telegram.org"

RESTART / 재시작 및 검증

Gateway 재시작 후 정상화 확인

openclaw gateway run --force

30~60초 대기 후 검증.

openclaw status openclaw channels status

다음 3가지를 확인한다.

OK Gateway가 reachable 상태
OK 새 세션의 토큰 % 낮음 (시작 직후 0% 또는 낮은 한 자릿수)
OK eventLoopDelayMaxMs < 100

05 — PREVENTION

재발 방지 — 자동화가 답이다

복구는 사후 조치다. 같은 일을 반복하지 않으려면 감지·자동 복구 체계가 필요하다.

P1. 외부 watchdog (Scheduler 기반)

Windows Task Scheduler 또는 cron으로 5분마다 OpenClaw 상태를 점검하는 별도 스크립트를 띄운다. OpenClaw 내부의 heartbeat(30분)와 다른 메커니즘이라 봇 자체가 hang 상태여도 감지된다.

점검 항목 권장 임계값:

지표	알림 임계값	자동 액션 임계값
세션 컨텍스트 토큰	70%	80% (compact 후보)
Stalled session age	6분	10분 (자동 abort)
eventLoopDelayMaxMs	500	3000
eventLoopUtilization	0.85	—
cpuCoreRatio	0.85	—

P2. 자동 복구 — 안전 조건 필수

Stalled session 자동 abort는 잘못 발동되면 정상 작업을 끊는다. 다음 3가지 AND 조건을 모두 만족할 때만 실행하도록 한다.

abortedLastRun = true — 시스템이 이미 한 번 abort를 시도했음
세션 age 10분 이상 — 충분히 오래 멈춰 있음
해당 session-key에 running task 없음 — 현재 사용자 메시지를 처리 중이 아님

세션 compact/reset은 대화 컨텍스트 손실 위험이 있으므로 자동 실행하지 않는다. 80% 임계값을 넘으면 사용자에게 승인 요청만 보낸다.

P3. 작업 외부화 습관

가장 강력한 예방은 사용자 습관이다. 작업 진행 중 중요한 결정이나 산출물은 반드시 워크스페이스 파일로 저장한다.

MEMORY.md — 장기 기억할 사실
USER.md — 사용자 프로필, 선호도
projects/<NAME>/ — 프로젝트별 설계, 진행 상황
memory/YYYY-MM-DD.md — 일자별 메모

이렇게 외부화하면 세션 삭제가 발생해도 작업의 본질이 보존된다. 봇은 새 세션에서 이 파일들을 다시 읽어 컨텍스트를 빠르게 재구성한다.

P4. 네트워크 단 영구 설정

IPv6 라우팅 실패는 환경마다 다르다. 한번 발생한 환경이면 거의 재발한다. NODE_OPTIONS=--dns-result-order=ipv4first를 Gateway 시작 스크립트에 영구 추가하는 것이 최선이다.

OpenClaw 인스턴스가 여러 개 있으면 각각의 gateway.cmd를 모두 점검한다. 한 인스턴스만 수정해도 다른 쪽에서 같은 문제가 발생할 수 있다.

▸ 검증 체크리스트 재발 방지 설정 적용 후, 의도적으로 컨텍스트가 차오를 때까지 사용하면서 다음을 확인한다. (1) 70% 도달 시 알림이 오는가, (2) Stalled 발생 시 10분 안에 자동 복구가 작동하는가, (3) Gateway 재시작 시 startup 지연이 1분 이내인가.

06 — FAQ

자주 묻는 질문

QOpenClaw 텔레그램 봇이 갑자기 답을 안 하는 이유는?

가장 흔한 원인은 3가지다. (1) 세션 컨텍스트가 70% 이상 차서 Codex app-server의 compaction 작업이 hang 되는 경우. (2) IPv6 라우팅 실패로 Node.js fetch가 OS 타임아웃까지 대기하며 event loop가 막히는 경우. (3) Stalled session이 heartbeat 주기보다 짧은 시간 안에 감지되지 않고 방치되는 경우. 가장 먼저 openclaw status로 세션 토큰 %를 확인하라.

QStalled session이란 무엇인가?

OpenClaw가 작업을 시작했지만 일정 시간 동안 진행 신호(lastProgress)가 갱신되지 않는 상태다. 로그에 state=processing age=Ns reason=active_work_without_progress classification=stalled_agent_run으로 표시된다. age가 360초(6분)을 넘으면 시스템이 stuck session recovery를 시도해 embedded_run을 abort한다.

Q세션 컨텍스트 70%가 왜 위험한가?

70% 임계점에서 Codex app-server가 컨텍스트 압축(compaction)을 시작한다. 압축할 토큰이 많으면(예: 190k 토큰) 압축 자체가 수 분간 hang 될 수 있고, 그 동안 다른 모든 요청이 처리되지 않는다. 80%를 넘어가기 전에 세션을 분할하거나 워크스페이스 파일로 작업 결과를 외부화하는 것이 안전하다.

QIPv6 라우팅이 안 되는데 왜 봇이 느려지나?

Node.js의 기본 DNS 동작은 RFC 6724에 따라 IPv6 주소를 우선 시도한다. ISP나 네트워크에서 IPv6 라우팅이 실패하면 즉시 거절되지 않고 OS 타임아웃(수십 초)까지 대기한다. 이 동기 대기 시간 동안 Node.js의 event loop가 막혀 모든 비동기 작업(타이머, 다른 fetch)이 지연된다. NODE_OPTIONS=--dns-result-order=ipv4first로 해결한다.

Q세션을 삭제하면 작업 기록이 다 사라지나?

아니다. OpenClaw는 세 종류 저장소를 분리한다. (1) 세션 트랜스크립트(jsonl) — 대화 흐름, 삭제 대상. (2) memory-core 플러그인 — 명시적으로 저장한 장기 기억, 유지됨. (3) 워크스페이스 파일 — MEMORY.md, USER.md, 프로젝트 폴더의 마크다운 파일, 유지됨. 평소 중요한 결정과 산출물을 워크스페이스 파일로 외부화하는 습관이 있으면 세션 삭제의 영향이 최소화된다.

Q같은 문제 재발을 막을 수 있나?

네 가지 예방 조치가 가능하다. (1) Rescue bot 또는 외부 Scheduler로 5분마다 event loop 상태와 세션 토큰 %를 모니터링. (2) gateway.cmd에 NODE_OPTIONS=--dns-result-order=ipv4first 영구 추가. (3) Stalled session 10분 이상 + running task 없음 조건일 때 자동 복구. (4) 세션 컨텍스트 70%·80% 임계값 알림 설정. 자동 abort나 자동 compact는 진행 중 작업을 끊을 수 있어 신중히 적용해야 한다.

Qsessions.json을 직접 편집해도 되나?

가능하지만 권장하지 않는다. 대신 트랜스크립트 파일(jsonl)만 삭제하고 openclaw sessions cleanup --fix-missing --enforce를 실행하면 OpenClaw가 sessions.json에서 해당 항목을 자동 정리한다. JSON 직접 편집은 인덱스와 트랜스크립트의 정합성이 깨질 위험이 있다.

QHeartbeat 주기를 30분에서 5분으로 줄이면 안 되나?

Heartbeat와 외부 watchdog은 다른 메커니즘이다. Heartbeat는 OpenClaw agent가 주기적으로 자기 점검과 메모 처리를 하는 대화형 루프다. 5분으로 줄이면 비용과 노이즈가 늘어난다. 장애 감지가 목적이라면 별도 외부 Scheduler 기반 watchdog(5분 주기)이 더 적합하다. Heartbeat는 30분 유지를 권장한다.

댓글 0