# 260307 24서버 정상복구 초기서버 기준 계획

**작성일**: 2026-03-07  
**상태**: 완료 (2026-03-10 기준)  
**전제**: 작성 당시 51124는 빈 초기 서버에 가깝고, 51123이 `테스트 + 임시 운영` 역할을 겸하고 있었다.

---

## 1. 목표
- 51124를 다시 robeing 프로덕션 실행 서버로 복구한다.
- 51123의 임시 수용 상태를 종료하고, 원래 역할인 `테스트 + 보조 + 인프라`로 되돌린다.
- 복구 후에도 IP/경로/시크릿 변경이 대량 수정으로 번지지 않도록 SSOT 구조를 함께 정착시킨다.

## 2. 복구 원칙
1. 24는 처음부터 다시 쌓는다고 가정한다.
- 과거 상태를 추측 복원하지 않는다.
- 필요한 구성요소를 체크리스트로 다시 올린다.

2. 서비스보다 기반을 먼저 복구한다.
- OS/계정/권한/디렉터리/SSOT/네트워크가 먼저다.
- 이 기반 없이 컨테이너만 올리면 재장애 가능성이 높다.

3. 프로덕션 판정은 24에서만 확정한다.
- 23에서 정상인 것은 사전 검증 근거일 뿐이다.
- 최종 정상 판정은 24의 실제 헬스체크와 실경로 검증으로만 내린다.

## 3. 24 서버에 먼저 갖춰야 할 것
### 3.1 운영 기본 계층
- 배포 사용자 계정 및 SSH 접근
- Docker / Docker Compose
- 기본 로그 경로
- 시스템 시간대, 방화벽, 필수 패키지
- 재부팅 후 자동 기동 정책(systemd 또는 compose 운영 규칙)

### 3.2 프로젝트 루트 구조
- `/home/admin/robeing`
- `/home/admin/workspace-config`
- 서비스별 배포 루트 경로
- 로그/데이터/마운트 경로

### 3.3 설정 SSOT 계층
- `/home/admin/workspace-config/runtime.env`
- `/home/admin/workspace-config/secrets.env`
- 서비스별 `.env`는 비워 두거나 로컬 오버라이드 전용으로 유지
- IP/포트/내부 호스트/외부 연계 주소는 runtime.env 기준으로만 관리

### 3.4 네트워크/연계
- 24 -> 23 DB 접근 확인
- 24 -> NAS 또는 대체 스토리지 접근 확인
- 23 gateway가 24 upstream으로 다시 붙을 수 있는지 확인
- 헬스체크/내부 포트/UFW 정책 선반영

## 4. 복구 대상 서비스
### 4.1 우선 복구
- `rb8001`
- `skill-email`
- `skill-calendar`
- `skill-news`
- `skill-slack`
- `skill-rag-file`
- `skill-embedding`
- `ChromaDB`

### 4.2 조건부 복구
- `robeing-monitor`
- 기타 실험/보조 컨테이너

원칙:
- 프로덕션 핵심 경로를 먼저 복구한다.
- 모니터링/실험 서비스는 핵심 경로 안정화 후 붙인다.

## 5. 단계별 실행 계획
### 5.1 Phase 1: 바닥 공사
- 24 서버 기본 패키지, Docker, 사용자 권한, SSH 키, 방화벽 구성
- 프로젝트 루트 디렉터리 생성
- `infra-config` 배치 및 권한 적용
- Gitea Actions가 접근할 배포 경로 생성

완료 기준:
- SSH 접속 가능
- Docker 실행 가능
- 배포 경로/권한 오류 없음

### 5.2 Phase 2: 설정 이식
- 23 기준 운영값 중 24에 필요한 항목만 선별
- `runtime.env`와 `secrets.env`에 반영
- 하드코딩 IP/경로가 남아 있는 서비스는 이 단계에서 제거

완료 기준:
- 각 서비스 compose가 24에서 동일한 SSOT 파일을 읽음
- 서비스 내부 코드에 23 전용 하드코딩이 남아 있지 않음

### 5.3 Phase 3: 데이터/스토리지 연계
- PostgreSQL 연결 확인
- ChromaDB 볼륨 및 데이터 경로 확인
- NAS 또는 공유 스토리지 마운트 확인
- 로그 저장 경로 확인

완료 기준:
- DB read/write 정상
- 필요한 파일 마운트가 실제 경로에서 읽힘
- 로그가 지정 경로에 기록됨

### 5.4 Phase 4: 서비스 기동
- 핵심 서비스부터 `docker compose down && docker compose up -d --build`
- 각 서비스별 헬스체크 확인
- 컨테이너 포트/네트워크 실제 바인딩 확인

완료 기준:
- `docker ps` 기준 핵심 컨테이너 running/healthy
- 서비스별 health endpoint 응답 정상

### 5.5 Phase 5: 23과 연결 복구
- 23 gateway upstream을 24 기준으로 재설정
- auth / gateway / upstream 로그를 같은 요청 기준으로 대조
- 실제 도메인 기준 요청 흐름 검증

완료 기준:
- `ro-being.com` 실제 경로에서 핵심 API 응답 정상
- gateway/nginx/upstream 로그가 한 요청 기준으로 이어짐

### 5.6 Phase 6: 역할 정상화
- 24를 프로덕션으로 확정
- 23의 임시 실행 컨테이너 정리
- 23을 다시 `테스트 + 보조 + 인프라` 역할로 축소
- 임시 예외 설정 제거 여부 확인

완료 기준:
- 프로덕션 트래픽 기준 서버가 24로 고정됨
- 23은 테스트/보험 역할만 수행

## 6. 검증 체크리스트
1. 인프라
- SSH, Docker, disk, memory, UFW 정상

2. 데이터
- 24에서 PostgreSQL 연결 정상
- ChromaDB 경로/볼륨 정상
- 공유 스토리지 접근 정상

3. 서비스
- `rb8001` health 정상
- 핵심 스킬 health 정상
- monitor 필요 시 health 정상

4. 요청 흐름
- 실제 도메인에서 gateway -> upstream 응답 정상
- 인증 경로 정상
- 로그가 요청 단위로 추적 가능

5. 운영
- Actions 배포 성공
- 재기동 후 자동 복구 가능
- 23/24 역할 문서와 실제 구성이 일치

## 7. 실패 패턴 경계
- 23의 임시값을 24 복구값으로 착각하는 것
- `.env`, compose, 코드, 문서가 각각 다른 값을 갖는 것
- 컨테이너만 살아 있고 실제 도메인 요청은 실패하는 상태를 정상으로 오판하는 것
- 24 복구 전에 23 임시 설정을 정리해 버리는 것

## 8. 복구 완료 선언 조건
- 24에서 핵심 서비스가 healthy
- 실제 도메인 기준 핵심 경로 응답 정상
- 23 gateway와 24 upstream 연결 정상
- 문서, runtime.env/secrets.env, 배포 경로가 서로 일치
- 23 임시운영 예외 항목이 후속 문서에 정리됨

## 9. 후속 문서 연결
- [260303_23테스트보조_24프로덕션_운영전환_계획](./260303_23테스트보조_24프로덕션_운영전환_계획.md)
- [260304_24장애시_23자동임시프로덕션전환_계획](./260304_24장애시_23자동임시프로덕션전환_계획.md)
- [260304_51123_임시복구_서비스연속성_조치내역](../troubleshooting/260304_51123_임시복구_서비스연속성_조치내역.md)
- [260307_gateway_SSOT_runtime_secrets_분리_적용_및_검증](../troubleshooting/260307_gateway_SSOT_runtime_secrets_분리_적용_및_검증.md)