병합 충돌은 지루해졌다

2026년 10월 21일 · 2분

내가 일했던 모든 팀에서는 비슷한 일이 벌어졌다. 두 개의 PR이 같은 파일을 수정하고 비슷한 시점에 승인을 받으면, 누구도 말은 안 하지만 서로 먼저 병합하려 했다. 늦게 병합한 사람은 충돌을 해결하느라 대개 오후의 나머지 시간을 보내기 때문이다. 나도 자주 그랬고, 채팅에서 “곧 병합할 거야?”라고 묻는 쪽이 되기도 했다. 정중한 표현일 뿐, 먼저 병합하려는 행동과 다르지 않았다.

올봄쯤 그런 행동을 멈췄다는 걸 알아차렸다. 이유를 깨닫는 데는 시간이 걸렸지만, 코딩 에이전트가 충돌 해결을 잘하게 된 것이었다. 오히려 충돌은 전보다 늘었다. 보통 에이전트 몇 개가 같은 저장소에서 동시에 작업해 서로 부딪히기 때문이다.

브랜치에서 충돌이 나면 에이전트에게 main을 기준으로 리베이스하고 문제를 해결하라고 한 뒤 다른 일을 한다. 에이전트는 양쪽 변경 사항과 충돌을 일으킨 main의 커밋을 살펴본다. 다른 PR의 설명을 읽어 변경 이유를 파악하고, 병합된 버전을 작성한 다음 테스트를 실행하고 푸시한다. 돌아와 보면 충돌마다 짧은 설명이 붙은 해결 브랜치가 있다. 나는 변경 사항(diff)을 읽는다. 올해 GitHub는 병합 창에 ‘Fix with Copilot’ 버튼을 추가해 같은 작업을 할 수 있게 했다. 휴대전화 앱에서도 작동하는데, 이건 아주 편리한 일일 수도 있고 우리가 일하는 방식에 문제가 생겼다는 신호일 수도 있다.

충돌에서 가장 힘들었던 건 맥락을 전환하는 일이었다고 생각한다. 이미 다른 일로 넘어갔는데, 이제 두 가지 의도를 다시 떠올려야 한다. 그중 하나는 다른 사람의 의도다. 짜증이 난 상태에서 두 가지를 올바르게 합쳐야 한다. 에이전트는 하던 일을 멈추고 다른 맥락으로 전환할 필요가 없고, 금요일 오후 6시에 처리하는 것도 꺼리지 않는다.

이런 상황에서는 먼저 병합하려고 경쟁할 이유가 없다. 나중에 병합해도 변경 사항을 몇 분간 읽으면 된다. 지난 몇 달 동안 “곧 병합할 거야?”라는 질문을 듣지 못했고, 오래 걸리는 브랜치를 매일 아침 불안해서 리베이스하는 일도 그만뒀다.

그래도 병합 전에 해결 결과를 모두 읽는다. 내가 경험한 바로는 에이전트가 흔한 충돌은 거의 매번 제대로 해결한다. 가끔은 내가 다르게 판단했을 만한 결정을 내리는데, 대개 두 브랜치가 서로 다른 이유로 같은 로직을 바꾼 경우다. 어떤 도구도 잡아내지 못하는 사례도 있다. 예를 들어 한 브랜치가 설정 키 이름을 바꾸는 동안 다른 브랜치가 이전 이름을 읽는 새 위치를 추가하면, Git은 충돌을 보고하지 않는다. 그러므로 테스트는 여전히 중요하다.

일상 업무에서는 이 문제가 거의 해결된 것처럼 느껴져 더는 신경 쓰지 않게 됐다. 훨씬 큰 팀에서도 같은 변화가 나타나는지, 아니면 팀 규모가 커지면 다시 문제가 생기는지 궁금하다.