Context Injection 설계 전략: 음성 에이전트에 CRM 데이터를 언제, 얼마나 넣을 것인가

음성 에이전트가 CRM(고객관계관리 시스템) 데이터를 '얼마나, 언제' 받아 쓸지 설계하지 않으면, 빠른 모델도 느린 응답을 만들고 정확한 모델도 엉뚱한 답을 합니다.

Context Injection이란 무엇인가

Context Injection(맥락 주입)은 음성 에이전트가 응답을 만들기 직전에 CRM·ERP(전사 자원 관리 시스템)·KB(지식 베이스)에서 필요한 고객 맥락을 꺼내 LLM(대규모 언어 모델) 프롬프트에 넣는 기법입니다. RAG(Retrieval-Augmented Generation, 검색해서 찾은 자료로 답을 만드는 방식)의 음성 에이전트 버전이라고 볼 수 있지만, 결정적인 차이가 하나 있습니다.

텍스트 RAG는 2초 지연을 허용할 수 있다. 음성 에이전트에서 2초는 대화가 끊긴 것이다.

음성 채널에서는 검색 지연이 곧 침묵이 되므로, 무엇을 넣느냐보다 언제 넣느냐를 먼저 정해야 합니다.

설계 원칙: 맞는 정보를 빨리 넣는다

상담 이력 전체를 프롬프트에 붙이면 토큰(모델이 읽고 쓰는 글자 단위) 비용이 크게 늘고 첫 응답까지 걸리는 시간도 길어집니다. 실무에서는 3단계 계층으로 나누는 방식이 효과적입니다.

Context Injection 계층 설계

Layer 1: Pre-loaded (통화 시작 전)
  ├── 고객 이름, 최근 구매 이력, VIP 여부
  ├── 지난 통화 요약 (1-2문장)
  └── 토큰 예산: ~200 tokens

Layer 2: Intent-triggered (의도 파악 후)
  ├── 해당 제품 FAQ, 가격 정보
  ├── 미납 잔액, 납기 일정 (수금 시나리오)
  └── 토큰 예산: ~300 tokens

Layer 3: On-demand (tool call)
  ├── 실시간 재고 조회, 예약 가능 슬롯
  ├── 배송 추적, 계약 상세 조건
  └── 토큰 예산: 가변 (결과에 따라)

Layer 1은 세션을 만들 때 미리 불러오므로 통화 중 추가 지연이 없습니다. Layer 2는 첫 발화의 intent(고객 의도)가 확정된 뒤 비동기로 가져옵니다. Layer 3는 LLM이 도구를 호출할 때만 실행됩니다.

흔한 실수 3가지

1. 전체 상담 이력 덤프: 최근 3건 요약이면 충분합니다. 50건 이력을 붙이면 LLM이 핵심을 놓칩니다.

2. 모든 턴마다 CRM 동기 조회: 첫 턴에 한 번 불러오고, 상태가 바뀔 때만 갱신합니다.

3. PII(개인 식별 정보)를 필터 없이 프롬프트에 삽입: Zero Retention(통화 데이터를 남기지 않는 처리 방식) 환경에서는 마스킹이나 조회용 토큰 치환이 필수입니다.

Agentic RAG: 다음 단계

기존 RAG는 정적 검색입니다. 질문이 들어오면 벡터 DB에서 가장 가까운 문서 조각을 가져옵니다. Agentic RAG는 에이전트가 검색 전략을 스스로 정합니다. 첫 질문에서 KB를 검색할지, CRM API를 호출할지, 이전 턴 맥락만으로 충분한지를 판단합니다.

Meilisearch도 Agentic RAG를 LLM이 언제 검색하고 언제 답을 만들지 스스로 결정하는 방식으로 설명합니다. '무엇을 검색할까'에 앞서 '검색이 필요한가'를 먼저 묻는 셈입니다.

이 판단 단계가 들어가면 불필요한 검색 호출이 줄고, 그만큼 응답 지연도 낮아집니다.

BringTalk의 Context Injection 설계

BringTalk은 LQA(Lead Qualification Agent, 리드 자격 확인 상담)에서 리드의 CRM 상태, 최근 행동 이벤트, 캠페인 유입 경로를 Layer 1으로 미리 불러옵니다. FUA(Follow-Up Agent, 후속 연락 상담)에서는 이전 통화 요약과 끝나지 않은 후속 조치를 넣어, 에이전트가 '지난번에 어디까지 이야기했는지'를 바로 파악하게 합니다. 주입하는 데이터는 모두 Zero Retention 경계 안에서 처리하고, 원본 PII는 Tool Server(외부 시스템 조회를 맡는 서버) 뒤에서 마스킹합니다.