LLM 챗봇 설계, 우리가 답변보다 구조를 먼저 고민한 이유
LLM(Large Language Model)이 대중화되면서 많은 서비스가 챗봇을 도입하고 있습니다. 하지만 단순히 API를 호출하는 코드를 작성하는 것과, 실제 운영 환경에서 비즈니스 가치를 줄 수 있는 챗봇을 만드는 것은 전혀 다른 차원의 문제였습니다. 이번 글에서는 라이브 환경의 특수성을 고려하며 챗봇을 설계했던 과정과 그 과정에서의 의사결정들을 공유하고자 합니다.
💬일반 FAQ 챗봇과 라이브 챗봇은 무엇이 달랐나
흔히 접하는 FAQ 챗봇은 답변의 근거가 되는 자료가 정적이며, 질문의 범주 역시 서비스 용도에 맞춰 명확하게 제한되어 있는 경우가 많습니다. 반면 저희가 구현해야 했던 라이브 환경은 방송마다 판매하는 상품과 카테고리가 매번 달라지며, 그에 따른 운영 정책도 시시각각 변하는 곳이었습니다.
여기서 가장 큰 설계 고민이 시작되었습니다. 특정 방송이나 상품군에만 특화된 프롬프트를 구성하면 당장의 정확도는 높일 수 있지만, 이는 지속 가능한 운영 방식이 아니었습니다. 특정 카테고리에 너무 맞춘(Overfitting) 프롬프트를 구성하면, 다른 성격의 데이터가 들어왔을 때 의도치 않은 간섭이 발생하거나 답변의 일관성이 깨질 위험이 컸기 때문입니다. 결국 '데이터의 성격이 바뀌어도 흔들리지 않는 범용적인 판단 기준'을 잡는 것이 무엇보다 중요했습니다. 데이터를 어떻게 가공하고 어떤 기준으로 질문을 판별할지, 그 메커니즘을 추상화하여 어떤 도메인의 데이터가 들어와도 유연하게 대응할 수 있는 구조를 만드는 데 집중했습니다.
📂답변 생성 전에 질문을 먼저 분류해야 했던 이유
사용자의 모든 메시지를 곧바로 답변 생성 단계로 넘기는 것은 운영 측면에서 큰 리스크였습니다. LLM 호출은 비용과 직결될 뿐만 아니라, 무의미한 채팅이나 방송과 무관한 질문이 입력될 경우 환각(Hallucination) 현상이 발생해 라이브 진행에 부정적인 영향을 줄 수 있는 답변이 생성될 위험이 있었기 때문입니다. 이를 방지하기 위해 저희는 질문의 적합성을 판단하는 단계를 세분화했습니다.
초기 단계에서는 두 단계의 필터링을 거쳤습니다. 먼저 정규식(Regex)을 이용한 1차 판별을 통해 의미 없는 단순 채팅을 걸러냈고, 이어지는 2차 단계에서는 LLM을 활용해 해당 질문이 현재 방송과 연관이 있는지, 어떤 데이터가 필요한지를 분류했습니다. 이때 2차 LLM의 부하를 줄이기 위해 방대한 로우 데이터 전체가 아닌, 이를 요약한 핵심 정보만을 컨텍스트로 제공하여 방송 연관성을 체크하도록 설계했습니다. 이 과정을 통과한 질문만이 실제 답변 생성에 필요한 로우 데이터를 전달받아 최종 응답을 만들 수 있었습니다.
하지만 시스템이 고도화되면서 이 구조에도 변화가 생겼습니다. 단순히 로우 데이터를 그대로 넘기는 방식에서 벗어나, LLM을 통해 로우 데이터 간의 정합성을 맞춘 정제된(Curated) 데이터를 답변 생성에 활용하게 된 것입니다. 답변에 쓰이는 데이터의 품질 자체가 이미 검증되었기 때문에, 2차 LLM에서 수행하던 복잡한 데이터 분류의 필요성이 낮아졌습니다. 결과적으로 '방송 무관 여부 체크' 로직을 답변 생성 LLM의 프롬프트에 통합함으로써, 호출 단계를 줄여 비용을 절감하고 응답 속도까지 개선하는 최적화된 구조로 발전할 수 있었습니다.
👨🏻💻답변 기계를 넘어 '디지털 운영자'로:
추론의 허용과 점수 체계
저희가 이번 프로젝트를 진행하며 가졌던 가장 큰 목표는 단순히 정보를 출력하는 답변 기계가 아니었습니다. 실제 라이브 방송을 운영하는 전문 인력을 대체할 수 있는, 진짜 사람 같은 챗봇을 만드는 것이었습니다. 실제 운영자는 정해진 매뉴얼에 완벽하게 일치하는 질문이 아니더라도, 자신이 알고 있는 정보들을 조합하고 상황을 추론하여 어떻게든 시청자의 궁금증을 해결해 줍니다.
이러한 '사람 같은 대응'을 위해 저희는 LLM의 사고력과 추론 능력을 프롬프트 수준에서 강하게 제어하지 않았습니다. 라이브 환경에서는 데이터에 정답이 문장 형태로 박혀 있지 않은 경우가 훨씬 많습니다. 파편화된 정보들을 LLM이 스스로 연결하고 논리적으로 추론해야만 비로소 답변의 근거를 찾아낼 수 있는 애매한 질문들이 존재하기 때문입니다. LLM의 추론 능력을 열어둠으로써, 챗봇은 더 넓은 범위의 질문에 대해 스스로 근거를 탐색하고 유연하게 답할 수 있게 되었습니다.
물론 추론을 폭넓게 허용하는 만큼 환각(Hallucination)의 리스크는 필연적으로 따라옵니다. 저희는 이를 억제하기 위해 추론을 막는 대신, 생성된 답변의 품질을 사후에 검증하는 '점수 체계 기반의 답변 필터링'을 설계했습니다.
근거 탐색 및 점수 산정: 생성된 답변이 명확한 근거 데이터를 바탕으로 논리적 정합성을 갖췄는지 평가합니다. 추론을 통해 애매한 질문에서 답변의 근거를 잘 찾아냈다면 높은 점수를 부여합니다.
최종 안전장치: 반대로 추론의 결과가 논리적으로 빈약하거나 근거가 아예 없는 '저득점 답변'에 대해서는 별도의 응답 전략을 취했습니다. 단순히 "모른다"고 답하며 흐름을 끊는 대신, "현재 정확한 확인은 어렵지만, 지금 방송 중인 상품에는 이런 혜택들이 있으니 참고해 보세요!"와 같이 시청자를 다시 방송 맥락으로 유도하는 템플릿을 적용했습니다.
결국 저희가 정의한 '사람 같은 챗봇'의 핵심은 LLM의 추론 능력을 최대한 활용해 답변의 근거를 끝까지 찾아내려는 노력, 그리고 데이터가 부족한 상황에서도 라이브의 호흡을 유지하는 유연함의 조화였습니다. 이를 통해 단순한 질의응답 시스템을 넘어, 방송의 활력을 유지하는 디지털 운영자로서의 역할을 수행하고자 했습니다.
⏳비용과 응답속도를 줄이기 위한 LLM 호출 최적화: 컨텍스트 캐싱 전략
LLM 기반 서비스를 설계할 때 비용과 지연시간(Latency)은 언제나 큰 숙제입니다. 특히 저희 프로덕트의 경우, 일반적인 챗봇 UI처럼 답변이 한 글자씩 써지는 '스트리밍(Streaming)' 방식을 사용할 수 없는 환경이었습니다. 기존 채팅 서버를 통해 완성된 답변 메시지를 한 번에 전송해야 했기에, LLM의 답변 생성 시간은 사용자가 대기해야 하는 시간과 정확히 일치했습니다. 즉, 생성 속도가 사용자 경험 그 자체인 구조였습니다.
여기에 더해 사고형 모델(Reasoning Model)로 시스템을 고도화하면서 비용과 속도에 대한 부담은 더욱 커졌습니다. 모델의 사고력이 깊어질수록 품질은 올라가지만 연산량과 토큰 소모량이 늘어나기 때문입니다. 운영 측면에서 지속 가능한 구조를 만들기 위해 저희가 선택한 솔루션은 '컨텍스트 캐싱(Context Caching)'이었습니다.
하지만 모든 데이터를 캐싱할 수는 없었습니다. 라이브 환경에서는 데이터의 성격에 따라 실시간성이 요구되는 정도가 다르기 때문입니다. 저희는 데이터를 두 가지 성격으로 분류하여 전략을 이원화했습니다.
실시간성이 핵심인 '혜택 및 이벤트' 데이터: 쿠폰 마감이나 방송 전용 혜택은 실시간 방송 여부나 재방송 여부에 따라 수시로 변합니다. 데이터의 양이 비교적 적고 정제된 형태였기에, 이 정보는 캐싱하지 않고 매 호출마다 최신 정보를 주입하여 실시간성을 최우선으로 확보했습니다.
방대하지만 변화가 적은 '상품 상세' 데이터: 상품의 고유 특성, 스펙, 크롤링된 방대한 리뷰 데이터 등은 답변의 풍부함을 더해주지만 매번 전송하기엔 비용과 속도 부담이 큽니다. 다행히 상품 정보 자체는 방송 중에 빈번하게 변하지 않습니다. 저희는 이 방대한 상품 정보를 컨텍스트 캐싱으로 처리하여, 모델이 미리 정보를 '기억'하고 있게 했습니다.
여기서 한 가지 짚고 넘어갈 점은, 질문과 답변 쌍을 저장하는 '단순 응답 캐싱'은 철저히 배제했다는 것입니다. 라이브 방송은 초 단위로 상황이 변하는 도메인입니다. 방금 전 질문에는 정확했던 답변이, 불과 몇 초 뒤 데이터가 업데이트 되거나 방송 상황이 바뀌면 순식간에 '틀린 답변'이 될 수 있기 때문입니다. 예를 들어 "쿠폰 남았어?"라는 동일한 질문에 대해 캐싱된 답변을 내보낸다면, 실제로는 쿠폰이 소진되었음에도 남았다고 안내하는 치명적인 오류를 범하게 됩니다.
결국 저희는 답변 자체를 캐싱하여 발생할 수 있는 리스크를 감수하기보다, 입력 데이터의 성격을 분석해 컨텍스트를 캐싱하는 방식을 택했습니다. 이를 통해 속도 면에서 큰 이득을 보았을 뿐만 아니라, 캐싱된 토큰에 대해서는 일반 비용의 약 10% 수준으로 운영이 가능해지면서 정확도와 비용이라는 두 마리 토끼를 잡는 핵심 설계가 되었습니다.
마치며
LLM의 기술 발전은 이미 무서울 정도로 빠르게 진행되고 있습니다. 이제는 주어진 정보 안에서 정답을 찾고, 자연스러운 문장으로 답변하는 능력 자체는 점점 기본값에 가까워지고 있습니다. 실제 서비스에서 중요한 것은 그다음 단계라고 생각합니다. 정확한 답변을 생성하는 것을 넘어, 그 답변이 어떤 온도와 태도로 전달되는지를 설계하는 일입니다.
LLM과 사람의 차이는 단순히 지식의 양이나 답변 속도에만 있지 않습니다. 사람은 상대의 상황을 한 번 더 생각하고, 너무 단정적으로 말하지 않으며, 때로는 조심스럽게 말을 고릅니다. 반면 LLM은 매우 유창하게 답할 수 있지만, 그 유창함만으로는 사람이 느끼는 배려나 신뢰의 감각을 온전히 대체하기 어렵습니다.
저희가 만들고자 한 챗봇도 바로 그 지점에 있었습니다. 비록 LLM을 기반으로 동작하지만, 단순한 자동 응답기가 아니라 실제 운영자가 방송을 함께 보며 대응하는 것처럼 느껴지는 디지털 운영자에 가까운 경험을 제공하고 싶었습니다. 이를 위해 질문 분류, 데이터 정제, 점수 기반 검증, 컨텍스트 캐싱, RAG까지 다양한 설계를 고민했고, 각각의 선택은 더 정확한 답변뿐만 아니라 더 자연스럽고 사람다운 대응을 만들기 위한 과정이었습니다.
앞으로도 LLM의 성능은 계속 좋아질 것입니다. 하지만 그 기술을 실제 서비스의 가치로 바꾸기 위해서는 모델이 얼마나 많이 알고 있는지만큼, 어떤 태도로 말하고 어떤 온도로 반응해야 하는지를 설계하는 일도 중요하다고 생각합니다. 저희는 앞으로도 정답을 잘 말하는 챗봇을 넘어, 라이브의 흐름을 이해하고 운영자의 감각과 온도를 담아낼 수 있는 챗봇으로 계속 고도화해 나가고자 합니다.