# 8팀 병렬 Merge 안전 설계 (실측 기반, read-only)

상태명: `PARALLEL_MERGE_SAFETY_DESIGN_READY_ACTIVE_FALSE`
작성: ANU 직접 (2026-07-01 KST). 코드/설정 변경 0 · read-only 실측 위 설계. 근거: 회장 질의(8팀 동시 병렬 merge 뒤죽박죽 방지) + GPT 단계판정(90점 수용 + 5필수 포함) + gh 실측.

## 1. 결론 (한 줄)
**stale base(옛날 main 기준 GREEN인 채 merge)는 ruleset `strict=true`로 이미 자동 차단됨.** 8팀 병렬의 남은 과제는 안전성이 아니라 **① 자동화 병목(수동 순차 rebase) ② merge_group 결선 갭 ③ affected_files 경고→hard-block ④ semantic conflict 탐지**.

## 2. 현황 매트릭스 (gh 실측)
- **stale base 차단**: ruleset `main-protection`(active) `required_status_checks.strict=true` → **이미 방어됨** ✅ (topic이 최신 main 아니면 merge 불가)
- **merge_group CI 트리거**: `ci.yml`에 `merge_group:` 존재 ✅ (큐 켜면 즉시 반응 준비)
- **pre_push_guard B-2 ahead/behind(behind>0 FAIL)**: 있음(push 시점 보조; 주 방어선은 ruleset strict)
- **Merge Queue rule**: ruleset rules = deletion/non_fast_forward/pull_request/required_status_checks → **merge_queue rule 없음** ⚠️(자동화 갭)
- **affected_files 충돌**: bot 중복=hard block ✅ / **파일 겹침=경고만**(Telegram, Lv0-1 병렬 허용) ⚠️
- **semantic 탐지**: 파일경로 레벨만, symbol/API/schema/test dependency 탐지 **없음** ⚠️

## 3. ★ merge queue 켜기 전 필수 blocker — deadlock 아니라 **false-pass** (정정, GPT 판정)
required check 8개 × merge_group 실행 매핑:
```
ci/guard            job if:always()                → merge_group 실행 ✅ 보고 ✅
guard               job if:always()                → ✅ ✅
cancel-kill-switch  job if:always()                → ✅ ✅
qc-check            job if:always()                → ✅ ✅
hidden-path-audit   job if:always()                → ✅ ✅
lock-in-check       job if:always()                → ✅ ✅
merge-safety-check  job if:always()                → ✅ ✅
gemini-review-gate  job if:event=='pull_request'   → merge_group에서 job SKIP ⚠️ (skipped=success 보고)
```
**정밀 판별(deadlock vs false-pass):**
- ci.yml `on:` 에 `merge_group:` 존재(line 5) → **workflow(CI)는 merge_group에서 트리거됨**(큐 안 막힘).
- required check 이름 `gemini-review-gate`는 ci.yml 내 **job name**(line 120) = job-level check.
- 이 job은 `if: github.event_name == 'pull_request'`(line 123) → merge_group 이벤트에선 **skipped**.
- **GitHub 규칙: job-level `if`로 skip된 job은 conclusion=skipped로 보고되고, skipped는 required check 판정에서 success와 동등 → merge 허용.**
- **∴ 결과 = deadlock(큐 막힘)이 아니라 `false-pass`**: 큐는 잘 통과하는데 **merge_group(최종 main 진입) 단계에서 Gemini 검증축이 사실상 우회됨**. GPT가 "더 위험할 수도"라 지목한 시나리오가 정확히 우리 케이스(겉으론 자동 merge 잘 되는데 OWNER/Gemini 검증이 빠짐).
- (phase3-merge-gate도 동일 구조·pull_request-only지만 **required 목록엔 없음** → 큐 통과 영향 없음. 단 이것도 Gemini evidence alias라 merge_group에선 안 돎)
- **⚠️ 이전 판(§ 초안 "deadlock") 정정**: workflow 미트리거였다면 deadlock이나, 우리는 workflow 트리거 O + job skip이라 **false-pass**가 정확.

## 3-A. 수정안 A/B/C 리스크 비교표
- **A. gemini-review-gate를 merge_group에서도 실행(조건 완화)**
  - 원리: `if` 조건에 merge_group 추가.
  - 리스크: merge_group payload엔 `pull_request.*` 필드 **없음** → 단순 완화 시 PR/SHA resolve 오판정. merge_group SHA→포함 PR **역추적 로직 신규 필요**. 각 PR은 이미 PR단계서 Gemini 완료 → merge_group서 새 리뷰 강제는 **중복·부적절**.
  - 난이도: **최상**. 정석이지만 구현 복잡·오판정 위험.
- **B. required에서 gemini-review-gate 제외(PR 전용 유지)**
  - 원리: required 목록에서 빼고 PR 단계 게이트로만.
  - 리스크: 큐는 잘 돎. 그러나 **최종 main 진입 단계 Gemini gate 약화** = false-pass를 사실상 수용. "merge 전 Gemini HIGH0" 원칙 철학 흔들림. **임시 우회책**으로만 가능(별도 merge_group gate에서 fresh 검증 병행 조건).
  - 난이도: **최하**. 가장 위험(검증축 최종부재).
- **C. 분리 설계 ★GPT 권장**
  - 원리: **PR 전용 Gemini review gate(기존 유지)** + **merge_group 전용 evidence freshness auditor gate(신규)**.
  - merge_group auditor는 **새 Gemini 리뷰를 강제로 돌리지 않고**, queue에 포함된 각 PR을 head SHA로 역추적해 아래를 **evidence 검증(auditor)**:
    - merge_group에 포함된 각 PR head SHA
    - 각 PR head SHA 기준 **fresh Gemini review** 존재
    - unresolved **HIGH/CRITICAL = 0**
    - **OWNER resolve** 필요 thread 잔존 0
    - PR head SHA가 **queue commit과 일치**(merge_group 생성 후 새 commit 끼어들지 않음)
  - 리스크: auditor 구현 필요(freshness 판정 정확성 요구). 단 A보다 명확·B보다 안전. **철학 유지 + 큐 통과 + false-pass 차단** 동시 달성.
  - 난이도: **중**. 권장안.
- **결론 권장**: **C**(정석·안전). B는 급할 때 임시 우회(단 merge_group freshness 병행 필수). A는 비권장(복잡·중복).

## 3-B. GPT 지시 실행 순서 (설정 변경 전)
1. ✅ gemini-review-gate SKIP = **false-pass** 판별 완료(§3).
2. ✅ required 8개 전체 merge_group report 여부 확인(§3 표: 7개 report O / gemini 1개 skipped=success).
3. ▶ gemini-review-gate를 **PR 전용 gate + merge_group 전용 evidence freshness auditor**로 분리 설계(안 C) — **설계만**, 회장 승인 시 구현.
4. ▶ 그 다음 Merge Queue 자격 확인(§4) 및 활성화 — 회장 승인.
- **설정 변경(ruleset/merge_queue rule/ci.yml/gemini if 조건) 전부 미실행.** 판별+비교표 보고 후 회장 결정 대기.

## 4. Merge Queue 자격 (미확정 — 확인 필요)
- repo = **Organization + private** (개인 repo 아님 → 자격 가능성 있음).
- 단 merge queue는 "org public repo" **또는** "GHE Cloud 조직의 private repo"만 가능 → **이 조직이 GitHub Enterprise Cloud인지**가 최종 확인 포인트(회장/조직 설정 확인 필요).
- GHE Cloud 아니면 → 대안: **strict ruleset(이미 있음) + ANU 순차 merge + rebase 자동화 스크립트**(merge train 경량 자체 구현).

## 5. affected_files 경고 → hard-block 승격 기준 (제안)
현재 겹침=경고+ANU 보류판단, Lv0-1은 병렬 허용. 8팀 규모 제안:
- **Lv2+ 또는 forbidden_paths 근접 파일 겹침 = hard block**(동시 dispatch 거부).
- **Lv0-1 문서/독립 파일 겹침 = 경고 유지**(원복 저렴).
- 판정을 dispatch.py에서 레벨 + 파일민감도로 분기(현 bot_collision hard-block 로직 확장).

## 6. semantic conflict 탐지 계획 (가장 어려운 갭)
파일 안 겹쳐도 논리 얽힘(A가 함수 시그니처 변경 + B가 그 함수 호출). 계층:
- **1차(즉시 가능)**: merge_group CI에서 **전체 회귀** 실행 → 통합 SHA에서 깨지면 큐가 자동 reject(merge 전 차단). ← merge queue의 진짜 가치.
- **2차(중기)**: dispatch 단계에서 expected_files의 **import/symbol 그래프 겹침** 정적 분석(같은 심볼·API·schema·test를 두 task가 건드리면 경고). 신규 도구 필요.
- **3차(보험)**: post-merge canonical 전체 회귀(이미 존재) — 주 방어선 아닌 확인용.

## 7. 8팀 병렬 목표 아키텍처
**"작업은 병렬, main 진입은 큐/직렬"**:
```
8팀 병렬 작업(worktree 격리) → PR별 CI GREEN → queue-ready 승격
  → [merge queue] merge_group SHA(최신 main+앞선 큐 합산)에서 required 재검증 → 통과 순 merge
  → post-merge 전체 회귀(확인용)
```
merge 권한 원칙: **개별 PR GREEN이어도 merge 금지, queue-ready까지만. 최종 merge는 최신 main/merge_group SHA 재검증 통과분만.**

## 8. rollout (각 단계 회장 승인)
1. **선결**: gemini-review-gate merge_group 결선 갭 해소(§3 택1) — merge queue 전 필수.
2. GHE Cloud 자격 확인(§4).
3. 자격 O → merge_queue rule 추가 + merge_group CI 전체 보고 검증.
4. 자격 X → strict(기존) + ANU 순차 merge + 경량 rebase 자동화.
5. affected_files hard-block 승격(§5) + semantic 1차(merge_group 전체회귀, §6).
6. semantic 2차(symbol 그래프) = 중기 별도 과제.

## 9. 현재 안전도 요약
- **지금도 stale base는 막힘**(strict). 8팀을 당장 돌려도 "뒤죽박죽 main"은 구조적으로 거의 안 생김(단 수동 rebase 병목·semantic은 남음).
- merge queue는 **안전 추가가 아니라 병목 제거 + semantic 1차(merge_group 전체회귀)** 를 위해 도입.

## 금지 (본 설계 단계)
설정 변경(merge_queue rule 추가/ruleset 수정) · ci.yml 변경 · gemini-gate 조건 변경 · 실제 8팀 병렬 실행 — 전부 **미실행**(문서만). 각 실행은 회장 승인.