동일한 파일을 서로 다른 PR로 편집할 때, 어디에서 알아챌 수 있는가

Claude Code나 Codex와 같은 AI coding agent를 병렬로 실행하면, 동일한 repository에 여러 개의 pull request가 짧은 시간 내에 생성됩니다.

각 PR의 test가 통과하더라도, 다른 PR이 동일한 파일을 향하고 있다는 점까지는 PR 단일 결과만으로는 읽어낼 수 없습니다. merge conflict가 발생하는 경우도 있고, Git 상으로는 merge가 가능하더라도 먼저 들어간 PR로 인해 후속 검토가 필요해지는 경우도 있습니다.

이에 따라, 두 개의 AI 에이전트를 상정한 작은 변경 사항을 실제 공개 repository에서 두 개의 PR로 생성했습니다.

• 공개 lab: GetVeripsa/ai-pr-collision-lab
• Agent A 상정: PR #1 — 5% bulk discount
• Agent B 상정: PR #2 — flat $10 large-cart discount

둘 다 작은 변경입니다. 둘 다 orders/pricing.py와 tests/test_pricing.py를 편집합니다.

이 기사에서 다루는 것은 탐지 알고리즘이 아닙니다. GitHub의 PR 화면에서 무엇이 보이고, 하나를 merge한 후에 표시가 어떻게 변했는가에 대한 것입니다.

PR #1에 남아 있는 「둘 다 open」 상태

PR #1의 Veripsa Core comment에는 둘 다 open이었던 시점의 상태가 남아 있습니다.

요점은 다음 세 가지입니다.

Clear to land — nothing is blocking you
1 in-flight PR is waiting behind this one
Suggested order: PR #1, then PR #2

comment에는 PR #1이 예약하고 있는 공개 path로서 orders/pricing.py와 tests/test_pricing.py가 표시되며, PR #2가 그 뒤에 queued 되어 있음이 표시됩니다.

여기서의 Clear to land는 PR #1의 구현이 올바르다는 의미가 아닙니다. 보이는 PR traffic 상에서 PR #1보다 먼저 반영되어야 할 blocking PR이 없다는 상태를 의미합니다. code review, test, CI는 별도로 필요합니다.

PR #1을 merge하자, PR #2의 표시가 바뀌었다

다음으로 PR #1을 merge했습니다.

PR #2의 최종 표시는 다음과 같은 내용으로 바뀌었습니다.

Cleared — the earlier overlap has resolved

먼저 있던 PR #1이 land했기 때문에, PR #2가 기다리던 대상은 in-flight 상태가 아니게 되었습니다. 공개 PR #2는 데모 종료 후 merge하지 않고 close 했지만, comment에는 이 상태 전이가 남아 있습니다.

이 두 건은 다음과 같은 before / after로 읽을 수 있습니다.

• 둘 다 open: PR #1이 선두이고, PR #2가 뒤에 queued 됨
• PR #1을 merge: PR #2의 이전 overlap이 해소됨
• PR #2의 최종 표시: Clear

Clear는 올바름의 증명도, 향후 충돌이 없을 것이라는 보장도 아닙니다. 현재 보이는 분석 대상인 PR traffic에서 blocking 대상이 보이지 않는다는 제한된 의미입니다. 정보가 부족한 면은 Unknown이며, Clear와는 구분해서 읽어야 합니다.

GitHub App이 막는 것이 아니라, branch policy가 결정한다

이 공개 예시의 check는 advisory입니다. Veripsa Core가 단독으로 merge button을 무효화하는 것은 아닙니다.

실제로 action_required를 merge gate로 취급할지는, repository 측에서 Veripsa check를 branch protection이나 rulesets의 required check로 설정하느냐에 따라 결정됩니다. 처음에는 하나의 selected repository에서 advisory 상태로 관찰하고, warning이 운영에 적합하다고 확인한 후에 required화할 수 있습니다.

통상적인 PR마다 ACK 작업을 추가할 필요도 없습니다. veripsa-ack

는 사람이 중요한 (material) warning을 확인하고, 그럼에도 불구하고 예외적으로 진행하겠다고 명시했을 때의 기록입니다. 이는 code review approval, 충돌 해결(conflict resolution), 또는 영구적인 mute가 아닙니다.

무엇을 다루고, 무엇을 남기지 않는가

공개해도 되는 경계도 데모와 함께 확인할 수 있습니다.

Veripsa Core는 source file body나 diff body를 저장하거나 표시하지 않으며, code review 출력용으로도 사용하지 않습니다. signal 생성을 위해 repository content를 일시적으로 읽을 수는 있습니다.

유지 대상이 될 수 있는 것은 PR traffic을 표시, 업데이트, 감사하기 위한 content-free metadata입니다.

• GitHub account / installation / repository / PR의 식별자 및 공개 handle
• repository 이름, branch 이름, commit 또는 content의 fingerprint
• path, symbol name/kind, language, 변경 line range, 관계 유형
• check / comment / ACK / delivery / lifecycle의 상태 및 timestamp

이 경계는 공개 contract인 DATA_HANDLING.md에도 분리되어 명시되어 있습니다.

GitHub의 secret store에는 접근하지 않습니다. 단, secret 값을 tracked file에 commit한 경우, 해당 file body는 다른 source와 마찬가지로 일시적인 처리 대상이 될 수 있습니다. 값을 의도적으로 추출하거나 유지하도록 설계되지는 않았으나, secret 자체를 repository에 commit하지 않는 것을 전제로 합니다.

이 공개 정보로 알 수 있는 것은 "무엇을 다루는가"까지입니다. 어떤 signal을 어떻게 조합하여 순서를 도출할지, 내부의 판정 방법이나 우선순위는 공개하지 않습니다.

자신의 repository에서 테스트하려면, 처음에는 하나만

공개 lab은 GitHub check/comment가 어떻게 보이는지 확인하기 위한 재현 환경입니다. 고객 환경에서의 time saved, incident 방지, 모든 충돌 탐지를 보여주는 benchmark가 아닙니다.

테스트할 경우, 다음 순서를 따르면 영향을 제한할 수 있습니다.

• 공개 lab에서 PR #1/#2의 표시를 확인한다.
• 자신이 관리하는 selected repository를 하나 선택한다.
• branch protection은 변경하지 않고, advisory 모드에서 check/comment를 관찰한다.
• Clear를 correctness로 읽지 않으며, Unknown을 Clear에 섞지 않는다. - warning이 유용할 경우에만 required check로 전환하는 것을 검토한다.

Veripsa Core 자체의 상태와 보증 범위 제외 사항은 "Veripsa Core란? GitHub에서 늘어나는 AI의 PR을 merge 전에 확인하는 GitHub App"에 정리되어 있습니다.

Discussion