클로드 코드 권한 설정 방법: 팝업 줄이고 안전하게 쓰는 기준

클로드 코드 권한 설정 방법 핵심 흐름 이미지
처음에는 권한을 전부 넓게 푸는 것보다, 자주 쓰는 작업부터 정리하는 편이 안정적입니다.

클로드 코드(Claude Code)를 처음 쓰다 보면 가장 자주 멈추는 지점이 권한입니다. 파일은 읽어도 되는지, 수정은 바로 해도 되는지, 다른 폴더까지 같이 봐도 되는지, 실행 명령은 어디까지 허용할지에서 흐름이 자주 끊깁니다.

이 글은 그런 답답함을 줄이기 위한 클로드 코드 권한 설정 방법 정리입니다. 공식 문서 기준으로 어떤 승인이 왜 뜨는지, 어떤 모드부터 시작하면 좋은지, 어디까지 허용해야 편하고 안전한지를 차근차근 설명해보겠습니다.

왜 권한 설정이 중요한가

권한 설정은 불편함을 만드는 기능이 아니라, 오히려 반복 확인을 줄이고 작업 흐름을 일정하게 만드는 기준에 가깝습니다. 처음 이 기준을 잡지 않으면 간단한 수정도 매번 멈추고, 반대로 너무 넓게 열어두면 어디까지 허용했는지 감이 흐려질 수 있습니다.

즉 목표는 모든 제한을 없애는 것이 아니라, 자주 하는 작업은 덜 막히게 하고, 위험할 수 있는 작업은 한 번 더 확인하게 만드는 것입니다.

가장 먼저 /permissions부터 열어보기

처음에는 설정 파일을 바로 뒤지기보다, 클로드 코드 안에서 /permissions를 먼저 열어보는 편이 좋습니다. 현재 어떤 승인 흐름이 적용되고 있는지 바로 확인하기 쉽기 때문입니다.

claude
/permissions

이 메뉴에서 지금 세션에 어떤 규칙이 걸려 있는지, 어떤 작업이 자주 막히는지 감을 잡을 수 있습니다. 권한 문제는 “왜 안 되지”라고 느끼기 쉬운데, 실제로는 규칙을 아직 안 정했거나 범위를 좁게 둔 경우가 많습니다.

allow, ask, deny를 먼저 이해하기

권한 규칙은 단순하게 보면 세 가지로 생각하면 됩니다.

  • allow : 묻지 않고 허용
  • ask : 확인 후 진행
  • deny : 허용하지 않음

처음에는 이 세 가지의 우선순위만 이해해도 훨씬 편합니다. 보통은 위험도가 낮고 자주 하는 작업은 allow, 실행이나 변경처럼 영향이 큰 작업은 ask, 정말 막아야 하는 작업은 deny로 생각하면 무리가 없습니다.

중요한 점은 처음부터 다 allow로 바꾸는 것이 능사가 아니라는 점입니다. 몇 번 실제로 써보면서 어떤 승인 팝업이 반복되는지 보고 줄여가는 쪽이 더 현실적입니다.

defaultMode는 어떤 것을 고르면 좋을까

클로드 코드 권한 모드 정리 이미지
처음에는 default나 acceptEdits 정도에서 시작하는 편이 무난합니다.

공식 문서 기준으로 권한과 관련된 기본 모드는 여러 단계가 있습니다. 처음에는 이름이 비슷해서 헷갈리기 쉬운데, 사용감은 꽤 다릅니다.

  • default : 기본 승인 흐름입니다. 처음 시작할 때 가장 무난합니다.
  • acceptEdits : 파일 편집 승인 흐름을 조금 더 부드럽게 가져갈 때 유용합니다.
  • plan : 분석과 계획 중심으로 쓰고, 실제 변경은 신중하게 가져가고 싶을 때 맞습니다.
  • dontAsk, bypassPermissions : 매우 강한 모드라서 초반에는 권장하기 어렵습니다.

개인적으로 처음에는 default에서 시작해서, 자주 하는 편집 작업이 너무 자주 끊길 때만 acceptEdits를 검토하는 흐름이 가장 안정적입니다.

권한 팝업이 너무 많다면 이렇게 정리하면 됩니다

처음 권한 팝업이 많을 때는 짜증부터 나기 쉽지만, 조금만 나눠보면 정리할 수 있습니다.

  1. 매일 반복되는 작업인지 확인
  2. 실수해도 영향이 작은 작업인지 확인
  3. 그 작업만 allow 쪽으로 조금 완화
  4. 위험한 실행이나 광범위 변경은 계속 ask 유지

예를 들어 코드 읽기, 요약, 구조 설명 같은 흐름은 비교적 덜 엄격해도 괜찮지만, 대량 수정이나 시스템 명령 실행은 여전히 확인을 두는 편이 좋습니다.

프로젝트 바깥 폴더를 읽지 못할 때는 /add-dir

권한 문제처럼 느껴지지만, 실제로는 작업 범위 문제인 경우도 많습니다. 지금 프로젝트 밖의 폴더를 같이 봐야 하는데 못 읽는다면 /add-dir를 먼저 확인하는 편이 좋습니다.

/add-dir ../shared-lib

예를 들어 메인 저장소와 공용 라이브러리를 같이 봐야 하거나, 문서 폴더와 코드 폴더를 함께 읽혀야 할 때 유용합니다. 이 경우는 권한을 무작정 넓게 푸는 것보다, 읽어야 할 디렉터리 범위를 정확히 추가하는 것이 더 깔끔합니다.

팀 설정과 개인 설정은 섞지 않는 편이 좋습니다

클로드 코드를 팀 단위로 쓰기 시작하면, 권한 규칙을 어디에 둘지 헷갈리는 경우가 많습니다. 이럴 때는 기준을 단순하게 두는 편이 좋습니다.

  • 팀 전체에 필요한 규칙은 프로젝트 설정에
  • 내 컴퓨터에서만 필요한 실험용 규칙은 로컬 설정에
  • 전 프로젝트 공통 기본값은 전역 설정에

이 기준이 없으면 저장소 안에 개인 취향이 섞여 들어가고, 나중에는 왜 이런 규칙이 있는지 설명하기 어려워집니다.

처음 추천하는 권한 설정 기준

처음부터 복잡하게 갈 필요는 없습니다. 아래 정도면 꽤 안정적으로 시작할 수 있습니다.

  • 읽기와 분석은 비교적 넓게 허용
  • 파일 수정은 기본 승인 흐름 유지
  • 실행 명령은 필요한 범위만 점진적으로 허용
  • 대량 변경, 민감한 작업은 계속 확인 유지
  • 프로젝트 바깥 디렉터리는 필요할 때만 추가

이렇게 시작하면 너무 답답하지도 않고, 나중에 왜 이런 규칙을 잡았는지도 설명하기 쉽습니다.

자주 헷갈리는 부분

권한을 넓혔는데도 여전히 막혀요
현재 세션 규칙, 프로젝트 설정, 전역 설정이 겹쳐 있을 수 있습니다. 한 번에 너무 많은 파일을 만지기보다, 어디가 실제로 적용되는지 먼저 정리하는 편이 좋습니다.

dontAsk를 바로 써도 될까요?
초반에는 권장하지 않습니다. 반복 작업이 많고, 지금 허용하는 범위를 정확히 알고 있을 때만 신중하게 검토하는 편이 낫습니다.

acceptEdits는 언제 유용한가요?
코드 수정 승인 흐름이 너무 자주 끊겨서 사용감이 떨어질 때 검토할 만합니다. 다만 처음에는 기본 모드로 충분히 적응한 뒤 바꾸는 편이 안전합니다.

정리

클로드 코드 권한 설정은 보안을 위해 무조건 엄격하게 두거나, 편의를 위해 전부 풀어버리는 문제가 아닙니다. 반복되는 승인 팝업을 줄이면서도 작업 범위를 명확하게 유지하는 균형이 중요합니다.

처음에는 /permissions로 현재 상태를 보고, defaultacceptEdits 중심으로 차근차근 조정하는 편이 가장 현실적입니다. 그리고 프로젝트 바깥 폴더가 필요할 때는 권한을 넓히기보다 /add-dir를 먼저 떠올리는 편이 훨씬 깔끔합니다.

함께 보면 좋은 글:

참고한 공식 문서

  • Claude Code settings
  • Claude Code permissions

댓글 남기기

광고보고 콘텐츠 계속 읽기
원치않으시면 뒤로가기를 해주세요
광고보고 콘텐츠 계속 읽기
원치않으시면 뒤로가기를 해주세요