Claude Code 자율 운영 복구 설계

git 안전 브랜치·watchdog·루프 감지로 AI 실패 비용 제로

by AI개발자

Mar 19. 2026 brunch_membership's

AI는 반드시 실패한다 - 중요한 건 그 다음이다

Safety Guards, Code Quality, Monitoring을 모두 설정했다. 이제 "그래도 실패했을 때"의 경우를 대비해야 한다.이 전제를 받아들이는 것이 이번 장의 출발점이다.

"AI가 실패하지 않도록 막는 것"이 목표가 아니다. "AI가 실패해도 손실이 없도록 설계하는 것"이 목표다.

이 관점의 전환이 자율 운영의 내구성을 결정한다.

Recovery의 3가지 체크는 전부 이 원칙 위에 세워져 있다.

체크 12: 파괴적 작업 전에 반드시 안전 브랜치를 만든다

어떤 일이 벌어졌나

Claude Code가 "성능 개선을 위해 전체 리팩터링하겠습니다"라고 말하며 30개 이상의 파일을 수정했다. 작업 후 실행해 보니 서비스가 기동되지 않았다.

git log를 확인했다. 마지막 커밋은 작업 시작 3시간 전이었다. Claude Code는 커밋 없이 모든 변경을 진행했고, 원래 코드로 돌아갈 방법이 없었다.

2시간의 수작업 복구 끝에 일부는 살렸지만, 나머지는 처음부터 다시 작성했다.

왜 이런 일이 생기나

Claude Code는 기본적으로 "일단 변경하고, 완료되면 커밋한다" 는 흐름으로 움직인다. 중간 단계의 스냅샷을 자동으로 남기지 않는다. 변경 범위가 크고 실패하면, 되돌아갈 지점이 없다.

해결책 1: branch-guard.sh의 안전 브랜치 기능 활용

이 hook은 1장(체크 1)에서 이미 설정했다. branch-guard.sh는 위험 명령 차단 외에 안전 브랜치 자동 생성 기능도 포함한다. 추가 설치 없이 이 기능을 활성화할 수 있다.

hook이 파괴적 변경을 감지하면 작업 전에 자동으로 타임스탬프 기반 백업 브랜치를 생성한다.

# hook이 자동 생성하는 브랜치 이름 예시

backup/before-changes-20260228-143022

backup/before-changes-20260301-091455

해결책 2: CLAUDE.md에 안전 브랜치 규칙을 명시

hook만으로 커버되지 않는 상황(예: 대규모 파일 이동, DB 마이그레이션 등)을 위해 CLAUDE.md에도 명시적인 규칙을 추가한다.

## 안전 브랜치 규칙

아래 작업을 시작하기 전에는 **반드시** 안전 브랜치를 먼저 생성할 것:

- `rm` 또는 `mv`로 다수의 파일을 삭제·이동하는 경우

- 5개 이상의 파일을 동시에 수정하는 대규모 리팩터링

- 데이터베이스 스키마 변경 또는 마이그레이션 실행

- 패키지·의존성의 메이저 버전 업그레이드

- 환경 변수·설정 파일의 구조적 변경

### 안전 브랜치 생성 명령

```bash

git checkout -b backup/before-changes-$(date +%Y%m%d-%H%M%S)

```

안전 브랜치를 생성한 뒤, 원래 브랜치로 돌아와서 작업을 시작한다:

```bash

# 예시: main 브랜치에서 작업하는 경우

git checkout -b backup/before-changes-$(date +%Y%m%d-%H%M%S)

git checkout main

# 이제 작업 시작

```

작업이 성공적으로 완료되면, 백업 브랜치는 일주일 후 삭제해도 좋다.

� 한국 개발 현장 팁: 모노레포(monorepo) 구조를 사용하는 경우, 특정 패키지 디렉터리만 백업하고 싶을 때도 있다. 그럴 때는 브랜치 대신 git stash나 git stash push -m "backup-before-refactor" packages/특정패키지/ 형태로 부분 백업하는 방법도 유효하다. 단, stash는 브랜치보다 접근성이 낮으므로 팀 환경에서는 브랜치를 권장한다.