R9(팔 D, 관측 스택) coresidency 리허설이 팔 C 이후에서 두 번 다 실패 — 원인 로그 유실

[Khyojae]

배경

2026-09-02 EC2에서 `CORES_ARMS="C D"`로 coresidency 리허설을 두 번 시도했다(다른 세션, S3 RUN_ID: `ec2-20260902-145329` · `ec2-20260902-163425`). 팔 D(관측 스택, #645에서 준비)를 실제로 한 라운드에 넣은 것은 이게 처음이다 — 지금까지 P6 라운드 셋 모두 "길어지면 뺀다"로 D 없이 끝났다(AWS-RIDE-ALONG.md §1 從-R9).

두 번 다 `coresidency_rehearsal`이 FAIL(1)로 끝났다.

현상 (근거)

1차 시도 (`ec2-20260902-145329`, 커밋 `5ccd052c`)

• G2("세션 개설 → 프레임 수락")에서 실패: `probe.log`

  ✅ 세션 생성 — sessionId=1901, aiWorkerIndex=2
  🔴 20s 안에 분석기가 안 붙었다: 세션 1901가 시작되지 않았습니다 (StartAnalysis 먼저 호출 필요)
  

• 커밋 `5ccd052c`는 P6 coresidency 리허설 G2 FAIL — StartAnalysis는 AI에 도착하는데 /api/v1/pose가 분석기를 못 찾는다 #651(probe.sh X-AI-Worker 헤더 누락) 수정 커밋인데, 그 메시지 자체가 "검증 중 별개의 새 버그(acquire는 성공하는데 registry가 계속 못 찾는 경우)를 발견해 #654로 분리 등록"이라고 적어뒀다 — 이 실패가 그 #654일 가능성이 높다.

2차 시도 (`ec2-20260902-163425`, 커밋 `04a7058d`)

• G0~G3 게이트는 전부 통과(`aiWorkerIndex=2, sessionNonce=있음`까지 확인).
• 팔 C는 정상 진행 — `coresidency.tsv`에 discard/r1(세션 5·10) 3판이 detect_pct 100%·setup_fail 0~2로 깨끗하게 찍힘.
• 그런데 팔 D로 넘어가는 지점에서 FAIL(1)로 끝났다(238초 소요) — D 태그가 붙은 파일이 하나도 없다. `ghz_C_`·`stats_C_`만 있고 `D`는 전무.
• `phases.tsv`: `coresidency_rehearsal FAIL(1) 238` → `coresidency SKIP`(자동 정지 전 진단 시간 확보라는 원래 취지대로 본판은 안 돌고 collect까지만 실행됨, run_all.sh: repl_preflight FAIL이어도 FINAL_OK=1이 되어 AUTO_SHUTDOWN이 박스를 꺼버린다 #641 로직대로 정상 동작).

원인 — 알 수 없음 (로그 유실)

정확한 bash 레벨 에러 메시지는 `/root/run_all.log`에만 찍히는데, 그 파일은 `$OUTDIR` 밖이라 S3에 안 올라가고 인스턴스 종료와 함께 사라진다(`run_all.sh:1684`가 이미 이 한계를 알고 있음, #198 관련). 두 인스턴스 다 이미 terminate됨.

영향

• R9(관측 스택 동거 비용, Q5·H5)를 아직 한 번도 실제로 못 쟀다 — 팔 D가 리허설조차 통과 못 함.
• 원인 후보(미검증, 조사 안 됨):
  • `docker compose --profile obs up -d`(팔 D 전환 명령) 자체의 실패 — 이미지는 부트스트랩이 미리 당겨두게 했지만(P4(복제) 절차 — AL2023 기본 root SSH 차단이 REPLICA_SSH 요구사항과 문서화 안 된 채 충돌 #642 PR fix(loadtest): 부트스트랩이 role과 무관하게 root SSH를 연다 (#642) #657) 실제 기동까지는 확인 안 됨
  • obs 스택 컨테이너(prometheus·grafana·mysqld-exporter 등)가 떠도 헬스체크/포트 대기에서 리허설 타임아웃에 걸렸을 가능성
  • 관측 스택이 켠 부가 프로세스가 CPU/메모리를 더 써서 다른 단계가 늦어졌을 가능성

다음에 볼 것

• 다음 시도에서는 `run_all.sh`를 `nohup ... > /root/run_all.log 2>&1 &`로 띄운 뒤 SSH로 붙어서 실시간으로 tail 하거나, 실패 즉시(자동 정지 전에) `/root/run_all.log`를 손으로 S3에 올릴 것
• `docker compose --profile obs up -d`를 손으로 재현해서 팔 D 전환 자체가 되는지부터 확인
• 재발하면 이 이슈에 근거를 더 쌓을 것 — 지금은 "두 번 다 D 근처에서 죽었다"는 패턴만 있고 정확한 지점은 모른다