openclaw status는 멀쩡해 보이는데, 실제로는 답변이 자꾸 예전 맥락을 물고 오거나 이미 끝난 흐름이 다시 튀어나오는 경우가 있다. 이럴 때 사람들은 모델 문제나 캐시 문제로 먼저 의심하지만, 실무에서는 살아 있는 세션이 예상보다 오래 남아 있거나, active 세션 범위를 잘못 보고 있는 경우가 더 많다.
공식 문서 기준으로도 출발점은 단순하다. Gateway runbook은 건강한 기준선을 openclaw gateway status와 openclaw status에서 먼저 확인하라고 설명하고, sessions 문서는 openclaw sessions --active 120과 openclaw sessions cleanup --dry-run으로 실제 저장된 세션 범위를 보라고 안내한다. 즉, 이 문제는 “왜 답이 이상하지?”라고 넓게 보기보다 상태 확인 → active 세션 확인 → cleanup 시뮬레이션 순서로 자르는 편이 훨씬 빠르다.
안내: 이 문서는 생성형 AI로 초안을 작성한 뒤, OpenClaw 공식 문서와 실제 운영 루틴을 교차 확인해 정리했습니다.
flowchart LR A[답변이 예전 흐름을 계속 끌고 옴] --> B[openclaw gateway status] B --> C[openclaw status] C --> D[openclaw sessions --active 120] D --> E{오래된 active 세션이 보이나?} E -- 예 --> F[openclaw sessions cleanup --dry-run] F --> G[필요하면 --enforce] E -- 아니오 --> H[새 짧은 요청으로 재현 분리] G --> I[짧은 요청 2회 재검증] H --> I
칠판 치트시트
- 먼저
openclaw gateway status,openclaw status로 기준선을 본다- 그다음
openclaw sessions --active 120으로 실제 살아 있는 세션을 본다- 바로 지우지 말고
openclaw sessions cleanup --dry-run부터 본다- 새 짧은 요청 1~2회로 정말 세션 문제인지 다시 자른다
- 세션 정리는 “많이 지우기”보다 현재 active key 보호가 중요하다
왜 이런 일이 생기나
공식 status 문서에 따르면 openclaw status는 채널과 세션의 진단을 폭넓게 보여준다. 하지만 이 명령은 지금 무슨 문제가 체감되는지를 설명해 주는 도구이지, 어떤 대화 저장소에 오래된 세션이 얼마나 남아 있는지까지 바로 세밀하게 잘라 보여주는 도구는 아니다.
반면 공식 sessions 문서는 openclaw sessions --active 120으로 최근 활성 세션을 따로 볼 수 있다고 안내한다. 여기서 많이 갈린다. 운영자는 “지금 한 채팅만 보고 있다”고 느끼는데, 실제 저장소에는 메인 세션·자동화 세션·에이전트별 세션이 함께 남아 있어서 체감과 저장 상태가 다를 수 있다.
즉, 이 문제는 보통 아래 셋 중 하나다.
- 실제 active 세션이 오래 남아 있어서 예전 흐름이 계속 이어지는 경우
- 문제는 세션인데, 사람이
status만 보고 전체를 정상으로 판단한 경우 - cleanup 없이 세션이 누적돼서 무엇이 현재 흐름인지 설명하기 어려워진 경우
가장 빨리 확인하는 순서
1) Gateway와 전체 상태를 먼저 본다
세션 정리 전에 먼저 확인할 기준선은 아래 두 줄이다.
openclaw gateway status
openclaw status공식 Gateway runbook 기준 healthy baseline은 Runtime: running, RPC probe: ok 같은 신호다. 여기서 이미 Gateway 자체가 흔들리면 세션 정리보다 서비스 상태가 먼저다.
2) 최근 active 세션 범위를 따로 본다
openclaw sessions --active 120이 단계에서는 세션 수를 세는 것보다, 지금 쓰지 않는 흐름이 아직 active처럼 남아 있는지를 보는 게 중요하다.
특히 아래 장면을 먼저 본다.
- 메인 채팅은 하나인데 active 세션이 여러 개 보이는가
- 자동화/서브에이전트 흐름이 예상보다 오래 살아 있는가
- 내가 생각한 현재 흐름과 실제 저장된 active 목록이 다른가
3) 바로 지우지 말고 cleanup을 미리 시뮬레이션한다
openclaw sessions cleanup --dry-run공식 sessions 문서도 cleanup은 먼저 --dry-run으로 미리 보라고 설명한다. 이 단계가 중요한 이유는 간단하다. 실제 삭제보다 먼저 무엇이 남고, 무엇이 정리될지를 사람이 눈으로 확인할 수 있기 때문이다.
특히 active 세션이 아직 필요한 흐름이라면, 문서에 나온 --active-key 같은 보호 옵션을 같이 생각해야 한다. 세션 정리는 청소이지만, 잘못하면 현재 살아 있는 대화까지 같이 건드리는 청소가 될 수 있다.
4) 필요할 때만 enforce로 실제 정리를 적용한다
openclaw sessions cleanup --enforce여기서는 무조건 세게 정리하는 게 목적이 아니다. 핵심은 지금 문제를 만드는 오래된 세션 범위만 줄이는 것이다. 정리 후에는 바로 긴 작업을 다시 붙이지 말고, 새 짧은 요청 1~2회로 흐름이 정상화됐는지 먼저 확인하는 편이 안전하다.
현장 미니 사례 2개
사례 A) status는 정상인데 답변 톤이 자꾸 예전 프로젝트를 끌고 온 경우
- 상황: Gateway도 살아 있고 채널도 멀쩡해 보여서 모델 문제라고 생각함
- 실제:
openclaw sessions --active 120을 보니 오래된 작업 흐름이 active로 남아 있었음 - 처리:
cleanup --dry-run으로 범위를 확인한 뒤 필요한 정리만 적용 - 결과: 새 짧은 요청부터 현재 문맥으로 정상화
사례 B) 자동화가 끝났는데도 사람이 보기엔 계속 같은 작업이 이어지는 경우
- 상황: cron/에이전트 작업이 끝난 뒤에도 운영자가 답변 꼬임을 느낌
- 실제: 저장소 기준 active 세션이 사람이 느끼는 종료 시점보다 길게 남아 있었음
- 처리: 세션 목록과 cleanup 계획을 먼저 확인하고, 본 작업 전 짧은 헬스체크를 추가
- 결과: “고장”처럼 보이던 현상이 세션 관리 문제로 정리됨
누가, 무엇을, 어떤 순서로 하면 되나
운영자는 아래 순서만 따르면 된다.
openclaw gateway status와openclaw status로 서비스 기준선을 확인한다.openclaw sessions --active 120으로 active 세션 범위를 본다.openclaw sessions cleanup --dry-run으로 실제 정리 영향을 미리 확인한다.- 필요할 때만
openclaw sessions cleanup --enforce를 적용한다. - 새 짧은 요청 1~2회로 흐름이 진짜 정상화됐는지 재검증한다.
즉, 복구 핵심은 “다 지우기”가 아니라 지금 문제를 만드는 세션 범위를 설명 가능하게 만드는 것이다.
이렇게 확인되면 거의 복구다
아래 4개가 맞으면, 실무에서는 대부분 정리 완료로 봐도 된다.
openclaw gateway status가 healthy baseline을 보여준다.openclaw status에서 서비스 전반이 정상으로 읽힌다.openclaw sessions --active 120결과가 현재 체감과 크게 어긋나지 않는다.- cleanup 뒤 새 짧은 요청 2회가 현재 흐름 기준으로 안정적으로 응답한다.
재발 방지 팁
- 세션이 이상해 보일 때는 모델을 바꾸기 전에
sessions --active부터 본다. - cleanup은 바로 실행하지 말고 항상
--dry-run을 먼저 본다. - 장기 자동화가 많은 환경이라면 주기적으로 세션 유지 정책을 점검한다.
- 운영 기록에는 “무슨 세션을 정리했는지”보다 “왜 정리했는지”를 함께 남긴다.
한 줄 결론
OpenClaw가 예전 세션을 계속 붙잡는 것처럼 보일 때는, 모델보다 active 세션 범위를 먼저 확인하는 편이 빠르다. openclaw status만 보고 끝내지 말고, openclaw sessions --active 120과 cleanup --dry-run까지 봐야 원인이 제대로 잘린다.
내부링크·다음글 연결 (10)
- 07. Quota 기본 구조
- 23. Quota 리셋됐는데 요청이 막힐 때 복구
- 27. OpenClaw 대시보드가 안 열릴 때
- 26. Subagent 결과가 안 돌아올 때
- 17. cron은 돌았는데 텔레그램 전달이 안 올 때
- 11. Scheduled reminder 떴는데 액션이 안 이어질 때
- 10. Quota 리셋 알림 왔는데 quota exceeded 계속 뜰 때
- 13. Subagents 설계와 프롬프트
- 서브에이전트 분산운영
- Troubleshooting 허브
다음 추천 읽기: 27. OpenClaw 대시보드가 안 열릴 때
AI 활용 고지
이 문서는 생성형 AI를 활용해 초안을 구성했고, OpenClaw 공개 문서와 실제 운영 흐름을 함께 검토해 정리했습니다.