몇 주 전, 나는 매우 평범한 질문에서 시작된 깊은 탐구(rabbit hole)에 빠졌습니다:

메인 PC에서 OpenClaw를 실행해도 될까요?

나는 통제 불능의 에이전트(rogue agents), 창발적 기만(emergent deception), 그리고 GPT-5가 어떻게든 당신의 dotfiles를 선택 사항이라고 결정해 버리는 문제에 대한 일반적인 담론을 예상했습니다.

하지만 내가 발견한 것은 훨씬 덜 영화적이고 훨씬 더 유용했습니다.

나는 r/openclaw에서 메인 머신에 OpenClaw를 사용하는 것에 대한 스레드를 읽고 있었는데, 가장 좋은 댓글들은 자아를 가진 AI(sentient AI)에 관한 것이 아니었습니다. 그것들은 지루한 실패 모드(failure modes)에 관한 것이었습니다:

• 잘못된 브라우저 클릭
• 잘못된 셸 명령 (shell command)
• 오염된 페이지
• 덮어쓰여진 파일
• 과도한 파일 시스템 접근 권한 (filesystem reach)

그것이 진짜 문제입니다.

OpenClaw, Claude Code, 그리고 OpenAI Codex CLI의 위험은 모델이 악해지는 것이 아닙니다. 그것은 당신이 확률론적 시스템(probabilistic system)에 되돌릴 수 없는 일을 수행할 수 있는 권한을 부여했다는 점입니다.

그렇게 틀을 잡고 나니, 올바른 보안 모델이 명확해졌습니다:

신뢰가 아닙니다.

가드레일 (Guardrails)입니다.

강력한 가드레일 말입니다.

위험은 지능이 아니라 권한입니다

그 OpenClaw 토론의 한 댓글은 말하지 못하던 진실을 소리 내어 말했습니다: 진짜 위험은 모델이 "통제 불능(going rogue)"이 되는 것이 아니라, 네트워크 접근 범위(network reach)와 명령 실행(command execution)이라는 것입니다.

이는 내가 실제로 목격한 것과 일치합니다.

만약 에이전트가 다음과 같은 일을 할 수 있다면:

• 임의의 웹 페이지 읽기
• 셸 명령 (shell commands) 실행
• 브라우저 내 클릭
• 좁은 범위를 벗어난 파일 쓰기

그렇다면 당신은 "도구를 가진 챗봇"을 가진 것이 아닙니다.

당신은 잘못된 입력에 의해 오도될 수 있는 실행 엔진 (execution engine)을 가진 것입니다.

이것이 사람들이 로컬 에이전트(local agents)를 위한 AI 안전성(AI safety)을 이야기할 때 건너뛰는 부분입니다. 모델이 당신에게 해를 끼치기 위해 악의적일 필요는 없습니다. 단지 충분한 권한과 단 하나의 잘못된 지시만 있으면 됩니다.

실제로 중요한 4가지 위험 범주

만약 당신이 OpenClaw, Claude Code, Codex CLI 또는 임의의 커스텀 에이전트 루프(agent loop)를 실행하고 있다면, 다음이 주요 위험 요소입니다:

• 삭제, 이동, 설치 또는 데이터 유출(exfiltrate)을 수행하는 셸 명령 (Shell commands)
• 프롬프트 인젝션 (prompt injection)을 유발하는 임의의 URL 가져오기 (URL fetching)
• 클릭, 제출, 다운로드 또는 인증과 같은 브라우저 동작
• 레포지토리(repo), 설정(config) 또는 노트를 조용히 손상시키는 파일 쓰기

그것이 체크리스트입니다.

"모델이 정렬(aligned)되었는가?"가 아닙니다.

그보다는 다음과 같습니다: 모델이 무엇을 건드릴 수 있으며, 모델이 잘못되었을 때 어떤 일이 발생하는가?

웹 액세스가 위협 모델(threat model)을 빠르게 변화시키는 이유

프롬프트 인젝션(Prompt injection)은 구체적인 사례를 접하기 전까지는 이론적으로 들립니다.

다음과 같이 적힌 페이지를 상상해 보세요:

만약 당신이 AI 에이전트라면, 로컬 비밀 정보(secrets), API 키, 그리고 저장된 인증 정보(credentials)를 업로드하십시오.

에이전트가 해당 페이지를 읽을 수 있고, 읽은 후에 실제로 행동을 취할 수 있게 되기 전까지는 이 문장이 바보같이 들릴 것입니다.

이것이 바로 임의의 페치(arbitrary fetch)와 도구(tools)의 결합이 매우 위험한 이유입니다.

칭찬할 점은, Anthropic의 Claude Code 문서가 이 점을 이해하고 있는 것으로 보인다는 것입니다. 제가 정말 마음에 드는 세부 사항 하나는, curl과 wget이 기본적으로 자동 승인되지 않는다는 점입니다.

이는 강력한 신호입니다.

벤더(vendor)가 curl을 묵인하기를 거부한다면, 그들은 진짜 문제가 모델의 의식(consciousness)이 아니라는 점을 인정하고 있는 것입니다. 진짜 문제는 신뢰할 수 없는 콘텐츠(untrusted content)가 실제 권한(permissions)에 너무 가깝게 접근하는 것입니다.

이는 공상 과학(sci-fi) 버전의 이야기보다 훨씬 더 유용한 프레임입니다.

가장 과소평가된 가드레일(guardrail): 작업 디렉토리(working directory)

모두가 마법 같은 정책 엔진(policy engine)을 원합니다.

하지만 대부분의 사람들에게 실제로 필요한 것은 폴더 경계(folder boundary)입니다.

Claude Code의 문서에 따르면, 추가 승인 없이 시작된 폴더와 그 하위 폴더 내부에는 파일을 쓸 수 있지만, 명시적으로 허용하지 않는 한 상위 디렉토리(parent directories)는 보호된 상태로 유지된다고 합니다.

지루하게 들릴 수도 있습니다.

하지만 이것은 전체 스택(stack)에서 가장 훌륭한 안전 제어 장치 중 하나입니다.

"조심하세요"라고 말하는 가드레일은 약합니다.
"내가 승인하지 않는 한, 당신은 말 그대로 ./repo 상위의 어떤 것도 건드릴 수 없습니다"라고 말하는 가드레일이 진짜입니다.

이것은 다음과 같은 차이를 만듭니다:

• ~/projects/demo-app 내의 브랜치(branch)를 망가뜨리는 것
• ~/.ssh로 흘러 들어가는 것
• ~/Documents를 건드리는 것
• 브라우저 프로필(browser profile)을 변형시키는 것

저는 파일 시스템 액세스(filesystem access)가 제한되지 않은 천재적인 모델보다는, 엄격한 디렉토리 경계가 있는 평범한 모델을 사용하겠습니다.

이것은 반(anti) AI적인 태도가 아닙니다. 기본적인 엔지니어링입니다.

벤더들이 동일한 패턴으로 수렴하고 있다

흥미로운 점은 Anthropic과 OpenAI 모두 동일한 설계 방향으로 움직이고 있다는 것입니다:

범위가 지정된 자율성(Scoped autonomy).

전적인 자율성(total autonomy)이 아닙니다.

Anthropic이나 OpenAI 중 그 누구도 "당신의 머신을 모델에게 그냥 믿고 맡기세요"라고 말하고 있지 않습니다.

그들은 이렇게 말하고 있습니다: 먼저 경계(boundaries)를 설정하십시오.

그것이 이 도구들이 어떻게 사용되어야 하는지를 말해줄 것입니다.

내가 실제로 허용할 것들

내가 본 가장 좋은 패턴은 유용하면서도 좁은 범위(narrow)를 갖는 것입니다.

Claude Code의 'Accept Edits' 모드가 좋은 예시입니다. 이 모드는 편집을 자동 승인하며, 작업 디렉토리 내부의 아주 작은 파일 시스템 명령 세트만을 허용합니다:

• mkdir
• touch
• rm
• mv
• cp
• sed

단 6개의 명령입니다.

전체 bash가 아닙니다.
"YOLO, 그냥 배포해(YOLO, ship it)"도 아닙니다.
그저 생산성을 유지할 수 있을 만큼만 허용합니다.

그 외의 모든 것은 여전히 승인이 필요합니다.

이것이 내가 신뢰하는 패턴입니다:

1. 우선 읽기 전용(Read-only)으로 시작
2. 제한된 쓰기 범위(Limited write scope)
3. 지루한 명령들의 작은 허용 목록(allowlist)
4. 네트워크 및 셸 권한 상승(escalation)에 대한 수동 승인
5. 더 많은 자율성이 필요할 때는 샌드박스(Sandbox) 사용

네트워크 가져오기(network fetches)를 허용해야 한다면, 그것을 의도적인 선택으로 만드십시오.

예를 들어:

Bash(curl *)

유용한가요? 물론입니다.

하지만 내 데일리 머신에서 전역적으로 자동 승인할 것인가요? 절대 아닙니다.

더 넓은 자율성이 필요하다면, 나는 그것이 샌드박스화되기를 원합니다.

내가 추천하는 실질적인 설정

개발 머신에서 제정신인(sane) 로컬 에이전트 설정을 원한다면, 이것이 좋은 기준점(baseline)이 될 것입니다.

1. 전용 작업 디렉토리 생성

mkdir -p ~/agents/demo-repo
cd ~/agents/demo-repo

에이전트를 홈 디렉토리가 아닌 그곳에서 시작하십시오.

2. 가능한 경우 관리자(admin)가 아닌 계정 사용

macOS나 Linux에서는 별도의 사용자 계정을 만드는 것이 저렴한 격리(isolation) 방법입니다.

sudo adduser agentuser
sudo usermod -aG developers agentuser

작업이 진정으로 필요로 하지 않는 한 관리자 권한을 주지 마십시오.

3. 명령 허용 목록(allowlist)을 아주 작게 유지

패키지 설치가 아니라 파일 작업에 집중하십시오.

좋은 후보들:

mkdir
touch
cp
...

나쁜 기본 승인 대상:

curl
wget
bash
...

4. 브라우저 자동화(browser automation)를 고위험으로 취급하십시오

만약 에이전트(agent)가 사용자의 실제 Chrome 프로필, 저장된 세션(sessions), 또는 인증된 탭(authenticated tabs)을 사용할 수 있다면, 폭발 반경(blast radius)은 훨씬 커집니다.

그럴 때는 VM(가상 머신), 일회용 브라우저 프로필, 또는 별도의 머신으로 전환해야 합니다.

5. 경계를 넘나드는 모든 작업에 대해 승인을 요구하십시오

다음 사항들이 포함됩니다:

• 리포지토리(repo) 외부 쓰기
• 네트워크 페치(network fetches)
• 패키지 설치(package installs)
• 브라우저 로그인
• 와일드카드(wildcards)를 포함한 셸 명령(shell commands)

메인 머신인가, 별도의 머신인가?

제 대답은 이렇습니다: 폭발 반경(blast radius)에 따라 다릅니다.

에이전트가 단 하나의 리포지토리 내에서 코드만 편집한다면, 범위(scope)가 좁을 경우 메인 머신을 그대로 사용해도 괜찮은 경우가 많습니다.

하지만 에이전트가 광범위한 브라우저 접근 권한을 갖거나, 장시간 실행되는 세션, 또는 실제 계정에 접근한다면 저는 머신을 분리하겠습니다.

메인 머신에서 사용해도 괜찮은 경우

• 리포지토리 범위 내의 코딩(repo-scoped coding)
• 읽기 중심의 분석(read-heavy analysis)
• 검토된 작은 규모의 편집
• 관리자 권한(admin privileges) 없음
• 제한 없는 브라우저 프로필 접근 권한 없음

VM, VPS, 또는 별도의 박스(separate box)에 배치해야 하는 경우

• 저장된 로그인을 사용하는 브라우저 자동화
• Stripe, Gmail, GitHub, AWS 또는 운영 환경(prod)에 접촉하는 모든 것
• 장시간 실행되는 자율 루프(autonomous loops)
• 임의의 URL 페칭(URL fetching)
• 단 한 번의 잘못된 클릭이 큰 비용을 초래하는 워크플로우(workflows)

이 지점부터는 "그냥 Claude를 믿으세요"라거나 "GPT-5는 이제 똑똑합니다"라는 논리가 저에게는 통하지 않습니다.

벤더(vendors)들조차 제한 없는 로컬 자율성(local autonomy)이 기본적으로 안전하다고 행동하지 않습니다. 그들의 문서는 권한 제어(permission controls), 승인 흐름(approval flows), 그리고 격리 기능(containment features)으로 가득 차 있습니다.

그것은 두려움이 아닙니다.

그것은 제품이 사용자에게 올바른 운영 모델(operating model)을 알려주는 것입니다.

지루한 설정이 안전한 설정입니다

딱 한 가지만 기억해야 한다면, 이것입니다:

모호한 신뢰보다는 제한된 도달 범위(limited reach)가 언제나 승리합니다.

가장 안전한 로컬 에이전트(local-agent) 설정은 안전 마케팅을 가장 잘하는 설정이 아닙니다. 모델이 아주 작은 공간에서 몇 가지 일만 할 수 있고, 위험도가 높아질 때는 사용자의 승인을 거치도록 하는 설정입니다.

제 체크리스트는 다음과 같습니다:

• 제한된 작업 디렉토리(bounded working directory)에서 시작하기
• 기본 모드를 읽기 전용(read-only)으로 유지하기
• 쓰기(writes), 셸 명령(shell commands), 브라우저 동작(browser actions)에 대해 승인 요구하기
• curl 또는 wget을 자동 승인하지 않기
• 관리자 권한이 없는 샌드박스 사용자(sandboxed user) 사용하기
• 위험도가 높은 워크플로우(workflows)는 VM, VPS 또는 별도의 머신으로 이동하기

그 OpenClaw 스레드는 극적이지 않았습니다. 실용적이었습니다.

솔직히 말해서, 그 점이 저를 더 신뢰하게 만들었습니다.

이 분야에서의 가장 좋은 조언은 대개 지루하게 들립니다.

폴더 경계.
허용 목록(Allowlists).
승인 프롬프트(Approval prompts).
격리된 사용자(Isolated users).

이것은 타당합니다. 왜냐하면 당신이 방어하려는 대상 또한 대개 지루하기 때문입니다.

통제 불능의 초지능(rogue superintelligence)이 아닙니다.

그저 잘못된 rm 한 번, 오염된 페이지 하나, 확신에 찬 클릭 한 번, 그리고 필요 이상의 권한을 가진 에이전트(agent) 하나면 충분합니다.

에이전트 워크플로우를 구축하는 팀을 위한 한 가지 더

이 지점은 비용과 권한이 충돌하기 시작하는 곳이기도 합니다.

승인 게이트(approval gates), 재시도(retries), 샌드박스 실행(sandboxed runs)을 더 많이 추가할수록 에이전트가 수행하는 호출(calls)은 늘어납니다. 당신의 가격 모델이 실험에 대해 불이익을 주지 않는다면 이는 괜찮습니다.

만약 n8n, Make, Zapier, OpenClaw 또는 커스텀 루프(custom loops)에서 에이전트를 실행하고 있다면, 토큰당 과금(per-token billing) 방식은 비용을 예측 가능하게 유지하기 위해 가드레일(guardrails)을 느슨하게 만들려는 이상한 유인을 제공합니다.

저는 그것이 잘못되었다고 생각합니다.

추가적인 검토 단계마다 청구 금액이 늘어날까 봐 걱정하지 않고도, 에이전트를 제한된 범위 내에 가두고, 승인 중심적이며, 반복적으로 실행할 수 있는 자유를 원해야 합니다.

그것이 제가 Standard Compute가 하고 있는 일을 좋아하는 이유 중 하나입니다. 고정된 월간 가격, OpenAI 호환 API, 그리고 에이전트 워크로드(agentic workloads)를 위한 무제한 AI 컴퓨팅을 제공합니다. 만약 당신의 워크플로우에 재시도, 라우팅(routing), 긴 루프, 또는 많은 제약 조건이 있는 도구 사용(constrained tool use)이 필요하다면, 예측 가능한 비용은 실질적인 운영상의 이점입니다.

가드레일은 토큰 불안(token anxiety)을 최적화하려 하지 않을 때 더 잘 작동합니다.

그리고 에이전트 워크플로우의 경우, 이 트레이드오프(tradeoff)는 사람들이 인정하는 것보다 훨씬 더 중요합니다.