AI 에이전트가 여러 명이 되니, 사람 팀이 겪던 문제가 그대로 돌아왔어요
요즘 Claude Code 같은 AI 코딩 에이전트를 하나만 띄워서 쓰는 게 아니라, 여러 개를 동시에 돌리는 개발자들이 늘고 있어요. 하나한테는 버그 수정을 시키고, 다른 하나한테는 리팩토링, 또 하나한테는 테스트 작성을 맡기는 식으로요. 에이전트가 알아서 몇십 분씩 작업을 하니까, 사람은 감독만 하면서 처리량을 몇 배로 끌어올리는 거죠.
그런데 이렇게 하면 곧바로 벽에 부딪혀요. 여러 에이전트가 같은 저장소를 동시에 고치면 서로의 변경사항이 충돌하거든요. A 에이전트가 고친 파일을 B 에이전트도 건드렸다면 나중에 합칠 때 머지 충돌이 나고, 운이 나쁘면 각자 브랜치에서는 테스트를 통과했는데 합쳐놓으니 빌드가 깨지는 상황도 생겨요. 사람 개발자 여럿이 한 저장소에서 일할 때 겪던 고전적인 문제가 에이전트 시대에 그대로 재현된 건데요. 이번에 GitHub에 공개된 한 오픈소스 프로젝트는 이 문제를 '로컬 머지 큐'라는 접근으로 풀었어요.
머지 큐가 뭐냐면
머지 큐(merge queue)는 원래 규모가 큰 조직에서 쓰던 개념이에요. 이게 뭐냐면, 완성된 변경사항들을 줄 세워놓고 한 번에 하나씩, 최신 메인 브랜치 위에 다시 얹어서 테스트를 돌린 다음, 통과한 것만 머지하는 장치예요. 핵심은 '내 브랜치에서 통과'가 아니라 '합쳐진 상태에서 통과'를 보장한다는 점이에요. 각자 브랜치에서는 멀쩡했던 코드 둘이 만나는 순간 깨지는, 이른바 의미적 충돌까지 걸러낼 수 있거든요. GitHub에도 Merge Queue 기능이 내장돼 있고, Rust 프로젝트가 오래 써온 Bors라는 봇이 이 방식의 원조 격이에요.
이 프로젝트는 그 개념을 개인 개발자의 로컬 환경으로 가져왔어요. 흐름은 대략 이래요. 먼저 git worktree로 에이전트마다 독립된 작업 폴더를 만들어줘요. worktree가 뭐냐면, 저장소를 통째로 다시 클론하지 않고도 같은 저장소의 서로 다른 브랜치를 별도 폴더에 동시에 펼쳐놓을 수 있는 git 기능이에요. 덕분에 에이전트들이 서로의 파일을 밟지 않고 각자 방에서 일할 수 있죠. 에이전트가 작업을 마치면 그 브랜치를 큐에 등록하고, 큐는 순서대로 하나씩 꺼내서 최신 메인에 얹고 테스트를 돌린 뒤 통과하면 머지해요. 충돌이나 테스트 실패가 나면 그 브랜치만 탈락시키고 다음 것을 처리하고요. GitHub의 유료 기능이나 별도 CI 서버 없이 내 컴퓨터 안에서 이 파이프라인이 돈다는 게 포인트예요.
'에이전트 오케스트레이션'이라는 큰 흐름
한 발 떨어져서 보면 이건 지금 업계에서 벌어지는 큰 흐름의 한 조각이에요. 얼마 전까지는 "에이전트한테 일을 어떻게 시킬까"가 화두였다면, 요즘은 "에이전트 여러 개를 어떻게 굴릴까", 즉 오케스트레이션이 화두거든요. Claude Code 자체도 서브에이전트나 병렬 세션 같은 개념을 키워가고 있고, 커뮤니티에서는 worktree 기반 병렬 작업 스크립트가 쏟아지고 있어요. 재미있는 건 그 해법들이 대부분 사람 팀을 위해 만들어진 도구, 그러니까 브랜치 전략, 코드 리뷰, CI, 머지 큐의 재활용이라는 거예요. 에이전트가 사실상 '동료 개발자'로 취급되기 시작했다는 뜻이죠.
한국 개발자에게는
Claude Code나 비슷한 에이전트를 이미 쓰고 있다면 병렬 운용은 생각보다 가까운 미래예요. 그때 이런 로컬 머지 큐 패턴을 알아두면 "에이전트 셋 돌렸더니 저장소가 걸레가 됐다"는 참사를 예방할 수 있어요. 당장 에이전트를 안 쓰더라도 git worktree와 머지 큐 개념 자체가 실무에서 그대로 유용하고요. 특히 이 구조는 테스트 스위트가 튼튼해야 의미가 있다는 점을 곱씹어볼 만해요. 결국 에이전트 시대에 사람이 공들여야 할 곳은 코드 그 자체보다 코드를 검증하는 장치라는 얘기거든요.
한 줄 정리: AI 에이전트를 병렬로 돌리는 순간 필요해지는 건 더 똑똑한 AI가 아니라, 사람 팀이 쓰던 머지 큐 같은 협업 인프라다. 여러분은 에이전트를 동시에 몇 개까지 돌려보셨나요? 충돌 문제는 어떻게 해결하고 계신지 궁금해요.
🔗 출처: Hacker News