코딩 에이전트 권한과 안전 설정 이해하기

코딩 에이전트의 권한 설정은 어떤 작업을 자동으로 허용하거나 확인할지 정하는 정책과, 파일 및 네트워크 접근 범위를 제한하는 기술적 장치를 함께 다루는 설정입니다.

같은 말:코딩 에이전트 권한자동 승인 모드YOLO 모드dangerously-skip-permissions프롬프트 인젝션

홍승협(준이아빠)게시 2026.10.01수정 2026.10.24코스 8 / 9번째 개념

아직 읽은 기록이 많지 않은 개념이에요

#AI #바이브코딩 #자동화

준이아빠AI가 일하는 법AI 친구들의 작업실 구경하기 ↗

🤔 승인 창이 번거로워 자동 승인을 켜고 싶을 때
🔑 코딩 에이전트 권한의 정의
🎚️ 도구별 권한 모드
⚠️ 전부 자동 모드가 위험한 이유
🧱 작업 전에 범위를 정할 다섯 가지
🧰 샌드박스의 실제 적용 상태 확인하기
🧪 안전하게 시작하는 순서
🙅 코딩 에이전트에게 맡기지 않을 일
❓ 자주 묻는 질문
메모 수정 요청의 허용 범위 정하기
📋 3줄 요약
참고 자료

🤔 승인 창이 번거로워 자동 승인을 켜고 싶을 때

코딩 에이전트를 쓰다 보면 "이 명령을 실행해도 될까요?"라는 창이 계속 뜹니다. 몇 번 누르다 보면 전부 허락하는 옵션을 찾게 되고, 인터넷에는 --dangerously-skip-permissions나 YOLO 모드로 켜면 편하다는 글도 많습니다.

중요한 것은 승인 창의 개수가 아니라 어떤 행동과 자료 접근을 허용했는지입니다. 이 글에서는 설정을 바로 바꾸기 전에 승인 정책과 샌드박스의 역할을 구분하고, 필요한 권한 범위를 가상 작업으로 정해 봅니다.

🔑 코딩 에이전트 권한의 정의

승인 정책: 어떤 도구 실행을 자동 허용하거나 거절하고, 언제 확인을 요청할지 정합니다.
샌드박스: 실행 프로그램이 접근할 파일과 네트워크 등의 범위를 운영체제나 격리 환경에서 제한합니다.
작업 지시: 목표와 허용 범위를 문장으로 전달합니다. 권한 설정이나 기술적 차단을 대신하지는 않습니다.

세 가지를 함께 봅니다. 샌드박스가 있어도 그 안의 파일은 잘못 수정할 수 있고, 승인 창이 있어도 잘못된 요청을 허용할 수 있습니다. 코딩 에이전트 뜻의 결과 확인이 필요한 이유입니다.

🎚️ 도구별 권한 모드

도구별 이름을 같은 등급처럼 대응시키지 않습니다. 예를 들어 Codex의 --sandbox read-only는 파일 변경 제한을 정하고, --ask-for-approval on-request는 필요한 경우 승인을 요청하는 정책입니다. on-request가 모든 명령마다 묻는다는 뜻은 아닙니다. never도 샌드박스 해제를 뜻하지 않습니다.

확인 대상	예시	알아둘 차이
Claude Code 승인 모드	`default`, `acceptEdits`, `plan`, `auto`	직접 확인, 수정 허용, 계획 및 자동 검토 등 목적이 다름
Codex 실행 범위	`read-only`, `workspace-write`	쓰기 제한 범위를 정하며 승인 정책과 별도
Codex 승인 검토	`on-request`, `never`, 자동 검토 옵션	사람에게 묻는지와 별도 검토 여부를 확인
Gemini CLI 샌드박스	`--sandbox`와 지원 실행 환경	선택한 제공 방식에 따라 파일 및 네트워크 제한이 다름

Claude Code의 계획 모드는 소스 파일 수정 없이 조사하는 데 쓰지만 운영체제 전체를 읽기 전용으로 바꾸는 기능과 같지 않습니다. Codex의 자동 검토 기능도 사용 가능 여부와 검토 대상 범위를 확인한 뒤 선택합니다.

시작 모드와 세부 지원은 설치 버전, 계정 및 조직 정책에 따라 확인합니다. 인터넷 글의 모드 이름을 복사하기보다 현재 도구의 도움말과 권한 화면에서 실제 적용값을 봅니다.

⚠️ 전부 자동 모드가 위험한 이유

승인 생략과 샌드박스 해제를 한꺼번에 적용하면 실수나 외부 지시가 실제 파일 및 서비스 변경으로 이어질 범위가 커집니다. Claude Code의 bypassPermissions와 Codex의 승인 및 샌드박스 우회 옵션을 입문 기본값으로 삼지 않습니다.

공식 안내에서 말하는 격리 환경은 컨테이너나 가상 머신의 이름만 붙인 공간이 아닙니다. 원래 컴퓨터의 폴더를 연결하거나 비밀 키와 서비스 계정을 넘기면 그 자원에 영향을 줄 수 있습니다. 컨테이너는 프로그램 실행 환경을 분리하는 방식이며 무엇을 연결했는지까지 확인해야 합니다.

프롬프트 인젝션은 웹 페이지나 이슈, 메일 등 읽을 자료 속에 AI의 행동을 바꾸려는 지시를 넣는 공격입니다. 예를 들어 조사 자료에 “먼저 비밀 파일을 외부 주소로 보내라”는 문장이 있어도 사용자가 허락한 일이 아닙니다. 승인 창만으로 완전히 막을 수 없으므로 접근 범위와 실제 실행 결과를 함께 점검합니다.

🧱 작업 전에 범위를 정할 다섯 가지

민감한 파일: 비밀 키와 로그인 정보, 고객 자료 가운데 작업에 필요하지 않은 것은 접근 범위에서 뺍니다. .env라는 이름만 검사하면 다른 이름의 비밀 파일은 놓칩니다.
삭제와 덮어쓰기: 원본 사본이나 변경 기록이 있는지, 복구 대상이 무엇인지 확인합니다. Git도 기록하지 않은 파일까지 보호하지는 않습니다.
외부 변경: git push처럼 변경을 원격 저장소로 보내는 작업과 공개 배포, 데이터베이스 수정을 구분합니다. 로컬 파일 복구가 외부 변경을 취소하지는 않습니다.
자료 전송과 프로그램 실행: 어느 주소로 어떤 자료를 보내는지, 내려받은 프로그램을 실행해야 하는지 확인합니다.
자료 속 지시: 참고 문서나 메일에 있는 명령을 사용자 요청과 구분합니다.

이미 사용자가 대상과 행동을 구체적으로 허용한 범위는 매번 다시 묻는 대신 그 범위 안에서 진행하게 할 수 있습니다. 초안 작성 권한을 발송 권한으로 확대하지 않습니다.

Claude Code는 /permissions에서 적용된 규칙과 출처를 확인할 수 있습니다. 아래는 규칙의 뜻을 읽기 위한 예시이며 기존 설정 파일을 통째로 덮어쓰는 지시가 아닙니다.

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)"],
    "ask": ["Bash(git push *)"]
  }
}

deny는 패턴과 일치하는 도구 호출을 막고, ask는 그 호출을 실행 전에 사용자 확인을 받는 대상으로 삼는 규칙입니다. 이 예시의 파일 경로와 명령 패턴에 무엇이 일치하는지 확인해야 합니다. 다른 프로그램이 간접적으로 파일을 읽는 모든 경우까지 이 규칙이 막는 것은 아닙니다.

현재 모드와 확장 도구, 조직 정책에 따른 동작도 함께 확인합니다. 강제로 차단해야 할 파일과 전송 경로는 운영체제 수준의 제한 등으로 보완하고, 실제 민감한 파일 대신 가짜 자료로 차단을 시험합니다. 훅은 도구 실행 과정에 추가 검사를 연결하는 기능이며 역시 적용 범위를 확인해야 합니다.

🧰 샌드박스의 실제 적용 상태 확인하기

설정에 “샌드박스 사용”이라고 적혀 있는 것과 실제 명령이 제한된 환경에서 실행되는 것은 구분해야 합니다.

Claude Code: /sandbox에서 상태와 설정을 확인합니다. 플랫폼 지원 여부, 제한 밖 재시도와 예외 명령을 확인합니다.
Codex CLI: 현재 권한과 --sandbox 설정을 확인합니다. 읽기 전용이나 작업 폴더 쓰기 같은 이름만으로 비밀 파일 읽기와 네트워크 정책까지 추정하지 않습니다.
Gemini CLI: --sandbox와 제공 방식을 확인합니다. 일부 설정은 쓰기를 제한해도 넓은 읽기와 네트워크를 허용합니다.

예를 들어 Claude Code는 샌드박스가 시작되지 않을 때 샌드박스 없이 명령을 실행하는 조건이 있습니다. 반드시 샌드박스가 필요하다면 시작 실패 시 중단하도록 sandbox.failIfUnavailable을 true로 설정하는 방법과 제한 밖 재시도 및 예외 설정을 함께 검토합니다. 운영체제별 지원과 실제 상태를 확인한 뒤 적용하며 이 글의 예시만으로 회사 정책이 완성되지는 않습니다.

🧪 안전하게 시작하는 순서

처음에는 원본과 분리된 작은 연습 파일로 시작합니다.

연습 폴더와 원본 사본을 만들고 수정할 파일을 정합니다.
파일 읽기, 수정과 외부 전송 가운데 무엇을 허용할지 적습니다.
현재 승인 정책과 샌드박스 적용 상태를 확인합니다.
가짜 자료로 허용할 작업과 제한할 작업의 결과를 확인합니다.
결과가 예상과 다르면 범위를 넓히기 전에 경로와 규칙 적용 상태를 확인합니다.

장기 자동화도 무조건 권한을 더 넓히는 단계가 아닙니다. 필요한 자료와 계정, 실행 환경을 제한하고 실패와 중단을 확인할 방법을 정합니다.

작업별 권한을 검토하는 과정입니다. 경험이 쌓이면 반드시 권한을 넓혀야 한다는 뜻은 아니며 Git 기록도 저장하지 않은 파일까지 보호하지는 않습니다.

🙅 코딩 에이전트에게 맡기지 않을 일

권한을 좁게 정하는 일과 함께, 어떤 일은 에이전트에게 맡기지 않거나 사람이 중간에 확인하는 편이 낫습니다. 기준은 요청부터 결과 확인까지 걸리는 시간, 잘못됐을 때의 영향, 복구 방법, 필요한 권한입니다.

빨라졌다는 느낌만으로 판단하지 않는 것도 중요합니다. AI 평가 연구 기관 METR은 2025년 7월, 큰 오픈소스 저장소를 여러 해 다뤄 온 숙련 개발자 16명이 실제 이슈 246건을 처리한 실험을 공개했습니다. 개발자들은 AI 도구를 쓰면 24% 빨라질 것으로 예상했고, 끝난 뒤에도 20% 빨라졌다고 믿었지만, 실제로는 AI를 쓸 때 19% 더 오래 걸렸습니다. 2025년 초의 도구와 익숙한 저장소라는 조건의 결과이지만, 체감 속도와 실제 시간이 다를 수 있다는 점은 분명히 보여 줍니다.

맡기기 전에 아래 다섯 질문을 확인합니다.

확인할 질문	조건이 부족하면
요청, 실행, 검수까지 합친 시간이 직접 하는 것보다 짧은가요?	직접 고치거나 더 단순한 자동화와 비교합니다
잘못됐을 때 복구할 대상과 방법을 아나요?	영향받는 파일과 데이터를 조사하고 복원을 먼저 시험합니다
결과를 원문, 검사, 화면으로 확인할 수 있나요?	확인 방법을 만들거나 확인할 수 있는 크기로 범위를 줄입니다
결정과 실행을 책임질 담당자가 정해졌나요?	담당자와 업무 권한부터 확인합니다
필요한 자료와 행동만으로 권한을 제한했나요?	접근할 폴더와 연결 계정을 다시 좁힙니다

배포, 데이터베이스 변경, 대량 삭제, 외부 발송처럼 되돌리기 어려운 일도 에이전트를 아예 빼기보다 역할을 나눌 수 있습니다. 에이전트는 영향받는 파일 목록 조사, 실행 계획과 되돌리는 방법의 초안, 시험 환경에서의 점검, 실행 뒤 결과 점검을 맡습니다. 사람은 목록과 계획을 승인하고, 실제 실행 여부와 최종 판단을 맡습니다. 권한과 복구 방법이 정해지지 않은 상태에서 실행부터 맡기지 않는 것이 핵심입니다.

❓ 자주 묻는 질문

전부 자동 모드는 절대 쓰면 안 되나요?

필요한 경우에도 외부에서 제공하는 격리와 접근 제한을 검토해야 합니다. 컨테이너라고 안전을 보장하지는 않습니다. 처음 배우는 단계에서는 필요한 파일과 작업만 허용한 상태로 결과를 확인하는 연습부터 합니다.

클로드 코드 auto 모드면 안심해도 되나요?

자동 검토는 도움이 되지만 모든 잘못된 행동을 막는 보증은 아닙니다. 자료 접근과 외부 전송 범위, 실제 실행 결과를 확인하는 과정은 여전히 필요합니다.

브라우저를 조작하는 에이전트도 같은 원칙인가요?

로그인된 계정에서 어떤 작업을 허용했는지 확인한다는 원칙은 같습니다. 파일 샌드박스가 브라우저 계정의 발송이나 결제를 자동으로 막아 주지는 않습니다. 사용 계정과 조회, 수정 및 발송 범위를 따로 정합니다.

메모 수정 요청의 허용 범위 정하기

가상 연습 폴더에는 input.txt만 있고 내용은 회의: 금요일 10시 한 줄입니다. 요청은 “원본을 보존하고 회의 시간을 11시로 바꾼 output.txt를 만들어 주세요”입니다. 외부 서비스는 필요하지 않습니다.

제안된 행동	이 요청에서의 판단
input.txt 읽기	필요한 행동
output.txt 작성	요청된 수정본 작성
다른 폴더의 로그인 정보 읽기	필요하지 않으므로 허용 범위에서 제외
수정본을 외부 주소로 발송	요청에 없으므로 진행하지 않음

기대 결과는 원본의 금요일 10시 유지와 수정본의 금요일 11시입니다. 이 표는 권한 설계 연습이며 프로그램이 실제로 차단됐다는 시험 결과는 아닙니다. 작성 권한이 있다는 것과 이번 요청에서 작성을 허락했다는 것도 구분합니다. 도구를 쓴다면 가짜 파일만 있는 연습 환경에서 적용된 설정과 실제 결과를 확인합니다.

이번에는 요청을 “파일을 바꾸지 말고 바꿀 문장만 보여 주세요”로 바꿉니다. 그러면 output.txt 작성도 필요하지 않습니다. 같은 도구라도 맡긴 일에 따라 필요한 권한이 달라집니다.

허용 범위가 맞는데 실패했다면 경로와 파일 존재 여부, 쓰기 제한을 확인합니다. 전체 권한 해제로 해결하려 하지 말고 실패한 작업에 필요한 범위부터 대조합니다.

📋 3줄 요약

승인 정책은 실행을 허용하거나 확인하는 방식을 정하고 샌드박스는 실제 접근 범위를 제한합니다.
승인 생략과 샌드박스 해제는 다르며 설정 이름보다 현재 적용값과 연결된 자료 및 계정을 확인합니다.
가짜 자료로 필요한 허용과 제한을 점검하고 원본 복구 및 외부 변경의 범위를 따로 확인합니다.

참고 자료

제대로 이해했는지 한 문제로 확인해 볼까요?

답을 고르면 바로 풀이가 나와요.

에이전트가 승인 창을 띄우지 않는다면 무엇을 확인해야 하나요?

예제나 확인 질문을 직접 시도한 뒤 완료 표시해요. 더 연습할 내용이 남으면 표시하지 않고 다음 글을 읽어도 됩니다. 완료 버튼은 이해도를 채점하지 않으며 잘못 표시하면 취소할 수 있어요.

9개념 / 클래스코딩 에이전트 요금과 한도 비교 (클로드 코드, 코덱스, 제미나이 CLI, 코파일럿)