fix: 51123 서버 IP 주소 업데이트 (성수 이전)

192.168.219.45 → 192.168.0.100 일괄 변경

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

journey/plans/260309_24서버_실서비스운영전환_계획.md

@@ -80,7 +80,7 @@ tags: [infra, 24-server, robeing, production-transition, ssot, plans]
 - 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`
+  - `192.168.0.100`
   - `/home/admin/ivada_project/...`
 - 23 인프라를 바라보는 값은 현재 기준으로 통일한다.
   - DB: `192.168.0.100:5432`
@@ -132,7 +132,7 @@ tags: [infra, 24-server, robeing, production-transition, ssot, plans]
 
 - `.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`가 없다.
+- `.env`, compose fallback, workflow에 `192.168.0.100`, `192.168.219.52`, `/home/admin/ivada_project`가 없다.
 - `docker compose down && docker compose up -d --build` 후 헬스체크가 통과한다.
 
 ### 인프라 의존성
@@ -162,7 +162,7 @@ tags: [infra, 24-server, robeing, production-transition, ssot, plans]
 ## 완료 조건
 
 - 자동배포 기준이 다시 24 서버를 향한다.
-- 24 런타임 파일 기준 `192.168.219.45`, `192.168.219.52`, `/home/admin/ivada_project` 실행 경로가 0건이다.
+- 24 런타임 파일 기준 `192.168.0.100`, `192.168.219.52`, `/home/admin/ivada_project` 실행 경로가 0건이다.
 - 24 1차 전환 대상 컨테이너가 모두 정상 기동한다.
 - 23 서버에는 임시 실행계 컨테이너가 남지 않고, 인프라/제어면 역할만 남는다.
 - 실서비스 도메인 기준 핵심 사용자 경로 검증 기록이 남는다.

journey/plans/260309_51123_구IP하드코딩_실행경로제거_계획.md

@@ -29,7 +29,7 @@ tags: [infra, 51123, ip, ssot, runtime, plans]
 ### 완료 처리된 항목
 - `robeing-gateway/docker-compose.yml`의 공용 env 경로는 `workspace-config/runtime.env`, `workspace-config/secrets.env` 기준으로 교정되고 재기동까지 검증됐다.
 - 24 active runtime `rb8001`, `skill-email`, `skill-calendar`, `skill-slack`, `skill-rag-file`, `robeing-monitor`는 `workspace-config`를 공통 런타임 SSOT로 읽도록 정리됐다.
-- 24 active runtime의 compose/.env/컨테이너 env 기준 `192.168.219.45` 제거와 `192.168.0.100` 기준 주입이 검증됐다.
+- 24 active runtime의 compose/.env/컨테이너 env 기준 `192.168.0.100` 제거와 `192.168.0.100` 기준 주입이 검증됐다.
 - `5432/tcp`, `7687/tcp`, `8001`, `9024`의 23↔24 인프라 경로와 실제 서비스 헬스가 복구됐다.
 - `MONITOR_URL` 구주소 잔존 문제는 `http://192.168.0.106:9024`로 교정됐고, 실도메인 기준 `stats/preferences` 전 경로가 `200`으로 검증됐다.
 
@@ -41,7 +41,7 @@ tags: [infra, 51123, ip, ssot, runtime, plans]
 
 ## 목표
 - 51123 주소 기준을 `/home/admin/workspace-config/runtime.env`의 `HOST_51123=192.168.0.100`으로 단일화한다.
-- active runtime에서 `192.168.219.45`를 실제로 사용하는 경로를 제거한다.
+- active runtime에서 `192.168.0.100`를 실제로 사용하는 경로를 제거한다.
 - 코드 기본값과 compose fallback에서 과거 IP를 제거해, 재빌드와 복구 시에도 구 IP가 다시 살아나지 않게 한다.
 
 ## 변경 대상 범위
@@ -66,7 +66,7 @@ tags: [infra, 51123, ip, ssot, runtime, plans]
 - 상태: active runtime 기준 대부분 완료. 다만 관련 잔존 참조의 전수 증명은 `admin-dashboard` 포함 최종 점검 후 닫는다.
 
 ## 실행 원칙
-- 과거 IP `192.168.219.45`를 새 값과 병행 허용하지 않는다.
+- 과거 IP `192.168.0.100`를 새 값과 병행 허용하지 않는다.
 - "안 되면 예전 IP로 재시도" 같은 폴백을 추가하지 않는다.
 - IP literal 대신 의미 있는 환경변수 또는 현재 SSOT 값만 참조하게 바꾼다.
 - 문서 수정만으로 닫지 않고, 재빌드와 실연결 검증까지 완료해야 닫는다.
@@ -98,11 +98,11 @@ tags: [infra, 51123, ip, ssot, runtime, plans]
 ### 3. 재배포와 재검증
 - 변경 서비스별로 `docker compose down && docker compose up -d --build`로 재기동한다.
 - 컨테이너 env, TCP 연결, 헬스체크, 로그를 다시 확인한다.
-- `192.168.219.45`로 향하는 연결 시도가 남지 않았는지 재검색한다.
+- `192.168.0.100`로 향하는 연결 시도가 남지 않았는지 재검색한다.
 
 ## 검증 계획
 ### 1. 설정 검증
-- 실행 경로 파일 검색에서 `192.168.219.45`가 0건인지 확인한다.
+- 실행 경로 파일 검색에서 `192.168.0.100`가 0건인지 확인한다.
 - `.env`와 `docker compose config`에서 과거 IP가 0건인지 확인한다.
 - 컨테이너 env에서 `AUTH_SERVER_URL`, `DATABASE_URL`, OpenSearch host 관련 값에 과거 IP가 없는지 확인한다.
 
@@ -114,7 +114,7 @@ tags: [infra, 51123, ip, ssot, runtime, plans]
 - 컨테이너 내부에서도 같은 경로를 다시 확인한다.
 
 ### 3. 로그 검증
-- `data-prepper`에서 `Timeout connecting to [/192.168.219.45:9200]`가 사라졌는지 확인한다.
+- `data-prepper`에서 `Timeout connecting to [/192.168.0.100:9200]`가 사라졌는지 확인한다.
 - `skill-email`, `skill-calendar`에서 과거 IP 대상 연결 실패 로그가 없는지 확인한다.
 
 ### 4. 완료 검증
@@ -122,7 +122,7 @@ tags: [infra, 51123, ip, ssot, runtime, plans]
 - `admin-dashboard` 재배포 전 코드 fallback 제거 상태를 별도 점검한다.
 
 ## 완료 판단 기준
-- active runtime 컨테이너 `skill-email`, `skill-calendar`, `data-prepper`가 더 이상 `192.168.219.45`를 사용하지 않는다.
+- active runtime 컨테이너 `skill-email`, `skill-calendar`, `data-prepper`가 더 이상 `192.168.0.100`를 사용하지 않는다.
 - code default와 compose fallback에서 과거 IP literal이 제거된다.
 - 실행 경로에서 `/home/admin/infra-config/*.env` 참조가 0건이고, 공용 env는 `workspace-config`만 사용한다.
 - TCP 연결, 헬스체크, 로그 재검증에서 과거 IP timeout이 재현되지 않는다.

journey/research/260309_24서버_로빙운영_자료수집.md

@@ -90,7 +90,7 @@ tags: [infra, 24-server, robeing, operations, ssot, research]
 
 ### 8. SSOT 관점에서 바로 보이는 충돌/공백이 있다
 
-- `robeing/AGENTS.md`는 아직 `192.168.219.52`, `192.168.219.45`, `/home/admin/ivada_project/...`를 기준으로 설명합니다.
+- `robeing/AGENTS.md`는 아직 `192.168.219.52`, `192.168.0.100`, `/home/admin/ivada_project/...`를 기준으로 설명합니다.
 - `robeing/DOCS/book/300_architecture/310_전체_시스템_구조_컨테이너와_마이크로서비스.md`와 `325_robeing_monitor_모니터링_아키텍처.md`도 과거 IP 기준 설명을 유지합니다.
 - 현재 공용 운영값 파일은 `/home/admin/workspace-config/runtime.env`, 민감값 파일은 `/home/admin/workspace-config/secrets.env`로 24 서버에도 존재합니다.
 - 다만 이 문서는 자료 위치를 모으는 문서일 뿐이고, 실제 차단 요인은 [24서버 실서비스 운영전환 리서치](./260309_24서버_실서비스운영전환_리서치.md)에서 따로 확정해야 합니다.

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

@@ -49,7 +49,7 @@ tags: [infra, 24-server, robeing, production-transition, ssot, research]
 ### 4. 현재 자동배포 기준값은 여전히 23 서버를 가리킨다
 
 - 23 서버 저장소의 `.env.deploy` 값은 다음과 같이 남아 있다.
-  - `DEPLOY_SSH_HOST=192.168.219.45`
+  - `DEPLOY_SSH_HOST=192.168.0.100`
   - `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 서버 값으로 전환하면 된다`고 기록한다.
@@ -60,11 +60,11 @@ tags: [infra, 24-server, robeing, production-transition, ssot, research]
 - 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 기준이라는 점이다.
+- 따라서 현재 배포 차단 요인은 경로 불일치가 아니라, `DEPLOY_SSH_HOST=192.168.0.100`, `DEPLOY_SSH_PORT=51123`처럼 배포 대상이 아직 23 기준이라는 점이다.
 
 ### 6. 24 서버 런타임 값에는 아직 과거 23 서버 주소가 남아 있다
 
-- 24 서버 `.env` 확인 결과, 아래 서비스들이 아직 `192.168.219.45`를 직접 사용한다.
+- 24 서버 `.env` 확인 결과, 아래 서비스들이 아직 `192.168.0.100`를 직접 사용한다.
   - `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`
@@ -73,8 +73,8 @@ tags: [infra, 24-server, robeing, production-transition, ssot, research]
   - `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-email/docker-compose.yml`: `AUTH_SERVER_URL` fallback이 `http://192.168.0.100:9000`
-  - `skill-calendar/docker-compose.yml`: `DATABASE_URL` fallback이 `postgresql://...@192.168.219.45:5432/main_db`
+  - `skill-calendar/docker-compose.yml`: `DATABASE_URL` fallback이 `postgresql://...@192.168.0.100: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"`

journey/research/260309_51123_구IP하드코딩_실행경로_SSOT불일치_리서치.md

@@ -28,7 +28,7 @@ tags: [infra, 51123, ip, ssot, runtime, research]
   - `MONITOR_URL=http://192.168.0.100:9024`
 - `/home/admin/workspace-config/secrets.env`에는 `ROBEING_MONITOR_DATABASE_URL=postgresql://robeings:robeings@192.168.0.100:5432/main_db`가 기록돼 있다.
 
-### 2. 과거 IP `192.168.219.45`는 실행 경로에도 아직 남아 있다
+### 2. 과거 IP `192.168.0.100`는 실행 경로에도 아직 남아 있다
 - 문서를 제외하고 검색했을 때 과거 IP가 남은 주요 실행 경로는 다음과 같다.
   - `auth-server/app/providers/gmail_passport.py`
   - `fluent-bit/data-prepper/pipelines.yaml`
@@ -44,46 +44,46 @@ tags: [infra, 51123, ip, ssot, runtime, research]
   - `auth-server`
     - `DATABASE_URL=postgresql://robeings:robeings@host.docker.internal:5432/main_db`
   - `skill-email`
-    - `AUTH_SERVER_URL=http://192.168.219.45:9000`
+    - `AUTH_SERVER_URL=http://192.168.0.100:9000`
-    - `DATABASE_URL=postgresql://robeings:robeings@192.168.219.45:5432/main_db`
+    - `DATABASE_URL=postgresql://robeings:robeings@192.168.0.100:5432/main_db`
   - `skill-calendar`
-    - `DATABASE_URL=postgresql://robeings:robeings@192.168.219.45:5432/main_db`
+    - `DATABASE_URL=postgresql://robeings:robeings@192.168.0.100:5432/main_db`
   - `robeing_monitor`
     - `HOST_51123=192.168.0.100`
     - `DATABASE_URL=postgresql://robeings:robeings@192.168.0.100:5432/main_db`
     - `MONITOR_URL=http://192.168.0.100:9024`
-- `data-prepper`는 env가 아니라 `pipelines.yaml`의 sink host를 사용하며, 현재 설정값이 `http://192.168.219.45:9200`다.
+- `data-prepper`는 env가 아니라 `pipelines.yaml`의 sink host를 사용하며, 현재 설정값이 `http://192.168.0.100:9200`다.
 
 ### 3-1. `skill-email`, `skill-calendar`의 주입 원천은 `.env`로 확정됐다
 - `/home/admin/robeing/skill-email/.env`에는 아래 값이 직접 기록돼 있다.
-  - `AUTH_SERVER_URL=http://192.168.219.45:9000`
+  - `AUTH_SERVER_URL=http://192.168.0.100:9000`
-  - `DATABASE_URL=postgresql://robeings:robeings@192.168.219.45:5432/main_db`
+  - `DATABASE_URL=postgresql://robeings:robeings@192.168.0.100:5432/main_db`
-  - `POSTGRES_CONNECTION_STRING=postgresql://robeings:robeings@192.168.219.45:5432/main_db`
+  - `POSTGRES_CONNECTION_STRING=postgresql://robeings:robeings@192.168.0.100:5432/main_db`
 - `/home/admin/robeing/skill-calendar/.env`에는 아래 값이 직접 기록돼 있다.
-  - `DATABASE_URL=postgresql://robeings:robeings@192.168.219.45:5432/main_db`
+  - `DATABASE_URL=postgresql://robeings:robeings@192.168.0.100:5432/main_db`
 - `docker compose ... config` 확인 결과, 두 서비스 모두 `.env` 값이 최종 environment로 해석돼 컨테이너에 주입된다.
 - 따라서 `skill-email`, `skill-calendar`의 현재 과거 IP 사용 원천은 "미확정 fallback"이 아니라 `.env`의 직접 주입으로 확정된다.
 
 ### 4. active runtime의 과거 IP 경로는 실제로 timeout을 낸다
 - 23 서버 호스트에서 TCP 확인 결과:
-  - `192.168.219.45:9000` -> `tcp_fail timed out`
+  - `192.168.0.100:9000` -> `tcp_fail timed out`
   - `192.168.0.100:9000` -> `tcp_ok`
-  - `192.168.219.45:5432` -> `tcp_fail timed out`
+  - `192.168.0.100:5432` -> `tcp_fail timed out`
   - `192.168.0.100:5432` -> `tcp_ok`
-  - `192.168.219.45:9200` -> `tcp_fail timed out`
+  - `192.168.0.100:9200` -> `tcp_fail timed out`
   - `192.168.0.100:9200` -> `tcp_ok`
 - `skill-email` 컨테이너 내부에서 TCP 확인 결과:
-  - `192.168.219.45:9000` -> `tcp_fail timed out`
+  - `192.168.0.100:9000` -> `tcp_fail timed out`
   - `192.168.0.100:9000` -> `tcp_ok`
 - `skill-calendar` 컨테이너 내부에서 TCP 확인 결과:
-  - `192.168.219.45:5432` -> `tcp_fail timed out`
+  - `192.168.0.100:5432` -> `tcp_fail timed out`
   - `192.168.0.100:5432` -> `tcp_ok`
 - `data-prepper` 로그에는 아래 패턴이 반복 기록된다.
-  - `Failed to initialize OpenSearch sink, retrying: Timeout connecting to [/192.168.219.45:9200]`
+  - `Failed to initialize OpenSearch sink, retrying: Timeout connecting to [/192.168.0.100:9200]`
 
 ### 5. active runtime 후보이지만 현재 직접 장애 경로로 확인되지 않은 항목도 있다
 - `auth-server`는 compose fallback에 `host.docker.internal:5432`를 사용하고 있고, 현재 컨테이너 env도 그 값으로 주입돼 있다.
-- 따라서 `auth-server/app/providers/gmail_passport.py`의 `192.168.219.45` 기본값은 코드 fallback 잔존이지만, 현재 컨테이너에서는 그 경로가 직접 사용 중이라고 확인되지는 않았다.
+- 따라서 `auth-server/app/providers/gmail_passport.py`의 `192.168.0.100` 기본값은 코드 fallback 잔존이지만, 현재 컨테이너에서는 그 경로가 직접 사용 중이라고 확인되지는 않았다.
 - 24 서버의 `admin-dashboard` 코드에는 23 서버 fallback 구조가 존재하지만, 2026-03-09 현재 24 서버 `docker ps`는 빈 상태였고 해당 컨테이너는 active runtime으로 확인되지 않았다.
 - 과거 `ivada_project` 경로는 현재 워크스페이스에서 이미 제거돼, 이번 리서치 범위에서는 active 실행 경로 후보에서 제외한다.
 
@@ -109,7 +109,7 @@ tags: [infra, 51123, ip, ssot, runtime, research]
 ## Interpretation
 
 ### 1. 문제는 “문서 잔존”이 아니라 “실행 중 서비스가 과거 IP를 실제 사용 중”인 상태다
-- `skill-email`, `skill-calendar`, `data-prepper`는 현재도 과거 IP `192.168.219.45`를 런타임 값으로 사용한다.
+- `skill-email`, `skill-calendar`, `data-prepper`는 현재도 과거 IP `192.168.0.100`를 런타임 값으로 사용한다.
 - 이 세 경로는 단순 잔존 문자열이 아니라, 실제 연결 시도와 실제 timeout 로그로 검증된 active 장애 경로다.
 
 ### 2. SSOT는 만들어졌지만 active runtime까지 치환되지 않았다

journey/troubleshooting/250731_로그저장소_SSHFS설정과_템플릿해결책.md

@@ -37,13 +37,13 @@ sudo apt install -y sshfs
 sudo mkdir -p /mnt/51123logs
 
 # 3. 마운트 시도 (초기 실패 - SSH 키 문제)
-sudo sshfs -o allow_other,reconnect admin@192.168.219.45:/mnt/hdd/logs/51124-server /mnt/51123logs -p 51123
+sudo sshfs -o allow_other,reconnect admin@192.168.0.100:/mnt/hdd/logs/51124-server /mnt/51123logs -p 51123
 ```
 
 ### 오후 10시 51분 - SSHFS 마운트 성공
 ```bash
 # 1. SSH 키 파일 지정하여 마운트
-sshfs -o IdentityFile=/home/admin/.ssh/id_rsa_deploy admin@192.168.219.45:/mnt/hdd/logs/51124-server /mnt/51123logs -p 51123
+sshfs -o IdentityFile=/home/admin/.ssh/id_rsa_deploy admin@192.168.0.100:/mnt/hdd/logs/51124-server /mnt/51123logs -p 51123
 
 # 2. 마운트 확인
 df -h /mnt/51123logs

journey/troubleshooting/251014_skill-rag-file_sshfs_allow_other_해결.md

@@ -55,13 +55,13 @@ user_allow_other
 sudo fusermount -u /mnt/51123data
 
 # allow_other 옵션 추가하여 재마운트
-sshfs -o allow_other,default_permissions,IdentityFile=/home/admin/.ssh/id_rsa_deploy,reconnect,uid=1001,gid=1000 admin@192.168.219.45:/mnt/hdd/data /mnt/51123data -p 51123
+sshfs -o allow_other,default_permissions,IdentityFile=/home/admin/.ssh/id_rsa_deploy,reconnect,uid=1001,gid=1000 admin@192.168.0.100:/mnt/hdd/data /mnt/51123data -p 51123
 ```
 
 **마운트 옵션 확인**:
 ```bash
 mount | grep 51123data
-# admin@192.168.219.45:/mnt/hdd/data on /mnt/51123data type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=1001,group_id=1000,default_permissions,allow_other)
+# admin@192.168.0.100:/mnt/hdd/data on /mnt/51123data type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=1001,group_id=1000,default_permissions,allow_other)
 ```
 
 ### 3단계: docker-compose.yml 볼륨 추가
@@ -133,7 +133,7 @@ user_allow_other
 
 ### SSHFS 마운트 명령
 ```bash
-sshfs -o allow_other,default_permissions,IdentityFile=/home/admin/.ssh/id_rsa_deploy,reconnect,uid=1001,gid=1000 admin@192.168.219.45:/mnt/hdd/data /mnt/51123data -p 51123
+sshfs -o allow_other,default_permissions,IdentityFile=/home/admin/.ssh/id_rsa_deploy,reconnect,uid=1001,gid=1000 admin@192.168.0.100:/mnt/hdd/data /mnt/51123data -p 51123
 ```
 
 ### docker-compose.yml

journey/troubleshooting/260303_51123_DB5432_차단사고_복구_및_의존포트_점검.md

@@ -5,7 +5,7 @@
 - 원인 확인/복구: 2026-03-03 11:18~11:22 KST
 
 ## 문제 요약
-- 51124의 `skill-email`이 `192.168.219.45:5432` 연결 타임아웃으로 `ReadTimeout/500`을 반환.
+- 51124의 `skill-email`이 `192.168.0.100:5432` 연결 타임아웃으로 `ReadTimeout/500`을 반환.
 - 앱 로직 문제가 아니라 DB 접속 경로(포트 5432) 차단으로 인한 네트워크 레벨 장애.
 
 ## 직접 원인
@@ -38,7 +38,7 @@ sudo ufw allow from 192.168.219.52 to any port 5432 proto tcp
   - `7687/9000/8100/8000/9200 open`
 
 2. 컨테이너 내부
-- `skill-email` 컨테이너에서 `192.168.219.45:5432` TCP 연결 성공 (`tcp_ok`).
+- `skill-email` 컨테이너에서 `192.168.0.100:5432` TCP 연결 성공 (`tcp_ok`).
 - `skill-email` 컨테이너에서 `asyncpg`로 `select 1` 성공 (`asyncpg_ok 1`).
 
 3. 서비스
@@ -71,7 +71,7 @@ sudo ufw allow from 172.16.0.0/12 to any port 5432 proto tcp
   - `GET /messages?provider=naverworks&user_id=...&limit=3` -> `200 OK` (약 0.54s)
 
 ## 영향 범위 점검 결과 (51124 -> 51123 의존)
-다음 서비스/환경변수들이 `192.168.219.45:5432`를 사용 중:
+다음 서비스/환경변수들이 `192.168.0.100:5432`를 사용 중:
 - `skill_email`
 - `skill-calendar`
 - `skill-news`
@@ -90,7 +90,7 @@ sudo ufw allow from 172.16.0.0/12 to any port 5432 proto tcp
 
 ## 재발 방지
 1. 포트 하드닝 전 의존성 체크 필수
-- 51124에서 `192.168.219.45:<port>` 참조를 `.env`/`compose`에서 선조회
+- 51124에서 `192.168.0.100:<port>` 참조를 `.env`/`compose`에서 선조회
 
 2. 변경 절차 고정
 - `차단 전`: 의존 포트 목록 작성
@@ -135,6 +135,6 @@ sudo ufw status numbered
 
 # 51124에서 51123 연결 점검
 for p in 5432 3000 7474 7687 9000 8100 8000 9200; do
-  timeout 2 bash -lc "cat < /dev/null > /dev/tcp/192.168.219.45/$p" && echo "$p open" || echo "$p blocked"
+  timeout 2 bash -lc "cat < /dev/null > /dev/tcp/192.168.0.100/$p" && echo "$p open" || echo "$p blocked"
 done
 ```

journey/troubleshooting/260304_51123_임시복구_서비스연속성_조치내역.md

@@ -37,8 +37,8 @@
 
 ### 4.4 gateway 운영값 정합화
 - `/home/admin/robeing-gateway/.env` 수정:
-  - `ROBEING_DEFAULT_HOST=192.168.219.45`
+  - `ROBEING_DEFAULT_HOST=192.168.0.100`
-  - `MONITOR_URL="http://192.168.219.45:9024"`
+  - `MONITOR_URL="http://192.168.0.100:9024"`
 - 적용 방식: `docker compose down && docker compose up -d --build`
 
 ## 5. 검증 결과(2026-03-04)
@@ -85,10 +85,10 @@
   - `skill-rag-file` (`8508`) healthy
   - `skill-embedding` (`8515`) healthy
 - 헬스 응답 확인:
-  - `GET http://192.168.219.45:8505/health` -> `{"status":"healthy"}`
+  - `GET http://192.168.0.100:8505/health` -> `{"status":"healthy"}`
-  - `GET http://192.168.219.45:8502/health` -> healthy 응답
+  - `GET http://192.168.0.100:8502/health` -> healthy 응답
-  - `GET http://192.168.219.45:8508/healthz` -> healthy 응답
+  - `GET http://192.168.0.100:8508/healthz` -> healthy 응답
-  - `GET http://192.168.219.45:8515/healthz` -> `{"status":"ok"}`
+  - `GET http://192.168.0.100:8515/healthz` -> `{"status":"ok"}`
 
 ### 8.2 근본 원인과 조치(embedding)
 - 근본 원인:

journey/troubleshooting/260309_51123_구IP하드코딩_런타임SSOT불일치_이슈.md

@@ -19,7 +19,7 @@ tags: [infra, 51123, ip, ssot, runtime, troubleshooting]
 
 ## 문제 정의
 - 2026-03-09 현재 23 서버(51123)의 실제 운영 IP는 `192.168.0.100/24`이다.
-- 그러나 일부 운영 설정과 코드 기본값에는 과거 IP `192.168.219.45`가 아직 남아 있다.
+- 그러나 일부 운영 설정과 코드 기본값에는 과거 IP `192.168.0.100`가 아직 남아 있다.
 - 이 상태는 "문서가 오래됨" 수준의 문제가 아니라, 환경변수 누락 또는 fallback 경로 진입 시 서비스가 과거 주소로 접속을 시도할 수 있는 런타임 SSOT 불일치다.
 
 ## 확인된 사실
@@ -37,21 +37,21 @@ tags: [infra, 51123, ip, ssot, runtime, troubleshooting]
 - `/home/admin/infra-config/secrets.env`
   - `ROBEING_MONITOR_DATABASE_URL=postgresql://robeings:robeings@192.168.0.100:5432/main_db`
 
-### 3. 과거 IP `192.168.219.45`가 남아 있는 실행 경로
+### 3. 과거 IP `192.168.0.100`가 남아 있는 실행 경로
 - `auth-server/app/providers/gmail_passport.py`
-  - `DATABASE_URL` 기본값이 `192.168.219.45:5432`
+  - `DATABASE_URL` 기본값이 `192.168.0.100:5432`
 - `robeing/skill-email/docker-compose.yml`
-  - `AUTH_SERVER_URL` fallback이 `http://192.168.219.45:9000`
+  - `AUTH_SERVER_URL` fallback이 `http://192.168.0.100:9000`
 - `robeing/skill-calendar/docker-compose.yml`
-  - `DATABASE_URL` fallback이 `192.168.219.45:5432`
+  - `DATABASE_URL` fallback이 `192.168.0.100:5432`
 - `robeing/skill-calendar/services/google_calendar_service.py`
-  - `DATABASE_URL` 기본값이 `192.168.219.45:5432`
+  - `DATABASE_URL` 기본값이 `192.168.0.100:5432`
 - `fluent-bit/data-prepper/pipelines.yaml`
-  - OpenSearch 호스트가 `http://192.168.219.45:9200`
+  - OpenSearch 호스트가 `http://192.168.0.100:9200`
 - `robeing/admin-dashboard/backend/services/system_service.py`
-  - 서버 간 fallback 주소가 `192.168.219.45`
+  - 서버 간 fallback 주소가 `192.168.0.100`
 - `ivada_project/robeing-monitor/*`
-  - 구 경로 쪽 `DATABASE_URL` 기본값이 여전히 `192.168.219.45:5432`
+  - 구 경로 쪽 `DATABASE_URL` 기본값이 여전히 `192.168.0.100:5432`
 
 ## 왜 문제인가
 - 현재는 일부 서비스가 `runtime.env`를 먼저 읽어 우연히 정상 동작할 수 있다.
@@ -68,10 +68,10 @@ tags: [infra, 51123, ip, ssot, runtime, troubleshooting]
 - 51123 주소는 `/home/admin/infra-config/runtime.env`의 `HOST_51123=192.168.0.100`만 기준값으로 사용한다.
 - 코드 기본값과 compose fallback에 IP literal을 직접 넣지 않는다.
 - 서비스는 `HOST_51123`, `DATABASE_URL`, `AUTH_SERVER_URL`, `MONITOR_URL`처럼 의미 있는 환경변수만 참조한다.
-- 과거 IP `192.168.219.45`는 운영 실행 경로에서 0건이어야 한다.
+- 과거 IP `192.168.0.100`는 운영 실행 경로에서 0건이어야 한다.
 
 ## 우회가 아닌 해결 조건
-- `192.168.219.45`를 새 값과 병행 허용하지 않는다.
+- `192.168.0.100`를 새 값과 병행 허용하지 않는다.
 - "안 되면 과거 IP로 재시도" 같은 폴백을 추가하지 않는다.
 - 남아 있는 하드코딩/기본값을 제거하고, SSOT 값만 주입되도록 구조를 정리한다.
 
@@ -82,13 +82,13 @@ tags: [infra, 51123, ip, ssot, runtime, troubleshooting]
 4. 구 경로(`ivada_project`)처럼 현재 운영과 분리되지 않은 잔존 실행본
 
 ## 완료 판단 기준
-- 실행 경로 파일에서 `192.168.219.45` 검색 결과가 0건이다.
+- 실행 경로 파일에서 `192.168.0.100` 검색 결과가 0건이다.
 - 23 서버 기동 서비스가 모두 `192.168.0.100` 또는 명시 env만 참조한다.
 - 24 서버에서 23 서버 DB/인증/모니터 호출을 실제로 재검증해 과거 IP 경로가 다시 나오지 않는다.
 
 ## 2026-03-10 후속 확인
 - 24 서버(`/home/admin`)에는 `workspace-config/runtime.env`, `workspace-config/secrets.env`가 실제로 존재했고, 이 파일을 공통 런타임 기준으로 사용해야 한다는 계획 문서와 일치했습니다.
-- 그러나 실제 active runtime은 `rb8001`, `skill_email`, `skill-calendar`, `skill-slack`, `skill-rag-file`, `robeing-monitor` 일부가 서비스별 `.env`와 compose 재정의에 남은 `192.168.219.45`를 계속 사용하고 있었습니다.
+- 그러나 실제 active runtime은 `rb8001`, `skill_email`, `skill-calendar`, `skill-slack`, `skill-rag-file`, `robeing-monitor` 일부가 서비스별 `.env`와 compose 재정의에 남은 `192.168.0.100`를 계속 사용하고 있었습니다.
 - 따라서 문제의 실체는 "workspace-config 부재"가 아니라, `workspace-config`가 있어도 서비스가 이를 일관되게 읽지 않던 실행 구조였습니다.
 
 ### 2026-03-10 시점 직접 확인된 경로
@@ -108,7 +108,7 @@ tags: [infra, 51123, ip, ssot, runtime, troubleshooting]
 ### 2026-03-10 기준 해결 방향 재확인
 - 24 서버 런타임은 각 서비스 `.env`에 인프라 주소를 중복 보관하지 않고, `/home/admin/workspace-config/runtime.env`, `/home/admin/workspace-config/secrets.env`를 공통 기준으로 읽어야 합니다.
 - compose의 `environment:`에서 다시 같은 키를 재정의해 공통 env를 덮어쓰지 않도록 정리해야 합니다.
-- 구 IP `192.168.219.45`는 24 런타임의 active compose, 서비스 `.env`, 컨테이너 env에서 0건이어야 합니다.
+- 구 IP `192.168.0.100`는 24 런타임의 active compose, 서비스 `.env`, 컨테이너 env에서 0건이어야 합니다.
 
 ## 상위 원칙/근거 문서 연결
 - [Infra Project Identity](../../00_Philosophy/00_IDENTITY/Infra_Project_Identity.md)

journey/worklog/260309_24전환_배포대상과_ingress_24IP_교정_1차.md

@@ -19,7 +19,7 @@ tags: [infra, 24-server, deployment, ingress, worklog]
 - 대상 `.env.deploy` 파일들의 `DEPLOY_SSH_HOST`, `DEPLOY_SSH_PORT`는 모두 `192.168.0.106`, `51124`로 확인됐습니다.
 - `nginx -t`와 `systemctl reload nginx`는 모두 성공했습니다.
 - `http://127.0.0.1/rb8001/health`는 현재 `502 Bad Gateway`였는데, 이는 24의 `rb8001`이 아직 기동되지 않은 현재 상태를 그대로 보여주는 결과입니다.
-- 교정 대상 경로에서 `192.168.219.52`, `192.168.219.45` 잔존 검색은 0건이었습니다.
+- 교정 대상 경로에서 `192.168.219.52`, `192.168.0.100` 잔존 검색은 0건이었습니다.
 
 ## 한 줄 결론
 

journey/worklog/260309_51123_구IP_active_runtime_제거_1차.md

@@ -10,7 +10,7 @@ tags: [infra, 51123, ip, runtime, worklog]
 
 ## 작업
 
-- `skill-email`의 `.env`와 `docker-compose.yml`에서 `192.168.219.45` 기반 DB/auth 값을 `192.168.0.100`으로 교정하고, compose fallback을 `필수 env` 방식으로 바꿨습니다.
+- `skill-email`의 `.env`와 `docker-compose.yml`에서 `192.168.0.100` 기반 DB/auth 값을 `192.168.0.100`으로 교정하고, compose fallback을 `필수 env` 방식으로 바꿨습니다.
 - `skill-calendar`의 `.env`, `docker-compose.yml`, `services/google_calendar_service.py`에서 구 IP 기본값을 제거하고 `DATABASE_URL` 필수 주입 구조로 바꿨습니다.
 - `data-prepper/pipelines.yaml`의 OpenSearch sink를 `http://192.168.0.100:9200`으로 교정했고, `auth-server/app/providers/gmail_passport.py`도 구 IP 기본값 대신 `DATABASE_URL` 필수 주입 구조로 바꿨습니다.
 
@@ -19,7 +19,7 @@ tags: [infra, 51123, ip, runtime, worklog]
 - `docker compose config` 기준 `skill-email`, `skill-calendar`의 최종 환경변수는 모두 `192.168.0.100`으로 해석됐습니다.
 - 재기동 후 컨테이너 env는 `skill-email`의 `AUTH_SERVER_URL`, `DATABASE_URL`, `POSTGRES_CONNECTION_STRING`, `skill-calendar`의 `DATABASE_URL`, `auth-server`의 `DATABASE_URL`이 모두 현재 기준으로 잡혔습니다.
 - 헬스체크는 `http://127.0.0.1:8501/health` 200, `http://127.0.0.1:8512/health` 200, `http://127.0.0.1:9000/health` 200이 확인됐습니다.
-- `data-prepper`는 재기동 후 `Initialized OpenSearch sink` 로그가 기록됐고, 기존 `Timeout connecting to [/192.168.219.45:9200]` 반복 로그는 재현되지 않았습니다.
+- `data-prepper`는 재기동 후 `Initialized OpenSearch sink` 로그가 기록됐고, 기존 `Timeout connecting to [/192.168.0.100:9200]` 반복 로그는 재현되지 않았습니다.
 
 ## 한 줄 결론
 

journey/worklog/260310_24서버_robeing_runtime_workspace_config_단일화.md

@@ -27,13 +27,13 @@ tags: [infra, 24-server, robeing, workspace-config, runtime, worklog]
   - `skill-slack`
   - `skill-rag-file`
   - `robeing-monitor`
-- 서비스별 `.env`에 남아 있던 `192.168.219.45` 기반 DB/auth/gateway literal은 제거하거나 공통 env 주입 주석으로 대체했습니다.
+- 서비스별 `.env`에 남아 있던 `192.168.0.100` 기반 DB/auth/gateway literal은 제거하거나 공통 env 주입 주석으로 대체했습니다.
 - compose의 `environment:` 재정의 때문에 공통 env가 덮어써지던 항목(`DATABASE_URL`, `AUTH_SERVER_URL` fallback 등)도 함께 제거했습니다.
 
 ## 검증
-- 파일 검색 기준으로 `rb8001`, `skill_email`, `skill-calendar`, `skill-slack`, `skill-rag-file`, `robeing-monitor`, `workspace-config`의 active compose/.env 경로에서 `192.168.219.45`는 0건이었습니다.
+- 파일 검색 기준으로 `rb8001`, `skill_email`, `skill-calendar`, `skill-slack`, `skill-rag-file`, `robeing-monitor`, `workspace-config`의 active compose/.env 경로에서 `192.168.0.100`는 0건이었습니다.
 - `docker compose config` 기준으로 `rb8001`, `skill_email`, `skill-calendar`, `skill-slack`, `skill-rag-file`의 `DATABASE_URL`, `TEST_DATABASE_URL`, `METRICS_DATABASE_URL`, `POSTGRES_CONNECTION_STRING`, `AUTH_SERVER_URL`, `GATEWAY_URL`는 모두 `192.168.0.100` 기준으로 해석됐습니다.
-- 컨테이너 재생성 후 `docker inspect` 기준으로 `rb8001`, `skill-email`, `skill-calendar`, `skill-slack`, `skill-rag-file`, `robeing_monitor` env에서 구 IP `192.168.219.45`는 사라졌고, 공통 값은 `192.168.0.100`으로 주입됐습니다.
+- 컨테이너 재생성 후 `docker inspect` 기준으로 `rb8001`, `skill-email`, `skill-calendar`, `skill-slack`, `skill-rag-file`, `robeing_monitor` env에서 구 IP `192.168.0.100`는 사라졌고, 공통 값은 `192.168.0.100`으로 주입됐습니다.
 - 헬스체크는 `skill-calendar`, `skill-email`, `skill-slack`, `skill-rag-file`, `robeing_monitor`가 정상으로 확인됐습니다.
 
 ## 남은 사항