블로그

Kimi Code 묻지 않기: 모드와 위험한 명령

Markdown

묻지 않기 모드에서 Kimi Code는 확인 없이 rm -rf와 shutdown을 실행합니다. 세 가지 모드는 어떻게 다르며, config.toml에서 위험한 명령을 금지하려면 어떻게 해야 할까요?

전체 글 읽기

Kimi Code의 묻지 않기 모드(/auto)는 모든 것을 자동으로 승인합니다. 질문 한 번 없이 rm -rf, shutdown, reboot를 실행합니다. 에이전트가 이 명령을 실행하기 전에 묻는 것은 나머지 두 모드인 항상 묻기와 필요할 때 묻기에서뿐입니다.

저는 Claude Code에서 “모두 허용”을 켜고 직접 작업합니다. 그렇지 않으면 계속 클릭만 하게 되니까요. 예, 예, 예. 하지만 열 번 중 한 번은 에이전트가 자기 방식대로 일을 처리합니다.

개인 프로토타입에도 중요한 파일과 자격 증명이 노출될 수 있습니다. 권한을 제한한 격리 사본이나 컨테이너와 검증된 백업을 사용하세요. 고객 시스템에서는 필요한 접근만 가진 별도 데이터베이스 계정도 부여하세요.

Kimi Code의 각 모드가 어떻게 작동하는지, 보호 기능이 어디서 작동하는지, 금지 규칙을 설정하는 방법을 살펴보겠습니다. 시작하죠.

서비스 사용 방법은 Ailoot 문서를 참고하세요.

핵심 요점

Kimi Code에는 모드가 3가지 있습니다. 기본 모드인 항상 묻기에서는 파일 읽기가 자동으로 이뤄지고, 그 밖의 모든 작업은 한 번에 하나씩 확인합니다. 필요할 때 묻기(/yolo)는 일반적인 수정은 자동 승인하지만, 키가 포함된 파일에 접근하거나 위험한 명령을 실행하거나 계획 모드를 종료하기 전에는 묻습니다. 묻지 않기(/auto)에서는 아무것도 묻지 않으며 위험한 명령 보호 기능도 작동하지 않습니다. ~/.kimi-code/config.toml에 deny 규칙을 추가해 영구적으로 금지할 수 있습니다. 실제 데이터베이스가 있는 환경에서는 묻지 않기를 켜지 않는 편이 좋습니다.

Kimi Code의 세 가지 모드는 어떻게 다른가요?

이미 Kimi Code를 설치했다면, 승인 패널을 본 적이 있을 겁니다. 에이전트가 파일을 수정하거나 명령을 실행하려고 하고, 당신의 “예”를 기다리는 패널입니다. 모드 이름은 Manual, YOLO, Auto였기 때문에 이전 명령어인 /yolo와 /auto가 아직도 사용됩니다.

항상 묻기. 기본 모드입니다. 에이전트는 묻지 않고 파일을 읽지만, 모든 수정과 명령을 각각 확인해야 합니다. 가장 느린 모드입니다.

필요할 때 묻기. /yolo로 켭니다. 일반적인 수정과 명령은 자동 승인하지만, .env(프로젝트의 비밀번호와 키가 들어 있는 파일)와 서버 SSH 키에 접근하기 전, shutdown(컴퓨터 종료)이나 rm -rf(휴지통을 거치지 않고 폴더 전체 삭제) 같은 위험한 명령을 실행하기 전, 그리고 계획 모드를 종료하기 전에는 묻습니다. 에이전트가 직접 질문할 수도 있습니다.

묻지 않기. /auto로 켭니다. 민감한 파일에 접근하거나 계획 모드를 종료하는 경우를 포함해 모든 작업이 자동 승인됩니다. 에이전트는 질문하지 않고 모든 것을 스스로 결정합니다.

Kimi Code의 세 가지 권한 모드 표: 항상 묻기, 필요할 때 묻기, 묻지 않기
Kimi Code CLI의 권한 모드 3가지.

계획 모드는 Shift-Tab 또는 /plan으로 별도로 켭니다. 에이전트가 먼저 계획을 작성하고 승인을 기다린 뒤 파일을 수정합니다.

제가 확인 없이 작업하는 경우

Claude Code에서 “모두 허용”은 새 채팅마다 켜 두는 기본 설정입니다. 이 설정이 없으면 바이브 코딩이 너무 느립니다. 바이브 코더는 이미 아는 것이 별로 없는데, 버튼까지 계속 눌러야 합니다. 예, 예, 예, 아니요, 아니요, 아니요.

하지만 이 모드에서는 에이전트가 데이터베이스를 지우는 것처럼 정말 무모한 짓도 할 수 있습니다. 그러고는 “죄송합니다, 정말 죄송합니다”라고 말하겠지만, 때로는 이미 벌어진 일을 되돌릴 수 없습니다. 그러니 이 모드는 겁 없는 사람을 위한 것이고, 책임은 본인에게 있습니다.

제 원칙은 이렇습니다. 개인 프로젝트, 실험, 프로토타입의 무확인 모드는 중요한 파일과 운영 자격 증명이 없고 권한이 제한되며 백업된 격리 사본이나 컨테이너 안에서만 검토하세요. 고객이 없어도 개인 파일과 키가 보호되지는 않으며 격리도 검증해야 합니다. 하지만 프로덕션 서버에 접근할 수 있는 프로젝트에서 이 모드를 켜면, 프롬프트 한 번만으로 에이전트가 밤사이에 데이터베이스를 삭제하고 실제 사이트에 변경 사항을 배포할 수 있습니다.

말로 금지해도 보호되지 않는 이유

많은 사람이 에이전트 지침에 “데이터베이스는 건드리지 마”라고 씁니다. 그 말이 당신을 지켜 줄 거라고 기대하지 마세요. “이쪽은 들어오지 마”라고 해도 에이전트는 들어와서 필요할 때 필요한 것을 가져갈 겁니다. 특히 중국산 Kimi는 당신이 설정한 금지 사항을 무엇이든 어길 겁니다. 미국 모델은 그렇게 하지 않도록 훨씬 더 잘 훈련되어 있습니다.

저는 업무에서 여전히 Kimi를 사용합니다. Kimi K3는 아주 꼼꼼해서, 프로젝트에 키가 노출됐는지 확인하고 정보를 수집하는 데 사용합니다. 한 번은 이틀 만에 사용 한도를 모두 소진했습니다. Kimi는 엇나가지 않고 요청한 일을 모두 합니다. 그래서 Kimi로 작업할 때는 격리가 필요합니다. 여기에서 제 작업으로 Kimi를 어떻게 시험했는지 설명했습니다.

두 가지 방식으로 격리해야 합니다.

  1. 설정의 명령 차단 목록. 일치하는 도구 호출을 막지만 한 명령 표기 패턴은 다른 도구나 동등 동작에 대한 완전한 경계가 아닙니다. 운영체제·컨테이너·데이터베이스 권한과 함께 사용하세요.
  2. 데이터베이스 읽기 전용 접근. 운영 데이터베이스에서는 에이전트에 읽기 전용 권한이 있는 별도의 사용자를 제공합니다. 그러면 묻지 않기 모드에서도 에이전트가 데이터베이스를 지울 수 없습니다.

위험한 명령 보호 기능은 어디서 작동하나요?

Kimi Code의 기본 위험 명령 보호 기능은 기본적으로 켜져 있습니다. 항상 묻기와 필요할 때 묻기 모드에서는 shutdown, reboot(다시 시작), rm -rf를 실행하기 전에 확인을 요청합니다. 묻지 않기에서는 이 명령들이 중단 없이 실행됩니다.

예외는 2가지입니다.

  • 임시 폴더 /tmp 또는 /temp의 내용만 삭제하는 경우 rm -rf는 확인 없이 실행됩니다(버전 0.43.0부터).
  • 필요할 때 묻기 모드에서는 Kimi Code가 미리 분석할 수 없는 터미널 명령에 대해 묻지 않습니다(버전 2.0.1부터).

버전 0.40.0의 Auto 모드는 위험한 명령을 차단했지만, 이 차단 기능은 0.41.0에서 제거됐습니다.

이전/현재: Kimi Code의 자율 모드는 위험한 명령을 차단했지만, 이제는 차단하지 않는다
0.40.0: Auto는 위험한 명령을 차단했다. 0.41.0: 차단 기능이 제거됐다.

설정 파일 ~/.kimi-code/config.toml의 [permission] 섹션에서 dangerous_command_guard = false를 지정하거나 KIMI_CODE_DANGEROUS_COMMAND_GUARD=false 변수를 설정해 보호 기능을 비활성화할 수 있습니다. 개발자들은 위험한 명령을 외부에서 이미 가로채는 환경에서만 이 설정을 끄도록 권장합니다.

Kimi Code에서 영구 금지 규칙을 설정하는 방법

에이전트가 무언가를 변경하려고 하면 Kimi Code가 승인 패널을 표시합니다.

  • 승인: 화살표 키와 Enter를 사용하거나 1, 2, 3을 바로 누릅니다.
  • 거부: Esc, Ctrl-C 또는 Ctrl-D를 누릅니다.
  • 이번 세션 동안 승인: 같은 종류의 호출을 세션이 끝날 때까지 승인합니다.
  • 영구 규칙: 설정 파일에 영구 허용 또는 거부 규칙을 추가합니다.

영구 규칙은 설정 파일 ~/.kimi-code/config.toml의 [[permission.rules]] 블록에 작성합니다. Kimi Code는 규칙을 순서대로 확인하고 처음 일치하는 규칙을 적용하므로, 허용 규칙보다 금지 규칙을 위에 두세요. 각 규칙에는 decision이 있으며, allow(즉시 허용), deny(즉시 거부), ask(매번 확인) 중 하나입니다.

rm -rf를 금지하고 다른 모든 터미널 명령은 확인을 요청하도록 설정하는 예시입니다.

[[permission.rules]]
decision = "deny"
pattern = "Bash(rm -rf*)"

[[permission.rules]]
decision = "ask"
pattern = "Bash"

터미널 명령의 패턴은 괄호 안에 넣습니다: Bash(command-pattern). 파일 읽기의 경우에는 Read(path-pattern)을 사용합니다. MCP 도구, AgentSwarm, 사용자 정의 도구는 전체 이름으로만 금지할 수 있습니다.

기술적인 내용을 잘 모르고 설정 파일을 열고 싶지 않다면, 아래 프롬프트를 에이전트에 붙여 넣으세요. 제한해야 할 항목을 에이전트가 직접 찾을 겁니다. 다만 작업 속도가 얼마나 느려질지 먼저 알려 달라고 하세요. 확인 없이 작업하는 데 익숙하다면 금지 규칙을 추가한 뒤 일부 기능이 작동하지 않을 수 있습니다. 다음은 제가 사용하는 프롬프트입니다.

내 프로젝트를 분석해 프로덕션 서버, 스테이징 데이터베이스, 프로덕션 키에 접근할 수 있는지 알려 줘. 접근할 수 있다면 위험한 명령에 대한 보호 기능을 설정해 줘. 전체 폴더 삭제, 변경 이력을 되돌릴 수 없게 다시 쓰는 명령, 프로덕션 데이터베이스에 직접 접근하는 명령을 금지해 줘. 먼저 “전 - 후” 형식으로 계획을 보여 주고, 작업 속도가 얼마나 느려질지도 솔직하게 알려 줘.

별도 문서에서 Claude Code에서 같은 설정을 하는 방법도 설명했습니다. Claude Code의 Auto 모드가 에이전트의 작업을 확인하는 방법도 살펴보세요.

어떤 모드를 선택해야 할까요?

  • 에이전트가 수행하는 모든 단계를 보고 싶은 경우: 기본 모드인 항상 묻기를 사용하세요. 읽기를 제외한 모든 작업을 확인합니다.
  • 실제 고객이 없는 개인 프로젝트나 프로토타입: Always Ask나 Ask When Needed로 시작하세요. Never Ask는 권한이 제한되고 중요한 데이터나 키가 없는 일회용 격리 사본에서만 검토하세요. 고객이 없다는 사실 자체가 안전을 주지는 않습니다.
  • 실제 고객이 있고 서버에 접근할 수 있는 프로젝트: 묻지 않기를 켜지 마세요. config.toml에 deny 금지 규칙을 설정하고 에이전트에는 데이터베이스 읽기 전용 접근 권한을 주세요.

그리고 데이터베이스는 프로젝트와 별도의 컴퓨터에 백업하세요. 다른 안전 규칙은 별도 문서에 정리했습니다.

확인 모드를 프로젝트의 접근 권한에 맞추고, 어디에 금지 규칙이 필요한지 확인하세요.

출처

Ailoot에 대해 알아보세요.

자세히 보기

Kimi Code 묻지 않기: 모드와 위험한 명령: 자주 묻는 질문

고객 없는 개인 프로젝트이면 Never Ask가 안전한가요?

아닙니다. 개인 파일을 손상하거나 키를 노출할 수 있습니다. 무확인 모드를 검토하기 전에 권한 제한, 일회용 격리 사본이나 컨테이너, 백업을 준비하세요.

rm -rf deny 규칙이 격리를 대신하나요?

아닙니다. 일치하는 호출만 막고 동등한 모든 파일 변경을 막지는 않습니다. 중요한 데이터와 운영 자격 증명을 접근 밖에 두고 작업에 필요한 권한만 가진 별도 데이터베이스 계정을 쓰세요.

모든 글