사내 문서 검색 AI, 우리 부서 자료로 시범 운영하려면 무엇부터 정해야 할까?

직답 요약

사내 문서 검색 AI는 부서 자료를 모아 질문에 답하게 만드는 구조이며, 관건은 질문이 반복되는 한 영역을 골라 그 답을 최신으로 유지하는 데 있습니다. 먼저 도입한 곳들도 전사 문서를 넣는 대신 업무 절차나 인사 제도처럼 영역을 좁힌 뒤 갱신 구조를 따로 만들었습니다. 시범 운영에서 확인할 것은 답이 그럴듯한지가 아니라 그 답이 어느 문서에서 나왔는지 화면에서 확인되는지입니다.

같은 질문이 반복해서 들어오는 부서가 있습니다. 규정이 어떻게 되는지, 지난번 그 건은 어떻게 처리했는지, 양식이 어디 있는지 묻는 연락이 매주 옵니다. 답은 이미 문서로 존재하는데 그 문서가 어디 있는지 아는 사람이 정해져 있어서 질문이 그 사람에게 몰립니다.

검색 기능이 없어서 생긴 일은 아닙니다. 그룹웨어에도 검색창이 있고 공유 드라이브에도 있는데 반복 응대는 줄지 않습니다. 검색이 찾아 주는 것과 질문한 사람이 원하는 것이 서로 다르기 때문입니다.

이 글은 부서 자료로 문서 검색 AI를 시범 운영해 보려는 실무 담당자를 기준으로 정리했고, 무엇부터 넣고 무엇을 보고 판단할지까지 다룹니다. 검색 증강 생성(RAG)이 무엇인지부터 알아야 한다면 RAG 개념 편을 먼저 보시기를 추천합니다. 설명은 오픈소스 AI 앱 개발 플랫폼인 Dify를 기준으로 하며, 화면 이름과 제한값은 2026년 8월 기준입니다.

문서를 찾아주는 것과 답을 해주는 건 뭐가 다를까?

검색은 문서가 있는 자리를 알려주는 반면 문서 검색 AI는 그 문서를 읽어 답 문장까지 만들어 줍니다.

그룹웨어 검색창에 "연차 이월"을 넣으면 그 단어가 들어간 문서 목록이 나오는데, 목록을 받은 사람은 문서를 하나씩 열고, 해당 대목을 찾고, 지금 상황에 맞는 조항인지 판단해야 합니다. 질문한 사람이 원했던 것은 "며칠까지 이월되는가"라는 한 문장인데 검색이 준 것은 그 문장을 찾을 재료입니다.

문서 검색 AI는 이 세 동작을 대신합니다. 그 안에서는 세 단계가 순서대로 돌아갑니다. 질문이 들어오면 먼저 넣어 둔 자료에서 가장 관련 있는 내용을 찾고(Retrieval) 찾아온 내용을 원래 질문과 합쳐 언어모델에 넘긴 뒤(Augmented) 그 내용을 근거로 답을 만듭니다(Generation). 이 3단계는 순서가 고정돼 있다는 뜻이므로, 앞에서 엉뚱한 문서를 가져오면 뒤에서 문장을 아무리 잘 만들어도 그 답은 틀린 근거 위에 서 있게 됩니다.

검색은 못 찾으면 빈 화면을 보여줘서 실패가 바로 드러나는 반면 문서 검색 AI는 근거를 덜 찾아온 상태에서도 문장을 만들어 내기 때문에 틀렸다는 사실 자체가 눈에 띄지 않습니다. 그래서 도입을 검토할 때는 답이 얼마나 매끄럽게 나오는지보다 그 답이 어느 문서에서 나왔는지 확인할 수단이 붙어 있는지를 보게 됩니다.

표에서 "잘 맞는 경우" 줄은 두 방식이 서로를 대신하지 못한다는 뜻이기도 합니다. LG CNS는 사내 시스템이 복잡하다는 임직원 조사 결과를 배경으로 사내 지원 체계를 손보면서 기존 키워드 검색과 생성형 AI 챗봇을 함께 제공하고 있습니다. 정확한 문서를 다시 열어야 하는 일과 한 줄만 확인하면 되는 일이 부서 안에 섞여 있기 때문입니다.

부서 문서 중에 뭐부터 넣어야 할까?

먼저 도입한 곳들은 전사 문서를 넣지 않고 질문이 반복되는 한 영역을 골랐습니다.

풀무원은 2024년 12월에 임직원용 AI 챗봇 두리번을 열면서 대상을 근태와 복리후생, 학습, 평가, 승진, 보상 같은 인사 제도로 한정했습니다. LG CNS가 공개한 소개 자료에서 챗봇이 다루는 것으로 나온 범위도 업무 워크플로우입니다. 두 회사가 서로 다른 업종에서 서로 다른 시기에 각자 내린 선택인데 범위를 좁혔다는 점이 같습니다.

저희가 도입 검토를 함께할 때도 문서를 모으는 일보다 어느 질문이 반복되는지 세는 일을 먼저 합니다. 넣을 문서를 정하는 기준이 자료의 중요도가 아니라 질문의 빈도이기 때문입니다. 중요한 문서일수록 열람 권한이 갈리고 예외 조항이 많아 첫 시범 대상으로는 오히려 어렵습니다.

질문이 반복되는 영역을 고른다

최근 한 달 동안 부서로 들어온 문의를 훑어 같은 답을 두 번 이상 한 질문만 남기면 대개 한 영역으로 모입니다. 인사 제도이거나 업무 절차이거나 양식과 그 작성법입니다. 그 영역의 문서만 목록으로 뽑는 것이 첫 작업입니다.

범위는 도구 쪽에서도 정해집니다. Dify에서는 문서를 모아 넣는 묶음을 지식 베이스라고 부르고 그 안에 넣는 파일 하나하나를 지식 문서라고 부릅니다. 그리고 사람들이 실제로 질문을 넣는 화면을 앱이라고 부르는데, 지식 베이스를 만든 다음 그 앱에 연결하는 순서로 진행됩니다. Dify를 클라우드로 쓸 때 무료 요금제는 지식 문서를 50개까지 넣을 수 있습니다. 부서 규정집과 자주 쓰는 양식을 담기에는 넉넉하면서 부서 자료를 전부 밀어 넣기에는 모자란 크기이므로, 첫 범위를 알아서 좁혀 주는 울타리에 가깝습니다.

그 영역 파일이 읽히는 형식인가

고른 문서가 기계에 읽히는 상태인지는 따로 봐야 합니다. JPG나 PNG 같은 이미지 파일은 2MB 미만인 것만 글자가 자동으로 추출되고, PDF 안에 박혀 있는 이미지처럼 다른 파일에 들어앉은 것은 별도의 문서 추출 플러그인을 거쳐야 합니다.

실무에서 걸리는 것은 대개 여러 장을 PDF로 묶어 둔 스캔본과 표가 많은 자료입니다. 스캔본은 글자가 PDF 안의 이미지로 들어앉아 있어 추출 플러그인을 붙이기 전에는 검색 대상이 되지 않고, 표는 글자가 살아 있더라도 조각으로 잘릴 때 행과 열의 관계가 흐트러져 값이 어긋나 나오기도 합니다. 둘 다 첫 시범 범위에서 빼거나 표가 있는 문서를 처리하는 방법을 따로 준비한 뒤에 넣으시기를 권합니다.

문서가 바뀌면 답도 바뀔까?

넣어 둔 문서를 고쳤다고 답이 저절로 따라오지는 않으므로 갱신을 무엇으로 굴릴지 시작할 때 정해야 합니다.

LG CNS 챗봇은 워크플로우가 새로 등록되거나 수정, 삭제되는 사건에 맞춰 자동으로 업데이트되도록 만들어져 있고, 풀무원도 두리번을 두고 답변 생성의 근거가 되는 정보를 업데이트할 수 있다는 점을 내세웠습니다. 두 곳 다 갱신을 사람 기억에 맡기지 않고 구조로 만들어 두었다는 뜻입니다. 원본 시스템과 자동으로 연동되지 않는 환경이라면 그 자리를 담당자로 채워야 하므로, 부서에서 시작할 때는 개정 주기가 있는 자료에 교체할 사람을 적어 두는 것이 자동 연동을 대신합니다.

개정이 잦은 자료를 넣을 때는 옛 버전을 어떻게 처리할지도 실무 결정이 됩니다. Dify는 문서를 지우는 것과 보관하는 것을 다르게 다루는데, 보관은 검색에서만 빼고 읽기 전용으로 남겨 두므로 영구 제거라 복구되지 않는 삭제와 달리 언제든 되살릴 수 있습니다. 개정된 규정의 지난 버전처럼 답변에는 나오면 안 되지만 기록으로는 남겨야 하는 자료가 보관 쪽입니다.

옛 버전을 그대로 두면 옛 규정과 새 규정이 같이 검색돼 답이 흔들립니다. 문서를 넣는 시점에 개정 주기가 있는 자료를 표시해 두고 개정할 때 무엇을 보관으로 돌릴지까지 적어 두시기를 권합니다.

잘 되고 있는지 뭘 보고 알까?

검색 테스트 화면에는 무엇을 집어 왔는지가 그대로 보입니다. 답은 근거가 부실해도 문장이 매끄럽게 나오기 때문에 잘 되고 있는지를 답 화면으로 판단하기는 어렵습니다.

Dify는 넣은 문서를 조각으로 잘라 저장하므로 검색에 걸리는 단위도 문서 전체가 아닌 그 조각입니다. 검색 테스트에서는 실제 사용자가 할 법한 질문을 넣어 어떤 조각이 걸려 나오는지 확인하고 검색 설정을 여러 가지로 바꿔 볼 수 있습니다. 결과에는 찾아온 조각과 관련도 점수, 그 조각이 어느 문서에서 나왔는지가 함께 표시됩니다. 여기서 바꾼 설정은 그 테스트 세션에만 적용되고 저장되지 않으므로, 이 화면은 설정을 확정하는 자리가 아니라 상태를 판정하는 자리라고 보시면 됩니다.

답이 이상하게 나올 때도 이 화면부터 엽니다. 찾아온 조각 자체가 엉뚱하다면 원인은 문서 쪽에 있으므로 해당 문서에 답이 실제로 적혀 있는지, 옛 버전이 같이 걸리지는 않는지, 한 문서에 여러 주제가 섞여 있지는 않은지를 봅니다. 조각은 맞는데 답이 틀렸다면 답을 만드는 단계로 넘어간 문제인데, 여기까지 파고들어 검색 방식과 데이터 구조를 손봐야 하는 단계라면 답변 오류를 데이터 관점에서 다룬 글이 따로 있습니다.

시범 운영의 합격선은 문서를 넣기 전에 정해 두시기를 권합니다. 결과를 먼저 보고 나서 기준을 정하면 나온 결과에 기준을 맞추게 되므로 잘 됐는지 안 됐는지가 사람마다 다르게 읽히기 때문입니다. 반복 질문 20개 정도를 미리 적어 두고 그중 몇 개에 대해 맞는 문서를 집어 오는지 세면 판단이 숫자로 남습니다.

이 목록은 문서를 추가하거나 설정을 바꿨을 때 같은 기준으로 다시 잴 수 있으므로 한 번 쓰고 버리게 되지 않습니다. 시범 결과를 위에 보고할 때도 몇 건 중 몇 건이라는 형태가 되므로 도입 여부를 논의하는 자리에서 그대로 쓸 수 있습니다.

어디까지 믿고 어디서 사람이 확인할까?

출처를 함께 띄우면 확인하는 사람이 표시된 부분만 열어 보고 넘어갑니다.

Dify에는 답변 아래에 근거 문서를 표시하는 기능이 있습니다. 이 기능을 켜면 지식 베이스에서 가져온 답에 번호가 붙은 인용이 달리고, 그 번호를 누르면 답의 근거가 된 원래 문서와 그 안의 조각을 바로 볼 수 있습니다. 답 전체를 처음부터 검증하는 대신 표시된 문장만 열어 보면 되므로 확인에 드는 시간이 줄어듭니다.

풀무원도 두리번을 소개하면서 인사 정보 문서를 기반으로 답을 만들기 때문에 사실과 다른 답을 최소화한다고 밝혔습니다. 최소화한다고 썼지 없앴다고 쓰지는 않았으므로, 문서에 근거를 두는 구조가 틀린 답을 줄이기는 해도 없애지는 못한다는 뜻으로 읽는 편이 안전합니다.

그래서 선은 답의 성격으로 긋는 편이 실용적입니다. 양식 위치나 담당 부서처럼 확인이 쉬운 질문은 답을 그대로 써도 되는 반면, 금액이나 기간, 자격 요건처럼 틀리면 되돌리기 어려운 항목이라면 표시된 출처를 열어 원문을 보고 쓰도록 안내 문구를 답변 화면에 함께 두시기를 권합니다.

이 구분을 도입 전에 정해 두지 않으면 나중에 답 하나하나를 두고 논쟁이 붙는데, 어디까지 믿기로 했는지가 정해져 있지 않으면 틀린 답 한 건이 나올 때마다 도구 전체를 쓸지 말지의 문제로 번지기 때문입니다. 반대로 확인이 필요한 항목이 미리 적혀 있으면 그 한 건은 정해진 절차가 작동한 사례로 처리됩니다.

부서별로 누가 볼 수 있게 할까?

부서별로 나누는 방법은 지식 베이스를 여러 개 만들어 앱마다 골라 연결하는 것이고, 만드는 권한과 보는 권한이 따로 관리되므로 올리기 전에 열람 범위를 확인해야 합니다.

Dify의 작업 공간 구성원은 소유자와 관리자, 편집자, 일반 구성원의 권한이 각각 다릅니다. 지식 베이스를 만들고 고치고 지울 수 있는 것은 편집자까지이고 관리자는 거기에 더해 구성원과 모델 공급자를 관리하며 일반 구성원은 발행된 앱을 쓰기만 합니다. 다만 이미 만들어진 지식 베이스를 누가 보고 쓸 수 있는지는 역할과 별개로 그 지식 베이스 자체 설정에서 따로 정합니다.

만든 앱을 웹으로 열 때 플랫폼 안의 특정 구성원에게만 보이게 하거나 외부 사용자를 SSO로 인증해 들이는 식으로 접근 범위를 나누는 기능은 Dify Enterprise에서 제공됩니다. 그래서 인사나 재무 자료처럼 부서 밖으로 나가면 안 되는 문서가 섞여 있다면 시범 단계에서는 자료를 나눠 담는 쪽이 안전하며, Dify는 용도와 데이터 출처별로 지식 베이스를 여러 개 만들어 앱마다 골라 연결하도록 되어 있습니다.

우리 회사 환경에서 돌아갈까?

클라우드로 쓸지 사내에 설치할지가 갈림길이고 이 결정은 보안팀과 함께 해야 합니다.

Dify는 회사 서버에 직접 설치해 쓸 수 있고 오픈소스로 공개된 커뮤니티 버전은 무료이며 작업 공간 하나를 씁니다. 도커 컴포즈로 배포하는 방식이라 IT팀이 서버에 올려 줘야 하고 부서 단독으로는 진행하기 어렵습니다. 앞서 나온 지식 문서 50개 한도는 클라우드 무료 요금제에 붙는 조건이므로, 직접 설치하는 경우에는 그 숫자 대신 서버 사양이 넣을 수 있는 양을 정합니다.

사내에 설치해도 데이터가 회사 밖으로 나갈 수 있습니다. 앞서 본 3단계대로 질문과 찾아온 문서 조각은 답을 만들 때 언어모델로 넘어가므로, 그 모델을 외부 API로 부르는 구성이라면 그 내용은 사내 서버 밖으로 나갑니다. 망분리 환경이거나 자료가 밖으로 나가면 안 되는 조건이라면 모델까지 사내에 두어야 하며, 이 선택은 비용과 성능이 함께 걸리는 문제라 온프레미스 AI 편에 따로 정리해 두었습니다.

시범 단계에서 IT팀과 보안팀에 물어볼 항목은 세 가지입니다.

• 사내 설치와 클라우드 중 어느 쪽이 허용되는지

• 답을 만드는 모델을 외부 API로 부를 수 있는지

• 계정을 사내 인증과 연동해야 하는지

세 가지가 정해지면 나머지 구성은 그 위에서 결정됩니다.

자주 묻는 질문

문서를 넣기만 하면 바로 답하나요?

문서를 올리면 검색할 수 있는 형태로 처리하는 과정을 거친 뒤 앱에 연결해야 답이 나옵니다. 처리 자체는 화면에서 진행되지만 어떤 질문에 답하게 할지, 답을 못 찾을 때 어떻게 반응하게 할지는 앱 쪽에서 따로 정합니다.

문서가 몇 개는 있어야 쓸 만한가요?

개수보다 질문의 반복도가 기준입니다. 같은 답을 반복하는 질문 20개 정도를 커버하는 문서 묶음이면 시범 운영에 충분하며, Dify를 클라우드로 쓸 때의 무료 지식 문서 50개 한도가 그 범위와 대체로 맞습니다.

답이 틀리면 누구 책임인가요?

답을 그대로 쓰기로 한 범위를 정해 둔 조직에서는 그 범위를 정한 쪽이, 정해 두지 않은 조직에서는 답을 가져다 쓴 사람이 지게 됩니다. 그래서 금액과 기간처럼 되돌리기 어려운 항목은 출처를 확인하고 쓰도록 도입 시점에 정해 두는 편이 낫습니다.

그룹웨어 검색을 없애야 하나요?

아닙니다. LG CNS처럼 키워드 검색과 AI 챗봇을 함께 두는 구성도 실제로 쓰입니다. 정확한 문서를 다시 열어야 하는 일에는 검색이 낫습니다.

부서마다 따로 만들어야 하나요?

Dify는 용도별로 지식 베이스를 나눠 만들고 앱마다 필요한 것만 연결하도록 되어 있어서 자료를 나눠 담을 수 있습니다. 다만 만든 앱을 웹으로 열 때 누가 들어올 수 있는지를 단계별로 제어하려면 Enterprise 기능이 필요하므로 시범 단계에서는 한 부서로 좁히는 편이 간단합니다.

뭐부터 하면 될까?

쓸 만한지 판단하는 데까지의 순서입니다. 실제로 부서에 열어 주는 것은 이 판단이 끝난 뒤의 일입니다.

1. 최근 한 달 문의를 훑어 같은 답을 두 번 이상 한 질문을 적습니다. 20개 정도면 충분하며 이 목록이 나중에 합격선을 재는 기준이 됩니다.

2. 그 질문들이 걸린 문서만 목록으로 뽑습니다. 부서 전체 자료가 아니라 그 영역입니다.

3. 목록에서 스캔 문서와 표 위주 자료를 표시합니다. 처리를 따로 준비해야 하므로 첫 시범에서는 빼는 편이 낫습니다.

4. IT팀과 보안팀에 설치 방식과 모델 호출, 계정 연동 세 가지를 먼저 확인합니다. 문서를 어디에 올리게 되는지가 여기서 정해지므로 5번보다 앞에 두어야 합니다.

5. 개정 주기가 있는 자료에 갱신 담당을 적습니다. 개정본이 나오면 새로 올리고 지난 버전은 지우지 말고 보관으로 돌리는 것이 그 사람이 할 일입니다.

6. 어느 항목까지 답을 그대로 쓸지 선을 긋습니다. 금액과 기간, 자격 요건은 출처를 열어 보고 쓰도록 정해 둡니다.

7. 자료를 올린 뒤 검색 테스트에 1번 목록을 하나씩 걸어 봅니다. 맞는 문서가 검색되는 비율을 세면 시범 결과가 숫자로 남습니다.

저희는 이 목록에서 1번과 5번을 가장 무겁게 봅니다. 문서를 모으는 일부터 시작하면 범위가 계속 넓어지고, 갱신 담당을 안 정하면 몇 달 뒤에 옛 규정이 답에 딸려 나옵니다. 반대로 이 둘만 잡아 두면 나머지는 화면에서 확인하며 조정할 수 있으므로 첫 시범은 생각보다 무겁지 않습니다.

도입 판단 전체를 놓고 보고 싶다면 Dify 도입 판단 편에 기능과 라이선스, 비용 항목을 정리해 두었습니다.

출처

출처

• Dify 공식 문서, Knowledge 개요 및 RAG 3단계 설명 https://docs.dify.ai/en/cloud/use-dify/knowledge/readme

• Dify 공식 문서, 문서 업로드 제한과 이미지 추출 https://docs.dify.ai/en/cloud/use-dify/knowledge/create-knowledge/import-text-data

• Dify 공식 문서, 검색 테스트와 근거 표시 https://docs.dify.ai/en/guides/knowledge-base/retrieval-test-and-citation

• Dify 공식 문서, 검색 테스트 설정의 적용 범위 https://docs.dify.ai/en/use-dify/knowledge/test-retrieval

• Dify 공식 문서, 문서 관리(보관과 삭제) https://docs.dify.ai/en/guides/knowledge-base/knowledge-and-documents-maintenance/maintain-knowledge-documents

• Dify 공식 문서, 작업 공간 구성원 역할 https://docs.dify.ai/en/use-dify/workspace/team-members-management

• Dify 공식 문서, 웹 앱 접근 제어 https://docs.dify.ai/en/use-dify/publish/webapp/web-app-access

• Dify 공식 문서, 답변 근거 표시 기능 https://docs.dify.ai/en/guides/workflow/additional-features

• Dify 공식 문서, 도커 컴포즈 설치 https://docs.dify.ai/en/getting-started/install-self-hosted/readme

• Dify 요금제 (2026년 8월 확인) https://dify.ai/pricing

• LG CNS, 디지털AX 사내 지원 체계 소개 https://connect.lgcns.com/language-masters/ko/service/biz-process-intelligence/digital-ax

• 풀무원 뉴스룸, 인사 AI 챗봇 두리번 오픈 (2024-12-23) https://news.pulmuone.co.kr/pulmuone/newsroom/viewNewsroom.do?id=3431