에이전트 검증: 예약, 결제 또는 전송 전 반드시 멈추세요

TL;DR

• 에이전트 검증 (Agent validation)은 예약, 결제 또는 무언가를 전송하는 것과 같은 모든 되돌릴 수 없는 동작(irreversible action)을 수행하기 전 반드시 거쳐야 하는 필수 체크포인트입니다.
• 검증이 없다면, 단 하나의 잘못된 데이터 포인트가 시스템 전체로 전파되며 이를 쉽게 되돌릴 수 없습니다.
• 이는 금융 브로커, 보험사, 그리고 에이전트가 실제 돈이나 실제 캘린더를 다루는 모든 이들에게 가장 중요합니다.

에이전트 검증 (Agent validation)은 AI 에이전트가 되돌릴 수 없는 동작을 수행하기 전에 일시 중지하고, 진행하기 전에 데이터가 깨끗한지 확인하는 패턴입니다. 예외는 없습니다.

왜 에이전트들은 먼저 확인하지 않고 행동할까요?

대부분의 에이전트는 안전이 아닌 속도를 최적화하도록 설계되어 있으며, 이는 되돌릴 수 없는 작업에 손을 대는 순간 문제가 됩니다.

음성 AI (Voice AI) 구축의 기본 자세는 다음과 같습니다: 데이터를 수집하고, 일을 처리한다. 빠른 것은 좋고, 마찰(Friction)은 나쁩니다. 그리고 이러한 논리는 에이전트가 잠재 고객을 잘못된 캘린더 슬롯에 예약하거나, 잘못된 번호로 확인 SMS를 발송하거나, 오타가 입력된 카드로 결제를 트리거하기 직전까지 유지됩니다. 이제 고객의 불만과 수동 정리 작업이 기다리고 있습니다. 둘 다 빠르지 않습니다.

문제는 AI가 아닙니다. "데이터 수집"과 "조치 실행" 사이에 게이트(gate)가 없다는 점입니다. 에이전트 검증 (Agent validation)은 그 게이트를 추가합니다.

에이전트 검증 단계는 실제로 어떤 모습인가요?

이는 데이터 수집 후와 액션 노드(action node) 실행 전 사이에 실행되는 함수로, 에이전트가 진행하기 전에 정의된 규칙에 따라 모든 필수 필드를 확인합니다.

실제로 에이전트 검증 (agent validation)은 워크플로 오케스트레이터 (workflow orchestrator) 내부에 위치합니다. N8N에서는 일반적으로 일련의 전제 조건 (preconditions)을 확인하는 IF 노드 또는 코드 노드 (Code node)로 구현됩니다. 모든 확인 절차가 'true'를 반환할 때까지 에이전트는 앞으로 나아가지 않습니다.

기본적인 검증 블록 (validation block)은 다음 사항들을 포함합니다:

• 필수 필드 (name, phone, email, appointment time)가 존재하며 비어 있지 않은지 확인
• 전화번호 형식이 실제 패턴과 일치하는지 확인 (예: 호주 번호, 0으로만 이루어진 문자열이 아님)
• 이메일이 구문 검사 (syntax check)를 통과하고 도메인이 명백하게 가짜가 아닌지 확인
• 충돌하는 데이터가 없는지 확인 (동일한 세션 내에서 두 개의 서로 다른 예약 시간이 캡처되는 경우)
• 외부 CRM이 데이터를 다시 쓰기 전에 리드 (lead) 레코드가 존재하는지 확인

만약 어떤 확인 절차라도 실패하면, 에이전트는 데이터 수집 단계를 재시도하거나 사람에게 연결 (route)합니다. 절대로 다음 단계로 진행하지 않습니다.

에이전트 검증은 더 넓은 아키텍처의 어디에 위치하는가?

검증은 대화 레이어 (conversational layer)와 통합 레이어 (integration layer) 사이의 경계에 위치해야 하며, 프롬프트 (prompt) 내부에 있거나 마지막에 덧붙여지는 형태여서는 안 됩니다.

이것이 대부분의 초보 운영자들이 저지르는 실수입니다. 그들은 LLM 프롬프트 자체 내에서 검증을 처리하려고 시도합니다. "예약하기 전에 전화번호가 유효한지 확인하세요."라고 말하는 식입니다. 그것은 에이전트 검증이 아닙니다. 그것은 하나의 제안일 뿐입니다. 모델이 이를 따를 수도 있고, 따르지 않을 수도 있습니다. 그리고 프롬프트는 코드 블록을 테스트하는 것과 같은 방식으로 단위 테스트 (unit test)를 할 수 없습니다.

진정한 에이전트 검증은 지침 (instructions)이 아니라 코드 (code)입니다. 이는 결정론적 (deterministically)으로 실행됩니다. 매번 모호함 없이 통과(pass) 또는 실패(fail)를 판정합니다.

만약 Postgres에 통화 상태 (call state)를 저장하고 있다면, 검증 (validation) 단계에서 해당 상태를 읽어와 프롬프트 계층 (prompt layer)에서는 절대 볼 수 없는 예외 케이스 (edge cases)를 잡아낼 수도 있습니다. Postgres에 상태를 저장하는 프로덕션 에이전트 (Production agents that store state in Postgres)에서 이 패턴을 자세히 다룹니다. 그리고 조용히 실패하는 모든 검증 호출에 대해, 실패한 호출 이벤트를 위한 데드 레터 큐 (dead letter queue for failed call events)를 사용하면 리드 (lead)를 놓치지 않고 복구할 수 있는 재생 (replay) 능력을 제공합니다.

ACMA 또한 아웃바운드 통신 (outbound communications)에 대한 동의 및 연락 기록에 관한 요구 사항을 가지고 있습니다. 에이전트 검증 (Agent validation)은 아웃바운드 작업이 실행되기 전에 이러한 플래그 (flags)를 확인하기에 매우 자연스러운 지점입니다.

이 게이트 (Gate)를 추가할 때의 트레이드오프 (Trade-off)는 무엇인가요?

에이전트 검증은 약간의 지연 시간 (latency)과 구축 복잡성 (build complexity)을 추가합니다. 그것이 트레이드오프의 전부입니다. 이는 매우 쉬운 선택입니다.

검증 단계가 추가되면 단계가 하나 더 늘어납니다. 실제 통화 중이라면, 에이전트가 예약을 확정하기 전에 잠시 멈칫할 수도 있음을 의미합니다. 괜찮습니다. 통화자는 그 짧은 멈춤을 눈치채지 못합니다. 하지만 잘못된 예약이나 낯선 사람의 번호로 전송된 확인 SMS는 눈치챕니다.

구축 측면에서는 검증 함수 (validation function)를 작성하고 유지 관리해야 합니다. 복잡한 코드는 아닙니다. 하지만 워크플로 (workflow)에서 실제로 사용하는 필드 (fields)와 항상 동기화되어 있어야 합니다. 만약 우편번호가 필요한 새로운 연동 (integration)을 추가한다면, 에이전트 검증 블록 (agent validation block)도 이를 알고 있어야 합니다.

원칙은 이렇습니다: 에이전트 워크플로에 되돌릴 수 없는 작업 (irreversible action)을 추가할 때마다, 그 앞에 상응하는 검증 규칙 (validation rule)을 추가하십시오. 예외는 없습니다. "나중에 추가하자"도 안 됩니다. "이건 위험도가 낮으니까"도 안 됩니다. 쉽게 되돌릴 수 없는 모든 작업에는 반드시 게이트 (gate)를 설치해야 합니다.

핵심 요약 (Key Takeaways)

• 에이전트 검증 (Agent validation)은 프롬프트 지시 사항 (prompt instruction)이 아니라 결정론적인 코드 체크 (deterministic code check)입니다. 이는 모든 예약, 결제 또는 전송 작업 전에 실행됩니다.
• 이를 워크플로 (workflow) 내의 별도 노드 (discrete node)로 구축하여, 대화 계층 (conversational layer)과 통합 계층 (integration layer) 사이에 배치하십시오.
• 워크플로에 추가되는 모든 새로운 되돌릴 수 없는 작업에는 그에 상응하는 검증 규칙 (validation rule)이 필요합니다. 이를 타협 불가능한 사항으로 취급하십시오.

금융, 보험 또는 부동산 고객을 위한 음성 에이전트 (voice agents)를 구축하고 있으며, 귀하의 검증 계층 (validation layer)이 어떻게 연결되어 있는지에 대해 제2의 시각을 원하신다면, 저에게 AUDIT이라고 DM을 보내주세요. 일반적으로 격차가 발생하는 지점을 보여주는 다섯 가지 질문을 보내드리겠습니다.

원문은 theautomate.io에 게시되었습니다.