회사 문서를 고객 안내 챗봇으로 바꾸는 8단계

고객은 보통 같은 질문을 반복합니다.

“설치 전에 뭘 준비해야 하나요?”
“AS는 어디로 접수하나요?”
“가격은 어떻게 결정되나요?”
“이 경우에는 담당자 확인이 필요한가요?”

담당자는 매번 비슷한 답을 다시 씁니다. 문제는 시간이 아니라 일관성입니다. 같은 회사 안에서도 사람마다 설명이 조금씩 달라지고, 오래된 가격표나 예전 안내문이 섞이면 고객은 더 헷갈립니다.

반복 문의가 쌓이면 담당자의 시간이 줄어드는 것보다 먼저, 안내 기준이 흔들리기 시작합니다.

AI 자동 안내 챗봇은 이 문제를 줄이기 위한 시스템입니다. 다만 좋은 챗봇은 모델 하나를 설치한다고 만들어지지 않습니다. 먼저 회사 문서를 정리하고, 그 문서를 AI가 찾기 쉬운 형태로 바꾸고, 고객 질문이 들어오면 근거를 찾아 답하게 해야 합니다.

우리가 말하는 “LLM 튜닝”도 모델을 무작정 다시 학습시키는 일이 아닙니다. 문서, 검색, 프롬프트, 평가, 운영 기록을 계속 다듬어 자동 안내 품질을 높이는 전체 과정입니다.

1. 자동화할 질문과 사람이 맡을 질문을 나눕니다

처음 해야 할 일은 챗봇에게 무엇을 시킬지 정하는 것입니다.

자동 안내 시스템은 모든 상담을 대신하지 않습니다. 반복적이고 기준이 분명한 안내를 먼저 맡깁니다. 견적 확정, 계약 변경, 환불 판단, 법적 책임이 생길 수 있는 답변은 담당자에게 넘겨야 합니다.

이 경계를 먼저 정해야 챗봇이 과하게 답하지 않습니다. 자동화의 목표는 사람을 없애는 것이 아니라, 사람이 봐야 할 질문을 더 선명하게 모아주는 것입니다.

2. 챗봇이 참고할 회사 자료를 모읍니다

그다음은 자료 수집입니다. 여기서 중요한 점은 “AI에게 줄 데이터”가 아니라 “고객에게 근거로 보여줄 수 있는 문서”를 모은다는 것입니다.

준비할 자료는 생각보다 평범합니다.

이 단계에서 이미 절반은 결정됩니다. 챗봇의 품질은 모델 이름보다 문서 정리 상태에서 먼저 갈립니다. 문서가 오래됐거나 서로 충돌하면, 아무리 좋은 모델을 써도 답변은 흔들립니다.

3. 문서를 AI가 찾기 쉬운 형태로 바꿉니다

AI는 긴 PDF 한 덩어리보다 잘 나뉜 문단과 메타데이터를 더 잘 사용합니다.

그래서 문서를 작은 단위로 나누고, 각 문단에 제목, 버전, 공개 범위, 담당 부서, 유효기간을 붙입니다. 고객에게 보여도 되는 문서와 내부 직원만 봐야 하는 문서를 구분하는 것도 이 단계에서 합니다.

문서 수집의 목표는 파일을 많이 넣는 것이 아니라, AI가 근거로 사용할 수 있는 지식베이스를 만드는 것입니다.

실제 작업 흐름은 이렇습니다.

1. 원본 문서를 보관합니다.
2. 최신 버전인지 확인합니다.
3. 텍스트를 추출합니다.
4. 문단 단위로 나눕니다.
5. 문서마다 공개 범위와 담당자를 붙입니다.
6. 검색 인덱스에 넣습니다.
7. 오래된 문서와 실패한 문서를 따로 기록합니다.

이 과정을 거치면 회사 문서는 단순한 파일 묶음이 아니라 챗봇이 검색할 수 있는 지식베이스가 됩니다.

4. 질문이 들어오면 문서에서 근거를 찾게 합니다

여기서 RAG가 등장합니다.

RAG는 쉽게 말해 AI에게 이렇게 시키는 구조입니다.

네 기억으로 대충 답하지 말고, 우리 문서에서 근거를 찾아 보고 답해.

고객이 홈페이지나 앱에서 질문하면, 시스템은 먼저 질문 의도를 확인합니다. 그다음 회사 문서에서 관련 문단을 찾고, 접근 권한을 확인한 뒤, LLM에게 그 근거를 넘깁니다. LLM은 전달받은 근거 안에서 답변을 만듭니다.

RAG 구조에서는 답변보다 먼저 근거를 찾습니다. 그래야 고객 안내에 기준이 생깁니다.

이 구조의 장점은 답변의 기준이 생긴다는 점입니다. 고객에게 답할 때 “AI가 그렇게 말했습니다”가 아니라 “어떤 문서를 근거로 답했습니다”라고 설명할 수 있습니다.

5. 모델과 장비는 규모에 맞춰 고릅니다

모델과 장비 선택은 처음부터 하나로 고정하지 않아도 됩니다. 카탈로그에서는 세 가지 선택지로 설명하는 것이 가장 이해하기 쉽습니다.

처음부터 대형 장비를 고정하지 않습니다. 문서와 질문으로 검증한 뒤 필요한 만큼 확장합니다.

작은 검증: Mac, 미니 PC, 개인 워크스테이션

처음에는 작은 장비로 충분합니다. Mac이나 미니 PC, 개인 워크스테이션에 Ollama, llama.cpp, MLX LM 같은 로컬 실행 환경을 올리고 소형 LLM을 실행합니다.

이 단계의 목적은 “우리 문서로 답변이 되는가”를 보는 것입니다. 속도와 대규모 동시접속보다 문서 정리, 검색 품질, 답변 규칙을 먼저 확인합니다.

1차 검증 후보 조합은 Qwen2.5-7B-Instruct + BGE-M3 + BGE reranker v2-m3입니다. Qwen2.5-7B-Instruct는 Apache-2.0 라이선스 모델이고, BGE-M3는 다국어 검색용 임베딩 모델 후보입니다. 다만 한국어 상담 품질과 실제 속도는 회사 문서 샘플로 실측해야 합니다.

사무실 운영: GPU 서버 또는 워크스테이션

고객용 홈페이지나 출판 앱에 붙이려면 서버 형태가 필요합니다. 사용자는 웹사이트에서 질문하지만, 실제 처리는 사무실 안의 AI 서버가 담당합니다.

이 구성에서는 홈페이지나 앱이 직접 모델을 들고 있지 않습니다. 앱은 질문을 서버로 보내고, 서버가 문서 검색과 LLM 답변을 처리합니다. 이렇게 하면 모델 교체, 문서 업데이트, 로그 관리, 권한 관리가 쉬워집니다.

대형 운영: DGX Spark 또는 DGX급 AI 서버

문서가 많고, 여러 사용자가 동시에 쓰고, 더 큰 모델이나 파인튜닝까지 검토한다면 DGX Spark나 DGX급 AI 서버를 선택지에 넣을 수 있습니다.

DGX Spark는 NVIDIA 공식 기준 128GB 통합 시스템 메모리를 제공하고, 최대 70B급 모델 파인튜닝 가능성을 제품 설명에 포함합니다. 이런 장비는 단순히 “더 빠른 컴퓨터”라기보다 큰 모델과 여러 AI 작업을 한 박스에서 운용하기 위한 선택지입니다.

모든 사업이 처음부터 이런 장비를 살 필요는 없습니다. 작은 모델로 먼저 검증하고, 실제 문의량과 문서 규모가 커질 때 서버를 키우는 방식이 더 현실적입니다.

6. 홈페이지나 출판 앱에 연결합니다

고객이 보는 화면은 단순해야 합니다.

웹사이트 오른쪽 아래의 채팅창, 전자 카탈로그 안의 “질문하기” 버튼, 출판 앱의 도움말 화면처럼 자연스럽게 붙입니다. 사용자는 복잡한 AI 시스템을 볼 필요가 없습니다. 그냥 질문하고 답을 받으면 됩니다.

고객은 채팅창만 보지만, 뒤에서는 문서 검색, 권한 확인, LLM 답변, 담당자 전환이 함께 움직입니다.

뒤에서는 다음 일이 일어납니다.

1. 사용자가 질문을 입력합니다.
2. 앱이 백엔드 API로 질문을 보냅니다.
3. 서버가 질문 유형을 분류합니다.
4. 문서 검색기가 근거 문단을 찾습니다.
5. 권한 필터가 비공개 문서를 제외합니다.
6. LLM이 정해진 말투로 답변을 만듭니다.
7. 근거가 부족하면 담당자 연결로 전환합니다.
8. 질문, 근거, 답변, 전환 사유를 로그로 남깁니다.

카탈로그에서 보여줄 핵심은 이것입니다.

챗봇은 홈페이지에 보이는 작은 창이지만, 실제로는 문서 정리, 검색, 모델, 서버, 담당자 전환이 연결된 안내 시스템입니다.

7. 실제 질문으로 시험합니다

챗봇은 감으로 완성도를 판단하지 않습니다. 실제 질문 시험지가 필요합니다.

처음에는 20~30개 질문이면 충분합니다. 쉬운 FAQ, 복잡한 비교 질문, 문서에 없는 질문, 권한 밖 질문, 담당자 전환 질문을 섞습니다.

채점 기준도 단순하게 시작합니다.

이 시험지가 있어야 “튜닝 전보다 좋아졌다”고 말할 수 있습니다.

8. 운영하면서 계속 튜닝합니다

좋은 자동 안내 시스템은 한 번 만들고 끝나지 않습니다. 고객 질문이 쌓이면, 어떤 문서가 부족한지 보입니다. 챗봇이 자주 틀리는 질문도 보입니다. 담당자에게 자주 넘어가는 질문도 보입니다.

실제 질문으로 시험하고, 틀린 이유를 문서·검색·프롬프트·모델 선택으로 나누어 고칩니다.

이때 튜닝은 다섯 가지로 나눠 생각합니다.

처음부터 모델을 다시 학습시키는 방식은 권장하지 않습니다. 먼저 문서를 고치고, 검색을 개선하고, 답변 규칙을 정리합니다. 그래도 같은 오류가 반복되고 충분한 예제가 쌓이면 그때 파인튜닝을 검토합니다.

마무리

AI 자동 안내 챗봇은 멋진 채팅창 하나가 아닙니다. 회사 문서를 정리하고, 검색 가능하게 만들고, 모델이 근거를 보고 답하게 하고, 사람에게 넘겨야 할 질문을 구분하는 운영 시스템입니다.

그래서 시작점은 모델 구매가 아닙니다.

시작점은 회사가 고객에게 어떤 기준으로 안내할지 정하는 것입니다. 그 기준이 문서가 되고, 문서가 검색 시스템이 되고, 검색 시스템이 LLM과 연결될 때 비로소 자동 안내 챗봇이 됩니다.

작게는 Mac이나 미니 PC에서 소형 LLM으로 검증할 수 있습니다. 운영 단계에서는 사무실 GPU 서버로 홈페이지와 출판 앱에 연결할 수 있습니다. 더 큰 규모에서는 DGX급 장비를 검토할 수 있습니다.

온프레미스 방식이라면, 외부 LLM API, 외부 분석 로그, 원격 백업을 사용하지 않도록 구성하고 네트워크 경로를 검증한 경우에 고객 질문과 답변 로그는 사무실 안의 AI 서버에 머무릅니다. Core Company의 핵심 약속인 “당신의 데이터는 밖으로 나가지 않는다”는 바로 이 구성에서 지켜집니다.

중요한 것은 순서입니다.

문서를 먼저 정리하고, 검색을 붙이고, 실제 질문으로 시험하고, 운영 기록을 보며 튜닝합니다. 그렇게 해야 AI 챗봇은 신기한 데모가 아니라 고객 안내 품질을 높이는 실제 시스템이 됩니다.