OpenAI Realtime API와 LangGraph를 사용하여 실시간 영업 코칭 AI 에이전트 구축하기

영업 사원들은 스스로 인지하지 못하는 순간에 계약을 놓칩니다. 잠재 고객의 말을 끊거나, 구매 신호를 놓치거나, 반대에 부딪혔을 때 침묵하는 경우 등이 그렇습니다. 귀에 대고 속삭여 주는 코치가 있다면 대부분의 문제를 해결할 수 있겠지만, 대부분의 기업은 영업 사원 한 명당 코치 한 명을 배치할 여력이 없습니다. 실시간 통화를 듣고 있는 AI 에이전트가 그 코치 역할을 할 수 있습니다.

저지연 오디오 이해를 위한 OpenAI Realtime API와 코칭 로직을 오케스트레이션(orchestration)하기 위한 LangGraph를 사용하여 이를 구축하는 방법을 소개합니다.

이 스택을 사용하는 이유

OpenAI Realtime API — WebSocket을 통해 오디오를 입력받고 텍스트/오디오를 출력하며, 배치(batch) 방식이 아닌 실시간처럼 느껴질 정도로 낮은 지연 시간(latency)을 제공합니다.
LangGraph — 단일 프롬프트 루프 대신 상태 유지 그래프(stateful graph)를 제공합니다. 따라서 "반대 탐지 → 플레이북 확인 → 코칭 팁 생성 → 중복 팁 억제"와 같은 과정이, 단순히 운에 맡기는 거대한 시스템 프롬프트가 아니라 명시적이고 디버깅 가능한 노드(node)가 됩니다.

단일 LLM 호출은 전사(transcribe)하고 반응할 수는 있습니다. 하지만 통화 상태(현재 탐색 단계인가? 가격 협상 단계인가? 클로징 단계인가?)를 안정적으로 추적하거나, 동일한 팁을 두 번 반복하는 것을 방지하거나, 중요한 순간에만 에스컬레이션(escalate)하는 것은 불가능합니다. 이것은 오케스트레이션(orchestration)의 문제이며, 바로 LangGraph가 해결하고자 하는 지점입니다.

아키텍처

Mic/Call Audio
     ↓
OpenAI Realtime API (streaming transcription + voice activity detection)
...

핵심 설계 결정 사항: 코치 노드는 아무 말도 하지 않을 수 있어야 합니다. 10초마다 팁을 던지는 코칭 에이전트는 영업 사원이 첫 주 만에 음소거해 버릴 소음에 불과합니다.

1단계: Realtime API로 오디오 스트리밍하기

import asyncio
import websockets
import json
...

이를 통해 전사된 발화(utterance)의 라이브 스트림을 얻을 수 있습니다. 만약 영업 사원과 잠재 고객의 오디오 트랙을 분리하여 입력한다면(권장 사항 — 대화 시간 비율은 가장 신호가 높은 코칭 지표 중 하나입니다), 화자별로 분할된 스트림을 얻을 수 있습니다.

2단계: LangGraph 상태(State) 정의하기

from typing import TypedDict, Literal
from langgraph.graph import StateGraph, END

...

3단계: 그래프 연결하기

graph = StateGraph(CallState)

graph.add_node("transcript", transcript_node)
...

새로운 전사된 발화(transcribed utterance)가 발생할 때마다 이 그래프를 실행합니다:

async for transcript_chunk in stream_call_audio(audio_chunks):
    state["transcript"].append(transcript_chunk)
    state = app.invoke(state)

...

코칭을 실제로 유용하게 만드는 요소

이러한 에이전트를 구축하며 얻은 몇 가지 명확하지 않은 교훈들입니다:

침묵도 하나의 기능입니다. 모든 팁(tip)은 중복 제거/쿨다운(dedupe/cooldown) 노드를 거치도록 설계하세요. 영업 사원(Reps)들은 너무 말을 많이 하는 에이전트의 말에는 귀를 닫아버립니다.
단계 인지형 팁(Stage-aware tips)이 일반적인 팁보다 낫습니다. 현재 상황이 탐색(discovery) 단계인지 가격 협상(pricing) 단계인지 모르는 상태에서 "후속 질문을 하세요"라는 말은 아무런 의미가 없습니다.
발화 시간 비율(Talk-time ratio)은 가장 저렴하면서도 가치 있는 신호입니다. 이를 계산하기 위해 LLM이 필요하지는 않습니다. 화자 트랙 간의 실시간 단어 수 비율을 계산하면 "영업 사원이 독백 중임"을 즉시 포착할 수 있습니다.
코치 노드(coach node)의 프롬프트를 좁게 유지하세요. 단 하나의 작업만 수행하게 하세요: 감지된 신호를 하나의 짧고 실행 가능한 문장으로 변환하는 것입니다. 코치 노드가 통화 내용을 요약하려고 시도하게 두지 마세요. 요약은 별도의 노드로 분리해야 합니다.
모든 팁과 그 결과를 로그로 남기세요. 어떤 팁이 실제로 더 높은 계약 성사율(close rates)과 상관관계가 있는지 평가해야 하며, 이를 위해서는 사후 고려가 아닌 첫날부터 구조화된 로깅(structured logging)이 필요합니다.

다음 단계

**통화 후 요약 노드(post-call summary node)**를 추가하여 통화가 종료되면 모든 신호와 팁을 정리해 CRM에 바로 입력할 수 있는 노트로 만드세요.
플레이북 검색 노드(playbook retrieval node)(팀의 실제 영업 플레이북에 대한 RAG)를 추가하여, 팁이 일반적인 SaaS 영업 조언이 아닌 귀사만의 특정 방법론에 기반하도록 하세요.
실제 영업 사원들에게 배포하기 전에 녹음된 통화에 대해 **평가 스위트(eval suite)**를 실행하세요. 조용한 실패(팁이 분명히 필요했던 상황에서 제공되지 않음)는 소음이 발생하는 실패보다 더 나쁩니다.

실시간 오디오 입력, 상태 기반 의사결정 로직을 위한 LangGraph, 좁은 목적의 단일 노드 구성이라는 이 패턴은 영업 코칭을 넘어 범용적으로 적용될 수 있습니다. 단계 분류기(stage classifier)와 플레이북을 귀사의 도메인에 맞게 교체하기만 하면, 고객 지원 통화 QA, 인터뷰 코칭 또는 실시간 컴플라이언스 모니터링을 위한 동일한 아키텍처를 갖게 됩니다.

실시간 음성 에이전트 (realtime voice agent)를 출시해 보신 적이 있나요? 무엇이 가장 발목을 잡았나요 — 지연 시간 (latency), 상태 관리 (state management), 아니면 에이전트가 언제 말을 멈춰야 할지 알게 하는 것인가요?