GitButler CLI: 스테시와 체크아웃의 굴레를 끊는 5가지 핵심 워크플로우

개발자의 시간은 비쌉니다. 하지만 우리는 그 귀한 시간의 상당 부분을 코드 작성이 아닌 컨텍스트 스위칭에 허비하곤 합니다. 피처 개발 도중 날아든 긴급 핫픽스 요청 하나에 git stash를 실행하고, 브랜치를 옮기고, 다시 돌아와 stash pop을 하며 충돌을 해결하는 과정은 시니어 엔지니어의 집중력을 조각냅니다.

표준 Git은 선형적인 히스토리 관리를 위해 설계되었습니다. 한 번에 하나의 작업만 한다는 가정을 전제로 하죠. 하지만 실제 현장은 복합적입니다. 여러 개의 코드 리뷰 피드백을 반영하면서 동시에 신규 기능을 개발해야 합니다. 2026년, 이제는 Git의 한계를 인정하고 도구를 진화시킬 때입니다. GitButler CLI인 but은 단순한 편의 도구를 넘어 버전 관리의 패러다임을 바꿉니다.

---

작업의 병렬화: 가상 브랜치의 혁신

GitButler의 가장 강력한 무기는 하나의 작업 디렉토리에서 여러 브랜치를 동시에 활성화하는 능력입니다. 기존 Git에서는 불가능했던 일입니다.

표준 Git은 특정 시점에 단 하나의 HEAD 포인터만 유지합니다. 반면 GitButler는 gitbutler/workspace라는 특수 브랜치를 통해 현재 활성화된 모든 가상 브랜치(Lane)를 실시간으로 병합한 상태를 유지합니다.

비교 항목	표준 Git (Vanilla)	GitButler (Virtual Branches)
작업 영역 상태	한 번에 하나의 브랜치만 존재	여러 가상 브랜치의 변경 사항이 공존
컨텍스트 전환	Stash + Checkout (수 초~수 분)	즉시 (논리적 할당 변경)
충돌 관리	리베이스 중단 필수	충돌을 '상태'로 보존하며 작업 지속 가능

이 구조 덕분에 IDE나 컴파일러는 별도 설정 없이도 여러 작업을 하나의 일관된 소스 트리로 인식합니다. 흐름을 끊지 않고도 멀티태스킹이 가능하다는 뜻입니다.

---

실무 생산성을 높이는 3가지 테크닉

단순히 편리함을 넘어 업무 속도를 물리적으로 단축하는 구체적인 방법론을 살펴봅시다.

1. 멈추지 않는 컨텍스트 스위칭

복잡한 로직을 짜다가 오타를 발견했다면 어떻게 하시겠습니까. 예전에는 하던 일을 멈춰야 했습니다. 이제는 그 자리에서 수정하고 but branch new fix-typo를 입력하면 끝입니다. 작업 영역은 그대로 유지한 채, 특정 수정분(Hunk)만 새 브랜치에 논리적으로 할당할 수 있습니다.

2. 'but rub'을 통한 커밋 정제

커밋 히스토리는 동료에게 전달하는 서사입니다. 지저분한 중간 과정은 생략되어야 합니다. GitButler는 rebase -i의 복잡함을 제거하기 위해 but rub 명령어를 도입했습니다. 수정 사항을 특정 커밋에 문질러 흡수시키는 방식입니다. 실행 즉시 해당 커밋이 수정(Amend)되고, 그 상위 커밋들은 자동으로 리스테킹(Restacking)됩니다. 리베이스 도중 발생하는 충돌 때문에 작업을 중단할 필요가 없는 First Class Conflict 시스템이 이를 뒷받침합니다.

3. 마킹(Marking) 시스템과 AI 협업

2026년 업데이트의 핵심은 마킹입니다. 특정 커밋을 활성 마크로 지정하면 이후의 모든 변경 사항이 해당 지점에 자동으로 누적됩니다.

특히 Claude Code나 Cursor 같은 AI 에이전트를 사용할 때 위력을 발휘합니다. 에이전트가 생성하는 수많은 잔가지 코드들을 하나의 깔끔한 의미 단위로 자동 병합하여, 히스토리가 항상 최종 형태를 유지하게 만듭니다. commit --fixup 이후 나중에 autosquash를 챙겨야 하는 번거로움이 완전히 사라집니다.

---

안전한 도입을 위한 장치: Oplog와 확장성

새로운 도구 도입 시 가장 큰 두려움은 데이터 손실입니다. GitButler는 Git의 reflog보다 정교한 Oplog를 제공합니다. 모든 데이터 변경 직전의 전체 스냅샷을 기록하기에, 실수로 커밋을 삭제하거나 리베이스를 망쳤더라도 but undo 한 번이면 충돌 해결 상태까지 완벽하게 복원합니다.

또한 파워 유저를 위해 모든 명령어에서 JSON 플래그(but status -j)를 지원합니다. 이를 jq와 조합하면 CI 결과에 따라 특정 가상 브랜치만 골라 푸시하는 자동화 스크립트를 단 몇 줄로 구현할 수 있습니다.

도입 전 체크리스트

• 타겟 설정: but config target origin/main으로 기준 브랜치를 명시하십시오.
• 점진적 전환: 처음부터 모든 브랜치를 병렬로 쓰기보다, 하나의 가상 브랜치부터 익숙해지는 것을 권장합니다.
• Hooks 확인: 기존 프로젝트의 Lint나 Test 훅이 but setup 과정에서 올바르게 연결되는지 체크하십시오.

---

가상 브랜치가 가져다주는 심리적 안정감

우리가 매일 사용하는 stash와 checkout의 불편함은 사실 당연한 것이 아니었습니다. 도구의 한계에 사고를 맞추지 마십시오.

가상 브랜치를 통한 병렬 작업과 직관적인 히스토리 정제는 개발자에게 심리적 안정감을 제공합니다. 실수해도 되돌릴 수 있고, 흐름을 끊지 않고도 협업할 수 있다는 확신이 생산성의 차이를 만듭니다. 지금 터미널에서 but status를 입력해 보십시오. 당신의 작업 디렉토리가 얼마나 더 논리적이고 자유로워질 수 있는지 확인하는 순간, 과거의 비효율로는 다시 돌아가지 못할 것입니다.