5.2에스컬레이션과 모호성 처리

에이전트 설계에서 가장 자주 마주치는 긴장은 자율성과 안전성의 균형입니다. 기준 없이 만들면 모델은 극단 중 하나로 치우칩니다. 사소한 것까지 확인을 구해 사용자를 지치게 하거나, 위험한 가정을 조용히 밀어붙입니다.

실무 기준선은 **행동의 되돌리기 가능성(reversibility)**과 가정의 확신도라는 두 축으로 세웁니다.

• 되돌릴 수 있고 요청 범위 안인 작업: 진행합니다. 코드 수정, 임시 파일 생성, 읽기 작업이 여기 속합니다.
• 되돌리기 어렵거나 외부에 노출되는 작업: 확인을 받습니다. 배포, 이메일 발송, 데이터 삭제, 과금이 발생하는 API 호출이 대표적입니다.
• 요청 해석이 갈리는 지점: 합리적 기본값이 있으면 그것을 선택하고 선택했음을 보고합니다. 기본값이 없고 해석에 따라 결과가 크게 달라지면 질문합니다.

이 기준은 시스템 프롬프트에 명시적으로 넣어야 합니다. 모델의 암묵적 판단에 맡기면 세션마다 다르게 행동합니다.

[시스템 프롬프트 발췌]
- 파일 수정·생성은 확인 없이 진행한다.
- 다음 행동은 반드시 사용자 승인을 받는다:
  배포, 외부 발송, 삭제, 결제, 권한 변경.
- 지시가 모호할 때: 합리적 기본값이 있으면 선택 후
  "~로 가정했습니다"라고 보고하고, 없으면 선택지를
  2~3개로 좁혀 질문한다.

시험에서는 "항상 사용자에게 확인받는다"와 "항상 자율적으로 진행한다" 둘 다 오답이며, 행동의 성격에 따라 기준을 나누는 선택지가 정답인 패턴이 반복됩니다.

모호한 입력은 유형에 따라 대응이 다릅니다.

1. 누락된 정보(missing information): "보고서를 만들어줘"에서 대상 기간이 없는 경우입니다. 관찰 가능한 맥락(최근 파일, 이전 대화)에서 추론할 수 있으면 추론하고 가정을 명시합니다. 추론 근거가 전혀 없으면 질문합니다.

2. 상충하는 지시(conflicting instructions): "테스트를 모두 통과시키되 코드는 수정하지 마라"처럼 동시에 만족할 수 없는 경우입니다. 이때는 조용히 한쪽을 무시하면 안 되고, 충돌을 보고하고 우선순위를 확인해야 합니다. 에이전트가 임의로 한쪽을 버리면 사용자는 나머지 지시가 지켜졌다고 믿게 됩니다.

3. 다의적 표현(ambiguous reference): "그 파일 지워줘"에서 후보가 여럿인 경우입니다. 파괴적 행동과 결합된 다의성은 반드시 확인 대상입니다. 반대로 읽기 작업의 다의성은 가장 그럴듯한 후보를 선택해 진행해도 위험이 낮습니다.

질문을 할 때도 품질이 중요합니다. 열린 질문("어떻게 할까요?")보다 선택지를 좁힌 질문이 사용자 부담을 줄입니다.

나쁨: "어떤 방식으로 인증을 구현할까요?"
좋음: "인증 방식을 확인해 주세요:
  (A) 기존 세션 쿠키 재사용 — 변경 최소
  (B) JWT 도입 — 모바일 앱 대비 가능, 마이그레이션 필요
  A를 권장합니다. 이유: 현재 코드베이스가 세션 기반입니다."

권장안과 근거를 함께 제시하는 것이 표준 패턴입니다.

자동화된 파이프라인(CI, 배치 작업, 무인 에이전트)에서는 질문할 사용자가 실시간으로 없습니다. 이 경우 에스컬레이션은 "질문"이 아니라 구조화된 실패 처리로 설계해야 합니다.

핵심 요소는 세 가지입니다.

1. 명시적 에스컬레이션 채널: 에이전트에게 "막히면 어디로 보고하는가"를 툴로 제공합니다. 예를 들어 escalate_to_human 툴을 정의하면, 모델이 불확실할 때 임의 행동 대신 이 툴을 호출하게 됩니다.

{
  "name": "escalate_to_human",
  "description": "확신이 없거나 승인이 필요한 상황에서 사람에게 검토를 요청한다. 되돌리기 어려운 작업 전 확신이 서지 않으면 반드시 이 툴을 사용할 것.",
  "input_schema": {
    "type": "object",
    "properties": {
      "reason": { "type": "string", "description": "에스컬레이션 사유" },
      "blocked_action": { "type": "string", "description": "보류 중인 작업" },
      "recommendation": { "type": "string", "description": "권장 처리안" }
    },
    "required": ["reason", "blocked_action"]
  }
}

2. 안전한 기본 동작(safe default): 에스컬레이션 후 응답이 없을 때의 동작을 정합니다. 원칙은 "확신이 없으면 아무것도 바꾸지 않는다"입니다. 부분 완료 상태로 멈출 때는 어디까지 했는지 기록을 남깁니다.

3. 에스컬레이션 정보의 품질: 사람이 받아보는 에스컬레이션에는 상황 요약, 시도한 것, 막힌 이유, 권장안이 담겨야 합니다. "실패했습니다"만 보고하는 에이전트는 사람의 디버깅 비용을 늘립니다.

시험 함정: "무인 파이프라인에서는 에이전트가 항상 최선의 추측으로 진행해야 한다"는 오답입니다. 무인 환경일수록 안전한 기본 동작과 에스컬레이션 채널이 더 중요해집니다.

에스컬레이션 기준을 "확신이 없을 때"로 정의하면, 모델의 확신도 표현을 신뢰할 수 있어야 합니다. 그러나 언어 모델의 자체 보고 확신도는 완벽히 캘리브레이션되어 있지 않습니다. 이를 보완하는 실무 기법은 다음과 같습니다.

• 근거 기반 확신도: "확신도를 0~1로 답하라" 대신 판단의 근거를 먼저 서술하게 한 뒤 확신 수준을 분류하게 합니다. 근거를 명시하는 과정 자체가 성급한 확신을 줄입니다.
• 검증 가능성 우선: 확신도 자체보다 검증 수단이 있는지를 기준으로 삼습니다. 테스트를 돌려볼 수 있는 코드 수정은 확신도가 낮아도 진행 후 검증하면 되고, 검증 불가능한 대외 발송은 확신도가 높아도 확인을 받는 식입니다.
• 이중 경로 설계: 확신도가 임계값 이상이면 자동 진행, 미만이면 사람 검토 큐로 보내는 분류 파이프라인이 대표적입니다. 이때 임계값은 실제 오류율 데이터를 보고 조정해야 하며, 초기에는 보수적으로(낮은 자동화율로) 시작하는 것이 안전합니다.

result = classify(document)
if result.confidence == "high" and result.evidence:
    auto_process(result)
else:
    review_queue.add(document, result)  # 사람 검토로 우회

이 주제는 5.5 휴먼 리뷰 캘리브레이션과 이어집니다. 시험에서는 "모델이 확신한다고 답하면 검증 없이 진행해도 된다"가 전형적 오답입니다.