왜 「관계 탐지」를 측정해야 하는가

AI coding agent가 동일한 repository에 여러 개의 pull request를 병렬로 제출할 때, 문제가 되는 것은 개별 PR의 정확성이 아니라 PR과 PR 사이의 관계입니다. 같은 함수를 건드리고 있지는 않은지, 한쪽이 토대로 삼고 있는 부분을 다른 쪽이 변경하고 있지는 않은지. 이는 「PR 단독의 CI가 통과(green)되는가」와는 별개의 축입니다.

그렇다면 그 「PR 간의 관계」는 실제로 어디까지 탐지할 수 있을까요? 이는 주장이 아니라, 측정하여 확인해야 할 숫자입니다. 이 기사에서는 제가 실제 개인 개발 repository에서 측정한 범위 내에서, PR 관계 탐지의 재현율(recall)이 현재 어디에 와 있는지 pinned된 값으로 기술하겠습니다. 홍보가 아닌, 측정에 관한 이야기입니다.

ground truth proxy — 「나중에 수정된 것」을 정답 대신 사용하기

관계 탐지의 재현율을 측정하려면 「실제로 관계가 있었던 file의 쌍」이라는 정답 데이터가 필요합니다. 하지만 그 정답을 수작업으로 망라하여 만드는 것은 현실적이지 않습니다. 그래서 **proxy(근사 정답)**를 사용합니다.

사용된 proxy는 correction-incident입니다. fix / revert / bug / hotfix와 같은 subject를 가진 commit에서 함께 변경된 file의 쌍을 「나중에 수정되었으므로, 원래 관계했을 가능성이 높은 쌍」으로 간주합니다.

• pinned된 패널: 실제 개인 개발 / SaaS 계열 repository (python / js / ts / go 등의 indie repo)
• 평가 대상: 9 repository, correction-incident file 쌍으로
  n = 10,741 쌍 - 실행은 read-only / network-free / content-free. corpus는 frozen SHA와 byte-exact 일치로, 재측정해도 동일한 값을 재현합니다.

proxy이므로 이것은 「진정한 결합의 전체량」이 아닙니다. 어디까지나 나중에 수정된 쌍을 정답 대신 놓은 연구상의 측정입니다.

최신 main에서 재측정한 값

최신 main에서 재측정한, pinned된 재현율입니다.

언어별(양측 합산)로는 JavaScript 25.8% / Python 15.6% / TypeScript 30.5%였습니다.

숫자는 이것뿐입니다. 숨기지 않겠습니다. 다만, 이 16.5% / 20.7%를 「Veripsa의 성적」으로 읽는 것은 오류입니다. 다음 절에서 이것이 무엇을 측정하고 있고, 무엇을 측정하고 있지 않은지를 구분하겠습니다.

16.5%가 가리키지 않는 것

인용할 때 반드시 함께 적어야 할, 이 숫자의 **부정(negation)**입니다.

product 전체의 정확도도, Veripsa의 품질 스코어도 아닙니다. 이것은 하나의 평가 측면에 불과합니다. -
same-path / same-file의 충돌 탐지율이 아닙니다. 2개의 in-flight PR이 동일한 경로를 건드린다는 Veripsa의 pre-merge 주요 태스크는, 이것과는 다른 훨씬 히트율이 높은 시그널이며 여기서는 측정하지 않았습니다. git conflict marker의 탐지율도 아닙니다.-
merge / traffic control 전체의 성공률도 아닙니다. 이것은 proxy 대 proxy로서, 잠재적인 cross-file 결합의 재현율을 측정한 연구상의 숫자입니다.

즉 16.5%는 「나중에 수정된 file의 쌍 중, 구조 시그널이 사전에 얼마나 관련 지어지고 있었는가」라는, 단 한 문제에만 답하는 숫자입니다.

결정적 탐지와 의미적 관계는 별개의 레이어

이 부분이 가장 혼동되기 쉬우므로 구분하겠습니다.

Veripsa가 merge 전에 우선 담당하는 것은 **결정적 탐지(deterministic detection)**입니다. 2개의 PR이 동일한 경로를 건드리는 직접적인 충돌, 그리고 추가된 미해결 conflict marker — 이것들은 높은 신뢰도로 잡아낼 수 있습니다. 이것이 pre-merge의 주요 태스크이며, 위의 16.5%는 이것을 측정한 것이 아닙니다.

반면 16.5%가 측정하고 있는 것은, **text로는 보이지 않는 의미적 관계(semantic relationship)**의 재현율입니다. 서로 다른 파일에 있고 행의 중첩이 없음에도 나중에 함께 수정되는 쌍. 이 영역은 「놓칠 수 있는」 영역이며, 솔직히 발전 단계에 있습니다.

능력을 층(layer)으로 나열하면, 평가 방식도 해석도 층마다 다릅니다.

동일한 「탐지 (detection)」일지라도, 결정적 탐지와 재현율 (recall) 측정을 하나의 숫자로 섞어버리면 반드시 어느 한쪽을 오독하게 됩니다. 그래서 분리하여 산출합니다.

놓치는 것의 정체 — 83.6%는 「경계가 없는 cross-dir」

그렇다면 양쪽 모두에서 잡아내지 못한 8,517개 조합은 무엇일까요? 내역의 지배적인 부분은 다음과 같습니다.

즉, 놓치는 것의 **83.6%**는 디렉토리를 가로지르며, 언어 내의 구조적인 연결을 공유하지 않는 조합입니다. 전형적인 예로는 backend↔frontend의 계약 (contract) (예: .py와 .ts 사이)이나, 동일한 기능을 구성하는 형제 모듈의 공진화 (co-evolution)가 있습니다. 텍스트의 중첩도, 언어 내의 구조적 링크도 없기 때문에, content-free 제약 조건하에서는 포착하기 어려운 영역입니다.

왜 「재현율(recall)만 높이는 넓은 탐지기」를 내놓지 않는가

「놓치는 것이 많다면, 더 넓게 잡으면 된다」라고 생각하기 쉽습니다. 실제로 저도 측정해 보았습니다.

결론부터 말씀드리면, 놓치는 것의 대부분(약 74%)에는 content-free로 의지할 수 있는 구조적인 앵커 (anchor)가 없다는 것입니다. 그 부분을 넓게 잡으려는 탐지기를 실제로 측정해 보면, 재현율 (recall)은 거의 오르지 않고 정밀도 (precision)만 망가졌습니다. 오탐 (false positive)투성이인 경고는 개발자에게 없는 것이나 다름없거나 그 이하의 가치를 가집니다.

따라서 방침은 「재현율 (recall)만을 쫓지 않는다」입니다. 측정한 결과로서, 넓은 탐지기는 정밀도 (precision)를 망가뜨리므로 현행 기능으로는 내놓지 않는다는 판단입니다. 여기서 내부의 탐지 로직이나 임계값 (threshold)에 대한 이야기는 하지 않겠습니다. 어디까지나 측정해 보았고, 내놓지 않기로 결정했다는 사실만을 기술합니다.

대신 다음에 노리는 것은 **명시적인 계약 (explicit contract)**입니다. route / queue / schema와 같이, content-free로도 추적할 수 있는 앵커를 가진 관계는 탐지기 (detector)를 분리하여 대상을 한정한다면 정밀도 (precision)를 유지하면서 포착할 수 있습니다. 이곳이 정밀도를 떨어뜨리지 않고 재현율 (recall)을 늘릴 수 있는 다음 단계입니다.

measured와 unmeasured를 구분하기 — 16%는 「전체상」이 아니다

16.5%를 「Veripsa는 16%밖에 모른다」라고 읽는 것은, measured한 측면과 unmeasured한 측면을 섞어서 오독하는 것입니다. 정합성을 위한 관점을 몇 가지 추가합니다.

• micro-average는 비관적입니다. 하나의 거대한 fix commit이 조합론적으로 대량의 조합을 만들어내며, pipeshub-ai 하나만으로 분모의 61%를 차지합니다.
• 동일한 pinned corpus에서, correction commit을 1건씩 동일하게 세는 **commit-weighted 방식으로는 양자 합산 시 54.4%**가 됩니다. 기계적이지 않은 2~5개 파일의 솔직한 수정으로 한정하면 44.3%입니다.
• 놓치는 것 중, 정말로 「명확하다고 말할 수 있는 사각지대 (clear-blind)」는 **73.8%**뿐이며, 5.5%는 처음부터 unknown으로 표시됩니다. 놓친 것을 초록색 체크 표시 아래에 숨기지 않습니다.

요약하자면, 16.5%는 「비관적인 한 단면」일 뿐이며, 성적표가 아닙니다. 결정적 탐지 (measured / 고신뢰)와 의미적 관계의 재현율 (recall) (발전 중), 그리고 Unknown (정직한 사각지대의 가시화)은 각각 따로 읽어야 하는 숫자입니다.

향후 노릴 측면과 그 경계

현재 위치를 경계로 기술하면 다음과 같습니다.

• 고신뢰: same-path 충돌, conflict marker. 결정적으로 포착함.
• 대상 한정으로 다음에 노릴 것: route / queue / schema 등의 명시적 계약. 앵커가 있으므로 정밀도를 유지하며 확장 가능.
• 발전 중: 파일을 가로지르는 구조 추정. proxy 측정 시 16.5% (양자 합산 시 20.7%).
• 현재 주장하지 않음: 구조적 앵커가 없는 cross-layer contract (backend↔frontend 등). 놓치는 영역으로서 현행 기능으로는 주장하지 않음.
• Unknown: 검증할 수 없는 측면은 「clear하지 않음」으로 표시함.

숫자에 대해 이야기할 때 중요한 것은, shared-context-coverage(공유된 맥락의 범위가 얼마나 되는가)를 단 하나의 재현율(recall)로 뭉뚱그리지 않는 것입니다. measured(측정됨)와 unmeasured(측정되지 않음)를 구분하고, 결정적 탐지(deterministic detection)와 recall을 분리해야 합니다. 그렇게 작성해야 비로소 16.5%라는 수치를 올바르게 읽을 수 있습니다.

Veripsa 자체가 「모름」을 어떻게 출력할 것인가(Unknown의 설계)는 CI가 「안전하다고 말할 수 없음」이라고 응답해 온 결과입니다. 이것은 bug가 아니며, content-free(내용이 없는 상태)에서 어디까지 보일 수 있는지에 대한 경계선은 소스 본문을 맡기지 않고 「PR 간의 충돌이 어디까지 보이는가」로 나누어 두었습니다. Ready 상태 이후의 합류를 안정화하는 merge queue와의 시간축 차이는 「merge queue로 해결할 수 없는 PR 정체 — Mergify/Graphite/AI 리뷰와의 차이점」에 있습니다.

운영 측면에서 단계적으로 required check(필수 체크)로 전환하는 절차는 「GitHub Rulesets를 사용하여 AI 생성 PR의 required check를 단계적으로 도입하는 절차」에 정리해 두었습니다.

요약

PR 관계 탐지는 주장(claim)이 아니라, proxy(대리 지표)로 측정하는 대상입니다. correction-incident(수정 사고)를 정답 대신 사용하여, n = 10,741로 측정했습니다.

최신 main 브랜치의 pinned 값은 구조 시그널(structural signal)만 있을 때 16.5% / 이력 시그널(historical signal)만 있을 때 6.5% / 양자 합산 시 20.7%입니다.

이 수치는 same-path 충돌 탐지율도, conflict marker 탐지율도, 제품 전체의 정확도도 아닙니다. 결정적 탐지(고신뢰)와는 별개의 레이어인, 의미적 관계의 recall입니다.

놓친 83.6%는 구조적 앵커(structural anchor)가 없는 cross-dir(디렉토리 간) 사례입니다. 이를 넓게 포착하는 탐지기는 측정 시 precision(정밀도)이 무너졌기 때문에 포함하지 않았습니다.

commit-weighted 방식에서는 54.4%, clear-blind 방식은 73.8%에 그쳤습니다. measured와 unmeasured를 구분해서 읽어야 합니다.

메커니즘(설치 ~ merge): https://veripsa.com/ja/how-it-works

Discussion