안녕하세요, 구독자님,
Git 설치는 잘 해보셨나요? 오늘은 제가 가장 좋아하는 Git 기능을 소개하려고 합니다.
여러 AI에게 동시에 일 시키기
"여러 AI 에게 같은 기능을 맡겨보면, 결과물이 전부 조금씩 달라요."
정말 공감되는 말이죠? 저는 예전부터 UI 작업할 때 이걸 의도적으로 자주 활용 해왔습니다. Lovable에게는 미니멀한 디자인을 맡겨보고, Cursor한테는 화려한 애니메이션을 시켜보고 이런 식으로요.
그런데 문제가 있었습니다.
처음엔 폴더를 여러 개 복사해서 각각 작업했어요. project_minimal, project_dynamic, project_vivid... 이러다 보니 어느 순간 뭐가 최신 버전인지, 어떤 게 제일 마음에 드는 버전인지 헷갈리더라고요. 무엇보다 귀찮았습니다.
그때 시도해본게 바로 브랜치(Branch)입니다.
브랜치: 코드의 멀티버스
마블 영화의 멀티버스 아시죠? 브랜치가 딱 그겁니다.
하나의 프로젝트에서 여러 개의 평행우주를 만들어, 각 우주에서 다른 실험을 하는 거예요. 그리고 마지막에 가장 마음에 드는 우주를 메인 타임라인으로 선택합니다.
제가 실제로 했던 프로젝트 이야기를 들려드릴게요.
실전 스토리: 3개 AI의 대결
영어 녹음기반 학습 앱을 만들 일이 있었습니다. 모바일 개발은 처음이라 디자인 작업이 낯설고 어떤 라이브러리를 써야할지, 그러면 어떤식으로 보일지 좀 막막했습니다. 그래서 재미있는 실험을 생각했어요.
작전을 이렇게 짰습니다:
- main 브랜치에 기본 구조만 만들기
- 각 AI별로 브랜치 생성
- 동시에 3개 버전 진행
- 완성본 비교 후 최종 선택
쿠퍼티노 브랜치 (w/ Claude Sonnet 4.0)
"쿠퍼티노 스타일의 UI를 만들어줘"라고 주문했더니, 애플 느낌의 미니멀한 디자인을 만들어줬습니다. 로딩 속도도 빠르고 코드도 깔끔했죠.
애니메이션 브랜치 (w/ GPT 4o)
"사용자 경험을 최우선으로 인터랙티브하게"라고 했더니, 애니메이션과 트랜지션이 가득한 화려한 버전이 나왔습니다. 다만 코드가 좀 복잡했습니다.
머터리얼 브랜치 (w/ Gemini 2.5 Pro)
"Material Design 3 가이드라인을 따라서"라고 요청했더니, 구글스러운 느낌의 안정적인 디자인이 나왔습니다. 가장 쾌적한 느낌이었어요.
승자를 가리는 순간
3개 버전이 완성된 후, 시뮬레이터에서 각 브랜치의 디자인을 비교해봤습니다.
GitHub에서 AI별 변경된 파일 수, 코드 라인 수, 코드 구조 등도 비교하고, 'git checkout'을 이용해서 브랜치를 넘나들며 동료들에게 "어떤 게 제일 마음에 드세요?"라며 직접 시연도 시켜봤습니다.
결과적으로 Material UI의 버전을 베이스로 하되, GPT의 애니메이션 일부를 가져와서 합치기로 했습니다.

이렇게 해서 "안정적이면서도 생동감 있는" 최종 버전이 탄생했습니다!
브랜치의 진짜 매력
- 비교가 쉽다: 폴더를 여러 개 만들 필요 없이, 브랜치만 전환하면 순식간에 다른 버전을 볼 수 있습니다.
- 합치기가 쉽다: A 브랜치의 장점과 B 브랜치의 장점을 골라서 합칠 수 있습니다. 마치 레고 조립하듯이요.
- 히스토리가 남는다: 어떤 AI가 어떤 접근을 했는지, 왜 최종적으로 이 버전을 선택했는지 모든 기록이 남습니다.
이제는 정말 편해진 브랜치 작업 feat. Codex
지난 제 코덱스 뉴스레터 기억 나시나요?
Codex를 이용하면 따로 사람이 브랜치를 생성해서 AI를 분산할 필요가 없습니다. Codex는 기본적으로 작업마다 브랜치를 알아서 생성하거든요.
이제는 Codex 하나만 켜두고, 하나의 작업을 다양한 컨셉으로 시켜볼 수 있습니다. 지난 뉴스레터를 못보신 분들을 위해 플로우 간단히 소개드리자면 다음과 같습니다:
- Codex를 git repository에 연결한다.
- 작업 요청
- "메인화면에 미니멀한 ui를 적용해줘"라는 1번작업을 요청한다. (신규 브랜치 생성)
- "메인화면에 다이나믹한 ui를 적용해줘"라는 2번작업을 요청한다. (신규 브랜치 생성)
- 작업#3, 작업#4,.. 계속 요청 가능
- 작업 완료
- 작업#1 브랜치에 대한 Git PR#1(병합 요청 → 뉴스레터 4편에서 설명)이 생성됨
- 작업#2 브랜치에 대한 Git PR#2(병합 요청 → 뉴스레터 4편에서 설명)이 생성됨
- 사용자는 Git PR들을 살펴보고 마음에 드는 것을 원본에 병합한다.
어때요? 참 쉽죠?
(*비슷한 플로우를 GitHub Copilot으로도 구현할 수 있습니다. → 뉴스레터 5편에서 소개 예정)
git 명령어를 사람이 한줄도 입력할 필요가 없이 Codex가 서로 격리된 병렬 작업 환경을 완벽하게 구성합니다. Codex 사용법이 궁금하다면 지난 뉴스레터나 제 유튜브 영상강의를, Git PR의 원리가 궁금하다면 화요일날 발행될 뉴스레터 4편을 기대해주세요 👀
혼자서도 팀플레이
“이제는 사실상 ‘매니저 너드(manager nerds)’의 시대가 될 것이라고 생각합니다. AI 에이전트 집단을 관리하고 이를 오케스트레이션할 수 있는 능력이 사람들을 엄청나게 강력하게 만들 것이라고 봅니다.”
Anthropic의 공동창업자 Jack Clark
브랜치를 활용한 이 방식의 가장 큰 장점은, 혼자 일해도 마치 여러 명의 팀원들과 협업하는 것 같은 체계적인 프로세스를 가질 수 있다는 겁니다.
바이브코딩 시대에 우리는 모두 관리 역량을 키워야 합니다. Claude는 신중한 시니어 개발자, GPT는 창의적인 디자이너, Gemini는 체계적인 아키텍트. 이렇게 각자에게 페르소나를 부여해서 일을 시키고, 우리는 프로젝트 매니저가 되어 최종 결정을 내려야 하는 거죠. Git은 이런 '바이브 관리자'로서 갖춰야할 필수 스킬이라고 할 수 있겠습니다.
다음 편 예고: 원격 저장소와 협업의 세계로! 지금까지는 내 컴퓨터에서만 놀았다면, 다음편에서는 클라우드에서 진짜 협업이 시작됩니다. AI와의 작업을 넘어, 실제 사람들과 함께 일하는 방법을 알려드릴게요. 🌍
다음주 화요일에 뵙겠습니다!
(*아래 내용은 부록입니다)
실습: 브랜치로 에이전트별 작업 분리하기
브랜치(branch)란 메인 작업 줄기에서 갈라져 나온 독립적인 개발 흐름입니다. 기본 브랜치(일반적으로 main)는 배포 혹은 최종 코드를 담고 있고, 새로운 기능이나 실험은 브랜치를 만들어 진행합니다. 각 브랜치는 서로 격리돼 있으므로 한 브랜치에서 한 에이전트가 만든 코드가 다른 브랜치나 main에 당장 영향을 주지 않습니다.
새 브랜치 생성: Git에서 브랜치를 만드는 것은 가상의 복사본을 만드는 것과 비슷합니다. 예를 들어 UI 기능을 세 AI 에이전트에게 각기 맡긴다면 다음과 같이 브랜치를 만듭니다:
# 에이전트 A용 브랜치 생성 및 체크아웃
git checkout -b feature/ui-agent-a- git checkout -b 브랜치이름 명령은 새 브랜치를 만들고 즉시 그 브랜치로 이동(checkout)하는 기능입니다. 위에서는 feature/ui-agent-a라는 브랜치를 main으로부터 생성했습니다. 이제 이 상태에서 하는 커밋들은 모두 feature/ui-agent-a 브랜치에 쌓이게 됩니다.
- 동일하게 다른 에이전트들도 각자 브랜치를 만들어줍니다:
git checkout -b feature/ui-agent-b # 에이전트 B 브랜치 생성/이동
git checkout -b feature/ui-agent-c # 에이전트 C 브랜치 생성/이동- (브랜치를 새로 만들면 자동으로 그 브랜치로 전환됩니다. 작업을 옮길 땐 git checkout <브랜치명>으로 이미 존재하는 브랜치로 이동 가능합니다.)
브랜치별 작업: 이제 각 브랜치에서 AI 에이전트가 제안한 코드를 적용하고 커밋합니다.
이 상태에서는 main은 아직 깨끗하고(에이전트들의 실험 코드가 들어가지 않음), 각 브랜치에 에이전트별 코드가 격리되어 있습니다. 이제 우리는 서로 다른 접근으로 만들어진 세 가지 UI 구현을 비교하고, 최종 하나를 main에 병합(merge)할 준비를 할 수 있습니다.
브랜치 비교 및 병합하기
변경점 비교: GitHub 웹 UI에서는 브랜치 간의 변경 내용을 시각적으로 비교해볼 수 있습니다. 뉴스레터 2편에서는 아직 GitHub와 같은 원격 저장소를 다루지 않으므로, 로컬을 기준으로 비교를 해보기 가장 편한 툴은 Visual Studio Code가 있습니다. 또는 각각의 브랜치를 git checkout 해가며 코드확인과 실제 배포 테스트를 해볼 수 있습니다.
최종안 선택과 병합: 세 에이전트의 결과를 충분히 검토했다면, 그중 가장 마음에 드는 구현을 main 브랜치에 합치면 됩니다. 병합은 GitHub 웹에서 Pull Request 머지 버튼을 눌러 진행할 수도 있고, 로컬에서 Git 명령으로 할 수도 있습니다. 로컬에서 직접 병합하려면:
# main 브랜치로 체크아웃
git checkout main
# main에 에이전트 A의 브랜치를 병합
git merge feature/ui-agent-a이러면 main 브랜치에 feature/ui-agent-a의 커밋 내용이 합쳐집니다. 병합 커밋이 자동 생성되며 (Merged feature/ui-agent-a into main 등의 메시지), git log로 보면 분기됐던 이력이 하나로 합쳐진 것을 확인할 수 있습니다.
선택받지 못한 다른 브랜치(feature/ui-agent-b, ...c)는 당장 병합하지 않아도 그 자체로 기록이 남아 있으므로 나중에 참고하거나 실험을 이어갈 수 있습니다. 필요없게 되면 브랜치를 git branch -d 브랜치명으로 삭제할 수도 있습니다
스쿼시 병합(Squash merge) 개념: 병합 방법 중에 “스쿼시”라는 옵션이 있습니다. 위 예시에서 에이전트 A 브랜치에서 여러 번 자잘하게 커밋을 했다면, 그대로 병합하면 히스토리에 그 커밋들이 모두 남습니다. 하지만 스쿼시 병합을 사용하면 브랜치의 모든 변경 내역을 하나의 새 커밋으로 압축(squash)하여 main에 합칩니다. 이렇게 하면 main 브랜치의 기록이 깔끔해지는 장점이 있습니다. (예: “UI 에이전트 A 결과물 병합” 한 줄 커밋 하나로 합쳐짐) 다만 스쿼시하면 브랜치의 개별 커밋 로그는 사라지므로, 해당 브랜치의 자세한 작업 내역을 보존할 필요가 있을 땐 일반 병합을 쓰고, 작은 실험 커밋이 지저분하게 많은 경우 히스토리를 단순화하기 위해 스쿼시 병합을 고려합니다.
체크리스트 ✅
- 기능/에이전트별로 새로운 브랜치를 git checkout -b 브랜치명으로 만들어 작업했다.
- 메인(main) 브랜치에 선택한 브랜치의 변경사항을 git merge로 병합했다.
- 스쿼시 병합을 사용하면 히스토리가 단순해진다는 개념을 이해했다.
의견을 남겨주세요