Claude 기반 사내 지식검색 시스템 구축 아키텍처

기업에서 문서와 데이터가 늘어나면서 “필요한 정보를 어디에서 찾아야 하는가”가 중요한 업무 문제가 되고 있습니다. 사내 규정, 인사 매뉴얼, 상품 자료, 회의록, 업무 가이드 등이 여러 폴더와 서비스에 분산되면 직원이 필요한 정보를 찾는 데 상당한 시간이 소요됩니다.

이 문제를 해결하는 방법 중 하나가 Claude 기반 사내 지식검색 시스템입니다. 단순히 Claude에게 문서를 업로드하는 방식이 아니라, 사내 문서를 검색하고 필요한 정보만 Claude에 전달하는 RAG(Retrieval-Augmented Generation) 구조로 설계하면 기업용 지식검색 시스템으로 확장할 수 있습니다.

1. Claude 지식검색 시스템의 기본 구조

Claude 기반 사내 지식검색 시스템은 일반적으로 다음과 같은 구조로 구성됩니다.

사내 문서 → 문서 수집 → 텍스트 추출 → Chunking → Embedding → Vector DB → 검색 → Claude → 답변

사용자가 질문을 입력하면 Claude가 모든 사내 문서를 직접 읽는 것이 아니라, 검색 시스템이 질문과 관련성이 높은 문서를 먼저 찾아냅니다.

그다음 검색된 문서의 내용을 Claude에 Context로 전달하고, Claude가 해당 정보를 기반으로 자연어 답변을 생성합니다.

즉, 핵심 구조는 다음과 같습니다.

사용자 질문
   ↓
검색 API
   ↓
Vector Database
   ↓
관련 문서 검색
   ↓
검색 결과 + 사용자 질문
   ↓
Claude API
   ↓
근거 기반 답변

이 구조를 사용하면 Claude를 단순한 챗봇이 아니라 기업 내부 지식에 접근하는 AI 인터페이스로 활용할 수 있습니다.

2. 문서 수집 계층

첫 번째 단계는 회사 내부에 존재하는 다양한 데이터를 수집하는 것입니다.

예를 들어 다음과 같은 데이터가 대상이 될 수 있습니다.

PDF
Word 문서
Excel 파일
사내 매뉴얼
업무 규정
FAQ
회의록
제품 설명서
기술 문서
Google Drive 문서
Notion 페이지
사내 Wiki

여기서 중요한 것은 문서 형식보다 문서의 출처와 권한 정보를 함께 관리하는 것입니다.

예를 들어 다음과 같은 메타데이터를 저장할 수 있습니다.

document_id
document_name
department
author
created_at
updated_at
access_level
source_url
version

이렇게 구성하면 나중에 검색 결과를 단순한 텍스트가 아니라 “어떤 문서에서 나온 정보인지”까지 추적할 수 있습니다.

3. Chunking이 검색 품질을 결정한다

문서를 그대로 Vector Database에 넣는 것은 좋은 방법이 아닙니다.

예를 들어 100페이지짜리 인사규정 PDF를 하나의 데이터로 저장하면 사용자의 질문과 정확히 관련된 부분을 검색하기 어렵습니다.

따라서 문서를 작은 단위인 Chunk로 나눕니다.

예를 들어,

인사규정.pdf

→ 제1장 총칙
→ 제2장 근무시간
→ 제3장 휴가
→ 제4장 복리후생
→ 제5장 퇴직

처럼 의미 단위로 분할하는 방식입니다.

단순히 글자 수만 기준으로 자르는 것보다 제목, 문단, 표, 섹션 등의 의미 구조를 유지하면서 분할하는 방식이 검색 품질에 유리합니다.

특히 기업용 RAG에서는 Chunk 크기와 overlap을 무조건 고정하기보다 문서 유형에 따라 다르게 설정하는 전략이 필요합니다.

4. Vector Database와 Embedding

문서를 Chunk 단위로 분리했다면 각각을 검색할 수 있도록 벡터화합니다.

일반적인 흐름은 다음과 같습니다.

문서
 ↓
Chunk
 ↓
Embedding Model
 ↓
Vector
 ↓
Vector Database

Vector Database에는 텍스트뿐만 아니라 문서의 메타데이터도 함께 저장합니다.

예를 들어:

text:
"연차휴가는 입사일을 기준으로..."

department:
"HR"

access_level:
"employee"

document:
"인사규정_2026.pdf"

사용자가

“연차휴가는 어떻게 계산하나요?”

라고 질문하면 질문 역시 벡터화하고, Vector Database에서 의미적으로 유사한 Chunk를 검색합니다.

이것이 일반적인 키워드 검색과 RAG 검색의 중요한 차이입니다.

5. Claude는 검색 결과를 해석하는 역할

여기서 중요한 부분이 있습니다.

Vector Database가 답변을 만드는 것은 아닙니다.

Vector Database는 관련 문서를 찾아주는 역할을 담당하고, Claude는 검색된 정보를 해석하고 사용자에게 답변하는 역할을 담당합니다.

예를 들어 검색 결과가 다음과 같다고 가정해 보겠습니다.

[문서 A]
연차휴가는 근속기간에 따라 다음과 같이 부여한다.

[문서 B]
연차휴가 신청은 사내 시스템에서 진행한다.

[문서 C]
특별휴가는 별도의 승인 절차를 거친다.

사용자의 질문이

“연차휴가를 어떻게 신청하나요?”

라면 검색 시스템은 관련 문서를 찾아 Claude에 전달합니다.

Claude는 해당 Context를 기반으로

“연차휴가는 사내 시스템에서 신청할 수 있습니다.”

와 같이 답변을 생성합니다.

따라서 검색 정확도와 Claude의 응답 품질을 함께 관리해야 합니다.

6. 권한 관리가 가장 중요한 기업용 요소

사내 지식검색 시스템에서 일반적인 챗봇보다 더 중요한 것이 접근 권한 관리입니다.

예를 들어 인사팀 직원에게만 공개되는 급여정책 문서가 있다고 가정해 보겠습니다.

일반 직원이 질문했다고 해서 해당 문서가 검색 결과에 포함되면 안 됩니다.

따라서 검색 단계에서부터 권한을 필터링해야 합니다.

사용자 인증
   ↓
사용자 권한 확인
   ↓
검색 가능한 문서 필터링
   ↓
Vector Search
   ↓
Claude

예를 들어 사용자가 marketing 부서라면 검색 조건에

department = marketing
OR
access_level = employee

같은 조건을 적용할 수 있습니다.

이렇게 해야 “Claude가 보지 말아야 할 문서를 검색하는 상황” 자체를 방지할 수 있습니다.

7. Hallucination을 줄이는 방법

기업용 지식검색에서 가장 중요한 문제 중 하나가 Hallucination(환각)입니다.

Claude가 검색된 문서에 없는 내용을 임의로 생성하면 기업 업무에서는 문제가 될 수 있습니다.

따라서 시스템 프롬프트에 다음과 같은 원칙을 설정할 수 있습니다.

제공된 사내 문서를 근거로 답변한다.

문서에서 확인할 수 없는 내용은 추측하지 않는다.

근거가 부족한 경우
"현재 제공된 사내 문서에서 확인되지 않습니다."
라고 답변한다.

답변에 사용한 문서의 출처를 함께 표시한다.

그리고 답변에 출처 문서명과 관련 섹션을 표시하도록 설계하면 사용자가 답변을 검증하기도 쉬워집니다.

8. 검색과 생성 결과를 별도로 평가해야 한다

RAG 시스템을 구축했다고 해서 바로 좋은 시스템이 만들어지는 것은 아닙니다.

두 가지를 별도로 평가해야 합니다.

검색 품질

질문과 관련된 문서를 제대로 가져왔는가?

생성 품질

검색된 문서를 바탕으로 Claude가 정확한 답변을 만들었는가?

예를 들어 100개의 테스트 질문을 만들어 다음과 같은 지표를 관리할 수 있습니다.

평가 항목	확인 내용
Retrieval Accuracy	필요한 문서를 검색했는가
Context Relevance	검색 결과가 질문과 관련 있는가
Faithfulness	답변이 검색 문서에 근거하는가
Answer Relevance	질문에 적절하게 답했는가
Citation Accuracy	출처가 실제 근거와 일치하는가

이러한 Evaluation 체계를 구축하는 것이 실제 기업용 AI 시스템과 단순한 개인용 챗봇의 중요한 차이입니다.

9. 추천 아키텍처

실제 구축에서는 다음과 같은 형태로 확장할 수 있습니다.

                [사내 사용자]
                      │
                      ▼
               [Web / Chat UI]
                      │
                      ▼
              [인증 / 권한 관리]
                      │
                      ▼
                [Search API]
                 /          \
                /            \
       [Keyword Search]   [Vector Search]
                \            /
                 \          /
                  [Reranking]
                      │
                      ▼
                [관련 문서]
                      │
                      ▼
                [Claude API]
                      │
                      ▼
             [답변 + 출처 표시]

이 구조에서는 Vector Search 하나만 사용하는 것보다 Keyword Search와 Vector Search를 결합한 Hybrid Search를 사용하는 것도 고려할 수 있습니다.

특히 사내 문서에는 제품명, 직원 코드, 문서번호, 프로젝트명처럼 정확한 키워드 검색이 중요한 정보가 많기 때문입니다.

10. 최종적으로는 AI Agent로 확장할 수 있다

Claude 기반 사내 지식검색 시스템은 단순 검색에서 끝나지 않습니다.

예를 들어 직원이

“지난달 마케팅팀 회의에서 결정된 신규 캠페인 일정 알려줘.”

라고 질문했을 때 관련 회의록을 검색하고 답변하는 수준에서 시작할 수 있습니다.

이후 시스템을 확장하면

“신규 캠페인 관련 회의록을 찾아서 주요 결정사항을 정리하고 담당자별 업무를 표로 만들어줘.”

처럼 검색 → 분석 → 요약 → 업무 분류까지 수행하는 AI Agent로 발전시킬 수 있습니다.

여기에 MCP나 Tool Use를 연결하면 Google Drive, Notion, 사내 DB, CRM 등의 시스템과 연결해 검색을 넘어 실제 업무를 수행하는 기업용 AI로 발전시킬 수도 있습니다.

마무리

Claude 기반 사내 지식검색 시스템의 핵심은 Claude 자체가 아니라 전체 아키텍처에 있습니다.

단순히 사내 문서를 Claude에게 제공하는 것이 아니라,

문서 수집 → Chunking → Embedding → Vector DB → 권한 필터링 → 검색 → Reranking → Claude → 출처 기반 답변 → 평가

라는 구조를 설계해야 합니다.

특히 기업 환경에서는 검색 정확도, 권한 관리, 데이터 보안, Hallucination 방지, 출처 추적, 지속적인 평가가 핵심입니다.

따라서 Claude를 사내 지식검색에 적용할 때는 단순한 “AI 검색창”을 만드는 것보다 RAG 기반 기업 지식 플랫폼을 구축한다는 관점으로 접근하는 것이 바람직합니다.

이 주제는 기존의 “Claude 사용법” 수준보다 훨씬 기술적인 콘텐츠라서, 블로그에서는 다음 글로 「Claude RAG에서 Chunking 전략이 검색 정확도에 미치는 영향」, 「Claude와 Vector Database 연결하는 방법」, 「Claude RAG의 Hallucination을 줄이는 방법」을 이어서 작성하면 전문적인 시리즈로 구성하기 좋습니다.