# 답이 없는 봇을 재시작하기 전에, 고장 난 층부터 찾는 스킬을 만들었다
## 한줄 요약
메시징 봇의 무응답을 하나의 장애로 뭉뚱그리지 않고, 채팅 전달부터 게이트웨이·라우팅·모델 실행·발신까지 마지막으로 확인된 층을 찾도록 규칙을 고정했다.
## 바쁘시면 이것만 보세요
- 프로세스가 떠 있다는 사실은 봇이 정상이라는 뜻이 아니다.
- 채팅 화면의 시각, 전달 표시, 실제 봇 계정을 먼저 확인한 뒤 같은 시간대 로그를 맞춘다.
- 재시작은 상태 변경이다. 승인을 받고, 새 메시지의 왕복까지 확인해야 복구다.
## 이런 분께 추천합니다
- 답이 없으면 일단 서비스를 재시작하는 운영 습관을 줄이고 싶은 분
- 여러 봇과 프로필을 함께 운영해 엉뚱한 로그를 보기 쉬운 분
- “연결됨”, “포트 열림” 같은 부분 증거를 전체 정상으로 오해한 적이 있는 분
## 제작 배경
처음에는 무응답 문의를 받으면 프로세스와 포트만 보면 된다고 생각했다. 하지만 사용자가 말을 건 봇과 내가 조사한 런타임이 다를 수 있었고, 계정 인증은 정상인데 채널 플러그인이 로드되지 않을 수도 있었다. 메시지가 들어온 뒤 에이전트 실행이나 발신에서 멈추는 경우도 있었다. 재시작부터 하면 장애 시각과 마지막 정상 단계를 지운다. 그래서 복구 명령이 아니라 증거를 층별로 보존하는 순서를 스킬로 만들었다.
## 어떤 스킬인가
`messaging-bot-operations`는 실제 채팅을 출발점으로 봇 계정, 마지막 메시지, 전달·응답 상태를 확인하고 해당 런타임과 연결한다. `openclaw-operations`는 서비스, 게이트웨이, 채널 플러그인, 계정 설정, 인바운드, 라우팅, 에이전트 턴, 아웃바운드를 분리한다. 두 스킬의 공통 언어는 “마지막으로 직접 확인된 단계”다. 원인이 입증되지 않았으면 `확인됨`, `가장 가능성 높음`, `알 수 없음`을 구분한다.
## 어떻게 만들었나
먼저 무응답을 “봇 다운” 한 줄로 쓰지 못하게 했다. 채팅에서 메시지가 도착했는지, 런타임 로그에 인바운드가 있는지, 응답 준비와 발신 기록이 있는지를 순서대로 놓았다. 다음으로 프로세스 존재, 리스너, 게이트웨이 건강, 채널 연결을 각각 독립 증거로 정의했다. 설정 변경·플러그인 활성화·재시작·시험 메시지 발송은 모두 승인 경계에 넣었다. 마지막으로 복구 완료 조건을 “명령 성공”이 아니라 새 인바운드가 들어오고 같은 대화에 답이 도착하는 왕복 검증으로 고정했다.
## 어떻게 사용하는가
1. 실제 채팅에서 봇과 마지막 메시지 시각을 확인한다.
2. 그 봇이 속한 프로필과 런타임을 식별한다.
3. 해당 시각 주변 로그에서 인바운드→라우팅→에이전트 턴→발신 중 마지막 확인 단계를 찾는다.
4. 프로세스·포트·채널 상태를 보조 증거로 대조한다.
5. 읽기만으로 범위가 좁혀지지 않을 때 변경 대상과 중단 시간을 설명하고 승인을 받는다.
6. 변경 후 새 메시지 한 건으로 왕복을 확인한다.
## 검증과 시행착오
가장 큰 시행착오는 계정 점검 성공과 채널 실행 성공을 같은 것으로 본 일이었다. 토큰이나 계정 상태가 정상이어도 플러그인이 비활성일 수 있다. 또 발신 시험 성공만으로 인바운드 폴링과 라우팅까지 정상이라고 말할 수 없었다. 그래서 보고서에 코어 정상, 채널 연결, 인바운드 확인, 에이전트 응답 확인을 따로 적게 했다. 오래된 로그와 현재 장애를 섞지 않도록 채팅 시각을 기준점으로 삼은 것도 중요한 수정이었다.
## 효과 / Before-After
**Before:** “봇이 조용하다 → 프로세스 확인 → 재시작 → 아마 복구”처럼 진단과 변경이 섞였다.
**After:** “어느 봇의 어느 메시지가 어느 층까지 왔는가 → 필요한 변경만 승인 → 새 왕복으로 확인”이라는 짧은 운영 계약이 생겼다. 효과는 속도를 과장하는 데 있지 않고, 확인하지 않은 구간을 정상이라고 부르지 않게 된 데 있다.
## 한계와 중단 조건
직접 채팅이나 해당 런타임 로그에 접근할 수 없으면 근본 원인을 확정하지 않습니다. 자격증명 값은 직접 입력·복사하지 않고, 로그인·계정 선택·권한 동의는 사용자에게 넘깁니다. 설정 변경과 서비스 재시작은 명시적 승인 없이는 진행하지 않습니다. 새 시험 메시지가 허용되지 않으면 “런타임 복구”와 “실제 응답 복구”를 분리해 후자를 미검증으로 남깁니다.
## 다른 업무에 적용하는 법
웹훅, 이메일 자동화, 배치 알림에도 같은 방식이 통한다. 사용자 화면, 수신 커넥터, 큐, 처리기, 외부 발신을 층으로 나누고 마지막 확인 지점을 찾으면 된다. 핵심은 제품명이 아니라 부분 성공을 전체 성공으로 승격하지 않는 보고 규칙이다.
## 재사용 체크리스트
- [ ] 대상과 시각을 확인했는가
- [ ] 올바른 프로필·런타임을 매핑했는가
- [ ] 마지막 확인 단계를 기록했는가
- [ ] 상태 조회와 상태 변경을 분리했는가
- [ ] 변경 승인을 받았는가
- [ ] 새 인바운드와 실제 답변을 각각 검증했는가
