measure(actions): 대기 큐의 약 47%가 중앙 리뷰 체크로 merge를 막지 못하는 67개 저장소에서 나온다 (76개 전수, 기본 브랜치 기준 정정됨)

[seonghobae]

요약

org 전체 대기 실행 2093건 가운데 1282건(61.3%)이 중앙 리뷰 체크가 merge를 막지 않는 저장소에서 나옵니다. 76개 저장소를 표본이 아니라 전수로 확인했습니다.

중앙 리뷰 체크가 merge를 막는 저장소   5개 :  811건 (38.7%)
중앙 리뷰 체크가 merge를 못 막는 저장소 71개 : 1282건 (61.3%)
                                    합계   : 2093건

merge를 막는 5곳은 .github, contextual-orchestrator, fast-mlsirm, pg-erd-cloud, bandscope 뿐입니다.

측정 방법

• 대기 깊이: 저장소마다 actions/runs?status=queued&per_page=1의 total_count. 필터 없는 actions/runs는 최근 30건만 돌려주므로 깊이 측정에 쓰면 안 됩니다.
• 게이팅 판정: 저장소마다 두 경로를 모두 봤습니다. classic branch protection(branches/main/protection/required_status_checks)과 ruleset 유효 규칙(rules/branches/main). 한쪽만 보면 틀립니다 — 실제로 aFIPC와 newsdom-api는 classic protection이 없어서 처음에 게이팅 없음으로 잘못 분류됐고, ruleset 경로에서야 잡혔습니다.
• 중앙 체크 판정: 필수 context 이름에 opencode-review|coverage-evidence|noema-review|required-workflow-bootstrap|strix|scan-pr-queue|CodeQL|osv-scan|trivy-fs|scorecard|dependency-review 중 하나라도 있는지로 봤습니다. wardnet의 유일한 필수 context는 rust라서 중앙 리뷰는 이 저장소의 merge를 막지 못합니다. newsdom-api도 pytest 하나뿐입니다.
• 합계 검증: 811 + 1282 = 2093, 5 + 71 = 76. join에서 누락된 행이 없습니다.

큐가 cron이 아니라 PR에서 옵니다

게이팅 없는 저장소 4곳의 대기 실행 event 분포입니다. per_page=100 상한이 있어 naruon은 240건 중 최근 100건 표본입니다.

naruon              pull_request 59 + pull_request_target 19,  schedule 0
xtrmLLMBatchPython  pull_request 66 + pull_request_target 13,  schedule 0
OriginWeave         pull_request 53 + pull_request_target 29,  schedule 1
noema               pull_request 36,                           schedule 3

정기 실행이 밀어 넣는 게 아닙니다. PR마다 붙는 필수 워크플로가 밀어 넣습니다. .github 기준으로 PR 하나의 synchronize가 실제로 만드는 job은 33개입니다(matrix 전개 포함, if:로 확실히 skip되는 job 제외).

무엇을 주장하고 무엇을 주장하지 않는가

주장하지 않는 것: 71개 저장소의 리뷰를 끄자는 게 아닙니다. 게이팅이 없다고 리뷰 결과가 쓸모없지 않습니다. 권고 신호로서의 가치는 그대로입니다.

주장하는 것: 포화 상태에서 merge를 막을 수 없는 작업이 큐의 61%를 차지하고, merge를 막는 39%가 그 뒤에 줄 서 있습니다. 60-job 상한이 org 공유이므로 이건 직접적인 자리 경합입니다.

다음 판단이 필요한 지점

리뷰 역량을 없애지 않으면서 실행 시점을 바꾸는 쪽이 방향으로 보입니다 — 게이팅 없는 저장소에서 push마다가 아니라 merge 시점이나 예약, 혹은 요청 시 도는 형태. 다만 이건 org ruleset(18156473)의 적용 범위를 바꾸는 일이고, ruleset 읽기에 admin:org 권한이 필요해서 이 세션에서는 확인도 변경도 못 합니다. 소유자 판단이 필요합니다.

재현

gh api "repos/ContextualWisdomLab/<repo>/actions/runs?status=queued&per_page=1" --jq '.total_count'
gh api "repos/ContextualWisdomLab/<repo>/branches/main/protection/required_status_checks" --jq '.contexts'
gh api "repos/ContextualWisdomLab/<repo>/rules/branches/main" --jq '[.[]|select(.type=="required_status_checks")]|.[].parameters.required_status_checks[].context'

측정 시각 2026-09-05 11:2x UTC. 대기 깊이는 스냅샷이라 변합니다. 게이팅 구성은 구조적이라 잘 안 변합니다.

[seonghobae]

정정: 헤드라인 수치가 틀렸습니다 (61.3% → 47.1%)

원 본문의 "61.3%가 merge를 막지 못한다"는 틀렸습니다. host1 세션이 잡아줬습니다.

무엇이 틀렸나

저장소마다 branches/main/protection을 조회했는데, 76곳 중 35곳의 기본 브랜치가 main이 아닙니다. naruon은 main 브랜치 자체가 없어서 API가 "Branch not found"를 돌려줬고, 저는 그 404를 "보호 설정 없음"으로 읽었습니다. 실제로는 develop에서 중앙 리뷰 체크 5개(required-workflow-bootstrap, strix, coverage-source-tree, coverage-evidence, opencode-review)가 merge를 막습니다. 대기 231건으로 org 2위 기여자입니다.

bandscope가 기본 브랜치는 develop인데도 제 원래 조회에서 게이팅으로 잡힌 건, 이 저장소에는 기본이 아닌 main 브랜치가 따로 존재하고 거기에 보호가 걸려 있기 때문입니다. 즉 브랜치 이름을 상수로 박으면 오류가 나는 게 아니라 엉뚱한 브랜치의 그럴듯한 답이 돌아올 수도 있습니다.

정정된 수치

기본 브랜치를 저장소마다 .default_branch로 확인해 다시 전수한 결과입니다.

                        원 발표        정정
중앙 리뷰 게이팅          5곳  811       9곳 1107 (52.9%)
게이팅 없음              71곳 1282      67곳  986 (47.1%)
                             2093           2093

게이팅되는 9곳: .github, contextual-orchestrator, fast-mlsirm, pg-erd-cloud,
semantic-data-portal(이상 main), naruon, bandscope, scopeweave,
linux-cluster-ops(이상 develop).

이 정정 자체의 한계

정정하면서 두 가지를 동시에 바꿨습니다 — 기본 브랜치 확인, 그리고 중앙 체크 판정 정규식에 Analyze(CodeQL의 실제 job 이름)와 coverage-source-tree 추가. 그래서 61.3 → 47.1의 이동분을 브랜치 수정 하나에 귀속시킬 수 없습니다. 두 수치의 차이를 인용하지 마시고, 정정된 값만 쓰십시오.

결론은 어떻게 바뀌나

과반 주장은 죽었습니다. "큐의 대부분이 merge를 못 막는다"고 더 이상 말할 수 없습니다.

방향과 처방은 남습니다. 대기의 **약 47%**가 어떤 merge도 막지 못하면서 org 공유 60-job 상한을 똑같이 소비하고, 실제로 게이팅하는 1107건이 그 뒤에 줄 서 있습니다. 절반에 가까운 수치이므로 "실행 시점을 바꾼다"는 방향은 그대로 유효합니다. 바뀐 것은 강도이지 결론이 아닙니다.

재현 (브랜치 상수를 쓰지 마십시오)

db=$(gh api "repos/ContextualWisdomLab/<repo>" --jq .default_branch)
gh api "repos/ContextualWisdomLab/<repo>/branches/$db/protection/required_status_checks" --jq '.contexts'
gh api "repos/ContextualWisdomLab/<repo>/rules/branches/$db" \
  --jq '[.[]|select(.type=="required_status_checks")]|.[].parameters.required_status_checks[].context'

[seonghobae]

완주한 실행 하나를 끝까지 뜯었습니다 — 대기가 벽시계의 99.87%입니다

.github run 33863887680 (fix/pyo3-native-peer-gate). #1910 병합 전에 생성돼서 옛 depth-5 그래프를 그대로 통과한 완전한 실행입니다. 6개 job 전부 실제 러너를 받았고 steps도 다 있습니다.

job                                 start            직전 종료 후 대기      실행
required-workflow-bootstrap         09-04 13:11:01           2:36:27   0:00:06
cancel-superseded-opencode-review   09-04 13:16:51           0:05:44   0:00:16
admit-current-head                  09-04 15:49:49           2:32:42   0:00:02
coverage-source-tree                09-04 20:23:13           4:33:22   0:00:03
coverage-evidence                   09-04 22:42:35           2:19:19   0:00:03
opencode-review                     09-05 02:11:41           3:29:03   0:00:43

생성 09-04T10:34:34Z  ->  종료 09-05T02:12:25Z     총 15:37:50

실제 계산은 6개 job 합쳐 약 73초입니다. 벽시계는 15시간 37분 50초입니다.

직렬 sentinel 홉의 값이 처음으로 실측됐습니다

admit-current-head(2초), coverage-source-tree(3초), coverage-evidence(3초) — 이 세 job이 하는 일은 합쳐서 8초입니다. 이걸 실행하려고 지불한 큐 대기는 2:32:42 + 4:33:22 + 2:19:19 = 9시간 25분 23초입니다.

"직렬 링크 하나가 큐 패스 하나를 문다"는 주장이 이제 추론이 아니라 한 실행 안의 관측입니다.

#1910에 대해 말할 수 있는 것과 없는 것

#1910은 coverage-source-tree와 coverage-evidence를 임계 경로에서 뺐습니다. 이 실행에서 그 두 홉의 대기는 4:33:22 + 2:19:19 = 6시간 52분 41초였습니다.

단, 이걸 예측으로 쓰면 안 됩니다. 같은 날 같은 워크플로군에서 layer0 대기가 1.87h에서 7.75h까지 흔들린다는 측정이 따로 있습니다(host1 세션, n=80). 분산이 이 정도면 반사실 한 건은 "이 실행이었다면 얼마였을까"이지 "앞으로 얼마가 된다"가 아닙니다. 홉당 상수는 이미 폐기했고 여기서 되살리지 않습니다.

"25시간째 실행 없음"은 필터 아티팩트였습니다

status=success로만 조회하면 이 실행이 안 보입니다. failure로 끝났기 때문입니다. 마지막 실제 실행은 09-04T10:14Z가 아니라 09-05T02:12Z이고, 측정 시점 기준 약 9.4시간 전입니다.

opencode-review job 자체는 steps=4로 정상 실행됐고 결론만 failure입니다. 즉 리뷰가 안 돈 게 아니라 돌아서 부정 판정이 났거나 판정 생산에 실패한 것이고, 이건 러너를 못 받는 것과 전혀 다른 상태입니다.

교훈: 파이프라인 생존을 볼 때 status=success만 보면 실패로 끝난 실제 실행이 통째로 빠집니다. success와 failure를 각각 조회하거나, run 결론이 아니라 job의 steps로 판정하십시오.

[seonghobae]

후속 측정: 기아가 org 전체에 균일하지 않습니다. .github이 가장 나쁩니다

큐가 줄고 있어서 "회복 중"이라고 쓸 뻔했는데, 큐는 실행으로도 줄고 취소로도 줍니다. 둘은 반대 뜻이라 갈라서 셌습니다.

2026-09-05 11:45Z~12:50Z(약 65분) 사이에 종결된 run을 conclusion별로 전수 집계했습니다.

저장소                     종결   success  cancelled  skipped   success 비율
contextual-orchestrator     33      16        15        0         48%
naruon                      30      10        20        0         33%
OriginWeave                 23       2        21        0          9%
.github                     51       1        17       33          2%
fast-mlsirm                 36       0        36        0          0%
                          ----    ----      ----     ----
합계                       173      29       109       33

failure는 contextual-orchestrator 2건뿐입니다.

절단 확인: 다섯 저장소 모두 per_page=100 페이지가 창 경계(11:45Z)보다 훨씬 이전(06:42~10:58Z)까지 닿고, 창 내 건수도 전부 100 미만(51/30/33/23/36)입니다. 창이 잘리지 않았습니다. 오늘 이 이슈에서 이미 한 번 상한 절단으로 틀린 적이 있어 먼저 확인했습니다.

두 가지가 동시에 참입니다

하나, 큐 감소의 대부분은 실행이 아니라 취소입니다. 173건 중 109건(63%)이 cancelled입니다. 그러니 "큐가 줄었다 = 처리되고 있다"로 읽으면 안 됩니다.

둘, 그럼에도 실제 실행은 재개됐습니다. 오늘 오전에는 .github에서 3시간 넘게 success/failure가 0건이었는데, 지금은 표본 전체에서 29건의 success가 나옵니다. contextual-orchestrator 16건, naruon 10건입니다. 그건 진짜 변화입니다.

그런데 그 회복이 .github에는 오지 않았습니다

.github은 **51건 종결 중 success 1건(2%)**입니다. skip 33건은 러너를 안 먹으니 빼고 보면 실질 18건 중 1건, 5.6%입니다. 같은 창에서 contextual-orchestrator는 33건 중 16건(48%)입니다.

.github은 org에서 가장 깊은 큐(562건)를 들고 있으면서 가장 낮은 실행률을 받고 있습니다. fast-mlsirm도 36건 전부 취소로 0%입니다.

원인은 주장하지 않습니다

저장소별 실행률이 0%에서 48%까지 벌어지는 이유를 이 데이터는 말해주지 않습니다. 큐 깊이 대비 배분, 저장소별 concurrency 그룹의 취소 패턴, 혹은 .github이 required-workflow 원본 저장소라는 사실 — 어느 것도 확인 안 했습니다. 관측만 올립니다.

운영상 함의

이건 지금 무엇을 어디서 하느냐를 바꿉니다.

• .github에 push하는 작업은 지금 가장 비쌉니다. 가장 깊은 큐 + 가장 낮은 실행률이라 결과를 보기까지 가장 오래 걸립니다. 충돌 해소처럼 필요한 작업은 계속해야 하지만, "기다리면 체크가 붙는다"는 전제는 .github에서 제일 약합니다.
• contextual-orchestrator는 실제로 돌고 있습니다. 검증이 필요한 작업은 지금 그쪽에서 훨씬 빨리 신호를 받습니다.

측정 시각 2026-09-05 12:50 UTC. 스냅샷이며, 오전 관측(3시간 무완주)과 다르다는 것 자체가 이 값이 빠르게 변한다는 증거입니다.

[seonghobae]

재측정: .github 실행률 2% → 0%, 형제 저장소는 전부 상승. 비대칭이 유지가 아니라 확대됐습니다

13:15Z~13:48Z(33분) 종결 run, conclusion별. 절단 확인: 다섯 저장소 모두 페이지가 창 경계 이전까지 닿음.

저장소                     종결  success  cancelled  skipped  failure   rate    (이전 창 11:45~12:50Z)
.github                      92      0        67        25       0      0%     2%
naruon                       32     22        10         0       0     69%    33%
contextual-orchestrator       5      4         0         0       1     80%    48%   n 작음
OriginWeave                   7      6         0         0       1     86%     9%   n 작음
fast-mlsirm                   1      1         0         0       0    100%     0%   n=1

인용할 수 있는 대비는 .github 0/92 대 naruon 22/32입니다. 나머지 셋은 방향만 일치하고 n이 작아 비율로 쓰지 마십시오.

.github의 92건은 전부 러너 없는 종결입니다

67 cancelled + 25 skipped = 92. success 0, failure 0 — 33분 동안 .github에서 실제로 실행돼 끝난 run이 하나도 없습니다. 같은 33분에 org의 다른 곳에서는 실제 종결이 33건(22+4+6+1) 있었습니다.

그리고 그 67건 취소의 대부분은 우리 자신의 작업입니다: #1932 머지가 d44aa07d의 27건을 취소했고, peer3의 재해소 push 3건과 #1661 push가 superseded run을 취소했습니다. 그래서 .github은 "종결 92건"으로 활발해 보이지만 실행은 0입니다. 큐가 줄거나 종결이 늘어도 실행이 늘었다는 뜻이 아니라는 것, 이 이슈에서 두 번째로 확인됩니다.

큐 깊이

11:25Z 503  →  12:30Z 586  →  12:50Z 562  →  13:48Z 594

다시 오르고 있고, 마찬가지로 우리 push입니다.

원인은 여전히 주장하지 않습니다

큐 깊이 비례 기아, 저장소별 공평 배분, required-workflow 원본 저장소라는 사실 — 셋 다 확인 안 했습니다. 이 데이터가 말하는 건 .github이 org에서 유일하게 실행률이 0인 저장소이고, 그 상태가 최소 2시간(11:45Z~13:48Z) 지속됐으며, 형제들은 그 사이 회복했다는 것까지입니다.

운영상 결론 (변경 없음, 강화됨)

• .github에 push하고 체크를 기다리는 것은 지금 어떤 정보도 주지 않습니다. 로컬 전체 스위트가 유일한 검출기입니다.
• fix(dispatch): parse the trusted-dispatcher allowlist identically in all three consumers (#1929) #1932(디스패치 허용목록)와 fix(codeql): serialise the dispatched scan matrix with toJSON #1926(CodeQL toJSON)처럼 .github 자체를 고치는 PR은 이 실행률에서는 정상 경로로 절대 초록이 될 수 없습니다 — chicken-and-egg 승인이 정확히 이 경우를 위한 것이고, 실제로 그렇게 처리했습니다.
• 소유자 조치가 필요한 지점이 둘 남습니다: OPENCODE_REPOSITORY_DISPATCH_ACTOR 변수 갱신(opencode-review-dispatch rejects the current dispatcher identity: allowlist says github-actions[bot], sender is opencode-agent[bot] #1929), 그리고 org Actions 배분 자체(admin:org 없이는 읽을 수도 없음).

측정 13:48Z.

[seonghobae]

정정: 앞 코멘트의 "비대칭 확대"는 틀렸습니다 — 그 창의 0%는 배분이 아니라 우리 churn입니다

15분 전 제가 올린 "13:15~13:48Z 창에서 .github 0/92, 형제들은 회복 → 비대칭 확대"를 철회합니다. host1 세션이 잡았고, 제가 독립 확인했습니다.

왜 0%가 배분에 대해 아무것도 말하지 않는가

그 창에서 취소된 .github run의 수명(생성→취소)을 쟀습니다:

host1 측정:  n=60  중앙값 7.5분   p90 28.7분   최대 36.2분   3시간 넘게 산 run 0건
제 재측정:   (아래 첫 줄)

오늘 layer-0 러너 대기의 일자별 중앙값은 3.3~5시간입니다(host1 n=80). 그런데 이 창의 run은 최대 36분밖에 못 살았습니다. 어느 run도 러너를 받을 수 있는 나이에 도달하지 못했습니다. 배분이 완벽했어도 0/92였을 겁니다 — 러너가 오기 세 시간 전에 우리가 죽였으니까요. skipped 25건은 if: 스킵이라 러너와 무관합니다.

취소의 원인도 우리입니다: 같은 브랜치의 후속 run에 의한 취소 37/60(62%), 그중 fix/dispatch-actor-allowlist 17건은 #1932 머지가 자기 리뷰 run을 취소한 것입니다.

naruon 22/32과의 대비도 성립하지 않습니다

naruon에는 여섯 세션이 몇 분마다 push하지 않습니다. naruon의 run은 살아서 러너를 기다릴 수 있었고 .github의 run은 그럴 기회가 없었습니다. 두 모집단이 "배분"이 아니라 "생존 기회"에서 이미 갈립니다. 비교가 아니라 오독이었습니다.

무엇이 살아남는가

• 오전의 배분 비대칭(대기 28% / 실행 슬롯 4%, host1)은 실행 중인 job을 직접 센 것이라 별개로 유효합니다. 이 창이 그걸 강화하지 않을 뿐입니다.
• ".github이 유일하게 실행률 0"은 참이지만 원인은 유일하게 에이전트 여섯이 동시에 push하는 저장소라서입니다.
• 행동 결론은 그대로: push는 무효화할 증거가 없으니 비용 0, 로컬 스위트가 유일한 검출기.

새로 적어야 할 것

배분 기아를 실측하려면 "3시간 이상 산 .github run이 있는데도 러너를 못 받았는가"를 봐야 하는데, 지금 그런 run은 0건입니다. 그건 "배분이 정상"이 아니라 우리가 측정을 막고 있다는 뜻입니다. 우리가 고치려는 push가 우리가 재려는 run을 죽이고, 그 결과를 기아로 읽을 뻔했습니다. 오늘 오전 freeze 실험에서 배운 "분류기가 결과를 결정한다"의 재발이고, 이번엔 우리 행동이 그 분류기입니다.

한 push가 이 저장소의 실행률 측정을 통째로 오염시킵니다. #1932 머지 하나가 그랬습니다. 앞으로 .github 실행률을 인용할 때는 그 창의 취소 run 수명 분포를 같이 붙여야 하고, 최대 수명이 러너 대기 중앙값보다 짧으면 그 창은 배분에 대해 무효입니다.

앞 코멘트는 남겨두되 이 정정이 그 위에 섭니다. 잡아준 건 host1 세션입니다.