From 524937317509d758520ae66c5c7fb7f34d25dff8 Mon Sep 17 00:00:00 2001
From: happybell80 <happybell80@naver.com>
Date: Wed, 11 Mar 2026 21:27:09 +0900
Subject: [PATCH] docs: update runner evidence for 24 auto deploy incident

---
 ...��_0초종료_runtime_ssot복구_계획.md | 33 ++++++-----
 ...�종료_runtime_ssot불일치_리서치.md | 57 +++++++++++++------
 ...0초종료_runtime_ssot불일치_이슈.md | 32 +++++++++--
 3 files changed, 86 insertions(+), 36 deletions(-)

diff --git a/journey/plans/260311_24자동배포_0초종료_runtime_ssot복구_계획.md b/journey/plans/260311_24자동배포_0초종료_runtime_ssot복구_계획.md
index 60d9e8a..a3c385c 100644
--- a/journey/plans/260311_24자동배포_0초종료_runtime_ssot복구_계획.md
+++ b/journey/plans/260311_24자동배포_0초종료_runtime_ssot복구_계획.md
@@ -14,33 +14,38 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, plans]
 - [24서버 robeing runtime workspace-config 단일화](../worklog/260310_24서버_robeing_runtime_workspace_config_단일화.md)
 
 ## 결정
-- 이번 문제는 `rb8001` 코드가 아니라 `배포 인프라 경로` 문제로 다룬다.
-- 따라서 수정 우선순위는 `workflow가 읽는 .env.deploy 복구 -> 구주소 예시 제거 -> 필요 시 secret/variable화 -> SSH 검증 -> task 로그` 순서다.
+- 이번 문제는 `rb8001` 코드가 아니라 `배포 인프라 경로 + 51123 runner 실행층` 문제로 다룬다.
+- `c7bca94`로 `.env.deploy`와 예시 파일은 이미 SSOT에 맞춰졌으므로, 이제 수정 우선순위는 `runner 실행 복구 -> dispatch/task 로그 확인 -> workflow 본문 재진입 검증 -> 필요 시 secret/variable화` 순서다.
 
 ## 범위
 - 포함:
-  - `rb8001/.env.deploy` 실파일 복구 또는 대체 주입 경로 확정
-  - `.env.deploy.example`의 구주소/구포트 제거
+  - 51123 self-hosted runner 기동 상태 복구
+  - runner 시작 방식과 운영 기준(systemd vs script) 정리
+  - 최신 `#677`과 같은 `0s` 종료 run의 dispatch/task fetch 경로 확인
   - 24 배포 대상 host/port/path SSOT 확인
-  - Gitea Actions secret/variable 교정
-  - `cicd.yml` 하드코딩 경로 제거 또는 SSOT 기준 교정
+  - 필요 시 Gitea Actions secret/variable 교정
   - 실제 push 기반 자동 배포 재검증
 - 제외:
   - 애플리케이션 기능 수정
   - 24 runtime.env/secrets.env 구조 재설계
 
 ## 실행 단계
-1. `rb8001/.gitea/workflows/cicd.yml`의 deploy host/port/path 참조를 확인한다.
-2. `rb8001/.env.deploy`를 다른 서비스와 같은 형식으로 복구하고 `192.168.0.106:51124` 기준으로 맞춘다.
-3. `.env.deploy.example`의 구주소 `192.168.219.45:51123`를 제거한다.
-4. 필요 시 Gitea Actions secret/variable 기반으로 전환하되, 값 기준은 여전히 `192.168.0.106`, `51124`, 실제 배포 경로로 고정한다.
-5. 23 제어면에서 같은 값으로 24 실행면 SSH 접속이 실제 되는지 검증한다.
-6. 테스트 커밋 또는 재실행으로 Actions task가 실제 실행되고, 24 서버 컨테이너가 재시작되는지 검증한다.
+1. 51123에서 runner 프로세스, 시작 스크립트, 등록 정보(`/etc/act_runner/.runner`)를 기준으로 실제 기동 경로를 확정한다.
+2. `/home/admin/scripts/start-act-runner.sh` 기반 재기동 구조가 맞는지 확인하고, 같은 방식으로 runner를 재기동해 `ps -ef`, `act_runner.log`, Gitea DB `action_runner.last_online`이 현재 시각으로 갱신되는지 본다.
+3. backlog가 다시 흐르기 시작하는지 `action_task` 신규 row 생성과 pending queue 감소로 확인한다.
+4. `rb8001 #677`이 backlog를 통과하면 `action_run_job.task_id`가 `0`에서 실제 task id로 바뀌는지 확인한다.
+5. `rb8001/.gitea/workflows/cicd.yml`, `.env.deploy`, `.env.deploy.example`가 현재 SSOT(`192.168.0.106:51124`, `/home/admin/robeing/rb8001`)를 유지하는지 재확인한다.
+6. workflow가 본문에 진입하면 SSH 접속, `git pull`, `docker compose down && docker compose up -d --build`, health check까지 실제 로그를 확인한다.
+7. backlog를 지나도 `rb8001`만 `task_id=0`이면 `#677` 재실행 또는 새 push 재트리거로 개별 run 상태를 분리 진단한다.
+8. runner 재기동 후에도 `0s` 종료가 계속되면 Gitea의 runner online 상태, dispatch/task 저장 경로, repo-level Actions 설정을 추가로 점검한다.
+9. 복구 후 runner 운영 방식을 systemd 유닛 또는 동등한 자동복구 경로로 정리해, 수동 스크립트만 남는 단일 장애점을 제거한다.
 
 ## 완료 기준
-- `cicd.yml` task가 `0s` 종료가 아니라 실제 실행 로그를 남긴다.
+- `cicd.yml` task가 `0s` 종료가 아니라 checkout 이후 실제 실행 로그를 남긴다.
+- Gitea DB 기준 `action_run_job.task_id != 0`, `action_task` 신규 row 생성, `action_runner.last_online` 현재 시각 갱신이 확인된다.
+- backlog가 실제로 감소하고, `rb8001 #677`도 queue 대기에서 task 실행 상태로 전이된다.
 - `git push origin main` 후 24 서버 `rb8001` 컨테이너가 자동 재시작된다.
 - 수동 배포 없이도 `docker ps`, 헬스체크, 최신 커밋 반영이 확인된다.
 
 ## 한 줄 결론
-- 목표는 `24=192.168.0.106` SSOT를 Actions 배포 경로까지 일치시켜 자동 배포를 다시 신뢰 가능한 상태로 복구하는 것이다.
+- 목표는 `24=192.168.0.106` SSOT를 유지한 채 51123 self-hosted runner를 다시 실행 경로에 올려 `git push -> workflow 본문 실행 -> 24 자동 배포`를 복구하는 것이다.
diff --git a/journey/research/260311_24자동배포_0초종료_runtime_ssot불일치_리서치.md b/journey/research/260311_24자동배포_0초종료_runtime_ssot불일치_리서치.md
index cf228b2..1003a85 100644
--- a/journey/research/260311_24자동배포_0초종료_runtime_ssot불일치_리서치.md
+++ b/journey/research/260311_24자동배포_0초종료_runtime_ssot불일치_리서치.md
@@ -11,7 +11,7 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, research]
 - [23임시배포 env.deploy SSOT 및 배포실패 근본원인 해결](../troubleshooting/260305_23임시배포_envdeploy_ssot_및_배포실패_근본원인_해결.md)
 
 ## 목적
-- 이번 자동 배포 `0s` 종료를 `애플리케이션 문제`가 아니라 `인프라 배포 경로 SSOT 불일치` 관점에서 닫기 위한 확인 포인트를 정리한다.
+- 이번 자동 배포 `0s` 종료를 `애플리케이션 문제`가 아니라 `인프라 배포 경로 SSOT 불일치 -> 51123 runner 실행층` 순서로 좁혀 닫기 위한 확인 포인트를 정리한다.
 
 ## 확인된 SSOT
 - 24 실행 서버 기준 주소: `192.168.0.106`
@@ -19,23 +19,46 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, research]
 - 24 실행면 공통 런타임 값 기준: `/home/admin/workspace-config/runtime.env`, `/home/admin/workspace-config/secrets.env`
 - 배포 경로 기준: 서비스별 하드코딩이 아니라 workflow 변수/secret의 단일 기준 사용
 
-## 이번 문제에 가장 가까운 원인 후보
-1. `rb8001` 저장소에 `.env.deploy` 실파일이 없어 workflow가 시작 직후 필수 파일 검증에서 실패한다.
-2. `.env.deploy.example`가 아직 `192.168.219.45:51123`를 가리켜 복원하더라도 잘못된 값을 주입할 위험이 있다.
-3. repo-level Actions secrets/variables가 비어 있어, 현재 workflow를 대체할 다른 배포값 주입 경로도 없다.
-4. workflow가 `DEPLOY_PROJECT_DIR` 대신 오래된 절대경로를 사용한다.
+## Facts
+- 2026-03-11 `git -C /home/admin/robeing/rb8001 pull` 결과 `0313313..c7bca94`로 fast-forward 됐다.
+- 현재 `rb8001/.env.deploy`, `.env.deploy.example`는 모두 `192.168.0.106:51124`, `DEPLOY_PROJECT_DIR=/home/admin/robeing/rb8001` 기준으로 정렬돼 있다.
+- `rb8001/.gitea/workflows/cicd.yml`은 여전히 저장소 루트 `.env.deploy`를 직접 읽는 구조다.
+- 최신 run `#677`은 여전히 `0s` 종료로 보이며, workflow 본문 단계 로그가 확인되지 않았다.
+- 2026-03-11 51123에서 `ps -ef | rg 'act_runner|start-act-runner'` 기준 실행 중인 runner 프로세스가 없다.
+- 같은 시각 `systemctl is-active act_runner`는 `inactive`, `systemctl status act_runner`는 `Unit act_runner.service could not be found.`를 반환했다.
+- `/etc/act_runner/.runner`에는 `org-shared-runner`, `http://localhost:3000`, `self-hosted:host`가 등록돼 있다.
+- `/mnt/hdd/logs/act_runner/act_runner.log`의 마지막 성공 실행은 2026-03-05 `robeing-monitor` 배포였고, 마지막 오류는 2026-03-06 `failed to fetch task ... dial tcp 127.0.0.1:5432: connect: connection refused`다.
+- 2026-03-11 현재 `curl http://localhost:3000/api/healthz`는 pass이고, `ss -tlnp` 기준 `3000`, `5432`는 모두 listen 상태다.
+- Gitea DB `action_runner` 기준 runner id `4`의 `last_online`은 `2026-03-06 08:11:27+09`, `last_active`는 `2026-03-05 16:38:37+09`다.
+- Gitea DB `action_run` 기준 `rb8001` 최신 run `#677`은 `status=5`, `started=0`, `stopped=0` 상태다.
+- Gitea DB `action_run_job` 기준 `#677`의 `deploy` job은 `task_id=0`이다.
+- Gitea DB `action_task` 기준 `rb8001`의 마지막 task 생성은 `2026-03-05 16:23:25+09`다.
+- 2026-03-11 21:24 KST `sudo /home/admin/scripts/start-act-runner.sh` 실행 후 `act_runner daemon --config .runner` 프로세스가 다시 생성됐다.
+- 재기동 직후 `act_runner.log`에는 `Starting runner daemon`, `runner ... declare successfully`, 신규 task `2109`, `2110` 시작 로그가 남았다.
+- Gitea DB `action_runner` 기준 runner id `4`의 `last_online`, `last_active`는 `2026-03-11 21:25:15+09`로 갱신됐다.
+- 2026-03-11 21:25 KST 기준 pending run은 총 8건이며, `rb8001 #677` 앞에 더 이른 시각의 pending run 6건이 남아 있다.
 
-## 이번 이슈에서 중요한 해석
-- 수동 배포가 같은 서버에서 정상 성공했기 때문에 `rb8001` 코드, Dockerfile, compose 자체가 주원인일 가능성은 낮다.
-- 따라서 우선순위는 `workflow가 읽는 실제 배포값 파일(.env.deploy)`, `예시 파일의 구주소`, `보완용 secret/variable 부재` 확인이다.
-- 기존 인프라 문서와도 일치하게, 이런 배포 실패는 대개 애플리케이션보다 `경로/권한/런타임 값`의 단일 기준 붕괴에서 발생한다.
+## Interpretation
+- 수동 배포가 정상 성공하고, `.env.deploy` 계열도 `c7bca94` 이후 SSOT에 맞춰졌기 때문에 `rb8001` 코드나 현재 저장소 파일 상태만으로 최신 `0s` 종료를 설명하기는 어렵다.
+- 따라서 원인 후보 우선순위는 `배포 파일 부재`에서 `51123 self-hosted runner 실행층 중단`으로 이동한다.
+- 특히 runner 프로세스가 현재 없고 로그도 2026-03-06 이후 멈춰 있으므로, 최신 `#677`은 workflow 본문 실행 전 dispatch/task fetch 단계에서 종료됐을 가능성이 높다.
+- `action_run_job.task_id=0`와 `action_task` 신규 생성 부재가 함께 보여서, 최신 이슈는 `job 생성 후 task 할당이 되지 않는 상태`로 보는 것이 가장 근거가 강하다.
+- 다만 재기동 뒤 신규 task가 실제로 다시 생성되는 것이 확인됐으므로, 지금 남은 상태를 `runner fetch 경로 완전 불능`으로 보기는 어렵고 `backlog 복구 진행 중`으로 보는 편이 정확하다.
+- 다만 2026-03-06의 `127.0.0.1:5432 connection refused`가 단발성인지, runner 중단의 직접 원인인지, 현재 재시작 불가와 연결되는지는 아직 확정할 수 없다.
 
-## 닫힘에 필요한 최소 확인
-- `cicd.yml`의 실제 deploy host/port/path 참조값
-- `rb8001/.env.deploy` 실파일 존재 여부
-- `.env.deploy.example`의 구주소 제거 여부
-- Gitea Actions secret/variable 부재를 유지할지, 변수 기반으로 바꿀지 결정
-- task가 왜 `0s`로 끝났는지 runner/task 로그 확인
+## Unresolved
+- Gitea UI에서 runner가 현재 `online/offline` 중 어떤 상태로 표시되는지
+- `start-act-runner.sh`가 systemd 없이 수동 실행만 전제하는 구조가 의도된 운영 기준인지
+- `start-act-runner.sh`의 `act_runner daemon --config .runner`가 실제 재기동 실패와 연결되는지
+- 최신 `#677` dispatch/task가 Gitea DB에는 남았지만 runner가 fetch하지 못한 상태인지
+- runner 재기동 직후 `action_runner.last_online`이 현재 시각으로 갱신되는지
+- runner 재기동 후 `#677`이 기존 pending 상태에서 순차 처리되는지, 아니면 새 run을 만들어야 하는지
+- runner 재기동 후 동일 커밋 재실행 시 workflow 본문 로그가 실제로 생기는지
 
 ## 결론
-- 현재는 가설 수준을 넘어서, `rb8001` 자동 배포 경로가 `.env.deploy` 부재와 구주소 예시 파일 때문에 실제 SSOT에 수렴하지 않았음`이 실증된 상태다.
+- 현재는 `rb8001 deploy SSOT 불일치`가 1차 원인이었음은 확인됐지만, 2026-03-11 기준 남아 있는 최신 `0s` 종료는 `51123 self-hosted runner 실행층 중단`이 더 가까운 원인 후보다.
+
+## 권장
+- 1순위: `/home/admin/scripts/start-act-runner.sh`로 runner를 재기동하고 `ps -ef`, `act_runner.log`, `action_runner.last_online` 갱신 여부를 동시에 확인한다.
+- 2순위: backlog가 실제로 줄어드는지 확인하고, `rb8001 #677`이 대기열을 지나도 `task_id=0`이면 그때 `#677` 재실행 또는 새 push로 재트리거한다.
+- 3순위: runner 복구가 확인되면 수동 스크립트 의존을 줄이기 위해 systemd 유닛화 또는 동등한 부팅 자동복구 경로를 별도 계획으로 승격한다.
diff --git a/journey/troubleshooting/260311_24자동배포_0초종료_runtime_ssot불일치_이슈.md b/journey/troubleshooting/260311_24자동배포_0초종료_runtime_ssot불일치_이슈.md
index 137c5ea..9f4ee9b 100644
--- a/journey/troubleshooting/260311_24자동배포_0초종료_runtime_ssot불일치_이슈.md
+++ b/journey/troubleshooting/260311_24자동배포_0초종료_runtime_ssot불일치_이슈.md
@@ -12,6 +12,7 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, troubleshooting]
 ## 문제
 - `rb8001` 최신 커밋 푸시 후 Gitea Actions `cicd.yml`이 `0s`로 종료되고 자동 배포가 실제로 수행되지 않았다.
 - 같은 시점에 24 실행 서버 `rb8001` 컨테이너는 재시작되지 않았고, 수동 `docker compose down && docker compose up -d --build` 후에만 코드가 반영됐다.
+- 2026-03-11 `c7bca94 fix: restore deploy ssot for rb8001` 반영 뒤에도 최신 run `#677`은 여전히 `0s`로 끝나 workflow 본문 실행 증거가 없다.
 
 ## 확인된 사실
 - 현재 24 실행 서버의 runtime SSOT는 `192.168.0.106`이다.
@@ -20,18 +21,39 @@ tags: [infra, gitea-actions, deploy, 24-server, runtime, troubleshooting]
 - 기존 인프라 문서상 배포 실패의 대표 원인은 `DEPLOY_PROJECT_DIR` 같은 단일 기준을 안 쓰고 서비스별 하드코딩 경로/값을 남긴 경우였다.
 - 이번 건은 자동 배포가 실행되지 않았지만, 같은 서버에서 수동 배포는 정상 성공했다.
 - `rb8001/.gitea/workflows/cicd.yml`은 `secrets.*`나 `vars.*`가 아니라 저장소 루트 `.env.deploy`를 직접 읽도록 작성돼 있다.
-- 현재 `rb8001` 저장소에는 `.env.deploy`가 없고 `.env.deploy.example`만 존재한다.
-- `rb8001/.env.deploy.example`에는 아직 `DEPLOY_SSH_HOST=192.168.219.45`, `DEPLOY_SSH_PORT=51123`가 남아 있다.
+- 2026-03-11 `git -C /home/admin/robeing/rb8001 pull` 결과 `0313313..c7bca94`로 갱신됐고, 현재 저장소에는 `.env.deploy` 실파일이 존재한다.
+- 현재 `rb8001/.env.deploy`, `.env.deploy.example` 모두 `DEPLOY_SSH_HOST=192.168.0.106`, `DEPLOY_SSH_PORT=51124`, `DEPLOY_PROJECT_DIR=/home/admin/robeing/rb8001`로 정렬돼 있다.
 - 반면 `skill_email`, `robeing-monitor`, `skill-rag-file`의 실제 `.env.deploy`는 모두 `DEPLOY_SSH_HOST=192.168.0.106`, `DEPLOY_SSH_PORT=51124`로 맞춰져 있다.
 - Gitea API 기준 `rb8001` 저장소의 Actions secrets/variables 목록은 현재 빈 배열(`[]`)이다.
+- 2026-03-11 51123 서버에서 `ps -ef | rg 'act_runner|start-act-runner'` 기준 실행 중인 runner 프로세스가 없었다.
+- 2026-03-11 51123 서버에서 `systemctl is-active act_runner`는 `inactive`, `systemctl status act_runner`는 `Unit act_runner.service could not be found.`를 반환했다.
+- `/home/admin/scripts/start-act-runner.sh`는 systemd 유닛이 아니라 `cd /etc/act_runner && nohup act_runner daemon --config .runner > /mnt/hdd/logs/act_runner/act_runner.log 2>&1 &` 방식으로 runner를 띄우도록 작성돼 있다.
+- `/etc/act_runner/.runner`에는 runner id `4`, name `org-shared-runner`, address `http://localhost:3000`, label `self-hosted:host`가 등록돼 있다.
+- `/mnt/hdd/logs/act_runner/act_runner.log`의 마지막 성공 실행 흔적은 2026-03-05 `robeing-monitor` 배포이고, 마지막 오류는 2026-03-06 `failed to fetch task ... dial tcp 127.0.0.1:5432: connect: connection refused`다.
+- 반면 2026-03-11 현재 51123에서 `curl http://localhost:3000/api/healthz`는 `status: pass`, `ss -tlnp` 기준 `3000`, `5432`는 모두 listen 상태다.
+- Gitea DB `action_runner` 기준 runner id `4`의 `last_online`은 `2026-03-06 08:11:27+09`, `last_active`는 `2026-03-05 16:38:37+09`에서 멈춰 있다.
+- Gitea DB `action_run` 기준 `rb8001` 최신 run `#677`은 `status=5`, `started=0`, `stopped=0` 상태로 남아 있다.
+- Gitea DB `action_run_job` 기준 `#677`의 `deploy` job은 `task_id=0`, `started=0`, `stopped=0`이라 runner에 task가 할당되기 전 단계에서 멈췄다.
+- Gitea DB `action_task` 기준 `rb8001`의 마지막 task 생성 시각은 `2026-03-05 16:23:25+09`이고, 2026-03-06 이후 새 task는 생성되지 않았다.
+- 2026-03-11 21:24 KST `sudo /home/admin/scripts/start-act-runner.sh` 실행 후 `act_runner daemon --config .runner` 프로세스가 다시 생성됐다.
+- 재기동 직후 `/mnt/hdd/logs/act_runner/act_runner.log`에는 `Starting runner daemon`, `runner: org-shared-runner ... declare successfully`가 기록됐고, 이어서 새 task `2109`, `2110`이 실제로 생성·실행되기 시작했다.
+- Gitea DB `action_runner` 기준 runner id `4`의 `last_online`, `last_active`는 `2026-03-11 21:25:15+09`로 갱신됐다.
+- 2026-03-11 21:25 KST 기준 pending run/job은 총 8건이며, `skill-slack`, `skill-email`, `auth-server`, `skill-calendar`, `robeing-monitor`, `admin-dashboard`, `rb8001`, `nginx-infra` 순으로 backlog가 남아 있다.
+- 따라서 현재 `rb8001 #677`은 `runner가 죽어서 영구 정지` 상태는 벗어났지만, 아직 자기 차례 task를 받기 전인 queue 대기 상태다.
 
 ## 현재 해석
-- 애플리케이션 코드 자체 문제보다는 `Gitea Actions -> 24 배포 경로`의 SSOT 불일치 가능성이 높다.
-- 특히 `rb8001`은 다른 서비스와 달리 `.env.deploy` 실파일이 없고, 예시 파일도 구주소를 가리켜 자동 배포 경로가 SSOT에 수렴하지 않은 상태다.
+- `rb8001` 저장소의 deploy SSOT 불일치 자체는 `c7bca94`로 상당 부분 해소됐고, 이 사실만으로는 최신 `0s` 종료를 더 이상 설명하기 어렵다.
+- 현재 우선 원인 후보는 `rb8001 앱`보다 `51123 Gitea Actions self-hosted runner 실행층`이다.
+- 특히 runner 프로세스 부재, systemd 유닛 부재, 로그 정지 시점(2026-03-06)이 함께 보여서 최신 `#677`은 workflow 본문 이전 단계에서 종료됐을 가능성이 높다.
+- DB 기준으로도 `#677`은 task 미생성 대기 상태라, `0s 종료`는 workflow 내부 스텝 실패보다 `runner fetch/할당 경로 미작동` 해석이 더 맞다.
+- 재기동 이후 새 task가 다시 생성되는 것이 실증됐으므로, `runner fetch 경로 자체는 복구 가능`함이 확인됐다.
+- 남은 미해결 범위는 `rb8001 #677` 개별 run이 backlog를 통과해 실제 task를 할당받고 24 자동배포까지 닫히는지 여부다.
+- 다만 `start-act-runner.sh`의 `--config .runner` 사용이 실제 재기동 실패와 연결되는지는 아직 미확정이므로, 관측 사실과 추정 원인을 분리해서 다뤄야 한다.
 
 ## 직접 영향
 - `git push origin main`이 배포 완료를 의미하지 않게 된다.
 - 운영자가 수동 배포로 개입해야 하므로 배포 재현성과 추적성이 깨진다.
+- runner가 실제로 죽어 있으면 `rb8001`뿐 아니라 같은 self-hosted runner를 쓰는 다른 저장소도 dispatch를 받아도 실행층에서 멈출 수 있다.
 
 ## 한 줄 결론
-- 이번 자동 배포 실패는 `24 실행면 runtime SSOT`와 `Gitea Actions 배포 경로`가 다시 어긋났을 가능성이 높은 상태다.
+- 이번 자동 배포 실패는 `rb8001 deploy SSOT 불일치`에서 시작됐지만, 2026-03-11 기준 남아 있는 `0s` 종료의 더 유력한 원인은 `51123 self-hosted runner 실행층 중단`이다.