제 에이전트 스택에서 가장 가치 있는 코드는 아무것도 하지 않는 코드입니다.

저는 에이전트가 주로 무인 상태로 콘텐츠를 조사하고, 초안을 작성하며, 게시를 위해 대기열에 추가하는 파이프라인을 운영합니다. 저에게 가장 많은 비용과 당혹감을 아껴준 것은 영리한 시스템 프롬프트 (System Prompt)가 아니었습니다. 그것은 바로 에이전트가 인간의 클릭 없이는 수행할 수 없는 작업들을 짧게 하드코딩 (Hard-coded)한 목록, 그리고 작업 중간에 추측하는 대신 멈춰서 질문을 던져야 하는 규칙들의 집합이었습니다.

거의 어떤 에이전트 튜토리얼도 이 부분을 다루지 않습니다. 모든 튜토리얼은 해피 패스 (Happy Path)만을 보여줍니다. 모델이 계획하고, 모델이 도구 (Tools)를 호출하고, 작업이 완료되어 축하 꽃가루가 날리는 식이죠. 하지만 에이전트의 결정적인 특성인 '사용자 없이 루프가 계속 돌아가는 것'이야말로, 시스템 전체에서 '중단 (Stop)' 조건을 설계하는 것을 가장 어려운 결정으로 만드는 바로 그 지점입니다. 한쪽 방향으로 잘못 설계하면 에이전트가 되돌릴 수 없는 잘못된 행동을 자신 있게 수행하게 됩니다. 반대 방향으로 잘못 설계하면 매우 비싼 확인 대화 상자 (Confirmation Dialog)를 만든 셈이 됩니다.

여기 중단 조건을 구축해야 하는 이유와, 오늘 오후에 바로 구현할 수 있는 세 가지 메커니즘을 소개합니다.

에이전트는 기본적으로 추측하며, 추측은 측정 가능한 수준으로 실패한다

머릿속에 담아둘 만한 두 가지 결과가 있습니다.

τ-bench (Sierra Research, 2024년 6월)는 함수 호출 (Function-calling) 에이전트들을 실제 도메인 정책(항공권 재예약, 소매 반품)을 따라야 하는 사용자와의 시뮬레이션 대화에 배치했습니다. 핵심 내용은 다음과 같습니다. 당시 최고의 에이전트들조차 50% 미만의 작업에서만 성공했으며, 신뢰도는 그 수치보다 더 낮았습니다. pass^8 지표(에이전트가 동일한 작업에 대해 8번 모두 성공하는가?)에서 소매 도메인의 성능은 25% 미만으로 떨어졌습니다 (논문, 벤치마크 리포지토리). 동일한 작업, 동일한 에이전트임에도 실행할 때마다 결과가 달랐습니다. 실패의 큰 비중은 정확히 여러분이 예측할 수 있는 내용입니다. 즉, 에이전트가 사용자가 실제로 원하는 것이 무엇인지 또는 정책이 실제로 허용하는 것이 무엇인지 해결하는 대신, 가정 (Assumption)을 바탕으로 진행해 버리는 것입니다.

ClarifyGPT (2023년 10월, 이후 FSE 2024에서 발표 — 논문 페이지)는 그 반대의 경우를 테스트했습니다. 즉, 모델이 모호함을 감지하고 생성하기 전에 질문하도록 강제하면 어떤 일이 벌어질까요? MBPP-sanitized 데이터셋에서, 모호한 요구사항에 대해 GPT-4가 타겟팅된 명확화 질문 (Clarifying questions)을 던지게 했을 때 Pass@1 수치가 70.96%에서 80.80%로 상승했습니다. 추측하는 대신 질문을 함으로써 약 10%포인트의 성능 향상을 이룬 것입니다. 이 논문의 동기 부여가 된 관찰 결과가 중요한 부분입니다. 즉, LLM은 그대로 내버려 두면 모호한 요청에 대해 질문을 던지는 대신, 완전하고 자신감 있는 답변을 생성해 버린다는 것입니다.

이것이 핵심 문제입니다. 모델은 *이번 턴 (turn)*에 최대한 도움이 되도록 훈련되었습니다. 모델에게 질문을 던지는 것은 실패처럼 느껴집니다. 따라서 질문 경로 (ask-path)를 직접 구축하지 않는 한, 그 경로는 존재하지 않습니다.

이러한 모델을 출시하는 벤더(Vendors)들도 같은 말을 합니다. Anthropic의 "Building Effective Agents" (2024년 12월, Simon Willison의 글에서 잘 요약됨)는 에이전트가 중단하고 인간의 검토를 기다리는 체크포인트 (Checkpoints), 특히 되돌릴 수 없는 행동을 하기 전의 단계를 권장합니다. OpenAI의 "A Practical Guide to Building Agents" (2025년 4월, 관련 보도)는 인간에게 에스컬레이션 (Escalate)되어야 하는 두 가지 트리거 (Triggers)를 명시합니다: 실패 임계값 초과 (Exceeding failure thresholds) 및 고위험 행동 (High-risk actions) — 즉 민감하거나, 되돌릴 수 없거나, 이해관계가 큰 작업들입니다. 두 가이드 모두 여러분에게 동일한 말을 하고 있습니다: 주의를 기울이라고 프롬프트(Prompt)를 짜지 말고, 주의를 기울이도록 설계(Architect)하십시오.

세 가지 트리거

제가 게이트(Gate)를 설정하는 모든 것은 다음 세 가지 질문으로 귀결되며, 이 순서대로 확인됩니다:

1. 행동이 되돌릴 수 없는 것인가? (Is the action irreversible?) 다른 도구 호출(tool call)로 되돌릴 수 있는가? 이메일 전송, 카드 결제, 게시물 발행, 레코드 삭제 — 아니오. 초안 작성, 브랜치 생성, 파일 스테이징 — 예. 되돌릴 수 없음(Irreversible) → 에이전트가 아무리 확신하더라도 항상 확인 절차를 거치십시오. 여기서 중요한 변수는 확신(Confidence)이 아니라, 영향 범위(blast radius)입니다.
2. 작업이 모호한가? (Is the task ambiguous?) 요청을 합리적으로 해석했을 때 실질적으로 다른 행동들이 뒤따를 수 있는가? 두 가지 유능한 해석이 서로 다른 두 가지 도구 호출로 이어진다면, 에이전트는 조용히 하나를 선택하는 대신 질문을 하나 던져야 합니다.
3. 실패 예산(failure budget)을 모두 소모했는가? 에이전트가 이미 이 단계에서 N번 실패했는가? 상한선이 없는 재시도 루프(retry loops)는 에이전트가 40달러어치의 토큰을 소모하며 정교하게 실패하게 만드는 원인이 됩니다. N번의 실패 후에는 재시도를 중단하고 요약과 함께 에스컬레이션(escalate)하십시오.

목록에 포함되지 않은 내용에 주목하십시오: "모델이 불확실해하는가?"입니다. 모델이 스스로 보고하는 확신은 제가 더 이상 신뢰하지 않기로 한 신호입니다. $\tau$-bench에서 방금 틀린 답을 낸 모델은 그 과정에서 확신을 유보(hedging)하지 않았습니다. 위의 세 가지 트리거는 모두 모델 외부에서 계산 가능합니다.

메커니즘 1: 확인 게이트 (the confirmation gate)

패턴: 모든 도구 호출은 실행되기 전에 정책 함수(policy function)를 통과합니다. 이 정책은 지루하고 결정론적인(deterministic) Python 코드이며, 의도적으로 LLM을 사용하지 않습니다.

from dataclasses import dataclass

# 영향 범위(blast radius)에 따라 도구의 등급을 나눕니다. 목록에 없는 것은 기본적으로 거부(Default-deny)합니다.
...

표준적인 Anthropic 도구 사용 루프(tool-use loop)에 연결하면 다음과 같습니다:

import anthropic

client = anthropic.Anthropic()
...

겉보기보다 더 중요한 두 가지 세부 사항:

• 알 수 없는 도구에 대한 기본 거부(Default-deny). 게이트의 실패 모드는 "안전한 도구에 대해 짜증 날 정도로 질문하는 것"이어야 하며, "지난주에 추가하고 분류하는 것을 잊어버린 위험한 도구를 조용히 허용하는 것"이 되어서는 안 됩니다.
• 거부(denial) 결과는 도구 결과로서 대화에 다시 전달됩니다. 에이전트는 "아니오"라는 응답에 충돌(crash)하지 않습니다. 대신 운영자의 이유를 학습하고 계획을 재수립(re-plan)합니다. 거부는 하나의 정보입니다.

ask_human은 CLI 도구의 input()만큼 원시적일 수도 있고, 두 개의 버튼과 보류된 작업이 있는 Slack 메시지처럼 실제적일 수도 있습니다. 현재 프레임워크들은 이를 위한 1급(first-class) 버전을 제공합니다. LangGraph는 그래프를 일시 중지하고, 상태를 영속화하며, 인간의 입력에 따라 재개하는 interrupt() 원시 요소를 내장하고 있습니다. 하지만 이 패턴을 프레임워크 없이 구현하려면 40줄이 필요하며, 40줄짜리 버전이 감사(audit)하기 더 쉽습니다.

메커니즘 2: 실제로 구현할 수 있는 모호성 확인 (ambiguity check)

'모호성을 감지하다(Detect ambiguity)'는 연구팀이 필요한 것처럼 들립니다. ClarifyGPT의 트릭은 더 간단하고 효과적입니다. 모델을 여러 번 샘플링하여 답변들이 일치하는지 확인합니다. 그들의 설정에서는 여러 코드 솔루션을 샘플링하고, 동일한 입력에 대해 해당 솔루션들이 다르게 동작하는지 테스트합니다. 행동적 발산(behavioral divergence)은 명세가 모호하다는 것을 의미합니다(논문).

일반적인 에이전트의 경우, 비용 효율적인 적응 방안은 코드 자체가 아니라 _계획(plan)_을 샘플링하는 것입니다:

import re

PLAN_PROMPT = (
...

만약 높은 온도(high-temperature)로 설정된 네 개의 샘플이 모두 동일한 행동에 전념한다면, 요청은 충분히 구체적입니다—진행합니다. 만약 이들이 발산한다면, 당신은 모호성에 대한 구체적인 증거를 얻었을 뿐만 아니라, 어떤 읽기(reading)가 충돌하는지 정확히 알기 때문에 훌륭한 명확화 질문을 위한 원자재도 갖게 됩니다:

CLARIFY_PROMPT = (
    "사용자가 요청한 내용: {task}\n"
    "합리적인 읽기로 인해 다른 행동이 도출되었습니다: {plans}\n"
...

비용: 작은 max_tokens를 가진 k개의 짧은 탐색 호출(probe calls)만 사용하면 됩니다. 저렴한 모델을 사용한다면 더욱 좋습니다—잘못된 되돌릴 수 없는 행동 하나에 비할 바가 못 됩니다. 저는 이 기능을 오직 CONFIRM 등급의 도달(reach)이 예상되는 작업에 대해서만 실행합니다. 읽기 전용 작업에는 필요하지 않습니다.

메커니즘 3: 자주가 아니라 잘 에스컬레이션하기 (escalate well, not just often)

실패 예산 (failure-budget) 코드는 위의 게이트(gate)에 있었습니다. 사람들이 건너뛰는 부분은 에스컬레이션 (escalation)이 무엇을 '말하는가'입니다. 멈춰서 200줄의 로그를 당신에게 쏟아붓는 에이전트는 기술적으로는 질문을 한 것이지만, 기능적으로는 당신이 그것을 무시하도록 가르치는 셈입니다. 제 에이전트의 모든 에스컬레이션은 반드시 다음과 같은 형태를 갖춰야 합니다:

차단됨 (BLOCKED): [한 줄 — 수행하려던 작업]
시도함 (Tried): [2~3가지 접근 방식, 각 한 줄씩, 에러와 함께]
판단 (Believes): [원인에 대한 최선의 추측]
...

기본값 (Default) 라인은 이 과정을 빠르게 유지하는 비결입니다. 대부분의 에스컬레이션이 한 단어짜리 인간의 답변으로 끝나게 함으로써, 인간이 실제로 계속 답변을 이어가게 만듭니다. "결정 가능한 하나의 질문 + 권장되는 기본값"이라는 형태는 ClarifyGPT가 코드 작업에서 효과적이라고 발견한 것과 동일하며, 당신이 문 앞에 서 있는 주니어 엔지니어에게 기대하는 것과도 같습니다.

솔직히 말해서, 이것이 이 포스트 전체의 멘탈 모델 (mental model)입니다. 당신이 의도한 것이 무엇이든 상관없이 제멋대로 행동하는 주니어는 위험합니다. 모든 것에 대해 질문하는 주니어는 지치게 만듭니다. 승진시켜야 할 주니어는 되돌릴 수 있는 일은 스스로 밀고 나가며, 행동이 되돌릴 수 없거나 정말로 명시되지 않았을 때 단 하나의 날카로운 질문을 들고 나타나는 사람입니다. OpenAI의 가이드는 인간의 개입을 신뢰성이 쌓임에 따라 점차 줄여나가는 (tune down) 것으로 정의합니다 (guide, April 2025) — 이것이 올바른 방향입니다. 넓은 범위의 확인 (CONFIRM) 단계로 시작하여, 모든 게이트 결정을 로그로 남기고, 로그상에서 확인 절차가 모두 형식적인 승인 (rubber stamps)이었음이 증명되면 도구의 권한을 허용 (ALLOW) 단계로 격상시키십시오.

하지만 게이트부터 시작하십시오. 언제 멈춰야 할지를 아는 에이전트만이 당신이 안심하고 실행을 맡길 수 있는 에이전트입니다.

저는 에이전트를 감독 없이 실행시키기 전에 적용하는 게이트 단계(gate tiers)와 위의 에스컬레이션 템플릿(escalation template)을 포함한 신뢰성 규칙(reliability rules) 전체 세트를 무료 extbf{Reliable Agent Field Guide}: penloomstudio.com/field-guide.html에 담아두고 있습니다. 만약 에이전트가 애초에 잘못된 도구(tool)를 호출하여 게이트가 계속 작동한다면, 그것은 대개 스키마(schema) 문제입니다. 제가 사용하는 린터(linter)와 스키마 패턴이 포함된 $2.99 도구 호출 신뢰성 팩(tool-calling reliability pack)이 준비되어 있습니다.