이메일 에이전트를 위한 Human-in-the-Loop 설계

환불 요청이 고객 지원 에이전트의 대기열에 도착했습니다. 지식 베이스 (knowledge-base) 매칭 결과는 0.91의 신뢰도(confidence)로 나타났습니다. 이는 초안 작성 임계값(drafting threshold)을 여유롭게 상회하며, 환불 정책에 관한 깔끔한 문서가 첨부되어 있습니다. 하지만 에이전트는 여전히 그 답장을 보내서는 안 됩니다. 만약 이 문장이 틀린 것처럼 들린다면, 이 포스트는 왜 그것이 옳은지에 대한 논거를 제시할 것입니다.

자율성(Autonomy)은 스위치가 아니라 다이얼입니다

대부분의 팀은 Human-in-the-loop를 이진법(binary)으로 정의합니다. 즉, 에이전트가 스스로 이메일을 보내거나, 혹은 사람이 모든 것을 승인하거나 둘 중 하나라고 생각합니다. 이러한 프레임워크는 양쪽 방향 모두에서 실패합니다. 모든 것에 대해 완전 자동화(Full-auto)를 적용하면, 단 하나의 잘못된 답장이 이사회 보고서(board deck)에 스크린샷으로 찍히게 됩니다. 반대로 모든 것에 대해 완전 검토(full-review)를 적용하면, 누구의 시간도 절약해주지 못하는 값비싼 초안 생성기를 만든 셈이 됩니다.

더 나은 모델은 에이전트 단위가 아니라, 메시지 유형(message type)별로 설정된 다이얼(dial)입니다. 동일한 지원 에이전트라도 주문 상태 조회에는 완전 자율(fully autonomous)로 작동하고, 결제 관련 질문에는 초안 작성 후 승인(draft-and-approve) 방식으로 작동하며, 법적 효력이 있는 모든 사항에는 수동 에스컬레이션(hands-off-escalate) 방식으로 작동할 수 있습니다. 이메일 지원 에이전트 레시피는 각 메시지에 대해 다이얼의 위치를 결정하는 두 개의 독립적인 게이트(gate)를 통해 정확히 이를 구현합니다.

첫 번째 게이트: 신뢰도 (confidence)

첫 번째 게이트는 기계적인 부분입니다. 지식 베이스 매칭이 얼마나 확실한가 하는 점입니다. 레시피의 임계값은 다음과 같습니다:

신뢰도 (Confidence)	조치 (Action)
≥ 0.85	매칭된 문서로부터 직접 초안 작성
...

중간 단계가 영리한 부분입니다. 인용이 필요한 초안(Citation-required drafts)은 검토자가 자신의 정밀도를 조정할 수 있게 해줍니다. 높은 신뢰도의 뭉치는 신뢰하고, 인용된 것들은 확인하며, 낮은 신뢰도의 것들은 직접 작성하는 방식입니다. 이것이 검토 작업이 또 다른 풀타임 업무가 되지 않도록 유지해 주는 비결입니다.

두 번째 게이트: 리스크(risk) — 그리고 이는 우선권을 가집니다

두 번째 게이트는 결과(consequences)에 관한 것이며, 첫 번째 게이트가 무엇이라고 말했든 상관하지 않습니다:

• Low (낮음) — 비밀번호 재설정, FAQ 형태의 질문 → 초안(draft) 작성, 사람이 승인.
• Medium (중간) — 환불, 계정 변경, 결제와 관련된 모든 사항 → 초안(draft) 작성, 사람이 추가적인 주의를 기울여 승인.
• High (높음) — 법적 위협, 규제 관련 사항, 사기 보고 → 초안(draft)을 아예 작성하지 않음; 즉시 모든 맥락을 파악하고 있는 담당자에게 에스컬레이션(escalate).

이것이 바로 신뢰도(confidence)가 0.91인 환불 답변이 발송되지 않는 이유입니다. 환불은 매칭 품질과 상관없이 중간 위험(medium-risk)에 해당합니다. 신뢰도는 "우리가 정답을 알고 있는가?"를 측정하는 반면, 위험은 "우리가 틀렸을 때 어떤 일이 발생하는가?"를 측정합니다. 이 둘은 직교(orthogonal)하는 질문이며, 이를 혼동하는 것이 에이전트가 귀하의 회사를 어떤 상황에 구속되게 만드는 방식입니다. 정확히 이러한 실패에 대해 널리 인용되는 항공사 챗봇 판결 사례가 있습니다: 봇이 존재하지 않는 환불 정책을 약속했고, 회사는 그 약속을 지켜야 했습니다.

초크 포인트 (The choke point)

코드상에서 전체 정책은 매우 작습니다:

def handle(msg):
    question = extract_question(msg)
    article, conf = kb.search(question)
...

여기서 무엇이 빠져 있는지 주목하십시오: 발송(send) 호출입니다. queue_for_approval이 바로 초크 포인트(choke point)입니다. 프로덕션 환경에서 이는 초안(draft)을 Slack이나 검토 도구로 떨어뜨릴 뿐, 절대 발송함(outbox)으로 직접 보내지 않습니다. 이 레시피는 핵심적인 제약 사항을 명시하고 있습니다: 전송하기 전에 항상 초안을 보여주어야 하며, 절대 자동 전송하지 마십시오. 다른 모든 규칙은 조정할 수 있지만, 이 규칙을 제거하면 그것은 더 이상 게이트(gate)가 아니라 지연(delay)일 뿐입니다.

만약 에이전트가 이를 실행할 자체 메일함을 갖게 하려 한다면, 현재 베타 버전인 Agent Accounts는 에이전트가 엔드 투 엔드(end-to-end)로 소유하는 support@ 아이덴티티를 위한 자연스러운 안식처가 됩니다. 또한 이는 초크 포인트에 네이티브 구현을 제공합니다: Drafts API는 완전한 CRUD를 지원하므로, 에이전트는 자신의 메일함에 초안을 생성할 수 있고, 검토자는 이를 수정할 수 있으며, 승인 시 기존 초안이 발송됩니다. 즉, 초안에 대한 발송 동작은 일반적인 발송과 정확히 동일하게 작동합니다. 대기 중인 답변은 Slack에 붙여넣은 스크린샷이 아니라, 대화가 존재하는 곳에 그대로 머뭅니다.

코딩하는 대신 정책을 선언하기

동일한 게이트(gates)가 설정(configuration)으로서 작동합니다. 만약 에이전트가 스킬 파일(skill-file) 플랫폼에서 실행된다면, 레시피는 전체 정책을 코드가 아닌 SKILL.md 형태로 보여줍니다:

# 지원 에이전트 (Support agent)

## 답변 스타일 (Reply style)
...

이 정책이 마치 신입 사원을 위한 온보딩 문서(onboarding doc)처럼 읽힌다는 점에 주목하십시오. 이는 올바른 직관입니다. 초안 작성 규칙(drafting rules) 섹션은 앞서 언급한 다이얼(dial)을 평이한 영어로 작성한 것이며, "전송 전 항상 초안을 표시할 것"이라는 내용도 여기에 포함됩니다. 이는 모든 리팩터링(refactor) 과정에서도 유지되기 때문입니다. 즉, 이는 특정 구현의 속성이 아니라 시스템의 속성입니다.

천천히 다이얼을 풀기

Human-in-the-loop(인간 참여형)는 영구적인 세금이 아닙니다. 이는 더 많은 자동화를 위해 데이터를 확보하는 방법입니다. 레시피의 단계별 수치(shakedown numbers)는 다음과 같습니다. 매처(matcher)와 리스크 분류기(risk classifier)를 조정하는 동안에는 사이클당 5개의 티켓을 처리하고, 오탐률(false-positive rate)이 수용 가능한 수준이 되면 20개로 늘립니다. 5~15분마다 폴링(polling)하는 것만으로도 고객 지원 지연 시간(latency) 측면에서는 충분하며, 공유 편지함(shared inbox)에서 웹훅 팬아웃(webhook fan-out)을 구현하는 것보다 간단합니다.

두 가지 관행이 이러한 완화 조치를 정당화할 수 있게 합니다. 첫째, 모든 것—모든 분류, 지식 베이스(KB) 조회, 승인 결정—을 로그(log)로 남기십시오. 그래야 메시지 유형을 '초안 작성 및 승인(draft-and-approve)'에서 '완전 자동(full-auto)'으로 전환하겠다고 제안할 때, 막연한 느낌(vibes)이 아니라 수천 개의 기록된 승인 데이터를 근거로 주장할 수 있습니다. 둘째, 에이전트가 매칭하지 '못하는' 것을 추적하십시오. 해당 티켓들은 누락된 지식 베이스(KB) 문서의 지도가 됩니다.

반론 또한 경청할 가치가 있습니다. 검토 피로(review fatigue)는 실재하며, 사람이 하루에 200개의 초안을 기계적으로 승인(rubber-stamping)하는 것은 게이트로서의 역할을 거의 수행하지 못합니다. 이에 대한 두 가지 해답이 있습니다. 첫째, 공격적으로 계층화(tier)하십시오. 진정으로 안전한 계층은 자동화하여 인간의 주의력이 결과에 변화를 줄 수 있는 곳에 집중되도록 하고, 반복적인 작업은 일괄 처리(batch)하십시오. 예를 들어 "제 영수증 어디 있나요?"라는 티켓이 연속으로 3개 도착한다면, 이는 3번의 작업이 아니라 하나의 지식 베이스(KB) 문서, 하나의 초안 템플릿, 그리고 한 번의 검토 과정으로 처리됩니다. 둘째, 게이트가 실제로 무엇으로부터 방어하고 있는지를 기억하십시오. 레시피는 이를 직설적으로 표현합니다. 정확도가 99%라 할지라도, 법적 약속(legal commitments)을 하게 만드는 나머지 1%는 99%가 쌓아 올린 신뢰를 순식간에 무너뜨립니다. 피로는 업무 설계(workload-design)의 문제이며 업무 설계로 해결해야 합니다. 하지만 그 1%는 그렇지 않습니다.

이번 주에는 여러분이 직접 운영하는 에이전트의 메시지 유형을 세 가지 위험 계층(risk tiers)으로 분류해 보고, 각 계층별로 조절 장치(dial)를 설정해 보십시오. 현재 여러분은 어떤 메시지 유형을 과도하게 검토(over-reviewing)하고 있습니까? 그리고 솔직히 말해서, 어떤 유형이 완전 자동화(full-auto) 상태로 두어서는 안 되는 유형입니까?