[AI] AI 여러 개를 쓸 때의 깃 워크플로우

muchan
muchan
∙∙조회 17
[AI] AI 여러 개를 쓸 때의 깃 워크플로우

기존에 클로드를 결제해서 쓰고 있었는데, 오늘 코덱스도 같이 결제했습니다. 두 모델을 같이 쓰면서 각자의 장점으로 병렬 작업을 해보고 싶었기 때문입니다. 마침 오늘 학원 친구가 깃 워크플로우를 알려줬는데, 병렬로 작업시키기 좋은 방법 같아서 일단 개념만 정리해봤습니다. 혹시 코덱스랑 클로드를 같이 쓰시는 분이 있다면 어떻게 쓰시는지 댓글로 팁을 남겨주시면 정말 감사하겠습니다. 이번 주말에 직접 세팅해보고 괜찮은 방법이 나오면 다시 글로 정리해보겠습니다.

깃 워크플로우란

브랜치를 어떻게 나누고 언제 합칠지에 대한 팀 규칙이다. Git의 기능이 아니라 관례에 가깝다.

핵심 트레이드오프는 하나다. 브랜치가 오래 살수록 격리는 잘 되지만 머지 비용이 커진다.

  • Git Flow — main / develop / feature / release / hotfix. 브랜치가 길게 산다. 버전 배포형 소프트웨어에 적합.
  • GitHub Flow — main + 짧은 feature 브랜치. PR로 머지. 가장 무난한 기본값.
  • Trunk Based — 모두 main에 하루 안에 머지. 미완성은 Feature Flag로 숨김. 테스트 자동화가 전제.

AI 에이전트는 뭐가 다른가

사람 팀원과 세 가지가 다르다.

  1. 동시성이 높다 — 세션 5개를 동시에 돌릴 수 있다. 브랜치가 5개 동시에 자란다.
  2. 컨텍스트가 격리돼 있다 — A는 B가 뭘 했는지 모른다. "옆자리에 물어보기"가 없다.
  3. 작업 단위가 짧다 — 한 세션은 몇 시간이지 몇 주가 아니다.

머지 충돌 위험은 커지고 브랜치 수명은 짧아진다. 위 트레이드오프에서 자연히 GitHub Flow / Trunk Based 쪽으로 밀린다. Git Flow는 안 맞는다. develop에 며칠 쌓아두면 충돌 해결 시간이 작업 시간을 넘어선다.

물리적 격리: git worktree

여러 에이전트에게 같은 폴더를 주면 서로의 파일을 덮어쓴다.

bash
git worktree add C:/GitHub/proj-feature-a feature/a
git worktree add C:/GitHub/proj-feature-b feature/b

.git은 공유하고 작업 디렉토리만 분리된다. 에이전트마다 독립된 폴더 = 독립된 브랜치. 이게 병렬 작업의 기본 단위다.

단, Unity처럼 Library 폴더가 무거운 프로젝트는 worktree마다 재임포트가 걸린다. 이 경우엔 순차 실행이 나을 수도 있다.

실제로 지켜야 하는 것

작업 분할이 곧 브랜치 전략

사람은 "이건 저 사람 파일이니 안 건드려야지" 하지만 에이전트는 안 한다. 지시할 때부터 파일 단위로 겹치지 않게 쪼개야 한다.

  • 좋음: A는 데이터 스키마 확장, B는 UI 패널
  • 나쁨: A는 "타워 개선", B는 "밸런스 조정" — 둘 다 같은 파일을 건드린다

규칙은 레포에 글로 박아둔다

CLAUDE.md 같은 파일이 사람 팀의 코딩 컨벤션 문서 역할을 한다. 에이전트끼리는 대화를 못 하므로, 공유돼야 할 규칙은 전부 파일로 존재해야 한다.

머지 순서는 사람이 정한다

에이전트는 자기 브랜치만 안다. "A 머지 후 B 리베이스" 같은 조율은 사람 몫이다.

커밋을 잘게 쪼갠다

롤백 단위가 된다. AI 작업은 실패율이 높으므로 되돌리기 쉬운 상태를 유지하는 게 중요하다.

정리

사람 팀AI 병렬
격리 수단브랜치worktree + 브랜치
컨텍스트 공유대화, 회의레포 내 문서 파일
브랜치 수명며칠~몇 주몇 시간
병목구현 속도리뷰·통합 속도

마지막 줄이 핵심이다. AI를 여러 개 쓰면 구현은 빨라지지만 통합과 검증이 병목이 된다. 워크플로우 설계는 결국 그 병목을 어떻게 처리할지의 문제다.