Claude Code에서 변경 사항을 되돌리는 방법: /rewind와 git

Ailoot 사용에 관한 실용적인 정보는 문서에서 확인할 수 있습니다.

Claude Code의 되돌리기란 무엇이며, 왜 세 단계만으로는 충분하지 않을까요?#

Claude Code를 사용한 첫 주에 /rewind를 활성화했습니다. 두 개의 프롬프트만으로 프로젝트의 인증 로직을 망가뜨렸기 때문입니다. 되돌린 뒤 안도의 한숨을 쉬고 작업을 계속했습니다. 한 달 후 다른 상황이 생겼습니다. 스키마 마이그레이션을 작성하고 있었고 Claude가 도와주었습니다. 커밋한 다음 브랜치를 전환하고 나서야 필요한 단계를 하나 빠뜨렸다는 사실을 깨달았습니다. /rewind는 도움이 되지 않았습니다. 세션이 이미 달라져 있었기 때문입니다. 이전 커밋으로 git checkout한 것이 도움이 됐습니다. 또 한 달 뒤에는 실수로 에이전트에게 “모든 것을 마지막 push 시점으로 되돌려”라고 말했고, 에이전트는 git reset --hard를 실행해 세 시간 동안의 작업을 망가뜨렸습니다. git reflog 덕분에 살아났습니다. 파괴된 커밋의 해시가 여전히 남아 있었습니다.

이 세 이야기는 서로 다른 방식으로 작동하고, 서로 다른 오류를 잡아내며, 모두 필요한 세 가지 보호 단계에 관한 것입니다. 이 가이드에서는 각 단계의 명령어와 한계, 예를 설명하고, Claude가 처음부터 프로젝트를 무너뜨리지 않도록 사전에 설정하는 방법도 보여줍니다.

되돌리기의 3단계 — 기능과 사용 시점:

이제 각 단계에서 정확히 무엇을 해야 하는지, 어떤 함정이 있는지, 문제가 생기지 않아 되돌릴 일도 없도록 설정하는 방법을 살펴보겠습니다.

/rewind는 어떻게 실행하나요? 명령어를 입력할까요, Esc를 두 번 누를까요?#

Claude는 응답을 마칠 때마다 해당 세션에서 수정한 모든 파일의 스냅샷을 자동으로 찍습니다. 스냅샷은 ~/.claude/file-history/{sessionId}/에 저장되며 최대 30일 동안 보관됩니다. 스냅샷은 증분 방식으로 저장됩니다. 파일 전체가 아니라 상태 간의 차이만 저장합니다. 기본적으로 세션당 최대 100개의 스냅샷을 보관합니다. 따라서 대부분의 실제 프로젝트에서는 어느 시점에든 그날 작업 중 Claude가 변경한 내용을 모두 확인할 수 있습니다.

입력란이 비어 있을 때 Esc를 두 번 눌러 되돌리기 메뉴를 엽니다.

[user-input is empty]
> _

[press Esc, Esc]

Rewind to which message?
  1. Create a migration for the User table          (3 files changed)
  2. Add the lastLoginAt field                      (1 file changed)
  3. Rewrite the authorization logic                (5 files changed)
  ...

입력란에 텍스트가 있으면 Esc를 처음 두 번 눌렀을 때 텍스트가 지워지고 Up 기록에 저장됩니다. 입력을 시작한 뒤 되돌려야겠다고 생각났을 때 유용합니다. Anthropic 공식 문서의 설명을 인용하면 다음과 같습니다.

/rewind 명령도 같은 역할을 합니다. 메뉴를 엽니다. 같은 메뉴로 이동하는 /checkpoint 별칭도 있습니다. 어떤 방법이 더 편한지는 습관에 따라 다릅니다. 저는 Esc Esc를 사용합니다. 더 빠르고 키보드에서 손을 떼지 않아도 되기 때문입니다.

Rewind 메뉴의 6가지 모드: 언제 어떤 모드를 선택해야 할까요?#

목록에서 지점을 선택하면 작업 메뉴로 이동합니다. 항목은 여섯 개이며, 각각 하는 일이 다릅니다.

모드 전체 표:

Summarize up to here 기능은 2026년 5월 11~15일, 20주 차에 출시된 Claude Code v2.1.139-v2.1.142에서 추가되었습니다.

Restore와 Summarize의 차이는 근본적입니다. Restore는 이전 상태로 돌아가 선택한 지점 뒤에 일어난 모든 일을 되돌립니다. Summarize는 아무것도 되돌리지 않고 압축만 합니다. 원래 메시지는 참고할 수 있도록 세션 기록에 남지만, 활성 컨텍스트에는 요약만 남습니다. “아무 일도 없었던 것처럼” 만들고 싶다면 restore를 사용하세요. “내용은 남기되 컨텍스트 공간은 차지하지 않게” 하고 싶다면 summarize를 사용하세요.

Restore conversation 또는 Summarize from here를 실행하면 선택한 프롬프트의 원문이 입력란에 다시 표시됩니다. 수정해서 다시 보낼 수 있습니다. Summarize up to here를 실행하면 입력란은 비어 있고 대화의 끝에 그대로 있게 됩니다.

/rewind로 되돌릴 수 없는 변경 사항은 무엇인가요?#

사람들이 주로 부딪히는 한계입니다. /rewind에 녹색 체크 표시가 뜨며 “되돌리기 성공”이라고 나오지만, Claude가 파일 외의 것도 건드려 프로젝트는 여전히 망가져 있을 수 있습니다. 세 가지 경우를 살펴보겠습니다.

1. Bash 명령은 추적되지 않습니다. Claude가 한 턴에서 rm file.txt나 mv old.txt new.txt를 실행하면, 해당 변경 사항은 체크포인트에 포함되지 않습니다. Anthropic 문서에는 다음과 같이 명시되어 있습니다.

따라서 Claude가 Bash 도구를 사용해 파일을 직접 삭제하거나 이동하거나 복사하면 /rewind로 모든 것을 복원할 수 없습니다. git checkout이나 백업 복원이 도움이 될 수 있지만, 키를 두 번 누르는 것만으로 해결되지는 않습니다.

2. 외부 편집은 포착되지 않습니다. VS Code에서 파일을 직접 열어 수정하거나, 두 번째 Claude 세션이 같은 파일을 병렬로 수정해도 첫 번째 세션은 그 변경 사항을 확인할 수 없습니다. 체크포인트 스냅샷은 Claude가 현재 세션의 턴을 마칠 때 생성됩니다. 턴 사이에 발생하는 일은 담당 범위 밖입니다.

3. 파일 외부 작업은 전혀 다루지 않습니다. npx prisma migrate dev로 적용한 Prisma 마이그레이션은 데이터베이스 스키마를 변경합니다. 데이터베이스는 프로젝트 파일 시스템 외부에 있으므로 /rewind로 취소할 수 없습니다. origin/main으로 force-push한 경우도 마찬가지입니다. 커밋이 원격 서버로 전송되었으므로 체크포인트로 되돌릴 수 없습니다. 비용을 청구하거나 레코드를 삭제한 원격 API 호출은 해당 API 자체의 메커니즘으로만 취소할 수 있습니다.

규칙: 데이터베이스 마이그레이션, git push, 원격 API처럼 프로젝트 파일 외부에 영향을 주는 작업이라면 외부 효과마다 별도의 롤백 전략을 준비하세요. /rewind는 현재 세션 안의 로컬 파일 기록만 다룹니다.

/rewind와 git은 어떻게 다르며, 둘 다 필요한 이유는 무엇인가요?#

Anthropic 문서에서는 이 조합을 다음과 같이 직접 설명합니다.

차이점을 표로 정리하면 다음과 같습니다.

두 기능을 함께 쓰는 방법은 간단합니다. “이제 잘 작동하고, 잃고 싶지 않다”는 상태에 도달할 때마다 git commit을 만드세요. 커밋 사이에는 /rewind를 사용하세요. 즉시 되돌릴 수 있고, 커밋 메시지도 필요 없으며, 중간 상태로 git 기록을 어지럽히지 않습니다. 작업이 끝나면 의미 있고 원자적인 커밋을 만드는 것이 좋습니다.

/rewind 하나로 전체 작업을 처리할 수 없는 이유는 무엇인가요?#

되돌리기는 컨텍스트 엔지니어링의 한 사례입니다. 세션 컨텍스트를 관리하면(언제 커밋할지, 언제 /rewind를 누를지, CLAUDE.md에 어떤 규칙을 넣을지) 프로젝트를 파괴하거나 작업을 잃지 않는 예측 가능한 Claude를 만들 수 있습니다.

Claude에게 “되돌려”라고 요청할 때 git reset --hard가 위험한 이유는 무엇일까요?#

“현재 상태를 저장하고 마지막 push 시점으로 되돌려 달라”는 요청은 다음 명령으로 이어질 수 있습니다.

git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix"  # saved uncommitted changes
git reset --hard 35eb731                                                # destroyed commits d63695e..882e618

첫 번째 명령은 올바르게 미커밋 변경 사항을 stash에 저장했습니다. 두 번째 명령은 파괴적이었습니다. 브랜치를 35eb731 커밋으로 되돌렸고, 그 커밋과 882e618 사이의 모든 커밋은 고아 상태가 되었습니다. 기본적으로 고아 커밋은 git gc가 실행될 때까지 .git/objects/에 남아 있습니다. git gc는 보통 2주 안에 자동으로 실행됩니다. 하지만 그때 무엇을 해야 할지 몰랐다면 이미 시간이 불리하게 흐르기 시작한 것입니다.

논리는 간단합니다. 자연어에서 “되돌리기”, “돌아가기”, “복원하기”, “원상 복구하기”, “취소하기”는 “기록을 살펴보거나” “안전한 지점으로 돌아간다”는 뜻입니다. “기록을 파괴한다”는 뜻이 아닙니다. git reset --hard는 브랜치를 다시 작성하고 HEAD에서 도달할 수 있는 커밋을 제거해 기록을 파괴합니다. 안전한 대안은 git checkout <commit>입니다. 분리된 HEAD를 만들어 브랜치를 건드리지 않고 이전 상태를 살펴볼 수 있습니다.

실용적인 핵심은 여러 파일을 리팩터링하는 등 중요한 작업을 시작하기 전에 현재 상태를 git commit으로 저장하는 것입니다. 커밋 하나만 있으면 Claude가 실수해도 작업을 잃지 않고 git checkout . 명령 하나로 되돌릴 수 있습니다.

파괴적인 reset 이후 git reflog는 어떻게 작업을 살려낼까요?#

파괴적인 reset 후에는 즉시 git reflog를 실행하세요.

git reflog

출력은 다음과 비슷합니다.

35eb731 HEAD@{0}: reset: moving to 35eb731
882e618 HEAD@{1}: commit: middleware refactoring complete
d63695e HEAD@{2}: commit: leaveRemove method finalized
1f9c8a3 HEAD@{3}: commit: tracker enter/leave disabled
35eb731 HEAD@{4}: pull origin main

HEAD@{1}부터 HEAD@{3}까지가 바로 그 “파괴된” 커밋입니다. git의 로컬 객체 저장소에서 사라진 것이 아니라 브랜치를 통해 접근할 수 없게 된 것뿐입니다. 복구하려면 다음을 실행하세요.

# Create a branch from the last “destroyed” commit
git branch recovered-work 882e618

# Or switch directly
git reset --hard 882e618

그러면 브랜치에 재난이 발생하기 전까지의 기록이 다시 모두 포함됩니다.

reflog의 한계:

1. 로컬에만 있습니다. reflog는 .git/logs/HEAD에 저장되며 원격 저장소에는 없습니다. force-push한 뒤 로컬 저장소 복사본을 삭제하면 reflog도 폴더와 함께 사라집니다.
2. 기본 보관 기간은 90일입니다. 오래된 항목은 git gc가 제거할 수 있습니다. git config gc.reflogExpire 200.days.ago로 설정을 변경할 수 있습니다.
3. HEAD에 없었던 내용은 다루지 않습니다. 커밋이 stash에만 있었고 stash가 파괴됐다면 reflog에는 stash의 최신 상태만 표시되고 내부 기록은 표시되지 않습니다.

팀 규칙: 재난 직후에는 git gc --aggressive를 절대 실행하지 마세요. 먼저 reflog로 조사하고 복구한 다음 나머지 작업을 하세요. 필요한 내용이 모두 push되었는지 확인하기 전에는 로컬 저장소 클론도 삭제하지 마세요.

CLAUDE.md를 통해 파괴적인 git 명령으로부터 프로젝트를 보호하는 방법은 무엇인가요?#

취약점은 기본적으로 Claude에 보호 맥락이 없다는 점입니다. 기술적으로 유효한 방법이기 때문에 “되돌려”를 git reset --hard로 해석합니다. 프로젝트의 시스템 프롬프트 파일인 CLAUDE.md에 보호 규칙을 넣으세요.

최소 규칙 (CLAUDE.md에 추가):

## Git 안전 프로토콜

- 비파괴적인 git 명령(예: push --force, reset --hard, checkout ., restore ., clean -f, branch -D)은 사용자가 해당 작업을 명시적으로 요청하지 않는 한 절대 실행하지 마세요. 허가되지 않은 파괴적 작업은 도움이 되지 않으며 작업 손실을 초래할 수 있습니다.
- 제가 "roll back", "go back", "restore", "revert", "undo"라고 말하면 이를 검토 명령으로 해석하세요. `git log`, `git diff`, `git checkout <commit>`(분리된 HEAD를 생성), `git stash`(변경 사항을 보존)를 사용하세요.
- 다음 조건에 해당하는 명령을 실행하기 전에는 항상 확인을 요청하세요.
  - 브랜치에서 HEAD를 다른 커밋으로 이동하는 경우
  - 커밋 기록을 수정하는 경우
  - 커밋하지 않은 작업을 잃을 수 있는 경우
  - --hard, --force, --aggressive 플래그가 포함되는 경우
- 파괴적인 명령을 실행하기 전에 번호를 매긴 비교를 출력하세요.
  - 안전: 임시로 확인하려면 `git checkout <commit>`을 사용하세요.
  - 파괴적: `git reset --hard`를 사용하면 영구적으로 파괴됩니다.
- 사용자의 명시적 선택을 기다린 다음 실행하세요.

팀을 위한 확장 규칙(저장소 루트의 CLAUDE.md에 추가):

## Git 작업 흐름 규칙

- 동작하는 단계마다 커밋하세요. WIP 커밋 전 `git status`와 `git diff`를 확인하고 검토한 파일만 `git add -- path/to/file`로 지정해 스테이징한 뒤 staged diff를 확인하세요. 타이머는 검토 알림이지 전체 트리를 추가할 권한이 아닙니다.
- Claude는 커밋할 때 `git add .` 또는 `git add -A`를 사용하면 안 됩니다. `git status` + `git diff`를 확인한 뒤 파일 이름을 지정하세요.
- main에 `git push --force`를 하기 전에는 멈추고 사용자에게 물어보세요. 기능 브랜치에서는 이전 버전을 잃어도 괜찮은지 확실할 때만 신중하게 force-push하세요.
- 병합 충돌을 해결할 때 즉시 "ours" 또는 "theirs"를 선택하지 말고, 먼저 두 버전을 모두 보여주세요. 그런 다음 제가 결정하겠습니다.
- `.gitignore`에는 `.env*`, `.claude/personal/`, `node_modules/`, `dist/`가 포함되어야 합니다. 빠져 있다면 추가하세요.

이 블록을 추가하면 “마지막 push 시점으로 되돌려”라는 말에 다음과 같이 응답하게 됩니다.

현재 커밋하지 않은 파일이 3개 있고 마지막 push 이후 커밋이 4개 있습니다. 두 가지 방법이 있습니다.

1. 안전: git checkout <last-push-hash>를 통해 view-last-push 브랜치를 만들겠습니다. 작업은 모두 보존하고, push 당시 상태를 잠시 보여드리겠습니다.
2. 파괴적: git reset --hard <last-push-hash>를 실행하면 커밋 4개와 커밋하지 않은 변경 사항을 영구적으로 파괴합니다. 90일 이내에 git reflog를 통해서만 복구할 수 있습니다. 어느 쪽을 선택하시겠습니까?

작업을 잃고 네 시간을 허비하는 대신 대화 30초면 충분합니다.

Claude Code에서 되돌리는 5가지 방법은 무엇이며, 올바른 방법을 어떻게 고를까요?#

“Claude가 망가뜨렸으니 급히 복원해야 한다”는 상황에서는 이 사다리의 낮은 단계부터 차례로 올라가세요. 항상 1단계부터 시작하세요.

1단계. /rewind — 세션 안에서 즉시 되돌리기.

Esc Esc를 누르거나 /rewind를 입력하세요. 문제가 생기기 전 지점을 선택하세요. 모드를 선택하세요(대개 Restore code and conversation). 잠시 후 과거 상태로 돌아와 다시 시작할 수 있습니다. “Claude가 잘못된 일을 했다”는 사례의 80%를 다룹니다.

2단계. git checkout . — 모든 미커밋 변경 사항 되돌리기.

git diff                    # first see what actually changed
git checkout .              # undo all uncommitted changes in all files
# or selectively:
git checkout -- path/to/file.ts   # only one file

/rewind가 작동하지 않았을 때(예를 들어 Claude가 Bash를 통해 파일을 수정했을 때)나 세션 기록 외부의 변경 사항을 되돌려야 할 때 유용합니다. 커밋하지 않은 모든 변경 사항은 영구적으로 사라집니다. 후회할 수도 있다면 먼저 git stash를 실행하세요(2.5단계 참고).

2.5단계. git stash — 변경 사항을 잠시 보관하기.

git stash save "might still need this"
# return to a clean state (without changes)
# ...
# if you change your mind—restore from stash:
git stash pop

“영원히 잃기”와 “현재 상태 그대로 두기” 사이의 좋은 절충안입니다. 명시적으로 지우기 전까지 stash는 로컬에 남습니다.

3단계. git checkout <commit> — 기록을 잃지 않고 이전 커밋으로 돌아가기.

git log --oneline               # find the hash of the right commit, e.g. abc1234
git checkout abc1234            # detached HEAD—view without changing anything
# like the state? create a branch from it:
git checkout -b recovery abc1234
# return:
git checkout main

안전한 “임시 복귀” 방법입니다. 분리된 HEAD는 브랜치를 변경하지 않으므로 현재 main(또는 원래 작업하던 브랜치)의 작업은 그대로 유지됩니다. 이 상태에서 작업하려면 브랜치를 만드세요.

4단계. git reset --hard <commit> — 브랜치를 이전 지점으로 이동하기.

⚠️ 파괴적입니다. 지정한 해시보다 앞선 커밋은 고아 상태가 됩니다.

git reflog                                  # note the hash of the current state
git reset --hard abc1234                    # rewrite the branch
# found a mistake? return through reflog:
git reset --hard HEAD@{1}                   # to where you were before the reset

뒤의 커밋이 필요 없다고 확신할 때만 사용하세요. 마음이 바뀌었을 때 돌아갈 위치를 알 수 있도록 reset 전에 항상 git reflog를 확인하세요.

5단계. git reflog + 복구 — 재난 상황.

누군가(Claude, 사용자 또는 동료)가 이미 git reset --hard나 force-push를 실행해 작업을 날렸습니다. 어떻게 해야 할까요?

git reflog                                          # look for the last hash before the disaster
git branch recovered HEAD@{N}                       # create a branch from it
git checkout recovered                              # switch to it
git diff main                                       # compare with the current state
git checkout main && git merge recovered            # restore into main, if you're sure

reflog가 이미 지워졌다면(기본적으로 90일이 지나면 지워짐) 마지막 수단은 git fsck --lost-found입니다. .git/objects/에서 연결이 끊긴 커밋을 보여줍니다. 고고학에 가까운 일이지만 때로는 성공합니다.

단계 선택 규칙:

되돌릴 일이 없도록 프로젝트를 보호하는 방법은 무엇인가요?#

규칙 1. 30분마다 커밋하세요.

“작업이 끝날 때까지” 기다리지 마세요. 작동하는 중간 단계가 생길 때마다 커밋하세요. 커밋 메시지는 무엇이든 괜찮습니다. 중요한 것은 Claude(또는 사용자)가 git checkout 명령 하나로 작동하는 상태로 돌아갈 수 있다는 점입니다.

# at the beginning of a task
git status                        # inspect all staged and unstaged paths
git diff                          # review the changes
# Replace this example path with the actual file you reviewed.
git add -- path/to/file.ts
git diff --cached                 # verify exactly what will be committed
git commit -m "wip: starting User schema migration"

# after 30 minutes (or after the first working iteration)
git status
git diff
git add -- path/to/file.ts         # actual reviewed path, not a directory wildcard
git diff --cached
git commit -m "wip: User schema is ready, migration applied locally"

# at the end of the task—a meaningful commit
git reset --soft HEAD~2           # combine the three wip commits into one
git commit -m "feat(auth): add lastLoginAt field to User table"

PostToolUse 알림을 추가해도 같은 검토와 명시적 경로 스테이징 규칙을 유지하세요. 타이머를 무검토 자동 커밋으로 만들면 무관한 수정이나 이미 스테이징된 파일이 커밋에 들어갈 수 있습니다.

규칙 2. 최소한의 .gitignore.

다음 항목은 프로젝트 루트에 필요합니다.

# secrets
.env
.env.local
.env.*.local

# local Claude Code settings (not pushed to the team repository)
.claude/personal/
.claude/sessions/
.claude/file-history/

# dependencies and build
node_modules/
dist/
.next/
build/

저는 .claude/personal/ 폴더를 개인 실험과 메모에 사용합니다. 이 내용은 공유 저장소에 포함되면 안 됩니다. .claude/sessions/와 .claude/file-history/ 폴더는 Claude Code의 로컬 저장소입니다. 저장소에 둘 필요가 없고, 공간을 많이 차지하며, 특정 컴퓨터에 종속됩니다.

규칙 3. 실험은 별도 브랜치에서 하세요.

작업 규모가 크다면(파일 10개 이상 리팩터링, 새 데이터베이스로 마이그레이션, 모듈 재작성) main 브랜치에서 하지 마세요.

git checkout -b experiment/auth-rewrite
# work, commit every 30 minutes
# if it works:
git checkout main
git merge experiment/auth-rewrite
# if it doesn't:
git checkout main
git branch -D experiment/auth-rewrite     # delete the branch
# that's it, the main branch is intact

이 간단한 습관으로 “Claude가 프로젝트를 망쳤다”는 상황을 “Claude가 브랜치 하나를 망쳐서 삭제했고, 다시 시작하면 된다”로 바꿀 수 있습니다.

규칙 4. 위험한 작업 전에는 git tag를 사용하세요.

데이터베이스 마이그레이션, 대규모 리팩터링 또는 의존성 업데이트 전에 태그를 만드세요.

git tag pre-prisma-migration-v2
# work
# something went wrong:
git reset --hard pre-prisma-migration-v2
# or just take a look:
git checkout pre-prisma-migration-v2

태그는 커밋을 가리키는 이름 있는 포인터입니다. reflog를 정리하더라도 잃지 않습니다.

다음 단계: 되돌리기는 컨텍스트 엔지니어링과 어떤 관계가 있나요?#

이 세 가지 되돌리기 단계는 문제가 생겼을 때 상태를 복원하는 방법을 아는 하나의 기술을 뒷받침하는 기반입니다. 그 기술만으로는 범위가 좁습니다. 하지만 다른 컨텍스트 엔지니어링 도구와 결합하면 더 큰 역할을 합니다.

Plan Mode에서는 즉시 코드를 작성할 수 없습니다. 먼저 계획을 세우고, 확인한 다음, 실행합니다. 이는 예방적 되돌리기입니다. 계획을 미리 검토하므로 나중에 되돌려야 할 내용을 작성하지 않게 됩니다. Claude Code의 Plan Mode 가이드에서 더 알아보세요.

CLAUDE.md는 위에서 다룬 Git 안전 프로토콜을 비롯해 Claude가 기본적으로 따르는 규칙을 설정합니다. 파괴적인 명령을 막는 예방책입니다.

Second Brain은 세션 사이에 Claude가 프로젝트를 기억하도록 합니다. 어떤 코드가 있는지, 비즈니스 로직은 무엇인지, 이전에 어떤 합의를 했는지 알게 됩니다. 기억이 많을수록 잘못된 일을 할 가능성이 낮아집니다.

Skills와 하위 에이전트는 코드로 표현한 여러분의 방법론입니다. 올바른 git 작업 흐름이 Skill에 포함되어 있으면 어떤 하위 에이전트도 확인 없이 git reset --hard를 실행하지 않습니다.

이 모든 것이 함께 Context Engineering입니다. 프롬프트를 입력하는 동안이 아니라 그 전에 컨텍스트를 관리하세요. 컨텍스트 엔지니어링이란 무엇인가에서 더 알아보세요.

되돌리기는 최후의 방어선입니다. Plan Mode + CLAUDE.md + Second Brain + Skills가 앞선 네 가지 방어선입니다. 이들을 설정하면 되돌리기는 드물고 빠르게 끝납니다. 설정하지 않으면 매일 반복하는 일이 됩니다.

되돌리기는 계획이 끝나는 지점에서 시작됩니다.

Ailoot 열기.