AI 코딩 에이전트에게 셸 권한, 어디까지 맡겨도 될까? rm 없이도 작업이 날아가는 이유

들어가며

Claude Code, Codex, Cursor 같은 AI 코딩 에이전트가 이제 많은 개발자의 일상 도구가 됐습니다. 코드를 쓰는 데서 끝나지 않고 테스트를 돌리고, 마이그레이션을 실행하고, git 작업까지 셸 명령으로 직접 처리하죠. 그런데 이렇게 편해질수록 고민도 커집니다. 에이전트에게 셸 권한을 어디까지 줘야 할까?

GeekNews에 올라온 질문 글이 이 고민을 잘 짚고 있어서 핵심을 정리하고, 실무에서 참고할 만한 대응 전략을 덧붙여 봤습니다.

핵심 요약

공개된 사고 보고서를 보면 AI 에이전트 때문에 홈 폴더, 저장소, 데이터베이스가 통째로 날아간 사례가 적지 않습니다.
그런데 실행된 명령 자체는 위험해 보이지 않은 경우가 많았습니다.
- rm은 스크립트나 테스트 파일 안에 있었고, 에이전트는 그 스크립트를 실행했을 뿐입니다.
- prisma migrate reset, git stash drop처럼 rm이 한 글자도 없는데 작업을 날리는 명령도 있었습니다.
글쓴이는 이런 명령을 실행 전에 판정하는 Claude Code 플러그인을 만들고 있고, 다른 개발자들이 실제로 어떻게 쓰는지 묻고 있습니다.

왜 "rm만 막으면 된다"로는 부족할까?

많은 사람이 위험한 명령이라고 하면 rm -rf부터 떠올립니다. 그래서 차단 목록에 rm을 넣어 두면 안심하기 쉽죠. 하지만 실제 사고는 그 틈으로 들어옵니다.

1. 간접 실행 문제

에이전트가 npm test나 ./scripts/cleanup.sh를 실행하는 건 겉보기에 아무 문제가 없습니다. 그런데 그 스크립트 안에 rm -rf $DIR/* 같은 코드가 있고 $DIR이 비어 있다면 결과는 아주 다릅니다. 명령어 문자열만 검사하는 방식으로는 스크립트 안에서 일어나는 일을 볼 수 없습니다.

2. 이름만 봐서는 위험한지 모르는 명령

아래 명령들은 rm 없이도 데이터를 되돌리기 어렵게 지울 수 있습니다.

| 명령 | 위험 요소 | |---|---| | prisma migrate reset | DB를 드롭하고 다시 만들어 데이터 전체 삭제 | | git stash drop / git stash clear | 커밋 안 한 작업 내용 유실 | | git reset --hard, git clean -fdx | 작업 트리 변경 사항과 미추적 파일 삭제 | | git push --force | 원격 히스토리 덮어쓰기 | | docker volume prune, docker compose down -v | 볼륨에 저장된 데이터 삭제 | | DROP TABLE, TRUNCATE (CLI로 실행된 SQL) | 테이블 데이터 삭제 | | terraform destroy, kubectl delete | 인프라 리소스 삭제 |

공통점은 도메인 지식이 있어야 위험한지 알 수 있다는 점입니다. 단순한 키워드 매칭으로는 잡기 어렵습니다.

글쓴이가 던진 세 가지 질문

원문은 커뮤니티에 아래 세 가지를 묻습니다. 스스로 답해 보면 자기 환경을 점검하는 데 꽤 도움이 됩니다.

권한은 어떻게 두시나요?
- 매번 확인 / 일부 명령만 자동 허용 / 컨테이너 안에서 전부 허용 중 어느 쪽인지, 그리고 그렇게 정한 이유
에이전트가 묻지 않고 실행하면 가장 곤란한 명령은 무엇인가요?
스크립트 안에서 일어나는 삭제는 어떻게 대비하시나요?
- 백업, 컨테이너, 커밋 습관 등

에디터가 정리한 실전 대응 전략

원문은 질문 글이지만, 일반적으로 많이 쓰는 방어 방법을 단계별로 정리해 보면 다음과 같습니다.

✅ 권한 모델 고르기

매번 확인: 가장 안전하지만, 확인 요청이 너무 잦으면 내용을 읽지 않고 '승인'을 누르게 됩니다. 결국 형식적인 절차가 되기 쉽습니다.
허용 목록(allowlist) 방식: ls, cat, git status, git diff, 테스트 실행처럼 읽기 전용이거나 영향이 작은 명령만 자동 허용하고 나머지는 확인을 받습니다. 편의성과 안전 사이에서 무난한 선택입니다.
샌드박스·컨테이너 안에서 전부 허용: Dev Container나 Docker, VM 안에서 에이전트를 자유롭게 풀어 줍니다. 단, 호스트 디렉터리를 마운트하거나 실제 DB 접속 정보를 넣어 두면 격리 효과가 크게 줄어든다는 점을 꼭 기억하세요.

✅ 실행 전 검사(Hook) 활용

Claude Code는 도구 호출 전에 실행되는 PreToolUse 훅을 지원합니다. 이걸 이용하면 위험 패턴(migrate reset, stash drop, --force 등)을 감지해 차단하거나 추가 확인을 요구할 수 있습니다. 글쓴이가 만드는 플러그인도 이런 방향으로 보입니다.

✅ 스크립트 내부 삭제 대비

자주 커밋하기: 에이전트에게 작업을 맡기기 전에 커밋하거나 별도 브랜치·git worktree에서 작업하게 하세요. 커밋된 내용은 웬만해서는 복구할 수 있습니다.
스크립트 방어 코드: set -euo pipefail을 쓰고, rm -rf "${DIR:?}"/*처럼 변수가 비어 있으면 실패하도록 작성합니다.
개발 DB 분리: 에이전트가 쓰는 환경에서는 운영·스테이징 DB 접속 정보를 아예 빼 두세요.
정기 백업과 스냅샷: 파일 시스템 스냅샷(Time Machine, Btrfs/ZFS 스냅샷 등)이나 DB 덤프를 습관처럼 남겨 두면 최후의 보험이 됩니다.

마무리

AI 에이전트의 셸 권한 문제는 결국 **"어떤 명령을 막을까"가 아니라 "무엇이 날아가도 괜찮은 환경을 만들까"**의 문제에 가깝습니다. 명령어 검사도 필요하지만, 스크립트 속 rm이나 도구별 파괴적인 명령까지 모두 막을 수는 없습니다. 그래서 **격리(컨테이너) + 복구 가능성(커밋·백업) + 최소 권한(접속 정보 분리)**을 함께 갖추는 게 현실적인 답입니다.

여러분은 에이전트에게 권한을 어디까지 주고 계신가요? 이번 기회에 한 번 점검해 보세요.

원문: https://news.hada.io/topic?id=36930&utm_source=geeknews&utm_medium=rss&utm_campaign=news