테크버킷 로고
Published on

Git Worktree가 필요한 이유: 여러 브랜치를 동시에 작업하기

Authors
  • 테크버킷
    Name
    테크버킷
    Twitter

요약: 브랜치는 변경 이력을 분리하지만 하나의 작업 폴더에서는 보통 한 브랜치만 펼칠 수 있습니다. Git worktree는 같은 저장소에 연결된 작업 폴더를 추가해 여러 브랜치를 동시에 열어둡니다. Orca는 이 실제 Git 기능을 작업 단위로 삼아 여러 AI 코딩 에이전트의 터미널, 브라우저와 diff를 분리합니다.

Git의 브랜치를 이용하면 기능 개발과 버그 수정의 변경 이력을 나눌 수 있습니다. 그런데 실제 개발에서는 브랜치만으로 해결되지 않는 불편이 생깁니다. 저장소, 커밋과 브랜치가 아직 낯설다면 Git 핵심 개념과 용어를 먼저 참고해도 좋습니다.

기능을 만들던 중 운영 장애를 고쳐야 하거나, 코드 리뷰를 위해 다른 브랜치를 잠깐 실행하거나, AI 에이전트 두 개에 서로 다른 작업을 맡기는 상황입니다. 변경 이력은 브랜치로 분리할 수 있지만 실제 파일이 펼쳐진 작업 폴더는 하나이기 때문입니다.

이번 글에서는 이 문제에서 worktree가 왜 필요한지, 언제 유용한지, 그리고 Orca가 worktree를 어떻게 AI 코딩 작업 공간으로 확장하는지 살펴봅니다.

브랜치 전환이 불편해지는 순간

하나의 저장소 폴더에서 보통 다음처럼 작업합니다.

project/  → 현재 feature/payment 브랜치의 파일

이 상태에서 긴급 수정 브랜치로 이동하려면 먼저 진행 중인 변경을 정리해야 합니다.

git status
git stash push -m "payment work in progress"
git switch main
git switch -c hotfix/login

긴급 수정을 마치면 원래 브랜치로 돌아와 stash를 복원합니다.

git switch feature/payment
git stash pop

이 방식은 틀리지 않습니다. 짧은 전환에는 충분합니다. 하지만 다음과 같은 비용이 생깁니다.

  • 커밋하기 애매한 중간 변경을 임시로 stash해야 함
  • 브랜치를 바꿀 때 파일과 빌드 결과가 한꺼번에 교체됨
  • 개발 서버, 편집기 탭과 디버깅 문맥을 다시 맞춰야 함
  • 오래된 stash가 어떤 작업인지 구분하기 어려워짐
  • 두 브랜치의 결과를 나란히 실행하거나 비교하기 어려움

브랜치가 이력의 분리를 해결한다면, worktree는 작업 디렉터리의 분리를 해결합니다.

폴더를 복사하거나 저장소를 다시 clone하면 안 될까

물론 프로젝트 폴더를 복사하거나 같은 저장소를 두 번 clone해도 두 브랜치를 동시에 열 수 있습니다. 하지만 단순 복사는 Git 메타데이터나 무시해야 할 파일까지 함께 복제하기 쉽고, 각 폴더가 어떤 원본에서 왔는지 관리하기 어렵습니다.

여러 번 clone하는 방식은 각각 독립된 저장소라 이해하기는 쉽습니다. 대신 Git 객체와 원격 설정을 각 clone이 따로 관리하고, 브랜치와 로컬 커밋을 다른 clone에서 바로 보지 못할 수 있습니다.

Worktree는 그 중간에 있습니다.

하나의 Git 저장소와 커밋 데이터
├─ project/          → main
├─ project-payment/  → feature/payment
└─ project-hotfix/   → hotfix/login

커밋과 브랜치 같은 저장소 데이터는 공유하면서, 체크아웃된 파일은 디렉터리마다 따로 둡니다. Git 공식 문서는 처음 init 또는 clone으로 만든 공간을 main worktree, 추가한 공간을 linked worktree라고 부릅니다.

Git worktree란 무엇인가

git worktree는 하나의 Git 저장소에 여러 working tree를 연결해 둘 이상의 브랜치를 동시에 체크아웃할 수 있게 하는 공식 Git 기능입니다.

여기서 용어를 구분해두면 좋습니다.

  • working tree: 현재 체크아웃된 실제 파일 영역을 가리키는 일반 개념
  • worktree: Git의 git worktree 명령으로 관리되는 main 또는 linked working tree

Work Tree 용어 설명도 함께 읽으면 저장소와 작업 폴더의 관계를 이해하는 데 도움이 됩니다.

Worktree는 새 저장소를 만드는 기능이 아닙니다. 기존 저장소의 커밋과 브랜치를 공유하는 별도 작업 폴더를 연결합니다.

첫 worktree 만들기

먼저 원래 저장소에서 현재 상태와 등록된 worktree를 확인합니다. 아래 명령을 터미널에 입력합니다.

git status
git worktree list

main을 기준으로 feature/payment이라는 새 브랜치와 작업 폴더를 함께 만들려면 아래 명령을 입력합니다.

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

각 인자의 의미는 다음과 같습니다.

  • ../project-payment: 새 작업 폴더가 생길 위치
  • -b feature/payment: 새로 만들 브랜치 이름
  • main: 새 브랜치가 시작할 기준 커밋 또는 브랜치

원격의 최신 기본 브랜치를 정확한 기준으로 삼고 싶다면 먼저 fetch한 뒤 origin/main에서 시작할 수 있습니다.

git fetch origin
git worktree add ../project-payment -b feature/payment origin/main

이제 기존 project 폴더는 원래 브랜치에 그대로 있고, project-payment 폴더에서는 새 브랜치로 작업할 수 있습니다. 두 터미널과 편집기를 각각 열어도 파일이 서로 바뀌지 않습니다.

기존 브랜치를 별도 폴더에서 열기

이미 존재하며 다른 worktree에서 사용 중이지 않은 브랜치는 다음처럼 엽니다.

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

Git은 같은 로컬 브랜치를 일반적으로 두 worktree에 동시에 체크아웃하지 못하게 막습니다. 두 폴더에서 같은 브랜치를 서로 다르게 수정하면 어느 작업이 브랜치의 현재 상태인지 모호해질 수 있기 때문입니다.

현재 연결 상태는 언제든 아래 명령으로 확인합니다.

git worktree list

작업이 끝난 worktree 정리하기

먼저 worktree 안에서 변경이 커밋됐거나 더 이상 필요 없는지 확인합니다.

git -C ../project-payment status

필요한 변경을 commit하고 push한 뒤, 원래 저장소에서 아래 명령을 입력합니다.

git worktree remove ../project-payment

Worktree 제거와 브랜치 삭제는 별개입니다. 브랜치까지 필요 없다면 병합 여부를 확인한 뒤 따로 삭제합니다.

git branch -d feature/payment

파일 탐색기에서 폴더를 먼저 지웠다면 Git에 관리 정보가 남을 수 있습니다. 더 이상 존재하지 않는 worktree 정보를 정리하려면 아래 명령을 입력합니다.

git worktree prune

가능하면 폴더를 직접 삭제하기보다 git worktree remove를 사용하는 편이 관리 상태를 일치시키기 쉽습니다.

Worktree가 특히 유용한 상황

긴 작업 중 긴급 수정

기능 브랜치의 미완성 변경과 실행 환경을 그대로 둔 채 별도 폴더에서 hotfix를 처리할 수 있습니다. stash와 브랜치 왕복이 줄어듭니다.

코드 리뷰와 버전 비교

현재 개발 브랜치 옆에 PR 브랜치나 이전 릴리스를 열어 두고 각각 실행할 수 있습니다. 화면과 테스트 결과를 번갈아 재구성하지 않아도 됩니다.

여러 개발 서버 동시 실행

서로 다른 포트를 사용하면 두 브랜치의 앱을 동시에 실행해 동작을 비교할 수 있습니다. 다만 의존성 폴더와 빌드 캐시가 worktree마다 필요할 수 있습니다.

여러 AI 코딩 에이전트에 작업 분배

에이전트마다 브랜치와 폴더를 하나씩 주면 한쪽의 중간 변경을 다른 에이전트가 자기 작업으로 오해하거나 같은 파일을 덮어쓰는 문제를 줄일 수 있습니다.

feature/login   → Codex
fix/payment     → Claude Code
docs/api        → Cursor CLI

같은 문제를 여러 에이전트에 맡겨 결과를 비교할 때도 각 결과가 별도 브랜치와 diff로 남습니다.

Worktree가 모든 문제를 해결하지는 않는다

Worktree는 편리하지만 완전한 격리 환경은 아닙니다.

  • 같은 Git 객체와 저장소 설정을 공유합니다.
  • 각 폴더의 의존성, 빌드 결과와 캐시가 디스크 공간을 더 사용할 수 있습니다.
  • 데이터베이스, 포트와 외부 서비스는 자동으로 분리되지 않습니다.
  • .env처럼 Git이 추적하지 않는 파일은 새 worktree에 자동으로 생기지 않을 수 있습니다.
  • 한 worktree에서 만든 커밋과 브랜치는 같은 저장소의 다른 worktree에서도 보입니다.
  • 악성 명령이나 과도한 파일 접근을 막는 보안 샌드박스가 아닙니다.

프로젝트가 작고 브랜치를 가끔만 바꾼다면 기존 switch와 stash가 더 단순할 수 있습니다. 동시에 유지해야 할 작업 문맥이 둘 이상일 때 worktree의 가치가 커집니다.

Worktree와 Orca의 연결

명령줄로 worktree를 만들면 폴더와 브랜치는 분리되지만, 각 작업의 터미널·에이전트·브라우저·개발 서버·diff 상태는 사용자가 직접 관리해야 합니다. 작업이 많아지면 터미널 창과 편집기 창을 다시 구분하는 일이 생깁니다.

Orca는 실제 Git worktree를 작업 공간의 기본 단위로 사용하고 그 주변 도구를 함께 묶는 ADE(Agent Development Environment)입니다.

Git worktree
├─ 브랜치와 파일
├─ Codex·Claude Code 같은 에이전트 터미널
├─ 일반 터미널
├─ 편집기와 diff
├─ 개발 서버와 브라우저
└─ 커밋·push·PR 상태

Orca 공식 문서에 따르면 저장소를 추가하면 기본 브랜치를 기준으로 읽고, 새 작업 공간을 만들 때 실제 Git worktree와 브랜치를 생성합니다. 같은 요청을 세 에이전트에 맡기면 세 worktree, 세 브랜치와 세 diff로 결과를 분리해 비교할 수 있습니다.

따라서 Orca가 Git이나 브랜치를 대체하는 것은 아닙니다. Git worktree 위에 여러 AI 코딩 작업을 만들고, 상태를 확인하고, 결과를 검토하는 인터페이스를 더한 도구에 가깝습니다.

Orca를 사용하기 전에 알아두면 좋은 것

Orca의 버튼으로 worktree를 만들 수 있어도 다음 기본 개념을 알면 문제가 생겼을 때 원인을 찾기 쉽습니다.

  • 저장소는 커밋과 브랜치 이력을 관리합니다.
  • 브랜치는 커밋을 가리키며 작업별 이력을 분리합니다.
  • Worktree는 브랜치의 파일을 별도 디렉터리에 펼칩니다.
  • Commit은 에이전트의 변경을 검토 가능한 단위로 기록합니다.
  • Push는 로컬 커밋을 원격 저장소에 보냅니다.

Orca 자체와 지원 에이전트가 무엇인지 먼저 알고 싶다면 Orca란? ADE 핵심 정리를 읽어보세요. 직접 사용하려면 Orca 설치 방법과 기본 설정, Orca에서 Codex·Claude Code 병렬 실행하기로 이어갈 수 있습니다.

추천 학습 순서

Worktree 명령부터 외우기보다 아래 순서로 작은 저장소에서 연습하는 것이 좋습니다.

  1. status, add, commit, log로 로컬 커밋을 만듭니다.
  2. 새 브랜치를 만들고 switch로 이동합니다.
  3. merge 시 두 브랜치의 이력이 어떻게 합쳐지는지 확인합니다.
  4. 별도 worktree를 만들고 두 브랜치를 동시에 수정해봅니다.
  5. 필요해졌을 때 Orca로 에이전트와 브라우저까지 작업별로 관리합니다.

도구가 대신 만들어준 구조도 결국 Git의 저장소, 브랜치, 커밋과 worktree로 남습니다. 이 네 개의 관계를 알면 GUI와 명령줄 사이를 오가더라도 현재 상태를 잃지 않습니다.

자주 묻는 질문

Worktree마다 저장소를 다시 clone해야 하나요?

아닙니다. git worktree add는 기존 저장소에 연결된 작업 폴더를 추가합니다. 커밋과 브랜치 데이터를 공유하므로 별도의 전체 clone과는 다릅니다.

같은 브랜치를 두 worktree에서 열 수 있나요?

Git은 일반적인 사용에서 같은 로컬 브랜치를 두 worktree에 동시에 체크아웃하지 못하게 합니다. 작업마다 별도의 브랜치를 사용하세요.

Worktree를 지우면 커밋도 사라지나요?

커밋된 이력은 저장소에 남습니다. 다만 커밋하지 않은 파일은 worktree 폴더와 함께 잃을 수 있으므로 제거 전에 git status를 확인해야 합니다.

Orca를 쓰려면 worktree 명령을 외워야 하나요?

필수는 아닙니다. Orca가 생성과 정리를 인터페이스로 제공하지만, git worktree list와 저장소·브랜치·커밋의 관계를 알면 오류 해결과 결과 검토가 쉬워집니다.

Worktree는 AI 에이전트를 안전하게 격리하나요?

파일 작업 공간을 분리할 뿐 운영체제 수준의 보안 격리는 제공하지 않습니다. 에이전트 권한, 비밀 정보, 네트워크와 실행 명령은 별도로 관리해야 합니다.

마무리

Git의 브랜치는 가볍게 이력을 나누지만, 작업이 동시에 늘어나면 폴더와 실행 문맥도 나눌 필요가 생깁니다. Worktree는 같은 저장소를 공유하는 별도 작업 폴더를 만들어 브랜치 전환 비용을 줄입니다.

Orca는 이 구조를 여러 AI 에이전트가 일하는 작업 공간으로 확장합니다. 먼저 작은 저장소에서 git worktree add, list, remove를 경험한 뒤 Orca를 사용하면 자동으로 생성되는 브랜치와 작업 폴더가 훨씬 명확하게 보일 것입니다.

참고 자료