13장. 에이전트에게 주는 권한의 경계

LLM-Wiki 강의를 시작하고 수강생들과 첫 실습을 하면 거의 반드시 같은 질문이 나온다. “이 Allow, Yes 버튼을 계속 눌러야 하나요?” 에이전트가 파일을 읽거나 고치고 명령을 실행할 때마다 확인 창이 뜨기 때문이다. 확인 창이 계속 쌓이면 수강생은 내용을 읽지 않고 같은 버튼부터 누르게 된다. 저는 평소 Codex에서 Approve for me를 선택해 쓰는 편이다. 이 설정에서는 작업 공간의 경계를 벗어나려는 요청을 별도의 자동 검토가 판단하므로 사람이 매번 버튼을 누르는 횟수가 줄어든다. 어떤 설정이 맞는지는 사용하는 사람과 자료의 성격에 따라 달라진다. 처음 여는 폴더인지, 원본 파일을 직접 고치는지, 외부로 메일이나 문서를 보내는지에 따라 허용할 범위가 달라져야 한다. AI 에이전트가 내 파일을 어디까지 읽고 고칠 수 있는지, 어떤 명령을 실행할 수 있는지, 어느 순간에 다시 나에게 물어야 하는지를 정한 것이 권한이다. 권한을 정하지 않은 채 시작하면 확인 창을 무심코 반복해서 누르거나 작업 범위를 지나치게 넓게 열어 두게 된다.

권한을 물어보는 세 가지 상황

에이전트가 사람에게 확인을 요청하는 상황은 크게 셋이다. 첫째는 파일을 만들거나 고칠 때다. 새 문서를 쓰는 일과 이미 있는 문서를 덮어쓰는 일은 되돌리는 비용이 다르다. 앞의 것은 지우면 되고 뒤의 것은 이전 내용이 사라진다. 둘째는 명령을 실행할 때다. 목록을 보는 명령과 파일을 지우는 명령이 같은 통로로 나가므로 도구는 어느 명령이 안전한지를 판정하거나 사람에게 묻는다. 셋째는 폴더 바깥으로 나갈 때다. 작업 폴더 안의 파일을 다루는 것과 홈 폴더의 다른 위치를 건드리는 것, 그리고 네트워크로 나가는 것은 위험의 종류가 다르다. 권한 설정은 이 세 상황 각각에 대해 묻고 진행할지, 묻지 않고 진행할지, 아예 막을지를 정하는 일이다.

두 도구의 권한 모드

Claude Code와 Codex는 모두 작업 범위와 승인 방식을 나누지만 화면에 드러내는 단위가 다르다. Codex의 데스크톱 앱은 누가 경계 밖 요청을 검토하는지를 세 모드로 보여 주고 실제 파일 범위는 샌드박스나 권한 프로필이 정한다. Claude Code는 파일 편집과 명령 실행을 어느 정도까지 자동 승인할지를 여섯 모드로 나눈다. 이름을 일대일로 대응시키기보다 읽기 범위, 쓰기 범위, 네트워크 접근, 승인 주체를 각각 확인해야 한다. 아래 표의 영문은 2026년 8월 공식 문서에 쓰인 이름이고 한글은 이 책에서 뜻을 설명하기 위해 붙인 번역이다. 제품 판과 실행 화면에 따라 표시되는 모드는 달라질 수 있다. (Codex 권한 문서, Claude Code 권한 모드)

Codex에서는 승인 모드와 별도로 기술적 접근 범위를 확인한다. :read-only(읽기 전용)는 로컬 명령의 쓰기를 막고 :workspace(작업 공간)는 활성 작업 공간과 임시 폴더 안에서만 쓰기를 허용하며 :danger-full-access(제한 없는 로컬 접근)는 로컬 샌드박스 제한을 없앤다. Approve for me를 골라도 작업 공간 경계가 넓어지지 않는다는 점이 중요하다. 바뀌는 것은 경계 밖 요청을 사람이 검토하는지 자동 검토가 맡는지다.

아래 그림에서는 공식 모드를 세 등급의 운용 예시로 묶었다. 일반 고양이, 반고반기계 고양이, 사이보그 고양이는 이 책에서만 쓰는 비유다. 자료가 민감할수록 에이전트가 움직일 수 있는 환경을 좁히고 사람이 확인할 항목을 늘린다.

세 등급은 자료의 민감도에 따라 확인 강도를 높이는 이 책의 운용 비유다. 실제 설정에서는 바로 위 표의 Codex·Claude 공식 모드와 접근 범위를 함께 확인한다.

Claude Code의 권한 모드

Claude Code의 dontAsk와 bypassPermissions는 이름이 비슷해 보여도 동작이 반대다. dontAsk는 미리 허용하지 않은 도구를 조용히 거부하므로 사람이 지켜보지 않는 스크립트나 CI에 맞는다. bypassPermissions는 권한 검사를 건너뛰고 동작을 실행하므로 인터넷과 개인 파일에서 격리된 컨테이너나 가상 머신에 한정한다. 처음 시작할 때는 default로 두고 변경 전에 구조를 파악해야 할 때 plan을 고르는 편이 안전하다. 파일 변경을 계속 검토할 수 있는 작업에서는 acceptEdits로 확인 창을 줄일 수 있다.

Codex의 승인 정책과 샌드박스

Codex의 권한은 샌드박스와 승인 방식을 함께 봐야 한다. 샌드박스는 명령이 기술적으로 닿을 수 있는 파일과 네트워크를 정하고 승인 방식은 그 경계를 넘으려 할 때 누가 검토할지를 정한다. Auto라고 부르는 기본 조합은 작업 공간 쓰기와 필요 시 승인을 묶는다. Codex는 이 상태에서 작업 폴더 안의 파일을 읽고 고치며 명령을 실행하고 폴더 밖이나 네트워크가 필요할 때 승인을 요청한다. MCP나 앱 도구가 외부 상태를 바꾸는 경우에는 파일 권한과 별도의 승인이 적용될 수 있다. 설정 이름만 외우기보다 작업 폴더 안에서 무엇을 자동으로 할 수 있고 어떤 경계를 넘을 때 누가 승인하는지를 확인한다.

일상 작업의 출발점은 작업 공간 안의 읽기와 쓰기를 허용하고 그 밖의 파일이나 네트워크에 접근할 때 승인을 받는 자동 작업 프로필이다. Codex 공식 문서가 예로 드는 기본 조합도 작업 공간 쓰기와 필요 시 승인이다. 새 폴더를 탐색하거나 무엇이 있는지 확인만 할 때는 읽기 전용이 맞다. 이 상태에서는 실수로 파일이 바뀌지 않으므로 먼저 범위를 파악하기 좋다. 전체 접근과 승인 요청 없음은 샌드박스와 사람의 확인을 함께 약하게 만들므로 격리된 환경이 아니면 쓰지 않는다. 네트워크 접근은 작업 공간 쓰기 권한만으로 자동 허용되지 않고 기본적으로 꺼져 있다. 웹 검색 도구도 명령이 쓰는 네트워크와 별도의 설정을 가지며 저장된 검색 색인을 쓰는 방식과 실시간 검색을 구분한다. 이 책이 근거로 삼은 위키의 첫 번째 규칙은 사람이 요청하지 않으면 웹 검색을 하지 않는다는 것이고 그 규칙은 지침 파일에 적혀 있다. 도구가 강제하는 권한과 에이전트가 따르는 작업 규칙은 다른 층이므로 둘을 함께 확인해야 한다.

따라해보기

아래 블록은 AI 도구의 채팅창에 그대로 붙여 넣는 프롬프트다. 권한 설정을 고르는 일은 한 번 해 보면 감이 온다. 위키 폴더에서 세션을 열고 다음을 시켜 본다.

이 폴더의 구조를 파악하고 지금 무엇이 비어 있는지 알려 달라.
아무것도 만들거나 고치지 말고 읽기만 해 달라.

읽기 전용이나 계획 모드로 이 요청을 하면 에이전트가 무엇을 하려고 하는지 보인다. 같은 요청을 권한이 열린 상태에서 하면 요청하지 않은 파일이 만들어지는 경우가 있다. 두 결과를 비교해 보면 모드가 무엇을 막는지 알 수 있다. 그다음에 실제 작업을 시켜 본다.

sources/ 폴더에 문서 하나를 만들어 달라.
파일을 만들거나 고치기 전에 무엇을 어디에 만들지 먼저 보여 달라.

뒤의 한 줄이 도구 설정과 별개로 작동한다는 점이 중요하다. 권한 모드는 도구가 강제하는 경계이고 지침 파일과 요청에 적는 문장은 그 안에서 에이전트가 지키는 규칙이다. 앞의 것은 어기려 해도 어길 수 없고 뒤의 것은 지키기로 한 약속이다.

확인 창에서 볼 것

확인 창이 떴을 때 무엇을 보는지도 익혀 둘 필요가 있다. 창에 나오는 것은 대체로 무엇을 하려는지에 대한 요약과 실제로 실행될 내용이다. 요약만 읽고 누르면 요약이 정확한지를 확인하지 않은 채 승인하는 것이 된다. 파일을 고치는 경우에는 어느 파일인지와 무엇이 어떻게 바뀌는지를 본다. 여러 파일이 한 번에 나오면 그 수를 먼저 본다. 예상보다 많으면 범위가 잘못 잡힌 것이고 그때 멈추는 편이 낫다. 명령을 실행하는 경우에는 명령 자체를 읽는다. 특히 삭제하거나 덮어쓰거나 이동하는 동작, 그리고 여러 파일을 한꺼번에 지정하는 표현이 들어 있는지 본다. 대상 경로가 작업 폴더 밖을 가리키고 있지는 않은지도 본다.

확인 창을 누르는 속도가 빨라지는 것은 자연스럽지만 위험한 신호이기도 하다. 같은 종류의 확인을 열 번 넘게 받았다면 그것은 그 동작을 허용 목록에 넣어야 한다는 뜻이다. 매번 승인하면서 매번 읽지 않는 것보다, 한 번 판단해 목록에 넣고 나머지 확인은 실제로 읽는 편이 낫다. 확인 창의 수를 줄이는 일과 권한을 넓히는 일은 같지 않다. 반복되는 안전한 동작을 목록으로 빼면 창의 수는 줄어들고 허용 범위는 그대로다.

도구가 막는 것과 규칙이 막는 것

권한 설정으로 막을 수 있는 것에는 한계가 있다. 도구는 동작의 종류만 알고 의도는 모른다. 작업 폴더 안에서 문서를 만드는 일과 작업 폴더 안의 문서를 지우는 일은 도구 입장에서 둘 다 쓰기이고 같은 설정 아래에서 둘 다 허용되거나 둘 다 막힌다. 사람 입장에서 두 동작의 위험은 전혀 다르다. 이 간격을 메우는 것이 지침 파일이다. 도구가 허용한 범위 안에서 무엇을 어떤 순서로 할지는 규칙 문서가 정한다. 덮어쓰기 전에 먼저 읽고 무엇을 바꿀지 보여 준다는 규칙, 밖으로 나가는 것은 초안을 만들어 승인을 받는다는 규칙, 확인하지 못한 것을 이상 없음으로 적지 않는다는 규칙이 여기 해당한다. 두 층은 성격이 다르다. 도구의 경계는 어기려 해도 어길 수 없고 규칙은 지키기로 한 약속이다.

약속이라서 깨진다. 그래서 자주 깨지는 규칙에는 기계 검사를 붙인다. 위키에 넣지 않기로 한 표현이 문서에 들어갔는지 검사하는 스크립트, 종합 층과 연결되지 않은 페이지를 세는 감사, 끊긴 링크를 찾는 검사가 그런 것들이다. 검사가 붙은 규칙과 붙지 않은 규칙은 몇 달 뒤에 지켜지는 정도가 다르다. 모든 규칙에 검사를 붙일 수는 없는데 판단이 들어가는 규칙은 기계가 판정할 수 없기 때문이다. 무엇을 규칙으로 두고 무엇을 검사로 바꿀지는 그 판정이 결정적으로 내려질 수 있는가로 갈린다. 파일 이름의 형식은 검사할 수 있고 이 논문이 저 종합 문서와 관련이 있는지는 검사할 수 없다.

되돌릴 수 있는가로 나누는 경계

설정 값을 고르는 기준은 하나로 정리된다. 그 동작을 되돌릴 수 있는가다. 파일을 읽고 검색하고 초안을 만들고 형식을 맞추고 빠진 것을 찾는 동작은 되돌릴 수 있다. 결과가 마음에 들지 않으면 지우면 되고 손해도 남지 않는다. 이런 동작은 묻지 않게 두는 편이 낫다. 확인 창이 자주 뜨면 사람은 내용을 읽지 않고 누르게 되고 그 습관이 붙은 뒤에는 정말 봐야 할 확인 창도 그냥 눌린다. 되돌리기 어려운 동작은 반대쪽에 둔다. 기존 파일을 덮어쓰는 일, 여러 파일을 한 번에 바꾸는 일, 폴더 밖으로 나가는 일이 여기 해당한다. 밖으로 나가는 동작은 예외 없이 사람이 본다. 메일 발송, 남의 일정 변경, 외부 시스템에 무언가를 올리는 일은 되돌리는 비용을 상대가 함께 치르기 때문이다.

일괄 변경의 위험은 실제 사고에서 확인되었다. 이 책이 근거로 삼은 위키에서 위키링크 약 5만 개에 접두사를 붙이는 일괄 작업이 실행되어 사용 중이던 문서 구조가 망가진 적이 있다. 그 작업 자체는 승인을 받고 실행되었고 승인한 사람이 본 것은 무엇을 바꿀지에 대한 요약 한 줄이었다. 규모가 큰 변경에서는 승인 창의 문장 한 줄과 실제로 일어나는 일 사이의 간격이 커진다. 그래서 덮어쓰기 전에 먼저 읽고 무엇을 어떻게 바꿀지 보이고 승인을 받은 뒤에 쓴다는 순서를 지침 파일에 적어 두었다. 이 순서는 권한 모드로는 강제되지 않는다. 도구는 쓰기를 허용하거나 막을 뿐이고 쓰기 전에 무엇을 보여줄지는 정해 주지 않는다.

도구 단위 허용 목록

모드 하나로 정하는 것과 별개로, 어떤 도구를 쓸 수 있는지를 목록으로 지정하는 방법이 있다. Claude Code에는 허용할 도구 이름을 나열하는 설정이 있고 명령 실행의 경우 어떤 명령까지 허용할지를 패턴으로 적을 수 있다. 이 방식은 반복 작업에 유용하다. 매일 도는 예약 작업이나 정해진 절차를 반복하는 세션에서는 필요한 도구가 정해져 있으므로 그것만 허용하면 확인 없이 돌면서도 범위는 좁게 유지된다. 모드를 열어 두는 것과 목록으로 좁히는 것의 차이가 여기서 갈린다. 모드를 여는 것은 무엇이든 할 수 있게 하되 묻지 않는 것이고 목록을 쓰는 것은 정해진 것만 할 수 있게 하되 그 안에서는 묻지 않는 것이다. 사람이 지켜보지 않는 작업에는 뒤의 방식이 맞다. 27장에서 다루는 예약 자동화가 이 설정 위에서 돌아간다.

자료에 섞여 들어온 지시문

권한을 생각할 때 빠뜨리기 쉬운 경우가 하나 있다. 에이전트가 읽는 자료 안에 에이전트에게 향하는 문장이 섞여 있는 경우다. 위키에 들어오는 것은 논문 PDF와 웹에서 받은 문서와 메일과 남이 만든 파일이고 그 안에 지시처럼 읽히는 문장이 들어 있을 수 있다. 에이전트가 그것을 사람의 요청과 구분하지 못하면, 읽으라고 준 문서가 시키는 문서가 된다. 실제로 위험해지는 조합은 권한이 열려 있고 자료를 밖에서 받아 오는 경우다. 읽기만 허용된 상태에서는 그 문장을 읽어도 할 수 있는 일이 없지만 쓰기와 명령 실행이 열려 있으면 그 문장이 동작으로 이어질 수 있다. 그래서 밖에서 들어온 자료를 처음 처리하는 세션의 권한을 좁게 두는 편이 낫다.

원칙은 하나다. 지시는 사람이 대화로 준 것만이고 파일과 문서와 메일에 적힌 것은 전부 자료다. 자료 안에 지시처럼 보이는 문장이 있으면 그것을 따르지 말고 사람에게 그 문장이 있다는 사실을 알리게 한다. 이 규칙은 도구 설정으로 강제되지 않으므로 지침 파일에 적어 둔다. 판단이 애매한 경우도 있다. 자기가 예전에 쓴 규칙 문서는 자료인가 지시인가다. 이 경우는 지시로 다루되, 그 문서가 어디에 있는지를 정해 둔다. 지정한 위치의 규칙 문서만 지시로 읽고 위키의 다른 문서는 내용이 무엇이든 자료로 읽는다. 파일 위치로 구분하면 판단할 것이 없어진다.

설정이 흔들리는 원인

권한 설정에서 실제로 문제가 되는 것은 값을 잘못 고르는 일보다 값이 세션마다 달라지는 일이다. 급한 작업에서 확인 창이 성가셔 한 번 열어 두면 그 상태가 다음 세션까지 이어지고 언제부터 열려 있었는지는 기억나지 않는다. 그래서 기본값을 파일에 적어 두고 그 값에서 벗어날 때만 의식적으로 바꾸는 편이 낫다. 두 번째로 흔한 경우는 도구를 여러 대의 기계에서 쓸 때다. 한 기계에서 좁게 설정하고 다른 기계에서 넓게 설정해 두면, 같은 폴더에 같은 작업을 시켜도 결과가 다르다. 세 번째는 판이 올라가면서 값의 이름이나 기본값이 바뀌는 경우다. 도구를 갱신한 뒤에 첫 세션에서 무엇이 확인 없이 진행되는지 한 번 보는 습관이 필요하다. 확인 창이 뜨지 않는다면 그 종류의 동작을 이미 허용한 것이다.

처음 시작할 때 권하는 조합

권한을 어떻게 두고 시작할지에 대한 답은 작업의 단계마다 다르다. 새 폴더를 열고 무엇이 있는지 보는 단계에서는 읽기만 허용한다. 이 단계에서 파일이 바뀔 이유가 없고 읽기만 허용해 두면 시켜 보는 데 부담이 없다. 위키를 만들고 문서를 채우는 단계에서는 작업 폴더 안의 쓰기를 열고 폴더 밖과 명령 실행은 확인받는다. 실습을 따라가며 되돌리기 어려운 동작에서 확인 창이 뜨므로 어디에서 창이 뜨는지를 보는 것 자체가 배우는 과정이 된다. 검색 색인을 세우고 스크립트를 돌리는 단계에서는 명령 실행이 잦아지므로 안전한 명령을 자동으로 통과시키는 설정이 편해진다. 이때도 폴더 밖으로 나가는 동작과 외부로 내보내는 동작은 열지 않는다.

권한을 넓힐지 고민될 때 쓸 만한 질문이 하나 있다. 지금 이 확인 창을 없애면 무엇이 잘못될 수 있고 잘못되었을 때 되돌릴 방법이 있는가다. 되돌릴 방법이 있으면 열어도 되고 없으면 성가셔도 남겨 둔다. 되돌릴 방법이 파일 버전 기록뿐인 환경에서는 그 기록이 얼마나 오래 남는지도 확인해 둔다. 며칠치만 남는 설정이라면 몇 주 뒤에 발견한 문제는 되돌릴 수 없다. 이 확인은 위키를 만들기 전에 끝내 둔다.

이 책이 근거로 삼은 환경의 설정 파일을 열어 보면 앞 절이 권하는 조합보다 훨씬 넓게 열려 있다. 기본값이 확인을 묻지 않는 것이고 작업 폴더 밖까지 접근이 열려 있으며 도구 하나하나에 사람 승인을 강제해 둔 항목은 전체 설정에서 손에 꼽는다. 몇 년 동안 매일 돌리다 보면 확인 창을 닫는 동작이 습관이 되고 습관이 된 확인은 제 기능을 잃는다. 스무 번 눌러 온 창이 스물한 번째에 다른 것을 묻고 있어도 한곳을 누르게 된다. 그래서 확인 창의 수를 늘리는 대신 되돌릴 수 없는 동작만 골라 그곳에 강제 게이트를 두는 쪽으로 정리했다. 지금 기계적으로 막혀 있는 것은 이메일 발송과 일정 변경 둘이다. 나머지는 지침 문장과 작업별 프롬프트가 지키는데 프롬프트마다 같은 금지 목록이 반복해서 적혀 있다. 자동으로 메일을 보내지 않고 댓글을 자동으로 달지 않고 메일과 파일과 문서를 지우지 않는다.

값이 이 모양으로 정해진 경위는 대체로 사고 뒤였다. 일정 변경을 코드로 막은 가드는 같은 실수가 반복되고 나서 만들어졌고 운영 로그에는 아침에 허용되어 있던 동작이 같은 날 저녁에 읽기 전용으로 바뀐 기록도 남아 있다. 권한이 좁아진 시점은 전부 무언가 잘못된 뒤였고 미리 좁혀 둔 적은 없다. 이 순서를 뒤집을 수 있다고 믿지 않는 편이 낫고 그래서 처음 시작하는 사람에게는 앞 절의 좁은 조합을 권한다. 넓게 열어 둔 설정은 무엇이 잘못되었을 때 그것을 알아차리는 경로를 따로 갖춘 뒤에야 감당할 수 있다. 상시로 허용한 것이 있으면 그 사실도 프롬프트 안에 데이터로 적어 둔다. 무엇을 누가 언제 허용했고 그 범위가 어디까지인지를 적어 두지 않으면, 몇 달 뒤에는 그것이 결정이었는지 흘러온 상태인지 구분되지 않는다.