내 OpenClaw 에이전트가 헛소리를 하기 시작했을 때, 진짜 해결책은 더 나은 프롬프트가 아니라 킬 스위치였다

나는 r/openclaw에서 완벽한 제목의 스레드를 발견했다: “OpenClaw에서 미쳐버린 모델을 멈추는 방법.”

솔직히 말해서, 그게 게시물의 전부다.

왜냐하면 /abort 명령어가 작동하지 않는 순간부터, 당신은 더 이상 프롬프트 엔지니어링 (Prompt Engineering)을 하고 있는 것이 아니기 때문이다. 당신은 사고 대응 (Incident Response)을 하고 있는 것이다.

원문 작성자는 Ollama와 Kimi-K2.6:cloud를 사용하여 OpenClaw를 실행하고 있었다. 에이전트가 횡설수설하기 시작했다. /abort도 도움이 되지 않았다. stop도 도움이 되지 않았다. Ollama를 재시작하는 것도 도움이 되지 않았다.

그 순간 많은 사람이 더 나은 시스템 프롬프트 (System Prompt)를 찾으려 한다.

나는 그것이 잘못된 본능이라고 생각한다.

코딩 에이전트가 셸 (Shell) 접근 권한과 쓰기 권한을 가지고 있다면, 진짜 질문은 다음과 같아야 한다:

“어떻게 하면 모델이 제대로 행동하게 만들 수 있을까?”

가 아니라:

“어떻게 하면 잘못된 실행을 저렴하게 종료하고 쉽게 정리할 수 있을까?”

내 견해는 이렇다: 자기 치유 (Self-healing) 에이전트는 채팅 루프 외부에서 격리, 감독 및 종료하기가 쉬울 때만 안전하다.

따라서 당신이 OpenClaw를 실행 중이거나, n8n, Make, Zapier, OpenClaw, 또는 자체 러너 (Runner)에서 유사한 에이전트 워크플로우를 구축하고 있다면, 내가 실제로 신뢰할 수 있는 설정은 다음과 같다.

큰 실수: 프롬프트를 안전 시스템처럼 취급하는 것

프롬프트는 중요하다.

좋은 프롬프트는 모호함을 줄여준다. 좁은 범위(Scope)는 도움이 된다. 짧은 작업은 “앱을 리팩토링해줘”보다 복구하기가 더 쉽다.

하지만 프롬프트는 조향 장치 (Steering)이다.

브레이크 (Brakes)가 아니다.

이 차이점은 '해피 패스 (Happy Path, 정상 경로)'가 매우 훌륭해 보이기 때문에 무시되곤 한다. GPT-5.4나 Claude Opus 4.6을 코딩 작업에 투입하면, 파일들을 수정하고, 테스트를 실행하고, 차이점(Diff)을 설명하며, 모두가 에이전트가 신뢰할 수 있다고 믿기 시작한다.

그러다 한 번의 실행이 통제 불능 상태가 되면, 당신은 이것의 실체를 기억하게 된다: 도구 접근 권한을 가진 확률론적 시스템 (Probabilistic System)이라는 것을.

만약 /abort가 죽었다면, 당신의 프롬프트는 더 이상 제어 평면 (Control Plane)이 아니다.

당신의 아키텍처 (Architecture)가 제어 평면이다.

OpenClaw 스레드에서 실제로 도움이 된 것

그 스레드에서 가장 유용했던 답변은 가장 화려하지 않은 답변이었다.

한 Reddit 사용자는 기본적으로 이렇게 말했다: 더 이상 해당 저장소(Repo) 경로를 신뢰하지 말고, 폭발 반경 (Blast Radius)이 제한된 상태로 유지되도록 git worktree나 일회용 클론 (Disposable Clone)에서 에이전트를 실행하라고 말이다.

정확히 그렇습니다.

다음과 같은 방법이 아닙니다:

• 안전 주의 사항을 하나 더 추가하기
• 작업을 더 명확하게 반복하기
• 모델에게 주의를 기울이라고 요청하기

대신 다음과 같이 해야 합니다:

• 워크스페이스 (Workspace) 격리
• 쓰기 권한 제어 (Gate writes)
• 활성 상태 감독 (Supervise liveness)
• 실행 상태가 저하되면 즉시 종료 (Kill fast)

이것이 에이전트의 실패를 감내할 수 있는 수준(Survivable)으로 만드는 방법입니다.

규칙 #1: 코딩 에이전트가 메인 체크아웃 (Main Checkout)에서 직접 작업하게 두지 마세요

에이전트가 파일을 수정할 수 있다면, 가장 먼저 제어해야 할 것은 폭발 반경 (Blast radius)입니다.

로컬 개발 환경에서 이를 수행하는 가장 저렴한 방법은 대개 git worktree를 사용하는 것입니다.

일회용 워크스페이스를 생성하세요:

git worktree add -b agent-sandbox ../repo-agent-sandbox

또는 메인 브랜치로부터 추적하세요:

git worktree add --track -b agent-sandbox ../repo-agent-sandbox origin/main

이제 에이전트는 메인 체크아웃을 훼손하는 대신, 별도의 워킹 트리 (Working tree)에서 이상한 행동을 할 수 있습니다.

이 한 단계가 전체적인 리스크 프로필 (Risk profile)을 바꿉니다.

실행 모드	에이전트가 이상해졌을 때 발생하는 일
직접 레포지토리 실행 (Direct repo execution)	가장 높은 폭발 반경. 가장 빠른 설정, 최악의 실패 모드.
...

제 의견은 이렇습니다: 코딩 에이전트에게는 git worktree가 기본값이 되어야 합니다.

메인 레포지토리에서 직접 실행하는 것은 불안하게 느껴져야 합니다. 실제로 불안하기 때문입니다.

규칙 #2: 승인 (Approvals)은 모델 외부에서 이루어져야 합니다

이 지점이 바로 OpenClaw가 사람들이 생각하는 것보다 실제로 더 뛰어난 부분입니다.

OpenClaw의 승인 시스템은 호스트 수준의 정책 강제 (Policy enforcement)를 제공합니다. 외부 정책은 실질적인 제어 수단이기 때문에 이것은 매우 중요합니다. 모델의 지시 사항은 그렇지 않습니다.

현재 정책 확인:

openclaw exec-policy show

주의 깊은 (Cautious) 프리셋 확인:

openclaw exec-policy preset cautious --json

표준 입력 (stdin)으로부터 승인 설정:

openclaw approvals set --stdin <<'EOF'
{ version: 1, defaults: { security: "full", ask: "off" } }
EOF

만약 제가 에이전트에게 코드를 쓰도록 허용한다면, 저는 호스트 정책이 진실의 원천 (Source of truth)이 되기를 원합니다.

프롬프트가 아니라 말입니다.

모델이 스스로 보고하는 계획도 아닙니다.

바로 호스트입니다.

저의 실질적인 승인 규칙

• 읽기 전용 분석 (Read-only analysis): 대부분 자동화해도 괜찮음
• 샌드박스 워크트리 (sandbox worktree) 내 코드 수정: 허용되지만, 머지 (merge) 전 검토 필요
• 상태를 재작성할 수 있는 셸 명령 (Shell commands): 승인 필요
• 배포 (deploys), 비밀 정보 (secrets), 인프라 (infra) 또는 프로덕션 데이터 (production data)에 영향을 주는 모든 것: 별도의 환경을 사용하거나 자율 실행 금지

네, 이것은 YOLO 모드보다 느립니다.

그게 핵심입니다.

가드레일 (Guardrails)은 당신을 구하기 직전에 짜증스럽게 느껴지도록 설계된 것입니다.

규칙 #3: /abort가 실패한다면, 채팅 루프 외부의 킬 패스 (kill path)가 필요하다

해당 스레드에서 가장 웃겼던 답변 중 하나는 바로 이것이었습니다:

ctrl C

무뚝뚝하지만, 정답입니다.

인밴드 (in-band) 중단 경로가 고장 났다면, 아웃오브밴드 (out-of-band) 제어가 필요합니다.

즉, 에이전트 러너 (agent runner)는 대화 계층 (conversation layer)뿐만 아니라 슈퍼바이저 계층 (supervisor layer)에서 하드 킬 (hard kill)을 지원해야 한다는 뜻입니다.

최소한 다음 항목들이 모두 사용 가능해야 합니다:

• 키보드 인터럽트 (keyboard interrupt)
• 프로세스 킬 (process kill)
• 자식 프로세스 정리 (child process cleanup)
• 워크스페이스 폐기 (workspace disposal)
• 재시도 억제 (retry suppression)

만약 당신의 아키텍처가 모델이 종료 명령에 깔끔하게 협조하는 것에 의존하고 있다면, 당신은 킬 스위치 (kill switch)를 가진 것이 아닙니다.

당신은 그저 제안 상자를 가지고 있을 뿐입니다.

규칙 #4: 좀비 서브 에이전트 (zombie sub-agents)는 실제로 존재하므로, 하트비트 (heartbeat)를 추가하라

WhatsApp 신뢰성에 관한 별도의 OpenClaw 스레드에서 제 눈에 띄는 답변이 있었습니다:

“결국 여전히 실행 중인 서브 에이전트들이 문제였습니다.”

이것은 프롬프트 문제가 아닙니다.

이것은 오케스트레이션 드리프트 (orchestration drift)입니다.

이제 우리는 다음의 문제들에 대해 이야기하고 있습니다:

• 멈춰버린 작업 (hung jobs)
• 종료되지 않는 자식 워커 (child workers)
• 쌓여가는 재시도 (retries)
• 존재하지 않는 활성 상태 확인 (liveness checks)
• 실패를 선언하지 않는 슈퍼바이저 (supervisors)

이것은 n8n, Make, Zapier 또는 모든 커스텀 에이전트 러너에서 발생하는 것과 동일한 범주의 문제입니다. 만약 워크플로 (workflow)가 관리자 없이 루프를 돌 수 있다면, 프로세스 감독 (process supervision)이 필요합니다.

최소 기능 하트비트 설계 (Minimum viable heartbeat design)

1. Liveness timeout (생존 타임아웃): 30~60초 동안 유효한 이벤트가 도착하지 않으면 해당 실행(run)을 비정상(unhealthy)으로 표시합니다.
2. Sanity check (무결성 검사): 반복되는 잘못된 형식의 도구 호출(tool calls), 동일한 출력의 반복, 또는 명백한 의미 없는 루프(gibberish loops)를 감지합니다.
3. Step budget (단계 예산): 작업당 도구 호출(tool invocations) 및 파일 변형(file mutations) 횟수를 제한합니다.
4. Retry budget (재시도 예산): 최대 1회 재시도만 허용합니다.
5. Hard abort (강제 중단): 프로세스 트리(process tree)를 종료하고 워크스페이스(workspace)를 폐기합니다.

이것이 실무에서 말하는 "자가 치유(self-healing)"가 의미해야 하는 바입니다.

"느낌(vibes)이 좋아질 때까지 무한 재시도"하는 것이 아닙니다.

때로는 실행 상태를 복구 불가능하다고 선언하고 해체하는 것이 건강한 동작입니다.

단순한 감독자 패턴 (A simple supervisor pattern)

OpenClaw 실행을 감싸기 위해 제가 사용할 대략적인 형태는 다음과 같습니다:

#!/usr/bin/env bash
set -euo pipefail

...

이것은 화려하지 않습니다. 그래서 제가 좋아합니다.

나중에 다음과 같은 기능들로 더 똑똑하게 만들 수 있습니다:

• 이벤트 스트림 모니터링 (event stream monitoring)
• 출력 무결성 검사 (output sanity checks)
• 자식 프로세스 추적 (child process tracking)
• 모델 폴백 라우팅 (model fallback routing)
• 차이 기반 롤백 규칙 (diff-based rollback rules)

하지만 이 기본적인 래퍼(wrapper)조차 /abort 명령어가 당신을 구해줄 것이라고 믿는 것보다 훨씬 낫습니다.

더 나은 프롬프트도 여전히 도움이 됩니다. 다만 방식이 다를 뿐입니다.

과잉 교정하여 프롬프트가 중요하지 않은 척하고 싶지는 않습니다.

프롬프트는 중요합니다.

구체적인 작업일수록 감독(supervise)하기가 더 쉽습니다.

다음은 좋지 않은 예시입니다:

인증 흐름을 수정하고, 프론트엔드를 정리하며, 에러 핸들링을 개선하세요.

다음은 훨씬 더 좋은 예시입니다:

src/auth/login.ts 파일만 수정하세요.
다른 파일은 수정하지 마세요.
npm test -- auth/login.test.ts 를 실행하세요.
...

이러한 종류의 프롬프트는 성공률을 높여줍니다.

하지만 중요한 차이점은 이것입니다:

프롬프트는 정상적인 실행(good runs)을 개선하고

가드레일(guardrails)은 잘못된 실행(bad runs)을 개선합니다

만약 관리되지 않는 코딩 에이전트(unattended coding agent)를 위해 무엇이 더 중요한지 선택해야 한다면, 저는 언제나 가드레일을 선택할 것입니다.

에이전트가 심각하게 실패할 때 비용 문제가 빠르게 나타납니다

여기에는 매우 실질적인 경제적 관점도 존재합니다.

루프에 빠진 에이전트는 단순히 신뢰성 버그(reliability bug)에 그치지 않습니다. 토큰당 과금 방식(per-token pricing) 하에서는 과금 버그(billing bug)가 되기도 합니다.

그 루프가 다음 중 어디에서 발생하든 마찬가지입니다:

• OpenClaw
• n8n
• Make
• Zapier
• 커스텀 워커 큐 (custom worker queue)

잘못된 재시도 정책 (retry policy)은 아무런 유용한 일도 하지 않으면서 조용히 돈을 태워버릴 수 있습니다.

이것이 바로 고정 요금제 컴퓨팅 (flat-rate compute)이 상시 가동되는 에이전트 (agents) 및 자동화 (automations)에 훨씬 더 적합한 이유입니다. 매번 토큰 계산 (mental token math)을 하지 않고도 라우팅 (route)이나 재시도 (retry)를 할 수 있다면, 더 안전한 감독자 (supervisors)를 구축할 수 있습니다.

이것이 제가 Standard Compute가 하고 있는 일을 좋아하는 이유 중 하나입니다. 이들은 토큰당 과금 방식 대신 **고정 월간 요금제 (flat monthly pricing)**를 제공하는 **OpenAI 호환 API (OpenAI-compatible API)**를 제공하며, GPT-5.4, Claude Opus 4.6, Grok 4.20과 같은 모델들 사이를 동적으로 라우팅할 수 있습니다.

에이전트 워크플로우 (agent workflows)의 경우, 이는 동작 방식을 변화시킵니다.

다음과 같은 작업이 가능해집니다:

• 예상치 못한 청구서 걱정 없이 한 번 재시도하기
• 성능이 저하된 모델 스택 (model stack)으로부터 라우팅하기
• 토큰 불안감 없이 24/7 자동화 실행하기
• 기존의 OpenAI SDK 설정을 그대로 유지하기

만약 무인 자동화 (unattended automations)를 구축하고 있다면, 비용 예측 가능성 (cost predictability)은 있으면 좋은 기능(nice-to-have) 정도가 아닙니다. 이는 감독 (supervision)과 복구 (recovery)를 얼마나 공격적으로 수행할 수 있는지를 결정짓는 요소입니다.

제가 내일 당장 사용할 기본 설정

만약 제가 실제 업무를 위해 OpenClaw를 구성한다면, 저의 기본 설정은 다음과 같을 것입니다:

1) 모든 실행을 일회성 작업 공간 (disposable workspace)에서 시작하기

일반적인 코딩 작업에는 git worktree를 사용하세요.

위험도가 높은 실행에는 일회성 클론 (disposable clone) 또는 컨테이너 (container)를 사용하세요.

2) 승인 절차를 모델 외부에 두기

OpenClaw 호스트 승인 (host approvals)을 실제 강제 집행 계층 (enforcement layer)으로 사용하세요.

기본값은 **주의 (cautious)**로 설정하세요.

3) 감독자 하트비트 (supervisor heartbeat) 추가하기

에이전트 또는 하위 에이전트 (sub-agent)가 30초에서 60초 동안 합리적인 진전을 보이지 않는다면, 즉시 종료(kill)하세요.

4) 한 번만 재시도하고, 작업을 좁히기

똑같이 망가진 컨텍스트 (context)를 다섯 번이나 다시 실행하지 마세요.

더 작은 범위, 더 깨끗한 컨텍스트, 또는 다른 모델을 사용하여 한 번만 재시도하세요.

5) 강제 중단 (hard aborts)을 표준화하기

Ctrl+C, timeout, pkill, 자식 프로세스 정리 (child cleanup), 샌드박스 삭제 (sandbox deletion).

/abort가 작동한다면 좋습니다.

작동하지 않더라도, 당신의 시스템은 여전히 안전해야 합니다.

진짜 교훈

제가 그 OpenClaw 스레드에서 좋았던 점은, 가장 훌륭한 답변들이 프롬프트에 집착하는 사람들이 아니라,

운영자 (operators)처럼 생각하는 사람들에게서 나왔다는 점입니다.

그들은 올바른 질문을 던졌습니다:

• 서브 에이전트 (sub-agents)가 여전히 실행 중이라면 어떻게 될까?
• 워크스페이스 (workspace)를 더 이상 신뢰할 수 없다면 어떻게 될까?
• 채팅창 내의 중단 (abort) 경로가 가짜 위안에 불과하다면 어떻게 될까?

그것이 바로 변화의 핵심입니다.

한번 상시 가동되는 에이전트 (always-on agents)를 구축하고 나면, 당신은 더 이상 단순히 프롬프트 (prompts)를 작성하는 것이 아닙니다.

당신은 실패 경계 (failure boundaries)를 설계하는 것입니다.

그리고 모델이 헛소리를 쓰기 시작할 때, 올바른 대처는 모델에게 진정하라고 애원하는 것이 아닙니다.

전원을 차단하십시오.

피해를 격리하십시오.

차이점 (diff)을 검토하십시오.

버려도 상관없는 곳에서 새로 시작하십시오.