---
tags: [infra, 24-server, robeing, production-transition, ssot, plans]
---

# 260309 24서버 실서비스 운영전환 계획

**상태**: 완료 (2026-03-10 기준)

## 상위 원칙
- [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)
- [23서버 워크스페이스 SSOT 구조전환 계획](./260309_23서버_워크스페이스_SSOT_구조전환_계획.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제어면 gateway workspace-config 단일화](../worklog/260309_23제어면_gateway_workspace_config_단일화.md)
- [24서버 robeing runtime workspace-config 단일화](../worklog/260310_24서버_robeing_runtime_workspace_config_단일화.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 서버 프런트엔드 디렉터리 활용 여부

## 운영 결정 고정

- `skill-publish`는 현재 `/home/admin/robeing` 실행 자산에 없으므로 1차 전환 범위에서 제외합니다.
- `robeing-monitor` 외부 진입은 `23 gateway -> 24 robeing-monitor` 단일 경로로만 고정하고, 직접 포트 노출이나 병행 경로를 두지 않습니다.
- `robeing-gateway`는 23 서버에 유지하되, 공용 env 참조는 `/home/admin/workspace-config/runtime.env`, `/home/admin/workspace-config/secrets.env`만 사용하게 고정합니다.
- `auth-server`도 같은 23 제어면에 유지하고, gateway와 동일한 공용 env 기준을 사용합니다.

## 실행 순서

### 1. 배포 기준값을 먼저 24 기준으로 고정한다

- 각 실행계 저장소의 `.env.deploy`를 `192.168.0.106:51124` 기준으로 바꾼다.
- `DEPLOY_PROJECT_DIR`는 현재 24 실제 경로와 일치하게 유지한다.
  - `skill-email`
  - `skill-news`
  - 기타 실제 24 저장 경로
- 하드코딩된 원격 경로가 남아 있는 워크플로우는 `DEPLOY_PROJECT_DIR` 기반으로 통일한다.
- 이번 1차 전환 범위 밖인 `skill-publish`는 배포 기준 변경 대상에서 제외하고, active 실행 자산만 먼저 24 기준으로 전환한다.

### 2. 24 서버 런타임 SSOT를 먼저 정리한다

- 24 서버에 `/home/admin/workspace-config/runtime.env`, `/home/admin/workspace-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 기준만 사용한다.
- `admin-dashboard`의 24 대상 URL 목록도 `192.168.0.106` 기준으로 함께 교정한다.

### 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`
  - `workspace-config`와 DB 의존성 확인
- 5순위: `rb8001`
  - 모든 하위 서비스와 23 인프라 연결이 열린 뒤 마지막 기동

### 5. 23 게이트웨이와 24 실행면 연결을 다시 검증한다

- 23 게이트웨이 upstream이 24 `rb8001`, `robeing-monitor`를 정확히 바라보는지 확인한다.
- `robeing-monitor` 외부 진입 경로는 gateway 경유 1개 경로만 남기고, 병행 경로가 있으면 제거한다.
- 외부 실서비스 도메인에서 핵심 경로를 검증한다.
  - 메시지 핵심 경로
  - 이메일 경로
  - 일정 경로
  - 모니터/통계 경로
- 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 서버에는 임시 실행계 컨테이너가 남지 않고, 인프라/제어면 역할만 남는다.
- 실서비스 도메인 기준 핵심 사용자 경로 검증 기록이 남는다.