Git 머지 전략에 정답은 없습니다. 혼자 쓰는 저장소와 수백 명이 붙는 대기업 저장소가 같은 방식일 수는 없으니까요. 전략을 가르던 축은 오랫동안 팀 크기와 릴리스 주기 하나였습니다.

그런데 최근에 축이 하나 더 생겼습니다. AI가 코드를 쓰기 시작하면서, 병목이 코드 작성에서 “이걸 머지해도 되나”를 판단하는 리뷰로 옮겨간 것입니다.

브랜치가 갈라지고 합쳐지는 모습을 표현한 3D 에디터리얼 콘셉트 씬 브랜치가 갈라지고 합쳐지는 모습을 표현한 3D 에디터리얼 콘셉트 씬 — 출처: 개념 컷 · agy 자가 생성

먼저, 팀 크기가 전략을 가른다

브랜치 전략은 크게 짧게 자주 합치느냐(트렁크 기반), 여러 장수 브랜치로 릴리스를 통제하느냐(GitFlow)로 갈립니다. 어느 쪽이 맞는지는 규모가 정합니다.

[1인 개발] main 하나에 바로 쌓거나 짧은 브랜치만. GitFlow 는 오버헤드

[소규모(스타트업)] GitHub Flow 나 트렁크 기반. 짧게 살고 빨리 합치는 브랜치 + PR 리뷰 한 명

[엔터프라이즈] 여러 버전을 동시에 유지하고 규제·감사를 받아 GitFlow·릴리스 브랜치가 필요

정리하면 작은 팀일수록 트렁크로 단순하게, 큰 팀일수록 브랜치로 통제가 기본값이었습니다. 여기까지가 AI 이전의 그림입니다.

합치는 방식도 모양이 다르다

같은 “합치기”라도 커밋 히스토리에 남는 모양이 다릅니다.

[fast-forward] 갈래 없이 그대로 이어 붙어 그래프가 한 줄로 남음

[merge commit] 두 갈래를 합치며 병합 커밋을 하나 남김. 갈라졌다 만난 자국이 보임

[squash] 여러 커밋을 하나로 눌러 합침. 깔끔한 대신 중간 과정이 사라짐

[rebase] 브랜치를 최신 위로 옮겨 다시 쌓음. 한 줄로 깔끔하지만 커밋 해시가 바뀜

작은 팀은 squash로 히스토리를 단순하게 두는 경우가 많고, 엔터프라이즈는 merge commit으로 병합 이력을 남겨 추적성을 확보하는 쪽으로 갈립니다. 어느 것도 정답은 아니고 팀이 추적성과 단순함 중 무엇을 앞에 두느냐가 정합니다.

네 방식이 커밋 그래프에 어떻게 다르게 남는지는 한 단계씩 넘겨 보면 훨씬 빨리 이해됩니다. 그림은 제가 직접 만든 시각화 웹 Oh My Algorithm에서 가져온 것으로, 알고리즘과 기술 개념을 스크롤하며 한 단계씩 보여 주는 사이트입니다. 브랜치·머지 편에서 네 방식을 직접 눌러 볼 수 있고, 뒤에 나올 1인·규모별 리뷰 이야기도 같은 사이트에 편으로 있습니다.

🔗 링크 첨부 - https://www.ohmyalgorithm.com/algorithms/git/git-branch-merge

코드는 늘었는데 리뷰가 못 따라간다

소프트웨어 품질 도구 회사 Sonar가 2026년 초 현업 개발자 1,100명 이상에게 물었더니, 커밋되는 코드의 42%가 AI가 쓴 것이었습니다. 응답자들은 2027년에 이 비율이 65%까지 오를 것으로 봤어요.

그런데 같은 조사에서 나온 다른 숫자가 더 눈에 띕니다.

[신뢰] 96%가 AI 가 쓴 코드를 완전히 신뢰하지는 않는다고 응답

[검증] 커밋 전에 항상 검증한다는 응답은 48%

[리뷰 부담] 38%는 AI 코드 리뷰가 동료 코드보다 손이 더 간다고 응답

[검증에 쓰는 시간] 주당 근무 시간의 약 24%

신뢰하지 않는데 절반은 그냥 넘어가고, 넘어가지 않은 쪽은 근무 시간의 4분의 1을 검증에 쓴다는 뜻입니다. 어느 쪽이든 부담이 리뷰 단계로 몰립니다.

AI 도입률 높은 팀의 지표 변화 (전년 대비) AI 도입률 높은 팀의 지표 변화 (전년 대비) — 출처: Faros.ai 2026 자료 기반 자가 렌더

개발 데이터 분석 회사 Faros.ai는 1,255개 팀·개발자 1만 명 이상의 실제 활동 로그를 최대 2년치 모아 분기별로 비교했습니다. AI 도입률이 높은 팀에서 머지된 PR이 98% 늘었고, 완료한 작업은 21% 늘었습니다. 코드가 빨리 나오는 건 사실이에요.

문제는 같이 늘어난 것들입니다. PR 리뷰 시간이 91% 늘었고, 평균 PR 크기가 154%로 두 배 반이 됐습니다. 개발자당 버그도 9% 늘었고요. 리뷰어 입장에서는 덩치가 두 배 반이 된 PR이 두 배 많이 들어오는 셈입니다.

Faros는 결론에서 한 가지를 덧붙였습니다. 회사 단위로 보면 AI 도입률과 처리량·DORA 지표·품질 지표 사이에 유의한 상관관계가 없었다는 겁니다. 개인과 팀 단위에서는 분명히 빨라졌는데, 그게 회사가 내보내는 결과물로 이어지지는 않았습니다.

대기 줄은 리뷰어 앞에 생긴다

어디서 막히는지는 LinearB의 집계가 구체적입니다. 42개국 4,800개 조직에서 나온 PR 810만 건을 분석한 2026년 벤치마크인데, 여기서 나온 숫자가 병목의 위치를 정확히 짚습니다.

리뷰어가 PR을 집을 때까지 걸린 시간 리뷰어가 PR을 집을 때까지 걸린 시간 — 출처: LinearB 2026 벤치마크 기반 자가 렌더

같은 팀 안에서 사람이 쓴 PR은 리뷰어가 201분 만에 검토에 착수했는데, AI 에이전트가 올린 PR은 1,055분이 걸렸습니다. 5.3배예요. 사람이 AI 도구를 거들어 쓴 PR까지 다 합쳐도 4.6배입니다.

재미있는 건 일단 리뷰가 시작되면 AI PR이 2배 빨리 끝난다는 점입니다. 리뷰 자체가 오래 걸리는 게 아니라, 아무도 먼저 검토를 시작하려 하지 않아서 줄이 길어지는 겁니다. 그리고 그럴 만한 이유가 있었습니다. AI가 만든 PR의 수락률은 32.7%로, 사람이 쓴 PR의 84.4%와 크게 차이가 났습니다. 세 개 중 두 개는 결국 안 들어가는 PR을 열어 보는 일이 되니까요.

그래서 main에는 덜 들어간다

CircleCI는 2025년 9월 한 달간 자사에서 돌아간 워크플로 2,873만 건을 뜯어봤습니다. 전체 평균 처리량은 전년 대비 59% 증가로, 2019년 첫 보고서 이후 가장 큰 폭입니다.

그런데 이 59%는 평균이 만든 착시였습니다.

중앙값 팀의 브랜치별 처리량 변화 (전년 대비) 중앙값 팀의 브랜치별 처리량 변화 (전년 대비) — 출처: CircleCI 2026 보고서 기반 자가 렌더

[중앙값 팀] 피처 브랜치는 15% 증가, main 브랜치는 7% 감소

[상위 10%] 피처 브랜치 약 50% 증가, main 은 1% 증가

[상위 5%] 피처 85%, main 도 26% 증가

즉 평균 59%는 상위 5%가 끌어올린 값이고, 보통 팀에서는 브랜치에서만 활동이 늘고 실제 배포되는 main 처리량은 오히려 감소했습니다.

품질 지표도 같이 나빠졌습니다. main 브랜치 성공률이 70.8%로 5년 넘는 기간 중 최저였습니다. CircleCI가 권장하는 기준은 90%인데, 지금은 main에 합치려는 시도 열 번 중 세 번이 실패한다는 뜻이에요. 깨진 뒤 복구까지 걸리는 시간도 평균 72분으로 전년 대비 13% 늘었습니다(권장 60분).

그래서 리뷰를 나눠 맡는다

해법의 방향은 AI와 사람이 리뷰를 분담하는 것입니다.

[AI 가 1차] 서식, 알려진 취약점 패턴, 뻔한 버그처럼 규칙으로 잡히는 것

[사람이 2차] 이 변경이 맞는 문제를 푸는지, 구조와 비즈니스 로직

하나 더, PR을 작게 쪼개는 것이 예전보다 훨씬 중요해졌습니다. 앞서 본 대로 AI 도입 팀의 평균 PR 크기가 154% 늘었는데, 이건 리뷰어가 검토 착수를 미루는 직접적인 원인입니다. 덩치를 줄이는 건 도구가 대신 해 주지 않고 올리는 사람이 정해야 합니다.

국내 사례, 채널톡이 6개월 만에 바뀐 것

국내에도 이 전환을 공개한 팀이 있습니다. 채널톡은 Cursor를 전사 도구로 도입하고 JetBrains를 팀 전체에서 해지했는데, 6개월 뒤 변화를 기술 블로그에 정리했습니다.

[코드량] 4월 인당 250줄에서 7월 10일 기준 인당 1,000줄로 약 4배

[백엔드] 에러 로그 분석부터 원인 파악까지 자동화해 버그 대응·PR 리뷰 시간 90% 단축

[프론트엔드] Figma 디자인 명세에서 동작하는 React 컴포넌트까지 프롬프트로 생성

채널톡은 도구만 깔고 끝낸 게 아니라 온보딩·리팩터링·PR 리뷰·UI 구현 프로세스 자체를 AI 중심으로 다시 짰습니다. 앞의 통계에서 상위 5%와 나머지를 가른 게 무엇인지 짐작하게 하는 대목이에요.

🔗 링크 첨부 - https://tech.channel.io/kr/articles/tech-cursor-implementation-d35d88c4

다시, 팀 크기별로, AI 시대 버전

축이 하나 더 생겼으니 규모별로 다시 정리해 봅니다.

[1인 개발] 트렁크는 그대로 두되 AI 1차 리뷰를 붙이고 최종 판단만 직접

[소규모] 작은 PR + AI 자동 리뷰를 CI 게이트로, 사람 한 명은 구조·의도만

[엔터프라이즈] AI 리뷰를 필수 검증 단계로, 사람은 아키텍처·보안·규제에 집중

전략의 기본 방향(작을수록 트렁크, 클수록 통제)은 그대로입니다. 달라진 건 모든 규모에 “AI 1차 리뷰” 단계가 추가됐고, 사람의 역할이 코드 검사에서 판단으로 옮겨간 것입니다.

정리하면

규모 과거(사람 작성·리뷰) 현재(AI 작성 + AI·사람 리뷰)
1인 main 직접·짧은 브랜치, 리뷰 없음 트렁크 + AI 1차 리뷰, 내가 최종
소규모 GitHub Flow, 사람 1명 PR 리뷰 작은 PR + AI 게이트, 사람은 구조
엔터프라이즈 GitFlow·릴리스 브랜치, 다단계 리뷰 AI 필수 게이트, 사람은 아키텍처·규제

머지 전략을 고를 때 이제 두 가지를 함께 봅니다. 우리 팀 크기, 그리고 AI가 쓴 코드를 누가 어떻게 거를 것인가. 코드를 빨리 쓰는 건 이미 풀렸고, 남은 핵심 과제는 합쳐도 되는지를 정하는 속도입니다.

지표 하나만 본다면 커밋 수나 PR 수가 아니라 main 브랜치에 실제로 들어간 양을 보는 게 맞습니다. 그게 늘지 않으면 나머지는 브랜치에 쌓여 있을 뿐이니까요.

참고 출처