Claude Code 권한 하드닝: Bash·PowerShell 자동 승인 사고를 줄이는 팀 운영 기준 | DAKER 커뮤니티
Claude Code를 팀에서 쓰기 시작하면 처음에는 자동 승인이 편리하게 느껴집니다. 하지만 읽기처럼 보이는 명령이 실제로는 셸 실행 방식, 리다이렉션, 원격 플래그에 따라 전혀 다른 결과를 만들 수 있다는 점을 놓치면 작은 예외가 반복적인 사고로 이어지기 쉽습니다.
지금 이 주제를 다시 정리할 이유도 여기에 있습니다. 작성 기준일 현재 공식 릴리스에는 Bash, PowerShell, docker 원격 플래그, 긴 명령, 단일 폴더 패턴의 권한 판정 보강이 포함되어 있습니다. 결국 중요한 것은 기능 이름보다, 팀이 어떤 경우에 다시 묻고 어떤 경우에 자동 승인할지를 분명히 정해 두는 일입니다.
Claude Code 권한 하드닝의 핵심은 읽기처럼 보이는 명령도 실제 실행 방식에 따라 다시 묻도록 팀 규칙을 좁히는 것입니다.
Claude Code 권한 하드닝이란, 자동 승인 규칙을 좁게 만들고 위험한 명령은 다시 확인하게 만드는 운영 방식입니다.
무엇을 바로 잡아야 하나요?
핵심은 권한 규칙을 넓게 두는 습관을 줄이는 데 있습니다. 읽기 작업처럼 보이는 명령이라도 실제로는 Bash나 PowerShell에서 실행되면서 파일을 바꾸거나, 리다이렉션을 만들거나, 원격 대상으로 이어질 수 있습니다. 그래서 권한 판단은 명령의 겉모습이 아니라 실제 실행 방식 기준으로 다시 봐야 합니다.
이 글은 기능 설명보다 팀 운영 기준에 초점을 둡니다. 기능 사실은 공식 공개 문서로 비공개 검증했지만, 공개 본문에는 DAKER 정책에 맞춰 DAKER 내부 링크만 남깁니다.
왜 지금 팀 루틴으로 정리해야 하나요?
새 릴리스를 읽고도 팀 사고가 반복되는 이유는 대개 설정값 자체보다 완료 기준과 예외 기준을 함께 공유하지 않기 때문입니다. 권한이 강화되더라도, 팀이 넓은 폴더 패턴을 그대로 두거나 긴 명령을 사실상 읽기 명령처럼 취급하면 운영상 빈틈은 그대로 남습니다.
설정보다 더 중요한 것은 팀이 완료 기준과 예외 기준을 함께 공유하는 일입니다.
따라서 지금 필요한 것은 기능을 더 많이 켜는 일이 아니라, 어떤 명령은 다시 묻게 하고 어떤 경로만 허용할지를 팀 공통 언어로 정리하는 것입니다.
도입할 때 최소한으로 확인할 루틴
처음 적용하는 팀이라면 아래 순서처럼 최소 루틴부터 잡아두는 것이 좋습니다. 각 단계는 도구 사용법이라기보다 작업 확인 기준으로 보는 편이 맞습니다.
- 저장소 루트의 권한 규칙에서 넓은 폴더 패턴을 먼저 찾습니다.
- 쓰기 허용은 현재 작업 폴더 기준으로 필요한 경로만 남깁니다.
- Bash, PowerShell, docker 실행은 읽기 명령처럼 보여도 승인 질문이 뜨는지 확인합니다.
- 긴 명령이나 리다이렉션이 들어간 명령은 자동 승인 대상에서 제외합니다.
- 승인 규칙을 바꾼 뒤에는 팀 문서에 허용 범위와 남은 위험을 한 줄로 적습니다.
작업 요청은 어떻게 남기면 좋을까요?
작업 요청에는 먼저 목표를 쓰고, 다음 줄에 확인 기준을 적고, 마지막 줄에 확인하지 못한 범위를 남기면 됩니다. 이 세 줄만 있어도 Claude Code 세션의 결과 보고가 훨씬 덜 흐려집니다.
| 점검 항목 | 위험한 운영 | 권장 운영 |
|---|---|---|
| 폴더 규칙 | 넓은 패턴을 그대로 허용 | 현재 작업 폴더와 필요한 하위 경로만 허용 |
| 셸 명령 | 읽기처럼 보이면 자동 승인 | 리다이렉션, 긴 명령, 원격 플래그를 다시 확인 |
| 팀 문서 | 허용 목록만 공유 | 허용 이유와 남은 위험을 함께 기록 |
이미지 워크플로가 보여주는 장면
이미지 흐름도 같은 메시지를 보여줍니다. 개발자는 넓은 폴더 허용 규칙 앞에서 멈추고, 팀 보안 보드는 Bash, PowerShell, docker 세 칸으로 나뉩니다. 긴 명령과 리다이렉션 명령에는 승인 질문 카드가 붙고, 저장소 루트 규칙과 현재 작업 폴더 규칙은 분리되어 보입니다. 마지막에는 팀 문서에 허용 범위와 남은 위험이 기록됩니다.
팀 적용 체크리스트
이 체크리스트의 목적은 자동화를 더 많이 켜는 데 있지 않습니다. 작업이 끝났다고 말할 수 있는 증거를 남기는 데 있습니다.
- 한 폴더 패턴이 저장소 어디에서나 매칭된다고 착각하지 않았나요?
- 도움말 명령이나 파일 판별 명령을 무조건 읽기 명령으로 취급하지 않았나요?
- docker 원격 연결 플래그가 팀 승인 없이 실행되지 않게 했나요?
- PowerShell 환경의 문자 인코딩과 리다이렉션 결과를 따로 확인했나요?
- 자동 승인 실패를 불편함이 아니라 안전 신호로 설명했나요?
자주 나오는 질문
자동 승인을 모두 끄는 것이 답인가요?
아니요. 반복 작업은 허용하되, 쓰기 경로와 셸 실행 방식이 분명한 경우로 좁히는 것이 현실적입니다.
Bash와 PowerShell을 같은 기준으로 봐도 되나요?
기본 원칙은 같지만 리다이렉션, 문자 인코딩, 자식 프로세스 동작이 달라서 셸별 확인이 필요합니다.
팀에 먼저 적용할 규칙은 무엇인가요?
쓰기 허용 경로를 줄이고, 긴 명령과 원격 실행 플래그는 승인 질문이 뜨게 만드는 규칙부터 적용하면 됩니다.
공식 문서 링크를 본문에 넣지 않은 이유는 무엇인가요?
이 DAKER 자동화는 공개 링크를 DAKER와 DACON 도메인으로 제한하기 때문에 외부 공식 URL은 비공개 검증에만 사용합니다.
참고 자료
여러분 팀에서는 자동 승인 규칙을 어디까지 좁혀 두고 있는지 궁금합니다.