요약: Claude Code 2.1.183은 자동 모드에서 위험한 git 명령과 인프라 삭제 명령을 더 강하게 막도록 바뀌었습니다. 에이전트 코딩 도구를 실무 저장소에 붙일 때 가장 무서운 사고는 “코드를 못 짜는 것”이 아니라 “작업물을 지우는 것”입니다. 이번 변경을 기준으로 개발팀이 로컬 작업물 보호, 자동화 권한, PR 운영 기준을 어떻게 정리해야 하는지 살펴봅니다.
Anthropic의 Claude Code changelog에 따르면 2026년 6월 19일 공개된 2.1.183 버전은 자동 모드 안전성을 강화했습니다. 사용자가 로컬 작업물 폐기를 명시하지 않았을 때 git reset --hard, git checkout -- ., git clean -fd, git stash drop 같은 파괴적 git 명령을 차단합니다. 또한 에이전트가 이번 세션에서 만든 커밋이 아닌데 git commit --amend를 시도하는 경우도 막습니다. terraform destroy, pulumi destroy, cdk destroy 역시 사용자가 특정 스택 삭제를 요청하지 않으면 차단됩니다.
이 변화는 단순한 UX 개선이 아닙니다. AI 코딩 도구가 팀의 실제 개발 루프에 들어오면 “명령 실행 권한”이 곧 운영 리스크가 됩니다. 모델이 의도를 잘못 해석하거나, 오래된 문맥을 기준으로 정리 명령을 실행하거나, 테스트를 위해 만든 임시 조치를 되돌린다고 판단할 때 로컬 변경분이 날아갈 수 있습니다. 자동 모드에서 이런 명령을 기본 차단하는 것은 팀 단위 도입의 전제 조건에 가깝습니다.
개발자 입장에서는 이 업데이트를 보고 “도구가 알아서 막아주니 괜찮다”가 아니라 “우리 저장소의 안전 정책을 명문화해야겠다”로 받아들이는 편이 맞습니다. 도구의 기본 안전장치는 마지막 방어선이고, 팀의 작업 규칙이 첫 번째 방어선이어야 합니다.
AI 코딩 에이전트는 일반 자동화 스크립트와 다릅니다. 스크립트는 정해진 명령만 실행하지만, 에이전트는 상황을 해석하고 다음 행동을 고릅니다. 이 장점이 사고 원인이 되기도 합니다. 예를 들어 테스트가 깨진 이유를 찾다가 “현재 변경사항이 문제일 수 있으니 깨끗한 상태로 돌려보자”고 판단할 수 있습니다. 사람 개발자라면 git status를 보고 동료 작업인지 확인하지만, 에이전트는 그 문맥을 놓칠 수 있습니다.
또 다른 문제는 작업 단위가 길어질수록 의도와 명령 사이가 멀어진다는 점입니다. 사용자는 “빌드 에러 고쳐줘”라고 말했는데, 에이전트는 의존성 업데이트, 캐시 삭제, 파일 재생성, git 조작까지 이어갈 수 있습니다. 이 과정에서 git clean -fd 같은 명령이 섞이면 추적되지 않은 파일이 사라집니다. 임시 파일이면 괜찮지만, 아직 git add하지 않은 실험 코드나 로컬 설정이면 복구가 어렵습니다.
인프라 명령은 더 위험합니다. terraform destroy나 pulumi destroy는 로컬 파일 삭제가 아니라 실제 클라우드 리소스 삭제로 이어질 수 있습니다. 개발 환경이라고 생각했던 스택이 공유 스테이징일 수도 있고, 이름이 비슷한 워크스페이스를 잘못 잡을 수도 있습니다. 그래서 이번 Claude Code 업데이트가 인프라 삭제 명령을 별도로 다룬 것은 실무적으로 의미가 큽니다.
도구 업데이트와 별개로 팀은 에이전트 권한 정책을 정해야 합니다. 최소 기준은 세 가지입니다. 첫째, 에이전트는 변경 전 상태를 항상 확인해야 합니다. git status, 현재 브랜치, 최근 커밋, 추적되지 않은 파일 목록을 작업 시작 시 확인하게 해야 합니다. 둘째, 파괴적 명령은 사람이 명시적으로 요청한 경우에만 실행해야 합니다. 셋째, 인프라 변경은 로컬 개발 작업과 별도 승인 흐름으로 분리해야 합니다.
좋은 프롬프트는 “테스트하고 고쳐줘”에서 끝나지 않습니다. “로컬 변경분을 삭제하지 말고, 파괴적 git 명령을 쓰지 말고, 필요하면 먼저 이유를 설명해라”까지 포함해야 합니다. 이 문구가 반복된다면 저장소의 에이전트 가이드 문서에 넣는 것이 좋습니다.
브랜치 정책도 중요합니다. 에이전트에게 기본 브랜치에서 바로 작업시키지 말고, 작업별 브랜치를 만들게 해야 합니다. 커밋도 작게 나누는 편이 안전합니다. 큰 변경을 한 번에 커밋하면 리뷰어가 “어디서 위험한 수정이 들어갔는지” 찾기 어렵습니다.
첫 번째 패턴은 작업 시작 스냅샷입니다. 에이전트가 코드를 만지기 전에 현재 상태를 요약하게 합니다. 예시는 다음과 같습니다.
이 요약을 남기면 문제가 생겼을 때 어디서부터 꼬였는지 추적하기 쉽습니다. 또한 에이전트가 스스로 “추적되지 않은 파일이 있으니 삭제 명령은 피해야 한다”고 판단할 확률이 높아집니다.
두 번째 패턴은 삭제 대신 격리입니다. 캐시나 생성물을 정리해야 할 때 바로 삭제하지 말고 trash, 별도 백업 폴더, 임시 rename을 쓰게 합니다. 완전 삭제는 되돌릴 수 없지만, 이동은 복구할 수 있습니다. 로컬 개발에서 회복 가능성은 속도보다 중요합니다.
세 번째 패턴은 인프라 명령의 별도 채널화입니다. 애플리케이션 코드 수정 세션에서 Terraform, Pulumi, CDK destroy 계열 명령을 실행하지 않게 합니다. 인프라 변경이 필요하면 별도 작업으로 분리하고, 대상 스택과 계정을 사람이 확인해야 합니다.
이번 2.1.183의 차단 목록은 팀 규칙의 출발점으로 쓰기 좋습니다. 저장소의 에이전트 가이드에 다음 문장을 넣으면 효과가 큽니다.
“사용자가 명시적으로 로컬 작업물 삭제를 요청하지 않는 한 git reset --hard, git checkout -- ., git clean -fd, git stash drop을 실행하지 않는다. 이번 세션에서 만든 커밋이 아니면 git commit --amend를 실행하지 않는다. terraform destroy, pulumi destroy, cdk destroy는 특정 스택 삭제 요청과 별도 확인 없이는 실행하지 않는다.”
이 문장은 도구에만 의존하지 않고 모든 에이전트, 모든 개발자에게 같은 기준을 제공합니다. Claude Code를 쓰지 않는 팀원이나 다른 코딩 에이전트를 쓰는 환경에서도 동일하게 적용할 수 있습니다.
또한 CI에서도 안전장치를 둘 수 있습니다. 예를 들어 PR에서 인프라 삭제 관련 파일 변경이 감지되면 별도 라벨과 리뷰어를 요구하게 만들 수 있습니다. 자동화 도구가 로컬 명령을 막아도 PR에서 위험한 변경이 들어올 수 있기 때문입니다.
자동 모드는 반복 작업에 강합니다. 린트 수정, 테스트 보강, 타입 오류 수정, 작은 리팩터링은 자동으로 돌릴수록 생산성이 올라갑니다. 하지만 권한 경계가 흐리면 생산성보다 복구 비용이 커집니다. 기준은 간단합니다. “실패해도 git으로 되돌릴 수 있는가?”가 자동 실행의 기준입니다.
되돌릴 수 있는 작업은 자동화해도 됩니다. 파일 수정, 테스트 실행, 패키지 설치, 임시 브랜치 커밋이 여기에 해당합니다. 반대로 되돌리기 어려운 작업은 사람 승인으로 빼야 합니다. 로컬 변경분 삭제, 원격 브랜치 강제 푸시, 데이터베이스 마이그레이션, 클라우드 리소스 삭제가 여기에 해당합니다.
이 경계를 명확히 하면 에이전트도 더 잘 일합니다. 할 수 있는 일과 멈춰야 하는 일을 알기 때문입니다. 막연히 “조심해”라고 말하는 것보다 “이 명령은 금지, 이 상황은 질문”이라고 쓰는 편이 훨씬 안전합니다.
git status, 브랜치, 추적되지 않은 파일을 요약하게 한다.Claude Code 2.1.183의 안전 업데이트는 에이전트 코딩 도구가 장난감에서 실무 도구로 넘어가는 과정에서 필요한 변화입니다. 개발팀은 이 변경을 계기로 에이전트 권한, 파괴적 명령, 인프라 승인 기준을 문서화해야 합니다. 좋은 에이전트 운영은 모델 성능보다 복구 가능한 작업 환경에서 시작됩니다.