서버에서 Claude Code 안전하게 실행하는 방법

서버에서 Claude Code를 안전하게 실행한다는 것의 의미

서버에서 Claude Code를 안전하게 실행하려면 권한 확인 프롬프트를 켜두고, 전용 비권한(unprivileged) 사용자로 실행하며, 자동화된 작업에는 신뢰 대신 실질적인 경계(내장 샌드박스, 컨테이너, 혹은 중요 데이터가 없는 일회용 VPS)를 설정해야 합니다. --dangerously-skip-permissions 플래그는 모델과 셸 사이의 승인 단계를 생략합니다. 자동화된 작업에서는 이 방식이 합리적일 수 있으나, 잘못된 명령 하나가 미칠 수 있는 영향을 제한하는 경계 안에서만 허용해야 합니다. 이 가이드는 해당 플래그가 실제로 무엇을 변경하는지, 그리고 격리 수준을 단계별로 높여가며 어떻게 경계를 구축하는지 설명합니다.

Claude Code가 로컬 환경에서 수행할 수 있는 작업

Claude Code는 터미널에서 실행되는 코딩 에이전트입니다. 이 도구는 실행한 사용자의 권한으로 파일을 읽고, 작성하며, 셸 명령어를 실행합니다. 이것이 바로 이 도구의 핵심 가치입니다. 사용자가 일일이 명령어를 입력하지 않아도 저장소를 복제하고, 코드를 수정하고, 테스트를 실행하며, 실패 원인을 파악하고, 코드를 수정하는 과정을 반복할 수 있습니다. 서버에 아직 설정하지 않았다면 tmux를 사용하여 VPS에서 Claude Code 실행하기를 통해 설치 및 세션 관리 방법을 확인하십시오. 이 페이지에서는 설치 후 이 도구에 부여되는 권한에 대해 설명합니다.

위험성은 앞서 언급한 내용과 동일합니다. 사용자의 권한으로 셸 명령어를 실행하는 프로세스는 사용자가 할 수 있는 모든 작업을 수행할 수 있습니다. 이 도구는 ~/.ssh/id_ed25519, ~/.aws/credentials, 그리고 사용자가 열 수 있는 모든 .env 파일을 읽을 수 있습니다. 또한 curl를 실행하여 서버가 접근할 수 있는 모든 호스트로 데이터를 전송할 수 있습니다. git push --force을 실행하는 것도 가능합니다. 에이전트 자체에는 고유한 동기가 없습니다. 위험은 작업이 잘못되거나, 작업 중에 읽은 텍스트에 타인이 작성한 지시 사항이 포함되어 있을 때 발생합니다. 예를 들어, 가져온 웹 페이지나 수정 요청이 들어온 이슈의 댓글 등이 이에 해당합니다. 후자의 경우를 프롬프트 인젝션(prompt injection)이라고 하며, "모델은 보통 합리적이다"라는 생각이 보안 계획이 될 수 없는 이유가 바로 이것입니다. 지시 사항은 더 가까운 곳에서도 전달될 수 있습니다. 동일한 서버에서 두 개의 Claude Code 세션이 서로 텍스트를 주고받을 수 있기 때문이며, 다른 세션에서 온 메시지는 수신하는 에이전트에게는 그저 읽어야 할 또 다른 텍스트일 뿐입니다. 보안 계획은 평균적인 상황이 아니라 최악의 상황을 대비하여 수립해야 합니다.

권한 시스템의 이해

기본 설정에서 Claude Code는 작업을 수행하기 전에 사용자에게 확인을 요청합니다. 프로젝트 내부 파일을 읽는 작업은 조용히 진행되지만, 파일을 수정하거나 셸 명령어를 실행할 때는 수정 내용이나 명령어를 먼저 보여주고 사용자의 승인을 기다립니다. 사용자는 단일 작업을 승인하거나, 해당 세션 동안 동일한 유형의 작업을 모두 승인할 수 있습니다. 이러한 승인은 세션 단위로 적용되므로, CLI를 종료하고 새로 시작하면 다시 신중한 상태로 돌아갑니다. 영구적으로 적용하고 싶은 규칙은 설정 파일에 허용(allow), 확인(ask), 거부(deny) 목록으로 저장할 수 있습니다. 예를 들어 git status은 허용하고, git push는 확인하며, .env에 대한 읽기는 거부하도록 설정할 수 있습니다. 거부 규칙이 항상 우선합니다. 2026년 8월 14일부터는 자동 모드가 기본값이 되므로, 관리자가 직접 모니터링할 수 없는 서버에서 어떤 모드를 실행할지 결정하기 전에 각 권한 모드가 실제로 허용하는 범위를 파악해 두는 것이 좋습니다.

이 설계는 사람이 터미널을 지켜보고 있다는 전제하에 만들어졌으며, 노트북 환경에서는 실제로 그렇습니다. 하지만 서버 환경에서는 아무도 지켜보지 않는 경우가 많습니다. tmux 안에서 긴 작업을 시작하고 잠들었는데, 에이전트가 새벽 2시에 질문을 던지느라 멈춰 있다면 아침까지 아무런 진전이 없을 것입니다. 이러한 대기 시간은 비용과 시간을 낭비하게 만듭니다. 유휴 상태의 Claude Code 세션은 프롬프트 캐시를 잃게 되어 다음 작업 시 이를 다시 구축하는 비용이 발생하기 때문입니다. 이것이 서버 환경에서 사용자들이 skip 플래그를 찾는 현실적인 이유이며, 이 플래그가 해결하려는 문제는 분명합니다. 이 가이드의 나머지 부분에서는 모든 안전장치를 포기하지 않으면서 이 문제를 해결하는 방법을 다룹니다.

--dangerously-skip-permissions 옵션의 변경 사항

claude --dangerously-skip-permissions 옵션은 승인 단계를 비활성화합니다. 편집 작업은 확인 메시지 없이 즉시 수행됩니다. 셸 명령도 확인 절차 없이 실행됩니다. 민감한 경로를 보호하기 위해 평소 작동하던 경로 검사 기능도 건너뜁니다. 명시적인 거부 규칙은 여전히 적용되며, 극히 일부의 위험한 작업은 여전히 중단 후 확인을 요청하지만, 작동 원리는 단순합니다. 모델이 실행하기로 결정한 모든 작업이 그대로 수행됩니다.

서버 환경에서 이 플래그를 사용할 때 알아야 할 두 가지 사실이 있습니다. 첫째, Linux 및 macOS에서 Claude Code를 root 계정으로 실행하거나 sudo를 통해 실행할 경우 이 플래그는 차단됩니다. root 권한으로 확인 절차 없이 실행되면 시스템의 모든 파일이나 서비스를 변경할 수 있기 때문입니다. 에이전트는 어차피 고유한 비권한 계정으로 실행되어야 하며, 이 플래그는 해당 원칙을 강제합니다. 둘째, 이 플래그는 모델의 동작 방식 자체를 변경하지 않습니다. 단지 루프에서 인간을 제외할 뿐이며 다른 것은 아무것도 바꾸지 않으므로, 확인 절차를 통해 걸러낼 수 있었던 모든 실수가 그대로 실행됩니다.

따라서 솔직한 계산은 다음과 같습니다. 권한 확인을 건너뛰면 보안 질문은 "에이전트가 나쁜 행동을 할 것인가"에서 "한 번의 잘못된 행동으로 얼마나 큰 피해가 발생할 수 있는가"로 바뀝니다. 모든 결정을 통제하려 하기보다 피해 범위(blast radius)를 제어하는 방향으로 전환해야 합니다. 이에 대한 해답은 격리이며, 이는 단계별로 적용됩니다.

내장된 Claude Code 샌드박스

단계별 지침을 확인하기 전에, Claude Code가 이제 실행하는 명령어를 위한 OS 수준의 샌드박스를 제공하며, 사용자가 skip 플래그를 사용하던 대부분의 이유를 제거했다는 점을 알아두십시오. Linux 환경에서는 파일 시스템 격리를 위해 bubblewrap을 사용하며, 네트워크 트래픽을 프록시로 라우팅하기 위해 socat을 사용합니다. 샌드박스 내부에서 명령어는 프로젝트 디렉터리와 세션 임시 디렉터리에만 쓰기가 가능하며, 허용 목록(allow list)을 통해 모든 도메인을 검사하는 프록시를 통해서만 네트워크에 접근할 수 있습니다. 명령어가 새로운 도메인에 처음 접근하려고 할 때 Claude Code가 사용자에게 승인을 요청합니다.

세션 내에서 /sandbox 명령어를 사용하여 기능을 활성화하십시오. Ubuntu 및 Debian에서는 먼저 필요한 두 가지 패키지를 설치해야 합니다.

sudo apt install bubblewrap socat

Ubuntu 24.04 이상 버전에서는 기본 AppArmor 정책이 bubblewrap의 사용자 네임스페이스 생성을 차단합니다. 샌드박스 패널은 누락된 항목이 있을 때 이를 알려주며, Claude Code 샌드박싱 문서에는 이를 해결하기 위한 짧은 AppArmor 프로필이 포함되어 있습니다.

샌드박스에는 자동 허용(auto-allow) 모드가 있습니다. 강제된 경계가 기존의 프롬프트 역할을 대신하므로 샌드박스 내의 명령어는 별도의 프롬프트 없이 실행됩니다. 샌드박스 내부에서 실행할 수 없는 명령어는 일반적인 권한 흐름으로 돌아가므로, 정말로 이례적인 작업은 여전히 승인을 요청합니다. 대부분의 서버 워크플로우에서 이는 skip 플래그를 대체하는 올바른 방법입니다. OS가 강제하는 경계를 사용하면 프롬프트를 완전히 제거하는 대신 질문 횟수를 훨씬 줄일 수 있기 때문입니다.

샌드박스의 한계를 명확히 인지하십시오. 기본적으로 샌드박스 내의 명령어는 특정 경로를 거부하지 않는 한 자격 증명 파일을 포함한 대부분의 파일 시스템을 읽을 수 있습니다. sandbox.credentials 설정은 바로 이를 위해 존재합니다. 네트워크 프록시는 도메인 이름을 검사할 뿐 트래픽 자체를 검사하지는 않으므로, github.com과 같이 광범위한 허용은 여전히 데이터를 외부로 유출할 여지를 남깁니다. 샌드박스 내부에서는 Docker가 작동하지 않습니다. 샌드박스는 보안 수준을 크게 높여주지만 완벽한 격리 경계는 아니며, 이것이 아래의 단계들이 여전히 중요한 이유입니다.

격리 단계

격리 수준을 높이는 세 가지 단계입니다. 서버에서 운영 중인 다른 서비스와 환경을 고려하여 가장 낮은 단계부터 선택하십시오.

1단계: 전용 비권한 사용자. 에이전트에 별도의 계정, 홈 디렉터리, 프로젝트 디렉터리를 할당하고 sudo 권한을 부여하지 않습니다.

sudo adduser --disabled-password --gecos "" agent

계정 경계를 설정하면 에이전트가 사용자의 파일, SSH 키, 서버 내 다른 프로젝트에 접근할 수 없습니다. 또한 이 방식은 root 권한으로 실행할 수 없는 skip 플래그를 사용할 수 있게 합니다. 이는 모든 서비스를 비권한 사용자로 실행하기 원칙을 에이전트에 적용한 것입니다. 1단계에서 제한하지 못하는 범위는 네트워크와 서버 내의 모든 읽기 가능한 파일입니다.

2단계: 컨테이너. Anthropic은 Claude Code를 비권한 사용자로 실행하는 참조 devcontainer를 제공합니다. 직접 빌드한 컨테이너도 동일한 역할을 수행하며, 방화벽 규칙을 통해 에이전트가 접근할 수 있는 호스트를 제한합니다. 파일 시스템은 마운트된 볼륨으로 축소되고, 외부 통신은 컨테이너 규칙에 따라 제한됩니다. 서버에서 다른 중요한 서비스를 운영 중일 때 적합한 중간 단계입니다. 컨테이너는 호스트 커널을 공유하므로, 잘못된 마운트 설정 하나로 경계가 무너질 수 있다는 한계가 있습니다. 컨테이너에 /var/run/docker.sock 권한을 부여하면 호스트 전체에 접근할 수 있게 됩니다.

3단계: 전용 VPS. 가장 강력하고 확실한 단계는 에이전트에게 중요한 데이터가 없는 별도의 서버를 할당하는 것입니다. 소규모 VPS는 월 몇 달러 수준입니다. 새 VPS 초기 설정 10분 가이드에 따라 서버를 구성하고 깨끗한 상태를 스냅샷으로 저장한 뒤 에이전트를 실행하십시오. 해당 서버에는 개인 SSH 키, 클라우드 자격 증명, 운영 데이터 등 중요한 정보를 두지 않습니다. 오직 해당 저장소에만 접근 가능한 배포용 키(deploy key)만 사용합니다. 작업이 잘못되거나 초기화가 필요할 때 스냅샷을 복원하거나 서버를 삭제하고 다시 구축하는 데 몇 분이면 충분합니다. 피해 범위는 해당 서버로 한정됩니다. 이 환경에서는 --dangerously-skip-permissions가 더 이상 위협적이지 않습니다. 최악의 경우에도 서버를 재구축하고 토큰 하나를 폐기하는 것으로 해결되기 때문입니다.

이 단계들은 중첩하여 적용할 수 있습니다. 일회용 VPS에서 비권한 사용자로 실행되는 샌드박스형 에이전트는 추가 비용이 거의 들지 않으며, 보안 사고의 위험을 최소화합니다. 지루할 정도로 안전한 상태를 유지하는 것이 목표입니다.

자격 증명 보호

다른 모든 보안 조치의 기반이 되는 규칙은 다음과 같습니다. 에이전트 사용자는 다른 서비스에 속한 비밀 정보를 읽을 수 없어야 합니다.

API 키는 에이전트에게만 제공하십시오. 해당 키를 에이전트 사용자가 소유하고 모드가 600인 파일에 저장한 뒤, 셸이 시작될 때 불러오도록 설정하십시오.

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

그다음 반대 방향의 접근을 차단하십시오. Debian과 Ubuntu에서는 홈 디렉터리가 시스템의 모든 사용자에게 읽기 권한이 부여된 상태로 생성되는 경우가 많으므로, chmod 750 /home/youruser 명령을 사용하여 권한을 강화하십시오. ls -ld /home/* 명령으로 확인한 뒤, 에이전트 계정이 목록을 조회할 수 있는 모든 항목을 수정하십시오.

모든 토큰의 범위를 제한하십시오. 단일 저장소로 제한된 세밀한 GitHub 토큰이나 저장소별 배포 키를 사용하면, 자격 증명이 유출되더라도 전체 계정이 아닌 하나의 프로젝트만 피해를 입게 됩니다. 샌드박스를 사용하는 경우, ~/.ssh 및 ~/.aws 명령조차 읽기 권한이 거부되도록 자격 증명 설정을 추가하십시오. 또한 운영 환경의 자격 증명은 서버에 아예 두지 마십시오. 애초에 존재하지 않는 비밀 정보는 에이전트가 유출할 수 없기 때문입니다. 만약 이러한 비밀 정보를 자체 호스팅하는 비밀번호 관리자에 저장한다면, 에이전트와는 다른 서버에 배치하고 별도의 검토를 수행하십시오. Vaultwarden의 취약점은 암호화된 볼트 자체가 아니라 관리자 토큰과 백업 파일에 있기 때문입니다.

Git은 안전망입니다

에이전트가 수행하는 모든 변경 사항은 검토 및 되돌리기가 가능해야 하며, 에이전트가 브랜치에서 작업한다면 Git은 이 두 가지 기능을 기본적으로 제공합니다.

git switch -c agent/refactor-auth

git diff main...agent/refactor-auth를 사용하여 실행 결과를 검토하고, 유효한 변경 사항은 병합하며, 실행 결과가 만족스럽지 않다면 브랜치를 삭제하십시오. 3개의 파일을 수정한 실행 결과는 모듈 절반을 다시 작성한 결과보다 아침에 확인하기 훨씬 수월하며, 이는 작동하는 가장 작은 변경 단위로 에이전트를 제어하는 기술을 실천하는 근거가 됩니다. 코드 저장소 측에서 메인 브랜치를 보호하여 에이전트의 토큰이 해당 브랜치에 푸시하거나 어디에도 강제 푸시(force-push)할 수 없도록 설정하십시오. 커밋 기록은 사용자가 잠든 사이에 발생한 일을 보여주는 감사 로그 역할을 하며, 이는 터미널의 스크롤 기록보다 훨씬 가치 있습니다.

네트워크는 폭발 반경의 일부입니다

에이전트는 curl를 실행할 수 있습니다. 이 문장이 이그레스(egress) 문제의 핵심입니다. 에이전트가 읽을 수 있는 모든 것은 외부로 전송될 수 있으며, 프롬프트 인젝션을 당한 에이전트라면 실제로 그렇게 할 수 있습니다. 일반적인 권한 없는 사용자는 이를 전혀 제한하지 못합니다. 서버가 도달할 수 있는 모든 곳에 사용자도 도달할 수 있기 때문입니다. 샌드박스는 프록시를 통해 도메인 단위로 이를 제한합니다. 컨테이너는 자체 방화벽 규칙으로 이를 제한할 수 있습니다. 전용 VPS는 애초에 유출될 데이터 자체를 격리하므로, 이 세 가지 방법 중 가장 강력한 대응책입니다.

ufw만으로 이그레스 문제를 해결하려 하지 마십시오. ufw는 기본적으로 모든 나가는 트래픽을 허용하며, apt, npm, git, Claude API는 허용하면서 나머지는 차단하는 아웃바운드 규칙을 작성하는 것은 매우 번거롭고 조용히 실패하기 쉽습니다. 대신 샌드박스, 컨테이너, 또는 머신 수준에서 경계를 설정하십시오. 도메인 허용 목록을 사용하거나 아예 격리된 머신을 사용하는 것이 훨씬 깔끔한 해결책입니다.

Claude Code를 실행하는 대신 API를 사용하여 직접 에이전트를 구축하는 경우에도 동일한 사고방식이 적용됩니다. VPS에서 Claude로 AI 에이전트 구축하기에서 해당 경로를 다루고 있으며, 그 에이전트 역시 동일한 전용 사용자, 동일한 범위로 제한된 토큰, 그리고 동일한 일회용 환경을 사용해야 합니다.

먼저 서버 보안을 강화하십시오

어떤 단계를 선택하든, 에이전트를 설치하기 전에 서버 자체에 기본적인 보안 조치를 적용해야 합니다. SSH 키 인증만 허용하고, root 로그인을 차단하며, 기본 거부(default-deny) 방화벽을 설정하고, 보안 업데이트를 자동화하십시오. 여기서 체크리스트를 생성하고 순서대로 진행하십시오:

FAQ

--dangerously-skip-permissions 플래그를 서버에서 사용해도 안전합니까?

그 자체로는 안전하지 않습니다. 이 플래그는 모든 승인 프롬프트를 제거하므로, 모델이 잘못된 명령을 생성하는 즉시 실행됩니다. 피해 범위를 제한할 수 있을 때만 방어 가능한 선택이 됩니다. 최소한 권한이 없는 전용 사용자를 사용해야 하며, 진정한 의미의 무인 작업을 수행하려면 프로젝트 하나와 제한된 토큰만 포함하는 컨테이너나 일회용 VPS를 사용하십시오. 운영 자격 증명이나 손실 시 치명적인 데이터가 있는 머신에서는 절대 사용하지 마십시오.

Claude Code는 샌드박스를 제공합니까?

네. Claude Code는 셸 명령을 위한 내장 샌드박스를 제공하며, /sandbox 명령으로 실행할 수 있습니다. 이 샌드박스는 Linux에서는 bubblewrap, macOS에서는 Seatbelt를 사용하며, 프로젝트 디렉터리로 쓰기 권한을 제한하고 승인된 도메인만 허용하는 프록시를 통해 네트워크 접근을 라우팅합니다. 자동 허용 모드(auto-allow mode)는 프롬프트 없이 샌드박스 명령을 실행하므로, OS 수준의 경계를 유지하면서도 플래그를 건너뛰는 것과 같은 방식으로 중단을 줄여줍니다. 이는 완벽한 격리 경계가 아니므로, 무인 실행 시에는 전용 사용자나 전용 머신과 함께 사용하십시오.

왜 skip 플래그는 root 권한으로 실행하는 것을 거부합니까?

권한 확인 프롬프트가 없는 root 사용자는 시스템의 모든 파일과 서비스를 수정할 수 있기 때문입니다. 따라서 Claude Code는 Linux 및 macOS에서 root 또는 sudo로 실행될 때 --dangerously-skip-permissions 사용을 차단합니다. 이 확인 과정을 우회하려 하지 마십시오. 에이전트를 위한 권한 없는 사용자를 생성하고 그 계정에서 실행하십시오. 계정 경계는 가장 기본적이고 저렴한 방어 계층입니다.

Claude Code가 제 SSH 키와 .env 파일을 읽을 수 있습니까?

에이전트는 실행된 사용자가 읽을 수 있는 모든 것을 읽을 수 있으며, 샌드박스의 기본 정책조차 사용자가 거부하기 전까지는 자격 증명 경로에 대한 읽기를 허용합니다. 따라서 에이전트를 별도의 사용자로 실행하고, 본인의 홈 디렉터리 권한을 750 이하로 유지하며, 샌드박스 설정에서 자격 증명 경로를 거부하고, 운영용 비밀 정보는 머신에 아예 저장하지 마십시오. 샌드박스에 저장되지 않은 비밀 정보는 읽히거나 유출될 수 없습니다.

Claude Code를 무인으로 실행하는 가장 안전한 방법은 무엇입니까?

에이전트 작업 전용으로 사용하는 저렴한 VPS를 활용하는 것입니다. 10분 내로 보안을 강화하고, 깨끗한 상태로 스냅샷을 찍어두며, 권한 없는 사용자로 샌드박스를 켠 상태에서 Claude Code를 실행하십시오. API 키는 모드 600 파일에 저장하고, 저장소별 배포 키를 사용하며, 모든 작업은 병합 전 검토하는 브랜치에서 수행하십시오. 실행 중 문제가 발생하면 토큰 하나를 폐기하고 스냅샷을 복원하면 되며, 다른 자산에는 영향을 주지 않습니다.