---
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)
- [24서버 실서비스 운영전환 계획](../plans/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/frontend-customer`, `robeing/admin-dashboard`, `robeing/onnx_models`.
- 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`다.
- 23 서버의 `.env.deploy` 역시 각각 `DEPLOY_PROJECT_DIR=/home/admin/robeing/skill-email`, `DEPLOY_PROJECT_DIR=/home/admin/robeing/skill-news`로 적혀 있다.
- 따라서 현재 배포 차단 요인은 경로 불일치가 아니라, `DEPLOY_SSH_HOST=192.168.219.45`, `DEPLOY_SSH_PORT=51123`처럼 배포 대상이 아직 23 기준이라는 점이다.

### 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`
  - `admin-dashboard/backend/services/system_service.py`: `rb8001`, `skill-email`, `skill-news`, `robeing-monitor`, `skill-publish` URL이 `http://192.168.219.52:*`
  - `admin-dashboard/backend/routers/system.py`: `RB8001_URL = "http://192.168.219.52:8001"`
  - `admin-dashboard/backend/admin_routes.py`: `RB8001_URL = "http://192.168.219.52:8001"`
- 반면 현재 `skill-embedding/docker-compose.yml`의 ONNX 모델 경로는 `/home/admin/robeing/onnx_models`로 이미 교정돼 있다.
- 현재 `/home/admin/robeing` 아래에는 `skill-publish` 디렉터리나 배포 워크플로우가 존재하지 않으므로, `admin-dashboard`의 `skill-publish` 표기는 잔존 운영 목록으로 봐야 한다.

### 7. 24 서버의 `workspace-config` 기준 파일은 존재하지만, 전체 실행 경로가 아직 이를 따르지 않는다

- 24 서버에서 다음 경로 확인 결과:
  - `EXISTS:/home/admin/workspace-config/runtime.env`
  - `EXISTS:/home/admin/workspace-config/secrets.env`
- `runtime.env`에는 `WORKSPACE_ROOT=/home/admin`, `HOST_51123=192.168.0.100`, `ROBEING_DEFAULT_HOST=192.168.0.100`, `MONITOR_URL=http://192.168.0.100:9024`가 들어 있다.
- 그런데 `robeing-monitor/docker-compose.yml`은 `env_file`로 `/home/admin/workspace-config/runtime.env`, `/home/admin/workspace-config/secrets.env`, `.env`를 함께 요구한다.
- 반면 `robeing-gateway/docker-compose.yml`은 아직 `/home/admin/infra-config/runtime.env`, `/home/admin/infra-config/secrets.env`를 가리킨다.
- 따라서 `workspace-config` 파일 부재 이슈는 해소됐지만, 실행 경로 전체가 새 SSOT를 사용하도록 정리된 것은 아니다.

### 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`의 모델 경로는 자산 자체가 없어서 막히는 상황은 아니다.

### 10. 23 서버의 ingress와 운영 보조 코드에도 과거 24 서버 주소가 남아 있다

- `/etc/nginx/sites-enabled/default`의 `/rb8001/` upstream은 `proxy_pass http://192.168.219.52:8001/;`다.
- `/home/admin/infra/nginx/sites-available/default`도 같은 upstream을 `192.168.219.52:8001`로 유지한다.
- `admin-dashboard/backend/services/system_service.py`, `routers/system.py`, `admin_routes.py`도 모두 `192.168.219.52` 기준 URL을 사용한다.
- 따라서 24 서버 실행계를 올리기 전에, 23 서버 ingress와 운영 보조 코드도 새 24 IP `192.168.0.106` 기준으로 함께 교정돼야 한다.

### 11. 현재 리서치 문서 `24서버 로빙 운영 자료 수집`은 실행 전환 문제를 직접 닫는 문서가 아니다

- 해당 문서는 문서/자산/참고 순서를 모은 자료 수집 문서다.
- 실제 차단 요인인 `23 대상 자동배포`, `24 런타임의 과거 IP`, `23 ingress/운영코드의 구 24 IP`, `23 UFW/Neo4j 미개방`, `workspace-config 비적용 경로`를 실행 순서로 고정하지는 않는다.
- 따라서 이번 문제를 닫는 기준 리서치는 별도로 필요하다.

## Interpretation

- 지금 풀고 있는 정확한 문제는 `24 서버를 켤 수 있느냐`가 아니라, `23 임시운영 중에 굳어진 배포/런타임/방화벽 기준을 24 프로덕션 구조로 다시 맞추는 것`이다.
- 현재 전환이 안 되는 이유는 단일 원인이 아니다. `배포 대상이 아직 23`, `24 런타임은 구 23 IP를 참조`, `23 ingress와 운영 보조 코드가 구 24 IP를 참조`, `23 인프라 의존 포트가 새 24 IP에 열려 있지 않음`, `일부 실행 경로는 아직 workspace-config를 쓰지 않음`이 동시에 겹쳐 있다.
- 따라서 이번 계획 문서는 `24에 docker compose를 한 번 올리는 절차`가 아니라, `배포 SSOT -> 24 런타임 SSOT -> 23 ingress/운영코드 교정 -> 23 인프라 허용 규칙 -> 서비스별 기동 순서 -> 23 임시 컨테이너 해제`를 한 묶음으로 다뤄야 한다.

## Unresolved

- `skill-publish`와 `robeing-monitor` 외부 진입 계약은 [24서버 실서비스 운영전환 계획](../plans/260309_24서버_실서비스운영전환_계획.md)에서 각각 `1차 범위 제외`, `23 gateway 경유 단일 경로`로 넘겨졌다.
- 따라서 이 문서에 남은 미확정은 사실 부족보다 실행 검증 부족이며, 다음 단계는 결정 보강이 아니라 계획 실행 후 실경로 검증이다.

## 한 줄 결론

- 이번 문제는 `24 서버 복구`가 아니라 `23 임시 프로덕션을 끝내고 24 실서비스 운영 기준을 다시 세우는 전환`이며, 이를 막는 차단 요인은 이미 `배포 대상`, `24 런타임 구 IP`, `23 ingress/운영코드의 구 24 IP`, `23 인프라 포트`, `workspace-config 미적용 실행 경로`로 좁혀졌다.