LLM 콜봇 PoC, 현장에서 발견한 것

LLM 기반 콜봇의 PoC(개념 검증)는 생각보다 순조롭게 진행되는 경우가 많습니다. 시나리오 3개, 문서 수십 건, 통제된 환경에서 돌리면 응답 품질이 꽤 좋습니다. 그런데 실제 운영 환경으로 넘어가는 순간 예상하지 못했던 문제들이 터집니다. 이 글은 금융사 LLM 콜봇 PoC를 직접 진행하면서 발견한 구조적 갭을 정리한 것입니다. PoC가 잘 됐는데 왜 운영은 다른 이야기가 되는지, 그리고 검증 단계에서 무엇을 미리 확인해야 하는지를 현장 경험 기반으로 풀겠습니다.

[시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 8-1편

← 이전: 7-4 S2S 도입 검토자가 묻는 질문 / 다음 → 8-2 STT 정확도 93% 목표가 부족한 이유

전체 목차 펼치기 (63편)

Part 1 — 음성 AI가 느린 이유: 레이턴시 진단 (4편)

Part 2 — 텍스트를 넘어: End-to-End S2S의 원리 (4편)

Part 3 — 실시간 대화와 에이전트화: 인터럽트·MCP·도구 (5편)

Part 4 — 인프라·세션·보안: 프로덕션 백엔드 (5편)

Part 5 — 운영·품질·평가: 에이전틱 워크플로우와 신뢰성 (7편)

Part 6 — 음성 경험 고도화·실전 통합: 한국어·UX·전화망·엣지 (5편)

Part 7 — S2S 도입 전략·구매 의사결정 (4편)

Part 8 — LLM 콜봇 PoC 현장 (6편)

Part 9 — 상담어시스트: 상담사 화면을 바꾸는 실시간 AI (7편)

Part 10 — 직접 만든 롤플레이 챗봇: RAG 에이전트 구축기 (8편)

Part 11 — KMS 실무 — 지식관리시스템의 설계와 운영 현실 (8편)

PoC 환경과 운영 환경의 구조적 차이

LLM 콜봇 PoC는 대부분 통제된 환경에서 진행됩니다. 솔루션 사업자가 준비한 데모 서버, 정제된 시나리오 몇 가지, 그리고 매뉴얼 수십 건으로 구성된 지식 베이스입니다. 이 환경에서는 응답 품질이 인상적으로 나옵니다. 응답 시간도 빠르고, LLM이 문서를 찾아 자연스럽게 안내하는 흐름이 매끄럽습니다.

그런데 실제 운영 환경은 구조가 다릅니다. 지식 베이스는 수만 건의 문서로 구성되고, 동시 접속 세션은 수백 개에 달하며, 고객 질문은 미리 정해진 시나리오 밖으로 수시로 벗어납니다. PoC에서 검증한 것이 "이 구성 요소가 동작하는가"라면, 운영에서 실제로 묻는 것은 "이 구성 요소가 이 규모·이 부하에서도 동작하는가"입니다. 이 두 질문 사이에 존재하는 갭이 생각보다 큽니다.

가장 전형적인 차이는 RAG 파이프라인에서 드러납니다. PoC에서 벡터 검색은 소규모 코퍼스 안에서 수십 밀리초 안에 결과를 돌려줍니다. 그런데 운영 환경처럼 임베딩 벡터가 수십만 개를 넘어서면, 같은 검색 요청이 수백 밀리초로 늘어납니다. 상담사를 보조하는 텍스트 채널이라면 그 정도가 허용 범위일 수도 있습니다. 하지만 콜봇은 다릅니다. 고객이 전화기를 들고 음성으로 말을 하고 있는 상황이라 200ms 추가만 쌓여도 체감 지연이 확연히 달라집니다.

RAG 검색 시간은 문서 규모에 비례하지 않는다

이 지점을 처음 발견했을 때 직관과 달랐습니다. 벡터 검색은 색인 크기에 선형 비례하지 않는다는 것을 이론적으로는 알고 있었지만, PoC와 운영 사이의 실제 격차가 그렇게 크게 나타날 것이라고 예상하지 못했습니다. 금융사 PoC 환경에서는 지식 문서를 상품 안내, FAQ, 약관 주요 발췌 등 세 카테고리 합계 약 300건으로 구성했습니다. 이 상태에서 p95 RAG 검색 시간은 40~60ms 수준이었습니다.

운영 환경 시뮬레이션을 위해 같은 임베딩 모델, 같은 벡터 DB 구성 그대로 유지하면서 문서를 실제 운영 예상 규모인 5만 건으로 확장했습니다. 인덱스 최적화 없이 단순 확장했을 때 p95 검색 시간은 280~340ms 수준으로 올라갔습니다. LLM 추론 시간이 별도로 있고, TTS 변환 시간이 또 있습니다. 이것들이 전부 직렬로 쌓이면 전체 응답 레이턴시가 PoC 대비 두 배 가까이 늘어납니다.

더 정확하게는, HNSW 기반 벡터 인덱스는 로그 스케일로 증가하는 성격이 있어서 10배 문서 증가가 검색 시간 10배 증가로 이어지지는 않습니다. 그러나 파라미터 설정(ef_construction, M 값 등)이 PoC 환경에 맞춰져 있다면, 운영 규모에서는 정밀도와 속도 사이의 트레이드오프가 다르게 작동합니다. PoC 결과를 그대로 신뢰하고 운영 환경 전환 시 벡터 인덱스 재튜닝을 계약 범위에서 빠뜨리는 경우가 종종 있습니다.

PoC 통과 기준이 낮아지는 이유

PoC 기준이 실제보다 완화되는 데는 복합적인 이유가 있습니다. 솔루션 사업자 입장에서는 수주가 목표이고, 고객사 담당자 입장에서는 내부 보고를 위해 "PoC 통과"라는 결과가 필요한 경우가 있습니다. 그 사이에서 검증 기준이 점점 좁아지는 현상이 발생합니다.

전형적인 패턴을 보면 몇 가지 공통점이 있습니다. 첫째, 시나리오 범위가 과도하게 좁게 잡힙니다. "이 상품 가입하려면 어떻게 하나요", "한도는 얼마인가요" 같은 정형화된 질문만 테스트 케이스로 올라갑니다. 실제 콜센터에서 들어오는 "지난번에 상담사가 그렇게 설명했는데 왜 지금은 다르게 나오나요" 같은 맥락 의존형 질문, "제 나이가 만으로 몇 살인지 계산해주세요" 같은 예상 밖 요청은 아예 테스트하지 않습니다.

둘째, 성능 지표가 체감이 아닌 평균값으로만 측정됩니다. 평균 응답 시간 1.2초는 들으면 괜찮아 보입니다. 그런데 p99가 3.8초라면 이야기가 다릅니다. 100건 중 1건이 4초 가까이 걸린다는 뜻이고, 콜봇 환경에서 4초의 침묵은 고객 이탈로 이어집니다. 셋째, 동시 세션 부하 없이 단일 세션 기준으로만 측정합니다. 콜봇은 동시에 수백 통화를 처리해야 하는데, 단일 세션 레이턴시를 근거로 "충분히 빠르다"는 결론을 냅니다.

단계별 놓치기 쉬운 포인트 — STT·LLM·TTS

LLM 콜봇 파이프라인은 STT(음성인식) → LLM(언어 처리) → TTS(음성합성)의 세 단계로 구성됩니다. 각 단계마다 PoC에서 잘 드러나지 않는 특성이 있습니다.

STT 단계에서 가장 흔히 놓치는 것은 노이즈 환경 성능입니다. 콜봇 PoC는 보통 헤드셋이나 스튜디오 수준 환경에서 테스트합니다. 실제 고객은 지하철 안에서, 길거리에서, 배경 소리가 있는 공간에서 전화를 겁니다. 조용한 환경에서 95% 인식률을 기록한 STT가 노이즈 환경에서 80% 이하로 떨어지는 경우가 있습니다. 이 차이는 PoC에서 검출되지 않습니다. 또한 금융 도메인에서는 "만기", "중도해지", "이율", "거치식" 같은 전문 용어의 인식 정확도가 중요한데, 일반 STT 엔진은 이런 도메인 특화 용어에서 취약점을 드러냅니다.

LLM 단계에서는 RAG 검색과 맥락 유지 두 가지가 핵심입니다. 앞서 다룬 RAG 문서 규모 문제 외에, 멀티턴 대화에서 이전 맥락을 얼마나 잘 유지하는지도 PoC에서 충분히 검증되지 않습니다. 보통 PoC는 단일 질문-응답 쌍 위주로 테스트하기 때문에 "아까 말씀하신 상품"이라는 식의 지시어 처리나, 동일 세션 안에서 여러 주제를 오가는 상황이 테스트 케이스에 포함되지 않는 경우가 많습니다. 콜봇의 실제 대화는 평균 5~7턴을 넘어가는 경우가 흔합니다.

TTS 단계에서 주의할 점은 숫자와 단위 처리입니다. "3.5%"를 "삼 쩜 오 프로"로 읽어야 하는지, "삼 점 오 퍼센트"로 읽어야 하는지, 금융 도메인에서는 이 차이가 민원 사유가 됩니다. "만원"과 "일만원"의 처리, 날짜 표기 "24.01.15"와 "2024년 1월 15일"의 처리 등 금융 특화 텍스트 정규화(Text Normalization) 규칙이 TTS에 제대로 반영되어 있는지는 PoC 환경의 정제된 텍스트만 돌려서는 확인이 어렵습니다.

단계	PoC에서 놓치기 쉬운 포인트	운영에서 드러나는 방식
STT	노이즈 환경 인식률, 도메인 용어 인식	실제 통화 인식률 저하, 오인식 기반 잘못된 응답
LLM	대규모 RAG 레이턴시, 멀티턴 맥락 유지	응답 지연 누적, 앞 맥락 소실로 인한 오답
TTS	도메인 숫자·단위 처리, 텍스트 정규화	잘못된 발음, 고객 민원, 재청취 요청 증가

실부하 기반 PoC 검증 체크리스트

이런 갭을 줄이려면 PoC 검증 기준 자체를 바꿔야 합니다. 흔히 PoC 통과는 "동작하는가"로 판단하기 쉽지만, 실제로 던져야 할 질문은 "이 규모·이 부하에서도 동작하는가"입니다. 아래는 이 기준으로 정리한 체크리스트입니다.

문서 규모 테스트: PoC에서 사용한 문서 수의 최소 50배 이상을 투입한 상태에서 RAG 레이턴시를 측정합니다. 운영 예상 문서 규모를 알 수 없다면 1만 건과 5만 건 두 시나리오로 각각 측정합니다. p50이 아닌 p95, p99 기준으로 목표치를 설정합니다. 일반적으로 콜봇 전체 파이프라인의 p95 레이턴시는 1.5초 이내를 목표로 하는 것이 적절합니다.

엣지케이스 시나리오: 정형 시나리오 외에 다음 유형을 반드시 포함합니다. 지식 범위 밖 질문("담당자 연결해주세요" 같이 봇이 처리할 수 없는 요청), 이전 발화를 참조하는 맥락 의존 질문, 동시 여러 요청을 한 문장에 담은 복합 질문, 긴 침묵 후 재개되는 세션입니다. 이 네 유형에서 올바른 핸드오프(상담사 전환)가 발동하는지를 확인합니다.

실부하 측정: 단일 세션 성능이 아닌 동시 세션 부하 상태에서의 성능을 측정합니다. 예상 피크 동시 세션의 80% 부하를 걸었을 때 각 퍼센타일 레이턴시가 어떻게 변하는지, 그리고 부하가 빠졌을 때 회복 시간이 얼마나 걸리는지를 PoC 단계에서 확인합니다. 이것은 계약 범위에 명시적으로 포함시켜야 합니다. "별도 부하 테스트는 계약 외"라는 식으로 처리되면 운영 전환 시 성능 재협상 분쟁으로 이어질 수 있습니다.

STT 실환경 테스트: 실제 녹취 파일을 활용한 인식 테스트를 PoC에 포함시킵니다. 클린 마이크 환경이 아니라, 실제 고객 통화 환경을 시뮬레이션한 노이즈가 포함된 오디오로 측정합니다. 도메인 특화 용어 목록을 만들어서 해당 단어들의 인식 정확도를 별도로 측정하고, 필요 시 STT 사용자 정의 모델(Custom Speech Model) 적용 가능 여부를 확인합니다.

[참고] PoC 검증 기준은 계약서에 명시하지 않으면 효력이 없습니다. "성능 기준 충족 시 계약 전환" 조항을 작성할 때 위 항목들이 포함되었는지 확인하고, 측정 방법과 기준값(p95 1.5초 이하 등)을 수치로 명시해야 합니다. 정성적 표현("충분히 빠른", "만족스러운 수준")은 이후 분쟁의 씨앗이 됩니다.

자주 묻는 질문(FAQ)

Q1. PoC가 잘 됐으면 운영도 잘 되는 것 아닌가요?
PoC 환경과 운영 환경은 구조가 다릅니다. PoC는 통제된 소규모 데이터, 단일 세션, 정형 시나리오로 진행되는 반면, 운영은 대규모 문서, 동시 세션, 범위 밖 질문을 모두 처리해야 합니다. 특히 RAG 파이프라인은 문서 규모가 커질수록 레이턴시 특성이 달라지므로, PoC 결과를 운영 성능의 직접 근거로 보기 어렵습니다.

Q2. RAG 레이턴시는 인덱스 튜닝으로 해결할 수 있나요?
가능합니다. HNSW 파라미터(ef, M 값) 조정, ANN 알고리즘 선택, 필터링 전략 최적화 등으로 상당한 개선이 가능합니다. 그러나 이 작업은 운영 규모의 실제 데이터를 기반으로 해야 하며, PoC 이후 별도 최적화 공수가 필요합니다. 계약 범위에 이 작업이 포함되어 있는지 확인해야 합니다.

Q3. PoC 검증 기준을 높이면 수주 협상이 복잡해지지 않나요?
단기적으로는 그렇습니다. 하지만 기준이 낮은 PoC를 통과하고 운영 전환 시 성능 문제가 터지면 더 큰 비용이 발생합니다. 재협상, 추가 개발, 서비스 지연, 최악의 경우 계약 분쟁까지 이어집니다. 구매자 입장에서는 초기 협상이 복잡해지더라도 명확한 기준을 세우는 것이 장기적으로 유리합니다. 참고로 이 글의 판단은 필자의 현장 경험에 기댄 것이되, 회사명과 고객사명, 구체적 수치는 모두 일반화해 2026년 7월 기준으로 정리했습니다.

AI 보이스봇이 답답한 이유: Cascaded 구조 레이턴시 완전 분석

6월 13, 2026

자세한 내용 보기

이 블로그 검색

AI에이전트엔지니어링