여러 AI를 실행하는 순간, 당신은 분산 팀을 운영하고 있는 것이다

Claude Code, OpenAI Codex, GitHub Copilot과 같은 AI coding agent를 혼자서 사용하고 있더라도, 2개 이상의 task를 병렬로 실행하는 시점에서 상황은 '1인의 개발'이 아니게 됩니다.

각 agent가 branch를 나누고, pull request를 만듭니다. 잠시 후, 동일한 repository에 여러 개의 open PR이 동시에 나열됩니다. 이는 실질적으로 여러 작업자가 동일한 repository에 동시에 PR을 내고 있는 상태입니다. 즉, 당신은 작은 분산 팀을 운영하고 있는 것입니다.

여기서 막히는 원인은 대부분 '각 AI의 지능'이 아닙니다.

각 agent는 주어진 task를 타당하게 수행합니다. 하나의 PR만 보면 CI도 통과하고, diff도 논리적입니다. 그럼에도 불구하고 재작업(rework)이 발생하는 이유는, 각 agent가 '다른 PR이 지금 바로 무엇을 바꾸고 있는지' 모르는 상태에서 작업하고 있기 때문입니다.

부족한 것은 지능이 아니라, 공유 컨텍스트 (shared context) — 지금 이 순간, 다른 in-flight(진행 중인) 변경 사항이 동일한 repository의 어디를 향하고 있는지에 대한 공유 상태입니다.

왜 공유 컨텍스트가 결여되는가

공유 컨텍스트는 방치하면 자연스럽게 생겨나지 않습니다. 몇 가지 이유가 있습니다.

각 agent / 각 chat은 자신의 task만 본다. Agent A는 자신의 branch를, Agent B는 자신의 branch를 보고 있습니다. 서로의 PR은 서로의 시야 밖에 있습니다. -
개별적으로 질문하여 얻은 답은 해당 session에 국한된다. 어떤 chat에서 "이 파일은 다른 곳에서 건드리고 있지 않나?"라고 물어 얻은 답변은 그 자리에서의 일시적인 응답일 뿐, GitHub상의 다른 PR에 반영되는 공유 상태가 되지 않습니다. -
상황은 push / merge / close에 따라 움직인다. 어제 Clear(문제없음)였던 것이, 다른 PR이 먼저 main에 들어간 오늘은 Clear라고 단정할 수 없습니다. 공유 컨텍스트는 한 장의 스냅샷이 아니라 계속 움직이는 상태입니다. -
단 한 번 모든 PR을 분석하는 것만으로는 부족하다. PR은 늘어나고, main은 진행되며, draft는 ready 상태가 됩니다. 분석은 상황이 바뀔 때마다 업데이트되지 않으면 금방 낡은 정보가 됩니다.

이 때문에 'AI를 더 똑똑하게 만드는' 방향만으로는 이 문제를 해결할 수 없습니다. 채워야 할 곳은 개별 agent의 외부인 공유면 (shared surface) 쪽입니다.

공유면은 GitHub, 그곳에 상황을 기록한다

AI agent가 동일한 repository에서 PR을 만드는 운영 방식에서는 이미 모두가 공유하고 있는 면이 하나 있습니다. 바로 GitHub의 pull request 그 자체입니다.

Veripsa Core는 이 면에 상황을 기록하는 GitHub App입니다. 특정 AI 벤더에 의존하지 않는 공유면(= GitHub의 check와 PR comment)에, PR의 '내부'가 아니라 PR과 PR '사이'의 상황을 나타냅니다.

• 다른 open PR과 동일한 작업면을 향하고 있지는 않은가
• 어떤 PR에 착륙 순서(landing order) 주의가 필요한가
• 어디가 기다림 · rebase · 순서 변경 · 통상적인 review를 계속할지의 분기점인가
• 근거 부족을 Clear로 오독하고 있지는 않은가

중요한 점은, 이것을 agent의 session에 멋대로 주입하는 것이 아니라는 점입니다. Veripsa는 공유면에 상황을 둘 뿐이며, 사람도 agent도 그것을 PR 상에서 읽습니다. agent라면 gh pr checks <PR 번호>

또는 gh pr view <PR 번호> --comments

로 읽게 할 수 있습니다.

그리고 흔히 말하는 "traffic control (기다림 / rebase / 착륙 순서)"은 이 공유 컨텍스트로부터 도출되는 action입니다. 충돌은 그 공유 컨텍스트가 결여되었을 때 나타나는 증상 중 하나일 뿐입니다. 순서, 상류 의존성, 하류로의 파급, 대기 행렬 — 이 모든 것은 '지금 다른 곳에서 무엇이 움직이고 있는지'를 공유할 수 있을 때 비로소 내놓을 수 있는 조언입니다.

Veripsa Core 자체의 개요는 'Veripsa Core란? GitHub에서 늘어나는 AI의 PR을 merge 전에 확인하는 GitHub App'에서 다루고 있습니다. 이 기사에서는 공유 컨텍스트라는 상류(upstream)의 이야기에 집중합니다.

도감: 공유 컨텍스트로부터 Veripsa가 PR에 기록하는 것

"PR들 사이를 본다"라고 해도 추상적이므로, 실제로 Veripsa Core가 PR 상에 기록하는 내용을 공유 컨텍스트의 종류별로 나열합니다. 여기에 나열하는 것들은 모두 현재 기능으로서 PR에 출력되는 것들입니다.

A. 「기다림 / 순서」— 누가 먼저, 어디서 겹치는가

• 직접 충돌 → 순서대로 착지 (land): 2개의 in-flight PR이 동일한 파일을 건드리면, merge 전에 직접적인 충돌을 지적하고 "순서대로 land할 것"을 제안합니다.
• 대기 측과 보유 측 모두에게 알림: 대기 중인 PR에는 "어떤 PR의 뒤에 있는지"를, 보유 중인 PR에는 "뒤에 몇 개가 대기 중인지, 빨리 land해서 lane을 비워달라"고 양측에 전달합니다.
• 착지 순서 제안: 서로 얽힌 PR 그룹에는 가장 토대가 되는 것부터 착지하는 순서를 제안합니다. 후속 PR들은 단 한 번의 rebase만 수행하면 됩니다.

B. 「Heads up」— 텍스트로는 보이지 않는 관계

• 의미적 결합 경고: git의 textual merge로는 보이지 않는 구조적 결합(다른 파일에서의 참조, 공유 테이블, 공유 config 키 등)으로 2개의 PR이 연결되어 있을 때, "이것은 git conflict는 아니지만, merge 전에 맞춰두는 것이 좋다"라는 heads-up을 보냅니다.
• 상류 의존성(Upstream dependency)이 지금 막 변하고 있음: 자신의 PR이 토대로 삼고 있는 부분을 다른 in-flight 변경사항이 지금 막 수정하고 있을 때 경고합니다. 이는 나중에 다시 만들어야 하는 "재작업의 함정(rework trap)"입니다.
• 파급 범위 (blast radius): 변경의 구조적인 하류(downstream)를 보여주며, 그 확산 범위가 클 때는 "wide"와 같이 성질로 전달합니다 (가공되지 않은 건수를 출력하지는 않습니다).
• 반복적으로 충돌하는 토대 파일의 분할 제안: 독립적인 변경사항들이 반복적으로 동일한 토대 파일에서 충돌할 때, 해당 파일의 분할을 후보로 제안합니다 (해당 PR이 실제로 건드리는 파일에 한정합니다).
• main이 내 작업 중에 움직임: branch를 딴 후, 내가 편집 중인 파일이 main 측에서 업데이트되었다면, merge 시 conflict가 발생하기 전에 rebase를 촉구합니다. 병렬 PR 탐지만으로는 놓치기 쉬운 부분입니다.

C. 「Unknown」— 모르는 것을 Clear로 섞지 않기

• Unknown의 이유를 구분: "단순히 이 PR에서 신규 추가된 파일(merge 후에 계산 가능하며, 이는 경고가 아님)"과, "정말로 분석할 수 없었던 gap(unknown으로 취급)"을 구분합니다. 둘 다 편의상 Clear로 몰아넣지 않습니다.
• 억제된 결합을 침묵시키지 않음: 널리 공유된 파일을 경유하는 결합을 전체 그룹에 대한 경고로 만들지는 않으면서도, Clear라고 말하지도 않고, Unknown으로서 "이곳은 침묵하는 것이 아니라, 확인되지 않았다"라고 보이게 합니다.

D. hard fail과 acknowledge

• 미해결된 conflict marker: PR이 추가한 미해결된 conflict marker(git이 남기는 미해결 충돌 마커 쌍)를 행의 내용을 읽지 않고도 감지하여, check를 hard-fail 시킵니다. Veripsa가 스스로 내보내는 유일한 hard fail입니다.
• ACK (acknowledge to proceed)와 그 재확인: 진짜 cross-PR coupling은 veripsa-ack 라벨로 명시적으로 확인하기 전까지 action_required 상태로 유지됩니다. 이것은 approval이나 pardon이 아니라, "이 결합을 확인한 상태에서 진행한다"라는 기록입니다. 결합이 변하면 다시 pause하고 재확인을 요구합니다.

이렇게 나열해 보면 알 수 있는 점은, 이 모든 것이 "이 PR의 코드가 좋은가 나쁜가"가 아니라, **"지금 다른 곳에서 움직이고 있는 변경사항과의 관계"**를 기술하고 있다는 점입니다. 이것이 공유 컨텍스트의 정체입니다.

실물: 2개의 PR이 동시에 open되어 있을 때

추상론만으로는 이해하기 어려우므로, 공개 demo repository를 보겠습니다.

• 공개 lab: GetVeripsa/ai-pr-collision-lab
• PR #14 — Agent B 가정: flat $10 large-cart discount
• PR #13 — Agent A 가정: 5% bulk discount over $100

두 PR 모두 orders/pricing.py와 tests/test_pricing.py를 편집합니다. 둘 다 동시에 open되어 있었기에, 제가 PR 상의 Veripsa comment를 확인했을 때 다음과 같이 나와 있었습니다 (확인 시점의 실제 표시).

보유하고 있는 측, PR #14:

✓ Clear — nothing is blocking you

1개의 진행 중인(in-flight) PR이 다음 파일들에서 이 PR 뒤에서 대기 중입니다:
orders/pricing.py,
tests/test_pricing.py

뒤에서 기다리는 측, PR #13:

⏸ Wait in line — 앞쪽에 직접적인 충돌이 있습니다

당신은 calculate_total (in orders/pricing.py)에서 충돌합니다 — 이는 단순히 같은 파일이 아니라, 같은 코드입니다.

PR #13에는 추가로, orders/pricing.py의 22행 부근에서 rebase 시 textual conflict가 발생하기 쉽다는 heads-up과, 착지 순서(#14 → #13)가 함께 제공됩니다. 여기서 읽을 수 있는 내용은 다음과 같습니다.

• 두 PR 모두 단독으로는 타당하고 작은 변경입니다. 나쁜 PR이라는 뜻이 아닙니다.
• 두 개를 동시에 보고 나서야 비로소 "같은 calculate_total을 건드리고 있다", "#14가 먼저다"라는 공유 컨텍스트 (shared context)가 나타납니다.
• PR #14의 Clear는 "구현이 올바르다"는 증명이 아니라, "보이는 traffic 상에서 먼저 들어가야 할 상대가 없다"라는 제한된 의미입니다.

동일한 2개 에이전트의 충돌을 한쪽을 merge하기 전후의 before/after로 추적한 사례는 "2개의 AI 에이전트가 같은 파일을 편집—PR 충돌을 merge 전에 보는 GitHub App"과, "merge 전에 무엇을 읽어야 하는가에 대한 절차는 Claude Code/Codex의 PR이 충돌하기 전에 봐야 할 것"으로 나누어 설명하고 있습니다.

content-free — private repo에 넣기 위한 신뢰 경계 (trust boundary)

공유 영역에 상황을 기록한다고 하면, "소스 코드를 맡기는 것인가" 하는 우려가 생길 수 있습니다.

Veripsa Core는 source file body나 diff body를 저장하거나 표시하지 않습니다. signal을 계산하기 위해 repository content를 처리 시점에 일시적으로 읽을 수는 있지만, 영구적으로 저장하거나, comment에 붙여넣거나, code review 출력물로 재사용하지 않고 처리 후 폐기합니다.

이는 Veripsa의 핵심 가치 그 자체라기보다, **private repository에 넣어주기 위한 신뢰 경계 (trust boundary)**입니다. 무엇을 저장하고 무엇을 저장하지 않는지에 대한 정확한 구분은 "소스 본문을 맡기지 않고, PR 간의 충돌은 어디까지 보이는가"에 정리되어 있습니다.

지금 할 수 있는 것 / 아직 할 수 없는 것

공유 컨텍스트라고 해도, 현재의 대상 범위는 명확합니다.

• 대상은 1개의 installed repository 내의 open PR입니다. 동일한 owner의 다른 repository를 가로지르는 cross-repository / cross-owner 협업은 아직 제공 범위가 아닙니다.
• Veripsa는 advisory by default입니다. agent의 session에 상황을 자동으로 주입하거나, 자동으로 merge 또는 conflict 해결을 수행하지 않습니다. 공유 영역에 상황을 두고, 사람과 agent가 PR 상에서 읽는 형태입니다.
• 무엇을 block할지는 repository 측에서 Veripsa check를 branch protection / rulesets의 required check로 설정하느냐에 따라 결정됩니다.

도입 시 바로 merge gate로 설정할 필요는 없습니다.

• selected repository를 하나 선택한다.
• branch protection은 변경하지 않고, advisory 모드로 check / comment를 관찰한다.
• Clear / Heads up / Wait in line / Unknown이 어떻게 나타나는지 확인한다.
• 운영에 적합하다고 판단되면, required check로의 승격을 검토한다.

요약

단 한 명이라도 여러 개의 AI agent를 실행하고 있다면, 당신은 이미 분산 팀을 운영하고 있는 것입니다. 이때 병목이 발생하는 것은 각 AI의 지능 문제보다 먼저, "지금 다른 PR이 무엇을 바꾸고 있는가"라는 공유 컨텍스트 (shared context)의 결여입니다.

• 각 agent는 자신의 task만 본다.
• 개별 chat의 답변은 공유 상태가 되지 않는다.
• 상황은 push / merge / close에 따라 계속 움직인다.
• 단 한 번의 분석으로는 정보가 낡아진다.

Veripsa Core는 이 공유 컨텍스트를, 모두가 이미 공유하고 있는 GitHub의 PR 위에 작성합니다. 충돌은 그 공유 컨텍스트가 결여되었을 때 나타나는 증상 중 하나입니다.

토론 (Discussion)