벡터 DB 없는 엔터프라이즈 RAG: SharePoint Embedded와 Copilot Retrieval API 아키텍처 분석

유신2026.10.29

엔터프라이즈 환경에서 비정형 문서를 기반으로 한 RAG(Retrieval-Augmented Generation) 파이프라인을 구축할 때 가장 먼저 맞닥뜨리는 기술적 병목은 임베딩 모델의 성능이 아니라 데이터 거버넌스와 권한 동기화의 오버헤드다. 문서를 청킹(Chunking)하고 임베딩 벡터로 변환해 별도의 벡터 데이터베이스(Vector DB)에 인덱싱하는 순간, 원천 시스템의 ACL(Access Control List), Purview 기반 보안 레이블, eDiscovery 및 감사 로그와의 연결 고리가 끊어지게 된다. 이를 수작업 파이프라인으로 동기화하려는 시도는 동기화 지연, 데이터 유출 리스크, 인프라 운영 복잡도(Opex) 증가라는 결과를 낳는다.

Microsoft가 공개한 SharePoint Embedded 기반의 AI 애플리케이션 아키텍처는 문서를 외부 벡터 저장소로 복제하지 않고, Microsoft 365 테넌트 경계 내에서 검색과 권한 제어를 인라인으로 처리하는 대안을 제시한다.

1. 전형적인 벡터 DB 파이프라인의 구조적 한계

일반적인 RAG 파이프라인은 소스 저장소(SharePoint, 로컬 스토리지 등)에서 문서를 추출(ETL)하여 텍스트를 분할하고 임베딩을 생성한 뒤 독립된 벡터 DB에 적재하는 방식을 취한다. 이 아키텍처는 다음과 같은 엔터프라이즈 제약을 수반한다.

권한 불일치(Security Trimming 실패): 원천 저장소에서 특정 사용자의 파일 읽기 권한이 회수되더라도, 벡터 DB에 동기화되기 전까지 인덱스 검색 결과에 노출되는 데이터 누수 리스크가 상존한다.
컴플라이언스 파편화: Microsoft Purview의 DLP(데이터 손실 방지), 민감도 레이블, 감사(Audit), 보존 정책이 외부 벡터 DB 인프라에 일관되게 전파되지 못한다.
파이프라인 관리 비용: 임베딩 생성 배치 파이프라인 장애, 인덱스 동기화 누락, 청크 버전 관리 등 데이터 파이프라인 자체를 유지보수하기 위한 Opex가 지속적으로 누적된다.

SharePoint Embedded와 결합된 Copilot 검색 계층은 문서 저장소 자체를 API 구동형 콘텐츠 계층으로 두고, 해당 계층 내에서 시맨틱 인덱싱과 검색을 직접 처리하도록 설계되어 이러한 중간 파이프라인 단계를 배제한다.

2. SharePoint Embedded 기반 그라운딩 아키텍처

SharePoint Embedded는 기존 SharePoint UI(사이트, 라이브러리)에 종속되지 않고, API 호출만으로 문서 저장·관리 기능을 애플리케이션 백엔드에 통합할 수 있는 헤드리스(Headless) 콘텐츠 플랫폼이다.

[사용자 질의] 
     │
     ▼
[AI 애플리케이션 / 에이전트]
     │
     ├── (옵션 A) Microsoft Foundry Agent Service (SharePoint 지식 소스 연동)
     │                     │
     │                     ▼
     └── (옵션 B) Microsoft 365 Copilot Retrieval API 
                           │
                           ▼
              [SharePoint Embedded Container]
              - 시맨틱 인덱스 (Semantic Index)
              - M365 보안/컴플라이언스 (Purview, DLP, eDiscovery)
              - 테넌트 경계 내 정밀 권한 필터링

2.1 문서 저장 및 격리 메커니즘

애플리케이션은 SharePoint Embedded 컨테이너(Container) 단위로 데이터를 분리 및 관리한다. 모든 데이터는 고객의 Microsoft 365 테넌트 내부에 저장되므로, 조직의 데이터 주권과 규제 요건이 그대로 유지된다. 또한 과금 모델은 Azure를 통한 종량제(Consumption-based/Pay-as-you-go) 방식을 채택하여, 애플리케이션 개발 테넌트가 부담하는 표준 청구 모델 또는 실제 사용하는 테넌트에 비용을 전가하는 패스스루(Pass-through) 모델 중 아키텍처 요건에 맞추어 선택할 수 있다.

2.2 검색 및 그라운딩 경로

저장된 문서를 AI 에이전트의 지식 베이스로 활용하는 경로는 두 가지로 구성된다.

Microsoft Foundry Agent Service: 에이전트 설정 내에서 SharePoint를 지식 소스로 직접 지정하여 검색 및 응답 생성을 플랫폼 관리형으로 위임하는 방식.
Microsoft 365 Copilot Retrieval API: 커스텀 에이전트나 독립 애플리케이션에서 그라운딩 단계를 직접 제어할 때 사용하는 방식. API 호출을 통해 컨테이너 내 파일에 대한 시맨틱 인덱스 기반 검색을 수행하고 연관 청크를 반환받아 LLM 프롬프트에 주입한다. 라이선스를 보유한 사용자를 통해 시맨틱 인덱스를 초기화하여 동작한다.

3. 엔지니어링 관점의 트레이드오프와 아키텍처 분석

별도의 벡터 DB를 구축하지 않는 구성은 명확한 이점을 제공하지만, 시스템 설계 시 고려해야 할 엔지니어링 제약 또한 명확하다.

데이터 거버넌스 vs. 검색 파이프라인 제어권

자체 벡터 DB(예: Azure AI Search, Pinecone, Qdrant 등)를 구축하면 청킹 전략(Recursive, Semantic 등), 임베딩 모델(Text-embedding-3 등), 하이브리드 검색(BM25 + Dense)의 가중치, 리랭킹(Reranking) 알고리즘을 엔지니어가 직접 미세 조정할 수 있다. 반면, Copilot Retrieval API를 사용하는 방식은 인덱싱과 랭킹 메커니즘이 Microsoft 365 내부 엔진으로 추상화된다. 고도로 튜닝된 도메인 특화 검색 로직이 요구되는 시나리오보다는, 문서 보안과 규제 준수가 우선순위인 업무 문서 검색 시나리오에 적합하다.

단일 장애점(SPOF) 및 테넌트 의존성

모든 검색 및 저장소가 Microsoft 365 서비스 가용성에 결합된다. API Rate Limit 및 할당량 정책이 적용되므로, 대규모 트래픽이 집중되는 B2C 성격의 서비스보다는 엔터프라이즈 사내 업무 시스템 및 B2B SaaS 백엔드 아키텍처에 부합한다.

MCT로서 실무 아키텍트들에게 항상 강조하는 지점은, “최신 기술의 도입 여부는 기능 목록이 아니라 시스템의 유지관리 경계(Maintenance Boundary)를 어디까지 감당할 것인가에 달려 있다”는 사실이다. 별도 벡터 DB를 도입하여 인덱스 동기화 파이프라인을 직접 운영·감시할 인프라 역량이 부재하다면, 거버넌스가 플랫폼 레벨에서 강제되는 관리형 계층을 채택하는 것이 장애 표면적을 줄이는 실무적인 선택이다.

4. MCP(Model Context Protocol) 서버를 통한 개발 자동화

SharePoint Embedded는 공개 미리보기(Public Preview)로 MCP 서버를 제공한다. Claude, Cursor 등과 같은 코딩 에이전트가 표준화된 인터페이스를 통해 직접 SharePoint Embedded 환경을 제어할 수 있도록 지원하는 구조다.

컨테이너 수명 주기 관리: 컨테이너 유형(Container Type) 및 컨테이너 생성·구성.
환경 프로비저닝: 애플리케이션 등록, Azure 과금 연결 자동화.
콘텐츠 적재 및 레퍼런스 앱 스캐폴딩: 테스트 데이터 업로드 및 초기 프로젝트 코드베이스 생성 지원.

MS AI MVP 관점에서 이 에이전트 파이프라인의 구조적 한계와 가능성을 짚어보자면, MCP의 도입은 인프라 셋업과 프로비저닝에 소모되던 개발 오버헤드를 대폭 줄여주지만, 여전히 컨테이너 격리 수준 설계와 과금 계정 맵핑(개발 테넌트 vs. 고객 테넌트)과 같은 상위 수준의 아키텍처 결정은 엔지니어의 철저한 사전 검토가 선행되어야 한다.

5. 도입 가이드라인 및 결론

독립 벡터 DB 구축 대신 SharePoint Embedded와 Copilot Retrieval API를 선택해야 하는 명확한 기준은 다음과 같다.

보안 레이블 및 접근 권한의 즉각적인 반영이 필수적인 경우: 실시간 ACL 검증 및 Purview 컴플라이언스가 요구되는 데이터 환경.
인프라 파이프라인 간소화: 임베딩 모델 호스팅, 벡터 인덱스 파티셔닝, 동기화 스케줄러 개발 비용을 제거하고자 할 때.
M365 에코시스템과의 정합성: 이미 Microsoft 365 테넌트를 운영 중이며, Azure 종량제 과금을 통해 예측 가능한 비용 모델을 가져가고자 하는 엔터프라이즈 환경.

반면, 독자적인 임베딩 모델 커스터마이징, 밀리초 단위의 극단적인 저지연(Low-latency) 검색 응답, 비정형 텍스트 외의 특수 도메인 벡터 연산이 핵심 요구사항인 워크로드라면 자체 벡터 인프라를 유지하는 것이 타당하다.

📚 참고 자료

Microsoft 365 Developer Blog: Build AI-powered apps without creating a vector database (Steve Pucelik)