2026 OpenClaw 멀티채널(Feishu/LINE/Telegram): 업그레이드 후 세션 라우팅 검수와 끊김 복구 Runbook(Mac VPS)
Mac VPS에서 OpenClaw를 상시 게이트웨이로 돌리면 Slack 하나로는 부족하고 Feishu 워크플로, LINE 알림, Telegram DM을 동시에 얹고 싶어집니다. 라우팅 테이블·플러그인·세션 영속이 업그레이드로 바뀌면 모든 채널이 녹색인데 스레드가 엇갈리거나, 드문 끊김 뒤 재접속이 멈추는 현상이 먼저 납니다. 이 글은 Gateway와 영속화 프리플라이트, 단일→이중→전체 세 단계 검수, channels 프로브와 건강 판정, 채널·게이트웨이·Provider 계층 표, 다이제스트 고정 롤백까지 실무 순서로 정리합니다. 함께 읽기: 연결은 되는데 무반 분리, Docker 토큰과 pairing.
목차
1. 문제 분해: 라우팅 드리프트, 끊김, 업그레이드 결합
멀티 프로바이더는 webhook만 늘리는 일이 아닙니다. 각 IM의 속도 제한·서명·식별자를 게이트웨이 안에서 정규화해 단일 에이전트 세션 그래프로 옮겨야 하며, messaging profile이나 플러그인 경로가 깨지면 오프라인보다 교차 라우팅이 먼저 드러납니다.
- 세션 키 충돌: Feishu chat_id, LINE userId, Telegram chat id를 맞추지 않으면 채널 A가 B의 맥락을 끌어와 모델 쿼터로 오진합니다.
- 재연결 상태 구멍: 출구 TLS나 중간 장비 정책이 바뀔 때 지수 백오프와 재연결 로그가 없으면 하루 침묵처럼 보입니다.
- 설정 드리프트: Docker와 launchd의 환경 변수 주입 순서가 다르면 같은 버전도 비밀 경로가 달라 주간 랜덤 다운으로 보입니다.
- 단계 검수 부재: 세 채널을 동시에 켜면 실패 면이 넓어져 콜백 지연·secret 로테이션·큐 백프레셔를 가릅니다.
2. 단계 표: 단일·이중 부하·전체 관측
각 단계가 끝날 때마다 JSONL 슬라이스와 프로브 기록을 보관합니다.
| 단계 | 목표 | 주요 리스크 | 종료 기준 |
|---|---|---|---|
| 단일 채널 | 페어링 완료, DM·그룹 최소 권한, 에코 재현 | allowlist, requireMention, 멘션 규칙 불일치 | 연속 열 왕복에서 스레드 혼선 없음, 프로브 세 번 healthy |
| 이중 부하 | 교차 부하에서도 세션 분리·지연 허용 범위 | 단일 프로세스 HOL로 다른 채널 기아 | 합의 P95 미만, 오류 유형 클러스터 가능 |
| 전체 관측 | 세 채널 상시와 업그레이드 창, 로그 샘플링 | 디스크 가득 또는 로테로 필수 필드 손실 | 샘플 창에서 임의 메시지 상관 ID 복원 가능 |
3. 프리플라이트: Gateway·토큰·영속화·launchd
게이트웨이를 상태ful 서비스로 취급하고 토큰 권한, 영구 볼륨, ThrottleInterval과 크래시 재시작을 변경 티켓에 명시합니다. 최소 환경 변수 목록을 plist에도 반영해 대화형 셸 export에만 의존하지 않습니다. 컨테이너는 마운트와 uid를 다시 확인해 플러그인 디렉터리 읽기 전용 반기동을 피합니다.
openclaw doctor
openclaw gateway status --deep
openclaw channels status --probe
프로브에 시각과 빌드 ID를 붙이고 IP 허용이나 channel secret 변경 시 같은 스크립트로 재측정해 UI 클릭 의존을 없앱니다.
4. 다섯 단계: 에코부터 롤백 훈련까지
- 베이스라인 동결: messaging profile·플러그인·자격 지문을 기록하고 태그나 다이제스트로 latest 금지.
- 단일 에코: 부하 낮은 채널부터 페어링 후 고정 템플릿으로 DM·그룹 검증, 로그에서 accountId·thread 확인.
- 이중 부하: 스크립트나 사람이 교차 전송해 HOL을 관찰. 한쪽만 지연면 먼저 인바운드 속도 제한.
- 전체와 샘플링: JSONL은 messageId·channelId·latencyMs를 남기고 디스크는 로그 급증에 약 이십 퍼센트 여유.
- 롤백 훈련: 유지보수 창에서 이전 다이제스트로 내리고 재페어링 없이 복구되는지 확인, 소요·결손면 기록.
5. 세 가지 인용 지표: 프로브 주기, 재연결, 라우팅 샘플
- 프로브 주기: 운영은 삼~오분 경량 프로브를 하트비트와 분리하고 연속 세 실패 시 P1.
- 재연결 카운터: 장수명 연결은 시간당 재연결을 추적하고 자릿수가 튀면 TLS·인증서를 먼저 의심.
- 라우팅 샘플: 일일로 사용자 채널과 게이트웨이 session 정합을 확인하고 messageId 리플레이 가능하게.
6. 계층별 장애와 로그 운영
일부 지연·일부 침묵이면 webhook 응답 코드와 서명, 게이트웨이 프로세스·큐·플러그인 패닉, Provider 429·컨텍스트 순으로 봅니다. 셋 모두 녹색인데도 무반이면 페어링과 mention으로 돌아가 위 링크 체크리스트와 대조합니다. Mac VPS는 고정 공인 IP로 Feishu 허용이 단순하고 노트북 재부팅 의존보다 재현성이 낫습니다.
노트북 가정용 회선과 절전은 장수명 소켓 통계를 왜곡합니다. 영구 볼륨 없는 Docker 실험은 업그레이드마다 페어링을 잃어 QR 왕복에 시간을 씁니다. Feishu·LINE·Telegram을 프로덕션 플로에 올리면서 SSH와 launchd로 통제하려는 팀은 VPSMAC Apple Silicon Mac 클라우드를 전용 게이트웨이 호스트로 두고 출구·디스크·24/7 재시작 정책을 감사 가능한 한 장 체크로 모으는 편이 불안정한 엣지 장비에 채널을 쌓는 것보다 본질에 가깝습니다.
7. FAQ
Feishu와 Telegram이 같은 bot 토큰 디렉터리를 써도 되나요? 채널별 경로와 Unix 권한으로 분리해 chmod 실수로 둘 다 죽는 것을 막습니다.
이중 부하 메시지량은? 큐 머리가 막힐 정도면 충분하고 분당 수십 건 교차로도 백프레셔가 보입니다. 절대 QPS보다 재현 템플릿이 중요합니다.
언제 채널 하나를 끄나요? 제3자 장애로 SLA를 못 잡는 클러스터가 명확하면 읽기 전용 알림으로 내려 메인 루프를 막지 않습니다.
8. 정리
멀티채널 성공은 ‘보냈다’가 아니라 업그레이드 후에도 라우팅과 페어링이 추적·되돌리기 가능하다는 뜻입니다. 세 단계를 변경 템플릿에 넣고 프로브를 기존 알림에 연결하며 분기마다 십오 분 안에 본 Runbook 앞부분을 끝내는 훈련을 넣으면 운영이 안정됩니다.