2026-02-24

AI 전화 에이전트 만들기: 개발자를 위한 음성 AI 아키텍처 완전 가이드

AI 전화 에이전트의 핵심 아키텍처를 SIP, 미디어서버, STT/LLM/TTS 파이프라인별로 분해하고, 한국 환경에서의 실무 구축 가이드를 제공합니다.

AI 전화 에이전트 만들기: 개발자를 위한 음성 AI 아키텍처 완전 가이드

AI가 전화를 걸고 받는 시대가 본격적으로 열렸다. 예약 확인, 고객 상담, 리마인더 전화까지 — 음성 AI 에이전트는 이미 실무에 투입되고 있다. 하지만 막상 AI 전화 에이전트를 만들려고 하면, SIP 프로토콜부터 코덱, 레이턴시 최적화까지 넘어야 할 기술적 허들이 만만치 않다.

이 글에서는 AI 전화 에이전트의 핵심 아키텍처를 컴포넌트별로 분해하고, 한국 환경에서 실제 구축할 때 필요한 실무 지식을 정리한다.

음성 AI 에이전트의 핵심 아키텍처

AI 전화 에이전트는 다음과 같은 파이프라인으로 동작한다.

전화망(PSTN) ↔ SIP ↔ 미디어서버 ↔ STT ↔ LLM ↔ TTS ↔ 미디어서버 ↔ SIP ↔ 전화망

각 컴포넌트가 하나라도 병목이 되면 전체 대화 품질이 무너진다. 각 구성 요소를 살펴보자.

SIP 프로토콜 (RFC 3261)

SIP(Session Initiation Protocol)는 음성/영상 통화 세션을 생성, 변경, 종료하는 시그널링 프로토콜이다. RFC 3261로 표준화되어 있으며^[1], 유저 에이전트(UA) 간의 세션 협상과 프록시 서버를 통한 라우팅을 정의한다. AI 에이전트가 실제 전화번호로 통화하려면 SIP 트렁크를 통해 PSTN과 연결해야 한다.

미디어서버 (FreeSWITCH)

FreeSWITCH는 오픈소스 미디어서버로, SIP 시그널링과 RTP 미디어 스트림을 처리한다. 음성 코덱 간 트랜스코딩도 담당하는데, 전화망에서 사용하는 G.711(64 kbps, 비압축)과 대역폭 효율이 높은 G.729(8 kbps, 압축)간 변환이 핵심이다. AI 처리를 위해 오디오를 WebSocket으로 STT 엔진에 전달하는 브리지 역할도 수행한다.

STT → LLM → TTS 체인

컴포넌트	역할	일반적 레이턴시
STT (Speech-to-Text)	음성을 텍스트로 변환	100~500ms
LLM (Large Language Model)	의도 파악 및 응답 생성	200~2,000ms
TTS (Text-to-Speech)	텍스트를 음성으로 합성	200~800ms

세 컴포넌트를 단순 합산하면 500~3,300ms가 된다^[7]. 자연스러운 대화를 위해서는 이 전체 응답 시간을 600ms 이내로 줄여야 한다.

레이턴시 최적화: 600ms의 벽을 넘는 법

인간 대화에서 발화 간 평균 간격은 약 200~600ms다^[6]. 이 범위를 넘으면 사용자는 "AI가 멈췄다"고 느낀다. 핵심은 각 단계를 순차 실행이 아닌 스트리밍 파이프라인으로 연결하는 것이다.

1. 스트리밍 STT

배치(Batch) STT는 발화가 완전히 끝날 때까지 기다린 후 변환한다. 반면 스트리밍 STT는 음성이 들어오는 즉시 부분 결과(partial transcript)를 실시간으로 반환한다. 이 차이만으로 200~400ms를 절약할 수 있다.

2. LLM 응답 스트리밍

LLM이 전체 응답을 생성할 때까지 기다리지 않는다. 첫 번째 토큰이 생성되는 즉시 TTS로 전달을 시작한다. OpenAI, Claude 등 주요 LLM API는 모두 스트리밍 응답을 지원한다.

3. TTS 청크 스트리밍

TTS 엔진이 전체 문장의 합성을 완료할 때까지 기다리지 않고, 첫 번째 오디오 청크가 생성되면 즉시 재생을 시작한다. ElevenLabs Flash 등은 TTFB(Time to First Byte) 135ms 수준을 달성하고 있으며, Retell AI는 이러한 파이프라이닝으로 약 600ms의 엔드투엔드 레이턴시를 구현한다^[6].

4. 추가 최적화 기법

커넥션 풀링: LLM/STT/TTS API 연결을 재사용하여 DNS 조회와 TCP 핸드셰이크 오버헤드 제거
리전 최적화: 동일 리전 내 배포 시 네트워크 레이턴시를 약 200ms 이하로 유지 가능
포맷 턴 비활성화: STT 출력의 불필요한 포맷팅을 제거하여 처리 시간 단축

Function Calling으로 외부 시스템 연동

AI 전화 에이전트의 진정한 가치는 단순 대화가 아니라 실제 업무를 처리하는 데 있다. LLM의 Function Calling 기능을 활용하면 통화 중 실시간으로 외부 시스템과 연동할 수 있다.

연동 대상	Function Calling 예시
예약 DB	`check_availability(date, time)` → `create_booking(customer, slot)`
CRM	`get_customer_info(phone)` → `update_ticket(id, status)`
결제	`get_payment_status(order_id)` → `send_payment_link(customer)`

예를 들어, 고객이 "내일 오후 3시 예약 가능한가요?"라고 물으면 LLM이 check_availability 함수를 호출하고, 결과를 받아 "네, 내일 오후 3시 가능합니다. 예약 진행할까요?"라고 응답하는 흐름이 한 번의 통화 안에서 이루어진다.

한국 특화 고려사항

070 번호 획득

한국에서 AI 에이전트에 전화번호를 부여하려면 070(인터넷전화) 번호가 필요하다. 삼성 WYZ070 등의 SIP 트렁크 서비스를 통해 SIP 계정을 발급받아 연동하거나, AVOXI 같은 글로벌 SIP 트렁크 제공업체를 통해 한국 번호를 확보할 수 있다^[4]. 다만 직접 SIP 트렁크를 계약하고 미디어서버에 연동하는 과정은 통신사별 설정 차이, 인증 요건 등으로 상당한 시행착오가 필요하다.

통화 녹음과 개인정보 보호

한국의 통신비밀보호법상, 통화 당사자가 녹음하는 것 자체는 위법이 아니지만, 녹음 내용의 공개나 제3자 제공에는 제한이 있다. 개인정보보호법(PIPA)에 따라 음성 데이터는 개인정보에 해당하므로, AI 에이전트가 통화를 처리할 때에는 통화 시작 시 AI 상담임을 고지하고 녹음 동의를 받는 것이 안전하다. 수집된 음성 데이터의 보관 기간과 파기 절차도 명확히 설계해야 한다.

직접 구축 vs 플랫폼 활용

비교 항목	직접 구축	플랫폼 활용
초기 개발 기간	4~12주 (인프라만)	30분~1일 (API 연동)
초기 비용	$20,000~$50,000+	종량제 (분당 과금)
연간 유지보수	초기 비용의 15~25%	플랫폼 요금에 포함
SIP/코덱 전문성	직접 확보 필요	불필요
확장성	직접 설계	플랫폼이 처리
커스터마이징	완전한 제어	플랫폼 범위 내

대부분의 팀에게 현실적인 선택은 명확하다^[8]. FreeSWITCH 설정, SIP 트렁크 연동, 코덱 트랜스코딩, 레이턴시 최적화를 직접 구축하면 인프라만 4주 이상이 소요된다. 반면 API 기반 플랫폼을 활용하면 핵심 비즈니스 로직(프롬프트 설계, Function Calling 연동)에 집중할 수 있다.

물론 월 수만 건의 통화를 처리하는 규모이거나, 규제 산업에서 완전한 데이터 통제가 필요한 경우라면 자체 구축이 장기적으로 유리할 수 있다.

마무리

AI 전화 에이전트의 아키텍처는 SIP부터 TTS까지 각 레이어가 정교하게 맞물려야 한다. 특히 한국 환경에서는 070 번호 획득, 한국어 STT 정확도, PIPA 준수까지 추가로 고려해야 할 요소가 많다.

ClawOps는 이 모든 인프라 레이어를 API 하나로 추상화하여, AI 에이전트에게 한국 070 전화번호를 부여하고 실시간 통화를 처리할 수 있게 한다. SIP 트렁크 설정이나 미디어서버 운영 대신, 프롬프트 설계와 비즈니스 로직에 집중하고 싶다면 살펴볼 만하다.