안녕하세요. 쓰리래빗츠입니다.

쓰리래빗츠 홈페이지의 도움말에는 매뉴얼웍스 챗봇이 있습니다. 매뉴얼웍스로 쓴 제품 문서를 근거로 답하는 챗봇입니다. 8월과 9월 두 달 동안 이 챗봇이 남긴 답변을 하나도 빼지 않고 열어 보았습니다. 질문이 아주 많지는 않아서 건수보다는 비율로 정리했습니다. 내부 직원이 시험 삼아 던진 질문도 일부 섞여 있습니다.

결론부터 말씀드리겠습니다. 이번 분석에서 챗봇이 제대로 답하지 못한 이유는 대부분 챗봇이 아니라 문서에 있었습니다. 가장 큰 개선 과제는 문서 보완이었고, 매뉴얼웍스에는 그 문서를 찾아 고치는 길이 이미 갖춰져 있습니다.

두 달 동안의 챗봇 답변

매뉴얼웍스 챗봇은 모든 답변을 기록하고, 다음 신호가 붙은 답변을 "아쉬운 답변"으로 골라 줍니다. 놓치는 답변이 없도록 넓게 잡기 때문에 제대로 답한 답변도 일부 섞입니다.

• 챗봇이 "문서에 없다"고 답한 경우

• 문서를 찾다가 검색 횟수 한도에 닿은 경우

• 독자가 "도움이 되지 않음"을 누른 경우

다음 표의 비율은 그 달의 전체 답변 가운데 해당 신호가 붙은 답변의 비율입니다. 한 답변에 여러 신호가 함께 붙을 수 있어서, 신호별 비율을 더하면 아쉬운 답변의 비율보다 큽니다.

두 달 모두 답변 두 건 가운데 한 건 가까이(45%)가 아쉬운 답변으로 잡혔습니다. 비율은 같았지만 속은 달랐습니다. 9월에는 검색 한도에 닿은 답변이 45%에서 31%로 줄고, "문서에 없다"고 답한 경우가 19%에서 27%로 늘었습니다.

같은 사람이 짧은 시간 안에 비슷한 질문을 다시 한 경우는 내부 시험을 빼면 없었습니다.

아쉬운 답변이 절반 가까이라는 숫자만 보면 "챗봇 모델을 바꿔야 하나?" 하는 생각이 먼저 듭니다. 그런데 하나씩 열어 보니 이야기가 달랐습니다.

아쉬운 답변을 하나씩 열어 보니

아쉬운 답변으로 잡힌 질문과 답변을 모두 읽고, 답변마다 대표 원인 하나를 골라 나눴습니다.

마지막 줄의 30%는 챗봇이 문서를 여러 번 찾느라 한도에 닿았을 뿐, 답변 자체는 문서에 맞았습니다. 정상 답변으로 확인된 이 30%를 빼고 나머지만 보면, 문서에 내용이 없거나(54%) 독자의 말과 문서의 말이 달라서(23%) 생긴 경우가 약 77%였습니다. 나머지는 제품과 상관없는 질문이나 모호한 질문이었습니다.

문서에 내용이 없었습니다

챗봇이 "문서에 없다"고 답한 질문의 상당수는 실제로 문서에 없었습니다.

• 전체 문서의 소유자 목록을 한 번에 보는 방법

• 리버스 프록시 뒤에서 서비스할 때 컨텍스트 경로를 설정하는 방법

• 장을 만들 수 있는 권한

• 3.0 버전에서 최신 버전으로 업데이트하는 순서와 설치 파일

고객이 실제로 궁금해하는 내용입니다. 매뉴얼웍스 챗봇은 제공한 문서로만 답하므로, 문서에 없는 내용을 지어내지 않고 "문서에 없다"고 정직하게 답했습니다. 더 좋은 모델로 바꿔도 문서에 없는 답은 나오지 않습니다. 나와서도 안 됩니다.

없는 기능도 "없다"고 적어야 합니다

흥미로운 점도 있었습니다. 다음 질문은 매뉴얼웍스가 지원하지 않는 기능을 묻는 질문입니다.

• 짧은 문서 여러 개를 PDF 파일 하나로 합치기

• 서로 다른 두 문서를 비교하기

• MySQL에서 기본 데이터베이스(H2)로 되돌리기

문서에 아무 언급이 없으니 챗봇은 "지원하지 않습니다"가 아니라 "문서에 없습니다"라고 답합니다. 독자는 기능이 없는지, 문서가 빠진 것인지 알 수 없습니다.

반면 "HWP로 내려받을 수 있나요?"라는 질문에는 "지원하지 않는다"고 분명하게 답했습니다. 내려받을 수 있는 파일 형식(PDF, EPUB, HTML, MS 워드)이 문서에 분명히 적혀 있었기 때문입니다. 지원하는 것을 분명히 적으면, 지원하지 않는 것도 답할 수 있습니다.

독자의 말과 문서의 말이 달랐습니다

문서에 내용이 있는데도 찾지 못한 경우도 있었습니다.

• 독자는 "SSO"라고 묻고, 문서는 "OAuth 2.0"과 "LDAP"으로 설명합니다.

• 독자는 "폴더"라고 묻고, 문서는 "디렉터리"라고 씁니다.

• 독자는 "줄 3개에 펜이 있는 아이콘"이라고 묻고, 문서는 "책 만들기"라는 이름으로만 설명합니다.

챗봇은 의미가 비슷한 단락을 찾지만, 독자의 말과 문서의 말이 멀면 놓칩니다. 해결은 어렵지 않습니다. 문서에 독자가 쓰는 말을 함께 적으면 됩니다.

지금은 관리자 가이드에 "사내 인증 시스템과 매뉴얼웍스를 SSO(Single Sign-On)로 연동할 때도 OAuth 2.0을 사용합니다."라는 문장이 있습니다. 문서를 보완한 뒤 같은 "SSO" 질문으로 챗봇의 검색 단계만 다시 돌려 보니, SSO를 언급한 단락 두 개가 1위와 2위로 검색되었습니다.

챗봇 탓으로 볼 만한 경우는 적었습니다

"문서 만드는데,"처럼 말이 끊긴 질문이나 "매뉴얼웍스로 피자 주문하는 방법" 같은 질문도 있었습니다. 이런 질문에 "문서에 없다"고 답하는 것은 올바른 동작입니다. 문서에 내용이 분명히 있던 질문에서는 검색 횟수 한도에 닿더라도 대부분 문서에 맞게 답했습니다.

6.0.26 버전에서는 이런 질문을 더 잘 다루도록 챗봇을 다듬었습니다. 짧은 질문이 서로 다른 기능을 가리킬 수 있으면 짐작해서 답하지 않고 어느 쪽을 묻는지 되묻습니다. 질문을 검색어로 바꿀 때는 AI 어시스턴트에 적은 제품 설명을 참고하므로, "인덱스"를 데이터베이스 인덱스로 읽는 것처럼 다른 제품의 내용으로 검색이 빗나가는 경우를 줄입니다.

그래서 챗봇보다 문서입니다

챗봇을 만들 때 먼저 고민하는 것은 대개 어떤 AI 모델을 쓸지, 어떤 임베딩 모델로 검색할지입니다. 물론 중요합니다. 하지만 두 달 동안의 로그를 보고 나니 생각이 분명해졌습니다. 모델을 바꾸면 말솜씨와 검색 순위는 조금 나아질 수 있습니다. 그러나 문서에 빠진 내용까지 채워 주지는 못합니다.

저희는 챗봇의 답변 품질이 챗봇 기능이나 AI 모델보다 문서에서 나온다고 생각합니다. 그리고 챗봇 로그는 독자가 문서에서 무엇을 찾지 못했는지 알려 주는 가장 솔직한 기록입니다. 독자가 직접 쓴 말로, 독자가 실제로 막힌 곳을 알려 줍니다.

그래서 문서를 쓰는 도구와 챗봇은 한곳에 있어야 합니다. 매뉴얼웍스에서는 문서를 쓰고, 그 문서로 챗봇이 답하고, 고칠 일을 태스크로 관리하는 일이 한 제품 안에서 이어집니다. 챗봇 로그에서 찾은 문제를 다른 시스템으로 옮길 필요 없이 바로 문서 개선으로 가져갈 수 있습니다.

로그에서 태스크로, 태스크에서 문서로

로그를 읽는 데서 끝나면 아무것도 달라지지 않습니다. 매뉴얼웍스는 챗봇 로그를 읽고, 고칠 일을 태스크로 만들고, 문서를 고치고, 다시 확인하는 과정을 AI 도구와 함께 이어 갈 수 있게 합니다. 사람은 무엇을 고칠지 정하고 결과를 확인합니다. 나머지는 AI에게 맡기는 반자동 방식입니다.

1단계. 아쉬운 답변 모으기

사용자: 8월과 9월 챗봇 답변 가운데 아쉬운 답변을 원인별로 나눠줘.

AI: 두 달 동안의 아쉬운 답변을 모두 읽었습니다.

- 문서에 내용이 없음: 전체 문서의 소유자 목록, 리버스 프록시 컨텍스트 경로 ...

- 독자의 표현과 문서의 용어가 다름: SSO, 폴더, 아이콘 모양 ...

- 제대로 답했지만 검색 횟수 한도에 닿음: ...

AI 도구는 매뉴얼웍스 MCP의 챗봇 이력 도구로 아쉬운 답변(get_chatbot_weak_answers)과 같은 사람이 다시 물은 질문(get_chatbot_reasks)을 찾습니다. 이미 남은 로그만 읽으므로 AI 모델을 새로 부르지 않고, 여러 날을 한꺼번에 볼 수 있습니다. 질문 원문을 함께 돌려주므로 독자가 어떤 말로 물었는지도 그대로 보입니다.

2단계. 고칠 일을 태스크로 만들기

사용자: "문서에 내용이 없음"과 "용어가 다름"으로 나눈 질문마다 고칠 문서와 장을 찾아 "문서 개선" 채널에 태스크로 만들어줘.

AI: 관련 장을 찾아 태스크를 만들었습니다.

- "관리자 가이드 - 사용자 관리: 전체 문서의 소유자를 한 번에 확인하는 방법 추가"

- "설치 가이드 - 리버스 프록시 구성 시 하위 경로를 지원하지 않는다는 점과 서브도메인 구성 방법 안내"

- "사용자 가이드 - 파일 만들기: 여러 문서를 한 파일로 합칠 수 없다는 점 명시"

- ...

태스크마다 독자의 질문 원문과 챗봇의 답변을 함께 적었습니다.

어떤 문서의 어느 장을 고칠지, 독자가 어떤 말로 물었는지가 태스크에 그대로 남습니다. 담당자를 정하고 마일스톤을 붙이면 문서 개선도 개발 일처럼 관리할 수 있습니다.

3단계. 문서 고치기

사용자: 리버스 프록시 태스크를 읽고 설치 가이드에 들어갈 단락 초안을 만들어줘. 어디에 넣을지도 알려줘.

AI: "리눅스 설치 가이드" 장 끝에 "리버스 프록시 뒤에서 서비스하기" 절을 새로 넣는 것을 제안합니다. 초안은 다음과 같습니다.

...

사용자: 좋아. 그 위치에 반영해줘.

AI: 단락을 추가했습니다. 태스크에 처리 결과를 답변으로 남기겠습니다.

초안은 AI가 쓰고, 확인은 사람이 합니다. 문서를 직접 고치기 부담스럽다면 브랜치에서 작업하고 검토한 뒤 병합할 수도 있습니다. 지원하지 않는 기능이라면 "지원하지 않는다"는 한 문장을, 독자가 쓰는 말이 다르다면 그 말을 함께 적는 것만으로도 충분한 경우가 많습니다.

4단계. 같은 질문으로 다시 확인하기

사용자: 고친 문서로 "SSO" 질문을 다시 검색해줘.

AI: 검색 단계만 다시 돌렸습니다.

1위: OAuth 2.0으로 사용자 관리하기 - "사내 인증 시스템과 매뉴얼웍스를 SSO로 연동할 때도 OAuth 2.0을 사용합니다."

2위: JSP를 이용한 사용자 로그인 처리 - "상용 SSO 솔루션 등 사내 인증 시스템과 ..."

이제 SSO를 언급한 단락이 가장 먼저 검색됩니다.

문서를 고친 뒤 벡터 저장소를 동기화하고, 독자가 했던 질문을 그대로 다시 넣어 봅니다. 답변과 근거 단락을 보거나(test_chatbot), 답변 없이 검색 순위만 볼 수 있습니다(test_chatbot_retrieval). 시험 실행은 고객 문의와 구분해 기록하며, 챗봇 이력을 조회할 때는 기본으로 빠집니다.

지금 바로 시작해 보세요

매뉴얼웍스 6.0.26 버전에서 챗봇과 관련해 다음이 달라졌습니다.

• 아쉬운 답변과 같은 사람의 재질문을 MCP로 찾습니다(get_chatbot_weak_answers, get_chatbot_reasks).

• 질문 하나로 답변과 근거 단락을 시험하거나 검색 순위만 확인합니다(test_chatbot, test_chatbot_retrieval).

• 모호한 짧은 질문에는 짐작해서 답하지 않고 되묻습니다.

• 질문을 검색어로 바꿀 때 어떤 제품의 문서를 찾는지 알고 검색합니다.

• "…를 참고합니다"처럼 다른 곳을 가리키기만 하는 단락은 검색 대상에서 뺍니다.

챗봇 이력을 읽는 MCP 도구는 "관리" 권한이 있는 사용자에게 보입니다. 챗봇을 설정하는 방법은 쓰리래빗츠 챗봇 가이드를, AI 도구를 연결하는 방법은 Claude Code/Codex/Gemini CLI에서 매뉴얼웍스 사용하기를 참고하세요.

이번 달 챗봇 로그를 AI 도구에게 건네 보세요. "아쉬운 답변을 모아서 고칠 문서를 태스크로 만들어줘." 이 한 문장이 문서를 고치는 출발점이 됩니다.