---
tags: [infra, gitea-actions, deploy, 24-server, runtime, research]
---

# 24 자동배포 0초 종료와 runtime SSOT 불일치 리서치

## 관련 문서
- [24 자동배포 0초 종료와 runtime SSOT 불일치 이슈](../troubleshooting/260311_24자동배포_0초종료_runtime_ssot불일치_이슈.md)
- [24서버 robeing runtime workspace-config 단일화](../worklog/260310_24서버_robeing_runtime_workspace_config_단일화.md)
- [24서버 우분투 터미널 불가, 네트워크 대역 오류, python3-apt 복구 기록](../troubleshooting/260309_24서버_우분투터미널불가_네트워크대역오류_python3apt복구.md)
- [23임시배포 env.deploy SSOT 및 배포실패 근본원인 해결](../troubleshooting/260305_23임시배포_envdeploy_ssot_및_배포실패_근본원인_해결.md)

## 목적
- 이번 자동 배포 `0s` 종료를 `애플리케이션 문제`가 아니라 `인프라 배포 경로 SSOT 불일치` 관점에서 닫기 위한 확인 포인트를 정리한다.

## 확인된 SSOT
- 24 실행 서버 기준 주소: `192.168.0.106`
- 과거 24 주소: `192.168.219.52` 사용 금지
- 24 실행면 공통 런타임 값 기준: `/home/admin/workspace-config/runtime.env`, `/home/admin/workspace-config/secrets.env`
- 배포 경로 기준: 서비스별 하드코딩이 아니라 workflow 변수/secret의 단일 기준 사용

## 이번 문제에 가장 가까운 원인 후보
1. `SSH_HOST_51124` 또는 대응 secret/variable이 아직 구 IP를 가리킨다.
2. SSH 포트가 현재 실제 접속 규칙과 어긋난다.
3. workflow가 `DEPLOY_PROJECT_DIR` 대신 오래된 절대경로를 사용한다.
4. runner는 뜨지만 실제 task가 시작 조건을 못 맞춰 즉시 종료된다.

## 이번 이슈에서 중요한 해석
- 수동 배포가 같은 서버에서 정상 성공했기 때문에 `rb8001` 코드, Dockerfile, compose 자체가 주원인일 가능성은 낮다.
- 따라서 우선순위는 `workflow 정의`, `Actions secret/variable`, `23 -> 24 SSH 대상값` 검증이다.
- 기존 인프라 문서와도 일치하게, 이런 배포 실패는 대개 애플리케이션보다 `경로/권한/런타임 값`의 단일 기준 붕괴에서 발생한다.

## 닫힘에 필요한 최소 확인
- `cicd.yml`의 실제 deploy host/port/path 참조값
- Gitea Actions secret/variable의 현재값이 24 SSOT와 일치하는지
- 23 제어면에서 24 실행면으로 SSH가 실제 성공하는지
- task가 왜 `0s`로 끝났는지 runner/task 로그 확인

## 결론
- 현재 가장 강한 가설은 `24 runtime SSOT는 192.168.0.106으로 정리됐지만, 자동 배포 경로 일부는 아직 그 기준으로 완전히 수렴하지 않았다`는 것이다.