보이스 에이전트를 위한 안전한 발신자 신원 인증 플로우 설계

보이스 에이전트는 단순한 FAQ 응답자에서 계정 수정, 거래 처리, 민감한 고객 데이터 접근 등 실제 행동을 수행하는 시스템으로 빠르게 발전하고 있습니다. 이 변화는 중요한 과제를 가져옵니다: 기존의 시각적 인증 방법이 없는 대화형 AI 시스템에서 어떻게 발신자 신원을 확인할 수 있을까요?

보이스 에이전트가 구독을 변경하거나, 계좌 잔액을 조회하거나, 환불을 시작할 수 있다면, 반드시 사람 상담원과 동일한 수준의 인증을 음성 기반 상호작용만으로 수행해야 합니다. 사람 상담원은 회사 정책을 따르지만, AI 에이전트는 LLM의 판단이 아닌, 도구 기반의 결정적인 인증이 필요합니다.

이 글에서는 엔터프라이즈 환경에서 Forward Deployed Engineer로 일하며 검증된 인증 패턴을 소개합니다. 임베디드 위젯용 세션 기반 인증부터 전화 전용 방식, OTP 인증까지 다섯 가지 핵심 접근법을 다루고, ElevenLabs 플랫폼에서 결정적인 워크플로 게이팅을 통해 각 방법을 구현하는 방법을 설명합니다.

무엇보다 인증을 대화 추론에 맡겨서는 안 되는 이유를 보여드립니다. 대신, 인증은 분리된 서브에이전트, 도구 기반 검증, 조건부 워크플로 라우팅을 통해 설계되어야 하며, 인증된 사용자만이 권한이 필요한 작업에 접근할 수 있도록 해야 합니다.

결정적인 인증을 위한 아키텍처적 기반

인증된 사용자만 계정 관련 정보에 접근할 수 있도록 하려면, ElevenLabs 워크플로를 통한 엄격한 환경 및 접근 분리가 필요합니다. 인증은 항상 불린 값(성공/실패)을 반환하는 도구 호출로 구현해야 하며, ElevenLabs 워크플로 빌더에서 디스패치 도구로 설정해야 합니다.

전달 조건을 도구 호출 결과에 직접 연결하면, 계정 데이터에 접근하는 서브에이전트는 인증이 성공한 후에만 접근할 수 있고, 인증되지 않은 사용자와는 완전히 분리됩니다. 이렇게 하면 인증이 LLM의 판단이 아닌 결정적으로 처리되며, 신원이 확인되지 않으면 다음 단계로 진행할 수 없습니다.

대안으로, 트랜스퍼 익스프레션(transfer expressions)을 신뢰할 수 있는 전달 방식으로 사용할 수 있습니다. 이 표현식은 도구 호출 결과로 업데이트되는 동적 변수를 참조합니다.

구현 예시

Salesforce에서 사용자 인증(도구 호출)을 진행합니다. 인증에 성공하면 Salesforce에서 고객 거래 데이터를 조회(또 다른 도구 호출)한 뒤, 이 데이터를 활용해 고객과 소통하고 필요한 추가 작업을 수행하는 서브에이전트로 사용자를 전달합니다.

사용자 신원 인증 방법

이러한 인증 방식은 ElevenLabs 플랫폼에서 기본적으로 지원하지 않습니다. CRM이나 백엔드/데이터베이스에 저장된 인증 데이터를 연동하는 서버 측 도구를 통해 구현할 수 있습니다.

호스트 애플리케이션 인증

웹사이트에 임베드된 보이스 에이전트의 경우, 호스트 애플리케이션이 사용자 세션 데이터(로그인 상태, 계정 ID, 세션 토큰 등)를 에이전트/위젯 초기화 시 동적 변수로 전달할 수 있습니다. 이 변수들은 도구 호출 시 자동으로 주입되어, 별도의 인증 없이도 통합 시스템에서 개인화된 데이터를 조회할 수 있습니다.

이 방식은 이미 호스트 애플리케이션에서 사용자가 인증되었기 때문에, 자연스러운 지원 플로우를 제공합니다. 커스텀 설정을 통해 직접 구성하거나, ElevenLabs 위젯을 사용해 런타임에 변수(예: <elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>)를 전달할 수 있습니다.

동적 변수(Dynamic Variables) 문서:

• https://elevenlabs.io/docs/agents-platform/customization/personalization/dynamic-variables#pass-variables-at-runtime 

지식 기반 인증(KBA)

보이스 에이전트가 발신자에게 계좌번호, 우편번호, 생년월일, 보안 질문 답변 등 인증 정보를 요청합니다. 서버 측 도구(웹훅 또는 클라이언트 측)가 데이터베이스(CRM 또는 신원 저장소 등)와 값을 대조해 확인합니다. 도구는 불린 상태(is_error)와 설명 텍스트가 포함된 성공/실패 결과를 반환합니다. 결정적인 워크플로 게이팅을 통해 구현할 수 있습니다: 필요한 정보를 요청한 뒤, 도구 디스패치를 설정하고, 도구의 성공/실패 상태에 따라 분기하는 조건부 워크플로 전환을 사용해 인증된 사용자를 '권한' 에이전트 노드로 라우팅합니다.

이 방식은 고정된 보안 질문과 동적 '지갑 외(out-of-wallet)' 스타일 인증 모두 지원하며, 사기 위험 수준에 따라 선택할 수 있습니다.

도구(Tools) 문서:

• https://elevenlabs.io/docs/agents-platform/customization/tools/server-tools 
• https://elevenlabs.io/docs/eleven-agents/customization/agent-workflows#dispatch-tool-node 

시스템 동적 변수(전화 전용)

전화 기반 대화(Twilio 또는 SIP 트렁크 사용)의 경우, 에이전트는 system__caller_id(발신자 전화번호) 등 전화 전용 시스템 변수를 자동으로 사용할 수 있습니다. 이 변수는 대화 시작 시 자동으로 채워지며, 두 가지 방식으로 참조할 수 있습니다: 1) 프롬프트/메시지에서: {{system__caller_id}}처럼 중괄호로 감싸서 사용하면 실제 값으로 대체됩니다. 2) 도구 파라미터에서: 도구 파라미터에 이 변수를 설정해, 프롬프트에서 언급하지 않고도 조용히 인증할 수 있습니다.

예를 들어, 도구를 설정해 발신자 ID를 CRM 조회 엔드포인트로 자동 전달하면, 에이전트가 들어오는 번호가 고객의 등록 번호와 일치하는지 조용히 확인해 사용자 인증을 할 수 있습니다. 도구 호출 대신, 대화 시작 전에 실행되는 대화 시작 웹훅으로 인증을 구성할 수도 있습니다.

보안 참고: 발신자가 등록된 번호와 다른 번호를 사용할 수 있거나, 저장된 번호가 무단 접근자에게 노출될 수 있으므로, 발신자 ID 기반 인증은 반드시 사전 고객 동의(opt-in)가 필요하거나 추가 인증 방식(예: 지식 기반 질문)과 함께 사용해야 합니다.

시스템 동적 변수 및 시작 웹훅 문서:

• https://elevenlabs.io/docs/agents-platform/customization/personalization/dynamic-variables#system-dynamic-variables 
• https://elevenlabs.io/docs/agents-platform/customization/personalization/twilio-personalization 

고급 지식 기반/보안 질문 인증

에이전트가 여러 보안 질문을 통해 사용자를 인증하고, 발신자가 미리 정해진 개수만큼 정답을 맞힐 때만 접근을 허용할 수 있습니다. 에이전트는 미리 정의된 질문 목록(예: 생년월일, 우편번호, 반려동물 이름 등)에서 무작위로 질문을 선택해, 도구 호출로 데이터베이스에서 답변을 검증할 수 있습니다.

인증 도구는 현재 성공 횟수가 포함된 JSON 응답을 반환합니다. 도구 할당을 통해 이 횟수는 자동으로 추출되어 동적 변수(예: auth_success_count)에 저장/업데이트됩니다. 매번 인증에 성공할 때마다 변수가 증가합니다.

필요한 인증 횟수(예: 3회)에 도달하면, 워크플로 표현식 조건이 동적 변수 값을 확인해 권한이 있는 서브에이전트 노드로 전환합니다. 이 표현식은 비교 연산자(예: auth_success_count >= 3)를 사용해 인증 상태에 따라 결정적으로 접근을 제어합니다.

관련 문서:https://elevenlabs.io/docs/eleven-agents/customization/agent-workflows#edges-and-flow-control 

일회용 코드

이 방식은 사용자의 기기로 SMS 또는 이메일을 통해 일회용 코드를 전송하는 범용 인증 방법입니다. 사용자는 받은 코드를 에이전트에게 전달해 인증을 완료해야 합니다.

구현 워크플로:

1. 코드 생성: 에이전트가 서버 도구 호출로 전용 엔드포인트에 요청을 보내면, 안전한 일회용 코드가 생성되어 사용자의 선호 채널(SMS 또는 이메일)로 전송됩니다.
2. 사용자 안내: 에이전트가 사용자가 받은 코드를 입력하도록 요청합니다. 음성 모드에서는 사용자가 코드를 말하면, 이를 음성 인식으로 받아들입니다.
3. 코드 검증: 에이전트가 사용자가 입력한 코드를 두 번째 도구 호출로 백엔드 검증 서비스에 전달합니다. 백엔드는 코드가 일치하는지, 만료되지 않았는지, 이미 사용된 적이 없는지 확인합니다.
4. 워크플로 라우팅: 에이전트는 검증 결과에 따라 다음과 같이 처리합니다. 성공: 코드가 올바르면, 성공 조건을 통해 인증 이후 워크플로로 이동합니다. 실패: 코드가 틀리면, 사용자가 다시 입력하도록 안내하거나, 새로운 코드를 발송하는 등 대체 절차를 시작할 수 있습니다.

보안 고려사항: 무차별 대입 공격을 방지하기 위해 요청 횟수 제한(rate limiting)을 적용하고, 코드는 3~5분 내 짧은 만료 시간을 설정해야 하며, 재시도 횟수도 추적 및 제한해야 합니다. 음성 상호작용에서는 코드 인식 정확도를 높이기 위해 확인 프롬프트를 사용하는 것이 좋습니다.

결론

이러한 인증 방식들은 정해진 해답이 아닌, 유연하게 조합할 수 있는 빌딩 블록입니다. 선택은 각자의 위험도, 규제 요건, 사용자 경험 목표에 따라 달라져야 합니다. 고객 서비스 챗봇과 금융 거래를 처리하는 어시스턴트는 서로 다른 보안이 필요합니다. ElevenLabs 플랫폼의 유연성 덕분에, 보안 전략은 위협과 요구사항 변화에 맞춰 언제든 발전시킬 수 있으며, 항상 보안과 사용자 경험의 균형을 유지할 수 있습니다.