들어가며

예전의 AI는 우리에게 코드 한 줄을, 함수 하나를 "자동완성" 해주는 정도였죠. GitHub Copilot이 다음 줄을 제안하고, ChatGPT에게 함수 하나를 물어보는 정도. 하지만 지금은 AI를 활용함에 있어 완전히 달라졌어요.

이제 AI 에이전트가 목표를 받아서 스스로 계획하고, 코드를 작성하고, 테스트하고, PR까지 올리죠. 그리고 이런 에이전트를 5개, 10개씩 동시에 돌립니다.

이것이 에이전틱 엔지니어링(Agentic Engineering)이고, 이걸 가능하게 만드는 핵심 중 하나가 Git Worktree입니다.

 

에이전틱 엔지니어링이란?

에이전틱 엔지니어링은 개발자가 직접 코드를 작성하는 대신, AI 에이전트에게 목표와 제약 조건을 부여하고 결과를 감독하는 방식의 소프트웨어 개발 방식이에요.

"에이전트는 목표를 받아 계획을 세우고, 도구나 API를 호출하며, 결과를 검토한 뒤 스스로 적응하는 의사결정 레이어다."

 

핵심 루프는 단순해요.

인식(Perceive) → 추론(Reason) → 실행(Act) → 학습(Learn)

 

바이브 코딩과의 차이

"바이브 코딩(Vibe Coding)"이라는 말이 유행이죠.

AI에게 대충 말하면 대충 코드가 나오는 방식. 에이전틱 엔지니어링은 이와 근본적으로 다릅니다.

 

바이브 코딩

- "이런 거 만들어줘"

- AI가 자동완성처럼 코드 생성

- 결과물의 품질이 들쑥날쑥

- 개발자가 결과물을 직접 수정

 

에이전틱 엔지니어링

- 목표, 제약 조건, 품질 기준을 명확히 정의

- AI 에이전트가 계획 → 구현 → 테스트 → 검증까지 자율 수행

- 개발자는 아키텍처 설계와 결과 감독에 집중

- 여러 에이전트가 역할을 분담하여 협업

 

개발자의 역할 변화

개발자는 이제 코드를 "작성하는 사람"이 아니라 "설계하고 감독하는 사람"이 되고 있습니다.

- AI 에이전트가 1차 구현, 스캐폴딩, 테스트, 문서화를 담당

- 엔지니어가 정확성, 리스크, 아키텍처 정합성을 검토

- 시스템 설계, 트레이드오프 결정, 최종 검증은 여전히 개발자의 몫

 

근데 왜 Git Worktree가 필요한가요?

에이전틱 엔지니어링의 핵심은 병렬 실행입니다. 에이전트 하나가 로그인 기능을 만드는 동안, 다른 에이전트는 결제 모듈을 작성하고, 또 다른 에이전트는 버그를 수정할 수 있게 실행하죠.

그런데 전통적인 Git 구조에서는 이게 불가능합니다.

 

전통적인 Git의 한계

하나의 Git 저장소 = 하나의 작업 디렉토리 = 하나의 브랜치.

 

에이전트 A가 feature/login 브랜치에서 작업하는 동안, 에이전트 B가 feature/payment 브랜치로 전환하려면?

git checkout을 해야 합니다. 그 순간 에이전트 A의 작업 환경이 없어지죠.

해결책으로 저장소를 5번 `git clone` 할 수도 있지만 대형 레포지토리라면 디스크 용량이 5배, 시간도 5배 듭니다.

 

Git Worktree: 해답

Git Worktree는 하나의 저장소에서 여러 개의 작업 디렉토리를 동시에 만드는 Git 내장 기능이에요.

 

# 메인 저장소

~/project/


# 워크트리 생성

git worktree add ../project-login feature/login

git worktree add ../project-payment feature/payment

git worktree add ../project-bugfix fix/critical-bug

 

이렇게 하면 3개의 독립된 작업 폴더가 생깁니다.

~/project/            ← main 브랜치

~/project-login/      ← feature/login 브랜치

~/project-payment/    ← feature/payment 브랜치

~/project-bugfix/     ← fix/critical-bug 브랜치

 

핵심 특징:

- 모든 워크트리가 같은 Git 히스토리를 공유. 5개 워크트리를 만들어도 .git 객체는 하나.

- 디스크 사용량이 git clone 5번보다 훨씬 적다.

- 한 워크트리에서 커밋하면 다른 워크트리에서도 즉시 접근 가능.

- 각 워크트리는 완전히 독립된 작업 환경. 서로 간섭 없음.

 

에이전틱 엔지니어링 + Git Worktree = 병렬 AI 개발

이 두 가지를 합치면 이런 워크플로우가 됩니다.

 

실제 작업 흐름

개발자: "이 3가지 작업을 처리해줘"
  1. 사용자 인증 기능 추가
  2. 상품 검색 API 최적화
  3. 결제 페이지 버그 수정

시스템:
  ├── Worktree A (feature/auth)     → 에이전트 1: 인증 기능 구현
  ├── Worktree B (feature/search)   → 에이전트 2: 검색 API 최적화
  └── Worktree C (fix/payment)      → 에이전트 3: 결제 버그 수정

  (3개가 동시에 병렬 실행)

  완료 후 → 각각 PR 생성 → 개발자가 리뷰 & 머지

 

순차적으로 했으면 3시간 걸릴 작업이, 병렬로 돌리면 1시간 안에 끝날 수도 있습니다.

 

현재 이를 지원하는 도구들

Claude Code (Anthropic)

- --worktree 옵션으로 에이전트를 격리된 워크트리에서 실행

- 여러 에이전트를 병렬로 띄워 동시 작업 가능

 

Codex App (OpenAI)

- 내장 워크트리 지원

- 클라우드 환경에서 여러 에이전트가 병렬로 작업

- 각 작업이 독립된 샌드박스에서 실행

 

Conductor

- Claude Code, Codex를 같은 인터페이스에서 실행

- 모든 작업이 자동으로 개별 브랜치와 워크트리를 받음

 

왜 이게 중요한가: 비결정적 AI의 특성

LLM은 비결정적(non-deterministic)입니다. 같은 프롬프트를 두 번 던져도 다른 코드가 나오죠.

이걸 단점이 아니라 장점으로 활용하는 방법이 있습니다.

같은 작업 → 에이전트 3개에게 동시 할당 (각각 별도 워크트리)
         → 3가지 다른 구현이 나옴
         → 가장 좋은 것을 선택하거나 장점만 합침

 

이런 방법은 예전의 개발에서는 실제로는 할 수 없는 접근 방법이죠. 사람 3명에게 같은 기능을 동시에 만들라고 할 수는 없으니까..

하지만 AI 에이전트라면 비용과 시간이 크게 줄어듭니다.

 

실전: Git Worktree 기본 사용법

에이전틱 도구를 쓰지 않더라도, Git Worktree는 그 자체로 강력한 기능이에요.

 

워크트리 생성

# 기존 브랜치로 워크트리 생성
git worktree add ../my-feature feature/my-feature

# 새 브랜치를 만들면서 워크트리 생성
git worktree add -b feature/new-feature ../new-feature

 

워크트리 목록 확인

git worktree list

# /Users/me/project          abc1234 [main]
# /Users/me/project-feature  def5678 [feature/my-feature]

 

워크트리 삭제

# 작업 완료 후 정리
git worktree remove ../my-feature

 

워크트리 정리 (죽은 참조 제거)

git worktree prune

 

기억할 점: 워크트리는 같은 브랜치를 두 곳에서 동시에 체크아웃할 수 없어요. 이는 충돌을 방지하기 위한 의도적인 설계입니다.

 

에이전틱 엔지니어링 도입 시 고려할 점

잘 맞는 경우

- 독립적인 기능 여러 개를 동시에 개발할 때

- 대규모 리팩토링에서 모듈별로 작업을 분배할 때

- 같은 문제에 대해 여러 접근법을 시도하고 싶을 때

- CI/CD 파이프라인에서 자동화된 코드 생성이 필요할 때

 

주의할 점

- 아키텍처 결정은 여전히 인간이. AI 에이전트에게 전체 시스템 설계를 맡기면 안 된다.

- 리뷰 없는 머지는 위험하다. 병렬로 빠르게 만들어도, 리뷰는 꼼꼼히.

- 워크트리 간 의존성 충돌. 에이전트 A가 공통 모듈을 수정하면 에이전트 B의 작업과 충돌할 수 있습니다. 독립적인 작업 단위로 나누는 게 핵심.

- 에이전트 결과물의 품질 편차. 검증(verification) 단계를 반드시 포함해야 한다.

 

마치며

에이전틱 엔지니어링과 Git Worktree의 조합은 단순한 도구 업그레이드가 아니에요. 이것은 소프트웨어를 만드는 방식의 전환이에요.

이제는 개발자에게 가장 중요한 역량은 더 이상 "코드를 얼마나 빨리 치느냐"가 아니에요. "AI 에이전트에게 얼마나 명확한 목표를 줄 수 있느냐", 그리고 "결과물을 얼마나 정확하게 판단할 수 있느냐"입니다.

Git Worktree라는, 사실 2018년부터 있었던 조용한 기능이 최근에 와서 갑자기 주목받는 이유가 여기에 있습니다.

기술은 때로는 시대를 만나야 비로소 빛이 나는가 봅니다.

 

긴 글 읽어주셔서 감사합니다.

 

 

참고 자료

- [What is Agentic Engineering? — IBM](https://www.ibm.com/think/topics/agentic-engineering)

- [What is agentic engineering? — Glide Blog](https://www.glideapps.com/blog/what-is-agentic-engineering)

- [How agentic AI will reshape engineering workflows in 2026 — CIO](https://www.cio.com/article/4134741/how-agentic-ai-will-reshape-engineering-workflows-in-2026.html)

- [How Git Worktrees Changed My AI Agent Workflow — Nx Blog](https://nx.dev/blog/git-worktrees-ai-agents)

- [Git Worktrees for AI Coding — DEV Community](https://dev.to/mashrulhaque/git-worktrees-for-ai-coding-run-multiple-agents-in-parallel-3pgb)