openclaw status --all을 돌렸더니 항목이 길게 나오고 경고까지 섞여 있으면, 많은 사람이 그 순간부터 전체가 불안정하다고 느낀다. 그런데 OpenClaw 공식 문서 기준으로 status --all은 읽기 전용 진단 요약에 가깝고, 거기서 보이는 경고도 성격이 서로 다르다. 어떤 것은 지금 답이 안 오는 실제 장애와 바로 연결되고, 어떤 것은 나중에 정리해도 되는 설정 경고다.
공식 status 문서는 --all을 full diagnosis라고 설명하고, gateway troubleshooting은 실제 복구 순서를 status → gateway status → logs → doctor → channels status --probe로 잡아 둔다. 핵심은 간단하다. 경고 줄 수를 세지 말고, 지금 증상과 바로 연결되는 줄부터 잘라야 한다.
안내: 본문은 생성형 AI로 초안을 정리하고, OpenClaw 공식 문서와 실제 CLI help 출력을 교차 확인해 보정했습니다.
flowchart TD A[`openclaw status --all` 경고 확인] --> B{지금 실제 증상이 있나?} B -->|답이 안 옴/연결 이상| C[`openclaw gateway status` + `openclaw channels status --probe`] B -->|예전 흐름이 붙음| D[`openclaw sessions --active`] B -->|겉보기 경고만 있음| E[Secrets/usage/status overview 먼저 분류] C --> F[`openclaw logs --follow`로 실제 드롭/실패 확인] D --> G[세션 범위 먼저 정리] E --> H{설정 경고인가 실행 경고인가?} H -->|설정/secret 경고| I[`doctor --repair` 검토] H -->|실행/채널 경고| C F --> J[현재 증상 해소 여부 재확인] G --> J I --> J
칠판 치트시트
status --all은 경고 수보다 종류가 중요하다- 지금 답이 안 오면
gateway와channels --probe가 먼저다- 예전 흐름이 붙으면 서비스보다
sessions를 먼저 본다- Secrets 경고는 당장 장애가 아닐 수도 있다
- 강한 복구는 마지막에
doctor --repair나doctor --force를 검토한다
이런 증상이면 이 문서가 바로 맞다
openclaw status --all에서 여러 줄 경고가 보이는데 무엇부터 봐야 할지 모르겠다.- 채널은 살아 있는 것 같은데 status 출력에 warning이 많아 불안하다.
- Secrets overview, usage, channel status가 같이 떠서 우선순위가 안 잡힌다.
status --all과doctor중 무엇을 먼저 믿어야 할지 헷갈린다.- 실제 장애인지, 읽기 전용 진단 경고인지 먼저 가르고 싶다.
왜 헷갈리는가
1) status --all은 진단 요약이라 여러 층을 한 화면에 모아 준다
공식 status 문서에 따르면 openclaw status는 channels와 sessions 진단용이고, --all은 full diagnosis다. 여기에 문서 설명상 Secrets overview, gateway 개요, 세션 요약, 채널 진단이 함께 들어올 수 있다. 즉 보기에는 한 덩어리 경고처럼 보여도 실제로는 채널 층, 세션 층, secret 층이 섞여 있을 수 있다.
작은 미니 케이스로 보면 더 분명하다. 메시지는 잘 오는데 status에 secret warning만 남는 경우와 메시지 자체가 안 오는데 channel probe가 흔들리는 경우는 같은 “경고 있음”으로 보여도 우선순위가 완전히 다르다.
2) 실제 복구 순서는 status 혼자서 끝나지 않는다
공식 gateway troubleshooting 문서는 첫 사다리를 openclaw status, openclaw gateway status, openclaw logs --follow, openclaw doctor, openclaw channels status --probe 순서로 둔다. 즉 status --all은 시작점이지 종착점이 아니다.
그래서 status --all 출력만 오래 들여다보면 오히려 복구가 늦어진다. 지금 필요한 건 문장 해석보다 다음 분기 명령을 고르는 일이다.
3) Secrets 경고와 실행 경고는 체감 무게가 다르다
공식 status 문서는 supported SecretRefs가 현재 command path에서 unavailable이면 read-only 경고를 보여 주고, JSON에는 secretDiagnostics가 포함된다고 설명한다. 이건 중요하지만, 항상 “지금 당장 답이 안 오는 장애”와 같은 급은 아니다.
반대로 channel probe나 gateway runtime 문제가 보이면, 그건 현재 체감 장애와 더 직접 연결될 가능성이 크다. 즉 Secrets 경고는 설정 가시성 문제일 수 있고, channel/gateway 경고는 실행 문제일 수 있다는 구분이 필요하다.
가장 빠른 5분 해석 순서
1) 먼저 지금 실제 증상이 있는지 한 줄로 자른다
가장 먼저 볼 것은 status 출력이 아니라 현실 증상이다.
- 답이 안 오나
- 특정 채널만 이상하나
- 예전 흐름이 붙나
- 그냥 경고만 보이나
이 한 줄이 잡히면 분기가 쉬워진다. 실제 증상이 없고 status --all에 warning만 있다면, 당장 강한 복구를 하기보다 설정성 경고부터 읽는 편이 안전하다.
2) 채널/실행 문제 같으면 gateway status와 channels status --probe로 바로 내려간다
공식 runbook과 실제 help 출력 기준으로 가장 짧은 흐름은 아래다.
openclaw status --all
openclaw gateway status
openclaw channels status --probegateway status가 흔들리면 서비스 축이 우선이다.channels status --probe가 흔들리면 채널 자격증명이나 transport 축이 우선이다.- 둘 다 안정적이면, status의 다른 경고는 설정/가시성 쪽일 가능성이 높다.
3) 예전 대화가 붙는 느낌이면 sessions를 먼저 본다
공식 status 문서도 channels + sessions 진단을 함께 말한다. 실제로는 많은 사람이 세션 문제를 서비스 문제로 오해한다.
openclaw sessions --active 120예를 들어 gateway도 정상이고 채널도 정상인데, 요청마다 예전 흐름이 길게 이어지면 서비스 재시작보다 세션 범위 확인이 먼저다. 이 분기를 놓치면 괜히 gateway만 여러 번 건드리게 된다.
4) Secrets overview warning은 즉시 장애인지, read-only 경고인지 구분한다
status 문서에 따르면 supported SecretRef가 현재 command path에서 unavailable이면 status는 read-only로 경고를 보여 준다. 이 말은 곧, 경고가 있어도 실제 런타임이 이미 정상 동작 중일 수 있다는 뜻이다.
이럴 때는 아래처럼 본다.
- 채널 동작도 정상, gateway도 정상 → 설정 가시성 warning일 가능성 큼
- 채널 동작은 비정상, Secret 경고와 함께 probe도 실패 → 설정/자격증명 축을 같이 봐야 함
- headless 경로에서만 경고 → command path 차이 가능성 확인
5) 구조 경고만 남으면 마지막에 doctor --repair를 검토한다
공식 doctor 문서와 실제 help 출력 기준으로 doctor는 gateway와 channels용 health checks + quick fixes다. 옵션도 --repair, --fix, --force, --deep 순으로 강도가 달라진다.
openclaw doctor --repair즉 status --all에서 구조 경고가 남아도, 현재 실행 문제를 먼저 자른 뒤 마지막에 doctor --repair를 검토하는 편이 안전하다. --force는 custom service config를 덮어쓸 수 있는 aggressive repairs라서 더 뒤다.
운영자가 바로 판단하는 기준
| 상황 | 먼저 볼 것 | 이유 |
|---|---|---|
| 답이 실제로 안 옴 | gateway status, channels status --probe | 실행 축 문제인지 먼저 자를 수 있다 |
| 예전 맥락이 길게 붙음 | sessions --active | 서비스보다 세션 문제일 가능성이 크다 |
| warning은 많은데 체감 장애는 없음 | Secrets overview, usage, overview | 읽기 전용 경고를 먼저 분리할 수 있다 |
| 구조 경고가 계속 남음 | doctor --repair | 설정 복구 단계로 넘어갈 기준점이다 |
| 전부 한꺼번에 이상해 보임 | logs --follow | 실제 실패 시그니처를 가장 빨리 확인한다 |
현장 미니 사례 2개
사례 A) warning은 많았지만 실제 서비스는 정상인 경우
- 상황:
status --all에 Secrets 관련 warning과 usage 정보가 같이 길게 보임 - 실제 원인: 현재 command path에서 secret 가시성이 일부 제한된 read-only 경고였고, 채널 동작은 정상
- 복구: 당장 재시작하지 않고 gateway와 probe부터 정상 확인
- 검증: 실제 메시지 송수신과
channels status --probe결과가 안정적인지 재확인
사례 B) status는 복잡했지만 실제 병목은 채널 probe였던 경우
- 상황: overview, sessions, warning이 한 화면에 섞여 보여서 전체 장애처럼 느껴짐
- 실제 원인: 특정 채널 자격증명 또는 transport probe 문제
- 복구:
openclaw channels status --probe와 로그로 범위 축소 - 검증: 해당 채널만 회복되면 나머지 warning은 뒤로 미뤄도 되는지 확인
검색형 FAQ
Q1. openclaw status --all에 warning이 뜨면 바로 고쳐야 하나요?
아니다. 공식 status 문서 기준으로 --all은 읽기 전용 full diagnosis다. 먼저 지금 실제 증상과 연결되는 warning인지부터 가르는 편이 빠르다.
Q2. status --all과 doctor 중 무엇을 먼저 봐야 하나요?
대개는 status --all로 범위를 읽고, 구조 복구가 필요할 때 doctor --repair로 내려가는 편이 좋다. 공식 troubleshooting runbook도 status를 먼저 둔다.
Q3. Secrets overview warning은 무조건 장애인가요?
그렇지 않다. status 문서 설명상 current command path에서 SecretRef를 못 풀 때 read-only 경고가 나올 수 있다. 실행 문제와 같은 급인지 따로 봐야 한다.
Q4. --deep는 언제 쓰나요?
공식 status 문서 기준으로 --deep는 live probes를 돈다. 기본 출력만으로 채널 상태가 애매할 때 probe 성격의 추가 진단으로 쓰기 좋다.
Q5. 가장 짧은 확인 순서는 무엇인가요?
openclaw status --all → openclaw gateway status → openclaw channels status --probe → 필요 시 openclaw sessions --active 120 → 구조 경고만 남으면 openclaw doctor --repair 순서가 가장 덜 헷갈린다.
다음 읽기
- 27. OpenClaw 대시보드가 안 열릴 때 해결
- 28. OpenClaw 예전 세션이 계속 붙을 때 정리
- 30. OpenClaw 채널은 연결됐는데 답이 없을 때 해결
- 32. OpenClaw browser에서 Access denied가 뜰 때 해결
- 33. OpenClaw gateway status는 정상인데 browser가 안 될 때 해결
- 41. OpenClaw doctor에서 경고가 여러 개 뜰 때 우선순위 정리
- 🚀 OpenClaw 허브
- Troubleshooting 허브
한 줄 결론
openclaw status --all 경고는 한 덩어리로 보지 말고, 실행 문제인지, 세션 문제인지, secret 가시성 경고인지 먼저 나눈 뒤 다음 명령으로 내려가는 것이 가장 빠르다.
※ 이 문서는 생성형 AI를 활용해 작성되었습니다.