docs: add 24 production transition research plan

2026-03-09 20:57:09 +09:00 · 2026-03-09 20:57:09 +09:00 · 4d716aac84
commit 4d716aac84
parent e373656b29
5 changed files with 353 additions and 0 deletions
--- a/journey/README.md
+++ b/journey/README.md
@ -41,8 +41,11 @@
 - [23서버 워크스페이스 인프라 구조정리 이슈](./troubleshooting/260307_23서버_워크스페이스_인프라_구조정리_이슈.md)
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 파일 동기화 아이디어](./ideas/260307_external_nas_companyx_sync_아이디어.md)
 - [컴퍼니엑스 직원용 모바일 파일 포털 아이디어](./ideas/260307_companyx_mobile_file_portal_아이디어.md)
+- [23장애시 24서버 임시진입면승격 아이디어](./ideas/260309_23장애시_24서버_임시진입면승격_아이디어.md)
 - [외부 NAS -> 내부 NAS 컴퍼니엑스 동기화 리서치](./research/260307_external_nas_companyx_sync_research.md)
 - [컴퍼니엑스 직원용 모바일 파일 포털 리서치](./research/260307_companyx_mobile_file_portal_research.md)
 - [51123 구 IP 하드코딩 실행 경로와 런타임 SSOT 불일치 리서치](./research/260309_51123_구IP하드코딩_실행경로_SSOT불일치_리서치.md)
 - [24서버 로빙 운영 자료 수집](./research/260309_24서버_로빙운영_자료수집.md)
+- [24서버 실서비스 운영전환 리서치](./research/260309_24서버_실서비스운영전환_리서치.md)
 - [51123 구 IP 하드코딩 실행 경로 제거 계획](./plans/260309_51123_구IP하드코딩_실행경로제거_계획.md)
+- [24서버 실서비스 운영전환 계획](./plans/260309_24서버_실서비스운영전환_계획.md)
--- a/journey/ideas/260309_23장애시_24서버_임시진입면승격_아이디어.md
+++ b/journey/ideas/260309_23장애시_24서버_임시진입면승격_아이디어.md
@ -0,0 +1,62 @@
+# 260309 23장애시 24서버 임시진입면승격 아이디어
+
+tags: [infra, 23-server, 24-server, failover, ingress, ideas]
+
+상위 원칙:
+- [Writing Principles](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/writing-principles.md)
+- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
+- [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
+- [Operational Guardrails](../../00_Philosophy/02_GUARDRAILS/Operational_Guardrails.md)
+
+## 문제
+
+- 현재 외부 진입은 공유기 `80/443`이 23 서버를 바라보고, 23 서버에서 `nginx -> robeing-gateway -> 24 실행계` 구조로 동작한다.
+- 이 구조는 역할 분리에는 맞지만, 23 서버 장애 시 외부 진입이 한 번에 끊기는 단일 장애 지점 문제가 있다.
+- `gateway`만 24로 옮기면 제어면과 실행면이 다시 섞이므로 구조상 이득이 작다.
+
+## 목표
+
+- 평시에는 `23=진입/제어`, `24=실행` 구조를 유지한다.
+- 다만 23 서버 장애 시에는 24 서버가 임시로 `nginx + gateway` 역할까지 승격 받아 외부 서비스 연속성을 제공할 수 있게 한다.
+- 이 구조를 상시 운영이 아니라 장애 대응용 `임시 진입면 승격` 아이디어로 남긴다.
+
+## 가능한 방향
+
+### 1. 24 서버 대기 nginx + gateway 준비
+
+- 24 서버에 평소에는 외부 미노출 상태의 `nginx`, `gateway` 구성을 미리 준비한다.
+- 23 장애 시 공유기 `80/443` 포워딩만 24로 바꿔 임시 승격한다.
+- 장점: 현재 구조를 크게 깨지 않고 연속성을 높일 수 있다.
+- 단점: 공유기 전환, 인증서, upstream 동기화 절차를 따로 관리해야 한다.
+
+### 2. 외부 진입면 완전 이중화
+
+- 23과 24 모두가 상시 외부 진입을 받을 수 있게 하고, 장애 시 자동 또는 반자동 전환한다.
+- 장점: 더 강한 연속성 확보 가능
+- 단점: 인증서, DNS, 헬스체크, 데이터 동기화, 운영 복잡도가 크게 증가한다.
+
+### 3. 수동 런북 기반 반자동 전환
+
+- 24 서버에 최소한의 대기 구성을 두고, 장애 시 문서화된 런북에 따라 사람이 포워딩과 서비스 승격을 수행한다.
+- 장점: 초기 구현 부담이 가장 낮다.
+- 단점: 사람 개입 속도와 정확도에 의존한다.
+
+## 권장 방향
+
+- 1차는 `수동 런북 기반 반자동 전환`으로 시작하는 것이 현실적이다.
+- 운영 리허설이 쌓이면 `24 서버 대기 nginx + gateway 준비`까지 올리고, 그다음에야 자동화 여부를 판단하는 것이 맞다.
+- 핵심은 `gateway를 24로 상시 이전`하는 것이 아니라, `23 장애 시 24가 임시 진입면을 대신할 준비`를 갖추는 것이다.
+
+## 먼저 확인할 것
+
+1. 공유기에서 `80/443` 포워딩 대상을 장애 시 신속히 바꿀 수 있는지
+2. 24 서버에 `nginx`, 인증서, gateway 설정을 동일하게 재현할 수 있는지
+3. 23의 `auth-server`, `DB`, `OpenSearch`까지 장애 범위에 포함되는지, 아니면 진입면만 죽는 시나리오인지
+4. 장애 시 24가 직접 바라봐야 할 upstream과 SSOT 환경값이 무엇인지
+5. 장애 리허설을 어떤 주기로 수행할지
+
+## 관련 문서
+
+- [24서버 실서비스 운영전환 리서치](../research/260309_24서버_실서비스운영전환_리서치.md)
+- [24서버 실서비스 운영전환 계획](../plans/260309_24서버_실서비스운영전환_계획.md)
+- [Infrastructure Project Structure](../../02_Architecture/Infrastructure_Project_Structure.md)
--- a/journey/plans/260309_24서버_실서비스운영전환_계획.md
+++ b/journey/plans/260309_24서버_실서비스운영전환_계획.md
@ -0,0 +1,154 @@
+---
+tags: [infra, 24-server, robeing, production-transition, ssot, plans]
+---
+
+# 260309 24서버 실서비스 운영전환 계획
+
+## 상위 원칙
+- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
+- [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
+- [Operational Guardrails](../../00_Philosophy/02_GUARDRAILS/Operational_Guardrails.md)
+- 공통 작성 원칙: [0_VALUE Writing Principles](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/writing-principles.md)
+
+## 관련 문서
+- [Infra Journey](../README.md)
+- [24서버 실서비스 운영전환 리서치](../research/260309_24서버_실서비스운영전환_리서치.md)
+- [260304 51123 임시복구 서비스 연속성 조치내역](../troubleshooting/260304_51123_임시복구_서비스연속성_조치내역.md)
+- [260305 23임시배포 env.deploy SSOT 및 배포실패 근본원인 해결](../troubleshooting/260305_23임시배포_envdeploy_ssot_및_배포실패_근본원인_해결.md)
+- [24서버 우분투 터미널 불가, 네트워크 대역 오류, python3-apt 복구 기록](../troubleshooting/260309_24서버_우분투터미널불가_네트워크대역오류_python3apt복구.md)
+
+## 문제 정의
+
+- 지금 상태는 `23 서버가 임시 프로덕션 역할을 계속 수행`하고 있고, `24 서버는 실행 자산만 존재하며 실제 서비스는 0개`인 상태다.
+- 목표는 `23=진입/제어/보조`, `24=로빙 실행면` 역할을 다시 맞추는 것이다.
+- 이번 작업의 닫힘 기준은 `24 서버에서 실행계 서비스가 정상 기동`하고, `23 서버는 인프라와 게이트웨이 역할만 유지`하며, 이후 자동배포도 다시 24로 향하게 만드는 것이다.
+
+## 범위 고정
+
+### 1차 전환 대상
+
+- `rb8001`
+- `robeing-monitor`
+- `skill-email`
+- `skill-calendar`
+- `skill-news`
+- `skill-slack`
+- `skill-rag-file`
+- `skill-embedding`
+
+### 23 서버에 유지할 대상
+
+- `robeing-gateway`
+- `auth-server`
+- `postgresql`
+- `opensearch`
+- `data-prepper`
+- `gitea`
+- 기타 23 제어면/운영면 자산
+
+### 2차 검토 대상
+
+- `skill-publish`
+- 24 서버 프런트엔드 디렉터리 활용 여부
+
+## 실행 순서
+
+### 1. 배포 기준값을 먼저 24 기준으로 고정한다
+
+- 각 실행계 저장소의 `.env.deploy`를 `192.168.0.106:51124` 기준으로 바꾼다.
+- `DEPLOY_PROJECT_DIR`는 24 실제 경로와 일치하게 맞춘다.
+  - `skill_email`
+  - `skill_news`
+  - 기타 실제 24 저장 경로
+- 하드코딩된 원격 경로가 남아 있는 워크플로우는 `DEPLOY_PROJECT_DIR` 기반으로 통일한다.
+- 특히 `skill-embedding`, `skill-publish`의 `ivada_project` 경로 기반 워크플로우를 먼저 제거한다.
+
+### 2. 24 서버 런타임 SSOT를 먼저 정리한다
+
+- 24 서버에 `/home/admin/infra-config/runtime.env`, `/home/admin/infra-config/secrets.env`를 복구하거나 배치한다.
+- 24 서버 `.env`, `docker-compose.yml`, workflow에서 다음 잔존값을 제거한다.
+  - `192.168.219.52`
+  - `192.168.219.45`
+  - `/home/admin/ivada_project/...`
+- 23 인프라를 바라보는 값은 현재 기준으로 통일한다.
+  - DB: `192.168.0.100:5432`
+  - auth-server: `192.168.0.100:9000`
+  - gateway: `192.168.0.100:8100`
+  - OpenSearch: `192.168.0.100:9200`
+- 24 내부 자기참조는 서비스 간 localhost 기준만 사용한다.
+
+### 3. 23 서버 인프라 의존 포트를 24 현재 IP 기준으로 다시 연다
+
+- 23 UFW `5432/tcp` 허용 대상을 `192.168.0.106` 기준으로 교체한다.
+- 24에서 Neo4j가 필요하면 23의 `7687`을 `192.168.0.106`에서 접근 가능하게 바꾸고, Neo4j 리슨 주소도 localhost 전용 상태를 해제한다.
+- 기존 `192.168.219.52`, `192.168.219.0/24`에 묶인 허용 규칙은 새 24 기준이 검증된 뒤 제거한다.
+
+### 4. 서비스는 의존 순서대로 24에서 기동한다
+
+- 1순위: `skill-embedding`
+  - ONNX 모델 마운트와 헬스체크 먼저 확인
+- 2순위: `skill-rag-file`
+  - `/mnt/51123data` 문서 경로와 임베딩 연계를 확인
+- 3순위: `skill-email`, `skill-calendar`, `skill-news`, `skill-slack`
+  - DB/auth 의존성이 있는 스킬군을 기동
+- 4순위: `robeing-monitor`
+  - `infra-config`와 DB 의존성 확인
+- 5순위: `rb8001`
+  - 모든 하위 서비스와 23 인프라 연결이 열린 뒤 마지막 기동
+
+### 5. 23 게이트웨이와 24 실행면 연결을 다시 검증한다
+
+- 23 게이트웨이 upstream이 24 `rb8001`, `robeing-monitor`를 정확히 바라보는지 확인한다.
+- 외부 실서비스 도메인에서 핵심 경로를 검증한다.
+  - 메시지 핵심 경로
+  - 이메일 경로
+  - 일정 경로
+  - 모니터/통계 경로
+- 24 로컬 헬스체크가 아니라, 23 게이트웨이를 거친 실서비스 경로 기준으로 최종 판정한다.
+
+### 6. 24가 검증된 뒤 23 임시 실행 컨테이너를 해제한다
+
+- 24 동일 서비스가 모두 정상인 것을 확인한 뒤, 23의 실행계 컨테이너를 순차적으로 내린다.
+- 23에는 게이트웨이/인증/DB/OpenSearch 등 인프라성 컨테이너만 남긴다.
+- 이 단계 이전에는 23 실행계를 섣불리 내리지 않는다.
+
+## 서비스별 체크리스트
+
+### 공통
+
+- `.env.deploy`가 `192.168.0.106:51124`를 가리킨다.
+- 24 실제 `DEPLOY_PROJECT_DIR`와 일치한다.
+- `.env`, compose fallback, workflow에 `192.168.219.45`, `192.168.219.52`, `/home/admin/ivada_project`가 없다.
+- `docker compose down && docker compose up -d --build` 후 헬스체크가 통과한다.
+
+### 인프라 의존성
+
+- 24 -> 23 TCP 확인:
+  - `5432`
+  - `7687` 필요 시
+  - `9000`
+  - `9200`
+  - `8100`
+- 실패 시 서비스 재기동보다 먼저 네트워크/리스닝/UFW를 다시 맞춘다.
+
+## 검증 기준
+
+### 24 서버 내부
+
+- `docker ps`에 1차 전환 대상 컨테이너가 모두 `Up`으로 표시된다.
+- 각 서비스 헬스체크가 로컬에서 통과한다.
+- 24에서 23 인프라 포트가 모두 의도대로 연결된다.
+
+### 실서비스 경로
+
+- 23 게이트웨이를 거친 핵심 API가 정상 응답한다.
+- 외부 도메인에서 메시지/이메일/일정/모니터 핵심 경로가 정상 동작한다.
+- 24 서비스 로그에서 구 IP 재접속, `ivada_project` 경로, DB 타임아웃, Neo4j 연결 실패가 재현되지 않는다.
+
+## 완료 조건
+
+- 자동배포 기준이 다시 24 서버를 향한다.
+- 24 런타임 파일 기준 `192.168.219.45`, `192.168.219.52`, `/home/admin/ivada_project` 실행 경로가 0건이다.
+- 24 1차 전환 대상 컨테이너가 모두 정상 기동한다.
+- 23 서버에는 임시 실행계 컨테이너가 남지 않고, 인프라/제어면 역할만 남는다.
+- 실서비스 도메인 기준 핵심 사용자 경로 검증 기록이 남는다.
--- a/journey/research/260309_24서버_로빙운영_자료수집.md
+++ b/journey/research/260309_24서버_로빙운영_자료수집.md
@ -5,6 +5,11 @@ tags: [infra, 24-server, robeing, operations, ssot, research]
 - 상위 원칙: [0_VALUE Writing Principles](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/writing-principles.md)
 - 상위 원칙: [0_VALUE Global Principles](https://github.com/happybell80/0_VALUE/blob/main/00_Principles/global-principles.md)

+## 범위 메모
+
+- 이 문서는 24 서버 운영에 필요한 문서와 실행 자산의 위치를 모으는 자료 수집 문서입니다.
+- `23 임시운영을 24 실서비스 운영으로 되돌리는` 실제 전환 차단 요인과 실행 순서는 [24서버 실서비스 운영전환 리서치](./260309_24서버_실서비스운영전환_리서치.md)와 [24서버 실서비스 운영전환 계획](../plans/260309_24서버_실서비스운영전환_계획.md)에서 따로 다룹니다.
+
 ## 목적

 - 24 서버를 로빙 실행 서버로 운영할 때 먼저 봐야 할 문서를 SSOT 순서대로 모읍니다.
--- a/journey/research/260309_24서버_실서비스운영전환_리서치.md
+++ b/journey/research/260309_24서버_실서비스운영전환_리서치.md
@ -0,0 +1,129 @@
+---
+tags: [infra, 24-server, robeing, production-transition, ssot, research]
+---
+
+# 260309 24서버 실서비스 운영전환 리서치
+
+## 상위 원칙
+- [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)
+- [Core Infrastructure Principles](../../00_Philosophy/01_PRINCIPLES/Core_Infrastructure_Principles.md)
+- [Operational Guardrails](../../00_Philosophy/02_GUARDRAILS/Operational_Guardrails.md)
+- 공통 작성 원칙: [0_VALUE Writing Principles](https://github.com/happybell80/0_VALUE/blob/main/02_Governance/writing-principles.md)
+
+## 관련 문서
+- [Infra Journey](../README.md)
+- [24서버 로빙 운영 자료 수집](./260309_24서버_로빙운영_자료수집.md)
+- [260304 51123 임시복구 서비스 연속성 조치내역](../troubleshooting/260304_51123_임시복구_서비스연속성_조치내역.md)
+- [260305 23임시배포 env.deploy SSOT 및 배포실패 근본원인 해결](../troubleshooting/260305_23임시배포_envdeploy_ssot_및_배포실패_근본원인_해결.md)
+- [24서버 우분투 터미널 불가, 네트워크 대역 오류, python3-apt 복구 기록](../troubleshooting/260309_24서버_우분투터미널불가_네트워크대역오류_python3apt복구.md)
+- [51123 DB 5432 차단사고 복구 및 의존 포트 점검](../troubleshooting/260303_51123_DB5432_차단사고_복구_및_의존포트_점검.md)
+
+## 목적
+
+- 지금 풀어야 하는 문제를 `24 서버 자료 찾기`가 아니라 `23 임시 프로덕션을 24 실서비스 운영으로 다시 승격`하는 문제로 정확히 고정합니다.
+- 24 서버 전환을 막는 실제 차단 요인이 문서, 배포, 런타임, 네트워크 중 어디에 있는지 확인합니다.
+- 이후 계획 문서가 구현 판단 없이 바로 실행될 수 있도록, 차단 요인을 사실 기준으로 좁힙니다.
+
+## Facts
+
+### 1. 현재 운영 상태는 `23 임시 프로덕션 / 24 실행 자산만 존재` 상태다
+
+- 2026-03-09 23 서버 `docker ps` 기준 실행 중 컨테이너는 `rb8001`, `robeing_monitor`, `skill-email`, `skill-calendar`, `skill-embedding`, `skill-rag-file`, `skill-slack`, `robeing-skill-news`, `auth-server`, `opensearch`, `data-prepper`, `robeing-gateway`다.
+- 같은 시각 24 서버 `docker ps` 결과는 빈 목록이다.
+- 24 서버 `systemctl is-active docker nginx` 결과는 `docker=active`, `nginx=inactive`다.
+- 24 서버 `ss -tlnp` 결과 외부에서 확인되는 리슨 포트는 `51124`만 있다.
+
+### 2. 이번 문제의 범위는 `23의 인프라`를 옮기는 것이 아니라 `24의 실행면`을 되살리는 것이다
+
+- `260304_51123_임시복구_서비스연속성_조치내역.md`는 23 단독 복구를 `핵심 연속성 확보 기준의 임시 안정화`로 규정한다.
+- 같은 문서의 `24 서버 인계 메모`는 24 복구 후 우선순위를 `rb8001/skill/chromadb 원복 배치 -> gateway upstream 재점검 -> 임시 성능 플래그 해제 여부 판단` 순으로 적고 있다.
+- `robeing/DOCS/journey/plans/260303_23테스트보조_24프로덕션_운영전환_계획.md`는 역할을 `23=테스트+보조`, `24=프로덕션`으로 고정한다.
+
+### 3. 24 서버에는 실행 자산이 이미 존재하고 Git 상태도 깨지지 않았다
+
+- 24 서버에 다음 디렉터리가 존재한다: `robeing/rb8001`, `robeing/robeing-monitor`, `robeing/skill_email`, `robeing/skill_news`, `robeing/skill-slack`, `robeing/skill-rag-file`, `robeing/skill-calendar`, `robeing/skill-embedding`, `robeing/skill-publish`, `robeing/frontend-customer`, `robeing/frontend-ir-valuation`.
+- 24 서버 각 저장소의 `git status --short --branch` 결과는 모두 `## main...origin/main`으로 깨끗하다.
+- 즉 24 서버는 "코드가 없어서 못 띄우는 상태"가 아니라 "실행 전환이 아직 적용되지 않은 상태"다.
+
+### 4. 현재 자동배포 기준값은 여전히 23 서버를 가리킨다
+
+- 23 서버 저장소의 `.env.deploy` 값은 다음과 같이 남아 있다.
+  - `DEPLOY_SSH_HOST=192.168.219.45`
+  - `DEPLOY_SSH_PORT=51123`
+- 확인 대상: `rb8001`, `robeing-monitor`, `skill-email`, `skill-news`, `skill-slack`, `skill-rag-file`, `skill-calendar`, `skill-embedding-repo`.
+- `260305_23임시배포_envdeploy_ssot_및_배포실패_근본원인_해결.md`도 `51124 복구 시 코드 수정 없이 각 레포 .env.deploy의 배포 대상 값만 24 서버 값으로 전환하면 된다`고 기록한다.
+- 따라서 지금 자동배포가 24로 가지 않는 직접 이유 중 하나는 `.env.deploy`가 아직 23 기준이라는 점이다.
+
+### 5. 24 서버의 실제 프로젝트 경로와 23 배포 기준 경로가 일부 다르다
+
+- 23 서버 소스 저장소는 `skill-email`, `skill-news` 디렉터리를 사용한다.
+- 24 서버 실제 디렉터리는 `skill_email`, `skill_news`다.
+- 그런데 24 서버에 있는 `skill_email/.env.deploy`, `skill_news/.env.deploy`도 각각 `DEPLOY_PROJECT_DIR=/home/admin/robeing/skill-email`, `DEPLOY_PROJECT_DIR=/home/admin/robeing/skill-news`로 적혀 있다.
+- 즉 24 복귀 시 단순히 SSH 대상만 바꾸면 끝나는 것이 아니라, 배포 대상 디렉터리도 실제 24 경로와 맞춰야 한다.
+
+### 6. 24 서버 런타임 값에는 아직 과거 23 서버 주소와 삭제된 경로가 남아 있다
+
+- 24 서버 `.env` 확인 결과, 아래 서비스들이 아직 `192.168.219.45`를 직접 사용한다.
+  - `rb8001`: `DATABASE_URL`, `TEST_DATABASE_URL`, `METRICS_DATABASE_URL`, `POSTGRES_CONNECTION_STRING`, `GATEWAY_URL`, `AUTH_SERVER_URL`
+  - `robeing-monitor`: `DATABASE_URL`
+  - `skill_email`: `DATABASE_URL`, `POSTGRES_CONNECTION_STRING`, `TEST_DATABASE_URL`
+  - `skill_news`: `DATABASE_URL`, `TEST_DATABASE_URL`
+  - `skill-slack`: `DATABASE_URL`
+  - `skill-rag-file`: `DATABASE_URL`
+  - `skill-calendar`: `DATABASE_URL`
+- 24 서버 compose/workflow에도 과거값이 남아 있다.
+  - `skill_email/docker-compose.yml`: `AUTH_SERVER_URL` fallback이 `http://192.168.219.45:9000`
+  - `skill-calendar/docker-compose.yml`: `DATABASE_URL` fallback이 `postgresql://...@192.168.219.45:5432/main_db`
+  - `skill-embedding/docker-compose.yml`: ONNX 모델 마운트가 `/home/admin/ivada_project/onnx_models`
+  - 24 서버 `skill-embedding/.gitea/workflows/deploy.yml`: `/home/admin/ivada_project/skill-embedding`
+  - 24 서버 `skill-publish/.gitea/workflows/deploy.yml`: `/home/admin/ivada_project/skill-publish`
+- `ivada_project`는 이미 운영 경로에서 제거된 상태이므로, 위 경로는 24 실서비스 전환에 그대로 사용하면 안 된다.
+
+### 7. 24 서버의 `infra-config` 기준 파일이 현재 없다
+
+- 24 서버에서 다음 경로 확인 결과:
+  - `MISSING:/home/admin/infra-config`
+  - `MISSING:/home/admin/infra-config/runtime.env`
+  - `MISSING:/home/admin/infra-config/secrets.env`
+- 그런데 24 서버 `robeing-monitor/docker-compose.yml`은 `env_file`로 `/home/admin/infra-config/runtime.env`, `/home/admin/infra-config/secrets.env`, `.env`를 함께 요구한다.
+- 따라서 현재 상태 그대로라면 24에서 `robeing-monitor`는 컨테이너 시작 이전 단계에서 환경 파일 경로 문제에 걸릴 가능성이 높다.
+
+### 8. 24에서 23으로 향하는 의존 포트는 일부만 열려 있다
+
+- 24 서버에서 23 서버 `192.168.0.100`으로 TCP 확인 결과:
+  - `9000 ok`
+  - `9200 ok`
+  - `8100 ok`
+  - `5432 fail`
+  - `7687 fail`
+- 23 서버 현재 UFW 규칙은 `5432/tcp`를 `192.168.219.52`와 `172.16.0.0/12`에만 허용한다.
+- 23 서버 현재 UFW 규칙은 `7687`을 `192.168.219.0/24`, `172.19.0.0/16`, `172.17.0.0/16`에만 허용한다.
+- 23 서버 `ss -tlnp` 결과 `5432`는 `0.0.0.0`에 열려 있지만, `7687`은 `127.0.0.1`에서만 리슨 중이다.
+- 즉 24가 현재 IP `192.168.0.106`로 돌아온 뒤에는, DB와 Neo4j 의존성에 대해 기존 허용 규칙이 더 이상 맞지 않는다.
+
+### 9. 24 서버의 저장 자산과 SSHFS 마운트는 존재한다
+
+- 24 서버에 `robeing/onnx_models`, `/mnt/51123data`, `/mnt/51123logs`가 존재한다.
+- 따라서 `skill-rag-file`의 문서 경로와 `skill-embedding`의 모델 경로는 자산 자체가 없어서 막히는 상황은 아니다.
+- 다만 `skill-embedding` compose가 실제 존재 경로가 아니라 삭제된 `ivada_project` 경로를 보고 있어, 구성값 교정이 필요하다.
+
+### 10. 현재 리서치 문서 `24서버 로빙 운영 자료 수집`은 실행 전환 문제를 직접 닫는 문서가 아니다
+
+- 해당 문서는 문서/자산/참고 순서를 모은 자료 수집 문서다.
+- 실제 차단 요인인 `23 대상 자동배포`, `24 런타임의 과거 IP`, `24 missing infra-config`, `23 UFW/Neo4j 미개방`, `24 경로 불일치`를 실행 순서로 고정하지는 않는다.
+- 따라서 이번 문제를 닫는 기준 리서치는 별도로 필요하다.
+
+## Interpretation
+
+- 지금 풀고 있는 정확한 문제는 `24 서버를 켤 수 있느냐`가 아니라, `23 임시운영 중에 굳어진 배포/런타임/방화벽 기준을 24 프로덕션 구조로 다시 맞추는 것`이다.
+- 현재 전환이 안 되는 이유는 단일 원인이 아니다. `배포 대상이 아직 23`, `24 런타임은 구 23 IP를 참조`, `24 필수 env 파일 부재`, `23 인프라 의존 포트가 새 24 IP에 열려 있지 않음`, `일부 워크플로우는 삭제된 ivada_project 경로를 사용`이 동시에 겹쳐 있다.
+- 따라서 이번 계획 문서는 `24에 docker compose를 한 번 올리는 절차`가 아니라, `배포 SSOT -> 24 런타임 SSOT -> 23 인프라 허용 규칙 -> 서비스별 기동 순서 -> 23 임시 컨테이너 해제`를 한 묶음으로 다뤄야 한다.
+
+## Unresolved
+
+- `skill-publish`를 이번 1차 전환 범위에 포함할지, 실행계 서비스 1차군(`rb8001`, `robeing-monitor`, `skill-email`, `skill-calendar`, `skill-news`, `skill-slack`, `skill-rag-file`, `skill-embedding`) 이후 2차군으로 둘지는 운영 우선순위 확인이 필요하다.
+- 23 게이트웨이에서 24의 `rb8001`과 `robeing-monitor`로 향하는 upstream 최종값이 현재 어떤 파일에서 관리되는지 이번 리서치에서는 다시 열어보지 않았다. 다만 `260304` 문서상 원복 시 재점검 대상임은 확인된다.
+
+## 한 줄 결론
+
+- 이번 문제는 `24 서버 복구`가 아니라 `23 임시 프로덕션을 끝내고 24 실서비스 운영 기준을 다시 세우는 전환`이며, 이를 막는 차단 요인은 이미 `배포 대상`, `런타임 구 IP`, `missing infra-config`, `23 인프라 포트`, `ivada_project 잔존 경로`로 좁혀졌다.