ElevenAgents 플랫폼 분석_01

자꾸 광고가 뜨길래 뭔지 분석해 보았다.

에이전트 빌더는 무료로 풀고 돈은 음성으로 챙긴다. 

0. 한 줄 정의

음성 에이전트를 만들고(Build) → 붙이고(Deploy) → 지켜보는(Monitor) 풀스택 플랫폼.
제품은 빌더, 과금은 런타임(분당).

1. 문서 IA(Information Architecture) = 제품 구조

docs의 목차 자체가 제품 철학. 3단계로 딱 나뉜다.

단계	섹션명	내용
Build	Design & Configure	워크플로우, 시스템 프롬프트, LLM, 대화흐름, 보이스, 지식베이스, 툴, 개인화, 인증
Deploy	Connect & Deploy	UI 컴포넌트, 위젯, React/Swift/Kotlin/RN SDK, SIP 트렁크, 배치콜, Twilio, WebSocket, Events
Monitor	Monitor & Optimize	유저추적, 대화검색, A/B실험, 에이전트 테스트, 대화분석, 애널리틱스, 프라이버시, 비용최적화, CLI, Hosted MCP

→ Monitor 섹션이 세 단계 중 가장 두껍다. 이게 이 회사의 포지셔닝을 그대로 드러낸다.

2. 런타임 4-스택

1. STT — 자체 파인튜닝 음성인식
2. LLM — 교체 가능 (아래 참조)
3. TTS — 자사 해자. 저지연
4. Turn-taking 모델 — 자체. 언제 끼어들지/기다릴지 판단

3·4번만 고유, 1·2번은 개방. 해자만 잠그고 나머지는 열어둔 구조.

2-1. 해자(moat) 분석 — 무엇을 잠그고 무엇을 열었나

해자(垓子, moat) = 성 둘레에 판 물웅덩이.
적이 성벽에 접근하지 못하게 막는 방어선.
경영에서는 경쟁사가 쉽게 따라올 수 없는 지속적 우위를 뜻한다.
워런 버핏이 쓰면서 굳어진 표현.

부품	따라할 수 있나	해자?	전략
귀 (STT)	가능. Whisper 등 오픈소스로 대체 가능	✗	열어둠
뇌 (LLM)	애초에 남의 것. 누구나 GPT·Claude 사용	✗	완전 개방 (커스텀 LLM까지 허용)
입 (TTS)	어려움. 음질 + 16,000개 목소리 창고	✓	잠금
눈치 (Turn-taking)	어려움. 수년치 실통화 데이터 필요	✓	잠금

진짜 해자는 기술이 아니라 창고다. TTS 음질은 언젠가 따라잡히지만, 성우 10,400명이 이미 자기 목소리를 올려둔 상태는
돈으로 단기간에 못 만든다.
성우가 여기 모이는 이유가 "여기가 제일 많이 팔려서"라 후발주자는 닭-달걀 문제에 걸린다. → 9절 참조

"열어둔다"는 게 왜 양보가 아닌가

1. 열어둔 건 어차피 못 지킬 것들.
   LLM 강제해봐야 반발만 사고 실제로 막지도 못함
2. 열면 도입 장벽이 사라진다.
   "우리는 이미 GPT 계약이 있는데요" → "그거 쓰세요" → 계약 성사
3. 잠근 건 어차피 고객이 안 바꾸고 싶어 한다.
   음질이 좋으니까

관대해 보이지만 아무것도 안 내줬다.
못 지킬 걸 열어주고 돈 되는 곳만 잠갔다.
★ 벤치마킹 핵심 질문: "우리가 열어도 되는 건 뭐고, 절대 열면 안 되는 건 뭔가?"
이 구분을 못 하면 지킬 필요 없는 걸 지키느라 고객을 잃고, 정작 지켜야 할 걸 내준다.

LLM 선택지

• ElevenLabs 자체: Qwen3.6-35B-A3B, Qwen3.5-397B-A17B
• Google Gemini (3.7 Flash ~ 2.5 Flash Lite)
• OpenAI GPT-5 계열, GPT-4 계열
• Anthropic Claude Opus / Sonnet / Haiku
• 커스텀 LLM: 엔드포인트 + 시크릿 스토리지로 자체 모델 연결 가능

주의: docs는 LLM 단가를 명시하지 않고 "공급자 문서를 보라"고 넘긴다. 비용 예측 책임을 고객에게 전가하는 설계.

3. Build — 진짜 핵심은 워크플로우 빌더

단일 시스템 프롬프트의 한계(one-size-fits-all)를 깨는 분기형 대화 그래프.

노드 타입

• Subagent 노드 — 특정 단계에서 에이전트를 통째로 오버라이드
  • 시스템 프롬프트 / LLM / 보이스 교체
  • 그 노드 전용 지식베이스 부착
  • 그 단계에서 쓸 수 있는 툴 제한
• Dispatch Tool 노드 — 툴 실행을 보장하고 성공/실패로 분기
• Transfer 노드 — 다른 AI 에이전트 / 사람 상담원(전화) / 대화 종료로 핸드오프

엣지(분기 조건)

• LLM 조건 — 자연어 판단 ("고객 문의가 해결되었다")
• Expression — 변수 기반 결정론적 로직
• 무조건 진행
• 역방향 엣지 — 재시도 루프, 반복 검증

활용 예

• 복잡한 추론 노드만 비싼 LLM, 나머지는 싼 LLM
• 민감정보 수집 단계만 엄격한 가드레일
• 자격심사 통과 후에만 가격 문서 노출
• 대시보드에서 노드별 지표 확인

Tool 시스템 (5종)

종류	실행 위치
Client Tools	브라우저/모바일 앱 로컬
Webhook Tools	외부 API 호출
Code Tools	ElevenLabs 인프라의 샌드박스 JS
MCP Tools	MCP 서버 연결
System Tools	플랫폼 내장

부가: 툴 실행 중 앰비언트 사운드 재생(대기 체감 완화), 툴 실행 중 유저 인터럽트 허용 여부 제어. → 침묵을 UX 문제로 인식하고 오디오로 푼 것. 음성 회사다운 디테일.

지식베이스 / RAG

• 소스: 파일 업로드 / URL / 직접 입력
• 포맷: PDF, Word, Text, Markdown, HTML, EPUB — 파일당 20MB
• Full Context 한계: 추출 텍스트 약 30만 자까지 프롬프트 직입
• 초과 시 RAG 필수. RAG 인덱싱 총량은 구독 티어에 종속
• 모드: auto(RAG 우선) / prompt(강제 풀컨텍스트) / RAG
• 폴더는 항상 RAG, 절대 프롬프트에 안 들어감
• 문서 1개를 여러 에이전트가 공유 가능

4. Deploy

• 채널: 전화(SIP 트렁크 / Twilio / 배치 아웃바운드), 웹 위젯, 모바일
• SDK: React, Swift, Kotlin, React Native, WebSocket(커스텀)
• ElevenLabs UI: React 컴포넌트 제공 — 프론트까지 대신 만들어줌
• Events: 실시간 이벤트 구독

5. Monitor — 여기가 실제 차별점

에이전트 테스트 (3종)

1. Simulation Testing — AI 가상 유저와 최대 50턴 멀티턴 대화. 시나리오("식당에서 주문하는 관광객") + 성공 조건 정의 후 자동 평가
2. Next Reply (Scenario) Testing — 대화 이력 주고 다음 한 마디만 평가. 품질/톤/정책 준수 체크. 통과·실패 예시 첨부 가능
3. Tool Call Testing — 올바른 툴을 올바른 파라미터로 호출했는지 검증. 매칭 방식: 정확일치 / 정규식 / LLM 의미 평가. 긴급 전화 이관, 데이터 보안 같은 고위험 시나리오용

테스트 인프라

• 실제 대화 → 테스트 케이스로 전환. 에이전트가 실수한 실제 통화를 그대로 회귀 테스트로 승격
• Tool Mocking — 전체/선택/미적용. 폴백으로 실제 실행 or 에러 반환 선택
• Probabilistic Testing — 같은 테스트 2~20회 반복, 통과율 배지(녹색 100% / 앰버 80%+ / 적색 80% 미만), 실패를 원인별로 그룹핑
• Dynamic Variables — 에이전트 설정 안 건드리고 테스트별 값(고객명, 주문번호) 주입
• 실행: 대시보드 / CLI elevenlabs agents test [agent-id] / API run_tests

권장 테스트 항목

페르소나 일관성, 멀티턴 추론, 프롬프트 인젝션 내성, 모호한 의도 처리

운영 도구

• 대화 검색(키워드 + 시맨틱), A/B 실험, 대화 분석, 외부 ID로 유저 추적
• CLI + 버전관리: elevenlabs agents init / push / test → 에이전트를 코드로 관리(GitOps)
• Hosted MCP: Claude에서 직접 붙여 쓰기

6. 마케팅 vs 문서 — 수치 불일치

항목	마케팅 페이지	기술 문서
보이스 수	16,000+	5,000+
언어	70+	31

→ 마케팅 수치는 TTS 제품 전체 기준, 문서 수치는 에이전트에서 실제 쓸 수 있는 기준으로 보임.
    벤치마킹 시 문서 수치를 신뢰할 것.

7. 벤치마킹 결론

벤치마킹 할 것

1. Build / Deploy / Monitor 3단 IA — 문서 구조가 곧 제품 서사. 그대로 차용 가능
2. 워크플로우 = 노드별 전체 오버라이드. "노드마다 다른 에이전트"라는 발상.
   비싼 LLM을 필요한 노드에만 쓰는 원가 구조까지 자연스럽게 따라온다
3. 실제 대화 → 테스트 케이스 승격.
   운영 로그가 회귀 스위트로 자동 전환되는 루프. 도입 결정권자가 실제로 사는 건 이것
4. Probabilistic Testing. LLM이 확률적이라는 걸 인정하고 통과율로 관리.
   단발 pass/fail로 보는 경쟁사 대비 명백한 우위
5. 에이전트 as 코드 (CLI + push). 대시보드로 시작해 Git으로 졸업시키는 경로. 개발자 록인
6. 툴 실행 중 앰비언트 사운드. 도메인 특성(침묵 = 이탈)을 기능으로 번역한 사례

피할 것 / 빈틈

1. LLM 단가를 문서에서 회피 → 고객이 월 비용 예측 불가. Retell 올인 $0.07/분이 여기서 이김
2. RAG 용량이 구독 티어에 종속 → 지식베이스 큰 고객은 바로 상위 플랜 강제. 숨은 비용
3. 파일당 20MB / 30만 자 제한 → 대형 매뉴얼·규정집 다루는 엔터프라이즈엔 빡빡
4. 동시통화 한도(Business $990에 40채널) → 콜센터 규모면 무조건 엔터프라이즈 영업행. 셀프서브 천장이 낮음
5. 한국어: 31개 언어 안에는 들지만 turn-taking·발음 품질은 별도 검증 필요

같은 영역 진입 시 공략점

정면(목소리 품질) 승부 X.
빈틈은 셋:

• 가격 예측 가능성 (올인 정액)
• 버티컬 도메인 워크플로우 (한국 콜센터 / 의료 예약 / 금융 본인확인)
• 온프렘 · 국내 데이터 레지던시

그래서 어떻게 수익구조를 가져가는지에 대해서는 2부에 계속..!