나는 탄탄한 AGENTS.md 파일만 있으면 대부분의 싸움에서 이길 수 있다고 생각했었다.

몇 가지 규칙을 추가한다.
에이전트에게 잘못된 가정을 반박하라고 말한다.
생각 없이 되돌릴 수 없는 변경을 수행하지 말라고 말한다.
어쩌면 "회의적으로 생각하라"는 섹션을 넣을 수도 있다.

합리적이지 않은가?

그러다 나는 한 에이전트가 잘못된 전제를 수용하고, 그 위에 결과물을 쌓아 올린 뒤, 아주 자신만만하게 다듬어진 실수를 반환하는 것을 목격했다.

실수 자체가 무서운 부분은 아니었다.

그 자신감이 무서웠다.

그 순간이 내가 프롬프트 규칙(prompt rules)을 안전장치로 취급하는 것을 멈춘 순간이었다.

AGENTS.md의 문제점

이 문제를 파고드는 동안, r/openclaw에서 좋은 스레드를 발견했다:

https://reddit.com/r/openclaw/comments/1v3v9v1/make_your_openclaw_smarter/

한 댓글이 문제를 정확히 짚었다:

문제는 에이전트(Agent) 또한 이를 속일 수 있다는 점이다. 어떤 방식으로도 강제되지 않는다. 이는 단지 제안일 뿐이며, 에이전트가 실제로 이를 수행하도록 강제하는 메커니즘 없이도 수행했다고 주장할 수 있다.

그것이 문제의 핵심이다.

에이전트는 확인했다고 말할 수 있지만, 당신의 시스템이 그 확인을 검증하지 않는다면 당신에게는 통제권이 없다.

당신은 프롬프트(prompt)를 가지고 있을 뿐이다.

그리고 프롬프트는 취약한 통제 수단이다.

때로는 유용하다. 쓸모없는 것은 아니다. 하지만 취약하다.

가장 중요한 실패 모드

최악의 에이전트 실패는 대개 터무니없는 환각(hallucinations)이 아니다.

그것은 잘못된 전제의 그럴듯한 연속이다.

같은 스레드의 다른 사람은 이렇게 말했다:

내가 그것들을 도입했더니, 그는 그 위에 결과물을 쌓아 올렸다.

정확하다.

잘못된 가정이 들어간다.
더 큰 잘못된 가정이 나온다.

모델이 완전히 탈선할 필요는 없다. 단지 몇 차례 동안 지나치게 동조하기만 하면 된다.

이것이 실제 워크플로(workflows)에서 AGENTS.md가 무너지는 이유다.

README를 요약하거나 변수 이름을 바꾸는 것과 같은 저위험 작업의 경우, 프롬프트 유도(prompt nudge)만으로도 충분한 경우가 많다.

하지만 파일을 작성하거나, SQL을 실행하거나, 외부 API를 호출하거나, 운영 환경의 설정을 변경하는 것과 같이 부작용(side effects)이 있는 모든 작업에 대해서는, 나는 증거(receipts)를 원한다.

프롬프트 전용 안전장치가 실패하는 이유

인센티브(incentives)가 왜곡되어 있기 때문이다.

OpenAI의 2025년 환각 (hallucination) 보고서는 이 점을 명확히 짚었습니다. 많은 평가 방식이 답변을 유보하는 것보다 추측하는 것에 보상을 준다는 사실입니다.

그들의 생일 예시는 매우 잔혹합니다.

모델이 생일을 추측한다면, 맞을 확률은 1/365입니다.
만약 모델이 모르겠습니다라고 말한다면, 일반적인 벤치마크 (benchmark)에서 0점을 받게 됩니다.

따라서 모델에게 “사용자에게 이의를 제기하라”거나 “회의적으로 생각하라”고 말하는 것은, 모델에게 다음과 같은 것들과 싸우라고 요구하는 것과 같습니다.

• 모델의 학습 인센티브 (training incentives)
• 대화의 흐름 (momentum of the conversation)
• 답변을 생성하려는 기본 편향 (default bias)

때로는 GPT-5가 전제를 의심하기도 합니다.
때로는 Claude Opus가 그러합니다.
때로는 Llama나 Qwen이 그러하기도 합니다.

하지만 승인 전에 증거를 요구하는 시스템을 구축하지 않는 한, 당신은 여전히 모델의 '착한 행동'에 의존하고 있는 것입니다.

착한 행동은 강제성 (enforcement)이 아닙니다.

나의 새로운 규칙: 실행 단계에 검증을 포함하라

이것이 변화의 핵심입니다.

안전장치 (safeguard)가 중요하다면, 그것은 단순히 글로만 존재하는 것이 아니라 실행 (execution) 단계에서 나타나야 합니다.

즉, 최소한 다음 중 하나는 갖춰져야 합니다.

• 행동하기 전 필수적인 반대 입장 (counter-position) 작성
• 도구 호출 (tool-call) 승인 단계
• 지속되는 체크포인트 (persisted checkpoints)
• 작업을 실패 처리할 수 있는 평가자 (evaluator)
• 깔끔한 답변 유보 (abstain) 경로

내가 이런 방식으로 생각하기 시작하자, 기존의 많은 에이전트 설계 조언들이 부실해 보이기 시작했습니다.

프롬프트 vs 증거: 실제로 얻게 되는 것

중간 행의 내용이 사람들이 생각하는 것보다 훨씬 중요합니다.

내가 본 더 나은 해킹 방법 중 하나는, 사소하지 않은 변경을 수행하기 전에 모델이 짧은 반대 입장을 쓰도록 강제하는 것입니다.

예를 들어:

사소하지 않은 변경을 수행하기 전에, 다음을 설명하는 3문장을 작성하세요:
1. 현재의 방향이 왜 틀릴 수 있는지
2. 어떤 가정이 실패할 수 있는지
...

이것이 마법처럼 모델을 신뢰할 수 있게 만들어주지는 않습니다.

하지만 이 방법은 '의견 불일치 (disagreement)'를 당신이 검사할 수 있는 결과물 (artifact)로 강제합니다.

이것만으로도 “회의적으로 생각하세요”라고 말하는 것보다 이미 큰 개선입니다.

도구 계층(Tool-layer) 검증이 훨씬 더 강력합니다

이 지점에서부터 상황은 단순한 '느낌(vibes)'을 벗어나 본격적인 '엔지니어링 (engineering)'이 됩니다.

만약 에이전트가 어떤 행동을 취하고 싶어 한다면, 그 행동을 명시적으로 만드세요.
그다음 그것을 차단(gate)하십시오.

MCP 모델은 올바른 형태의 좋은 예시입니다. 도구 호출 (tool call)은 막연한 주장이 아니라 구체적인 객체입니다:

{
  "jsonrpc": "2.0",
  "id": 2,
...

일단 그것을 확보했다면, 다음 단계는 명확합니다:

1. 인간에게 제안된 도구 호출 (tool call)을 보여줍니다.
2. 인자 (arguments)를 보여줍니다.
3. 승인/거절/수정 (approve/reject/edit)을 요구합니다.
4. 결정을 지속 (persist)합니다.
5. 안전하게 재개 (resume)합니다.

이것이 진정한 안전장치입니다.

예시: LangChain에서 위험한 도구에 대한 인간의 승인

LangChain의 HumanInTheLoopMiddleware는 검토 과정을 강제적인 일시 정지로 전환하기 때문에 가장 명확한 예시 중 하나입니다.

from langchain.agents import create_agent
from langchain.agents.middleware import HumanInTheLoopMiddleware
from langgraph.checkpoint.memory import InMemorySaver
...

이것은 다음과 같은 방식과는 의미 있는 차이가 있습니다:

# AGENTS.md
- 파일 쓰기에 주의할 것
- SQL을 실행하기 전에 생각할 것
...

첫 번째 방식은 실행을 중단시킬 수 있습니다.
두 번째 방식은 그저 바랄 수 있을 뿐입니다.

내가 실제로 권장하는 것

모든 에이전트 단계에 검토 게이트 (review gate)가 필요하다고 생각하지는 않습니다.

그렇게 하면 속도가 느려지고, 비용이 많이 들며, 짜증을 유발할 것입니다.

안전장치는 위험도에 맞춰야 한다고 생각합니다.

프롬프트 규칙 (prompt rules)을 사용해야 하는 경우:

• 요약 (summarization)
• 초안 작성 (drafting)
• 포맷팅 (formatting)
• 되돌릴 수 있는 내부 작업 (reversible internal chores)

반대 입장 (counter-position)을 요구해야 하는 경우:

• 가정이 많은 계획 (assumption-heavy planning)
• 아키텍처 변경 (architecture changes)
• 사용자가 확신을 가지고 틀렸을 가능성이 있는 경우

도구 수준의 검증 (tool-level verification)을 요구해야 하는 경우:

• 파일 쓰기 (file writes)
• SQL 실행 (SQL execution)
• 외부 API 호출 (external API calls)
• 결제 작업 (billing actions)
• 프로덕션 변경 (production changes)
• 공개적이거나 되돌리기 어려운 모든 것

이것이 실용적인 버전입니다.

효과적인 간단한 패턴

오늘날 에이전트를 구축하고 있다면, 설령 기본적인 워크플로우라 할지라도 이 패턴이 더 큰 프롬프트를 사용하는 것보다 훨씬 더 멀리 나아갈 수 있게 해줍니다.

1단계: 모델이 제안된 행동을 진술하게 하기

{
  "action": "execute_sql",
  "reason": "사용자가 보고한 계정 불일치를 확인해야 함",
...

2단계: 실행 전 검사 (inspect before execution)

• 도구가 올바른가?
• 인자(arguments)가 안전한가?
• 반대 입장(counter-position)을 고려했을 때 실제 위험이 드러나는가?
• 진행하기에 충분한 증거가 있는가?

3단계: 체크포인트 저장 (persist the checkpoint)

워크플로(workflow)가 일시 중단되더라도 상태(state)를 잃지 마세요.

이는 장시간 실행되는 자동화(automations)에서 매우 중요합니다.

4단계: 그제서야 부작용(side effects)을 허용하기

증거가 없다면, 승인도 없습니다.

자동화에서는 이것이 훨씬 더 중요합니다

워크플로가 더 에이전트 중심적(agentic)이 될수록, "나를 믿으라"는 식의 태도는 점점 더 용납하기 어려워집니다.

만약 다음과 같은 환경에서 에이전트들을 서로 연결하고 있다면:

• n8n
• Make
• Zapier
• OpenClaw
• 커스텀 LangGraph 또는 MCP 설정

그렇다면 진짜 위험은 단 하나의 잘못된 답변이 아닙니다.

진짜 위험은 하나의 잘못된 답변이 다음과 같은 결과로 이어지는 것입니다:

• 파일 쓰기 (file write)
• 데이터베이스 변형 (database mutation)
• 웹훅 호출 (webhook call)
• 결제 이벤트 (billing event)
• 운영 환경 변경 (production change)

바로 이 지점에서 팀들은 검증(verification)에 관심을 갖기 시작합니다.

또한, 토큰당 과금 방식(per-token pricing)이 빠르게 번거로워지는 지점이기도 합니다.

평가 루프(evaluator loops), 재시도(retries), 승인 체크포인트(approval checkpoints), 그리고 더 긴 도구 사용 실행(tool-using runs)을 추가하게 되면, 더 이상 저렴한 단일 샷 완료(single-shot completion)를 다루는 것이 아니기 때문입니다.

당신은 시스템을 운영하고 있는 것입니다.

이것이 에이전트 워크플로에서 가격 모델이 매우 중요한 이유 중 하나입니다.

모든 추가적인 검증 단계가 세금처럼 느껴진다면, 팀들은 안전을 타협하게 될 것입니다.

Standard Compute와 같은 OpenAI 호환 정액제(Flat-rate) 인프라는 이러한 압박을 일부 제거해주기 때문에 흥미롭습니다. 모든 추가 확인 작업이 토큰 비용만큼의 가치가 있는지 끊임없이 고민하지 않고도, 검증 루프, 미들웨어(middleware), 라우팅 로직(routing logic)을 계속 유지할 수 있습니다.

이는 프롬프트 파일이 에이전트를 정직하게 유지해주길 바라며 행운을 비는 것보다, 실제 자동화에 훨씬 더 적합한 방식입니다.

OpenClaw는 올바른 직관을 가지고 있었습니다

제가 OpenClaw 논의를 좋아하는 이유 중 하나는 사용자들이 데모 데이의 마법이 아니라 실제 실패 모드(failure modes)에 대해 이야기하고 있기 때문입니다.

동일한 실용적인 사고방식이 도구(tooling)에서도 나타납니다:

openclaw status
openclaw status --all
openclaw health --json
...

그것이 올바른 본능입니다.

신뢰하지 마세요. 검사(Inspect)하세요.

제 생각에 에이전트의 추론(reasoning)도 동일한 처우가 필요합니다.

프로세스의 상태(process health)를 검사할 수 있다면, 다음 사항들도 검사할 수 있어야 합니다:

• 모델이 어떤 전제(premise)를 수용했는지
• 어떤 반대 입장(counter-position)을 생성했는지
• 어떤 도구 호출(tool call)을 제안했는지
• 어떤 인자(arguments)를 사용했는지
• 어떤 출력(output)이 돌아왔는지
• 누가 다음 단계를 승인했는지

그렇지 않다면, 당신은 여전히 멋진 마크다운(markdown) 파일 하나를 옆에 둔 채 블랙박스(black box)를 실행하고 있는 것입니다.

나의 현재 체크리스트: 증거가 없으면 승인도 없다

에이전트가 어떤 중대한 일을 수행하고 있다면, 나는 그 결과를 신뢰하기 전에 최소한 다음 중 하나를 원합니다:

1. 가시적인 반대 입장 (counter-position)
2. 정확히 제안된 도구 호출(tool call)과 인자(arguments)
3. 가공되지 않은 도구 출력 (raw tool output)
4. 작업을 실패 처리할 수 있는 평가자 단계 (evaluator step)
5. 증거가 누락되었을 때의 기권 경로 (abstain path)

이것은 AGENTS.md보다 더 엄격하게 들리겠지만, 실제로 더 엄격하기 때문입니다.

하지만 이것이 더 정직하기도 합니다.

더 나은 모델들은 큰 도움이 됩니다. 아주 많이요.

하지만 그 모델들이 검증 루프(verification loops)의 필요성을 없애주지는 않습니다.

그러니 네, 프롬프트 규칙은 유지하세요.
도움이 된다면 AGENTS.md에 “사용자에게 도전하라”는 내용을 유지해도 좋습니다.

다만, 프롬프트가 통제 수단인 것처럼 가장하는 것만 멈추세요.

증거 기반의 에이전트(evidence-based agents)를 원한다면, 회의론(skepticism)을 성격적 특성이 아닌 필수적인 산출물(artifact)로 만드세요.