From 9d8bab3470ddd9d3af2701de99fde5902f2d317d Mon Sep 17 00:00:00 2001
From: happybell80 <happybell80@naver.com>
Date: Tue, 10 Mar 2026 23:09:32 +0900
Subject: [PATCH] docs: relocate infra troubleshooting to infra docs

---
 ...��소_SSHFS설정과_템플릿해결책.md | 120 +----------
 .../250930_opensearch_hdd_migration.md        |  65 +-----
 ...skill-rag-file_sshfs_allow_other_해결.md | 198 +-----------------
 ...260115_postgresql_neo4j_tcp_healthcheck.md |  48 +----
 ..._git_tracking_exposure_및_차단조치.md |  84 +-------
 5 files changed, 25 insertions(+), 490 deletions(-)

diff --git a/journey/troubleshooting/250731_로그저장소_SSHFS설정과_템플릿해결책.md b/journey/troubleshooting/250731_로그저장소_SSHFS설정과_템플릿해결책.md
index 69241bf..70cbdad 100644
--- a/journey/troubleshooting/250731_로그저장소_SSHFS설정과_템플릿해결책.md
+++ b/journey/troubleshooting/250731_로그저장소_SSHFS설정과_템플릿해결책.md
@@ -1,117 +1,7 @@
-# 250731 로그 저장소 SSHFS 설정과 템플릿 해결책
+# 250731_로그저장소_SSHFS설정과_템플릿해결책
 
-## 문제 상황
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
-### 초기 문제
-- rb10508 등 로빙 컨테이너들의 로그가 SSD에 저장되고 있음
-- CLAUDE.md에 명시된 대로 로그는 HDD(/mnt/hdd/logs/)에 저장되어야 함
-- 51123 서버에 HDD가 있고, 51124 서버에서 접근 필요
-
-### SSHFS가 적합한 이유
-1. 이미 SSH 키 설정 완료 - 추가 인증 설정 불필요
-2. 다양한 로그 형태 지원 - stdout/stderr뿐만 아니라 파일 로그도 저장
-3. 설정 최소화 - 51123 서버는 디렉토리만 만들면 됨
-4. 투명한 작동 - 컨테이너는 로컬 디렉토리처럼 사용
-
-## 실제 설정 과정
-
-### 오후 10시 48분 - 51123 서버 작업
-```bash
-# 1. 51124서버 전용 로그 디렉토리 생성
-sudo mkdir -p /mnt/hdd/logs/51124-server
-sudo chown admin:admin /mnt/hdd/logs/51124-server
-
-# 2. 51124서버의 SSH 공개키 추가
-# 51124 서버의 ~/.ssh/id_rsa_deploy.pub 내용을 ~/.ssh/authorized_keys에 추가
-
-# 3. cleanup 스크립트에 51124 서버 로그 정리 추가
-# 51124 서버 로그도 30일 후 자동 정리되도록 설정
-```
-
-### 오후 10시 50분 - 51124 서버 작업
-```bash
-# 1. SSHFS 설치
-sudo apt install -y sshfs
-
-# 2. 마운트 포인트 생성
-sudo mkdir -p /mnt/51123logs
-
-# 3. 마운트 시도 (초기 실패 - SSH 키 문제)
-sudo sshfs -o allow_other,reconnect admin@192.168.219.45:/mnt/hdd/logs/51124-server /mnt/51123logs -p 51123
-```
-
-### 오후 10시 51분 - SSHFS 마운트 성공
-```bash
-# 1. SSH 키 파일 지정하여 마운트
-sshfs -o IdentityFile=/home/admin/.ssh/id_rsa_deploy admin@192.168.219.45:/mnt/hdd/logs/51124-server /mnt/51123logs -p 51123
-
-# 2. 마운트 확인
-df -h /mnt/51123logs
-# 결과: 916G 크기의 HDD가 성공적으로 마운트됨
-
-# 3. 테스트
-mkdir -p /mnt/51123logs/rb10508
-echo "SSHFS mount test - $(date)" > /mnt/51123logs/rb10508/test.log
-```
-
-## 권한 문제의 딜레마
-
-### 발견된 문제점
-1. **SSHFS 마운트**: admin(UID 1000)으로 마운트됨
-2. **Docker 컨테이너**: UID 999로 실행
-3. **권한 불일치**: Docker가 디렉토리 생성 시 실패
-
-### 검토한 해결방안들
-
-#### 1. 심볼릭 링크
-```bash
-ln -s /mnt/51123logs/rb10508 logs
-```
-- 간단하지만 로빙마다 수동 작업 필요
-
-#### 2. docker-compose.yml 직접 수정
-```yaml
-volumes:
-  - /mnt/51123logs/rb10508:/code/logs:rw
-```
-- 명확하지만 역시 로빙마다 수정 필요
-
-#### 3. SSHFS UID 매핑
-```bash
-sudo sshfs -o allow_other,uid=999,gid=999 ...
-```
-- root 권한 필요, 복잡함
-
-#### 4. 사전 권한 설정
-```bash
-sudo chown -R 999:999 /mnt/hdd/logs/51124-server/
-```
-- 여전히 디렉토리는 수동 생성 필요
-
-## 제안된 해결책 (미구현)
-
-**참고**: 이 템플릿 방식은 제안만 되었고, 실제로는 250801 크론잡 방식으로 해결됨.
-- 크론잡으로 매일 새벽 3시 rsync 동기화
-- 자세한 내용은 [250801_claude_크론잡로그동기화설정.md](./250801_claude_크론잡로그동기화설정.md) 참조
-
-## 교훈
-1. **서버 간 통신은 항상 SSH 키 먼저**: 51123-51124 간 SSH 키가 설정되어 있지 않았음
-2. **마운트 포인트 이름 규칙**: /mnt/51123logs처럼 연결하는 서버 번호를 명시하면 관리가 편함
-3. **SSHFS vs NFS**: 간단한 로그 저장용도는 SSHFS가 설정이 훨씬 간편함
-4. **SSH 키 파일 명시**: -o IdentityFile 옵션으로 특정 키 파일 지정 필요
-5. **처음부터 템플릿 설계**: 하드코딩은 나중에 고통
-6. **권한 문제는 미리 해결**: Docker UID/GID 차이 주의
-7. **자동화는 필수**: 수동 작업은 실수의 원인
-
-## 실제 구현 상태
-- **250801 크론잡 방식으로 구현 완료**
-- 매일 새벽 3시 자동 동기화 중
-- 7일 이상 로컬 로그 자동 삭제
-
----
-
-작성일: 2025-07-31
-작성자: Claude (51123 서버 - SSH 키 등록 및 디렉토리 생성)
-        Claude (51124 서버 - SSHFS 설정 및 마운트)
-        로컬 개발자 (템플릿 해결책 제안)
-주제: 로그 저장소 중앙화를 위한 SSHFS 설정과 템플릿 기반 자동화
\ No newline at end of file
+- 새 위치: `250731_로그저장소_SSHFS설정과_템플릿해결책.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/250731_%EB%A1%9C%EA%B7%B8%EC%A0%80%EC%9E%A5%EC%86%8C_SSHFS%EC%84%A4%EC%A0%95%EA%B3%BC_%ED%85%9C%ED%94%8C%EB%A6%BF%ED%95%B4%EA%B2%B0%EC%B1%85.md>
+- 이유: 23/24 서버 간 로그 저장소 마운트, SSHFS, 권한 매핑, HDD 로그 보존 구조를 공통 인프라 기준으로 다루기 때문입니다.
diff --git a/journey/troubleshooting/250930_opensearch_hdd_migration.md b/journey/troubleshooting/250930_opensearch_hdd_migration.md
index 4859910..fb900c9 100644
--- a/journey/troubleshooting/250930_opensearch_hdd_migration.md
+++ b/journey/troubleshooting/250930_opensearch_hdd_migration.md
@@ -1,62 +1,7 @@
-# OpenSearch HDD 마이그레이션
+# 250930_opensearch_hdd_migration
 
-## 문제
-- OpenSearch 데이터가 SSD(/var/lib/opensearch)에 저장
-- SSD 용량 부족 우려
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
-## 해결
-
-### 1. 데이터 마이그레이션
-```bash
-sudo mkdir -p /mnt/hdd/opensearch
-sudo cp -rp /var/lib/opensearch/* /mnt/hdd/opensearch/
-sudo chown -R 1000:1000 /mnt/hdd/opensearch
-```
-
-### 2. 설정 파일 변경
-
-**파일**: `/home/admin/opensearch/docker-compose.yaml`
-- 34번 라인: `/var/lib/opensearch` → `/mnt/hdd/opensearch`
-
-**파일**: `/home/admin/opensearch/.gitea/workflows/cicd.yml`
-- 17-19번 라인: `/var/lib/opensearch` → `/mnt/hdd/opensearch`
-- 30-31번 라인: 기존 컨테이너 중복 방지 코드 추가
-
-**파일**: `/home/admin/opensearch/Dockerfile`
-- 보안 인증서 COPY 라인 제거
-- `ENV plugins.security.disabled=true` 추가
-
-### 3. 보안 플러그인 비활성화
-- docker-compose.yaml 15번 라인: `DISABLE_SECURITY_PLUGIN=true`
-- 내부 네트워크 전용 서비스로 TLS 불필요
-
-### 4. 해결 과정 중 발생한 문제
-- Actions 실패: TLS 인증서 파일 없음 → 보안 플러그인 비활성화로 해결
-- 컨테이너 이름 충돌 → Actions에 기존 컨테이너 제거 코드 추가
-- 설정 중복 에러 → Dockerfile ENV 제거, docker-compose.yaml에서만 설정
-
-### 5. 최종 상태
-- 데이터 경로: `/mnt/hdd/opensearch` (354MB)
-- 컨테이너: opensearch (opensearch-opensearch-node 이미지)
-- 포트: 9200, 9600
-- HDD 여유 공간: 869GB
-- API 응답: 정상
-- 로그 수집: fluent-bit → data-prepper → OpenSearch 정상
-
-### 6. 추가 이슈 (2025-09-30)
-- **문제**: 9/29부터 로그 수집 중단
-- **증상**: fluent-bit → data-prepper 200 OK, 하지만 OpenSearch 저장 실패
-- **에러**: `Cannot deserialize value of type java.util.ArrayList from Object value`
-- **원인**: Data Prepper가 JSON 배열 `[{...}]` 요구, fluent-bit이 단일 객체 `{...}` 전송
-- **시도한 해결책**:
-  - json_array on 추가 (Fluentd 전용 파라미터, Fluent Bit에는 없음)
-  - Flush 5초, Grace 30 설정 (배치 처리 시도)
-  - Format json_lines (Data Prepper 비호환)
-- **상태**: 미해결, 추가 조사 필요
-
-### 7. 커밋 이력
-- 7466068: HDD 경로 변경
-- 5f7bf49: Actions 워크플로우 경로 수정
-- 2df7afb: 보안 플러그인 비활성화
-- 8f667d3: DISABLE_SECURITY_PLUGIN 환경변수 수정
-- 66b5ee8: Dockerfile 중복 설정 제거
\ No newline at end of file
+- 새 위치: `250930_opensearch_hdd_migration.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/250930_opensearch_hdd_migration.md>
+- 이유: OpenSearch 저장 경로, HDD 마이그레이션, 로그 파이프라인과 스토리지 운영 문제를 공통 인프라 기준으로 다루기 때문입니다.
diff --git a/journey/troubleshooting/251014_skill-rag-file_sshfs_allow_other_해결.md b/journey/troubleshooting/251014_skill-rag-file_sshfs_allow_other_해결.md
index 2a75b58..96ae1b6 100644
--- a/journey/troubleshooting/251014_skill-rag-file_sshfs_allow_other_해결.md
+++ b/journey/troubleshooting/251014_skill-rag-file_sshfs_allow_other_해결.md
@@ -1,195 +1,7 @@
-# skill-rag-file SSHFS allow_other 권한 문제 해결
+# 251014_skill-rag-file_sshfs_allow_other_해결
 
-**날짜**: 2025-10-14
-**작성자**: Claude
-**관련 파일**: `skill-rag-file/docker-compose.yml`
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
----
-
-## 문제 상황
-
-### 증상
-- skill-rag-file 컨테이너가 `/mnt/51123data/documents/`에 파일 저장
-- 컨테이너 내부에서만 파일 보임
-- 호스트와 51123 서버 HDD에는 저장 안됨
-- 컨테이너 재시작 시 파일 손실
-
-### 근본 원인
-1. **SSHFS 마운트**: `user_id=1001,group_id=1000` (admin:xusers)
-2. **컨테이너 실행**: root (UID 0)
-3. **권한 불일치**: FUSE는 기본적으로 마운트한 사용자만 접근 허용
-4. **allow_other 미사용**: 다른 UID 접근 차단
-
-### 검증
-```bash
-# 컨테이너 내부
-docker exec skill-rag-file ls /mnt/51123data/documents/79441171.../2025-10/
-# → 파일 보임
-
-# 호스트
-ls /mnt/51123data/documents/79441171.../2025-10/
-# → No such file or directory
-```
-
----
-
-## 해결 과정
-
-### 1단계: /etc/fuse.conf 수정
-
-```bash
-sudo sed -i 's/^#user_allow_other/user_allow_other/' /etc/fuse.conf
-```
-
-**결과**:
-```
-user_allow_other
-```
-
-**의미**: 일반 사용자가 `allow_other` 옵션 사용 가능
-
-### 2단계: SSHFS 재마운트
-
-```bash
-# 기존 마운트 해제
-sudo fusermount -u /mnt/51123data
-
-# allow_other 옵션 추가하여 재마운트
-sshfs -o allow_other,default_permissions,IdentityFile=/home/admin/.ssh/id_rsa_deploy,reconnect,uid=1001,gid=1000 admin@192.168.219.45:/mnt/hdd/data /mnt/51123data -p 51123
-```
-
-**마운트 옵션 확인**:
-```bash
-mount | grep 51123data
-# admin@192.168.219.45:/mnt/hdd/data on /mnt/51123data type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=1001,group_id=1000,default_permissions,allow_other)
-```
-
-### 3단계: docker-compose.yml 볼륨 추가
-
-**파일**: skill-rag-file/docker-compose.yml
-
-```yaml
-volumes:
-  - ./chroma_db:/app/chroma_db
-  - ./logs:/app/logs
-  - ./.env:/app/.env:ro
-  - /mnt/51123data:/mnt/51123data:rw  # 추가
-```
-
-### 4단계: 컨테이너 재시작
-
-```bash
-cd /home/admin/ivada_project/skill-rag-file
-docker compose down
-docker compose up -d
-```
-
-**결과**: 컨테이너 정상 시작 (DOCS/250915 문서의 "mkdir /mnt/51123data: file exists" 에러 발생 안함)
-
----
-
-## 검증 결과
-
-### 테스트 1: 파일 쓰기
-```bash
-docker exec skill-rag-file touch /mnt/51123data/documents/test_write_from_container.txt
-ls -la /mnt/51123data/documents/ | grep test_write
-# -rw-r--r-- 1 admin xusers 0 10월 14 01:01 test_write_from_container.txt
-```
-
-**결과**: ✅ 컨테이너 → 호스트 즉시 동기화
-
-### 테스트 2: 디렉토리 생성
-```bash
-docker exec skill-rag-file mkdir -p /mnt/51123data/documents/test_team/2025-10
-docker exec skill-rag-file touch /mnt/51123data/documents/test_team/2025-10/test.pdf
-ls -la /mnt/51123data/documents/test_team/2025-10/
-# total 8
-# drwxr-xr-x 1 admin xusers 4096 10월 14 01:01 .
-# -rw-r--r-- 1 admin xusers    0 10월 14 01:01 test.pdf
-```
-
-**결과**: ✅ 디렉토리 생성 및 권한 매핑 정상
-
-### 테스트 3: 영속성
-```bash
-docker compose down && docker compose up -d
-docker exec skill-rag-file ls /mnt/51123data/documents/ | grep test
-# test.txt
-# test_team
-# test_write_from_container.txt
-```
-
-**결과**: ✅ 재시작 후에도 파일 유지
-
----
-
-## 핵심 설정 요약
-
-### /etc/fuse.conf
-```
-user_allow_other
-```
-
-### SSHFS 마운트 명령
-```bash
-sshfs -o allow_other,default_permissions,IdentityFile=/home/admin/.ssh/id_rsa_deploy,reconnect,uid=1001,gid=1000 admin@192.168.219.45:/mnt/hdd/data /mnt/51123data -p 51123
-```
-
-### docker-compose.yml
-```yaml
-volumes:
-  - /mnt/51123data:/mnt/51123data:rw
-```
-
----
-
-## 교훈
-
-### FUSE 기본 보안 정책
-- FUSE는 기본적으로 마운트한 사용자만 접근 허용
-- 컨테이너 내부 다른 UID 사용 시 접근 불가
-- `allow_other` 옵션으로 해결 가능
-
-### allow_other 사용 조건
-- `/etc/fuse.conf`에 `user_allow_other` 필수
-- `default_permissions` 옵션 권장 (일반 파일시스템 권한 체크)
-- 보안 위험: 모든 사용자가 접근 가능하므로 신중히 사용
-
-### Docker 볼륨 마운트
-- SSHFS 마운트 포인트를 Docker 볼륨으로 사용 가능
-- `allow_other` 없으면 컨테이너 내부에만 파일 존재 (휘발성)
-- 볼륨 마운트 시 `/mnt/51123data:/mnt/51123data:rw` 형태로 전체 마운트 포인트 바인드
-
-### 과거 문서 오류
-- DOCS/250915: "볼륨 제거"가 해결책이 아님 → 임시 우회책
-- DOCS/250731: "Docker SSHFS 충돌"로 롤백 → allow_other로 해결 가능
-- 교훈: FUSE 권한 모델 이해 부족으로 잘못된 결론 도출
-
----
-
-## 추가 발견 (2025-10-14 23:30)
-
-### 문제: SSHFS 긴 파일명 처리 실패
-
-**증상**:
-- coldmail workflow 실행 시 PDF 업로드 500 에러
-- 로그: `OSError: [Errno 74] Bad message`
-- 파일명 예시: `1d8072302cf85eee...pdf` (150자 이상)
-
-**원인**:
-- upload.py:82: `f"{file_hash}_{file.filename}"` → 150자 초과
-- SSHFS 파일시스템의 파일명 길이 제한
-
-**구현 완료** (커밋 dfe6978):
-- ✅ skill-rag-file/app/api/upload.py:73-87,106-107 수정 완료
-- ✅ import uuid 추가 (upload.py:5)
-- ✅ coldmail workflow PDF 첨부파일 재테스트 대기
-
----
-
-## 관련 문서
-
-- 250915_skill-rag-file_Docker_빌드_및_볼륨_마운트_문제.md
-- 250915_skill-rag-file_초기_구축.md
-- 250731_claude_SSHFS권한문제해결.md
+- 새 위치: `251014_skill-rag-file_sshfs_allow_other_해결.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/251014_skill-rag-file_sshfs_allow_other_%ED%95%B4%EA%B2%B0.md>
+- 이유: SSHFS 마운트, FUSE 권한, 컨테이너 볼륨 경로 정합성을 공통 인프라 기준으로 다루기 때문입니다.
diff --git a/journey/troubleshooting/260115_postgresql_neo4j_tcp_healthcheck.md b/journey/troubleshooting/260115_postgresql_neo4j_tcp_healthcheck.md
index 6101da8..38f4599 100644
--- a/journey/troubleshooting/260115_postgresql_neo4j_tcp_healthcheck.md
+++ b/journey/troubleshooting/260115_postgresql_neo4j_tcp_healthcheck.md
@@ -1,45 +1,7 @@
-# PostgreSQL/Neo4j TCP 소켓 헬스체크 구현
+# 260115_postgresql_neo4j_tcp_healthcheck
 
-**날짜**: 2026-01-15
-**작성자**: Auto
-**관련 파일**: 
-- `admin-dashboard/backend/services/system_service.py:32-33, 346-384, 421-423`
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
----
-
-## 문제 상황
-
-PostgreSQL/Neo4j가 HTTP 체크로 실패하여 Admin Dashboard에서 오류 표시 (실제로는 정상 작동 중)
-
----
-
-## 해결 방안
-
-- `system_service.py:32-33`: PostgreSQL/Neo4j HTTP URL 제거, `check_method: "tcp"` 추가
-- `system_service.py:346-384`: `check_tcp_service()` 함수 추가, 여러 호스트 시도 (`172.17.0.1` → `localhost` → `127.0.0.1`)
-- `system_service.py:421-423`: `check_method == "tcp"`인 경우 TCP 체크로 분기 처리
-
----
-
-## 구현 완료
-
-- Git 커밋: `4c9f227`
-- API 테스트: PostgreSQL/Neo4j 모두 `check_method: "tcp"`, `status: "healthy"` 확인
-
----
-
-## 교훈
-
-### 데이터베이스 서비스는 TCP 소켓 체크 사용
-- HTTP 프로토콜이 아닌 서비스는 TCP 소켓 체크 필수
-- Docker 컨테이너에서 호스트 접근 시 여러 호스트 시도로 네트워크 격리 문제 완화
-
-### 브라우저 테스트 시 docs 확인 필수
-- 로그인 비밀번호, API 엔드포인트 등 접근 정보는 코드 또는 docs에서 확인 (추측 금지)
-
----
-
-## 참고
-
-- `plans/251225_admin_dashboard_navigation_structure_refactoring.md`
-- `troubleshooting/251228_admin_서비스_헬스체크_개선.md`
+- 새 위치: `260115_postgresql_neo4j_tcp_healthcheck.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/260115_postgresql_neo4j_tcp_healthcheck.md>
+- 이유: PostgreSQL, Neo4j 헬스체크 방식과 Docker 컨테이너-호스트 접근 규칙을 공통 인프라 기준으로 다루기 때문입니다.
diff --git a/journey/troubleshooting/260308_env_backup_git_tracking_exposure_및_차단조치.md b/journey/troubleshooting/260308_env_backup_git_tracking_exposure_및_차단조치.md
index a479ff2..929309e 100644
--- a/journey/troubleshooting/260308_env_backup_git_tracking_exposure_및_차단조치.md
+++ b/journey/troubleshooting/260308_env_backup_git_tracking_exposure_및_차단조치.md
@@ -1,81 +1,7 @@
-tags: [env, secrets, git, security, troubleshooting]
+# 260308_env_backup_git_tracking_exposure_및_차단조치
 
-# 260308 env backup git tracking exposure 및 차단조치
+이 문서는 공통 인프라 문서로 재분류되어 `infra/DOCS`로 이관되었습니다.
 
-상위 원칙:
-- [global-principles](../../../../0_VALUE/00_Principles/global-principles.md)
-- [writing-principles](../../../../0_VALUE/02_Governance/writing-principles.md)
-
-## 1. 목적
-- `rb8001` 저장소에 `.env` 백업본과 배포용 env 파일이 git 원격에 포함된 경위를 기록합니다.
-- 동일 유형 파일이 다시 원격에 올라가지 않도록 차단한 조치와 잔여 범위를 남깁니다.
-
-## 2. Facts
-
-### 2.1 `rb8001` 노출 사실
-- 대상 파일: `.env.backup`, `.env.bak.20260304032910`, `.env.bak.20260306193102`, `.env.deploy`
-- 원격 반영 커밋:
-  - `b9731bfc68bd12d0bdefc74a1403a878433c6824` (`2026-01-02 12:53:52 +0900`): `.env.backup` 추가
-  - `5f24b2bdb515b0a372cebaf62052f7086d41e739` (`2026-03-07 17:01:56 +0900`): `.env.bak.20260304032910`, `.env.bak.20260306193102`, `.env.deploy` 포함
-- `5f24b2b`는 로컬 reflog 기준 같은 시각에 `refs/remotes/origin/main: update by push`가 확인됐습니다.
-
-### 2.2 `rb8001` 원인성 설정 사실
-- `/home/admin/robeing/rb8001/.gitignore`에는 기존에 `.env`만 있었고 `.env.*`, `*.env.*` 차단 규칙은 없었습니다.
-- 저장소 내부 검색 기준, `.env.bak.*` 또는 `.env.backup` 생성을 지시하는 자동 스크립트/코드는 확인되지 않았습니다.
-- `/home/admin/AGENTS.md`에는 환경변수 기준을 `/home/admin/infra-config/runtime.env`, `/home/admin/infra-config/secrets.env`로 두고, 서비스별 `.env`는 임시 로컬 오버라이드 전용이라고 명시돼 있습니다.
-
-### 2.3 `rb8001` 즉시 조치 사실
-- `2026-03-08`에 `.gitignore`를 아래 패턴까지 확장했습니다.
-  - `.env.*`
-  - `*.env`
-  - `*.env.*`
-  - 예외: `.env.deploy.example`
-- 추적 중이던 `.env.backup`, `.env.bak.20260304032910`, `.env.bak.20260306193102`, `.env.deploy`를 git 인덱스에서 제거했습니다.
-- 위 변경은 커밋 `5f0087d` (`chore: stop tracking env files`)로 `origin/main`에 push됐습니다.
-- 로컬 파일도 `.env.backup`, `.env.bak.20260304032910`, `.env.bak.20260306193102`를 삭제했습니다.
-
-### 2.4 워크스페이스 전수 확인 사실
-- 백업본 실파일 확인:
-  - `/home/admin/robeing/skill-news/.env.backup`
-- git 추적 중인 `.env*` 확인:
-  - `/home/admin/fluent-bit`: `.env`
-  - `/home/admin/ivada_project/robeing-monitor`: `.env.deploy`, `.env.deploy.example`
-  - `/home/admin/robeing/robeing-monitor`: `.env.deploy`, `.env.deploy.example`
-  - `/home/admin/robeing/skill-calendar`: `.env.deploy`, `.env.deploy.example`
-  - `/home/admin/robeing/skill-email`: `.env.deploy`, `.env.deploy.example`
-  - `/home/admin/robeing/skill-embedding-repo`: `.env.deploy`, `.env.deploy.example`, `.env.example`
-  - `/home/admin/robeing/skill-news`: `.env.backup`, `.env.deploy`, `.env.deploy.example`, `.env.example`
-  - `/home/admin/robeing/skill-rag-file`: `.env.deploy`, `.env.deploy.example`, `.env.example`
-  - `/home/admin/robeing/skill-slack`: `.env.deploy`, `.env.deploy.example`
-  - `/home/admin/vMIR/LocalTerra`: `.env`
-  - `/home/admin/vMIR/mirror-terra-web-dapp-ref`: `.env`, `.env.development`
-  - `/home/admin/vMIR/vmir-web-app`: `.env`, `.env.development`
-- `/home/admin/auth-server`는 `.git/config` 권한 문제로 이번 점검에서 추적 여부를 확정하지 못했습니다.
-
-## 3. Interpretation
-- `rb8001`의 직접 원인은 `.env`만 무시하고 `.env` 파생 파일을 무시하지 않은 `.gitignore` 공백입니다.
-- `.env.bak.20260304032910`, `.env.bak.20260306193102`는 파일명과 내용상 `.env`의 시점별 수동 백업본으로 해석됩니다.
-- 이 문제는 단일 저장소 실수라기보다, 여러 저장소에서 `.env`, `.env.deploy`, `.env.backup`를 버전 관리 대상으로 다뤄 온 운영 습관 문제로 봐야 합니다.
-- 전역 원칙 문서가 요구하는 방향은 SSOT(Single Source of Truth, 단일 진실 공급원) 기반의 `runtime.env`/`secrets.env` 분리이며, 서비스 루트의 실제 비밀 env 파일을 git에 유지하는 방식과 충돌합니다.
-
-## 4. Unresolved
-- 이미 원격 히스토리에 포함된 민감값은 커밋 삭제만으로 무효화되지 않으므로, 실제 키 폐기와 재발급 여부를 별도로 확인해야 합니다.
-- `skill-news`를 포함한 다른 저장소들의 `.env*` 추적 해제 범위는 아직 미적용 상태입니다.
-- `auth-server`는 권한 문제를 해소한 뒤 `.env*` 추적 여부를 다시 확인해야 합니다.
-- `.env.deploy`를 예제 파일만 남기고 모두 제거할지, SSOT 경로 참조 방식으로 전환할지 저장소별 운영 기준 정리가 필요합니다.
-
-## 5. 다음 조치 후보
-- 우선순위 1: 원격 히스토리에 노출된 Slack, OpenAI, Perplexity, Tavily, JWT 등 민감값 폐기 및 재발급
-- 우선순위 2: `skill-news` 포함 나머지 저장소에도 동일한 `.gitignore` 확장과 git 추적 해제 적용
-- 우선순위 3: 서비스별 `.env.deploy`를 예제 파일만 남기는 구조로 통일하거나, `/home/admin/infra-config` 참조 구조로 일원화
-
-## 6. 검증 근거
-- `git log --follow --date=iso --name-status -- .env.bak.20260304032910`
-- `git show --stat --summary 5f24b2bdb515b0a372cebaf62052f7086d41e739`
-- `git reflog --date=iso --all`
-- `git ls-files '.env*'`
-- `find /home/admin -path '*/.git' -prune -o -type f \( -name '.env.backup' -o -name '.env.bak.*' -o -name '.env.deploy' -o -name '.env' \) -print`
-
-관련 문서:
-- [260307 gateway SSOT(runtime/secrets) 분리 적용 및 검증](./260307_gateway_SSOT_runtime_secrets_분리_적용_및_검증.md)
-- [README](./README.md)
+- 새 위치: `260308_env_backup_git_tracking_exposure_및_차단조치.md`
+- 인프라 기준 문서: <https://git.ro-being.com/ivada-infra/DOCS/src/branch/main/journey/troubleshooting/260308_env_backup_git_tracking_exposure_%EB%B0%8F_%EC%B0%A8%EB%8B%A8%EC%A1%B0%EC%B9%98.md>
+- 이유: 서비스별 `.env` 오버라이드, SSOT runtime/secrets, git 추적 노출 문제를 워크스페이스 공통 인프라 기준으로 다루기 때문입니다.