DOCS/journey/research/260309_24서버_실서비스운영전환_리서치.md

---
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 서버의 `workspace-config` 기준 파일이 아직 완성되지 않았다

- 24 서버에서 다음 경로 확인 결과:
  - `MISSING:/home/admin/workspace-config/runtime.env`
  - `EXISTS:/home/admin/workspace-config/secrets.env`
- 그런데 `robeing-monitor/docker-compose.yml`은 `env_file`로 `/home/admin/workspace-config/runtime.env`, `/home/admin/workspace-config/secrets.env`, `.env`를 함께 요구한다.
- 따라서 24 전환 전에는 `workspace-config/runtime.env`를 먼저 채워야 한다.

### 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 workspace-config/runtime.env`, `23 UFW/Neo4j 미개방`, `24 경로 불일치`를 실행 순서로 고정하지는 않는다.
- 따라서 이번 문제를 닫는 기준 리서치는 별도로 필요하다.

## Interpretation

- 지금 풀고 있는 정확한 문제는 `24 서버를 켤 수 있느냐`가 아니라, `23 임시운영 중에 굳어진 배포/런타임/방화벽 기준을 24 프로덕션 구조로 다시 맞추는 것`이다.
- 현재 전환이 안 되는 이유는 단일 원인이 아니다. `배포 대상이 아직 23`, `24 런타임은 구 23 IP를 참조`, `24 workspace-config/runtime.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 workspace-config/runtime.env`, `23 인프라 포트`, `ivada_project 잔존 경로`로 좁혀졌다.