고민되는 지점

Claude Code나 Codex를 3체 이상 병렬로 돌리기 시작한 사람이라면, 아마 똑같은 문제에 직면했을 것입니다.

• agent A와 agent B가 서로 다른 브랜치에서 같은 함수의 같은 행을 각각 수정함 - 한쪽을 merge → 다른 쪽은 rebase가 필요함 → conflict 발생
• 혹은 "rebase는 통과했다"고 하지만, 한쪽의 변경 사항이 의미적으로 덮어씌워져(overwrite) 나중에 제대로 동작하지 않음

사람 3명이 같은 파일을 만져도 이런 일이 발생합니다. 에이전트를 5체 병렬로 돌리면 빈도는 단순하게 올라갑니다. 게다가 이를 깨닫는 시점은 항상 merge 후입니다.

CI를 빠르게 하거나 코드 리뷰를 강화하더라도 이 문제는 사라지지 않습니다. CI는 "해당 PR 단독으로 통과하는가"를 보고, 리뷰는 "해당 PR의 내용이 좋은가"를 봅니다. 열려 있는 PR들끼리 같은 지점에 착지하려고 한다는 가로 방향의 관계는 어느 쪽의 시야에도 들어오지 않기 때문입니다.

처음에 막히는 것은 '조정(Adjustment)' 레이어였다

병렬로 에이전트를 돌리기 시작하며 실감한 것은, 병목이 "코드를 빠르게 쓰는 것"이나 "리뷰의 질"이 아니라, 착지 순서와 중첩의 조정으로 옮겨간다는 사실이었습니다. 사람 한 명이라면 머릿속에 있던 "지금 이것과 이것을 동시에 만지고 있으니, 저쪽을 먼저 넣자"라는 판단이, 에이전트를 늘리는 순간 누구의 머릿속에서도 사라집니다.

필요한 것은 merge한 뒤에 깨닫는 것이 아니라, PR이 아직 작성되는 도중에 "이 두 개는 같은 곳에 착지할 것 같아"라고 말해주는 조언이었습니다. 차단(block)이 아니라 조언이면 충분합니다. 착지 순서를 결정하는 것은 사람이기(혹은 지시를 받은 에이전트이기) 때문입니다.

다만, 코드 본문은 전달하고 싶지 않다

여기서 보통 고민하게 되는 지점은, 제3자의 분석 서비스에 코드 본문을 통째로 넘겨야 한다는 전제입니다. 사내 코드를 전부 학습시키는 계약은 운영상으로나 법무상으로나 부담이 큽니다. 개인 개발이라 하더라도 자신의 코드를 외부에 맡기는 판단은 가볍지 않습니다.

그래서 설계의 출발점을 "본문을 저장하지 않는다·표시하지 않는다"에 두었습니다. 판정에 사용하는 것은 "어디를 건드렸는가"라는 최소한의 정보뿐이며, 함수 내용 그 자체는 가지지 않습니다. 이 선을 처음에 그어두면 이후의 설계가 훨씬 수월해집니다.

'읽지 않음'을 선택하면 무엇을 얻을 수 있는가

본문을 읽지 않는 설계에는 소소하지만 효과적인 실익이 두 가지 있습니다.

• 프라이버시 (Privacy): PR의 diff 본문을 외부에 전달하지 않습니다. "어디를 건드렸는가"라는 좌표 정보만으로 판정이 성립한다면, 애초에 본문을 맡길 필요가 없습니다.
• 재현성 (Reproducibility): 동일한 commit에 대해서는 동일한 판정이 내려집니다. 본문의 세부 사항을 LLM에게 "다시 읽게 하는" 설계라면 실행할 때마다 해석이 흔들릴 여지가 남지만, 좌표 기반이라면 그 부분이 안정됩니다.

당연히 놓치는 부분도 있다. 그래서 역할 분담

솔직히 말하면, 본문을 읽지 않는 설계는 "본문을 읽으면 알 수 있는 semantic(의미론적) 충돌"을 구조적으로 놓치게 됩니다. 함수명은 다르지만 한쪽이 API의 전제를 조용히 깨뜨리고 있는 경우—이런 것은 좌표만 봐서는 알 수 없습니다.

하지만 그것은 놓쳐도 괜찮습니다. 그곳은 AI code reviewer의 역할이기 때문입니다. 정리하자면, 병렬 개발에는 성격이 다른 세 가지 레이어가 있습니다.

• merge queue: 리뷰가 완료된 PR을 main에 넣는 순서와 안정성 측면에서 처리함 (merge 시점)
• AI code review: 해당 PR 단독의 내용이 좋은지 나쁜지를 봄 (PR 작성 중)
• 병렬 PR의 충돌 조정: 열려 있는 PR들끼리 같은 곳에 착지할 것인지를 착지 전에 조언함 (PR이 아직 작성되는 도중)

이 세 가지는 비슷해 보이지만, 바라보는 시간축과 대상이 다릅니다. "읽지 않는" collision 조정은 나머지 두 개를 대체하는 것이 아니라, 옆에 추가되는 하나의 레이어입니다.

대국 (Big Picture)

AI 에이전트를 병렬로 실행하는 시대에 가장 먼저 현상화되는 것은 CI도 코드 리뷰도 아닌 "병렬 PR 간의 충돌 조정"이었습니다. 에이전트 수가 늘어날수록 효과가 나타나는 종류의 병목이며, CI를 빠르게 한다고 해서 사라지지 않습니다.

그리고 그 조정은 본문을 읽지 않고도 상당한 수준까지 가능합니다. "처음부터 읽지 않는 설계를 선택한다"면, 프라이버시 요건과 재현성을 동시에 확보할 수 있고 역할 분담도 깔끔해집니다.

CTA

이 pre-merge 충돌 조정(conflict resolution) 과정을 GitHub App으로 구현한 것이 Veripsa Core입니다. 본문 내용은 저장하지 않고, "어디를 수정했는지"에 대한 최소한의 메타데이터만을 사용하여, 열려 있는 PR(Pull Request)들 사이의 중첩(overlap)을 머지(merge)하기 전에 조언해 줍니다. 한 번의 설치로 이후의 모든 PR에 조언 체크 기능이 추가됩니다.

병렬 에이전트 사용 시 "머지한 후에야 문제를 깨닫는" 상황이 늘어나고 있다면, 한 번 살펴보시기 바랍니다.

Discussion