chore(ci): dependency-graph job correlator 불일치 — develop base PR 의 dependency-review 가 의존성 전량을 신규 도입으로 오탐 #1009

📜 Overview (Required)

dependency-submission.yml 의 두 job 이 서로 다른 job correlator 로 dependency snapshot 을 제출한다. 그래서 base 가 develop 인 PR 에서 Review dependency changes 가 base 스냅샷을 0건으로 보고, 그 PR 의 의존성 전량을 «신규 도입» 으로 계산한다.

dependency-review 의 존재 이유가 «이 PR 이 새로 들여온 것만 검사» 인데, develop base PR 에서는 그 판별이 작동하지 않는다. 지금은 전량 검사와 같고, 기존 의존성에 붙은 취약점이 그 PR 탓으로 표시된다.

🔍 실측 (2026-08-24, PR #988 기준)

PR #988(refactor/634-core-ui-convergence, base=develop)은 색·컴포넌트 치환만 하고 의존성을 전혀 건드리지 않는다. 그런데 Review dependency changes 가 실패했다.

The number of snapshots compared for the base SHA (0) and the head SHA (1) do not match.
You may see unexpected additions in the diff.
##[error]Dependency review detected vulnerable packages.

base 스냅샷은 정상 존재한다 — 문제는 correlator 다

develop push(6123a68a) 제출 로그:
  ##[notice]Submitted ...-submit-default-branch.json:
            Dependency results for the repo have been successfully updated.

같은 base SHA 인데 상대가 develop 이면 정상 비교되고 PR head 면 base 가 0 이 된다. compare API 는 head 스냅샷의 correlator 에 대응하는 base 스냅샷을 찾기 때문이다. 제출 로그의 artifact 파일명이 곧 correlator 이고, 두 job 이 갈려 있다.

전량 added 가 실제 실패로 이어진다

6123a68a...76e0958 의 added 917건 중 high·critical 취약점 보유 12건:

org.bouncycastle:bcprov-jdk18on@1.79 · @1.80   critical  GHSA-574f-3g2m-x479
io.netty:netty-codec / -codec-http / -codec-http2 / -handler   (각 4.1.93 · 4.1.110)
org.jdom:jdom2@2.0.6
org.bitbucket.b_c:jose4j@0.9.5

12건 모두 develop 에 이미 있던 것이다. fail-on-severity: high 라 critical 하나로 실패한다.

스택 PR 은 통과한다 — 가설과 일치

PR #991 은 base 가 fix/736-request-count(PR 브랜치)라 양쪽 다 generate-pr-snapshot correlator 다. correlator 가 맞으므로 정상 비교되고 통과했다. 반대로 develop base 인 #988 과 feat/735(2026-08-23, 10분 38초 후 실패)가 실패했다.

타임아웃 조정은 해결이 아니다

retry-on-snapshot-warnings-timeout: 600 을 늘려도 correlator 가 다르면 base 는 영원히 0 이다. #988 은 재실행(05:17→05:28)해도 같은 자리에서 같은 이유로 실패했다.

🛠 해결 방향

두 job 이 같은 correlator 로 제출하게 고정한다. gradle/actions 는 GITHUB_DEPENDENCY_GRAPH_JOB_CORRELATOR 환경변수를 읽는다(v6.3.0 dist 실측 — action input 으로는 노출돼 있지 않다).

# .github/workflows/dependency-submission.yml — 두 job 모두
env:
  GITHUB_DEPENDENCY_GRAPH_JOB_CORRELATOR: afternote-gradle-dependency-graph

Submit PR Dependency Graph(download-and-submit)는 artifact 안에 기록된 correlator 를 그대로 제출하므로 생성 단계만 고정하면 따라온다.

적용 후 확인해야 할 것 — 기존 develop 스냅샷은 옛 correlator 로 남아 있다. 새 correlator 로 develop push 가 한 번 돌아야 base 가 채워진다. 그 전까지는 develop base PR 이 계속 전량 added 로 보인다. 즉 이 수정이 develop 에 머지된 직후 1회는 여전히 오탐이고, 그 다음 PR 부터 정상화된다.

검증 방법: 수정 머지 후 develop base PR 하나를 골라

gh api "repos/Afternote/Afternote-FE/dependency-graph/compare/<base_sha>...<head_sha>" \
  --jq '[.[] | select(.change_type=="added")] | length'

이 값이 그 PR 이 실제로 추가한 의존성 수와 맞으면 해소다(의존성 변경이 없는 PR 이면 0).

📌 관련

• security(ci): setup-gradle·Dependency Graph·PR Dependency Review·자동 업데이트 연결 #845 (closed) — 이 파이프라인을 만든 이슈. 3단 분리(생성/제출/검토) 자체는 fork PR 에 contents: write 를 주지 않으려는 정당한 설계이고, 그 구현의 잔존 결함이라 후속으로 분리한다.
• chore(build): 빌드·테스트 클래스패스 bouncycastle 1.84 상향 — dependency-review critical(GHSA-574f-3g2m-x479) 해소 #921 (open) — bouncycastle 1.84 상향. 위 12건 중 critical 을 없애므로 증상은 그쪽이 지운다. 다만 correlator 불일치가 남으면 다음에 기존 의존성에 high 가 붙는 순간 같은 오탐이 재발하고, 그 사이에도 «신규 도입만 검사» 는 계속 작동하지 않는다. 원인과 증상이라 둘 다 필요하다.

📍 Note (Optional)

• PR refactor(mindrecord): core:ui 정본으로 중복 6건을 수렴한다 #988 리뷰에서 이 체크 실패를 처음 «스냅샷 제출 타이밍 문제, 재실행이면 풀린다» 로 적었다가 재실행 실패로 오진임이 드러났다. 리뷰 본문은 위 내용으로 정정했다.
• 이 결함은 CI 가 빨간불일 때 리뷰어가 «코드 문제인가» 를 매번 판별해야 하는 비용도 만든다. 실제로 refactor(mindrecord): core:ui 정본으로 중복 6건을 수렴한다 #988 리뷰에서 그 판별에 재실행 1회와 compare API 실측이 들었다.