사내 AI 챗봇 응답이 느릴 때, 범인은 AI가 아니었습니다

질문을 보내면 화면에 "생각하는 중"이 떴습니다. 그 문구가 1분에서 길게는 4분까지 그대로 있었습니다.

2026년 8월, 보험대리점(GA) 지사 고객관리 시스템에 붙인 AI 비서에 실제 질문을 넣어 보던 중이었습니다.

저는 범인을 바로 정했습니다. 언어모델이 답을 만드는 데 오래 걸린다고 생각했습니다.

"언어모델이 느리다"는 가설

이 가설은 너무 자연스러웠습니다. 화면에 뜨는 말부터가 "생각하는 중"이니, 기다리는 시간은 곧 AI가 생각하는 시간처럼 보입니다.

근거도 있어 보였습니다. 비서를 다듬으면서 프롬프트에 붙는 것이 계속 늘었기 때문입니다.

실무지식 8건, 약관 5건, 계약 구조, 그리고 직전 대화 6턴까지 실렸습니다. 그 무렵 응답이 1~2분대로 걸리는 것을 봤습니다.

서버가 요청을 끊는 120초 문턱 바로 앞이었습니다. 저는 이것을 프롬프트가 무거워진 탓으로 읽었습니다.

그래서 처음 떠올린 대책도 모델 쪽이었습니다. 붙이는 근거를 줄이는 방법도 있었고, 답을 만들어지는 대로 흘려보내는 방법도 있었습니다.

먼저 넣은 스트리밍

저는 스트리밍부터 넣었습니다. 전체 생성 시간이 같아도 첫 글자는 바로 뜹니다.

답이 오는 동안 연결이 살아 있으니 120초 문턱에서 통째로 실패할 위험도 줄이려 했습니다.

구현에서 챙긴 부분도 있습니다. 서버가 흘려보내는 동안 답을 모아 두었다가 대화 이력에 저장했습니다.

스트리밍이 안 되는 경우에는 예전처럼 한 번에 받는 경로로 돌아가게 했습니다.

스트리밍을 넣고 나서야 원인이 다른 데 있다는 걸 찾았습니다. 범인을 잘못 짚었던 겁니다.

나중에 회고에 이렇게 적었습니다. "LLM이 느리다는 건 가장 편한(틀린) 가설이었다."

이 AI 비서가 하는 일

원인을 말하려면 구조부터 보셔야 합니다. 질문 하나가 들어오면 답이 나가기까지 여러 단계를 거칩니다.

비서가 참고하는 자료는 실무지식 2,582건, 보험 약관 11,236개 조항, 보험 뉴스입니다. 질문에 맞는 근거를 골라 프롬프트에 붙이는 RAG 방식입니다.

고객 정보는 다르게 다룹니다. 고객 이름·주민번호·연락처는 언어모델에 보내지 않는 것이 처음부터의 원칙이었습니다.

그래서 질문에 고객 이름이 들어 있는지 먼저 알아보는 단계가 있었습니다. 누구를 가리키는지 알아야 이름을 가리고 계약 구조만 넘길 수 있습니다.

이름을 가리는 구조 자체는 개인정보를 AI에 보내지 않는 방법을 참고하세요.

단계	하는 일
고객 확인	질문 속 이름이 우리 고객인지 조회
근거 검색	실무지식·약관·뉴스에서 관련 문서 찾기
프롬프트 조립	근거와 대화 이력을 묶기
모델 생성	언어모델이 답 작성
화면 표시	답을 대화창에 그리기

"생각하는 중"은 이 다섯 단계를 모두 덮고 있었습니다. 저는 그중 넷째 칸만 의심하고 있었습니다.

각 단계에 시각을 찍어 두지 않았으니 어느 칸이 긴지 볼 방법이 없었습니다. 저는 화면 문구만 보고 원인을 정했습니다.

DB 활동 화면에 걸린 14초

추측을 멈추고 DB를 열었습니다. PostgreSQL에는 지금 돌고 있는 쿼리와 경과 시간을 보여 주는 활동 조회가 있습니다.

질문이 처리되는 동안 그 화면을 보니 14초째 돌고 있는 쿼리가 하나 걸려 있었습니다.

고객 검색 쿼리였습니다. 고객 확인은 언어모델을 부르기 전 단계입니다.

돌고 있는 쿼리를 보는 데는 별도 도구가 필요 없습니다. 활동 조회에서 경과 시간이 긴 순으로 정렬하기만 해도 범인이 맨 위에 올라옵니다.

단어마다 돌던 고객 검색

코드를 따라가 보니 구조가 드러났습니다. 고객 확인 단계가 질문을 한글 단어로 쪼갠 뒤, 단어마다 고객 검색을 차례로 부르고 있었습니다.

단어는 최대 6개까지 잘랐습니다. 질문이 조금만 길어도 검색이 여섯 번 줄을 섰습니다.

검색 한 번도 무거웠습니다. 이름의 일부만 맞아도 찾도록 부분일치로 걸어 두어 인덱스를 못 타고 고객 표를 처음부터 끝까지 훑었습니다.

거기에 고객마다 건수를 세는 서브쿼리가 붙어 있었습니다. 고객 약 1.2만 건마다 그 계산이 반복되면서 단어 하나에 십수 초가 들었습니다.

이 함수는 이름 일부로 고객을 찾는 검색이었습니다. 부분일치와 건수 계산은 사람이 몇 글자 치고 고르는 자리라면 쓸모가 있는 구조입니다.

대화창은 그 함수를 단어마다 불렀습니다. 한 번 부를 때의 무게가 대화 한 번에 최대 여섯 겹으로 쌓였습니다.

고친 방법은 단순했습니다. 대화창 전용으로 정확히 일치하는 이름만, 인덱스를 타는 쿼리 한 번에 모아서 찾게 했습니다.

항목	고치기 전	고친 뒤
검색 횟수	단어마다, 최대 6번	한 번
맞추는 방식	이름 부분일치	이름 정확일치
읽는 범위	고객 표 전체 + 건수 계산	인덱스

대가도 있습니다. 성만 쓰거나 이름을 줄여 쓰면 이제 고객으로 알아보지 못합니다.

이 기능의 목적은 이름을 가리는 일이었습니다. 비슷한 후보를 사람에게 골라 보라고 보여 줄 일이 없으니 정확일치로 좁혀도 되는 자리였습니다.

고친 뒤의 정확한 응답 시간은 따로 재서 남겨 두지 못했습니다. 다음에 같은 일을 하신다면 고치기 전과 후를 같은 질문으로 재서 적어 두세요.

프롬프트 무게도 숙제로 남아 있습니다. 근거 문서 수에 상한을 두는 일은 답의 질과 바로 이어져 있어 따로 저울질해야 합니다.

실측하다 진짜 사용자를 막은 날

같은 날 실패가 하나 더 있었습니다. 라이브 화면을 자동 브라우저로 빠르게 돌려 보며 검증하던 중이었습니다.

앞단의 보안 장비가 그 움직임을 크롤링으로 판단했습니다. 문제는 차단이 제 접속에서 끝나지 않았다는 점입니다.

같은 통신사 대역을 쓰던 실제 사용자까지 403 화면을 받았습니다. 저는 차단을 풀고, 크롤링 탐지 규칙만 뺐습니다.

로그인해야 들어오는 내부 업무 시스템이라 크롤링 탐지로 얻는 것이 거의 없었습니다. 대량 요청 공격, 비밀번호 대입, 알려진 취약점 공격 방어는 그대로 뒀습니다.

여기서 하나 더 배웠습니다. 운영 중인 시스템을 잴 때는 측정 자체도 사용자에게 닿는 행동이라, 속도와 횟수를 조절해야 합니다.

이미 붙인 챗봇이 느릴 때

사내에 AI 챗봇을 붙였는데 직원들이 기다리다 창을 닫는다면 모델부터 바꾸지 마세요. 대기 시간을 구간별로 먼저 나눠 보세요.

제 경우에는 모델을 부르기 전 단계에서 시간이 새고 있었습니다.

제가 만든 고객관리 시스템의 화면 구성은 이음 데모에 가짜 데이터로 옮겨 두었습니다.

이미 붙인 챗봇이 느리다면 AI 자동화 상담에서 지금 구조를 같이 보면 됩니다. 고객 정보를 모델에 보내지 않고 사내 문서로 답하는 비서를 새로 만드는 것도 같은 자리에서 다룹니다.

직원들이 AI 답을 확인하는 습관부터 잡고 싶다면 생성형 AI 업무활용 강의가 맞습니다.

답이 늦을 때 잴 곳

제가 다음 챗봇에서 쓰는 순서입니다. 위에서부터 차례로 보세요.

1. 응답 시간을 구간으로 나눠 잽니다. 데이터 조회, 프롬프트 조립, 모델 생성, 화면 표시에 각각 시각을 찍습니다.
2. 질문을 보내 놓고 DB의 활동 조회를 엽니다. 저는 여기서 14초짜리 고객 검색을 찾았습니다.
3. 질문을 단어로 쪼개 단어마다 검색하는 구조가 있는지 봅니다. 있다면 한 번의 조회로 묶을 수 있는지 확인합니다.
4. 사람이 직접 고르는 용도의 부분일치 검색을 대화마다 부르고 있는지 봅니다. 그 무게가 질문마다 반복되고 있을 수 있습니다.
5. API 시간은 로그인한 세션으로 잽니다. 로그인 없이 찌르면 로그인 화면으로 돌려보내져 엉뚱한 응답을 보고 판단하게 됩니다.
6. 운영 서버에서 잴 때는 요청 속도를 낮춥니다. 보안 장비가 측정을 공격으로 보고 같은 대역 사용자까지 막을 수 있습니다.
7. 프롬프트에 붙는 근거 문서 수와 대화 턴 수에 상한을 둡니다. 서버의 요청 제한 시간과 실제 생성 시간을 나란히 적어 두세요.
8. 그래도 길면 스트리밍으로 첫 글자를 먼저 띄웁니다. 대화 이력 저장과 실패 시 되돌아갈 경로를 같이 만듭니다.
9. "모델이 느리다"는 결론은 여기까지 다 본 뒤에 내립니다.