ElevenAgents Architect로 고객 응대 AI를 점검하고 개선하는 방법

실패한 상담을 조사하고 수정안과 테스트를 준비하는 ElevenAgents Architect가 공개됐다. 환불 상담 예제로 살펴보는 활용법과 승인 모드, 개인정보, Alpha 무료 범위.

고친 내용: Architect의 Alpha 공개 범위, 가상 환불 상담 개선 절차, 승인·MCP 경로의 차이와 데이터 보관·예약 실행 한계를 출처 및 도표와 함께 정리했습니다. 원문 링크와 클릭해 재생하는 ElevenLabs 공식 소개 영상을 추가하고 영상의 확인 범위를 명시했습니다.

ElevenAgents Architect로 고객 응대 AI를 점검하고 개선하는 방법

고객 응대 AI를 출시한 뒤에는 새로운 일이 시작됩니다. 고객이 어떤 질문에서 막혔는지, 상담원 연결이 왜 늘었는지, 안내 문구를 바꿨더니 다른 문의에서 오류가 생기지는 않았는지 확인해야 합니다. 음성이 자연스러워도 업무 절차가 잘못 연결되면 상담은 끝나지 않습니다.

ElevenLabs는 2026년 10월 6일 ElevenAgents Architect를 Alpha로 공개했습니다. 운영자가 말이나 글로 요청하면 기존 에이전트의 대화와 설정을 조사하고 수정안과 테스트를 준비하는 내장 도우미입니다. 새 에이전트 구성에도 사용할 수 있지만 이미 운영 중인 에이전트의 문제를 찾아 개선하는 흐름에 특히 초점을 맞춥니다. 공식 출시 글

이 글은 공개 문서를 바탕으로 정리한 운영 가이드입니다. 아래 쇼핑몰 예제는 이해를 돕기 위해 구성했으며 Architect를 직접 실행해 얻은 성과나 실제 고객사의 상담 기록은 아닙니다.

이 절의 근거 S59

어떤 일을 맡길 수 있나

Architect는 에이전트의 프롬프트, 절차, 워크플로, 도구, 지식 자료와 테스트를 다룹니다. 조사할 때 필요한 설정과 기록을 도구로 읽고 바뀐 내용은 대시보드의 기존 초안·변경 내역·버전 기록에 남깁니다. 운영자가 별도의 숨겨진 설정을 관리하는 구조는 아닙니다. 제품 개요

업무를 맡길 때는 질문을 작게 만드는 편이 좋습니다. “고객 만족도를 높여 줘”보다 “최근 환불 문의에서 상담원 연결이 발생한 이유를 분류해 줘”가 확인할 결과를 분명하게 만듭니다. Architect의 설명을 듣고 끝내지 않고 어떤 대화를 읽었으며 어떤 근거로 수정안을 만들었는지 함께 확인하는 방식입니다.

공식 문서는 직접적인 수정 요청과 원인 조사 요청도 구분합니다. 문구를 짧게 고치라는 요청은 관련 설정을 읽고 변경안을 만들지만 상담원 연결이 늘어난 이유를 묻는 요청은 통계와 평가 결과부터 살펴본 뒤 필요한 대화 기록을 조사합니다. 전체 대화를 읽었다고 가정하지 말고 실제 분석한 범위를 확인해야 합니다. 작동 방식

이 절의 근거 S60 · S61

실제 도입 사례에서 읽을 수 있는 운영 과제

ElevenLabs가 1월에 공개한 Revolut 사례는 음성 에이전트가 계정 관련 질문에 답하고 고객별 정보와 업무 시스템을 연결하는 모습을 설명합니다. 핵심은 질문에 대답하는 능력뿐 아니라 기업이 업무 로직과 통제권을 유지하는 방식입니다. 이는 ElevenLabs Agents 플랫폼의 기존 고객 사례이며 10월에 공개된 Architect의 도입 성과를 입증하는 자료는 아닙니다.

함께 읽을 만한 자료는 ElevenLabs 현장 엔지니어링 팀의 운영 경험 글입니다. 이 글은 상담원 연결을 줄이는 것과 고객의 문제를 해결하는 것을 구별합니다. Architect를 평가할 때도 이 구별이 유용합니다. 상담원 연결률만 낮아지고 해결되지 않은 고객이 다시 전화를 건다면 성공으로 보기 어렵습니다.

이 절의 근거 S66 · S67

예제로 살펴보는 환불 상담 개선

다음은 가상의 쇼핑몰 상황입니다. 교환과 반품 안내를 맡긴 에이전트가 “상품을 개봉했는데 반품할 수 있나요?”라는 질문에서 상담원에게 연결합니다. 원인은 여러 가지일 수 있습니다. 지식 자료에 예외 조건이 빠졌거나 조회 도구가 실패했거나 상담원 연결 기준이 지나치게 넓을 수 있습니다.

처음부터 프롬프트를 길게 고치기보다 다음 순서로 범위를 좁혀 봅니다.

1단계 조사 범위를 정하기

운영자가 사용할 수 있는 요청 예시입니다.

최근 7일의 반품 관련 문의에서 상담원 연결이 발생한 원인을 조사해 줘. 실제로 확인한 대화 수와 선정 기준을 먼저 알려 줘. 정책 누락, 도구 오류, 고객의 명시적인 연결 요청을 구분하고, 아직 설정은 바꾸지 마.

여기서는 분모가 중요합니다. “문제가 다섯 번 발견됐다”는 결과만으로는 빈도를 판단하기 어렵습니다. 조사한 문의가 열 건인지 천 건인지, 특정 시간대만 읽었는지 함께 기록합니다. 고객이 직접 사람과의 상담을 요청한 경우도 시스템 실패와 따로 살펴봅니다.

2단계 하나의 원인만 수정하기

정책 누락이 원인으로 확인됐다고 가정하면 회사가 승인한 반품 규정을 먼저 준비합니다. Architect가 규정을 추측하게 두지 말고 적용할 문서와 바꿀 범위를 지정합니다.

승인된 반품 규정 문서에 있는 개봉 상품 조건을 참고해 수정안을 만들어 줘. 별도 브랜치에서 작업하고, 변경한 문장과 그 근거를 보여 줘. 실제 환불 실행 권한이나 상담원 연결 기준은 이번 변경 범위에서 제외해 줘.

이 예제의 범위 제한은 독자가 자신의 운영 정책에 맞게 바꿀 부분입니다. 안내 문구 수정과 실제 환불 실행은 고객에게 미치는 영향이 다릅니다. 한 번의 변경에서 둘을 함께 다루면 문제의 원인과 개선 효과를 구별하기도 어려워집니다.

3단계 수정 전후를 같은 테스트로 비교하기

테스트에는 정상 질문뿐 아니라 경계 조건을 넣습니다.

공식 문서에 따르면 Architect는 변경에 필요한 테스트와 시뮬레이션을 작성·실행할 수 있습니다. 다만 수정 전 실패와 수정 후 성공을 모두 확인하는 비교를 모든 변경에서 자동으로 수행하는 것은 아닙니다. 다음처럼 명시적으로 요구하는 것이 좋습니다. 검증 및 제안 문서

동일한 테스트를 기존 버전과 수정안에 실행해 비교해 줘. 수정 전에는 실패하고 수정 후에는 통과하는지 보여 줘. 반복 실행 결과가 달라지면 그 차이도 알려 줘.

4단계 배포 판단에 필요한 자료 모으기

검토자는 변경 내역, 근거 문서, 테스트 결과, 영향을 받을 문의 유형을 확인합니다. 새 브랜치의 결과가 좋아도 실제 통화 전체로 즉시 확대할 이유는 없습니다. 회사가 승인한 절차에 따라 제한된 범위에서 관찰하고 원래 버전으로 되돌릴 기준을 미리 정합니다.

성과 지표도 미리 정해 두는 편이 좋습니다. 이 예제에서는 반품 문의 해결률과 재문의율을 함께 보고 잘못된 환불 약속이 늘지 않았는지 확인할 수 있습니다. 이는 이 글이 제안하는 평가 설계이며 Architect가 보장하는 성과 수치는 아닙니다.

승인 모드와 외부 MCP의 차이

배포 전에 가장 먼저 읽어야 할 항목은 권한과 승인 모드입니다. Architect는 로그인한 사용자의 권한으로 동작합니다.

Approval required: 기본 모드. 에이전트 설정은 초안으로 준비하며 실시간 트래픽이나 공유 자원에 영향을 주는 작업에는 승인을 요청합니다

Plan: 읽기 중심으로 조사하고 계획을 제안합니다. 계획 승인 후에는 기본 승인 모드의 통제가 적용됩니다

Auto-approve: 도구 작업마다 확인을 받지 않습니다. 트래픽 비중 변경 등 영향이 큰 작업도 포함하므로 신중하게 사용해야 합니다

대시보드의 설정 초안은 사용자가 발행하지만 이것만 보고 모든 경로의 모든 변경이 안전하게 대기한다고 생각하면 안 됩니다. 공식 외부 AI 도우미 연결 문서는 MCP를 통한 에이전트 업데이트가 대상 브랜치에 직접 적용될 수 있다고 설명합니다. 브랜치를 지정하지 않으면 main이 대상이 될 수 있습니다. 외부 도우미에서는 해당 클라이언트의 도구 승인 설정도 확인해야 합니다.

운영 팀이 모든 실서비스 변경을 검토하려면 프롬프트에 “조심해 줘”라고 쓰는 데서 멈추지 말고 브랜치 보호와 권한 설정을 함께 점검해야 합니다.

이 절의 근거 S63 · S64

Alpha 기간에 확인할 비용과 개인정보

공식 개요 기준으로 Architect 대화는 2026년 10월 Alpha 기간에 무료이며 해당 사용량이 워크스페이스의 에이전트 분이나 LLM 비용에 합산되지 않습니다. 이 안내를 일반 고객 통화·별도 서비스 이용까지 모두 무료라는 뜻으로 확대해서는 안 됩니다. Alpha 이후 조건은 최신 문서와 연결된 요금 안내에서 다시 확인해야 합니다.

같은 문서는 Architect 대화에 Zero Retention Mode가 적용되지 않는다고 명시합니다. 고객 이름, 연락처, 결제·건강 정보 등을 조사 메시지에 무심코 붙여 넣지 않도록 주의해야 합니다. 실습은 가상 데이터로 시작하고 실제 기록을 사용할 때는 조직의 데이터 처리 기준을 먼저 확인하는 편이 안전합니다.

이 절의 근거 S60

아직 맡길 수 없는 일

공식 FAQ는 현재 예약 실행이나 백그라운드 작업을 지원하지 않는다고 설명합니다. 사용자가 대화 중일 때 작업하며 스스로 정기적으로 에이전트를 조사하거나 제안서를 여는 기능은 아직 제공되지 않습니다. 출시 홍보에 등장하는 선제적 개선이라는 표현과 현재 제공 범위를 구별해서 읽어야 합니다.

채팅에서 만든 대시보드도 지속적으로 갱신되는 운영 대시보드로 보기는 어렵습니다. 공식 문서상 데이터는 해당 브라우저 탭의 메모리에 유지되며 재접속하면 다시 만들어야 할 수 있습니다. 중요한 검토 결과는 팀이 사용하는 변경 제안이나 검토 기록에 정리해 두는 방식이 적합합니다.

이 절의 근거 S65

도입 판단

Architect를 처음 평가한다면 이미 실패 원인을 어느 정도 알고 있는 작은 상담 문제 하나로 시작하는 것을 권합니다. 사람이 예상한 원인을 찾는지, 관련 규정에 근거해 수정하는지, 기존 동작을 깨뜨리지 않는 테스트를 만드는지 확인할 수 있기 때문입니다.

TheMagicTower의 Eleven v4 한국어 음성 AI 가이드가 음성 모델 선택을 살펴보는 출발점이라면 Architect에서는 그 음성으로 수행하는 업무를 어떻게 검토하고 개선할지에 초점을 맞춰 볼 수 있습니다. 좋은 평가 질문은 “스스로 좋아지는가”보다 구체적입니다. 무엇을 바꿨고 어떤 테스트로 확인했으며 누가 배포를 승인했는가를 남길 수 있는지 살펴보면 됩니다.

정보 확인일: 2026년 10월 7일. Alpha 기능과 이용 조건은 변경될 수 있습니다.

이 절의 근거 S80