AI 코딩툴 보안 설정은 어디까지 나눠야 할까 2026 – MCP·파일권한·로그를 분리하는 운영표

Posted on by

AI 코딩툴은 이제 자동완성 도구가 아닙니다.

파일을 읽고,

코드를 고치고,

테스트를 돌리고,

MCP 서버를 통해 외부 도구까지 부릅니다.

편해졌습니다.

그리고 편해진 만큼 위험도 좀 더 입체적이 됐습니다.

예전에는 “이 플러그인 믿어도 되나?” 정도를 봤다면,

지금은 “이 에이전트가 어느 디렉터리를 읽고, 어디에 쓰고, 어떤 네트워크를 열고, 어떤 로그를 남기는가”를 봐야 합니다.

이 글은 겁주기용 보안글이 아닙니다.

Codex, Claude Code, MCP 기반 도구를 실제 개발 워크플로우에 붙일 때 권한을 어디까지 나눠야 하는지를 운영표로 정리합니다.

한 줄 결론부터 말하면 이렇습니다.

AI 코딩툴 보안은 모델 선택보다 권한 경계 설계가 먼저입니다.

모델이 똑똑해도 권한이 너무 넓으면 사고 범위도 넓습니다.

반대로 권한이 너무 좁으면 매번 멈춰서 사람이 허락 버튼만 누르게 됩니다.

개발자는 어느 순간 승인 버튼 누르는 기계가 됩니다.

그건 인간 자동화입니다. 방향이 이상하죠.

먼저 운영 결론

AI 코딩툴 보안 설정은 최소 네 층으로 나누는 것이 좋습니다.

층 나눌 것 기본값
작업 모드 읽기 전용, 워크스페이스 수정, 전체 자동 실행 읽기 전용 또는 워크스페이스 수정
파일 권한 읽기 가능 경로, 쓰기 가능 경로, 민감 파일 차단 저장소 내부만 쓰기
MCP/외부도구 읽기 도구, 쓰기 도구, 파괴적 도구 도구별 allowlist
로그/감사 프롬프트 저장, 도구 실행 로그, 승인 기록 프롬프트는 기본 비저장 또는 redaction

이 네 층을 한꺼번에 “자동 허용”으로 열면 편합니다.

하지만 사고가 났을 때 원인을 좁히기 어렵습니다.

반대로 네 층을 따로 나눠두면 나중에 운영이 쉬워집니다.

“이건 모델이 잘못했나?”

“MCP 서버가 과한 권한을 가졌나?”

“파일 권한이 너무 넓었나?”

“로그에 민감 정보가 남았나?”

이 질문에 답할 수 있어야 합니다.

왜 2026년에 이 주제가 중요해졌나

AI 코딩툴은 개발자의 손을 빌리지 않고 더 많은 일을 하게 됐습니다.

예전에는 제안만 했습니다.

지금은 실행합니다.

예전에는 코드 조각을 만들었습니다.

지금은 저장소를 훑고, 테스트를 돌리고, 문서를 고치고, 브랜치 작업까지 이어갑니다.

이 변화는 생산성을 올립니다.

하지만 보안 경계도 바꿉니다.

위험은 단순히 “AI가 틀린 코드를 짠다”가 아닙니다.

더 큰 위험은 다음입니다.

  • 민감 파일을 읽는다.
  • 필요 없는 네트워크 요청을 한다.
  • 외부 도구를 통해 데이터를 내보낸다.
  • 위험한 shell 명령을 실행한다.
  • MCP 서버가 너무 넓은 권한을 가진다.
  • 로그에 프롬프트나 소스코드가 남는다.
  • 사용자가 반복 승인 피로 때문에 그냥 허용한다.

공식 문서들도 이제 이 문제를 정면으로 다룹니다.

OpenAI Codex 문서는 sandbox mode와 approval policy를 별도 계층으로 설명합니다.

Claude Code 문서도 permissions와 sandboxing을 보완적 보안 계층으로 설명합니다.

MCP 공식 보안 문서는 confused deputy, token passthrough, SSRF, local MCP server compromise, scope minimization 같은 공격 흐름을 다룹니다.

즉, “AI 코딩툴 보안”은 더 이상 감정의 문제가 아닙니다.

운영 설계의 문제입니다.

1단계: 작업 모드를 먼저 나눈다

가장 먼저 정할 것은 작업 모드입니다.

AI 코딩툴을 쓸 때 모든 작업이 같은 권한을 필요로 하지 않습니다.

문서 읽기와 프로덕션 배포 스크립트 수정은 같은 위험이 아닙니다.

테스트 실행과 외부 API 호출도 같은 위험이 아닙니다.

그래서 작업 모드는 최소 세 개로 나누는 편이 좋습니다.

모드 허용 범위 쓰는 상황
Read-only 파일 읽기와 분석 중심 코드리뷰, 설계 질문, 문서 탐색
Workspace-write 저장소 내부 수정 일반 기능 개발, 테스트 수정, 문서 보강
Full-auto / bypass 계열 자동 실행 폭이 큼 신뢰 저장소, 격리 환경, 반복 작업

Codex의 경우 기본 보안 설명에서 sandbox mode와 approval policy가 함께 작동한다고 설명합니다.

sandbox mode는 기술적으로 무엇을 할 수 있는지,

approval policy는 언제 사용자 허가를 받아야 하는지를 정합니다.

이 둘을 분리해서 보는 것이 중요합니다.

“승인 프롬프트가 없다”는 말이 곧 “아무거나 가능하다”는 뜻은 아닐 수 있습니다.

반대로 “승인 프롬프트가 있다”는 말이 곧 안전하다는 뜻도 아닙니다.

사람이 피곤하면 아무거나 승인합니다.

버튼은 철학이 없습니다.

권장 프리셋

개인 개발자는 기본적으로 아래처럼 시작하면 됩니다.

작업 권장 모드
처음 보는 저장소 분석 read-only
내 저장소의 작은 버그 수정 workspace-write + on-request approvals
테스트 자동 수정 workspace-write + 네트워크 차단
외부 패키지 설치 필요 승인 기반 네트워크 허용
배포, 인프라, 결제, DB 변경 자동 실행 금지

팀이라면 더 강하게 나눠야 합니다.

환경 권장 정책
개인 실험 workspace-write 가능
팀 공용 저장소 repo-specific config
민감 코드 저장소 read-only 기본 + 명시 allowlist
고객 데이터 접근 가능 환경 AI 코딩툴 직접 접근 제한
배포 저장소 별도 승인 게이트

여기서 핵심은 “팀 규칙을 도구 설정으로 내려야 한다”는 점입니다.

문서에만 “조심하자”라고 써두면 언젠가 잊힙니다.

설정 파일, 권한 정책, CI, 리뷰 체크리스트로 내려야 합니다.

2단계: 파일 권한을 읽기와 쓰기로 나눈다

많은 팀이 쓰기 권한만 봅니다.

“AI가 파일을 마음대로 수정하면 위험하지”라는 생각입니다.

맞습니다.

하지만 읽기 권한도 중요합니다.

AI 코딩툴이 .env, credential JSON, production config, 고객 데이터 샘플을 읽을 수 있다면, 그 순간부터 대화와 로그의 민감도가 올라갑니다.

OpenAI Codex 문서는 filesystem profile로 특정 파일의 읽기를 deny할 수 있는 패턴을 설명합니다.

Claude Code 설정 문서도 민감 정보 파일을 막기 위해 permissions.deny로 .env, secrets, credentials 파일을 제외하는 예시를 듭니다.

실무 기준으로는 아래처럼 나누면 됩니다.

파일 유형 읽기 쓰기 메모
일반 소스코드 허용 작업 범위만 허용 기본 작업 대상
테스트 코드 허용 허용 자동 수정 적합
문서 허용 허용 위험 낮음
.env 차단 차단 원칙적으로 읽히지 않게
credentials JSON 차단 차단 로컬 개발에도 위험
production config 제한 차단 또는 승인 배포 사고 방지
DB dump 제한 차단 개인정보 가능성
build output 상황별 자동 수정 제한 generated 파일 충돌 방지

파일 권한은 “전체 저장소 허용”보다 “작업 루트 허용”이 좋습니다.

예를 들어 프론트엔드 컴포넌트 작업이면 src/components/**와 관련 테스트만 열어도 됩니다.

모노레포라면 더 중요합니다.

AI에게 전체 모노레포를 열어주면, 작업 범위보다 문맥이 커지고 위험도 커집니다.

AI도 사람처럼 책상이 너무 어지러우면 엉뚱한 서랍을 엽니다.

3단계: MCP는 서버 단위가 아니라 기능 단위로 본다

MCP는 AI 코딩툴을 강하게 만듭니다.

GitHub,

Slack,

Linear,

데이터베이스,

브라우저,

사내 API,

이런 도구를 모델이 직접 호출할 수 있게 해줍니다.

하지만 강해진 만큼 권한 설계가 중요합니다.

“MCP 서버 하나 연결”은 사실상 도구 묶음을 연결하는 일입니다.

그 안에 읽기 도구만 있을 수도 있고,

쓰기 도구가 있을 수도 있고,

삭제나 배포 같은 파괴적 액션이 있을 수도 있습니다.

그래서 MCP는 서버 이름보다 도구의 성격을 봐야 합니다.

MCP 도구 유형 예시 기본 정책
Read-only 이슈 조회, PR 조회, 문서 검색 허용 가능
Write-light 댓글 작성, 라벨 추가 승인 필요
Write-heavy 파일 수정, 티켓 상태 변경 강한 승인
Destructive 삭제, 배포, 권한 변경 기본 차단
Secret-bearing 토큰, 키, DB 접근 격리 또는 금지

Codex 문서는 app/MCP tool call도 side effect를 광고하면 승인을 유도할 수 있고, destructive annotation이 있는 도구는 승인이 필요하다고 설명합니다.

MCP 공식 보안 문서는 scope minimization을 별도로 다룹니다.

이 말은 단순합니다.

필요한 범위만 열어야 합니다.

GitHub MCP를 붙인다고 해서 모든 repo write 권한이 필요한 것은 아닙니다.

Slack MCP를 붙인다고 해서 모든 채널 메시지 읽기가 필요한 것도 아닙니다.

DB MCP를 붙인다고 해서 production write가 필요한 것은 거의 없습니다.

MCP 운영표

팀에서 MCP를 운영한다면 아래 표를 그대로 체크리스트로 쓰면 됩니다.

질문 답이 아니오면
이 MCP 서버의 도구 목록을 사람이 읽었나 연결 보류
read/write/destructive 도구를 구분했나 allowlist 재작성
production 데이터에 접근하나 격리 환경으로 이동
토큰 passthrough가 있는가 범위 축소 또는 금지
외부 URL 요청이 가능한가 SSRF 방어 확인
로그에 요청/응답이 남는가 redaction 확인
도구 호출이 감사 로그에 남는가 운영 투입 보류

MCP는 “연결하면 편한 것”이 아니라 “도구 권한을 모델에게 위임하는 것”입니다.

위임은 계약서가 있어야 합니다.

계약서 없이 위임하면 나중에 회의가 길어집니다.

회의는 이미 충분히 깁니다.

4단계: 네트워크 권한을 따로 본다

AI 코딩툴에 네트워크를 열어주는 순간 위험의 모양이 달라집니다.

패키지 설치,

웹 검색,

외부 API 호출,

원격 스크립트 다운로드,

텔레메트리 전송,

이 모든 것이 네트워크 권한에 걸립니다.

OpenAI Codex 문서는 기본적으로 로컬 workspace-write sandbox에서 네트워크 접근이 꺼져 있으며, 필요하면 설정으로 켤 수 있다고 설명합니다.

또한 웹 검색 결과도 untrusted로 취급하라고 안내합니다.

Claude Code 보안 문서도 위험한 웹 콘텐츠를 가져오는 명령을 기본적으로 차단하는 보호 장치를 설명합니다.

실무에서는 네트워크를 이렇게 나누면 됩니다.

네트워크 사용 기본 정책
패키지 설치 승인 후 허용
공식 문서 조회 브라우저/검색 도구만 허용
임의 URL curl/wget 기본 차단
사내 API 호출 allowlist + 로그
production DB 접속 금지
배포 서버 접속 별도 승인

특히 curl | bash 계열은 자동 허용하면 안 됩니다.

사람도 안 보고 실행하면 위험한데, AI가 안 보고 실행하면 더 위험합니다.

눈 감고 전기 콘센트 고치는 느낌입니다.

결과가 짜릿할 수는 있는데 좋은 짜릿함이 아닙니다.

5단계: 로그와 텔레메트리를 분리한다

보안 설정에서 자주 빠지는 것이 로그입니다.

AI 코딩툴은 실행 기록을 남길 수 있습니다.

도구 호출,

승인 결정,

프롬프트 길이,

응답 상태,

실행 결과,

에러 로그,

이런 정보는 운영에는 유용합니다.

하지만 소스코드와 민감 정보가 섞이면 위험합니다.

Codex 문서는 OpenTelemetry를 opt-in으로 제공하며, 프롬프트 텍스트는 기본적으로 redacted 상태로 둘 수 있고, tool arguments와 outputs도 민감하게 취급하라고 안내합니다.

팀 기준으로는 아래처럼 정하면 됩니다.

로그 항목 권장
승인/거절 이벤트 저장
도구 이름 저장
실행 시간/성공 여부 저장
전체 프롬프트 원문 기본 비저장
tool input/output 전문 redaction 후 제한 저장
소스코드 포함 응답 저장소 외부 전송 금지
보안 사고 의심 이벤트 별도 감사 로그

로그는 없으면 문제를 못 찾고,

너무 많으면 그 자체가 문제입니다.

그래서 “운영 로그”와 “내용 로그”를 분리해야 합니다.

운영 로그는 남깁니다.

민감 내용은 줄입니다.

이게 기본입니다.

승인 피로를 설계로 줄인다

승인 프롬프트는 보안 장치입니다.

하지만 너무 자주 나오면 사람은 무뎌집니다.

Anthropic의 Claude Code auto mode 글도 이 문제를 approval fatigue로 설명합니다.

Claude Code 사용자가 많은 권한 요청을 승인하는 현실에서, 수동 승인만으로는 충분하지 않다는 문제의식입니다.

그렇다고 모든 권한을 건너뛰면 위험합니다.

그래서 중간값이 필요합니다.

반복 작업 처리
테스트 실행 안전 명령 allowlist
린트 실행 allowlist
로컬 파일 수정 작업 루트 안에서 허용
외부 네트워크 승인
secrets 접근 차단
삭제/배포 강한 승인

승인을 줄이는 방법은 “무조건 허용”이 아닙니다.

반복 안전 작업만 자동화하고,

위험 작업은 더 선명하게 멈추는 것입니다.

알림이 적어야 진짜 위험 알림이 보입니다.

개인 개발자용 최소 설정표

개인 개발자라면 처음부터 엔터프라이즈 정책을 만들 필요는 없습니다.

하지만 최소한 아래는 잡아야 합니다.

항목 최소 기준
기본 작업 모드 workspace-write 또는 read-only
미확인 저장소 read-only
.env 읽기 차단
credentials 읽기 차단
네트워크 기본 차단, 필요할 때 승인
MCP read-only 도구부터 시작
자동 승인 테스트/린트 같은 반복 명령만
로그 프롬프트 원문 저장 최소화

개인 프로젝트라도 production 키가 있으면 개인 프로젝트가 아닙니다.

그건 작은 회사입니다.

작은 회사처럼 다뤄야 합니다.

팀용 운영표

팀에서는 설정을 개인 취향에 맡기면 안 됩니다.

사람마다 “괜찮겠지”의 반경이 다릅니다.

팀 기준표가 필요합니다.

영역 팀 운영 기준
저장소 신뢰 처음 clone한 저장소는 read-only
권한 설정 repo-specific config로 공유
민감 파일 deny rule로 차단
MCP 서버 승인된 서버만 allowlist
destructive tool 기본 차단
네트워크 domain allowlist 검토
로그 중앙 수집 시 redaction
변경 검증 PR diff + 테스트 필수
배포 AI 직접 배포 금지 또는 별도 게이트

엔터프라이즈에서는 여기에 managed configuration이 붙습니다.

Codex 문서도 관리자가 approval policy, sandbox mode, web search mode, MCP servers allowlist 같은 보안 민감 설정을 강제할 수 있는 구조를 설명합니다.

핵심은 “개발자가 매번 현명하길 기대하지 말고, 기본값을 현명하게 만든다”입니다.

위험도별 작업 분류

AI 코딩툴에 시킬 일을 위험도별로 나누면 운영이 쉬워집니다.

위험도 작업 예시 권장
낮음 문서 요약, 코드 읽기, 테스트 실패 원인 분석 read-only
보통 테스트 추가, UI 문구 수정, 작은 버그 수정 workspace-write
높음 인증 로직 수정, 결제 로직 수정, DB migration 사람 리뷰 강화
매우 높음 prod 배포, 권한 변경, secret rotation AI 자동 실행 금지

이 표가 있으면 “AI에게 어디까지 맡길까?”라는 논쟁이 줄어듭니다.

논쟁 대신 분류하면 됩니다.

분류는 감정보다 오래갑니다.

실제 워크플로 예시

예시 1. 새 라이브러리 도입 검토

첫 단계는 read-only입니다.

AI에게 현재 의존성, 번들 크기, 대체 라이브러리, 마이그레이션 범위를 분석하게 합니다.

네트워크는 공식 문서 조회에만 씁니다.

패키지 설치는 바로 허용하지 않습니다.

두 번째 단계에서 별도 브랜치로 workspace-write를 열고 설치와 테스트를 합니다.

예시 2. 버그 수정

처음에는 관련 파일과 테스트만 읽게 합니다.

수정 범위를 정한 뒤 workspace-write로 전환합니다.

AI에게 파일 소유권을 명확히 줍니다.

“인증 모듈만 수정하고 DB schema는 건드리지 마”처럼 말입니다.

수정 후 테스트와 diff를 봅니다.

예시 3. MCP로 이슈/PR 연동

처음에는 read-only MCP만 연결합니다.

이슈 조회,

PR 조회,

코멘트 읽기 정도입니다.

댓글 작성은 승인 필요로 둡니다.

라벨 변경, 상태 변경, 브랜치 삭제는 기본 차단합니다.

예시 4. 사내 API와 연결

사내 API MCP는 별도 개발용 토큰을 씁니다.

production token을 쓰지 않습니다.

권한 scope는 read-only부터 시작합니다.

요청/응답 로그는 redaction합니다.

자동 실행은 금지하고 사람이 승인합니다.

하지 말아야 할 설정

아래는 편하지만 위험합니다.

  • 처음 보는 저장소에서 full-auto 실행
  • .env와 secrets를 읽을 수 있는 상태로 두기
  • production API token을 로컬 MCP에 연결
  • GitHub write 권한을 모든 저장소에 열기
  • Slack 전체 채널 읽기를 기본 허용
  • curl, wget, remote script 실행을 자동 허용
  • 로그에 프롬프트 원문과 tool output 전문 저장
  • 배포 명령을 자동 승인
  • DB migration을 자동 실행

이 중 몇 개는 “한 번만” 하고 싶어집니다.

문제는 사고도 보통 한 번이면 충분하다는 겁니다.

한 번의 편함이 한 달의 복구가 될 수 있습니다.

도구별로 기억할 차이

Codex와 Claude Code는 모두 권한, sandbox, 승인 흐름을 다룹니다.

하지만 설정 파일, 명령어, 기본 동작은 다릅니다.

그래서 특정 도구의 설정 이름을 외우기보다 운영 원칙을 먼저 잡아야 합니다.

원칙 Codex 쪽 표현 Claude Code 쪽 표현
기술적 실행 경계 sandbox mode sandbox
승인 정책 approval policy permissions / permission mode
민감 파일 차단 filesystem deny profile permissions.deny
외부 도구 MCP/app tool calls MCP servers/tools
로그/감사 OTel events 설정/조직 정책/도구 로그

도구가 바뀌어도 질문은 같습니다.

무엇을 읽을 수 있나.

무엇을 쓸 수 있나.

무엇을 실행할 수 있나.

어디로 나갈 수 있나.

무엇이 기록되나.

이 다섯 개입니다.

15분 점검 체크리스트

오늘 당장 점검한다면 아래 순서로 보면 됩니다.

  1. AI 코딩툴 기본 모드가 무엇인지 확인한다.
  2. 처음 보는 저장소에서 read-only로 시작하는지 확인한다.
  3. .env, .env.*, credentials 파일 읽기가 차단되어 있는지 확인한다.
  4. 쓰기 가능 경로가 저장소 전체인지 작업 범위인지 확인한다.
  5. 네트워크 접근이 기본 허용인지 확인한다.
  6. MCP 서버 목록을 확인한다.
  7. MCP 도구를 read/write/destructive로 나눈다.
  8. production 토큰을 MCP에 연결했는지 확인한다.
  9. 자동 승인 명령 목록을 확인한다.
  10. 삭제, 배포, 권한 변경 명령이 자동 승인되는지 확인한다.
  11. 프롬프트 원문 로그 저장 여부를 확인한다.
  12. tool input/output 로그 저장 여부를 확인한다.
  13. 팀 저장소라면 repo-specific config가 있는지 확인한다.
  14. 설정 변경이 리뷰 대상인지 확인한다.
  15. 최종적으로 “사고가 나면 어디까지 번지는가”를 적어본다.

마지막 질문이 제일 중요합니다.

보안 설정은 멋진 용어보다 blast radius를 줄이는 일입니다.

사고가 나도 작게 나게 만드는 것.

그게 현실적인 보안입니다.

이 글의 결론

AI 코딩툴 보안 설정은 하나의 스위치가 아닙니다.

MCP,

파일 권한,

네트워크,

승인 정책,

로그,

이 다섯 가지를 따로 나눠야 합니다.

가장 좋은 기본값은 “작게 열고, 필요할 때 넓히는 것”입니다.

read-only로 시작하고,

workspace-write로 좁게 수정하고,

네트워크와 MCP write는 승인으로 묶고,

secrets와 production은 차단하고,

로그는 운영 정보 중심으로 남깁니다.

이 정도만 해도 AI 코딩툴은 훨씬 안전해집니다.

생산성을 포기하는 방식이 아닙니다.

생산성이 망가지지 않게 울타리를 치는 방식입니다.

AI에게 일을 맡길수록, 사람은 더 잘 나눠야 합니다.

분업의 시대인데 권한도 분업해야죠.

관련 글

FAQ

AI 코딩툴을 쓰면 무조건 sandbox를 켜야 하나?

민감 코드나 팀 저장소라면 sandbox를 기본값으로 보는 편이 좋습니다.

다만 sandbox만으로 모든 위험이 사라지는 것은 아닙니다.

파일 권한, 승인 정책, 네트워크, MCP 도구 권한을 같이 봐야 합니다.

MCP 서버는 read-only면 안전한가?

read-only는 write나 destructive 도구보다 낮은 위험입니다.

하지만 읽는 데이터가 민감하면 여전히 위험합니다.

읽기 권한도 scope를 줄여야 합니다.

.env 파일을 AI가 읽게 하면 왜 위험한가?

.env에는 API key, DB URL, production token이 들어갈 수 있습니다.

AI가 그 파일을 읽으면 대화 문맥, tool output, 로그, 외부 호출 경로에 민감 정보가 섞일 위험이 커집니다.

자동 승인 기능은 쓰면 안 되나?

쓰면 안 되는 것이 아니라 좁게 써야 합니다.

테스트, 린트, 포맷 같은 반복 안전 작업은 자동화할 수 있습니다.

네트워크, 삭제, 배포, secrets 접근은 자동 승인에서 빼는 편이 안전합니다.

로그는 많이 남길수록 좋은가?

운영 이벤트는 남기는 것이 좋습니다.

하지만 프롬프트 원문과 tool output 전문은 민감 정보가 섞일 수 있습니다.

redaction, 보관 기간, 접근 권한을 함께 설계해야 합니다.

공식 출처/참고 자료