WeKnora: 문서를 RAG·에이전트·Wiki로 연결할 때 어디까지 맡길까

문서가 여러 폴더와 협업 도구에 흩어져 있고 검색 결과를 다시 정리해야 한다면, 단순한 채팅 기능보다 지식베이스의 구조와 권한을 먼저 정해야 합니다. WeKnora는 문서를 검색 가능한 RAG(검색으로 근거를 찾아 답하는 방식)로 묶고, 에이전트와 Wiki로 확장하려는 오픈소스 프로젝트입니다.

이 Pick의 핵심은 “자동으로 지식을 만들어 준다”는 약속이 아닙니다. 어떤 문서를 어디까지 넣고, 에이전트가 어떤 도구를 쓰며, 사람이 어떤 결과를 확인할지 정하는 데 있습니다.

어떤 문서 업무에서 검토할 만한가요?

WeKnora는 PDF·Word·이미지·Excel·XMind 같은 자료를 지식베이스로 가져오고, 여러 자료를 검색해 질문에 답하는 흐름을 공식 README에서 설명합니다. Feishu, GitLab, Tencent IMA, Notion, Yuque 같은 외부 자료원과의 동기화 경로도 안내합니다.

다음과 같은 상황에서 비교 대상이 될 수 있습니다.

규정·매뉴얼·회의 자료가 여러 형식과 저장소에 나뉘어 있습니다.
답변뿐 아니라 어떤 문서에서 나온 내용인지 함께 확인해야 합니다.
문서를 한 번 검색하는 데서 끝내지 않고 질문·검토·정리 작업을 이어가야 합니다.
자체 환경에 설치하고 사용자·공간·지식베이스별 권한을 나누고 싶습니다.

문서가 소수이고 정해진 문장만 추출하면 된다면 이 정도의 시스템은 관리 항목을 늘릴 수 있습니다. 먼저 필요한 입력 형식과 답변에 필요한 근거 수준을 정하는 편이 좋습니다.

검색, 에이전트, Wiki를 서로 다른 기능으로 봅니다

빠른 질문에는 RAG 검색을 씁니다

공식 README는 지식베이스 안의 문서를 검색해 답변하고 출처를 보여 주는 빠른 질의응답을 기능 범위로 설명합니다. 이 단계에서는 문서가 제대로 들어갔는지, 표와 제목이 어떻게 쪼개졌는지, 인용이 원문을 가리키는지부터 확인해야 합니다.

여러 단계의 일에는 에이전트를 붙입니다

WeKnora는 ReAct 에이전트가 지식 검색, MCP 도구, 스킬 샌드박스와 웹 검색을 조합하는 구조를 안내합니다. 에이전트가 자료를 읽는 권한과 파일을 만들거나 외부 시스템을 바꾸는 권한은 같은 범위로 두지 않는 편이 안전합니다.

정리된 지식에는 Wiki 모드를 씁니다

공식 문서는 Wiki 모드가 원문에서 서로 연결된 Markdown 페이지와 지식 그래프를 만드는 흐름을 설명합니다. 생성된 페이지는 브라우저에서 수정하고, 버전 차이와 되돌리기 이력을 확인할 수 있습니다.

이 기능은 초안 정리를 빠르게 하는 방법입니다. Wiki 페이지가 원문을 정확히 대표하는지, 최신 문서가 반영됐는지, 사람이 수정한 내용이 다음 검색에 어떻게 영향을 주는지는 별도로 검수해야 합니다.

도입 전에 데이터와 권한 경계를 정하세요

WeKnora 공식 README는 로컬·프라이빗 클라우드 배포, 다중 워크스페이스, 역할 기반 권한, 지식베이스별 접근 제한과 감사 로그를 기능 범위로 제시합니다. API 키를 범위별로 제한하고 MCP 서버를 별도 연결하는 경로도 안내합니다.

실제 도입에서는 다음 질문을 먼저 문서로 남기는 편이 좋습니다.

어떤 문서를 지식베이스에 넣어도 되며, 원문과 변환 결과는 어디에 보관하나요?
검색·요약·Wiki 생성·외부 발송 중 사람 확인이 필요한 단계는 어디인가요?
에이전트가 읽을 수 있는 폴더와 호출할 수 있는 MCP 도구는 무엇인가요?
사용자·워크스페이스·지식베이스별로 누가 읽고 수정하고 삭제할 수 있나요?
문서가 갱신되었을 때 재색인과 Wiki 수정 이력을 어떻게 확인하나요?

공식 원문에서 확인한 현재 범위

GitHub API에서 2026년 9월 12일 확인한 Tencent/WeKnora는 별 22,286개, 주 언어 Go로 표시됐고 9월 11일에 최신 push가 기록되어 있었습니다. 저장소의 README는 Vue 3 프런트엔드와 Python 문서 처리 서비스가 함께 동작하는 구조도 설명합니다.

최신 정식 릴리스는 2026년 9월 3일 공개된 v0.8.0입니다. 해당 릴리스 설명에는 스킬 샌드박스, 워크스페이스별 스킬 카탈로그, 장기 메모리, Office 문서 파서, GitLab·Tencent IMA 자료원, LiteLLM과 XMind 파서가 포함되어 있습니다.

이 정보는 저장소와 공급자가 공개한 기능 범위입니다. 별 수와 릴리스 기록은 관심도와 공개 활동을 보여 줄 뿐, 문서 정확도·보안 인증·조직 적합성을 보증하지 않습니다.

한계와 주의사항은 무엇인가요?

PDF·Word·표·이미지의 처리 결과는 문서마다 달라질 수 있습니다. 실제 대표 문서로 제목·표·페이지·인용 위치를 대조해야 합니다.
Wiki 자동 생성은 원문을 사람이 다시 읽는 절차를 없애지 않습니다. 잘못된 링크나 오래된 페이지가 지식베이스에 남을 수 있습니다.
로컬 또는 프라이빗 클라우드 배포도 모델·검색·외부 자료원으로 데이터가 이동할 수 있습니다. 공급자별 처리 조건과 로그 보관 위치를 따로 확인해야 합니다.
기능이 여러 서비스와 저장소로 나뉘어 있어 설치·업데이트·권한 운영 비용이 작지 않을 수 있습니다.
HWP·HWPX가 핵심 입력이라면 공식 문서의 지원 형식과 변환 결과를 먼저 시험하고, 한글 문서의 서식·표·양식 검수 절차를 별도로 두어야 합니다.
이 저장소에서 실제 설치·성능·비용 비교를 실행한 것은 아닙니다.

처음에는 어떻게 시험할까요?

비식별 문서 세 개로 시작하세요. 본문 중심 문서, 표가 있는 문서, 이미지나 스캔이 포함된 문서를 각각 넣고 원문·검색 결과·인용 위치를 비교하면 파서와 검색의 문제를 나눠 볼 수 있습니다.

그 다음에는 Wiki 생성과 수정 이력을 작은 범위에서 확인하세요. 마지막으로 MCP·에이전트 연결을 읽기 전용으로 붙이고, 파일 생성·외부 API 호출·문서 삭제처럼 되돌리기 어려운 작업은 별도 승인 단계로 남기는 순서가 적합합니다.

문서 업무에 AI를 적용할 때 필요한 입력·검수·권한 기준은 기업 AI 업무자동화 실무교육과 HWP·HWPX 공공문서 AI 실무교육에서 이어서 확인할 수 있습니다.