docs: migrate infra troubleshooting from robeing

journey/README.md

@@ -36,7 +36,12 @@
 - [260226 NAS(192.168.219.51) 접속불가 임시 백업 복구](./troubleshooting/260226_NAS_192_168_219_51_접속불가_임시백업복구.md)
 - [260217 starsandi DNS/nginx/SSL 분리 적용](./troubleshooting/260217_starsandi_dns_nginx_ssl_분리적용.md)
 - [250727 51124 서버 이전 작업 및 nginx 프록시 설정](./troubleshooting/250727_happybell80_51124서버이전작업.md)
+- [250731 로그 저장소 SSHFS 설정과 템플릿 해결책](./troubleshooting/250731_로그저장소_SSHFS설정과_템플릿해결책.md)
+- [250930 OpenSearch HDD 마이그레이션](./troubleshooting/250930_opensearch_hdd_migration.md)
+- [251014 skill-rag-file SSHFS allow_other 해결](./troubleshooting/251014_skill-rag-file_sshfs_allow_other_해결.md)
+- [260115 PostgreSQL Neo4j TCP healthcheck](./troubleshooting/260115_postgresql_neo4j_tcp_healthcheck.md)
 - [51123 구 IP 하드코딩과 런타임 SSOT 불일치 이슈](./troubleshooting/260309_51123_구IP하드코딩_런타임SSOT불일치_이슈.md)
+- [260308 env backup git tracking exposure 및 차단조치](./troubleshooting/260308_env_backup_git_tracking_exposure_및_차단조치.md)
 - [24서버 우분투 터미널 불가, 네트워크 대역 오류, python3-apt 복구 기록](./troubleshooting/260309_24서버_우분투터미널불가_네트워크대역오류_python3apt복구.md)
 - [23 gateway MONITOR_URL 구주소 잔존으로 24 monitor 프록시 실패 복구](./troubleshooting/260310_23gateway_monitor_url_구주소잔존_24monitor프록시실패_복구.md)
 - [Gitea git credential helper 표준화](./troubleshooting/260309_gitea_git_credential_helper_표준화.md)

journey/troubleshooting/250731_로그저장소_SSHFS설정과_템플릿해결책.md

@@ -0,0 +1,117 @@
+# 250731 로그 저장소 SSHFS 설정과 템플릿 해결책
+
+## 문제 상황
+
+### 초기 문제
+- 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 설정과 템플릿 기반 자동화

journey/troubleshooting/250930_opensearch_hdd_migration.md

@@ -0,0 +1,62 @@
+# OpenSearch HDD 마이그레이션
+
+## 문제
+- OpenSearch 데이터가 SSD(/var/lib/opensearch)에 저장
+- SSD 용량 부족 우려
+
+## 해결
+
+### 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 중복 설정 제거

journey/troubleshooting/251014_skill-rag-file_sshfs_allow_other_해결.md

@@ -0,0 +1,195 @@
+# skill-rag-file SSHFS allow_other 권한 문제 해결
+
+**날짜**: 2025-10-14
+**작성자**: Claude
+**관련 파일**: `skill-rag-file/docker-compose.yml`
+
+---
+
+## 문제 상황
+
+### 증상
+- 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

journey/troubleshooting/260115_postgresql_neo4j_tcp_healthcheck.md

@@ -0,0 +1,45 @@
+# PostgreSQL/Neo4j TCP 소켓 헬스체크 구현
+
+**날짜**: 2026-01-15
+**작성자**: Auto
+**관련 파일**: 
+- `admin-dashboard/backend/services/system_service.py:32-33, 346-384, 421-423`
+
+---
+
+## 문제 상황
+
+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`

journey/troubleshooting/260308_env_backup_git_tracking_exposure_및_차단조치.md

@@ -0,0 +1,81 @@
+tags: [env, secrets, git, security, troubleshooting]
+
+# 260308 env backup git tracking exposure 및 차단조치
+
+상위 원칙:
+- [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)