docs: record 51123 skill recovery and deploy-safe path generalization

journey/plans/260304_24장애시_23자동임시프로덕션전환_계획.md

@@ -0,0 +1,94 @@
+# 260304 24장애시 23자동임시프로덕션전환 계획
+
+**작성일**: 2026-03-04  
+**상태**: draft  
+**목표**: 51124 물리/시스템 장애 시 51123이 자동으로 robeing 임시 프로덕션 역할을 승격 수행
+
+---
+
+## 1. 문제 정의
+- 현재 구조는 24 실행 서버 의존도가 높아 물리 장애 시 서비스 연속성이 급격히 저하된다.
+- 수동 복구는 운영자 가용성(물리 접근/원격 접속 가능 여부)에 강하게 의존한다.
+- 목표 RTO(복구 시간)와 RPO(데이터 손실 허용량)를 명시하고 자동 전환 체계를 구축해야 한다.
+
+권장 기준:
+- RTO: 5분 이내
+- RPO: 0~수초(공유 DB/공유 스토리지 전제)
+
+## 2. 결론 먼저 (도구 선택)
+1. **지금 당장(단기)**: Kubernetes/Swarm 없이 `Docker Compose + systemd + nginx upstream 자동전환`으로 구현 가능
+2. **중기(안정화 후)**: `k3s`(경량 Kubernetes) 권장
+3. **Swarm**: 신규 도입 비권장 (생태계/운영 표준/장기 유지보수 측면에서 k3s 대비 이점이 작음)
+
+## 3. 아키텍처 원칙
+- 단일 진입점 유지: 외부 트래픽은 기존 gateway/nginx 경유
+- 장애 감지와 승격 분리: detect(헬스) -> promote(기동/라우팅 전환) -> verify(스모크 테스트)
+- 이중 실행 방지: 스케줄러/배치 작업은 반드시 단일 리더만 실행(DB advisory lock)
+- 데이터 일관성 우선: 23/24가 같은 DB와 동일 스키마를 사용하도록 관리
+
+## 4. 단기 구현안 (즉시 실행 가능)
+
+### 4-1. 23 Warm Standby 상시 준비
+- 23에 아래 서비스 compose를 상시 준비(이미지 pull/빌드 캐시 유지):
+  - `rb8001`, `skill-email`, `skill-calendar`, `robeing-monitor` (+필요 스킬)
+- `.env` 및 시크릿 동기화:
+  - JWT secret, API key, DB 접속정보를 23/24 동일 정책으로 관리
+- UFW/포트 사전 허용:
+  - 23에서 내부 브리지 대역 -> 필요 포트 접근 허용 사전 적용
+
+### 4-2. 자동 장애 감지
+- `systemd timer`(1분 주기) 또는 runner cron으로 감지 스크립트 실행
+- 감지 조건 예시:
+  - `http://192.168.219.52:8001/health` 3회 연속 실패
+  - + TCP check 실패(이중 확인)
+
+### 4-3. 자동 승격
+- 승격 스크립트 동작 순서:
+1. 락 획득(중복 승격 방지)
+2. 23에서 대상 compose `down && up -d --build`
+3. nginx upstream을 24 -> 23으로 스위치
+4. `nginx reload`
+5. 스모크 테스트(`/healthz`, `/api/message`, 이메일 핵심 API)
+6. 성공 시 상태 파일 기록 및 알람 전송
+
+### 4-4. 자동 복귀(24 복구 시)
+- 24 헬스 일정 시간 안정(예: 10분) 확인 후 역전환
+- 역전환도 동일하게: 락 -> upstream 복귀 -> 스모크 테스트 -> 성공 기록
+
+## 5. 필수 안전장치
+- 스케줄 중복 방지:
+  - scheduler 실행 전 `pg_try_advisory_lock` 획득 실패 시 해당 노드 작업 skip
+- 배포/전환 충돌 방지:
+  - 배포 파이프라인과 failover 스크립트가 같은 락 파일/DB 락 사용
+- 관측성:
+  - 전환 이벤트를 `/mnt/hdd/logs/`에 구조화 로그(JSON)로 기록
+  - 실패 시 Slack/이메일 알림
+
+## 6. Kubernetes vs Swarm 판단
+
+### Kubernetes(k3s) 권장 조건
+- 서비스 수 증가, 셀프힐링/오토스케일/롤링업데이트 필요
+- 장애자동복구를 플랫폼 기능으로 흡수하고 싶을 때
+- 장기적으로 운영 표준화 필요할 때
+
+### Docker Swarm 비권장 이유
+- 신규 기능/생태계 확장성이 제한적
+- 장애 대응 및 관측 도구 선택폭이 Kubernetes 대비 좁음
+- 장기 투자 대비 이득이 작아 현재 시점 도입 우선순위 낮음
+
+## 7. 단계별 실행 로드맵
+1. Day 1: 23 standby compose/시크릿/UFW 정합화 + 수동 승격 리허설
+2. Day 2: 자동 감지/승격 스크립트 + nginx 자동 스위치 + 알람 연동
+3. Day 3: DB advisory lock 기반 스케줄 단일 실행 적용
+4. Day 4: 강제 DR 테스트(24 down 가정) 2회, RTO 계측
+5. Week 2+: k3s PoC 착수 여부 결정(비용/운영복잡도 평가 후)
+
+## 8. 완료 판정 기준
+- 24 차단 시 5분 이내 23 자동 승격 성공
+- `/api/message`, 9~10시 이메일/브리핑 스케줄 정상 수행
+- 중복 실행/중복 발송 없음
+- 전환/복귀 이벤트가 로그와 알림으로 추적 가능
+
+## 9. 후속 문서 연결
+- [260303_23테스트보조_24프로덕션_운영전환_계획](./260303_23테스트보조_24프로덕션_운영전환_계획.md)
+- [260304_51123_임시복구_서비스연속성_조치내역](../troubleshooting/260304_51123_임시복구_서비스연속성_조치내역.md)

journey/plans/260304_자기개선루프_프롬프트DB_23로컬24_통합실행기록.md

@@ -109,3 +109,22 @@
 - 본 문서 범위(게이트웨이 경유 자기개선/prompt-db 교차검증)는 완료.
 - 23 gateway 계층의 `POST 405/422` 이슈는 해소되었고, 24에서 운영 경유 증거까지 확인됨.
 - Slack `Invalid signature`는 별도 운영 이슈로 분리 관리(본 완료 판정 범위 밖).
+
+## 6. 후속 운영 안정화 기록 (2026-03-04 03:00~03:30 KST)
+1. 51123 스킬 가동 상태 보강
+- `skill-news(8505)`, `skill-slack(8502)`, `skill-rag-file(8508)`, `skill-embedding(8515)` 모두 healthy 복구.
+
+2. 장애 원인 확정
+- `skill-embedding` 부팅 실패 원인은 ONNX 모델 파일 부재(`model.onnx`)로 확정.
+- `jhgan/ko-sroberta-multitask` ONNX 생성 후 재기동으로 정상화.
+
+3. 23/24 자동배포 안전화 반영(푸시 완료)
+- `skill-rag-file`: `ab3ac78`
+  - compose 경로를 `DOCUMENT_MOUNT_ROOT`/`DOCUMENT_BASE_PATH`로 일반화.
+- `skill-embedding`: `5a0f357`, `ede5896`
+  - compose 경로를 `ONNX_MODELS_HOST_PATH` 기반으로 일반화.
+  - 24 기본값은 `/home/admin/ivada_project/onnx_models`, 23은 `.env` 오버라이드.
+
+4. workflow 점검 결론
+- `rb8001`, `skill-*`, `robeing-monitor` workflow 파일 점검 완료.
+- 본 이슈 기준 추가 YAML 필수 수정사항 없음(경로 이슈는 compose/.env 일반화로 해소).

journey/troubleshooting/260304_51123_임시복구_서비스연속성_조치내역.md

@@ -76,3 +76,41 @@
   2. gateway 대상 upstream 재점검
   3. 임시 성능 플래그(`INTENT_USE_LANGGRAPH=false` 등) 단계적 해제 여부 성능 측정 후 결정
 - 본 문서는 51123 임시복구 기준 운영 기록이며, 24 원복 시 별도 후속 문서로 분리 기록 권장.
+
+## 8. 추가 복구/배포 안전화 기록 (2026-03-04 03:00~03:30 KST)
+### 8.1 스킬 복구 상태(51123)
+- 실행 확인:
+  - `robeing-skill-news` (`8505`) healthy
+  - `skill-slack` (`8502`) healthy
+  - `skill-rag-file` (`8508`) healthy
+  - `skill-embedding` (`8515`) healthy
+- 헬스 응답 확인:
+  - `GET http://192.168.219.45:8505/health` -> `{"status":"healthy"}`
+  - `GET http://192.168.219.45:8502/health` -> healthy 응답
+  - `GET http://192.168.219.45:8508/healthz` -> healthy 응답
+  - `GET http://192.168.219.45:8515/healthz` -> `{"status":"ok"}`
+
+### 8.2 근본 원인과 조치(embedding)
+- 근본 원인:
+  - `skill-embedding` 재시작 루프 원인은 `/models/onnx/ko-sroberta-multitask/model.onnx` 파일 부재.
+  - 로그 근거: `FileNotFoundError: ONNX 모델 파일을 찾을 수 없습니다`.
+- 조치:
+  - `jhgan/ko-sroberta-multitask`를 ONNX로 변환해 `model.onnx` 생성.
+  - 생성 경로: `/home/admin/robeing/onnx_models/ko-sroberta-multitask/model.onnx` (약 423MB).
+  - 이후 `skill-embedding` `docker compose down && up -d --build`로 정상화.
+
+### 8.3 배포 안전화(23/24 경로 일반화) 및 푸시
+- `skill-rag-file`:
+  - `DOCUMENT_MOUNT_ROOT`, `DOCUMENT_BASE_PATH` 기반으로 볼륨/경로를 서버별 `.env` 오버라이드 가능하게 일반화.
+  - 반영 커밋: `ab3ac78` (`main` 푸시 완료).
+- `skill-embedding`:
+  - `ONNX_MODELS_HOST_PATH` 기반으로 모델 마운트 경로 일반화.
+  - 24 자동배포 기본값은 `/home/admin/ivada_project/onnx_models`로 고정.
+  - 23 임시복구는 `.env` 오버라이드로 유지.
+  - 반영 커밋: `5a0f357`, 추가 교정 `ede5896` (`main` 푸시 완료).
+
+### 8.4 Gitea workflow 점검 결과
+- 점검 대상: `rb8001`, `skill-news`, `skill-slack`, `skill-email`, `skill-calendar`, `skill-rag-file`, `skill-embedding`, `robeing-monitor`의 `.gitea/workflows/*.yml`.
+- 결론:
+  - 이번 이슈 기준(서버 경로 하드코딩)으로는 workflow YAML 추가 수정 없이 `.env`/compose 일반화로 대응 가능.
+  - 별도 개선 후보: `skill-calendar` workflow의 `runs-on` 위치가 비표준 구조라 안정성 점검 필요(후속 과제 분리).