스테일 워크트리 정리로 브레인스토밍 재시도 차단 해결

브레인스토밍 자동화 스크립트에서 재시도할 때마다 워크트리/브랜치 생성이 실패하는 문제를 발견했다. 원인은 이전 시도에서 남겨진 스테일한 상태를 정리하지 않았기 때문이었다.

배경: 브레인스토밍 스크립트와 격리된 환경

brainstorm_exec.py는 시각적 또는 소개 목적의 다중 시도(multiple attempts) 작업을 자동으로 실행하는 스크립트다. 각 시도마다 안전하게 격리된 환경을 보장하기 위해 git worktree를 만들고, 그 위에 임시 브랜치를 생성해서 작업한다. 이렇게 하면:

• 메인 저장소의 상태를 건드리지 않음
• 시도 간의 부작용이 없음
• 실패한 시도의 결과를 보존하거나 버릴 수 있음

이 패턴은 병렬 테스트, 다중 전략 탐색, 또는 원자적 작업 재시도가 필요할 때 매우 유용하다.

문제: Stale 워크트리가 재시도를 막음

하지만 한 가지 놓친 부분이 있었다. 스크립트가 중도에 실패하거나 사용자가 수동으로 중단할 때, 이미 만들어진 워크트리와 브랜치가 디스크에 남아있었다. 두 번째 시도를 할 때:

1. 스크립트가 "이 이름의 워크트리 만들어"라고 명령
2. Git은 "어? 이미 같은 이름 있는데?" 실패
3. 브랜치도 마찬가지로 이미 존재한다고 거절
4. 결과: 재시도가 완전히 차단됨

특히 자동화 시스템에서 이런 상황은 예상 이상으로 자주 발생한다. 네트워크 지연, 리소스 부족, 또는 타이밍 문제로 깔끔하게 마무리되지 않는 경우가 생기기 때문이다.

해결: 사전 정리 단계 추가

fix는 간단하지만 효과적했다. 새로운 시도를 시작하기 전에 이전 워크트리와 브랜치를 먼저 정리하는 단계를 추가했다.

이렇게 하면 "이전 상태가 뭐든 상관없이 새 시도는 항상 깨끗한 상태에서 시작"이라는 보장을 얻을 수 있다.

팀장 관점의 배운 점

이 문제는 작은 스크립트 수정이지만, 몇 가지 중요한 패턴을 다시 생각하게 했다:

• 방어적 초기화의 중요성: 부분 실패 시나리오를 고려하지 않으면, 자동화 워크플로우는 첫 번째 에러 후 영구적으로 막힐 수 있다. 이상적으로는 모든 스크립트가 "전 상태를 모르고 시작"하거나 "기존 상태를 자동으로 정리"해야 한다.

• 복구 가능성이 설계의 일부: retry 로직을 짤 때, 단순히 "실패하면 다시"만 해서는 부족하다. 이전 시도의 부작용을 어떻게 처리할지도 함께 고려해야 한다.

• 로컬 개발자 경험: 팀 내 누군가 이 스크립트를 직접 실행할 때마다 "워크트리 이미 있음" 에러로 막혀서 수동으로 정리해야 했다면, 답답했을 거다. 이렇게 작은 수정이 개발자 DX를 크게 개선하는 경우도 많다.

일반화

비슷한 작업을 할 때 참고할 체크리스트:

# 시작 전
- 이전 실행 결과 확인 (임시 파일, 브랜치, worktree 등)
- 정리 필요한 상태 식별
- 정리 순서 정의 (의존성 역순)
- 정리 실패 시 대응 (강제 옵션, 로깅)

# 작업 수행
- 정리 후 예상한 상태인지 검증
- 이후 작업 진행

# 종료 후
- 성공: 필요시 결과 보존, 임시 상태 정리
- 실패: 디버깅을 위해 상태 보존할지, 아니면 다음 재시도 가능하도록 정리할지 결정

이 커밋은 이런 식의 "깔끔한 상태 관리"가 자동화 워크플로우의 안정성을 얼마나 크게 좌우하는지 보여준다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 노이즈캔슬링헤드폰 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.