AI 에이전트에게 내 맥을 맡기기 전: RunOnMine이 보여준 권한 설계

핵심 요약 (TL;DR)

AI 코딩 에이전트가 편해질수록 질문은 ‘무엇을 만들 수 있나’에서 ‘어디까지 맡겨도 되나’로 옮겨갑니다. 최근 공개 프로젝트 RunOnMine은 이 질문에 흥미로운 경계를 제안합니다. AI와 내 컴퓨터 사이에 로컬 정책 층을 두고, 파일·터미널·브라우저·데스크톱 작업을 바로 실행하는 대신 허용, 로컬 승인, 거부로 나누는 방식입니다.

중요한 점은 특정 도구를 설치하라는 이야기가 아닙니다. 에이전트에게 권한을 줄 때 ‘신뢰한다’와 ‘전부 열어 둔다’는 같은 뜻이 아니라는 사실입니다.

왜 프롬프트만으로는 부족할까요?

‘중요한 파일은 건드리지 마세요’는 좋은 요청이지만, 시스템 경계는 아닙니다. 에이전트가 접근할 수 있는 폴더와 실행할 수 있는 명령이 넓다면 실수, 잘못된 자동화, 읽어서는 안 되는 외부 지시가 실제 행동으로 이어질 여지가 있습니다. RunOnMine의 README는 에이전트 요청마다 요청 주체, 호출 도구, 대상 자원, 로컬 승인이 필요한지를 검사한다고 설명합니다.

이 구조의 핵심은 권한을 요청 문장에만 맡기지 않는 것입니다. 선택한 디렉터리 안에서만 파일을 보게 하고, 명령 실행은 정책으로 평가하며, 민감한 행동은 사람이 승인하게 만듭니다. 어떤 구현을 쓰든 이 세 가지 원칙은 가져올 수 있습니다.

혼자 만드는 MVP에는 어떻게 적용할까요?

첫째, 작업 폴더를 분리하세요. 홈 디렉터리 전체를 연결하는 대신 프로젝트 하나만 열어 둡니다. 둘째, 비밀값은 코드와 분리하세요. .env 파일을 읽지 못하게 만들 수 없다면 최소한 실제 운영 키 대신 개발용 키로 시작합니다. 셋째, 위험도가 다른 행동을 구분합니다. 파일 읽기는 넓게 허용할 수 있어도 삭제, 배포, 결제 변경, 외부 메시지 전송은 사람 확인 뒤에 실행하는 편이 낫습니다.

넷째, 기록을 남기세요. AI가 어떤 파일을 수정했고 어떤 명령을 실행했는지 나중에 되짚을 수 있어야 합니다. 작업이 잘 됐을 때도 기록은 유용합니다. 다음 요청의 규칙이 되고, 문제가 생겼을 때 복구 경로가 됩니다.

도구를 쓰면 완전히 안전해지나요?

아닙니다. RunOnMine은 공개 베타(v0.1.0-beta.1)이며, README는 macOS 빌드가 Developer ID 서명이나 공증을 거치지 않았다고 명시합니다. 보안 도구 자체도 설치 전 출처, 릴리스, 권한을 확인해야 합니다. 또한 경계가 있어도 사람이 잘못된 권한을 넓게 설정하면 보호 효과는 줄어듭니다.

그래서 시작점은 거창한 보안 솔루션보다 ‘최소 폴더, 최소 권한, 중요한 작업 전 승인’입니다. 편리함을 포기하는 절차가 아니라, AI가 더 많은 일을 하도록 하되 되돌릴 수 있게 만드는 설계입니다.

FAQ: MCP를 쓰지 않으면 관계없는 이야기인가요?

아닙니다. MCP는 한 구현 방식일 뿐입니다. 에이전트에 파일, 터미널, 브라우저 권한을 주는 모든 환경에서 같은 질문이 필요합니다. 무엇에 접근할 수 있고, 누가 승인하며, 기록이 남는가를 확인하세요.

FAQ: 처음에는 무엇부터 바꾸면 될까요?

오늘 쓰는 에이전트의 작업 폴더부터 확인하세요. 프로젝트 폴더만 연결하고, 운영용 비밀값과 배포 권한은 별도 경로로 분리하는 것만으로도 시작이 됩니다.

출처: RunOnMine GitHub README 및 릴리스 안내
https://github.com/ademisler/RunOnMine
https://raw.githubusercontent.com/ademisler/RunOnMine/main/README.md
관찰 시점: 2026-08-10 KST