Cursor Auto-review 공개, Shell·MCP 자동 승인 실험

AI 요약

• 무슨 일: Cursor는 2026년 5월 29일 Auto-review Run Mode를 공개했습니다.
  • Shell, MCP, Fetch tool call을 allowlist, sandbox, classifier subagent, 사용자 승인으로 나눠 처리합니다.
• 의미: 장시간 코딩 에이전트의 병목이 "모델 응답"에서 실행 승인 정책으로 옮겨가고 있습니다.
• 주의점: Cursor docs는 classifier가 실수할 수 있으며 Auto-review는 security boundary가 아니다라고 경고합니다.
• 실무 영향: Enterprise 관리자는 Run Mode, sandbox networking, MCP protection, file deletion protection을 dashboard에서 조정해야 합니다.

Cursor는 2026년 5월 29일 changelog 3.6에서 Auto-review Run Mode를 공개했습니다. 기능 설명은 짧습니다. Cursor가 더 오래 작업하고, approval prompt를 덜 띄우고, 실행은 더 안전하게 하겠다는 것입니다. 하지만 실제 변화는 "프롬프트를 줄인다"보다 큽니다. Cursor agent가 Shell, MCP, Fetch tool call을 실행할 때 allowlist, sandbox, classifier subagent, 사용자 승인 중 어느 경로로 보낼지 결정하는 새 실행 정책입니다.

AI 코딩 에이전트가 길게 동작할수록 approval prompt는 제품 경험의 병목이 됩니다. npm test, pnpm build, rg, git diff처럼 반복 실행해야 하는 명령을 매번 물으면 agent는 장시간 작업을 끝내기 어렵습니다. 반대로 Shell과 MCP tool을 모두 자동 실행하면 파일 삭제, 외부 네트워크 접근, secret 노출, workspace 밖 수정 같은 위험이 커집니다. Cursor Auto-review는 이 둘 사이를 classifier subagent로 나누려는 시도입니다.

Auto-review가 처리하는 세 가지 도구

Cursor changelog는 Auto-review 적용 대상을 Shell, MCP, Fetch tool call로 명시합니다. Shell은 터미널 명령입니다. MCP는 외부 도구와 데이터 소스에 연결하는 표준 인터페이스입니다. Fetch는 웹 요청 계열 도구입니다. 이 세 범주는 코딩 에이전트가 단순 코드 편집기를 넘어 실제 작업 실행자로 바뀔 때 가장 먼저 위험해지는 표면입니다.

동작 경로는 네 갈래입니다. allowlisted call은 즉시 실행됩니다. sandbox로 실행 가능한 call은 sandbox 안에서 실행됩니다. 나머지 agent action은 classifier subagent로 넘어갑니다. classifier subagent는 그 call을 허용할지, 다른 접근을 시도하게 할지, 사용자의 승인을 요청할지 결정합니다. 사용자는 Settings > Cursor Settings > Agents > Run Mode에서 설정하고, classifier agent에 custom instructions를 줄 수 있습니다.

이 설계는 AI 코딩 도구의 승인 문제를 한 단계 더 제품화합니다. 예전에는 사용자가 승인하거나 거부했습니다. 이제는 모델 계열의 agent가 다른 agent의 도구 실행을 검토합니다. 사용자는 모든 호출을 직접 보지 않는 대신, allowlist와 sandbox 설정, classifier instruction, enterprise policy를 통해 위험 범위를 조정합니다.

Cursor 문서가 남긴 경고

Cursor Terminal docs는 changelog보다 더 중요한 문장을 담고 있습니다. 문서는 classifier가 non-deterministic이고 양방향 실수를 할 수 있다고 설명합니다. 안전한 call을 막을 수도 있고, 사용자가 막았을 call을 허용할 수도 있다는 뜻입니다. 문서는 Auto-review를 best-effort convenience로 취급하라고 경고하고, 엄격한 통제에는 Allowlist와 직접 승인을 쓰라고 적었습니다.

이 경고는 제품의 약점 고백이 아니라 정확한 책임선입니다. classifier subagent는 보안 경계가 아닙니다. 보안 경계는 sandbox, allowlist, network policy, file protection, enterprise admin control이어야 합니다. classifier는 approval fatigue를 줄이는 UX 장치에 가깝습니다. 개발팀이 Auto-review를 "자동 승인 보안 장치"로 이해하면 위험합니다.

OpenAI Codex, Claude Code, Cursor 같은 코딩 에이전트는 모두 같은 압력을 받습니다. 사용자는 agent가 오래 작업하길 원합니다. 제품은 tool call을 늘려야 합니다. 보안팀은 아무 명령이나 자동 실행하지 말라고 요구합니다. Auto-review의 등장은 Cursor만의 기능 출시가 아니라, agentic coding 제품들이 승인 정책을 별도 기능으로 팔기 시작했다는 신호입니다.

Sandbox와 allowlist가 실제 경계입니다

Cursor docs는 sandbox를 별도 섹션으로 설명합니다. sandboxed command는 파일 시스템과 네트워크 접근을 제한받습니다. network access는 sandbox.json Only, sandbox.json + Defaults, Allow All 같은 모드로 나뉩니다. 기본값은 사용자 allowlist에 Cursor의 built-in defaults를 더하는 방식으로 설명됩니다. 이 설정은 agent가 package manager, registry, API endpoint에 접근할 때 직접 영향을 줍니다.

allowlist도 두 종류입니다. Command Allowlist는 승인 없이 실행할 terminal command 목록입니다. MCP Allowlist는 승인 없이 실행할 MCP tool 목록입니다. Cursor docs는 mode에 따라 allowlist 명령이 sandbox 밖에서 실행될 수도 있고, allowlist 밖 명령이 sandbox 안에서 실행될 수도 있다고 설명합니다. 따라서 "allowlist에 넣는다"는 편의 설정이 아니라 권한 설계입니다.

개발팀은 allowlist를 "자주 쓰는 명령 모음"으로만 만들면 안 됩니다. git status, rg, ls, cat, pnpm test는 비교적 낮은 위험입니다. rm, curl | sh, cloud CLI, secret manager, deploy command, database migration command는 다릅니다. MCP tool도 마찬가지입니다. 문서 검색 MCP와 production database MCP를 같은 allowlist에 넣으면 Auto-review의 위험 표면이 커집니다.

Protection settings는 코딩 에이전트의 사고 유형을 반영합니다

Cursor docs의 protection settings에는 Browser Protection, File-Deletion Protection, Dotfile Protection, External-File Protection이 있습니다. Browser Protection은 browser tool 자동 실행을 막습니다. File-Deletion Protection은 파일 자동 삭제를 막습니다. Dotfile Protection은 .gitignore 같은 dotfile 자동 수정을 막습니다. External-File Protection은 workspace 밖 파일 생성 또는 수정을 막습니다.

이 항목들은 우연히 고른 목록이 아닙니다. 코딩 에이전트 사고는 대개 네 범주에서 발생합니다. 첫째, shell command가 예상보다 넓은 범위를 건드립니다. 둘째, 설정 파일이나 dotfile이 바뀌어 이후 작업 전체가 달라집니다. 셋째, workspace 밖 파일이나 secret이 건드려집니다. 넷째, browser나 network tool이 외부 시스템과 상호작용합니다. Cursor가 protection settings를 문서화했다는 점은 이런 사고 유형이 제품 설정으로 들어왔다는 뜻입니다.

이 설정은 개인 개발자보다 팀 환경에서 더 중요합니다. 개인 실험에서는 agent가 한 번 실수해도 local branch를 되돌리면 끝날 수 있습니다. 기업 repository에서는 agent가 dotfile, CI config, MCP server 설정, package lock, migration script를 바꾸면 다른 개발자와 배포 파이프라인에 영향을 줍니다. Auto-review를 켤 때는 "이 명령을 승인할까"보다 "이 종류의 변경은 자동화해도 되는가"를 먼저 정해야 합니다.

Enterprise controls는 Run Mode를 중앙 정책으로 만듭니다

Cursor docs는 Enterprise controls가 Enterprise subscription에서 제공된다고 설명합니다. 관리자는 web dashboard의 Settings > Run Mode에서 editor configuration을 override하거나 end user에게 보이는 설정을 조정할 수 있습니다. 항목에는 Run Mode controls, Sandboxing Mode, Sandbox Networking, Delete File Protection, MCP Tool Protection, Terminal Command Allowlist, Enable Run Everything이 포함됩니다.

이 목록은 AI 코딩 에이전트가 개인 생산성 도구에서 기업 정책 대상이 됐다는 사실을 보여줍니다. 예전 IDE 설정은 theme, keybinding, extension 정도가 중심이었습니다. 이제 enterprise admin은 agent가 network에 접근할 수 있는지, MCP tool을 자동 실행할 수 있는지, 파일 삭제를 자동화할 수 있는지, 모든 실행을 허용하는 mode를 사용자에게 줄지 정해야 합니다.

GitHub Copilot도 조직 정책과 model access를 다룹니다. OpenAI Codex도 sandbox와 approval을 제품 전면에 둡니다. Claude Code도 permissions와 plan별 실행 경계를 다룹니다. Cursor Auto-review는 이 경쟁 속에서 "agent가 일을 더 오래 하려면 승인 정책도 제품 기능이어야 한다"는 답을 내놓은 셈입니다.

Approval fatigue는 실제 제품 병목입니다

AI 코딩 에이전트는 작업을 잘게 쪼갭니다. 코드 검색, 파일 읽기, 테스트 실행, 빌드, 실패 로그 분석, patch, 재테스트가 반복됩니다. 각 단계가 사용자 승인에 막히면 agent는 긴 작업을 처리하기 어렵습니다. 사용자는 승인 버튼을 누르느라 피곤해지고, 어느 순간 위험한 명령도 습관적으로 승인할 수 있습니다. approval prompt가 많아지는 것이 항상 안전을 높이지는 않습니다.

Auto-review가 노리는 지점은 바로 이 피로입니다. 낮은 위험 call은 자동 처리하고, sandbox 가능한 call은 격리하고, 애매한 call은 classifier에게 검토시킵니다. 사용자는 정말 위험하거나 정책상 애매한 call에만 개입하게 됩니다. 이 구조가 잘 작동하면 agent는 더 오래 작업하고, 사용자는 더 적은 prompt를 봅니다.

하지만 classifier가 틀릴 수 있다는 점 때문에 이 구조는 보안 모델이 아니라 위험 완화 모델입니다. allowlist와 sandbox가 부실하면 classifier가 마지막 방어선처럼 보입니다. Cursor 문서가 "security boundary가 아니다"라고 못 박은 이유입니다. Auto-review를 켜기 전에 team policy, sandbox network access, MCP allowlist, file protection을 먼저 잡아야 합니다.

MCP 도구가 들어오면 승인 정책은 더 어려워집니다

MCP는 AI agent에게 외부 도구를 붙이는 표준 인터페이스로 빠르게 퍼졌습니다. Cursor도 MCP tool call을 Auto-review 대상에 넣었습니다. 문제는 MCP tool의 위험도가 매우 다르다는 점입니다. 문서 검색, issue 조회, 로그 읽기처럼 read-only 성격이 강한 tool이 있습니다. 반대로 ticket 수정, deploy trigger, database query, secret access, cloud resource 변경처럼 실제 시스템을 바꾸는 tool도 있습니다.

같은 "MCP call"이라도 보안 의미는 다릅니다. Auto-review가 MCP allowlist를 제공한다는 것은 팀이 tool 단위로 정책을 정해야 한다는 뜻입니다. MCP server 이름만 보고 허용하면 부족합니다. tool별 action, read/write 구분, 대상 환경, production 접근 여부, audit log 보존 여부를 봐야 합니다. agent가 MCP를 통해 더 많은 시스템에 닿을수록 Cursor의 Run Mode 설정은 개발 도구 설정이 아니라 접근 제어 설정에 가까워집니다.

Fetch도 작지 않은 표면입니다. agent가 웹에서 문서를 읽고 API를 호출하면 network allowlist와 prompt injection 위험이 같이 들어옵니다. 문서 페이지를 읽는 작업과 임의 URL에서 shell script를 받아 실행하는 작업은 다릅니다. Auto-review는 Fetch를 따로 언급함으로써 웹 접근도 단순 정보 검색이 아니라 실행 정책의 일부라는 점을 보여줍니다.

실무 팀이 정해야 할 기준

첫째, Run Mode 기본값을 업무 종류별로 나눠야 합니다. 개인 branch의 lint fix, test repair, 문서 정리에는 Auto-review가 유용할 수 있습니다. production migration, secret rotation, infrastructure config, database schema 변경에는 직접 승인과 더 엄격한 allowlist가 필요합니다. 같은 repository 안에서도 작업 종류에 따라 mode가 달라져야 합니다.

둘째, allowlist를 주기적으로 검토해야 합니다. 낮은 위험으로 보였던 명령도 project context에 따라 달라집니다. pnpm build는 보통 안전하지만 postinstall script가 있는 package graph에서는 network나 filesystem effect가 생길 수 있습니다. git 명령도 read-only 명령과 history rewrite 명령이 다릅니다. allowlist는 편의 설정이 아니라 정책 문서로 관리해야 합니다.

셋째, MCP tool을 read-only와 write-capable로 분리해야 합니다. 읽기 전용 문서 검색 MCP는 자동 실행 후보가 될 수 있습니다. Jira, GitHub, database, cloud provider처럼 쓰기 가능한 MCP는 별도 승인과 audit log가 필요합니다. Cursor Auto-review가 MCP Allowlist를 제공한다는 점은 MCP server 운영자가 tool metadata와 권한 모델을 더 명확히 해야 한다는 뜻이기도 합니다.

넷째, classifier instruction을 보안 정책으로 착각하지 말아야 합니다. custom instructions는 classifier가 판단할 때 참고하는 지시입니다. 하지만 non-deterministic model 판단입니다. "절대 삭제하지 마"라는 지시보다 File-Deletion Protection이 더 강한 경계입니다. "외부 파일 수정 금지"라는 지시보다 External-File Protection이 더 강한 경계입니다.

Cursor 3.6이 보여주는 다음 경쟁축

Cursor Auto-review Run Mode는 화려한 모델 발표가 아닙니다. 새 benchmark도 아니고, 수백만 토큰 컨텍스트도 아닙니다. 그러나 AI 코딩 에이전트 시장에서는 이런 기능이 점점 중요해집니다. agent가 더 오래 일하려면 명령 실행이 끊기지 않아야 합니다. agent가 실제 repository를 고치려면 tool call이 필요합니다. tool call이 늘어나면 승인 정책과 sandbox가 제품의 핵심 기능이 됩니다.

이 변화는 개발자 경험과 보안팀 요구가 같은 화면으로 들어오는 과정입니다. 개발자는 prompt가 줄어들길 원합니다. 보안팀은 자동 실행을 제한하길 원합니다. Cursor는 Auto-review로 그 사이에 classifier subagent를 넣었습니다. 하지만 Cursor 문서의 경고처럼 classifier는 편의 기능입니다. 실제 경계는 allowlist, sandbox, protection settings, enterprise controls입니다.

앞으로 코딩 에이전트를 비교할 때는 "어떤 모델을 쓰는가"만으로 부족합니다. Shell 권한을 어떻게 제한하는지, MCP tool을 어떻게 승인하는지, workspace 밖 파일을 막는지, dotfile 수정을 감지하는지, enterprise admin이 사용자의 Run Everything mode를 막을 수 있는지를 봐야 합니다. Cursor 3.6의 Auto-review는 이 질문을 제품 changelog 한 줄에서 전면으로 끌어낸 릴리스입니다.

출처

• Cursor Changelog, Auto-review Run Mode.
• Cursor Docs, Terminal.
• Cursor Changelog.
• Cursor Security.