사내 문서 검색 AI, 우리 부서 자료로 운영하려면 무엇이 필요할까?

직답 요약

사내 문서 검색 AI는 부서 자료를 모아 질문에 답하게 만드는 시스템이며, 관건은 질문이 반복되는 영역으로 범위를 좁히고 그 답을 최신으로 유지하는 데 있습니다.

사내 문의에 응대하다가 시간을 다 써버리는 날이 있습니다. 규정이 어떻게 되는지, 이전에는 어떻게 처리했는지, 필요한 양식은 어디에 있는지 묻는 연락이 계속 들어옵니다. 답은 이미 문서로 정리돼 있는데도 같은 질문이 반복됩니다.

문서가 없어서가 아닙니다. 어떤 문서를 봐야 하는지, 어디에서 찾아야 하는지를 아는 사람이 따로 있기 때문입니다. 결국 비슷한 질문이 몇몇 사람에게 반복해서 돌아갑니다.

그렇다면 문서를 검색하기 쉽게 만들면 해결될 것 같지만, 이미 그룹웨어에도 검색창이 있고 공유 드라이브에서도 파일을 찾을 수 있습니다. 그런데도 반복 문의가 사라지지 않는 이유는 검색이 찾아 주는 것과 질문한 사람이 원하는 것이 다르기 때문입니다.

검색창에 질문과 관련된 단어를 넣으면 그 단어가 포함된 문서 목록은 찾을 수 있습니다. 하지만 목록 가운데 어떤 문서를 열어야 하는지, 그 안에서 어느 부분을 봐야 하는지까지는 다시 사람이 찾아야 합니다.

이 글은 부서 자료로 문서 검색 AI를 시범 운영하려는 실무 담당자를 기준으로 정리했습니다. 어떤 질문부터 대상으로 삼을지, 어떤 문서를 넣을지, 그리고 시범 결과를 무엇으로 판단할지까지 순서대로 살펴봅니다. 검색 증강 생성(RAG)이 무엇인지 아직 익숙하지 않다면 RAG 개념 편을 먼저 참고하셔도 좋습니다. 설명은 오픈소스 AI 앱 개발 플랫폼인 Dify를 기준으로 진행합니다.

단순 문서 검색과 문서 검색 AI의 차이는?

문서 검색은 관련 문서의 목록과 위치를 찾아주고, 문서 검색 AI는 그 안에서 질문에 필요한 내용을 찾아 답으로 정리합니다.

예를 들어 그룹웨어 검색창에 "연차 이월"을 입력하면 해당 단어가 들어간 문서 목록이 나옵니다. 그다음에는 사람이 문서를 하나씩 열어 관련 조항을 찾고, 현재 상황에도 적용되는 내용인지 판단해야 합니다.

질문한 사람이 알고 싶은 것은 보통 "연차를 며칠까지 이월할 수 있나요?" 같은 답 한 줄입니다. 기존 검색은 그 답이 들어 있을 가능성이 높은 문서를 찾아주는 데서 역할이 끝납니다.

문서 검색 AI는 그다음 과정까지 이어갑니다. 질문이 들어오면 먼저 등록된 자료에서 관련 내용을 찾고(Retrieval), 찾아온 내용과 질문을 함께 언어모델에 전달한 뒤(Augmented), 그 자료를 근거로 답을 만듭니다(Generation).

여기서 가장 먼저 확인해야 하는 것은 답을 얼마나 자연스럽게 쓰느냐가 아니라, 질문에 맞는 내용을 제대로 찾아왔느냐입니다. 처음부터 엉뚱한 문서나 조각을 가져오면 뒤에서 문장을 아무리 매끄럽게 만들어도 답의 근거 자체가 잘못돼 있기 때문입니다.

실제 업무 현장에서는 두 방식을 함께 사용하는 경우가 빈번합니다. LG CNS는 사내 시스템이 복잡하다는 임직원 조사 결과를 배경으로 사내 지원 체계를 개편하면서 기존 키워드 검색과 생성형 AI 챗봇을 함께 제공하고 있습니다. 문서 전체가 필요한 상황과 질문에 대한 답 한 줄만 확인하면 되는 상황이 부서 안에 섞여 있기 때문입니다. 검색은 못 찾으면 빈 화면을 보여줘서 실패가 바로 드러나는 반면 문서 검색 AI는 근거를 덜 찾아온 상태에서도 문장을 만들어 내기 때문에 틀렸다는 사실 자체가 눈에 띄지 않습니다.

우리 부서 문서 중 어떤 것부터 넣는 게 좋을까?

먼저 도입한 사례들에서는 전사 문서를 처음부터 다 넣지 않고 질문이 반복되는 한 영역에 집중했습니다.

풀무원은 2024년 12월에 임직원용 AI 챗봇 두리번을 공개하면서 운영 범위를 근태와 복리후생, 학습, 평가, 승진, 보상 같은 인사 제도로 한정했습니다. LG CNS 챗봇이 답하는 범위도 사내에 등록된 업무 워크플로우로 묶여 있습니다. 소개 문구에는 답변 대상이 등록된 워크플로로 적혀 있습니다. 등록을 마친 절차인지가 범위를 가르는 선으로 읽힙니다.

두 회사는 모두 챗봇을 도입할 때 특정 영역에서만 활용되도록 범위를 좁혔습니다. 그렇다면 그 영역은 무엇을 기준으로 골랐을까요?

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

두 사례가 고른 영역을 겹쳐 보면 자료의 중요도로 범위를 정한 쪽은 없습니다. 풀무원은 구성원이 자주 묻는 인사 제도로, LG CNS는 시스템에 등록을 마친 절차로 각각 선을 그었습니다. 부서에서 실행할 수 있는 선은 반복해서 들어오는 질문입니다.

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

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

고른 문서가 AI가 읽을 수 있는 상태인지는 따로 체크해야 합니다. JPG나 PNG 같은 이미지 파일은 2MB 미만인 것만 텍스트가 자동으로 추출되고, PDF에 포함된 이미지처럼 다른 파일 안에 들어 있는 것은 별도의 문서 추출 플러그인을 거쳐야 합니다.

실무에서 걸리는 것은 대개 스캔본과 표가 많은 자료입니다. 스캔본은 텍스트가 이미지로 저장돼 있어 추출 플러그인을 붙이기 전에는 검색 대상이 되지 않습니다. 표는 구조가 살아 있어야 값이 제대로 읽히는데, 기본 처리만 거치면 행과 열의 관계가 흐트러져 값이 어긋나 나오기도 합니다. 둘 다 첫 시범 범위에서 빼거나 표가 있는 문서를 처리하는 방법을 따로 준비한 뒤에 넣으시기를 권합니다.

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

연동해서 가져온 문서는 원본이 바뀔 때 동기화로 최신 상태를 유지할 수 있고, 파일로 올린 문서는 갱신을 누가 할지 정해 두어야 합니다.

LG CNS 챗봇은 워크플로우가 새로 등록되거나 수정, 삭제되는 시점에 맞춰 자동으로 정보가 갱신되도록 구성돼 있습니다. 풀무원 역시 두리번을 소개하며 답변 생성의 근거가 되는 정보를 지속적으로 업데이트할 수 있다는 점을 강조했습니다. 두 사례 모두 정보 갱신을 담당자의 기억에 의존하지 않고 운영 체계를 통해 관리하고 있습니다.

원본이 Notion처럼 연동할 수 있는 소스에 있다면 문서가 바뀔 때 지식 베이스(Dify에서 문서를 모아 두는 묶음)에도 반영할 수 있게 연동해 두는 편이 낫습니다. 연동할 수 없는 소스라면 그 역할을 사람이 맡아야 합니다. 따라서 부서에서 시작할 때부터 개정 주기가 있는 자료에는 갱신 담당자를 정해 두는 것이 좋습니다.

Dify는 Notion 문서를 가져와 동기화를 설정할 수 있고, 원본이 바뀌면 문서 목록에서 해당 문서의 동기화 버튼을 눌러 반영합니다. 이때 임베딩이 다시 수행되기 때문에 임베딩 모델의 토큰을 사용합니다. 반면 파일로 직접 올린 문서에는 그 버튼이 없으므로, 개정본이 나오면 사람이 새로 올려야 합니다. 부서 자료가 대부분 파일로 오고 간다면 갱신 담당자가 자동 연동을 대신하는 셈입니다.

개정이 잦은 자료라면 지난 버전을 어떻게 처리할지도 미리 정해야 합니다. Dify는 문서를 삭제하는 것과 보관하는 것을 다르게 처리합니다. 보관된 문서는 검색 대상에서는 제외되지만 읽기 전용 상태로 남아 있어 다시 활성화할 수 있습니다. 반면 삭제한 문서는 영구 제거되므로 복구할 수 없습니다. 따라서 개정된 규정의 이전 버전처럼 현재 답변에는 사용되면 안 되지만, 기록으로는 남겨야 하는 자료라면 삭제보다 보관이 적합합니다.

옛 버전을 그대로 검색 대상으로 남겨 두면 이전 규정과 최신 규정이 동시에 검색돼 답변 정확도가 떨어질 수 있습니다. 문서를 처음 등록할 때부터 개정 주기가 있는 자료인지 표시하고, 새 버전이 들어올 때 어떤 문서를 보관으로 전환할지도 함께 정해 두는 편이 안전합니다.

잘 되고 있는지는 무엇을 보고 판단할까?

검색 테스트에서는 AI가 실제로 어떤 문서 조각을 가져오는지 확인할 수 있습니다.

답변은 근거가 충분하지 않아도 문장 자체는 자연스럽게 만들어질 수 있습니다. 따라서 시범 운영이 잘 되고 있는지를 최종 답변 화면만 보고 판단하기는 어렵습니다.

Dify는 등록한 문서를 여러 조각으로 나눠 저장하고, 사용자의 질문이 들어오면 관련성이 높은 조각을 찾아옵니다. 검색 테스트에서는 실제 사용자가 물어볼 법한 질문을 넣어 어떤 조각이 검색되는지 확인할 수 있고, 검색 설정을 바꿔가며 결과를 비교할 수도 있습니다. 결과 화면에는 검색된 문서 조각과 관련도 점수, 출처 문서가 함께 표시됩니다. 검색 설정 변경은 해당 테스트 세션에만 적용되므로, 이 화면은 설정을 확정하는 곳이 아니라 검색 결과를 점검하는 데 사용됩니다.

답변이 이상할 때도 먼저 이 화면을 확인합니다.

검색된 조각 자체가 엉뚱하다면 검색이나 문서 구성부터 살펴봐야 합니다. 해당 문서에 질문의 답이 실제로 들어 있는지, 이전 버전의 문서가 함께 검색되고 있지는 않은지, 하나의 문서 안에 서로 다른 주제가 지나치게 많이 섞여 있지는 않은지 확인합니다. 반대로 검색된 조각은 맞는데 최종 답변이 틀린다면 검색 이후 답변을 생성하는 단계의 문제일 가능성이 있습니다. 검색 방식과 데이터 구조까지 손봐야 하는 상황은 답변 오류를 데이터 관점에서 다룬 글에서 별도로 다루고 있습니다.

시범 운영의 합격 기준은 문서를 넣기 전에 정해 두는 것을 권장합니다. 결과를 먼저 본 뒤 기준을 정하면 나온 결과에 맞춰 기준이 달라질 수 있고, 같은 결과를 두고도 사람마다 성공 여부를 다르게 판단할 수 있기 때문입니다. 가장 단순한 방법은 반복적으로 들어오는 질문 20개 정도를 미리 정해 두고, 그중 몇 개에서 올바른 문서가 검색되는지를 세는 것입니다.

이 질문 목록은 문서를 추가하거나 검색 설정을 변경한 뒤에도 같은 기준으로 다시 사용할 수 있습니다. 시범 결과를 보고할 때도 20개 질문 중 17개에서 올바른 문서가 검색됐다는 형태로 숫자로 제시할 수 있어, 도입 여부를 논의할 때 훨씬 명확한 기준이 됩니다.

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

답변에 출처를 함께 표시하면 확인이 필요한 부분만 원문으로 돌아가 검증할 수 있습니다.

Dify에는 답변 아래에 근거 문서를 표시하는 기능이 있습니다. 이 기능을 켜면 지식 베이스에서 가져온 내용을 바탕으로 만든 답변에 인용 번호가 붙고, 해당 번호를 선택하면 근거가 된 원문과 문서 조각을 바로 확인할 수 있습니다.

답변 전체를 처음부터 다시 검증하는 대신, 중요한 내용이 나온 부분만 원문과 비교할 수 있으므로 확인에 드는 시간을 줄일 수 있습니다.

풀무원도 두리번을 소개하면서 인사 정보 문서를 바탕으로 답변을 생성해 사실과 다른 답변을 최소화한다고 설명했습니다. 여기서 중요한 표현은 "없앤다"가 아니라 "최소화한다"는 점입니다. 문서에 근거해 답하게 만드는 구조는 잘못된 답변의 가능성을 낮출 수 있지만, 완전히 없애는 것은 아닙니다.

따라서 어디까지 AI 답변을 그대로 사용하고, 어디부터 사람이 원문을 확인할 것인지는 답변의 성격에 따라 고민하는 것이 좋습니다. 양식의 위치나 담당 부서처럼 잘못 안내되더라도 바로 확인하고 수정할 수 있는 정보는 답변을 그대로 활용할 수 있습니다. 반면 금액, 기간, 자격 요건, 규정 적용 여부처럼 틀렸을 때 영향이 큰 정보는 답변에 표시된 출처를 열어 원문까지 확인하도록 안내하는 편이 안전합니다.

이 기준을 도입 전에 정해 두지 않으면 잘못된 답변 한 건이 나올 때마다 문서 검색 AI를 계속 써도 되는가라는 논쟁으로 번질 수 있습니다. 반대로 사람이 확인해야 하는 항목을 미리 정해 두면, 오류가 발생해도 정해진 검증 절차 안에서 처리할 수 있습니다.

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

부서별 자료를 나누려면 지식 베이스를 분리하고, 문서를 올리기 전에 열람 범위와 관리 권한을 함께 확인해야 합니다.

Dify는 앱을 사용하는 사람과 지식 베이스를 관리하는 사람의 권한을 나눠 둡니다. 일반 구성원은 주로 발행된 앱을 사용하고, 편집자는 지식 베이스를 만들고 수정할 수 있습니다. 관리자는 여기에 구성원 관리와 모델 설정까지 담당합니다. 다만 지식 베이스를 누가 열람하고 사용할 수 있는지는 작업 공간 역할만으로 결정되지 않습니다. 이미 만들어진 지식 베이스의 접근 범위는 해당 지식 베이스의 설정에서도 별도로 관리합니다.

발행된 앱의 접근 범위를 플랫폼 내 특정 구성원으로 제한하거나, 외부 사용자를 SSO로 인증해 접속시키는 기능은 Dify Enterprise에서 제공합니다. 따라서 인사나 재무 자료처럼 부서 밖으로 노출돼서는 안 되는 문서가 있다면 첫 시범부터 모든 자료를 하나의 지식 베이스에 섞기보다 용도와 데이터 출처에 따라 분리해서 운영하는 편이 안전합니다. Dify에서는 여러 지식 베이스를 만든 뒤 필요한 것만 앱에 선택해 연결할 수 있습니다.

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

가장 먼저 정해야 할 것은 클라우드로 사용할지, 회사 내부 서버에 설치할지입니다. 이 결정은 IT팀과 보안팀이 함께 검토해야 합니다.

Dify는 회사 서버에 직접 설치해 운영할 수 있으며, 오픈소스로 공개된 Community Edition은 무료로 사용할 수 있습니다. 일반적으로 Docker Compose를 이용해 배포하므로 실제 사내 구축에는 서버와 운영 환경을 담당하는 IT 조직의 협조가 필요합니다. 문서 수와 저장 용량 한도는 클라우드 요금제에 붙는 조건입니다. 직접 설치를 검토한다면 어느 정도 규모를 다룰 수 있는지는 서버 환경과 함께 IT 조직과 확인하는 편이 좋습니다.

다만 사내 서버에 Dify를 설치했다고 해서 모든 데이터가 자동으로 회사 안에만 머무르는 것은 아닙니다. 사용자의 질문과 검색된 문서 조각은 최종 답변을 만들기 위해 언어모델로 전달됩니다. 이때 OpenAI나 다른 외부 모델 API를 사용하는 구조라면 해당 정보가 회사 외부의 모델 제공자에게 전달될 수 있습니다. 망분리 환경이거나 자료가 외부로 나가서는 안 되는 조직이라면 Dify뿐 아니라 답변을 만드는 모델까지 사내 환경에서 운영할 수 있는지 검토해야 합니다. 이 경우 비용과 성능, 운영 난이도까지 함께 고려해야 하며 자세한 내용은 온프레미스 AI 편에 따로 정리했습니다.

따라서 시범 운영 전에 IT팀과 보안팀에 확인할 항목은 크게 세 가지입니다.

• 사내 설치와 클라우드 중 어떤 방식이 허용되는지

• 답변을 생성하는 모델을 외부 API로 호출해도 되는지

• 사용자 계정을 사내 인증 체계와 연동해야 하는지

이 세 가지가 정해지면 문서를 어디에 두고 어떤 모델을 연결하며 누가 접속하게 할지에 대한 나머지 구성을 결정할 수 있습니다.

뭐부터 하면 될까?

여기까지 왔다면 바로 전사 도입을 준비할 필요는 없습니다. 먼저 우리 부서에서 실제로 쓸 만한지를 확인하는 작은 시범 운영부터 진행하면 됩니다.

1. 최근 한 달 동안 들어온 문의를 훑어 같은 답을 두 번 이상 했던 질문을 적습니다. 20개 정도면 충분합니다. 이 목록이 이후 시범 운영의 테스트 질문이자 합격 기준이 됩니다.

2. 그 질문에 답하려면 필요한 문서만 목록으로 만듭니다. 부서 전체 자료를 모으는 것이 아니라 반복 질문에 필요한 영역만 먼저 대상으로 삼습니다.

3. 목록 가운데 스캔 문서와 표가 많은 자료를 표시합니다. 일반 텍스트 문서보다 별도 처리가 필요한 경우가 많으므로 첫 시범에서는 제외하거나 처리 방법을 먼저 확인하는 편이 좋습니다.

4. IT팀과 보안팀에 설치 방식, 모델 호출, 계정 연동 세 가지를 확인합니다. 문서가 어디에 저장되고 어떤 정보가 외부로 나갈 수 있는지가 여기서 결정되므로 실제 자료를 올리기 전에 확인해야 합니다.

5. 개정 주기가 있는 자료에는 갱신 담당자를 정합니다. 연동할 수 있는 소스에 있는 자료라면 원본이 바뀔 때 지식 베이스에서 동기화를 눌러 반영하도록 절차를 정합니다. 연동이 안 되는 자료는 담당자가 개정본을 등록하고 이전 버전을 보관 처리하도록 운영 규칙을 정합니다.

6. 어떤 정보까지 AI 답변을 그대로 사용하고, 어떤 정보는 원문을 확인할지 정합니다. 특히 금액, 기간, 자격 요건처럼 오류의 영향이 큰 정보는 출처를 열어 확인하도록 기준을 정해 두는 것이 좋습니다.

7. 자료를 등록한 뒤 검색 테스트에서 1번에 적어 둔 질문을 하나씩 확인합니다. 20개 질문 중 몇 개에서 올바른 문서가 검색되는지를 기록하면 시범 운영 결과가 숫자로 남습니다.

이 과정에서 특히 중요한 것은 첫 번째 질문 목록과 다섯 번째 갱신 담당입니다.

처음부터 부서의 모든 문서를 모으기 시작하면 시범 범위가 빠르게 커집니다. 반대로 실제 반복 질문부터 정하면 필요한 문서의 범위가 자연스럽게 좁아집니다.

또 갱신 방식을 정하지 않은 채 운영을 시작하면 처음에는 잘 작동하던 시스템도 몇 달 뒤에는 지난 규정이나 오래된 자료를 답변에 섞어 내놓을 수 있습니다. 처음부터 무엇을 답하게 할 것인지와 누가 최신 상태를 유지할 것인지만 정해 두어도 첫 시범의 부담은 크게 줄어듭니다.

자주 묻는 질문

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

문서를 올리면 먼저 검색할 수 있는 형태로 처리하는 과정을 거칩니다. 이후 해당 지식 베이스를 실제 사용자가 질문하는 앱과 연결해야 답변에 활용할 수 있습니다. 어떤 질문에 답하게 할지, 필요한 근거를 찾지 못했을 때 어떻게 응답할지는 앱에서 별도로 설정합니다.

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

문서 개수 자체보다 반복적으로 들어오는 질문에 필요한 내용이 들어 있느냐가 중요합니다. 첫 시범이라면 부서 전체 문서를 넣기보다 반복 질문 20개 정도에 답할 수 있는 자료부터 시작하는 편이 결과를 판단하기 쉽습니다.

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

AI 답변을 최종 판단으로 사용할지, 참고 정보로 사용할지는 조직이 먼저 정해야 합니다. 특히 금액, 기간, 자격 요건처럼 업무에 미치는 영향이 큰 정보는 출처 문서를 확인한 뒤 사용하도록 절차를 두는 것이 안전합니다. 동시에 잘못된 답변이 나왔다면 어떤 문서를 근거로 검색했는지 확인하고 문서와 검색 구조를 개선할 담당자도 정해 두는 것이 좋습니다.

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

그럴 필요는 없습니다. 문서 전체를 직접 열어야 할 때는 기존 검색이 더 적합하고, 여러 문서에서 질문에 해당하는 내용만 빠르게 찾아야 할 때는 문서 검색 AI가 유리합니다. 실제 업무에서는 두 방식을 대체 관계로 보기보다 용도에 따라 함께 사용하는 편이 자연스럽습니다.

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

반드시 그래야 하는 것은 아니지만, 열람 권한이나 관리 주기가 다른 자료라면 분리하는 편이 관리하기 쉽습니다. 특히 인사·재무처럼 접근 권한이 제한된 자료와 전사 공통 자료는 같은 지식 베이스에 섞기보다 별도로 관리하는 것이 안전합니다.

출처

출처

• 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 공식 문서, Notion 데이터 동기화 https://docs.dify.ai/en/cloud/use-dify/knowledge/create-knowledge/import-text-data/sync-from-notion

• 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