docs: record 23 runtime decommission after 24 recovery

journey/troubleshooting/260309_24서버_우분투터미널불가_네트워크대역오류_python3apt복구.md

@@ -229,6 +229,25 @@ sudo ip route del default via 192.168.219.1 dev eno1 metric 100
 - 한쪽 서버만 SSOT를 맞추고 다른 쪽에 과거 IP fallback을 남겨두면, 평상시에는 조용하다가 재배포, 장애 복구, env 누락 시점에 다시 옛 경로로 접속을 시도하는 구조적 재발 조건이 된다.
 - 따라서 24 서버 기준 완료 조건도 "주소가 바뀌었다"가 아니라, 실행 경로에서 `192.168.219.52` literal 검색 결과가 운영 파일 기준 0건이 되는 상태로 본다.
 
+## 2026-03-10 추가 조치: 23 임시 실행계 종료
+- 24 서버 실행면이 정상 복구된 뒤에도 23 서버에 `rb8001`, `robeing_monitor`, `skill-calendar`, `skill-email`, `skill-embedding`, `skill-rag-file`, `skill-slack`가 계속 떠 있어 스케줄 중복과 실행면 분리 실패 위험이 남아 있었다.
+- 2026-03-10 기준 23 서버에서는 아래 compose 작업 디렉터리에서 임시 실행계를 종료했다.
+
+```bash
+cd /home/admin/robeing/rb8001 && docker compose down
+cd /home/admin/robeing/robeing-monitor && docker compose down
+cd /home/admin/robeing/skill-calendar && docker compose down
+cd /home/admin/robeing/skill-email && docker compose down
+cd /home/admin/robeing/skill-embedding && docker compose down
+cd /home/admin/robeing/skill-rag-file && docker compose down
+cd /home/admin/robeing/skill-slack && docker compose down
+```
+
+- 종료 후 23 서버에는 `auth-redis`, `auth-server`, `data-prepper`, `fluent-bit`, `goosefarm-app`, `opensearch`, `robeing-gateway`, `robeing-skill-news`만 남아, 인프라/게이트웨이 중심 역할로 정리됐다.
+- 반대로 24 서버에는 `rb8001`, `robeing_monitor`, `skill-calendar`, `skill-email`, `skill-embedding`, `skill-publish`, `skill-rag-file`, `skill-slack`가 계속 `healthy` 상태로 남아 실행면이 24로 수렴한 것을 확인했다.
+- 외부 도메인 기준 검증도 유지됐다. `https://ro-being.com/rb8001/health`는 `{"status":"healthy", ...}`를 반환했고, 24 서버 로컬 `http://127.0.0.1:8001/health`도 같은 시각대에 정상 응답했다.
+- 따라서 24 복구의 완료 조건은 단순 부팅 복구가 아니라, 23의 임시 실행계를 내리고 24만 실행면으로 남기는 상태까지 포함해 닫는 것이 맞다.
+
 ## 재발 방지
 - 24 서버에서 시스템 `python3` 링크를 변경하지 않는다.
 - 개발용 Python 3.13은 `venv` 또는 명시적 바이너리 경로로만 사용한다.