From 6e6856617116545ec7e49808d0eb48620c7d5752 Mon Sep 17 00:00:00 2001
From: Claude-51124 <claude@51124.local>
Date: Mon, 9 Mar 2026 18:36:33 +0900
Subject: [PATCH] docs: redirect infrastructure troubleshooting to infra docs

---
 ...17_starsandi_dns_nginx_ssl_분리적용.md |  54 +------
 ...��사고_복구_및_의존포트_점검.md | 143 +-----------------
 ...51123_ufw_외부포트_차단_하드닝.md |  73 +--------
 ...05_51124_다운_상태_및_복구예정.md |  14 +-
 ...루트포스_차단_및_fail2ban_교정.md |  38 +----
 ..._bot_account_compromise_and_eradication.md |  79 +---------
 ...nclaw_gateway_상주프로세스_정리.md |  41 +----
 ..._219_51_접속불가_임시백업복구.md |  43 +-----
 ...8001_연결점검_23서버_전달사항.md |  59 +-------
 ...�복구_서비스연속성_조치내역.md | 119 +--------------
 ...ot_및_배포실패_근본원인_해결.md |  45 +-----
 ..._gitea_lfs_permission_denied_502_복구.md |  47 +-----
 ...�이전_네트워크변경_운영기록.md |  21 +--
 ...AS_권한정렬_및_실업로드_검증.md |  76 +---------
 ...SOT_전환_및_CIFS_실마운트_복구.md |  77 +---------
 ...untime_secrets_분리_적용_및_검증.md |  79 +---------
 journey/troubleshooting/README.md             |   6 +
 17 files changed, 87 insertions(+), 927 deletions(-)

diff --git a/journey/troubleshooting/2026-02-17_starsandi_dns_nginx_ssl_분리적용.md b/journey/troubleshooting/2026-02-17_starsandi_dns_nginx_ssl_분리적용.md
index fde7c65..0ff4eba 100644
--- a/journey/troubleshooting/2026-02-17_starsandi_dns_nginx_ssl_분리적용.md
+++ b/journey/troubleshooting/2026-02-17_starsandi_dns_nginx_ssl_분리적용.md
@@ -1,51 +1,7 @@
-# 2026-02-17 starsandi DNS/nginx/SSL 분리 적용
+# 2026-02-17_starsandi_dns_nginx_ssl_분리적용
 
-## 배경
-- 목표: 51123 서버에서 `ro-being.com`과 `starsandi.com`을 충돌 없이 분리 운영.
-- 요구사항:
-  - DNS: `A @ -> 124.55.18.179`, `CNAME www -> @`
-  - nginx: `starsandi.com`, `www.starsandi.com` 전용 서버 블록 분리
-  - HTTPS: certbot으로 인증서 발급 및 80 -> 443 적용
-  - 경로: starsandi 앱은 현재 `basePath=/starsandi` 유지
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
-## 원인 및 이슈
-- 초기 조회에서 `starsandi.com`이 Namecheap 주차 IP(`192.64.119.114`)로 응답되어 인증서 발급 타이밍 이슈 존재.
-- 권한 DNS(8.8.8.8, 1.1.1.1) 기준으로는 `124.55.18.179` 조회되어 전파 진행 중 상태 확인.
-
-## 적용 내용
-
-### 1) nginx 도메인 분리
-- 파일 추가: `/etc/nginx/sites-available/starsandi.conf`
-- 심볼릭 링크: `/etc/nginx/sites-enabled/starsandi.conf`
-- 핵심 설정:
-  - `server_name starsandi.com www.starsandi.com;`
-  - `location = / { return 301 /starsandi; }` (basePath 유지)
-  - `location /starsandi { proxy_pass http://127.0.0.1:3010; ... }`
-
-### 2) ro-being 경로 충돌 방지
-- 파일 수정: `/etc/nginx/sites-enabled/default`
-- 변경 내용:
-  - `ro-being.com` 블록의 `/startsandi`, `/zari`, `/starsandi` 요청을 `https://starsandi.com...`으로 301 리다이렉트
-
-### 3) SSL(certbot)
-- 실행 명령:
-  - `sudo certbot --nginx -d starsandi.com -d www.starsandi.com --non-interactive --agree-tos -m admin@starsandi.com --redirect`
-- 결과:
-  - 인증서 발급 성공
-  - 경로: `/etc/letsencrypt/live/starsandi.com/fullchain.pem`
-  - 만료일: `2026-05-18`
-  - certbot이 nginx 설정에 443 블록 자동 반영
-
-## 검증 결과
-- `sudo nginx -t` 성공
-- `sudo systemctl reload nginx` 성공
-- 로컬 강제 해석(`--resolve`) 검증:
-  - `http://starsandi.com` -> `https://starsandi.com/` 301
-  - `https://starsandi.com` -> `/starsandi` 301
-  - `https://www.starsandi.com` -> `/starsandi` 301
-  - `https://ro-being.com/starsandi` -> `https://starsandi.com/starsandi` 301
-
-## 운영 메모
-- DNS 캐시/전파 구간에서는 일부 클라이언트가 Namecheap 응답(주차/포워딩)을 잠시 볼 수 있음.
-- 실제 서비스 판별은 `dig @8.8.8.8 starsandi.com A`, `dig @1.1.1.1 starsandi.com A`로 재확인.
-- 용어 표기는 서버 규칙에 따라 `robeing` 기준 유지.
+- 새 위치: `260217_starsandi_dns_nginx_ssl_분리적용.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/260217_starsandi_dns_nginx_ssl_분리적용.md>
+- 이유: 23/24/NAS, 게이트웨이, 배포, 네트워크, 백업, 마운트 등 공통 인프라 사실을 다루기 때문입니다.
diff --git a/journey/troubleshooting/2026-03-03_51123_DB5432_차단사고_복구_및_의존포트_점검.md b/journey/troubleshooting/2026-03-03_51123_DB5432_차단사고_복구_및_의존포트_점검.md
index 362946b..70915e4 100644
--- a/journey/troubleshooting/2026-03-03_51123_DB5432_차단사고_복구_및_의존포트_점검.md
+++ b/journey/troubleshooting/2026-03-03_51123_DB5432_차단사고_복구_및_의존포트_점검.md
@@ -1,140 +1,7 @@
-# 51123 DB 5432 차단 사고 복구 및 의존 포트 점검
+# 2026-03-03_51123_DB5432_차단사고_복구_및_의존포트_점검
 
-## 발생 일시
-- 장애 징후 시작: 2026-03-03 10:59 KST 전후
-- 원인 확인/복구: 2026-03-03 11:18~11:22 KST
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
-## 문제 요약
-- 51124의 `skill-email`이 `192.168.219.45:5432` 연결 타임아웃으로 `ReadTimeout/500`을 반환.
-- 앱 로직 문제가 아니라 DB 접속 경로(포트 5432) 차단으로 인한 네트워크 레벨 장애.
-
-## 직접 원인
-- 2026-03-03 오전 포트 하드닝 작업 중, UFW의 `5432/tcp` 외부 허용 규칙을 제거함.
-- 이때 51124(`192.168.219.52`)의 DB 직접 접근도 함께 차단됨.
-
-## 사실 확인 (51123)
-1. PostgreSQL 리스닝: 정상
-- `ss -lntp` 결과: `0.0.0.0:5432`, `[::]:5432` LISTEN
-
-2. PostgreSQL 설정: 원격 수신 가능
-- `postgresql.conf`: `listen_addresses='*'`, `port=5432`
-- `pg_hba.conf`: `host all all 0.0.0.0/0 scram-sha-256`
-
-3. 방화벽: 장애 시점 기준 5432 허용 누락
-- `ufw status`에서 `5432` 허용 규칙이 없었음
-
-## 조치
-- 최소권한 원칙으로 51124 IP만 5432 허용 재개:
-
-```bash
-sudo ufw allow from 192.168.219.52 to any port 5432 proto tcp
-```
-
-## 복구 검증
-1. 네트워크
-- 51124 -> 51123 포트 테스트:
-  - `5432 open` (복구)
-  - `3000 blocked`, `7474 blocked` (의도된 차단 유지)
-  - `7687/9000/8100/8000/9200 open`
-
-2. 컨테이너 내부
-- `skill-email` 컨테이너에서 `192.168.219.45:5432` TCP 연결 성공 (`tcp_ok`).
-- `skill-email` 컨테이너에서 `asyncpg`로 `select 1` 성공 (`asyncpg_ok 1`).
-
-3. 서비스
-- `rb8001 /health` 정상(`200`).
-- 장애 핵심 경로였던 DB 접속 타임아웃은 네트워크 기준 해소.
-
-## 분리 이슈 (별도 추적 필요)
-- 복구 후에도 `skill-email`의 `/messages`, `/messages/{id}` 일부 호출에서 `500`이 재현됨.
-- 근거:
-  - DB 네트워크/인증/쿼리 기본 경로는 정상(`5432 open`, `asyncpg_ok 1`).
-  - 그럼에도 `docker logs skill-email`에 `메시지 조회 중 오류`/`메시지 상세 조회 중 오류`가 지속.
-- 판단: 이번 5432 차단 사고와는 별개의 애플리케이션 레이어 오류 가능성이 높음.
-
-## 분리 이슈 최종 판정 (2026-03-03 11:40 KST)
-- 위 "별도 앱 오류"로 분리했던 건 오판이었고, 실제로는 같은 5432 방화벽 영향이었다.
-- auth-server 컨테이너 DB 설정:
-  - `DATABASE_URL=postgresql://robeings:robeings@host.docker.internal:5432/main_db`
-- 당시 UFW는 `5432`를 `192.168.219.52`만 허용해서, Docker 브리지(172.17/18/20/21 대역)에서 들어오는 auth-server DB 연결이 차단됨.
-- 결과적으로 `auth-server /auth/naverworks/passport/refresh`에서 `asyncpg.connect` `TimeoutError`가 발생했고, 이를 호출하던 `skill-email /messages*`가 연쇄 500.
-
-### 추가 조치 (최종 복구)
-```bash
-sudo ufw allow from 172.16.0.0/12 to any port 5432 proto tcp
-```
-
-### 최종 검증
-- `auth-server` 컨테이너 내부 DB 테스트: `auth_db_ok 1`
-- `http://127.0.0.1:9000/auth/naverworks/passport/refresh` 호출: 타임아웃 미발생(즉시 405 반환, 경로 응답 정상)
-- 51124 `skill-email` 호출:
-  - `GET /messages?provider=naverworks&user_id=...&limit=3` -> `200 OK` (약 0.54s)
-
-## 영향 범위 점검 결과 (51124 -> 51123 의존)
-다음 서비스/환경변수들이 `192.168.219.45:5432`를 사용 중:
-- `skill_email`
-- `skill-calendar`
-- `skill-news`
-- `skill-rag-file`
-- `rb8001`
-- `robeing-monitor`
-- 일부 `admin-dashboard` 구성(호스트 브리지 기반)
-
-즉, 5432 차단 시 `skill-email`만이 아니라 위 서비스 전반에서 동일 장애 가능.
-
-실행중 컨테이너 환경변수 점검 결과(2026-03-03 11:22 KST):
-- `rb8001`: `5432`, `7687`, `9000`, `8100` 의존
-- `skill-email`: `5432`, `9000` 의존
-- `skill-calendar`, `skill-slack`, `skill-rag-file`, `robeing_monitor`: `5432` 의존
-- `admin-dashboard-backend`: `172.17.0.1:5432` 의존(호스트 브리지)
-
-## 재발 방지
-1. 포트 하드닝 전 의존성 체크 필수
-- 51124에서 `192.168.219.45:<port>` 참조를 `.env`/`compose`에서 선조회
-
-2. 변경 절차 고정
-- `차단 전`: 의존 포트 목록 작성
-- `차단 직후`: 51124 원격 TCP 매트릭스 테스트
-- `완료 전`: 핵심 서비스 헬스 + 최근 오류로그 교차 확인
-
-3. UFW 정책 원칙
-- 전면 허용(`Anywhere`) 대신 **의존 출발지 단위 최소 허용**으로 운영
-- `5432`는 최소 `192.168.219.52` + Docker 브리지 `172.16.0.0/12`를 포함해야 함
-
-## 운영 보강: 서버별 마운트 아키텍처 분기
-NAS 관련 장애 점검은 51123/51124가 서로 다른 구조임을 전제로 수행해야 함.
-
-- 51123: NAS/fallback 구조
-  - `/mnt/nas`, `/mnt/hdd/nas-fallback`
-  - `/etc/fstab`에 CIFS 항목(`//192.168.219.51/home /mnt/nas cifs ...`)
-- 51124: sshfs 연계 구조
-  - `/mnt/51123data`, `/mnt/51123logs` (sshfs)
-  - NAS CIFS/fallback 항목 없음
-
-즉, 같은 NAS 불통이어도 "경로가 다르다"는 사실 자체는 장애가 아니라 서버별 아키텍처 차이임.
-
-### NAS 실패 판정 규칙
-- `No route to host`와 `Timeout`은 둘 다 **연결 실패**로 동일 분류한다.
-- 에러 문구 차이는 시점/라우팅 상태에 따라 달라질 수 있으므로, 원인 분류 키로 사용하지 않는다.
-
-### 완료 전 필수 게이트 (고정)
-1. 컨테이너 env 기반 의존성 스캔
-2. 51124 -> 51123 포트 매트릭스 (`5432/9000/8100/7687`)
-3. 핵심 API 실호출
-   - `auth-server /auth/naverworks/passport/refresh`
-   - `skill-email /messages*`
-4. 서버별 스토리지 분기 점검
-   - 51123: NAS/fallback 경로
-   - 51124: sshfs 경로
-
-## 명령어 체크리스트
-```bash
-# 51123
-ss -lntp | grep 5432
-sudo ufw status numbered
-
-# 51124에서 51123 연결 점검
-for p in 5432 3000 7474 7687 9000 8100 8000 9200; do
-  timeout 2 bash -lc "cat < /dev/null > /dev/tcp/192.168.219.45/$p" && echo "$p open" || echo "$p blocked"
-done
-```
+- 새 위치: `260303_51123_DB5432_차단사고_복구_및_의존포트_점검.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/260303_51123_DB5432_차단사고_복구_및_의존포트_점검.md>
+- 이유: 23/24/NAS, 게이트웨이, 배포, 네트워크, 백업, 마운트 등 공통 인프라 사실을 다루기 때문입니다.
diff --git a/journey/troubleshooting/2026-03-03_51123_ufw_외부포트_차단_하드닝.md b/journey/troubleshooting/2026-03-03_51123_ufw_외부포트_차단_하드닝.md
index 651d825..dca1535 100644
--- a/journey/troubleshooting/2026-03-03_51123_ufw_외부포트_차단_하드닝.md
+++ b/journey/troubleshooting/2026-03-03_51123_ufw_외부포트_차단_하드닝.md
@@ -1,70 +1,7 @@
-# 51123 서버 UFW 외부 포트 차단 하드닝
+# 2026-03-03_51123_ufw_외부포트_차단_하드닝
 
-## 발생 일시
-2026-03-03 10:43~10:53 KST
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
-## 배경
-외부 공개 포트 점검 중, 운영 원칙(외부는 80/443 + 관리 SSH만 공개) 대비 과다 노출이 확인됨.
-
-## 확인된 원인
-- UFW에서 아래 포트가 `Anywhere`/`Anywhere (v6)`로 허용되어 있었음.
-  - `5432/tcp` (PostgreSQL)
-  - `3000/tcp` (Gitea 직접 포트)
-  - `7474/tcp` (Neo4j HTTP)
-- 이 상태는 도메인/nginx 경유가 아닌 직접 포트 접근 경로를 열어두는 구성임.
-
-## 조치 내용
-실서버(51123)에서 아래 명령으로 공개 허용 규칙 제거:
-
-```bash
-sudo ufw --force delete allow 5432/tcp
-sudo ufw --force delete allow 3000/tcp
-sudo ufw --force delete allow 7474/tcp
-```
-
-## 검증 결과
-조치 직후 실시간 검증:
-
-- 도메인 응답
-  - `https://ro-being.com` → `HTTP/2 200`
-  - `https://git.ro-being.com` → `HTTP/2 200`
-  - `https://auth.ro-being.com` → `HTTP/2 404` (기존 동작 동일)
-- 내부 서비스 헬스
-  - `http://127.0.0.1:9000/health` → `200`
-  - `http://127.0.0.1:8000/health` → `200`
-- UFW 규칙
-  - `5432/3000/7474`의 `Anywhere`, `Anywhere (v6)` 허용 규칙 삭제 확인
-
-## 영향도
-- 사용자 도메인 경유 트래픽 영향 없음
-- `git.ro-being.com` 기반 Gitea 사용 영향 없음
-- 직접 포트 우회 접근 경로만 차단됨
-
-## 현재 공개 정책(2026-03-03 기준)
-- 외부 공개 유지: `80/tcp`, `443/tcp`, `51123/tcp(관리 SSH)`
-- 내부/제한 네트워크 허용: `7687`, `7474(172.17.0.0/16)`
-
-## 후속 권장
-- Docker 퍼블리시 포트(`8000/8100/8200/9000/9200/9600`)의 외부 노출 축소(가능한 `127.0.0.1` 또는 내부 네트워크만 사용)
-- PostgreSQL `listen_addresses`, `pg_hba.conf`를 내부 대역 기반으로 추가 제한
-
-## 사후 정정 (2026-03-03 11:40 KST)
-초기 차단 조치만으로는 충분하지 않았고, 실제 운영 의존 경로를 일부 누락한 상태였다.
-
-- 누락된 의존 경로:
-  - 51124 직접 경로: `192.168.219.52 -> 51123:5432`
-  - Docker 브리지 경로: `172.16.0.0/12 -> 51123:5432` (예: auth-server `host.docker.internal:5432`)
-- 결과:
-  - `auth-server /auth/naverworks/passport/refresh` 타임아웃
-  - `skill-email /messages*` 연쇄 500
-
-복구 시 최종 반영한 규칙:
-
-```bash
-sudo ufw allow from 192.168.219.52 to any port 5432 proto tcp
-sudo ufw allow from 172.16.0.0/12 to any port 5432 proto tcp
-```
-
-최종 정책(정정):
-- "5432는 무조건 전체 차단"이 아니라, **실제 의존 출발지 단위 최소 허용**이 원칙.
-- 하드닝 변경 시 반드시 컨테이너 env 기반 의존성 스캔 + 변경 직후 연계 API 실호출을 완료해야 한다.
+- 새 위치: `260303_51123_ufw_외부포트_차단_하드닝.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/260303_51123_ufw_외부포트_차단_하드닝.md>
+- 이유: 23/24/NAS, 게이트웨이, 배포, 네트워크, 백업, 마운트 등 공통 인프라 사실을 다루기 때문입니다.
diff --git a/journey/troubleshooting/2026-03-05_51124_다운_상태_및_복구예정.md b/journey/troubleshooting/2026-03-05_51124_다운_상태_및_복구예정.md
index a31ca6a..9608e00 100644
--- a/journey/troubleshooting/2026-03-05_51124_다운_상태_및_복구예정.md
+++ b/journey/troubleshooting/2026-03-05_51124_다운_상태_및_복구예정.md
@@ -1,9 +1,7 @@
-# 2026-03-05 51124 다운 상태 및 복구 예정
+# 2026-03-05_51124_다운_상태_및_복구예정
 
-- 기준일: 2026-03-05
-- 대상 서버: 51124 (192.168.219.52)
-- 현재 상태: 다운(미가동)
-- 복구 계획일: 2026-03-06
-- 임시 운영 상태: 51123에서 robeing 임시 가동 중 (rb8001, skill 계열)
-- 원래 실행 위치: 51124 (robeing/skill 실행 서버)
-- 비고: 본 상태/일정은 사용자 운영 지시 기준으로 기록함
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
+
+- 새 위치: `260305_51124_다운_상태_및_복구예정.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/260305_51124_다운_상태_및_복구예정.md>
+- 이유: 23/24/NAS, 게이트웨이, 배포, 네트워크, 백업, 마운트 등 공통 인프라 사실을 다루기 때문입니다.
diff --git a/journey/troubleshooting/260226_51123_SSH_브루트포스_차단_및_fail2ban_교정.md b/journey/troubleshooting/260226_51123_SSH_브루트포스_차단_및_fail2ban_교정.md
index c75fcc8..7610d25 100644
--- a/journey/troubleshooting/260226_51123_SSH_브루트포스_차단_및_fail2ban_교정.md
+++ b/journey/troubleshooting/260226_51123_SSH_브루트포스_차단_및_fail2ban_교정.md
@@ -1,35 +1,7 @@
-# 260226 51123 SSH 브루트포스 차단 및 fail2ban 교정
+# 260226_51123_SSH_브루트포스_차단_및_fail2ban_교정
 
-## 시간
-- 기준일: 2026-02-26
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
-## 배경
-- 51123 SSH(포트 51123)로 무차별 대입 시도가 대량 유입됨
-- 집계 기준(당일): `Failed password 56,613`, `Invalid user 48,030`
-
-## 조치
-1. UFW 수동 차단
-- 허용(관리자 예외): `112.146.113.214`, `220.85.143.128`
-- 차단(반복 실패 상위): `134.209.249.168`, `164.92.167.107`, `209.38.245.39`
-
-2. fail2ban 설정 교정
-- 파일: `/etc/fail2ban/jail.d/ssh-custom.conf`
-- 핵심 변경:
-  - `port = 51123` (기존 `ssh` 포트 기본값 의존 제거)
-  - `ignoreip = 127.0.0.1/8 ::1 192.168.219.0/24 112.146.113.214 220.85.143.128`
-  - `sshd`: `maxretry=5`, `findtime=600`, `bantime=86400`
-  - `sshd-aggressive`: `maxretry=3`, `findtime=300`, `bantime=604800`
-
-3. 서비스 반영
-- `systemctl restart fail2ban`
-- `fail2ban-client status`로 `sshd`, `sshd-aggressive` 정상 활성 확인
-
-## 확인 결과
-- fail2ban 재시작 후 양쪽 jail에서 실시간 차단 동작 확인
-- 화이트리스트 IP는 수동 `unbanip` 실행으로 차단 예외 재확인
-- SSH 설정은 `Port 51123`, `PermitRootLogin no`, `PasswordAuthentication yes` 상태
-
-## 후속 권장
-1. 가능하면 `PasswordAuthentication no`로 전환(키 기반만 허용)
-2. 비상 접속 계정 1개만 비밀번호 허용 + 소스 IP 제한
-3. 월 1회 `fail2ban`/`ufw` 룰 정리 및 화이트리스트 검증
+- 새 위치: `260226_51123_SSH_브루트포스_차단_및_fail2ban_교정.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/260226_51123_SSH_브루트포스_차단_및_fail2ban_교정.md>
+- 이유: 23/24/NAS, 게이트웨이, 배포, 네트워크, 백업, 마운트 등 공통 인프라 사실을 다루기 때문입니다.
diff --git a/journey/troubleshooting/260226_51124_bot_account_compromise_and_eradication.md b/journey/troubleshooting/260226_51124_bot_account_compromise_and_eradication.md
index cc28a7e..08a1d0b 100644
--- a/journey/troubleshooting/260226_51124_bot_account_compromise_and_eradication.md
+++ b/journey/troubleshooting/260226_51124_bot_account_compromise_and_eradication.md
@@ -1,76 +1,7 @@
-# 51124 bot 계정 SSH 침해 대응 및 박멸 기록
+# 260226_51124_bot_account_compromise_and_eradication
 
-**날짜**: 2026-02-26
-**작성자**: admin
-**관련 파일**: `/var/log/auth.log*`, `/home/bot/.configrc7/*`, `/var/spool/cron/crontabs/bot`
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
----
-
-## 문제 상황
-- 51124 서버에서 비정상 고메모리 프로세스(`kauditd0`) 발견
-- 실체 확인 결과 `/home/bot/.configrc7/a/kswapd00` 실행 파일로 위장 동작
-- `bot` crontab에 재실행 지속성(`*/30 * * * * /tmp/.kswapd00 || /home/bot/.configrc7/a/kswapd00`) 존재
-
-## 침해 지표(IOC)
-- 프로세스/파일
-  - `kauditd0`, `kswapd00`, `edac0`
-  - `/home/bot/.configrc7/a/*`, `/home/bot/.configrc7/b/*`
-  - `/tmp/.kswapd00`, `/tmp/.X28-unix/.rsync/c/aptitude`
-- SSH/지속성
-  - `~/.ssh/authorized_keys`에 `mdrfckr` 주석의 `ssh-rsa` 키 주입 흔적
-  - `chattr +/-ia`를 이용한 `.ssh` 잠금 시도
-- 네트워크
-  - 공격 유입 성공 IP: `179.43.139.82`
-  - 감염 프로세스 외부 연결 IP: `179.43.139.85:80`
-
-## 로그 기반 사실 확인
-- `2026-02-18 18:46:05 KST`: `Accepted password for bot from 179.43.139.82`
-- `2026-02-18 18:54:06 KST`: `Accepted password for bot from 179.43.139.82`
-- `root` 계정 `Accepted` 로그인 성공 기록은 보관 로그 기준 미검출
-- `admin` 계정은 정상 운영 접속으로 보이는 `Accepted` 기록 다수 존재
-
-## 원인 판정
-- SSH 비밀번호 인증 허용 상태(`passwordauthentication yes`)에서 `bot` 계정 비밀번호 기반 침입 성공
-- `bot` 계정이 `sudo`/`docker` 권한 보유(`sudo ALL`) 상태여서 감염 스크립트 설치 및 지속성 확보가 가능했던 구조
-
-## 조치 내역
-1. 악성 프로세스 종료
-   - `kauditd0/kswapd00/edac0` 관련 프로세스 킬
-2. 지속성 제거
-   - `crontab -u bot -r`로 `bot` 사용자 크론 제거
-3. 악성 파일 제거
-   - `/home/bot/.configrc7`, `/tmp/.kswapd00`, `/tmp/.X28-unix/.rsync` 삭제
-4. 백도어 키 제거
-   - `/home/bot/.ssh/authorized_keys`의 `mdrfckr` 키 제거
-   - 백업: `/home/bot/.ssh/authorized_keys.bak.20260226212628`
-5. 계정 비밀번호 교체
-   - `2026-02-26` 기준 `admin`, `root`, `bot` 비밀번호 변경 완료
-
-## 검증 결과
-- `kauditd0/kswapd00/edac0` 프로세스 미검출
-- `bot` crontab 미존재 확인
-- IOC 경로(`/home/bot/.configrc7`, `/tmp/.kswapd00`, `/tmp/.X28-unix/.rsync`) 미존재 확인
-- `mdrfckr` 키 미검출 확인
-- 서비스 영향 없음: `docker ps` 전체 `Up`, `curl http://localhost:8001/health` HTTP 200
-
-## 남은 리스크
-- 보관 로그 한계로 과거 데이터 조회/유출 여부를 100% 확정할 수 없음
-- `bot` 계정으로 읽기 접근된 비밀값(API 키, 토큰, DB 접속정보)은 노출 가능성 배제 불가
-
-## 후속 권고
-1. SSH 하드닝
-   - `PasswordAuthentication no`
-   - `AllowUsers admin` 등 접속 사용자 제한
-2. 계정 정리
-   - `bot` 계정 업무 불필요 시 잠금(`usermod -L`) 또는 삭제
-   - `sudo`/`docker` 최소 권한 재설계
-3. 비밀값 로테이션
-   - `.env` 기반 토큰/Gitea 토큰/외부 API 키 전면 교체
-4. 모니터링 강화
-   - `auth.log`의 `Accepted password` 이상 탐지 알림
-   - 크론/시스템 서비스 신규 등록 이벤트 모니터링
-
-## 교훈
-- 비밀번호 SSH 허용 + 고권한 사용자 조합은 자동화 봇넷 침해에 매우 취약함
-- 박멸은 `프로세스 종료`만으로 끝나지 않고 `크론/파일/SSH 키`까지 함께 제거해야 재감염을 막을 수 있음
-- 침해 대응 후에는 서비스 정상 여부(`docker ps`, healthcheck)와 보안 후속조치를 같은 작업 단위로 처리해야 함
+- 새 위치: `260226_51124_bot_account_compromise_and_eradication.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/260226_51124_bot_account_compromise_and_eradication.md>
+- 이유: 23/24/NAS, 게이트웨이, 배포, 네트워크, 백업, 마운트 등 공통 인프라 사실을 다루기 때문입니다.
diff --git a/journey/troubleshooting/260226_51124_openclaw_gateway_상주프로세스_정리.md b/journey/troubleshooting/260226_51124_openclaw_gateway_상주프로세스_정리.md
index 3ce11f9..408d868 100644
--- a/journey/troubleshooting/260226_51124_openclaw_gateway_상주프로세스_정리.md
+++ b/journey/troubleshooting/260226_51124_openclaw_gateway_상주프로세스_정리.md
@@ -1,38 +1,7 @@
-# 51124 openclaw-gateway 상주 프로세스 정리
+# 260226_51124_openclaw_gateway_상주프로세스_정리
 
-**날짜**: 2026-02-26
-**작성자**: admin
-**관련 파일**: `/home/admin/.nvm/versions/node/v24.4.0/lib/node_modules/openclaw/package.json`, `/proc/1127450/*`
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
----
-
-## 문제 상황
-- 메모리 상위 프로세스 점검 중 `openclaw-gateway`(PID 1127458) 발견
-- 51124 운영 대상 서비스 목록(AGENTS.md)에는 `openclaw`가 포함되지 않아 비관리 상주 프로세스로 판단
-- 장기 상주 상태로 메모리 점유 및 운영 혼선 가능성 존재
-
-## 사실 확인
-- 시작 시각: `2026-02-05 09:33:48 KST` (`ps -o lstart` 기준)
-- 실행 주체: `admin` 계정 SSH 세션(`session-60400.scope`, `SSH_CLIENT=192.228.158.63`)
-- 실행 형태: systemd 서비스/크론 등록 없음, 수동 실행 후 orphan 상주
-- 프로세스 체인: `systemd(1) -> openclaw(PID 1127450) -> openclaw-gateway(PID 1127458)`
-- 패키지 정체: npm 글로벌 `openclaw@2026.2.2-3` (`description: WhatsApp gateway CLI ...`)
-
-## 해결 방안
-1. 비관리 프로세스 종료
-   - `pkill -f '^openclaw$'`
-   - `pkill -f 'openclaw-gateway'`
-2. 잔여 프로세스/포트 검증
-   - `ps`, `pgrep`, `ss -tlnp` 재확인으로 `openclaw` 관련 미검출 확인
-3. 리소스 재확인
-   - 종료 전후 메모리 비교에서 `free/available` 증가, swap 사용량 감소 확인
-
-## 검증 결과
-- `openclaw`, `openclaw-gateway` 프로세스 미검출
-- openclaw 관련 리슨 포트 미검출
-- 운영 필수 컨테이너(`rb8001`, `skill-*`, `robeing_monitor`) 영향 없음
-
-## 교훈
-- 운영 대상 외 프로세스는 발견 즉시 실행 주체/시작 시각/자동실행 경로(systemd·cron)까지 함께 확인해야 함
-- 비관리 상주 프로세스는 종료 후 반드시 `ps/pgrep/ss` 3중 검증으로 잔존 여부를 확인해야 함
-- 운영 문서(DOCS)에 즉시 기록해 동일 유형 이슈 재발 시 판단 시간을 단축해야 함
+- 새 위치: `260226_51124_openclaw_gateway_상주프로세스_정리.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/260226_51124_openclaw_gateway_상주프로세스_정리.md>
+- 이유: 23/24/NAS, 게이트웨이, 배포, 네트워크, 백업, 마운트 등 공통 인프라 사실을 다루기 때문입니다.
diff --git a/journey/troubleshooting/260226_NAS_192_168_219_51_접속불가_임시백업복구.md b/journey/troubleshooting/260226_NAS_192_168_219_51_접속불가_임시백업복구.md
index b5ee469..0dc65eb 100644
--- a/journey/troubleshooting/260226_NAS_192_168_219_51_접속불가_임시백업복구.md
+++ b/journey/troubleshooting/260226_NAS_192_168_219_51_접속불가_임시백업복구.md
@@ -1,40 +1,7 @@
-# 260226 NAS(192.168.219.51) 접속불가 임시 백업 복구
+# 260226_NAS_192_168_219_51_접속불가_임시백업복구
 
-## 시간
-- 기준일: 2026-02-26
-- 발생 시각: 2026-02-26 20:4x KST
-- 임시 복구 완료: 2026-02-26 20:55 KST
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
-## 증상
-- `51123`에서 `/mnt/nas` 접근 시 `Host is down` 발생
-- `192.168.219.51`에 `ping` 100% 손실
-- SMB(445) 접근 시 `No route to host`
-
-## 원인 판정
-- `51123`/`51124` 양쪽에서 동일하게 `192.168.219.51` 불통 확인
-- 로컬 서버(51123) 네트워크 자체는 정상(`192.168.219.1`, `192.168.219.52` 통신 정상)
-- 판정: 서버 로컬 이슈가 아니라 NAS 전원/링크/스위치 구간 장애 가능성 높음
-
-## 즉시 조치 (백업 공백 방지)
-1. 기존 `/mnt/nas` 마운트 해제
-2. 로컬 대체 경로 생성: `/mnt/hdd/nas-fallback/backup/{weekly,current,archives}`
-3. bind 마운트 적용: `/mnt/hdd/nas-fallback` -> `/mnt/nas`
-4. `weekly-backup.sh` 수동 실행으로 동작 검증
-
-## 검증 결과
-- `/mnt/nas/backup/weekly/20260226` 생성 확인
-- `weekly-backup-20260226.log` 기준 백업 완료 크기: `30M`
-- 임시 상태에서 주간 백업 크론 경로(`/mnt/nas/backup/weekly`) 정상 유지
-
-## 원복 절차 (NAS 복구 후)
-1. NAS(192.168.219.51) 통신 복구 확인 (`ping`, SMB 445)
-2. `sudo umount /mnt/nas`
-3. `sudo mount /mnt/nas` (fstab의 CIFS 원마운트 복귀)
-4. `/mnt/nas/backup` 실제 NAS 경로 접근 확인
-5. 임시 데이터(`/mnt/hdd/nas-fallback/backup`)를 NAS로 동기화 후 정리
-
-## 참고
-- 기존 NAS 백업 체계 문서: `./250729_서버백업및로그관리체계구축.md`
-
-## 후속 문서
-- 다음 단계: [260307_NAS_192_168_0_101_SSOT_전환_및_CIFS_실마운트_복구](./260307_NAS_192_168_0_101_SSOT_전환_및_CIFS_실마운트_복구.md)
+- 새 위치: `260226_NAS_192_168_219_51_접속불가_임시백업복구.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/260226_NAS_192_168_219_51_접속불가_임시백업복구.md>
+- 이유: 23/24/NAS, 게이트웨이, 배포, 네트워크, 백업, 마운트 등 공통 인프라 사실을 다루기 때문입니다.
diff --git a/journey/troubleshooting/260303_51123_gateway_rb8001_연결점검_23서버_전달사항.md b/journey/troubleshooting/260303_51123_gateway_rb8001_연결점검_23서버_전달사항.md
index 7bc47af..81e8b96 100644
--- a/journey/troubleshooting/260303_51123_gateway_rb8001_연결점검_23서버_전달사항.md
+++ b/journey/troubleshooting/260303_51123_gateway_rb8001_연결점검_23서버_전달사항.md
@@ -1,56 +1,7 @@
-# 23 서버 전달사항: 게이트웨이-8001 연결 점검 결과
+# 260303_51123_gateway_rb8001_연결점검_23서버_전달사항
 
-**날짜**: 2026-03-03  
-**작성자**: Codex  
-**관련 파일**: `robeing-gateway/app/main.py`, `robeing-gateway/app/routers/slack.py`, `robeing-gateway/app/services/slack_proxy.py`
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
----
-
-## 문제 상황
-- 요청사항: `51124 rb8001(8001) 배포본`이 `51123 robeing-gateway(8100)`를 통해 계획대로 전달되는지 확인.
-- 제약: `수정금지` 조건으로 코드/설정 변경 없이 확인만 수행.
-
-## 확인한 사실
-- 게이트웨이 상태
-  - `robeing-gateway` 컨테이너: `Up (healthy)`
-  - `GET /healthz`: `200 {"status":"ok"}`
-- 게이트웨이 대상 설정
-  - 컨테이너 환경변수: `ROBEING_DEFAULT_HOST=192.168.219.52`, `ROBEING_DEFAULT_PORT=8001`, `ROBEING_DEFAULT_ID=rb8001`
-- Run ID 전파 구현
-  - `app/main.py`의 `/api/chat`에서 `X-Run-Id` 생성/전달 및 응답 `run_id` 기본값 주입 확인
-  - `app/routers/slack.py` + `app/services/slack_proxy.py`에서 `X-Run-Id` 헤더 생성/전달 확인
-
-## 핵심 점검 결과
-- 아키텍처 적합성(게이트웨이 단일 진입) 관점에서 **부분 불일치** 확인.
-- 근거:
-  - 게이트웨이 범용 프록시는 `GET /api/{path:path}`만 존재 (`robeing-gateway/app/main.py`)
-  - 계획 핵심 신규 API는 `POST` 중심 (`/api/self-improvement/*`, `/api/prompt-db/*`)
-  - 실제 호출 결과:
-    - `POST /api/self-improvement/runs` -> `405 Method Not Allowed (allow: GET)`
-    - `POST /api/prompt-db/templates` -> `405 Method Not Allowed (allow: GET)`
-    - `POST /api/self-improvement/policy-versions` -> `405 Method Not Allowed (allow: GET)`
-- 대조 확인:
-  - 동일 경로를 rb8001(192.168.219.52:8001)로 직접 호출 시 `401 Unauthorized` 반환
-  - 즉, rb8001 경로 자체는 존재하며 인증이 필요한 상태이고, 게이트웨이에서 먼저 `POST`가 차단되고 있음.
-
-## 부가 관찰
-- Slack 검증 스크립트 실행 시 등록 사용자 이벤트가 `403` 발생.
-- 게이트웨이 로그에서 `No bot token found`, `No UUID found`가 함께 관찰됨.
-- 이 항목은 신규 self-improvement/prompt-db 경로 이슈와 별개로, Slack 사용자 매핑/토큰 데이터 상태 점검이 필요함.
-
-## 24서버 전달사항 (rb8001 측 확인 결과)
-- `rb8001` 현재 배포 커밋: `54f74d70fc7f2e72368a1ca081d0f52a8dfcba2b` (`Up (healthy)` 확인).
-- 신규 경로 존재 확인:
-  - `POST /api/self-improvement/policy-versions`
-  - `POST /api/self-improvement/runs`
-  - `POST /api/prompt-db/templates`, `.../versions`, `.../activate/...`, `POST /api/prompt-db/events`
-- DB 테이블 상태:
-  - `robeing_self_improvement_runs`, `robeing_policy_versions`, `prompt_templates`, `prompt_versions`, `prompt_events`, `prompt_metrics_daily` 모두 생성됨.
-  - API 직접 호출 시 `self_improvement_runs`/`prompt_events` 적재 정상 확인.
-- 유의사항:
-  - 현재 `/api/message` 호출만으로는 `run_id` 기준 `self_improvement_runs`/`prompt_events` 자동 적재가 연결되지 않음.
-  - 즉, 현재 기준 자기개선 루프 적재는 API 수동 호출 경로는 동작, 메시지 E2E 자동 폐루프는 미연결 상태.
-
-## 교훈
-- `51123 gateway`가 단일 진입점인 구조에서는 신규 백엔드 API가 추가될 때 `HTTP method(특히 POST/PUT/DELETE)`까지 포함한 프록시 경로를 동시에 열어야 한다.
-- `직접 upstream 성공`과 `gateway 경유 성공`은 별도 검증 항목이므로 배포 완료 판단 전에 둘 다 확인해야 한다.
+- 새 위치: `260303_51123_gateway_rb8001_연결점검_23서버_전달사항.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/260303_51123_gateway_rb8001_연결점검_23서버_전달사항.md>
+- 이유: 23/24/NAS, 게이트웨이, 배포, 네트워크, 백업, 마운트 등 공통 인프라 사실을 다루기 때문입니다.
diff --git a/journey/troubleshooting/260304_51123_임시복구_서비스연속성_조치내역.md b/journey/troubleshooting/260304_51123_임시복구_서비스연속성_조치내역.md
index a2f82aa..a3dc245 100644
--- a/journey/troubleshooting/260304_51123_임시복구_서비스연속성_조치내역.md
+++ b/journey/troubleshooting/260304_51123_임시복구_서비스연속성_조치내역.md
@@ -1,116 +1,7 @@
-# 260304 51123 임시복구 서비스 연속성 조치내역
+# 260304_51123_임시복구_서비스연속성_조치내역
 
-## 1. 목적
-- 51124 서버 장애 상황에서 51123 단독으로 robeing 핵심 서비스 연속성을 임시 복구한다.
-- 2026-03-04 기준, 내일(2026-03-05) 오전 9시~10시 일정/이메일 경로 중단을 방지한다.
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
-## 2. 장애 징후 및 운영 영향
-- `/api/message` 응답이 3초 제한 내 타임아웃(`HTTP:000`, `curl (28)`)으로 실패.
-- 게이트웨이 경유 일부 경로에서 422/500이 혼재되어 호출 신뢰도가 저하.
-- PostgreSQL 연결 슬롯 고갈(Idle 세션 누적)로 신규 작업 지연.
-- 51124 불가 상태로 기존 이중서버 가정(23 인프라 + 24 실행)이 깨짐.
-
-## 3. 확인된 근본 원인
-1. Docker 브리지 대역(`172.21.0.0/16`)에서 호스트 포트(8001, 9024, 8512) 접근이 방화벽에 막혀 내부 연계가 단절됨.
-2. PostgreSQL Idle 세션 누적으로 커넥션 풀 여유가 줄어 응답 지연이 증폭됨.
-3. rb8001 런타임에서 고비용 경로(의도/검색 그래프 포함)가 활성화된 상태로 느린 경로가 잦게 호출됨.
-4. gateway 환경변수 일부가 운영 실IP 기준과 어긋나 헬스/검증 경로가 불안정했음.
-
-## 4. 실제 조치 내역(51123)
-### 4.1 네트워크/방화벽
-- UFW allow 규칙 추가:
-  - `from 172.21.0.0/16 to any port 8001 proto tcp`
-  - `from 172.21.0.0/16 to any port 9024 proto tcp`
-  - `from 172.21.0.0/16 to any port 8512 proto tcp`
-
-### 4.2 데이터베이스
-- Idle 커넥션 92건 정리(`pg_terminate_backend`)로 슬롯 회복.
-- 즉시 재접속 정상화 확인.
-
-### 4.3 rb8001 성능 안전모드(임시)
-- `/home/admin/rb8001/.env` 오버라이드 적용:
-  - `INTENT_ENGINE=v1`
-  - `INTENT_USE_LANGGRAPH=false`
-  - `INTENT_USE_COT=false`
-  - `WEB_SEARCH_USE_GRAPH=false`
-- 적용 방식: `docker compose down && docker compose up -d --build`
-
-### 4.4 gateway 운영값 정합화
-- `/home/admin/robeing-gateway/.env` 수정:
-  - `ROBEING_DEFAULT_HOST=192.168.219.45`
-  - `MONITOR_URL="http://192.168.219.45:9024"`
-- 적용 방식: `docker compose down && docker compose up -d --build`
-
-## 5. 검증 결과(2026-03-04)
-1. 컨테이너 상태
-- `robeing-gateway(8100)`, `rb8001(8001)`, `robeing_monitor(9024)`, `skill-calendar(8512)`, `skill-email(8501)` running 확인.
-
-2. 헬스/응답
-- gateway `/healthz` 200.
-- gateway `/api/message` 정상 응답 복구(측정 약 0.5~1.7초 구간).
-
-3. 핵심 기능
-- 일정성 문구 포함 메시지 요청 시 응답 정상.
-- `self-improvement`, `prompt-db`는 유효 스키마 요청에서 성공, 비유효 payload는 기대대로 422/500.
-
-4. 이메일 경로(내일 9~10시 핵심)
-- `skill-email` `/health` 200.
-- rb8001 컨테이너 -> skill-email 내부 호출 200.
-- NaverWorks 메일 리스트 API(실 UUID `3550cef6-63e1-4ceb-8802-a25c9d1c6917`) 200, 목록 수신 확인.
-
-5. 스케줄 DB
-- `scheduled_jobs` 활성 항목 확인:
-  - `naverworks_daily`: `0 9 * * mon-fri`
-  - `coldmail_daily`: `5 9 * * mon-fri`
-  - `daily_headlines`: `10 9 * * mon-fri`
-  - `companyx_news`: `0 10 * * mon-fri`
-
-## 6. 잔여 리스크 및 운영 주의
-- `skill-embedding(8515)` 미기동 상태는 지속. rb8001 로그에 임베딩 연결 에러가 간헐적으로 남을 수 있음.
-- 현재 복구는 "핵심 연속성 확보" 기준의 임시 안정화이며, 51124 복구 후 원래 분리구조로 되돌리는 재배치가 필요.
-- 스케줄 실행 직전/직후(2026-03-05 08:55~10:10) 구간 모니터링을 강화해야 함.
-
-## 7. 24 서버 인계 메모
-- 51124 복구 후 우선순위:
-  1. rb8001/skill/chromadb 원복 배치
-  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` 위치가 비표준 구조라 안정성 점검 필요(후속 과제 분리).
+- 새 위치: `260304_51123_임시복구_서비스연속성_조치내역.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/260304_51123_임시복구_서비스연속성_조치내역.md>
+- 이유: 23/24/NAS, 게이트웨이, 배포, 네트워크, 백업, 마운트 등 공통 인프라 사실을 다루기 때문입니다.
diff --git a/journey/troubleshooting/260305_23임시배포_envdeploy_ssot_및_배포실패_근본원인_해결.md b/journey/troubleshooting/260305_23임시배포_envdeploy_ssot_및_배포실패_근본원인_해결.md
index de6fae7..c48d4f0 100644
--- a/journey/troubleshooting/260305_23임시배포_envdeploy_ssot_및_배포실패_근본원인_해결.md
+++ b/journey/troubleshooting/260305_23임시배포_envdeploy_ssot_및_배포실패_근본원인_해결.md
@@ -1,42 +1,7 @@
-# 260305 23임시배포 env.deploy SSOT 및 배포실패 근본원인 해결
+# 260305_23임시배포_envdeploy_ssot_및_배포실패_근본원인_해결
 
-**날짜**: 2026-03-05  
-**작성자**: Codex  
-**관련 파일**: `robeing/skill-rag-file/app/core/config.py`, `robeing/skill-rag-file/.gitea/workflows/deploy.yml`, `robeing/skill-embedding/config.py`, `robeing/robeing-monitor/.gitea/workflows/deploy.yml`
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
----
-
-## 문제 상황
-- 51124 다운 상태에서 51123 임시운영 중, 일부 스킬 배포가 반복 실패했다.
-- `skill-rag-file`, `skill-embedding`은 컨테이너 기동 직후 `ValidationError`로 헬스체크 실패가 발생했다.
-- `robeing-monitor`는 배포 스크립트 단계에서 권한 오류로 중단됐다.
-
-## 확인된 근본 원인
-1. `skill-rag-file`/`skill-embedding` 설정 모델이 `.env`의 추가 키를 허용하지 않아 런타임 시작이 실패했다.
-2. 워크플로우의 배포 경로가 서비스별 하드코딩 경로를 사용해 SSOT(`DEPLOY_PROJECT_DIR`)가 깨져 있었다.
-3. `robeing-monitor` 배포 스크립트의 `chmod 777 logs`가 실제 권한 정책과 충돌해 즉시 실패했다.
-
-## 해결 방안
-1. 설정 파서 수정(원인 직접 수정)
-- `skill-rag-file/app/core/config.py`: `SettingsConfigDict(..., extra="ignore")` 적용.
-- `skill-embedding/config.py`: `SettingsConfigDict(..., extra="ignore")` 적용.
-
-2. 배포 경로 SSOT 정리
-- `skill-rag-file/.gitea/workflows/deploy.yml`: `cd /home/admin/...` 하드코딩 제거, `DEPLOY_PROJECT_DIR` 사용으로 통일.
-- `robeing-monitor/.gitea/workflows/deploy.yml`: 하드코딩 경로 제거, `DEPLOY_PROJECT_DIR` 기반으로 통일.
-
-3. 권한 충돌 제거
-- `robeing-monitor/.gitea/workflows/deploy.yml`: 실패 원인인 `chmod 777 logs` 제거.
-
-## 검증 결과
-- `skill-embedding` 최신 커밋 `f89109c` 실행: Gitea Actions `task 2106` `Job succeeded`.
-- `skill-rag-file` 최신 커밋 `ddc4693` 실행: Gitea Actions `task 2107` `Job succeeded`.
-- `robeing-monitor` 최신 커밋 `c62794c` 실행: Gitea Actions `task 2108` `Job succeeded`.
-
-## 운영 결론
-- 51123 임시운영 기준 배포 실패 이슈는 해결 완료 상태다.
-- 51124 복구 시 코드 수정 없이 각 레포 `.env.deploy`의 배포 대상 값만 24 서버 값으로 전환하면 된다.
-
-## 교훈
-- 배포 실패는 폴백 추가보다 실패 지점의 단일 원인(설정/권한/경로)을 직접 수정해야 재발이 줄어든다.
-- 배포 경로는 서비스별 하드코딩이 아니라 `DEPLOY_PROJECT_DIR` 단일 기준으로 유지해야 운영 전환(23↔24)이 단순해진다.
+- 새 위치: `260305_23임시배포_envdeploy_ssot_및_배포실패_근본원인_해결.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/260305_23임시배포_envdeploy_ssot_및_배포실패_근본원인_해결.md>
+- 이유: 23/24/NAS, 게이트웨이, 배포, 네트워크, 백업, 마운트 등 공통 인프라 사실을 다루기 때문입니다.
diff --git a/journey/troubleshooting/260306_51123_gitea_lfs_permission_denied_502_복구.md b/journey/troubleshooting/260306_51123_gitea_lfs_permission_denied_502_복구.md
index 834b7ba..6260a13 100644
--- a/journey/troubleshooting/260306_51123_gitea_lfs_permission_denied_502_복구.md
+++ b/journey/troubleshooting/260306_51123_gitea_lfs_permission_denied_502_복구.md
@@ -1,44 +1,7 @@
-# 51123 Gitea LFS 권한 오류로 인한 git.ro-being.com 502 복구
+# 260306_51123_gitea_lfs_permission_denied_502_복구
 
-tags: [gitea, lfs, nas, recovery]
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
-**날짜**: 2026-03-06  
-**작성자**: admin  
-**관련 파일**: `/etc/gitea/app.ini`, `/etc/nginx/sites-enabled/default`
-
----
-
-## 문제 상황
-- 2026-03-06 19:04 KST 전후 `https://git.ro-being.com/` 접속 시 `HTTP/2 502` 발생.
-- nginx는 `git.ro-being.com`을 `http://localhost:3000/`으로 프록시 중이었고, upstream인 gitea가 비정상 상태였음.
-
-## 원인 확인
-1. 서비스 상태
-- `systemctl status gitea`에서 `failed (Result: exit-code)` 확인.
-
-2. gitea 로그
-- `journalctl -u gitea`에서 아래 치명 오류 반복 확인:
-  - `storage.Init failed: mkdir /mnt/nas/gitea-lfs: permission denied`
-- 19:04:28~19:04:31 KST 사이 재시작 반복 후 `Failed to start Gitea` 상태 진입.
-
-3. 설정 경로
-- `/etc/gitea/app.ini`에서 LFS 저장 경로가 `/mnt/nas/gitea-lfs`로 설정됨.
-
-## 복구 상태 확인
-- 2026-03-06 19:21:08 KST: `Started Gitea` 로그 확인.
-- 현재 `gitea.service`는 `active (running)` 상태.
-- 외부 검증: `curl -I https://git.ro-being.com/` 결과 `HTTP/2 200`.
-
-## 추가 관찰 사항
-- 현재 시점 확인 결과:
-  - `/mnt/nas`는 `findmnt /mnt/nas` 기준 `not-mounted`
-  - 디렉터리 권한은 `/mnt/nas`(root:root), `/mnt/nas/gitea-lfs`(git:git) 상태
-- 즉, gitea는 현재 경로 접근은 가능하지만 NAS 마운트 상태와 실제 저장 위치 일치 여부는 별도 운영 점검이 필요함.
-
-## 교훈
-- Gitea LFS가 NAS 경로를 사용하면, 서비스 기동 전 `마운트 상태 + 대상 디렉터리 소유권`이 동시에 만족되어야 함.
-- `502`만 보고 nginx 문제로 단정하면 오판 가능성이 높고, 반드시 `nginx(upstream) + systemd(gitea) + journal`을 같은 시각대로 교차 확인해야 함.
-- 스토리지 경로가 마운트 의존일 때는 마운트 해제/권한 변동 감시를 운영 체크리스트에 포함해야 함.
-
-## 후속 문서
-- 다음 단계: [260307_Gitea_LFS_NAS_권한정렬_및_실업로드_검증](./260307_Gitea_LFS_NAS_권한정렬_및_실업로드_검증.md)
+- 새 위치: `260306_51123_gitea_lfs_permission_denied_502_복구.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/260306_51123_gitea_lfs_permission_denied_502_복구.md>
+- 이유: 23/24/NAS, 게이트웨이, 배포, 네트워크, 백업, 마운트 등 공통 인프라 사실을 다루기 때문입니다.
diff --git a/journey/troubleshooting/260307_51123_성수이전_네트워크변경_운영기록.md b/journey/troubleshooting/260307_51123_성수이전_네트워크변경_운영기록.md
index d4d4b32..6219ce7 100644
--- a/journey/troubleshooting/260307_51123_성수이전_네트워크변경_운영기록.md
+++ b/journey/troubleshooting/260307_51123_성수이전_네트워크변경_운영기록.md
@@ -1,18 +1,7 @@
-# 260307 51123 서버 성수 이전 네트워크 변경 운영기록
+# 260307_51123_성수이전_네트워크변경_운영기록
 
-## 1. 배경
-- 51123 서버 운영 위치가 서울 양재에서 성수로 이전됨.
-- 이전 과정에서 공인 IP, 공유기, 내부 사설 IP 대역이 변경됨.
-- DNS 설정은 완료했고, 내부 사설 IP 정리 작업을 진행 중임.
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
-## 2. 현재 기준 주소(운영 사실)
-- 51123 임시 운용 서버 내부 사설 IP: `192.168.0.100`
-- NAS 내부 사설 IP: `192.168.0.101`
-
-## 3. 운영 반영 메모
-- 기존 `192.168.219.x` 기준 문서/환경변수/프록시/헬스체크 경로는 순차적으로 `192.168.0.x` 기준으로 정리 필요.
-- gateway 및 연계 서비스의 upstream 대상 주소는 실제 바인딩/노출 포트와 함께 재검증 필요.
-- NAS 마운트/백업 경로는 `192.168.0.101` 기준으로 재점검 필요.
-
-## 4. 기록 출처
-- 2026-03-07 사용자 전달 사실 기반 운영 기록.
+- 새 위치: `260307_51123_성수이전_네트워크변경_운영기록.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/260307_51123_성수이전_네트워크변경_운영기록.md>
+- 이유: 23/24/NAS, 게이트웨이, 배포, 네트워크, 백업, 마운트 등 공통 인프라 사실을 다루기 때문입니다.
diff --git a/journey/troubleshooting/260307_Gitea_LFS_NAS_권한정렬_및_실업로드_검증.md b/journey/troubleshooting/260307_Gitea_LFS_NAS_권한정렬_및_실업로드_검증.md
index 423d460..9d60f96 100644
--- a/journey/troubleshooting/260307_Gitea_LFS_NAS_권한정렬_및_실업로드_검증.md
+++ b/journey/troubleshooting/260307_Gitea_LFS_NAS_권한정렬_및_실업로드_검증.md
@@ -1,73 +1,7 @@
-# 260307 Gitea LFS NAS 권한정렬 및 실업로드 검증
+# 260307_Gitea_LFS_NAS_권한정렬_및_실업로드_검증
 
-tags: [gitea, lfs, nas, cifs, ssot]
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
-**날짜**: 2026-03-07  
-**작성자**: admin  
-**관련 파일**: `/etc/gitea/app.ini`, `/usr/local/bin/mount-nas-ssot.sh`, `/etc/systemd/system/mount-nas-ssot.service`, `/home/admin/infra-config/runtime.env`, `/home/admin/infra-config/secrets.env`
-
----
-
-## 문제 상황
-- Gitea는 기동 중이었고 `git.ro-being.com` 일반 Git push/pull도 정상 동작했다.
-- 하지만 실제 `git lfs push` 검증에서는 `500 Internal Server Error`로 실패했다.
-- 즉 "LFS 경로가 설정돼 있다"와 "실제 대용량 파일 업로드가 된다"가 분리된 상태였다.
-
-## 검증으로 확인한 사실
-1. 일반 Git 경로는 정상
-- `git push`, `git pull`은 정상
-
-2. LFS 경로는 비정상
-- 실제 `git lfs` 업로드 테스트에서 반복적으로 `500` 발생
-- `journalctl -u gitea` 기준 실패 시각(2026-03-07 09:35 KST) 로그:
-  - `mkdir /mnt/nas/gitea-lfs/18: permission denied`
-
-3. 근본 원인
-- `gitea.service`는 `git:git (uid=131 gid=138)`로 실행
-- NAS CIFS 마운트는 `uid=1001,gid=1000,file_mode=0755,dir_mode=0755` 기준
-- 결과적으로 `/mnt/nas/gitea-lfs`는 `admin:xusers` 소유처럼 보였고, `git` 사용자는 쓰기 불가
-
-## 실제 조치
-### 1. 마운트 권한 정렬
-- `/usr/local/bin/mount-nas-ssot.sh`의 CIFS 옵션을 아래 기준으로 조정
-  - `uid=1001`
-  - `gid=1000`
-  - `forceuid,forcegid`
-  - `file_mode=0664`
-  - `dir_mode=0775`
-
-### 2. Gitea 실행 사용자 그룹 정렬
-- `git` 사용자를 `xusers` 그룹에 추가
-- 결과: `git` 사용자가 `/mnt/nas/gitea-lfs`에 그룹 쓰기 가능
-
-### 3. 서비스 반영
-- NAS 재마운트 실행
-- `gitea.service` 재시작
-- `sudo -u git` 기준 직접 쓰기 테스트 성공
-
-## 재검증 결과
-1. 권한
-- `id git` -> `groups=138(git),1000(xusers)`
-- `/mnt/nas/gitea-lfs` -> `drwxrwxr-x`
-
-2. 실업로드 검증
-- `test-meta-skill` 저장소에 임시 브랜치 생성 후 1MB 바이너리 파일을 `git lfs`로 push
-- 재클론 후 `git lfs pull` 수행
-- 원본과 재다운로드 파일 SHA256 일치
-
-3. NAS 저장 확인
-- 실제 생성 경로:
-  - `/mnt/nas/gitea-lfs/4a/22/ae83cbb68dcdcddb9e053fdce9466e63463881c981597bb6c797ca4a0f7b`
-- 검증 시점 기준 LFS 파일 수:
-  - before=0
-  - after_push=1
-  - after_pull=1
-
-## 결론
-- 현재 Gitea LFS는 설정상 연결된 수준이 아니라, 실제로 NAS에 대용량 파일을 저장하는 상태까지 검증 완료됐다.
-- 이번 조치로 `git lfs push -> Gitea -> /mnt/nas/gitea-lfs` 경로가 실동작함을 확인했다.
-- 이후 동일 계열 문제 재발 시, `Gitea 상태`보다 먼저 `gitea 실행 사용자`와 `NAS 마운트 권한`을 함께 봐야 한다.
-
-## 전후 관계 문서
-- 이전: [260306_51123_gitea_lfs_permission_denied_502_복구](./260306_51123_gitea_lfs_permission_denied_502_복구.md)
-- 관련: [260307_NAS_192_168_0_101_SSOT_전환_및_CIFS_실마운트_복구](./260307_NAS_192_168_0_101_SSOT_전환_및_CIFS_실마운트_복구.md)
+- 새 위치: `260307_Gitea_LFS_NAS_권한정렬_및_실업로드_검증.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/260307_Gitea_LFS_NAS_권한정렬_및_실업로드_검증.md>
+- 이유: 23/24/NAS, 게이트웨이, 배포, 네트워크, 백업, 마운트 등 공통 인프라 사실을 다루기 때문입니다.
diff --git a/journey/troubleshooting/260307_NAS_192_168_0_101_SSOT_전환_및_CIFS_실마운트_복구.md b/journey/troubleshooting/260307_NAS_192_168_0_101_SSOT_전환_및_CIFS_실마운트_복구.md
index fd4f074..dec3645 100644
--- a/journey/troubleshooting/260307_NAS_192_168_0_101_SSOT_전환_및_CIFS_실마운트_복구.md
+++ b/journey/troubleshooting/260307_NAS_192_168_0_101_SSOT_전환_및_CIFS_실마운트_복구.md
@@ -1,74 +1,7 @@
-# 260307 NAS(192.168.0.101) SSOT 전환 및 CIFS 실마운트 복구
+# 260307_NAS_192_168_0_101_SSOT_전환_및_CIFS_실마운트_복구
 
-## 시간
-- 기준일: 2026-03-07
-- 작업 시각: 2026-03-07 오전
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
-## 배경
-- 서버 이전 후 NAS 내부 사설 IP가 `192.168.219.51`에서 `192.168.0.101`로 변경되었다.
-- 51123은 임시운영 상태에서 `/mnt/nas`를 다시 실NAS로 연결해야 했고, 동시에 SSOT 원칙에 맞게 NAS 설정을 정리할 필요가 있었다.
-- 기존 `/mnt/nas`는 실제 마운트가 아니라 로컬 디렉터리처럼 남아 있었고, `weekly-backup.sh`가 기대하는 `/mnt/nas/backup/weekly`도 실NAS 기준으로는 정합성이 깨져 있었다.
-
-## 확인된 사실
-1. `192.168.0.101`은 실제 응답하는 NAS였다.
-- `ping` 정상 응답
-- `22/80/443/139/445/5000/5001` 포트 오픈 확인
-- `5000/5001` 응답 기준 Synology DSM 장비 확인
-
-2. NAS 내부에는 기존 백업 구조가 남아 있었다.
-- `home` 공유 접근 가능
-- `backup/current/{robing,gitea,config}` 존재
-- `gitea-lfs` 디렉터리 존재
-
-3. 서버 쪽 마운트 설정은 구식 값이 남아 있었다.
-- `/etc/fstab`에 `//192.168.219.51/home /mnt/nas cifs username=admin,password=...` 형태의 평문 설정 존재
-- 이는 이전 IP 기준이며, SSOT 원칙에도 맞지 않았다.
-
-## 실제 조치
-### 1. NAS 접근 확인
-- `smbclient -L //192.168.0.101 -U admin%...` 로 `home`, `homes` 공유 확인
-- `smbclient //192.168.0.101/home ...` 로 `backup`, `gitea-lfs` 실제 존재 확인
-
-### 2. SSOT 반영
-- `/home/admin/infra-config/runtime.env`
-  - `NAS_HOST=192.168.0.101`
-  - `NAS_SMB_PORT=445`
-  - `NAS_SHARE=home`
-  - `NAS_MOUNT_PATH=/mnt/nas`
-- `/home/admin/infra-config/secrets.env`
-  - `NAS_USERNAME=admin`
-  - `NAS_PASSWORD=...`
-
-### 3. 마운트 방식 교체
-- `/etc/fstab`의 평문 CIFS 항목은 주석 처리
-- `/usr/local/bin/mount-nas-ssot.sh` 생성
-  - `runtime.env`, `secrets.env`를 읽어 CIFS 마운트 수행
-- `/etc/systemd/system/mount-nas-ssot.service` 생성 및 enable
-  - 부팅 후 SSOT 기준으로 NAS 마운트 복구 가능하도록 구성
-
-### 4. 권한 정합화
-- 초기 마운트는 `uid=1000` 기준이라 현재 사용자 `admin(uid=1001)`가 쓰기 불가
-- 마운트 옵션을 `uid=1001,gid=1000`으로 교정
-- 이후 `/mnt/nas/backup/weekly` 생성 및 쓰기 가능 확인
-
-## 검증 결과
-1. 마운트 상태
-- `//192.168.0.101/home on /mnt/nas type cifs` 확인
-- `df -h /mnt/nas` 기준 5.3T 마운트 정상
-
-2. 구조 확인
-- `/mnt/nas/backup/current`
-- `/mnt/nas/backup/archives`
-- `/mnt/nas/gitea-lfs`
-
-3. 쓰기 확인
-- `/mnt/nas/backup/weekly/latest.txt` 생성 및 기록 성공
-
-## 결론
-- 51123의 `/mnt/nas`는 다시 실NAS(`192.168.0.101`)를 바라보도록 복구되었다.
-- NAS 접속 정보는 `infra-config/runtime.env` + `secrets.env` 기준으로 SSOT화되었다.
-- 기존 `nas-fallback` 임시 우회 상태에서 한 단계 진전했지만, fallback 데이터 동기화 여부는 별도 점검이 필요하다.
-
-## 전후 관계 문서
-- 이전: [260226_NAS_192_168_219_51_접속불가_임시백업복구](./260226_NAS_192_168_219_51_접속불가_임시백업복구.md)
-- 관련: [260307_51123_성수이전_네트워크변경_운영기록](./260307_51123_성수이전_네트워크변경_운영기록.md)
+- 새 위치: `260307_NAS_192_168_0_101_SSOT_전환_및_CIFS_실마운트_복구.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/260307_NAS_192_168_0_101_SSOT_전환_및_CIFS_실마운트_복구.md>
+- 이유: 23/24/NAS, 게이트웨이, 배포, 네트워크, 백업, 마운트 등 공통 인프라 사실을 다루기 때문입니다.
diff --git a/journey/troubleshooting/260307_gateway_SSOT_runtime_secrets_분리_적용_및_검증.md b/journey/troubleshooting/260307_gateway_SSOT_runtime_secrets_분리_적용_및_검증.md
index ebad0b2..8f5b540 100644
--- a/journey/troubleshooting/260307_gateway_SSOT_runtime_secrets_분리_적용_및_검증.md
+++ b/journey/troubleshooting/260307_gateway_SSOT_runtime_secrets_분리_적용_및_검증.md
@@ -1,76 +1,7 @@
-# 260307 gateway SSOT(runtime/secrets) 분리 적용 및 검증
+# 260307_gateway_SSOT_runtime_secrets_분리_적용_및_검증
 
-## 1. 목적
-- 51123 임시 운용 환경에서 분산된 설정값을 1차 정리한다.
-- 우선순위가 높은 `robeing-gateway`부터 `runtime.env`(비민감)와 `secrets.env`(민감)로 분리 적용한다.
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
-## 2. 변경 사항
-### 2.1 SSOT 파일 신설
-- `/home/admin/infra-config/runtime.env` 생성
-  - 운영 비민감값(예: `HOST_51123`, `NAS_HOST`, `ROBEING_DEFAULT_HOST`, `MONITOR_URL`) 관리
-- `/home/admin/infra-config/secrets.env` 생성
-  - 민감값(예: `DATABASE_URL`, `JWT_SECRET_KEY`) 관리
-
-### 2.2 권한 적용
-- `runtime.env`: `640`
-- `secrets.env`: `600`
-- 디렉터리 `/home/admin/infra-config`: `750`
-
-### 2.3 게이트웨이 참조 경로 변경
-- 대상: `/home/admin/robeing-gateway/docker-compose.yml`
-- `env_file` 순서:
-  1. `/home/admin/infra-config/runtime.env`
-  2. `/home/admin/infra-config/secrets.env`
-  3. `.env` (임시 오버라이드 전용)
-
-### 2.4 기존 게이트웨이 `.env` 정리
-- 대상: `/home/admin/robeing-gateway/.env`
-- 실값 제거 후, “로컬 오버라이드 전용” 안내만 유지
-
-## 3. 검증 결과
-### 3.1 설정 파싱 검증
-- `docker compose -f /home/admin/robeing-gateway/docker-compose.yml config` 성공
-
-### 3.2 재가동 검증
-- 실행: `docker compose down && docker compose up -d --build`
-- 결과: `robeing-gateway` `Up (healthy)` 확인
-
-### 3.3 기능 검증
-- `GET http://127.0.0.1:8100/healthz` -> `200`
-- 도메인 경유 `/gateway/api/config` -> 미인증 요청 `401` (정상 인증 경계)
-- `gateway -> 192.168.0.100:8001/health` -> `200`
-- `gateway -> 192.168.0.100:9024/healthz` -> `200`
-
-## 4. 결론
-- 기존 무응답 핵심 원인이었던 연결 단절 상태는 해소됨.
-- 현재 `/api/message` 응답 경계는 연결 실패가 아니라 인증(`401`) 단계로 정상 전환됨.
-- SSOT 분리는 `robeing-gateway`에 1차 적용 완료, 나머지 서비스는 동일 패턴으로 순차 이전 필요.
-
-## 5. 후속 적용: robeing-monitor SSOT 분리 및 9024 복구
-### 5.1 변경 사항
-- 대상: `/home/admin/robeing/robeing-monitor`
-- `docker-compose.yml`이 `/home/admin/infra-config/runtime.env`, `/home/admin/infra-config/secrets.env`를 우선 참조하도록 변경
-- 기존 `.env`는 로컬 오버라이드 전용 안내만 유지
-- `app/core/config.py` 기본 DB 호스트를 현재 운영 기준 `192.168.0.100`으로 교정
-- `infra-config`에 아래 값을 추가
-  - `ROBEING_MONITOR_PORT`
-  - `ROBEING_MONITOR_LOG_LEVEL`
-  - `ROBEING_MONITOR_DATABASE_URL`
-  - `ROBEING_URLS`
-  - `SKILL_URLS`
-
-### 5.2 증상
-- 적용 전 `robeing_monitor` 컨테이너는 `unhealthy`
-- `curl http://127.0.0.1:9024/healthz` 타임아웃
-- Docker healthcheck도 동일하게 `Health check exceeded timeout (10s)` 반복
-
-### 5.3 검증 결과
-- `docker compose -f /home/admin/robeing/robeing-monitor/docker-compose.yml config` 성공
-- 실행: `docker compose down && docker compose up -d --build`
-- 결과: `robeing_monitor` `Up (healthy)` 확인
-- `GET http://127.0.0.1:9024/healthz` -> `200`
-
-### 5.4 결론
-- `robeing-monitor`도 SSOT 기반으로 1차 이전 완료
-- 9024 응답 정지 상태는 해소됐고, 현재 헬스체크 정상
-- 51123 임시 운용 핵심 경로는 `gateway`, `rb8001`, `robeing-monitor`까지 정상 응답 기준으로 복구됨
+- 새 위치: `260307_gateway_SSOT_runtime_secrets_분리_적용_및_검증.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/260307_gateway_SSOT_runtime_secrets_분리_적용_및_검증.md>
+- 이유: 23/24/NAS, 게이트웨이, 배포, 네트워크, 백업, 마운트 등 공통 인프라 사실을 다루기 때문입니다.
diff --git a/journey/troubleshooting/README.md b/journey/troubleshooting/README.md
index e9074e3..c85cd8f 100644
--- a/journey/troubleshooting/README.md
+++ b/journey/troubleshooting/README.md
@@ -18,6 +18,12 @@
    - 인증/보안: `*_auth_*`, `*_JWT_*`
    - 스킬별: `skill-*` 접두사의 문서
 
+## 인프라 문서 이관 원칙
+
+- `23/24/NAS`, 게이트웨이, 네트워크, 배포 SSOT, 백업, 마운트, Gitea/LFS 같은 공통 인프라 사실은 `infra/DOCS`를 기준으로 봅니다.
+- 이 디렉터리에 남아 있는 동일 제목 문서는 삭제가 아니라 이관 안내용 리다이렉트 문서일 수 있습니다.
+- 최신 인프라 기준 문서는 `https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/` 아래를 우선 확인합니다.
+
 ## 필수 참조 문서
 
 | 주제 | 문서 | 비고 |