uyeon.dev
게시일

에이전트는 GitFlow에서 길을 잃는다: AI 네이티브 개발이 트렁크로 수렴하는 이유

2010년 1월, 빈센트 드리센(Vincent Driessen)이 블로그에 “A successful Git branching model”이라는 글을 올렸다. develop, feature, release, hotfix, main. 다섯 개의 브랜치가 맞물려 돌아가는 그 다이어그램이 GitFlow다. 이후 10년간 전 세계 개발팀의 위키 첫 페이지에 이 그림이 붙었다.

10년 뒤, 드리센은 같은 글 맨 위에 회고 노트를 달았다. 철회는 아니다. 명시적으로 버전을 관리하는 소프트웨어에는 여전히 유효하다고 남겨뒀다. 다만 용도를 좁혔다. 지속적으로 배포하는 웹 앱이라면 GitFlow 대신 훨씬 단순한 워크플로우를 고려하라고. 자신이 10년 전에 상상한 소프트웨어는 그런 게 아니었다고. GitFlow 튜토리얼로 유명한 Atlassian도 지금은 이 방식을 “레거시 워크플로우”로 분류하고, 해당 페이지가 “역사적 기록 목적”이라고 못박아뒀다.

그런데 2026년에도 GitFlow는, 혹은 그 사촌인 개발/운영 환경 브랜치 모델은 여전히 수많은 팀의 기본값이다. 돌아가고 있기 때문이다. 브랜치 전략은 너무 기본적인 것이라, 한번 자리 잡으면 아무도 다시 들여다보지 않는다.

사람끼리 일하던 시절에는 그래도 괜찮았다. 불편해도 감당은 됐으니까. 에이전트가 코드를 쓰는 AI 네이티브 개발에서는 그 감당이 끝난다. 브랜치 전략은 이제 취향의 문제가 아니라 처리량의 문제고, 그 답은 트렁크 기반으로 수렴하고 있다. 이 글은 그 이유를 짚는다.

GitFlow는 그 시대엔 맞았다

GitFlow가 나쁜 설계였던 건 아니다.

2010년에 배포는 무서운 일이었다. CI는 흔치 않았고, 테스트 자동화는 사치였고, 배포는 분기에 한 번 날 잡고 치르는 행사였다. 통합이 그렇게 비싸고 위험하니, 위험한 것들을 브랜치에 격리해두는 게 최선이었다. 미완성 코드는 develop에, 출시 후보는 release에, 운영 코드는 main에. 합리적이다.

문제는 그 전제가 다 사라졌다는 것이다. 지금은 커밋마다 CI가 돌고, 배포는 버튼 하나고, 테스트는 코드와 같이 자란다. 통합을 비싸게 만들던 조건이 없어졌는데, 그 조건 때문에 만든 구조만 습관으로 남았다. 그리고 2026년, 그 습관 위에 에이전트가 올라탔다.

장수 브랜치가 실제로 청구하는 비용

GitFlow를 써본 사람이라면 아래 장면들이 낯설지 않을 것이다. 나부터 그랬다. 소수 인원으로 속도를 내야 하는 팀에서 GitFlow를 곧이곧대로 지키려 해본 적이 있는데, 얼마 안 가 브랜치 전략 자체가 개발의 병목이 됐다.

2주 묵은 feature 브랜치를 develop에 머지하는 날, 반나절이 충돌 해결로 사라진다. 리뷰어는 파일 40개짜리 PR을 받아 들고 “LGTM”을 누른다. 사실상 안 읽었다는 뜻이다. 그렇게 통과한 코드에서 버그가 나오고, 버그는 코드를 쓴 지 3주 뒤에 발견돼서 쓴 사람도 기억을 못 한다.

새벽에 운영 장애가 터져서 main에 핫픽스를 넣는다. develop에도 백머지해야 한다는 걸 그 새벽에 기억해야 한다. 잊으면 다음 릴리스에서 고쳤던 버그가 부활한다. 이것도 겪어봤다. 백머지 규칙은 문서에 명확하게 적혀 있었다. 그런데 급한 불을 끄는 와중에 그 규칙까지 제대로 챙기는 건 전혀 다른 난이도의 일이었다.

그리고 하나 더. 브랜치마다 빌드를 따로 만드는 구조라면, 당신 팀의 QA는 지금까지 단 한 번도 운영에 나간 빌드를 테스트한 적이 없을 수 있다. dev 브랜치에서 검증한 빌드와 main에서 배포한 빌드는 서로 다른 커밋 조합이기 때문이다. 검증한 아티팩트를 그대로 다음 단계로 올리는 빌드 승격(build promotion)이 없으면, 이 어긋남은 누구의 실수 없이도 구조의 기본 동작으로 매 릴리스 반복된다.

여기서 컴포넌트별로 브랜치를 또 쪼갠 변형(개발-프론트, 개발-백엔드, 운영-프론트, 운영-백엔드)까지 가면, API 하나 바꾸는 데 PR이 두 개 필요하고 배포 순서를 사람이 조율해야 한다. 모노레포를 쓰면서 폴리레포의 고통을 재현하는 셈이다.

이 장면들의 뿌리를 따라가면 역설이 하나 나온다. 배포가 무서워서 변경을 모아서 내보낸다. 그런데 모아서 내보내니까 배포가 더 무서워진다. 릴리스 간격을 늘릴수록 릴리스 하나에 담기는 변경이 커지고, 변경이 클수록 사고 확률도, 터졌을 때 원인을 찾는 난이도도 같이 오른다. 그래서 다음엔 더 신중하게, 더 모아서 내보낸다. 악순환이다. 많은 팀이 이 구조를 “우리는 신중하다”로 기억하지만, 그 신중함이 하는 일은 위험을 미래로 이월시키는 것이다. 머지 충돌은 git의 문제가 아니다. 통합을 미뤄둔 시간이 날아온 청구서다.

요즘 트렁크 기반은 이렇게 생겼다

“트렁크 기반”이라고 하면 SVN 시절처럼 다 같이 한 줄에 커밋을 밀어 넣는 그림을 떠올리는 사람이 많다. 브랜치를 정교하게 쓰는 게 우아하고, 트렁크에 다 붓는 건 투박하다는 인상도 있다. 둘 다 오해다. 요즘 방식의 하루는 이렇게 돌아간다.

오전에 이슈를 받고 main에서 브랜치를 딴다. 오후에 PR을 올린다. CI가 통과하고 리뷰가 끝나면 main에 머지하고, 브랜치는 삭제한다. 브랜치의 수명은 길어야 하루다. main에 머지되면 dev 서버에 자동 배포된다. 확인이 끝나면 커밋에 태그를 찍고, 그 태그가 운영 배포를 트리거한다. 이때 새로 빌드하지 않는다. dev에서 검증한 바로 그 빌드가 운영으로 승격된다. 아직 공개하면 안 되는 기능은 코드째 머지하되 feature flag로 꺼둔다.

GitFlow와 트렁크 기반 개발의 경로 비교: GitFlow는 feature→develop→release→main의 머지 4회와 핫픽스 백머지가 필요하고, 트렁크 기반은 단명 브랜치의 머지 1회 후 태그와 파이프라인 승격으로 처리된다GitFlow와 트렁크 기반 개발의 경로 비교: GitFlow는 feature→develop→release→main의 머지 4회와 핫픽스 백머지가 필요하고, 트렁크 기반은 단명 브랜치의 머지 1회 후 태그와 파이프라인 승격으로 처리된다

브랜치는 그대로 남아 있다. 역할만 바뀌었다. GitFlow에서 브랜치는 네 가지 일을 혼자 다 했다. 작업을 격리하고, 환경(dev/prod)을 표현하고, 버전을 보관하고, 미완성 기능을 숨겼다. 요즘 방식은 이 네 가지를 각각 제일 잘하는 도구에 나눠준다. 격리는 하루살이 PR 브랜치가, 환경은 배포 파이프라인이, 버전은 태그가, 숨김은 플래그가 맡는다.

GitFlow 브랜치가 겸직하던 네 가지 역할(작업 격리, 환경 표현, 버전 보관, 기능 숨김)이 트렁크 기반에서 단명 PR 브랜치, 파이프라인 스테이지, 태그·릴리스, feature flag로 각각 재배치되는 매핑GitFlow 브랜치가 겸직하던 네 가지 역할(작업 격리, 환경 표현, 버전 보관, 기능 숨김)이 트렁크 기반에서 단명 PR 브랜치, 파이프라인 스테이지, 태그·릴리스, feature flag로 각각 재배치되는 매핑

통제는 사라지지 않았다. 자리를 옮겼을 뿐이다. GitFlow의 안전장치는 상당 부분 팀의 관례였다. “핫픽스는 백머지할 것”, “release 딴 뒤엔 기능 넣지 말 것”. 아무도 강제하지 않는 규칙들이다. 트렁크 기반의 안전장치는 기계다. 테스트가 빨간불이면 머지 버튼이 눌리지 않고, 승인 없이는 운영 배포가 실행되지 않는다. 사람이 기억해야 할 것은 줄고, 대신 시스템이 막는다.

이 구분이 사람 팀에서는 “좋은 습관” 정도의 차이였다. 에이전트가 합류하면 생존의 차이가 된다.

AI는 브랜치 전략을 증폭시킨다

2025년 DORA 리포트(State of AI-assisted Software Development)는 기술 전문가 약 5천 명을 조사해 한 문장으로 요약되는 결론을 냈다. AI는 팀을 고쳐주지 않는다. 이미 있는 것을 증폭시킨다. 좋은 시스템을 가진 조직은 AI로 더 좋아지고, 망가진 시스템을 가진 조직은 그 망가짐이 더 빨라진다.

이 리포트는 AI 효과를 증폭시키는 7가지 기반 역량을 꼽으면서 그중 두 자리를 버전 관리에 배정했다. “강한 버전 관리 관행”과 “작은 배치로 일하기”다. 잦은 커밋은 AI의 개인 생산성 효과를 증폭시키고, 견고한 롤백 능력은 AI가 쏟아내는 코드 물량을 다룰 때 팀 성과를 끌어올리며, 작은 배치는 AI의 제품 성과 기여를 키우고 마찰을 줄인다. 2010년대 DevOps 연구의 오래된 결론이 AI 시대에 다시 확인된 것인데, 방향은 그대로고 배율만 커졌다.

에이전트 관점에서 보면, 배율이 커지는 구조적 이유가 세 가지 있다.

첫째, 에이전트에게는 관례가 없다. 마틴 파울러의 사이트에 실린 비르기타 뵈켈러(Birgitta Böckeler)의 하네스 엔지니어링 글이 이 지점을 정확히 짚는다. 코딩 에이전트에게는 사회적 책임감도, 300줄짜리 함수에 대한 미적 거부감도, “우리 팀은 그렇게 안 해”라는 직관도, 조직적 기억도 없다. 프롬프트만으로는 이 공백을 못 메운다. 필요한 건 가이드(사전 유도)와 센서(사후 검증)로 짜인 하네스, 즉 린터·테스트·CI 게이트 같은 장치들이다.

“관례를 AGENTS.md에 적으면 되잖아”라는 반론이 나올 수 있다. 실제로 문서화된 컨텍스트를 잘 주면 에이전트 산출물의 품질이 올라가긴 한다. 하지만 핵심 구분이 남는다. 문서화된 관례는 에이전트가 확률적으로 따르고, CI 게이트는 결정론적으로 강제한다. 내 경험도 그랬다. 절차를 문서로 쥐여줘도 에이전트는 세부 단계를 때때로 놓쳤는데, 그 모습이 부주의한 사람이 일할 때와 크게 다르지 않았다. “핫픽스는 develop에 백머지할 것”을 문서에 적어두면 대체로 지켜진다. 대체로. 테스트가 빨간불이면 머지가 물리적으로 안 되는 것과는 다른 등급의 보장이다. GitFlow는 안전의 상당 부분을 전자에 맡기는 구조다. 트렁크 기반은 후자에 맡긴다.

둘째, 에이전트는 명확한 신호가 필요하다. 에이전트가 스스로 고치려면 “지금 성공인가 실패인가”가 명확해야 한다. main 하나면 답도 하나다. main이 초록불인가. 브랜치가 넷이면 답이 넷의 조합이 된다. 당장 리베이스부터 헷갈린다. 기준은 develop인가 main인가. 방금 올린 커밋의 성패는 어느 브랜치의 CI를 봐야 하나. 핫픽스를 넣었다면 백머지까지 마쳐야 완료인가. 태스크 하나마다 이런 분기 판단이 끼어들고, 관례를 모르는 에이전트는 그때마다 얼마간 어긋난다. 개발-프론트는 통과했는데 운영-백엔드와 합치면 깨지는 상태는 또 어떻게 판단하나. 사람한테 헷갈리는 구조는 에이전트한테는 고장 난 신호등이다. 제목 그대로, 에이전트는 거기서 길을 잃는다.

셋째, 물량이 다르다. 이건 이제 숫자로 나와 있다. Faros AI의 “AI Engineering Report 2026: The Acceleration Whiplash”는 개발자 2만 2천 명, 4천여 팀의 2년치 텔레메트리를 분석했다. 조직마다 AI 사용이 가장 적었던 시기와 가장 많았던 시기를 비교하는 방식이다. AI 사용이 많은 시기일수록 조직 처리량은 실제로 올랐다. 개발자당 완료 에픽이 66.2% 늘었다. 그런데 같은 비교에서 평균 PR 크기는 51.3% 커졌고, PR이 리뷰에 머무는 시간 중앙값은 441.5% 늘었고, 리뷰 없이 머지되는 PR은 31.3% 증가했고, PR당 장애 발생은 3.4배(+242.7%)로 뛰었다. 생산은 폭증했는데 통합·검증 경로가 못 따라가서, 병목 앞에 코드가 쌓이고 일부는 검증을 건너뛰고 새는 그림이다. Faros는 이 패턴을 “Acceleration Whiplash”라고 부른다. 급가속 뒤에 반동으로 목이 꺾이는, 그 whiplash다. DORA 2025도 같은 방향을 확인했다. AI는 처리량을 올리면서 동시에 배포 불안정성도 올린다.

장수 브랜치의 유지 비용(드리프트, 충돌)은 변경량에 비례해서 커진다. 변경량이 몇 배가 되면 그 비용도 몇 배가 된다. 사람 시대에 불편했던 게 에이전트 시대엔 감당이 안 되는 이유고, 트렁크 기반의 “짧은 수명, 잦은 통합”이 유리해지는 이유다. 통합을 미루는 시간 자체가 이제 가장 비싼 자원이기 때문이다.

경영 관점에서 한 줄로 줄이면 이렇다. 에이전트 도입의 효과는 결국 “배포까지 간 변경의 수”로 환산된다. 코드가 아무리 빨리 생산돼도 머지에서 운영까지 가는 길이 막혀 있으면, 병목 앞에 쌓이는 건 성과가 아니라 재고다.

워크트리 시대의 오해: 개수가 아니라 수명이다

“우린 에이전트마다 워크트리를 쓰는데, 브랜치가 오히려 늘었는데?”라는 반문이 나올 수 있다.

맞다. 2026년에 에이전트 여러 대를 병렬로 돌리는 표준 패턴은 에이전트당 git worktree 하나, 브랜치 하나다. 파일 충돌을 막는 격리 장치로 이만한 게 없다. 그러니 활성 브랜치 개수만 세면 트렁크 기반의 “3개 이하” 기준을 우습게 넘긴다.

하지만 개수는 애초에 논점이 아니다. 트렁크 기반이 재는 건 수명과 통합 지연이다. 워크트리 브랜치는 몇 시간짜리다. 태스크 하나를 맡고, 끝나면 main으로 머지되고, 삭제된다. main에서 갈라져 있는 시간이 짧으니 드리프트가 쌓일 시간도 없다. 몇 주씩 살아남으며 develop과 어긋나가는 GitFlow의 feature 브랜치와는 정반대다. 실제로 병렬 에이전트를 돌리는 팀들의 플레이북은 거의 같은 모양으로 수렴하고 있다. 스펙 단위로 쪼갠 독립 태스크, 태스크당 워크트리, 머지를 막는 품질 게이트, 순차 통합, 그리고 단일 main. 트렁크 기반의 단명 브랜치가 여러 개 동시에 돌게 됐을 뿐이다.

단, 짧은 브랜치가 작은 배치를 보장하지는 않는다. 위의 텔레메트리가 보여주듯 에이전트는 내버려두면 PR을 키운다. 배치 크기는 브랜치 전략으로는 못 잡는다. 태스크를 쪼개는 단계, 즉 스펙 분해에서 사람이 잡아야 한다. 도구가 줄여주는 건 브랜치 수명까지다.

물론 공짜는 아니다

트렁크 기반에도 조건이 있다. 그것도 예전보다 하나 늘었다.

네 가지가 먼저 있어야 한다. 믿을 수 있는 CI, 배포와 공개를 분리하는 feature flag, main을 초록불로 유지하는 merge queue, 그리고 빠른 리뷰 경로. 마지막 것이 새로 추가된 항목이자, 2026년 현재 가장 크게 무너지고 있는 항목이다. 앞서 본 리뷰 시간 폭증이 말해주듯, 병목은 머지에서 리뷰로 옮겨갔다. 브랜치를 하루살이로 만들어도 리뷰 큐에서 사흘을 기다리면 통합 지연은 그대로다.

Faros 데이터에는 더 뼈아픈 대목도 있다. DevOps 성숙도가 높았던 조직도 이 하류 악화를 피하지 못했다. 잘하던 관행의 유지만으로는 안 되고, 리뷰 처리량 자체를 새로 설계해야 한다. 에이전트 시대의 트렁크 기반은 리뷰 처리량 설계(리뷰 SLA, 에이전트 사전 리뷰로 사람 리뷰 부담 줄이기, 배치 크기 강제)까지 포함해야 완성된다.

플래키 테스트(가끔 이유 없이 실패하는 테스트)는 에이전트와 만나면 최악이다. 사람은 “저건 원래 가끔 깨져” 하고 넘기지만, 에이전트는 그 신호를 진지하게 믿고 무한 재시도를 하거나, 테스트를 “고쳐”버린다. 실제 사례도 있다. GitHub 공동창업자 스콧 샤콘(Scott Chacon)이 에이전트로 Git을 Rust로 재작성한 Grit 프로젝트 회고에서 직접 밝힌 얘기다. 병렬로 돌리던 에이전트 하나가 테스트 하네스의 근본 부분을 망가뜨렸고, 거대한 회귀처럼 보여서 프로젝트를 중간에 거의 접을 뻔했다고 썼다. 원인은 조율되지 않은 병렬 쓰기였다. 신호 체계가 깨지면 에이전트 병렬화 전체가 같이 무너진다.

DORA의 단서도 정직하게 옮겨두자. 최근 몇 년 연구에서 트렁크 기반 단독의 효과는 엇갈리게 나왔다. 개발 성과에는 도움이 되지만 번아웃을 늘리는 경향이 관찰됐고, 그래서 DORA는 이걸 만능 처방으로 추천하지 않는다. 잦은 통합의 리듬은 사람을 계속 “머지 가능한 상태”로 몰아붙이는 압박이기도 하다. 다만 이 단서는 에이전트 시대에 무게가 달라진다. 통합의 잔손질(리베이스, 충돌 해결, CI 재시도)을 에이전트에게 넘길 수 있게 되면서, 트렁크 기반의 비용 구조에서 사람이 지불하던 부분이 줄고 있다. 번아웃 요인이 사라졌다는 뜻은 아니지만, 비용과 편익의 저울이 트렁크 쪽으로 더 기울고 있는 건 분명하다.

예외도 있다. 앱스토어 심사를 기다려야 하는 모바일, 버전별로 오래 지원해야 하는 라이브러리, 릴리스마다 감사가 붙는 규제 산업은 main에서 필요할 때 잘라내는 짧은 릴리스 브랜치를 쓰는 게 맞다. 드리센이 회고 노트에서 GitFlow의 자리로 남겨둔 영역도 정확히 여기다.

브랜치 전략을 바꿔서 승진한 사람은 없다

그래서 아무도 안 바꾼다. 브랜치 전략 같은 기본기는 대부분 경력 초기에 “팀이 하던 방식”으로 몸에 익히고, 그 뒤로는 재검토할 계기가 없다. 어쨌든 돌아가니까. 게다가 인센티브도 없다. 브랜치 전략을 고쳐봤자 성과 지표에 티가 안 나고, 바꾸다 문제가 생기면 책임은 바꾸자고 한 사람이 진다. 현상 유지가 개인에게는 언제나 합리적인 선택이다. 그런데 돌아간다는 것과 최선이라는 건 다른 얘기다. 기본기는 돌아가기만 하면 의심을 면제받는다. 그래서 프레임워크는 분기마다 갈아치우는 조직이, git 워크플로우는 10년째 그대로인 풍경이 흔하다.

에이전트는 이 면제를 끝낸다. AI가 증폭기라면, 브랜치 전략은 증폭기에 물린 첫 번째 회로다. 트렁크 기반 위의 에이전트는 처리량이 되고, 장수 브랜치 위의 에이전트는 리뷰 큐와 충돌 지옥이 된다. 같은 모델, 같은 프롬프트로도 그렇다. 차이는 그 아래 깔린 통합 구조에서 난다.

확인해보고 싶다면 오늘 5분이면 된다. 레포를 열고 머지되지 않은 브랜치가 몇 개인지, 가장 오래된 게 며칠 묵었는지 세어보라. 그 숫자가 지금 팀이 통합을 미뤄둔 총량이고, 에이전트를 붙이는 순간 몇 배로 불어날 원금이다. 그리고 하나만 더 떠올려보라. 우리 팀이 브랜치 전략을 마지막으로 재검토한 게 언제였는지. 아마 “한 번도”일 것이다.

바꾸기로 했다면 한 번에 갈 필요는 없다. 4개 브랜치면 먼저 2개로, CI와 플래그가 갖춰지면 1개로. 하네스가 성숙한 만큼만 브랜치를 줄이면 된다.

GitFlow냐 트렁크냐는 사실 부차적이다. 중요한 건 너무 기본이라 아무도 안 들여다보는 것들을 주기적으로 다시 들여다보는 습관이다. 기본기에도 유통기한이 있다. 다만 이번 재검토는 미룰수록 이자가 붙는다. 증폭기는 이미 켜져 있다.

참고 자료

댓글

댓글을 불러오는 중…