Roo Code 자동 승인 2026 안전한 설정 검수표

확인 요청이 너무 자주 뜨지만 자동 승인을 전부 켜기는 불안합니다.
가장 빠른 해법은 읽기부터 시작해 편집, 명령, 브라우저, MCP 도구 순서로 나누어 열고, 되돌릴 수 있는 작업만 허용 목록에 넣는 것입니다.

이 글은 반복 작업 때문에 Roo Code의 승인 요청에 자주 멈추는 개발자를 위한 내용입니다. 원격 개발 환경이나 클라우드 맥에서 장시간 실행하려는 팀, 에이전트 권한과 접속 열쇠를 검토하는 보안 및 플랫폼 담당자에게도 적합합니다.

자동 승인을 켜기 전에 위험 경계를 먼저 나눕니다

Roo Code의 권한은 하나의 안전 스위치가 아닙니다. 공식 문서에서는 읽기, 편집, 명령, MCP라는 도구 그룹을 구분하고 있으며, 모드에 따라 사용할 수 있는 도구가 달라집니다. 공식 도구 권한 설명에서도 코드 모드는 파일 수정과 명령 실행까지 사용할 수 있는 것으로 안내됩니다. (github.com)

먼저 다음 다섯 범주를 따로 평가해야 합니다.

• 읽기: 파일 목록, 검색, 문서 열람처럼 상태를 바꾸지 않는 작업입니다.
• 편집: 테스트 브랜치 안에서 수행하고 Git으로 되돌릴 수 있는 파일 수정입니다.
• 터미널 명령: 빌드와 테스트처럼 범위가 고정된 명령과 설치, 삭제, 배포 명령을 분리해야 합니다.
• 브라우저: 페이지 읽기와 외부 입력, 파일 업로드, 결제 또는 배포 동작을 같은 권한으로 취급하면 안 됩니다.
• MCP 도구: 데이터를 읽는 도구와 외부 시스템에 기록하거나 작업을 실행하는 도구를 분리해야 합니다.

기본적으로 접속 열쇠 읽기, 시스템 폴더 변경, 배포, 데이터 삭제, 권한 변경은 수동 승인을 유지해야 합니다. 샌드박스나 원격 환경도 잘못된 명령, 프롬프트 주입, 유출된 접속 열쇠까지 모두 없애 주지는 않습니다.

주의: 자동 승인은 “모델이 안전한 결정을 한다”는 뜻이 아니라 “특정 조건을 만족한 요청을 바로 실행한다”는 뜻입니다. 허용 범위가 넓으면 모델의 실수도 넓은 권한으로 실행됩니다.

1단계는 읽기와 제한된 편집만 허용합니다

처음부터 일상 저장소 전체를 열지 말고 별도의 테스트 저장소와 테스트 브랜치를 사용합니다. 이 단계의 목표는 Roo Code가 실제로 어디까지 볼 수 있고, 어디까지 수정할 수 있는지 확인하는 것입니다.

다음 순서로 점검합니다.

1. 작업 폴더를 새 테스트 저장소로 복제합니다.
2. 허용 폴더를 저장소 내부의 특정 경로로 제한합니다.
3. 비밀 파일, 배포 설정, 개인 설정 파일을 별도 경로로 옮깁니다.
4. 작은 문서와 테스트 파일만 수정하게 합니다.
5. 변경 뒤 git diff로 예상하지 않은 파일이 포함되지 않았는지 확인합니다.
6. 작업을 중단한 뒤 Git으로 원상 복구합니다.
7. 저장소 밖의 경로와 링크를 따라간 요청을 일부러 보내고 거부되는지 기록합니다.

합격 조건은 세 가지입니다. 허용한 폴더 안에서만 수정되고, 저장소 밖의 파일 접근이 거부되며, 편집 실패 뒤 변경 사항을 명확히 되돌릴 수 있어야 합니다. 권한 설정 화면, 변경 내역, 거부 기록을 함께 보관해야 합니다.

중단 조건도 분명히 정합니다. 작업 폴더 밖의 파일이 바뀌거나, 숨김 설정과 접속 열쇠가 출력되거나, 되돌리기 전후의 차이를 확인할 수 없다면 다음 단계로 넘어가지 않습니다.

2단계에서 터미널 명령을 대표 사례로 검수합니다

Roo Code가 터미널 명령을 자동 실행할 때의 위험

터미널 명령은 파일 편집보다 위험도가 높습니다. 명령 자체가 짧아도 변수, 현재 폴더, 재귀 옵션, 파이프 연결에 따라 작용 범위가 달라질 수 있습니다. 예를 들어 테스트 명령은 실패해도 작업 폴더를 크게 바꾸지 않지만, 정리 스크립트와 의존성 설치 명령은 네트워크와 파일 시스템을 동시에 건드립니다.

다음 네 가지를 각각 따로 실행해 봅니다.

• 빌드: 출력 경로가 테스트 폴더 안으로 제한되는지 확인합니다.
• 단위 테스트: 실패 시 파일과 데이터베이스가 바뀌지 않는지 확인합니다.
• 의존성 설치: 외부 저장소, 설치 스크립트, 실행 후크가 함께 작동하는지 확인합니다.
• 정리 스크립트: 삭제 대상이 현재 저장소와 임시 폴더로 한정되는지 확인합니다.

허용 목록에는 예측 가능하고 반복 실행해도 결과가 크게 달라지지 않으며, 실패 뒤 복구할 수 있는 명령만 넣습니다. 배포, 삭제, 권한 변경, 접속 열쇠 출력, 원격 명령 실행은 별도의 수동 승인으로 남겨야 합니다.

공식 명령줄 사용법에는 수동 승인을 요구하는 실행 방식이 따로 제공되며, 기본 대화형 실행에서는 도구와 명령이 자동 승인될 수 있다고 설명합니다. 따라서 개인 컴퓨터와 무인 실행 환경을 같은 설정으로 복제하지 않는 것이 안전합니다. 공식 명령줄 승인 안내를 배포 전에 확인해야 합니다. (github.com)

자동 승인 범위를 결정하는 비교 기준

이 표에서 “자동 승인 후보”는 바로 켜라는 뜻이 아닙니다. 테스트 환경에서 증거를 만든 뒤 허용할 수 있는 후보입니다. 한 단계라도 합격 증거가 없으면 이전 단계의 권한으로 돌아가야 합니다.

3단계에서 MCP 도구를 서버와 도구 단위로 나눕니다

Roo Code MCP 도구 허용 목록은 어떻게 구성해야 하나요

MCP 서버가 믿을 만하다는 이유만으로 그 서버의 모든 도구를 허용해서는 안 됩니다. 한 서버 안에도 조회, 기록, 삭제, 외부 요청, 민감 자료 접근 기능이 함께 들어갈 수 있습니다.

먼저 각 도구를 다음 네 가지로 분류합니다.

1. 읽기 전용 조회
2. 테스트 저장소에만 쓰기
3. 외부 시스템에 기록하거나 작업 실행
4. 접속 열쇠, 개인 자료, 운영 데이터 접근

첫 번째 범주만 낮은 위험 후보로 둡니다. 두 번째 범주는 테스트 계정과 제한된 저장소에서만 검수합니다. 세 번째와 네 번째 범주는 기본적으로 수동 승인으로 남깁니다.

MCP의 전체 사용 설정과 개별 도구의 자동 허용 설정을 따로 확인해야 합니다. 설정 파일에 특정 도구 이름을 자동 허용하는 방식이 쓰일 수 있으므로, 서버를 켠 뒤 실제 도구 목록과 설정된 이름이 일치하는지 비교합니다. 공식 MCP 사용 문서와 설정 예시를 기준으로 서버 범위, 도구 이름, 입력값, 접속 열쇠 출처, 철회 방법을 기록합니다. (github.com)

경험칙: MCP 도구의 입력값에 경로, 주소, 식별자, 삭제 조건이 들어간다면 도구 이름만 보고 읽기 전용으로 분류하지 마십시오. 실제 입력 범위까지 확인해야 합니다.

4단계는 원격 개발 환경에서 격리와 복구를 검증합니다

무인 실행에는 격리 환경이 필요한가요

무인 실행이나 장시간 실행에는 별도 환경이 필요합니다. 여기서 격리는 단순히 다른 컴퓨터를 쓰는 것보다 넓은 개념입니다. 저장소 권한, 네트워크 출구, 접속 열쇠, 로그, 종료 조건을 일상 개발 환경과 분리해야 합니다.

원격 개발 환경이나 클라우드 맥에서 다음 검사를 진행합니다.

1. 테스트 저장소만 복제하고 운영 저장소의 쓰기 권한은 제거합니다.
2. 필요한 외부 주소만 네트워크 허용 목록에 넣습니다.
3. 접속 열쇠는 작업 파일에 저장하지 않고 실행 시점에 주입합니다.
4. 정상적으로 되돌릴 수 있는 작업을 한 번 실행합니다.
5. 저장소 밖 파일 수정과 금지된 MCP 호출을 일부러 요청합니다.
6. 거부 기록, 명령 로그, 변경 내역을 저장합니다.
7. 시간 초과와 중단 신호가 실제 프로세스를 끝내는지 확인합니다.

Xcode나 맥 운영 체제 도구 체인이 필요한 작업은 일반 컨테이너의 검사 결과를 그대로 적용하면 안 됩니다. 서명 키, 시뮬레이터, 키체인, 화면 접근 권한처럼 맥 환경에만 존재하는 자원을 별도로 점검해야 합니다. 원격 맥 접속과 계정 관리가 필요한 경우에는 SSHMac 도움 센터의 원격 환경 안내도 함께 확인할 수 있습니다.

합격 기준은 정상 작업이 복구되고, 권한 범위 밖의 요청이 차단되며, 로그에 누가 언제 어떤 명령과 도구를 실행했는지 남는 것입니다. 하나라도 확인할 수 없으면 무인 실행을 중단하고 수동 승인으로 되돌립니다.

5단계에서 장기 운영 권한을 다시 줄입니다

첫 설정이 통과했다고 권한을 영구히 유지하면 안 됩니다. 다음 변화가 생길 때마다 재검수해야 합니다.

• Roo Code 확장이나 명령줄 도구를 업데이트한 경우
• MCP 서버나 서버 설정을 바꾼 경우
• 저장소의 설치, 빌드, 정리 스크립트를 수정한 경우
• 새로운 접속 열쇠를 추가한 경우
• 작업 폴더와 네트워크 출구를 바꾼 경우

공식 문서에는 자동 승인 요청 수를 제한하는 설정이 있으며, 일정 횟수 뒤 다시 승인을 요구하도록 구성할 수 있습니다. 장시간 작업에서는 무제한보다 제한된 요청 수가 검수 지점을 만들어 줍니다. 자동 승인 요청 수 제한 안내를 확인해 작업 길이에 맞는 중단 지점을 정하십시오. (github.com)

권한 판단은 다음처럼 운영합니다.

• 로그와 복구가 모두 정상이라면 같은 범위에서 유지합니다.
• 명령은 안전하지만 파일 범위가 넓어졌다면 허용 경로를 줄입니다.
• 예상하지 않은 파일이나 네트워크 요청이 발견되면 해당 도구만 철회합니다.
• 접속 열쇠가 로그에 나타났다면 전체 자동 승인을 끄고 열쇠를 교체합니다.
• MCP 서버가 바뀌었는데 도구 목록을 다시 확인하지 않았다면 사용을 보류합니다.

Roo Code 프로젝트의 보안 권고에는 MCP 설정 파일에 명령 실행 구성이 포함될 수 있고, 자동 승인된 파일 쓰기와 결합될 경우 임의 코드 실행 위험이 생길 수 있다고 설명되어 있습니다. 과거 권고에서는 영향을 받은 버전과 수정 버전도 구분되어 있으므로, 사용 중인 버전과 공식 저장소의 보안 공지를 함께 대조해야 합니다. 공식 보안 권고를 안전 결론의 근거로 삼으십시오. (github.com)

최종 점수로 운영 여부를 결정합니다

다음 다섯 항목을 각각 0점 또는 1점으로 평가합니다.

• 허용 경로가 작업 폴더 안으로 제한되었습니다.
• 명령별 입력 범위와 실패 결과를 확인했습니다.
• MCP 도구별 허용 목록과 접속 열쇠 출처를 기록했습니다.
• 금지 요청이 차단되고 로그에 남았습니다.
• 정상 작업을 Git 또는 별도 복구 절차로 되돌렸습니다.

5점이면 테스트 환경에서 제한적인 자동 승인을 유지할 수 있습니다. 3~4점이면 읽기와 검증 명령만 남기고 편집 또는 MCP 쓰기 권한을 줄입니다. 0~2점이면 자동 승인을 끄고 원인을 수정한 뒤 처음부터 다시 검수합니다. 이 점수는 공식 안전 보증이 아니라 운영 결정을 일정하게 만들기 위한 내부 도구입니다.

일상 작업을 개인 맥이나 기존 원격 서버에서 계속 실행하면 저장소 권한, 접속 열쇠, 브라우저 세션이 한 공간에 섞이는 문제가 남습니다. 직접 관리하는 환경은 장기 고정 부하와 물리 장치 접근에는 유리하지만, 매번 격리 환경을 만들고 폐기하기 어렵고 장애 시 복구 절차도 직접 운영해야 합니다. 반면 SSHMac에서 맥 환경을 임시로 빌리면 테스트용 원격 작업 공간을 일상 개발 환경과 분리하기 쉬워집니다. 다만 장기간 같은 자원을 계속 쓰거나 특정 물리 장치가 반드시 필요한 경우에는 직접 구매나 고정 서버가 더 적합합니다.

따라서 먼저 이 글의 단계별 검수 절차를 복제해 낮은 위험 작업을 한 번 실행하십시오. 로그, 권한 범위 밖 요청 차단, 롤백이 모두 확인된 뒤에만 Roo Code 자동 승인 범위를 넓히는 것이 안전합니다. 필요한 경우 SSHMac의 맥 원격 환경 안내를 참고해 격리된 테스트 공간부터 구성하는 편이 낫습니다.