왜 0.9 같은 매직 넘버는 항상 실패할까

대부분의 AI 에이전트 설정 파일에는 이런 한 줄이 있어요.

ESCALATION_THRESHOLD = 0.90

이 위면 에이전트가 혼자 처리하고, 아래면 사람에게 넘깁니다. 단순하고, 조정하기 쉽고, 뭔가 자율성을 통제하고 있다는 느낌도 들죠.

문제는 이게 틀린 프레임이라는 겁니다. 더 좋은 숫자를 찾는 게 답이 아니에요. 에스컬레이션 임계값은 애초에 퍼센트가 아니었어요. **가격(price)**이었습니다.

대부분의 팀이 "에이전트가 이걸 할 수 있나?"라는 역량 질문을 던져요. SQL을 쓸 수 있나? 환불을 처리할 수 있나? 가능하면 돌려버립니다. 하지만 "할 수 있다"와 "혼자 해도 된다"는 완전히 다른 문제예요. 후자는 비용 질문입니다.

  • 에이전트가 처리하면 → 실수 비용(Error Cost)을 리스크로 짊어진다
  • 사람에게 넘기면 → 에이전트가 맞았든 틀렸든 사람 시간 비용(Escalation Cost)을 지불한다

이 두 숫자만 있으면 나머지는 거의 민망할 정도로 단순해져요. (근거자료: Towards Data Science 원문)

Developer configuring AI agent confidence threshold in code editor with escalation logic IT Technology Image

실제 임계값은 '비율'이다 (Chow's Rejection Rule, 1970)

인간이 에스컬레이션된 티켓을 항상 올바르게 처리한다고 가정해봅시다. 에이전트가 혼자 행동해야 하는 조건은 다음과 같아요.

(1 - p) × ErrorCost  <  EscalationCost

여기서 p = 에이전트가 정답일 확률

이걸 p에 대해 정리하면:

p  >  1 - (EscalationCost / ErrorCost)

이 우변 값이 진짜 임계값입니다. 여기서 주목할 점은:

  • 모델 성능에 의존하지 않는다
  • 워크숍에서 정한 정책에 의존하지 않는다
  • 단지 두 비용의 비율에만 달려 있다

실수가 싸면 임계값이 낮아지고 에이전트가 더 자주 혼자 행동해도 됩니다. 실수가 비싸면 임계값이 올라가고, 아무리 자신감 넘치는 에이전트라도 사람에게 물어봐야 해요.

고정 컷오프는 이 비율이 모든 결정에 대해 동일하다고 가정합니다. 그런 경우는 거의 없어요.

두 개의 티켓 예시

숫자는 논증용으로 만든 것이지만 구조는 실제와 같아요.

케이스 A — 평범한 환불 요청

  • 실수 시 정리 비용: £15 (후속 티켓 + goodwill credit)
  • 에스컬레이션 비용: £4 (전문가 3분)
  • 임계값 = 1 - 4/15 ≈ 0.73
  • 에이전트 신뢰도 90% → 혼자 처리해야 함

케이스 B — 계정 탈취 의심

  • 실수 시 정리 비용: £2,000 (사기 손실, 규제 대응, 이탈 고객)
  • 에스컬레이션 비용: £4
  • 임계값 = 1 - 4/2000 ≈ 0.998
  • 에이전트 신뢰도 90% → 반드시 에스컬레이션

같은 에이전트, 같은 90%, 정반대의 정답입니다. 0.9 룰은 두 경우 모두 혼자 처리하라고 지시하고, 두 번째 케이스에서 티켓당 £196을 조용히 태워버려요.

코드로 본 규칙

# 교육용 예시입니다. 프로덕션 코드가 아닙니다.
def should_act_alone(p_correct: float, error_cost: float, escalate_cost: float) -> bool:
    """
    Chow의 rejection rule 기반 결정.
    p_correct는 반드시 캘리브레이션된 확률이어야 함.
    """
    threshold = 1 - (escalate_cost / error_cost)
    return p_correct > threshold

# 케이스 A: 평범한 환불
assert should_act_alone(0.90, error_cost=15, escalate_cost=4) is True

# 케이스 B: 계정 탈취 의심
assert should_act_alone(0.90, error_cost=2000, escalate_cost=4) is False

함수 안에는 화려한 게 없어요. 정말 중요한 건 세 입력값을 어떻게 고르느냐입니다. 매직 넘버가 0.85냐 0.92냐를 두고 싸우는 데 시간을 쓰지 마세요.

Data analyst reviewing calibration chart comparing stated confidence versus actual accuracy of AI agent Programming Illustration

함정 1: 캘리브레이션 (Confidence ≠ Calibration)

위 산수는 전부 하나의 가정 위에 서 있어요. 에이전트가 90%라고 말할 때, 실제로 90% 맞는다는 가정.

이게 캘리브레이션이고, confidence와는 다릅니다.

  • Confidence: 모델이 뱉는 숫자
  • Calibration: 그 숫자가 실제로 의미가 있는지

만약 stated 0.95가 실제로는 0.70이라면? 기대 오차 비용은 산수의 6배입니다. 그렇게 정성껏 계산한 임계값은 픽션이 돼요. 리스크를 관리하는 게 아니라, 확률처럼 생긴 숫자로 리스크를 세탁하는 겁니다.

캘리브레이션 체크 절차

  1. 모든 결정을 stated confidence와 함께 로깅
  2. 결정 클래스별로 confidence band 구간화
  3. 각 구간에서 stated vs. realized accuracy 비교
  4. 90%라고 했는데 78%가 맞다면 그 갭을 매핑 (Isotonic regression 또는 Platt scaling)

주의할 점 두 가지:

  • 에이전트는 희귀하고 고위험인 클래스에서 캘리브레이션이 최악인 경우가 많아요. 정확히 그 클래스가 극단적 임계값을 들고 있죠. 글로벌 평균은 중요한 실패를 숨깁니다.
  • 티켓 믹스가 바뀌면 매핑도 드리프트합니다. 스케줄에 맞춰 재측정하세요.

함정 2: 에스컬레이션 비용은 생각보다 훨씬 비싸다

에스컬레이션 비용 ≠ 분 × 시급이 아닙니다.

  • 에스컬레이션은 큐에 쌓이고, 큐는 혼잡해져요
  • 더 나쁜 건 과잉 에스컬레이션이 리뷰어를 도장 찍는 기계로 만든다는 겁니다
  • 한 시간에 평범한 환불 40건을 보내면, 일주일 안에 아무도 안 읽어요

모든 걸 승인하는 인간은 통제 장치가 아니라 의례(ritual)입니다. 볼륨이 커질수록 이 갭은 벌어져요.

함정 3: 인간도 틀린다

아까 미뤄둔 가정을 꺼내봅시다. 전문가의 오류율을 h라고 하면:

(1 - p) × ErrorCost  <  EscalationCost + h × ErrorCost

보통 h는 무시할 만큼 작지만, 진짜 애매한 티켓에서는 그렇지 않아요. 이 경우 임계값이 에이전트 쪽으로 다시 기웁니다. 의외로 많은 분들이 이 부분에서 놀라워하더라고요.

Security engineer evaluating cost-based escalation threshold for account takeover detection in AI triage system Dev Environment Setup

실무 적용 절차 (5단계)

  1. 결정 클래스 그룹화 — 실수 비용이 비슷한 것끼리 묶기. 환불은 환불끼리, 보안 사고는 보안 사고끼리.
  2. 각 클래스에 가격 매기기 — 에이전트 만든 사람 말고, 뒷정리하는 사람에게 물어보세요. 파이낸스와 서포트 옵스가 엔지니어링보다 이 숫자를 훨씬 잘 압니다. 그리고 대개 누가 물어봐줘서 좋아해요.
  3. 에스컬레이션 비용 추정 — 혼잡과 도장 찍기 효과 포함해서.
  4. 캘리브레이션된 확률을 규칙에 사용 — raw score 말고.
  5. 클래스별 임계값 도출, 비용이 움직이면 같이 움직이게 — 새로운 사기 패턴이 등장하면 보안 실수 가격이 올라가고, 임계값도 자동으로 올라갑니다. 회의 필요 없음. 도출된 것이지, 선포된 게 아니니까.

한국 개발 생태계에서의 적용 맥락

국내 SI·금융권 환경에서는 이 접근이 특히 중요합니다. 왜냐하면:

  • 감사(Audit) 요구사항 때문에 "왜 이 결정을 에이전트에 맡겼는가"를 설명해야 하는데, "0.9 넘어서요"는 답이 안 됩니다. "실수 비용 대비 에스컬레이션 비용이 낮아서"는 답이 됩니다.
  • 규제 산업(금융, 의료, 공공)에서는 클래스별로 임계값을 다르게 가져가는 게 컴플라이언스 방어에 유리해요.
  • 반대로 초기 스타트업에서는 에스컬레이션 비용이 사실상 창업자 시간이라 비율이 극단적으로 낮아집니다. 이 경우 거의 모든 걸 에이전트에 맡기는 게 합리적이에요.

이 접근의 한계

솔직히 말하면:

  • 비용 추정 자체가 어렵습니다. 특히 규제 리스크나 브랜드 리스크처럼 정량화가 힘든 항목은 숫자로 만들기가 괴로워요.
  • 클래스 경계가 흐릿한 경우가 많아요. "계정 탈취 의심"과 "평범한 비밀번호 재설정"은 스펙트럼이죠.
  • 캘리브레이션 측정 비용이 만만치 않습니다. 특히 롱테일 클래스는 샘플이 안 모여요.

그래도 이 방식의 진짜 장점은 논쟁의 축을 바꾼다는 겁니다. "0.85가 맞아, 0.92가 맞아?"라는 끝없는 싸움 대신, "이 실수의 가격은 얼마야?"라는 답할 수 있는 질문으로 넘어가요.

다음 단계 학습 방향

  • Learning to Defer 연구 라인 (Chow 1970 → Geifman & El-Yaniv 2017 → 최신 selective prediction 논문)
  • Calibration 기법: Temperature scaling, Isotonic regression, Platt scaling
  • Cost-sensitive learning: 클래스별 비용 행렬을 학습에 반영하는 방법

마무리

"내 에이전트가 혼자 행동하기 전에 얼마나 자신감 있어야 하나?"는 답할 수 없는 질문입니다. 명세가 부족하니까요.

"여기서 잘못된 판단의 비용은 얼마고, 물어보는 비용은 얼마인가?"는 답할 수 있습니다.

임계값을 가격으로 설정하세요. 퍼센트는 알아서 정리됩니다.

함께 보면 좋은 글

본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.