2025년, 에이전트 준비가 되려면 탄탄한 인프라가 필요한 이유

프롤로그

AI가 어디에나 존재하는 지금, 많은 아이디어와 함께 직접 행동에 나서거나 적어도 실험해 보고 싶은 욕구가 생겨납니다. 우리 glueckkanja AG는 이 과정 전반에 걸쳐 고객을 지원합니다. 물론 우리는 이미 에이전트를 개발하고 구축하고 있지만, 프로젝트의 80%에서 주된 초점은 에이전트 생성을 위한 데이터와 테넌트 준비에 있습니다. 조직에서 Copilot을 프로덕션 환경에 도입하기 전에 인프라를 비판적으로 점검해 볼 가치가 있습니다. 이 영역에서 의사 결정을 내릴 때는 AI 에이전트를 대규모로 배포하기 전에 이해해야 할 몇 가지 중요한 측면이 있습니다. 그래서 이 블로그 포스트에서 핵심 단계와 차이점을 안내해 드리려고 합니다. Microsoft 365 Copilot Agents 같은 AI 어시스턴트가 업무 세계를 변화시키겠다고 약속하는 시대에 무엇보다 확실한 원칙이 하나 있습니다. _AI는 그 아래에 있는 시스템만큼만 우수하다_는 것입니다.

이 종합 가이드는 SharePoint, Teams, Power Platform의 핵심 사례를 다루면서 Copilot Agents를 위해 데이터와 인프라를 준비하는 방법을 설명합니다.

인프라(데이터)가 중요한 이유

AI 에이전트를 활용할 때 반드시 이해해야 할 점은, 이 에이전트들이 우리 조직, 우리 데이터, 우리 고유의 운영 맥락에 대한 지식을 본질적으로 갖고 있지 않다는 것입니다. 기본적으로 AI 에이전트는 대규모 언어 모델(LLM) 학습에서 비롯된 내장 지식만을 지니고 있습니다. 이러한 AI 에이전트의 역량을 효과적으로 강화하고 확장하려면 다양한 구성 요소를 체계적으로 통합해야 합니다. 이는 시스템 프롬프트, 지식 베이스, 커넥터, 웹 검색 기능, Microsoft Graph 액세스, 시맨틱 검색을 비롯한 추가 도구의 구현을 통해 이루어질 수 있습니다. 이 구성 요소들이 결합되어 AI 에이전트가 조직의 특정 요구와 데이터에 밀접하게 부합하는, 더 정확하고 맥락에 맞는 응답과 작업을 제공할 수 있게 됩니다. 우리는 지금 에이전틱 시대의 초입에 있으므로, 많은 조직이 기존 SharePoint Online 라이브러리를 기반으로 정보를 가져오는 단순한 에이전트부터 시작하게 될 것입니다.

IT 담당자인 우리에게 이것은 SharePoint Online의 데이터를 그 어느 때보다 세심하게 관리해야 한다는 의미입니다.

SharePoint Online = 지식 = 데이터, 그리고 데이터 = 핵심

분명한 메시지를 드리자면, 조직에 AI 코파일럿을 도입하기 전에 먼저 데이터를 정리해야 합니다. Copilot Agents에 공급되는 데이터는 Microsoft 365 Copilot 자체에도 그대로 공급되기 때문입니다.

그뿐만이 아닙니다. Microsoft 365 Copilot도 동일한 데이터를 평가합니다. 데이터가 어수선하거나, 과도하게 공유되어 있거나, 제대로 보호되지 않으면 AI가 잘못된 정보나 민감한 정보를 예기치 않게 노출할 수 있습니다. 예를 들어 Copilot에 회사 조직 구조를 물었는데, 봐서는 안 되는 기밀 조직 개편 계획의 세부 내용을 받게 되는 상황을 상상해 보십시오. 이런 사고는 SharePoint나 Teams 같은 플랫폼에서 콘텐츠가 과도하게 공유(지나치게 광범위하게 접근 가능)될 때 발생합니다. 참고로 Copilot은 기존 권한을 모두 준수하므로, 이런 일은 권한이 잘못 구성되었을 때만 발생할 수 있습니다. 반대로 데이터가 사일로에 갇혀 있거나 접근이 불가능하면 AI 어시스턴트의 유용성은 떨어집니다.

Copilot은 개별 사용자가 최소한 보기 권한을 가진 조직 데이터만 표시합니다!

출처: https://learn.microsoft.com/en-gb/copilot/microsoft-365/microsoft-365-copilot-privacy?azure-portal=true

핵심 요점: 엔터프라이즈 AI는 탄탄한 데이터 기반 위에서만 성공합니다. 최근 Microsoft 보고서는 AI 배포 전에 해결해야 할 최우선 과제로 데이터 과잉 공유, 데이터 유출, 규정 미준수 사용을 지목합니다. SharePoint Online과 기타 데이터 소스의 준비에 투자하는 조직은 확신을 갖고 Copilot의 이점을 활용할 수 있는 반면, 그렇지 않은 조직은 보안 침해나 무의미한 AI 결과물의 위험을 감수하게 됩니다. 연구에 따르면 의사 결정권자의 약 3분의 1이 핵심 데이터에 대한 완전한 가시성을 확보하지 못하고 있습니다.

지금 M365 데이터 인프라를 개선하는 10단계

이제 에이전트에 데이터가 필요하다는 것을 알았습니다. 우리 glueckkanja가 이런 프로젝트에 참여할 때 고객과 함께 처음부터 끝까지 진행하는 전형적인 10단계 목록은 다음과 같습니다.

1단계: 핵심 공유 설정 점검

과도한 공유로 이어질 수 있는 테넌트 전체 설정을 확인합니다. 예를 들어 기본 링크 공유 정책(SharePoint/OneDrive에서 “링크가 있는 모든 사용자” 또는 “조직 내 사용자”가 기본적으로 허용되어 있는지), 사용자가 기본적으로 공개 팀을 만들 수 있는지, Power Platform 환경이 거버넌스 없이 열려 있는지를 면밀히 살펴봅니다. 여기서 잘못 구성된 기본값은 의도치 않은 광범위한 접근의 흔한 원인입니다.

2단계: 공개 팀 감사

“공개”로 설정된 Microsoft Teams 팀을 검토합니다. 공개 팀은 조직 내 누구나 그 콘텐츠를 검색하고 접근할 수 있다는 뜻입니다. 공개로 설정된 팀에 실제로 민감하지 않고 널리 공개해도 되는 콘텐츠만 있는지 확인하십시오. 그렇지 않다면 비공개로 전환하거나 구성원을 조정합니다. (팀이 공개로 생성된 뒤 잊혀져 파일이 전 직원에게 노출되는 일은 흔히 일어납니다.)

3단계: Graph 커넥터 검토

테넌트에 서드파티 데이터(예: 외부 파일 시스템, 위키 등)를 가져오는 _Microsoft Graph 커넥터_가 설정되어 있는지 확인합니다. 모든 사용자가 봐서는 안 되는 데이터를 인덱싱하는 커넥터는 제거하거나 보호하십시오. 이유는 무엇일까요? Graph 커넥터를 통해 인덱싱된 콘텐츠는 Microsoft Graph 검색 인덱스의 일부가 됩니다. 즉 Copilot이 프롬프트에 답할 때 이를 활용할 수 있다는 뜻입니다. 의도한, 관련 있는 데이터 소스만 연결되어 있어야 합니다.

4단계: SharePoint Online 기준 보고서 생성

SPO에는 에이전트와 Copilot에 원치 않는 데이터가 흘러들 수 있는 다양한 위험 요소가 있습니다. 다음과 같은 핵심 지표를 살펴봐야 합니다.

• 폴더 수준에서 끊어진 권한 상속
• 공개 SharePoint 사이트
• “외부 사용자를 제외한 모든 사용자” 또는 전체 사용자를 포함하는 기타 동적 그룹의 사용
• “모든 사용자” 공유 링크
• “조직 내 모든 사용자” 공유 링크
• 사이트 관리자 / 소유자 / 구성원 / 방문자 그룹에 포함된 부적절한 사용자

5단계: 위험 분류 및 우선순위 지정

1~4단계의 결과를 심각도에 따라 순위를 매깁니다. 어떤 사이트나 파일이 가장 비즈니스에 중요하거나 민감한 데이터를 담고 있으면서 동시에 노출 위험도 있습니까? 그것부터 수정하는 데 우선순위를 두십시오. 비즈니스 맥락을 겹쳐 보면(예: 재무 데이터가 있는 사이트 vs. 일반 템플릿이 있는 사이트) 가장 영향이 큰 문제부터 집중할 수 있습니다.

6단계: 액세스 검토에 사이트 소유자 참여시키기

위험하다고 표시된 각 SharePoint 사이트(또는 팀)에 대해 사이트 소유자가 누가 접근 권한을 갖고 있는지, 그것이 적절한지 다시 확인하게 합니다. 소유자는 대개 콘텐츠에 가장 가까이 있는 사람이므로 “어, 왜 _Everyone_이 여기에 읽기 권한을 갖고 있지? 이러면 안 되는데.” 같은 문제를 빠르게 발견할 수 있습니다. 사이트 관리자가 정기적으로 권한을 승인하는 프로세스를 도입하십시오.

7단계: 지속적인 감독 체계 수립

새로운 과잉 공유 문제를 잡아내는 지속적인 모니터링 프로세스를 마련합니다. 과잉 공유 통제는 일회성 조치가 아닙니다. 새로운 사이트, 팀, 파일이 계속 생성되는 만큼 잘못된 구성을 선제적으로 포착해야 합니다. 외부로 공유된 파일이나 대규모 그룹에 공유된 파일, 새로 생성된 공개 팀 등을 잡아내기 위해 Microsoft Purview의 보고서나 경고를 활용하는 것을 고려하십시오. Microsoft의 도구는 이러한 조건에 대한 경고를 자동화할 수 있으므로, 이를 활용해 견고한 보안 상태를 유지하십시오.

8단계: 민감도 레이블 및 DLP 정책 적용

Microsoft Purview의 민감도 레이블을 사용해 데이터를 분류하고(기밀, 극비 등) 해당 레이블을 보호 설정과 연결합니다. 예를 들어 “기밀” 레이블은 파일을 암호화하거나 외부 공유를 차단할 수 있습니다. 또한 데이터 손실 방지(DLP) 정책을 구성해 민감한 정보의 과잉 공유를 방지하거나 모니터링합니다(예: 누군가 고객 주민등록번호 목록을 이메일로 보내는 것을 차단). 이 도구들은 일상적인 사용에서의 우발적 유출을 막을 뿐 아니라 Copilot과도 함께 작동합니다. Copilot이 레이블이 지정된 콘텐츠에 부적절한 방식으로 접근하거나 출력하려 하면 DLP가 개입할 수 있습니다. 나아가 뒤에서 언급하듯 Copilot 자체가 문서의 레이블을 응답에까지 이어서 적용합니다.

9단계: Power Platform 거버넌스 구현

감독 범위를 Power Platform(Power Apps, Power Automate 등)으로 확장합니다. Power Platform용 DLP 정책을 정의해 커넥터를 통제합니다(예를 들어 누군가 민감한 SharePoint 목록에서 데이터를 끌어와 외부 서비스에 게시하는 흐름을 만들 수 없도록). 또한 적절한 보안을 갖춘 여러 환경(개발/테스트/프로덕션)을 운영해, 에이전트나 앱을 만드는 “시민 개발자”가 의도치 않게 데이터를 노출하지 않도록 하는 것도 고려하십시오. 요컨대 Power Platform이 데이터에 대한 통제되지 않는 뒷문이 되는 것을 막아야 합니다.

10단계: 에이전트 제작자 교육 및 역량 강화

마지막으로 AI 에이전트를 구축하거나 배포할 사람들(전문 개발자든 비즈니스 사용자든)을 위한 가이드라인과 모범 사례를 만듭니다. 데이터를 안전하게 다루는 교육을 마련하십시오. 예를 들어 에이전트에 적합한 지식 소스를 선택하는 방법, 널리 공유되는 에이전트에 민감한 파일을 포함하면 안 되는 이유, 에이전트의 출력에서 예상치 못한 정보가 있는지 테스트하는 방법 등입니다. “에이전트 메이커” 사이에 데이터를 의식하는 문화를 조성하면 AI 솔루션을 설계할 때 누군가 의도치 않게 정보를 노출할 가능성이 줄어듭니다.

출처:

• https://techcommunity.microsoft.com/blog/microsoft365copilotblog/from-oversharing-to-optimization-deploying-microsoft-365-copilot-with-confidence/4357963
• https://techcommunity.microsoft.com/blog/microsoft365copilotblog/microsoft-graph-connectors-update-expand-copilot%E2%80%99s-knowledge-with-50-million-ite/4243648

이 단계를 완료했다면 이제 안심하고 생산적인 에이전트 구축을 시작할 수 있습니다. 에이전트를 구축하기 위해 우리가 활용할 수 있는 Microsoft의 다양한 플랫폼과 기능이 있습니다. 가장 대표적인 예는 다음 장에서 확인할 수 있습니다. 이 목록과 관련해 도움이 필요하다면 언제든 문의해 주십시오. 이 중요한 준비 작업을 함께 도와드리겠습니다.

그동안에도 샘플 데이터, 수동으로 업로드한 파일, RAG로 연결한 특정 데이터를 사용해 PoC나 테스트 에이전트를 만드는 것은 얼마든지 가능합니다. 다만 에이전트를 대규모로 구현/배포하기 전에는 이 단계를 거치기를 권장합니다.

에이전트 플랫폼 간 차이 이해

1단계: 에이전트 제작자 이해

데이터를 준비하는 기초 작업을 마쳤다면, 이제 에이전트를 만들 수 있는 플랫폼에는 어떤 것들이 있는지 이해해야 합니다. 우리는 이 도구들을 기능과 가능성으로 구분해 보려고 하지만, 에이전트를 만들고 올바른 도구를 선택하는 일은 하나의 스펙트럼이라는 점에 유의해야 합니다. Microsoft 생태계에는 AI 에이전트를 구축하는 여러 방법이 있습니다. 필요와 팀의 역량 수준에 맞는 방법을 고르는 것이 중요합니다. 이는 언제 Azure AI Foundry를 활용하고 언제 Copilot Studio의 기본 도구를 쓸지도 분명하게 해 줍니다.

Microsoft는 현재 에이전트를 구축할 수 있는 다양한 도구 세트를 제공합니다. 서로 비슷해 보이지만, 각기 다른 대상과 전문성 수준을 위해 만들어졌습니다. 아래 개요를 자세히 살펴보십시오. 누가 이 에이전트를 만들고 유지 관리해야 하는지를 이해하면, 에이전트를 위해 어떤 지식 소스(= 데이터)를 준비해야 하는지도 알 수 있습니다. 아래 목록의 도구 외에도 M365 Agents Toolkit, Visual Studio Code, Agent SDK 등 에이전트를 구축하기 위한 프로 코드 솔루션이 더 있습니다. 이들 역시 다른 에이전트와 동일한 데이터에 접근하므로, 우리의 데이터 준비 단계는 이들에게도 모두 적용됩니다.

출처: https://www.egroup-us.com/news/microsoft-copilot-ai-integration/

2단계: 플랫폼에 대한 사용 사례와 요구 사항 파악

짐작하시겠지만 모든 플랫폼이 모든 사용 사례를 지원하는 것은 아닙니다. 에이전트는 기존 지식을 기반으로 질문에 답하는 단순한 작업에 쓰일 수도 있고, 답변을 자동으로 생성하거나 프로세스를 실행하는 복잡한 작업에 쓰일 수도 있습니다. 또한 이 에이전트에 어디서 어떻게 접근할 것인지, 즉 최종 UX도 플랫폼을 결정하는 데 중요한 요소입니다.

이러한 점을 고려해 우리는 보통 에이전트를 구축할 수 있는 가장 쉬운 솔루션을 사용하려고 합니다. 동시에 향후 발전에 대비해 확장 가능한 솔루션을 찾아야 합니다. 하지만 모든 에이전트를 처음부터 Azure AI Foundry 위에 구축할 필요는 없습니다.

팁:

에이전트 구축을 어디서 시작해야 할지 확신이 서지 않는다면 언제든 Copilot Studio를 사용해 Azure AI의 데이터를 추가로 통합하고 이를 Microsoft 365 Copilot에 게시할 수 있습니다. 이렇게 하면 “상하위 호환성”을 모두 확보할 수 있습니다.

RAG(Retrieval-Augmented Generation) vs. SharePoint vs. 업로드

처음 보면 모든 것이 RAG처럼 보이지만, 차이가 있습니다! Copilot Agents와 그 에이전트 기능을 처음 접하면 모든 지식 통합이 동일한 RAG(검색 증강 생성) 패턴을 따른다고 가정하기 쉽습니다. 문서를 검색해 답변을 생성한다는 점에서 겉으로는 모두 RAG처럼 보일 수 있지만, 내부에서 작동하는 방식은 크게 다릅니다. 목표, 규모, 기술적 준비 상태에 따라 올바른 접근 방식을 선택하려면 이 차이를 이해하는 것이 필수입니다. 간단한 설명과 개요는 다음과 같습니다.

수동 파일 업로드

수동 업로드는 Copilot 에이전트에 지식을 추가하는 가장 간단한 방법입니다. 문서를 Copilot Studio 인터페이스에 직접 드래그 앤 드롭하면 됩니다. Microsoft가 이 파일들을 자동으로 인덱싱하고 사용자 쿼리 시 관련 콘텐츠를 검색합니다. 소규모 파일럿과 초기 테스트에 이상적입니다. 다만 파일의 내용이 에이전트에 접근할 수 있는 모든 사람에게 공개되어도 괜찮은 것이어야 한다는 점에 유의하십시오. 여기에는 별도로 관리할 권한 관리 기능이 없습니다. 반면 내용이 바뀌면 장기적으로 이 파일들을 수동으로 업데이트해야 합니다. 현재 Copilot Agents에는 최대 20개의 파일을 수동으로 추가할 수 있습니다.

출처: https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/copilot-studio-agent-builder-knowledge#file-size-limits

SharePoint Online

이 방법은 Microsoft의 Retrieval API를 사용해 Graph 커넥터로 연결된 SharePoint Online의 콘텐츠에 직접 접근합니다. 에이전트는 쿼리 시점에 가장 관련성 높은 콘텐츠를 실시간으로 검색하며, 기존 Microsoft 365 권한을 준수합니다. 콘텐츠는 SharePoint 사이트, 문서 라이브러리, 폴더 또는 파일이 될 수 있습니다. 동적이고 안전하며, 자체 인프라를 관리하지 않고도 부서나 사업부 전체로 확장하기에 적합합니다. 기존 인프라 위에 구축하면서 SharePoint의 기본 보안 모델을 그대로 사용한다는 점은 다른 지식 옵션에 비해 큰 장점입니다. 각 부서가 파일을 쉽게 업데이트할 수 있고, 그 내용은 에이전트에 그대로 반영됩니다. 즉 접근 수준이 다른 두 사용자가 에이전트에 질문하면, 한 사람은 특정 파일에서 나온 답을 받고 (접근 권한이 없는) 다른 사람은 받지 못합니다. 이것이 바로 우리가 원하는 동작입니다.

참고: SharePoint 목록은 현재 지원되지 않는 지식 유형이므로 기본 기능만으로는 인덱싱할 수 없습니다(2025년 3분기 기준).

커스텀 RAG(자체 관리)

전통적인 RAG 구성에서는 전체 검색 파이프라인을 직접 구축하고 관리합니다. 여기에는 문서 전처리, 청킹, 임베딩, 벡터 데이터베이스 저장, 쿼리 시점의 상위 매칭 검색이 포함됩니다. 콘텐츠가 처리되고 검색되는 방식을 완전히 제어할 수 있지만, 그만큼 복잡성과 유지 관리 부담도 따릅니다. Microsoft의 관리형 서비스가 제공하는 범위를 넘어서는 커스터마이징이 필요한 고급 사용 사례에 가장 적합합니다. 이는 Copilot이나 Copilot Studio의 기본 기능이 아니며, Microsoft Azure에서 구현하게 됩니다.

RAG를 사용해야 하는 경우의 예를 들면, AI 에이전트를 자체 데이터베이스나 Microsoft 365 외부에 저장된 수천 개의 PDF와 통합하고 커스텀 필터를 적용해야 한다면 자체 관리형 RAG가 필요할 수 있습니다. 다만 이는 상당한 노력이 필요합니다.

출처: https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview?tabs=docs

무엇을 언제 선택해야 할까

세 가지 접근 방식 모두 언어 생성을 뒷받침하기 위해 콘텐츠를 검색하지만, 기술적인 의미에서 “진정한 RAG”에 해당하는 것은 커스텀 자체 관리형 솔루션뿐입니다. 처음 시작하는 대부분의 조직에는 수동 업로드나 SharePoint 연결이 훨씬 쉽고 빠르게 구현할 수 있는 방법입니다. 최소한의 설정으로 좋은 결과를 얻을 수 있고, 팀이 인프라가 아니라 사용 사례 설계와 도입에 집중할 수 있게 해 줍니다.

이 지점에서 제가 드리는 일반적인 조언은 다음과 같습니다.

에이전트를 가능한 한 데이터 가까이에 구축하십시오

예: 데이터가 대규모 SQL 데이터베이스나 외부 CRM 시스템에 저장되어 있다면 SharePoint 에이전트로는 해결되지 않습니다. 모든 지식이 SharePoint에 있다면 SharePoint 에이전트나 Copilot 에이전트가 좋은 출발점이 될 수 있습니다.

커스텀 RAG는 기본 출발점이 아니라, 관리형 옵션이 제공할 수 있는 범위를 넘어서는 요구가 있을 때만 고려해야 합니다. 수동 업로드는 첫 파일럿이나, 자주 업데이트되지 않는 제한적이고 특정한 지식을 다루는 소규모 파일럿에 적합합니다. 많은 시나리오에서 우리는 그냥 SharePoint 라이브러리나 사이트를 에이전트와 함께 사용합니다. 그래서 우리는 다음과 같은 시나리오에 집중하고 있습니다.

Microsoft 365 Copilot 및 Copilot Agents: 기본 제공되는 보안과 컴플라이언스

안전한 클라우드 인프라는 엔터프라이즈 AI의 초석입니다. Microsoft는 에이전트를 Microsoft 365 Copilot의 컨텍스트 안에 둠으로써 가능한 가장 안전한 프레임워크를 제공합니다. 모든 조직은 접근에 대해서는 Conditional Access와 다단계 인증 기반의 기존 보안 프레임워크를, 거버넌스에 대해서는 Microsoft Purview 기반의 기존 거버넌스 프레임워크를 그대로 신뢰할 수 있습니다.

M365 Copilot에서 사용되거나 Copilot Studio에서 Teams 챗봇으로 게시된 에이전트는 테넌트 경계 안에서만 접근할 수 있습니다. 즉 이 애플리케이션에 대해서도 이미 갖추고 있는 것과 동일한 수준의 보안을 확보하게 됩니다.

이에 더해 Microsoft는 “Enterprise Grade Data Protection”이라 부르는 여러 기술적, 조직적 약속을 제공합니다.

출처: https://learn.microsoft.com/en-gb/copilot/microsoft-365/microsoft-365-copilot-privacy?azure-portal=true

Microsoft 365 Copilot: 프롬프트와 응답을 위한 Enterprise Data Protection(EDP)

• 계약상 보호: 프롬프트(사용자 입력)와 응답(Copilot 출력)은 **데이터 보호 부록(DPA)**과 제품 약관에 따라 보호됩니다. 이는 Exchange의 이메일과 SharePoint의 파일에 적용되는 것과 동일한 보호입니다.
• 데이터 보안: 저장 및 전송 중 암호화, 물리적 보안 통제, 테넌트 수준 데이터 격리
• 개인정보 보호 약속 Microsoft는 데이터 처리자로서 고객이 지시한 대로만 데이터를 사용합니다. GDPR, EU 데이터 경계, ISO/IEC 27018 등을 지원합니다.
• 접근 제어 및 정책 상속: Copilot은 다음을 준수합니다. ID 모델과 권한, 민감도 레이블, 보존 정책, 감사 설정, 관리자 구성, AI 및 저작권 위험 완화, 그리고 프롬프트 인젝션, 유해 콘텐츠, 저작권 문제(보호 자료 감지 및 Customer Copyright Commitment를 통한)에 대한 보호
• 모델 학습에 미사용: 프롬프트, 응답, Microsoft Graph 데이터는 기반 모델 학습에 사용되지 않습니다.

SharePoint Online 지식을 사용하는 Copilot Agent:

• 권한 및 공유 모델: SharePoint Online에 접근하는 에이전트는 항상 연결된 SharePoint 사이트의 권한을 준수합니다. 즉 한편으로는 접근해야 할 모든 사람이 사이트에 최소한 읽기 권한을 갖고 있는지 확인해야 하고, 다른 한편으로는 민감한 정보가 권한 없는 사용자에게 노출될 수 있는 불필요한 권한을 부여하지 않도록 주의해야 합니다. 권한을 올바르게 구성하는 것이 핵심입니다. Copilot Agents는 질문하는 사용자가 볼 수 있도록 허용된 콘텐츠에만 접근하고 표시할 수 있기 때문입니다. 또한 Microsoft Purview 정보 보호를 활용하면 민감도 레이블과 데이터 손실 방지(DLP) 정책이 콘텐츠와 함께 유지됩니다.
• 지속되는 레이블과 DLP: Microsoft Purview 정보 보호를 활성화해 민감도 레이블이 콘텐츠와 함께 유지되도록 하십시오. Copilot 에이전트는 원본 문서의 레이블을 상속합니다. 즉 파일이 “기밀”로 분류되어 있다면, 이후 AI가 생성하는 모든 콘텐츠나 문서에 그 레이블이 이어집니다. 이 지속적인 레이블 상속은 데이터 손실 방지 정책과 맞물려 AI가 보호된 데이터를 의도치 않게 노출하는 것을 막습니다. 실제로 Copilot이 민감한 파일을 요약하더라도 그 요약본 역시 민감 정보로 취급된다는 뜻입니다. 이는 Microsoft 365 밖에서는 찾아볼 수 없는 탁월한 기능이며, Microsoft 365 생태계에 이 정도로 깊이 통합될 수 있는 AI 에이전트는 다른 곳에서는 볼 수 없을 것입니다!

에이전트 활용을 위한 SharePoint Online 추가 준비 모범 사례

Copilot Agents와 함께 SharePoint Online을 효과적으로 사용할 수 있도록 준비하려면 다음 모범 사례를 따르십시오.

전용 SharePoint 사이트

먼저 Copilot 에이전트의 지식 베이스 전용으로 설계된 SharePoint 사이트나 특정 폴더를 만드십시오. 이 접근 방식은 과잉 공유 관련 문제를 최소화하고, 사용자가 민감하거나 무관한 파일을 에이전트가 접근할 수 있는 저장소에 실수로 업로드할 위험을 줄여 줍니다. 기존 SharePoint 사이트를 사용하기로 했다면, 에이전트가 검색해서는 안 되는 기밀 또는 민감 정보가 저장되어 있지 않은지 콘텐츠를 꼼꼼히 검토하십시오.

액세스 권한 부여

의도한 모든 사용자가 사이트나 폴더에 접근하는 데 필요한 읽기 권한을 갖고 있는지 확인하는 것도 중요합니다. 접근 권한을 수동으로 부여해야 한다면, 프로세스를 단순화하고 우발적인 권한 구성 오류를 방지하기 위해 의도한 모든 사용자에게 사이트 읽기 권한을 부여하십시오(예: SharePoint 사이트의 방문자 그룹에 추가하거나 적절한 Azure AD 보안 그룹을 사용).

파일 준비

Copilot Agents에서 사용할 문서를 준비할 때는 AI가 현재 파일에 포함된 이미지를 해석할 수 없다는 점을 기억하십시오. 따라서 중요한 시각 정보가 손실되지 않도록 설명이 담긴 이미지 캡션이나 대체 텍스트를 추가하십시오. 텍스트 위주의 문서라면, 요약하거나 참조할 콘텐츠의 총량을 최대 150만 단어 또는 300페이지 이내로 유지해야 Copilot이 효과적으로 작동합니다.

Excel 파일의 경우 각 파일이 숫자 또는 텍스트 중 하나에 집중하도록 데이터를 구성하십시오. 콘텐츠가 섞인 표는 정확도가 떨어지는 경향이 있습니다. 또한 관련 데이터가 통합 문서의 단일 시트에 담겨 있을 때 에이전트가 쿼리에 가장 안정적으로 응답합니다.

에이전트는 Excel 데이터가 하나의 시트에 담겨 있을 때 가장 잘 응답합니다.

예: 대규모 고객 피드백 설문이 하나의 Excel 파일에 저장되어 있다면, 정량 데이터(평점, 수치 응답 등)와 정성 데이터(자유 텍스트 피드백 등)를 두 개의 시트로 분리하십시오. 이렇게 하면 Python이나 Excel 수식 같은 도구로 수치 데이터를 효율적으로 분석하면서(예: 평균 계산, 결과 정렬, 신뢰 수준 판단), M365 Copilot의 감성 분석 기능으로 텍스트 기반 피드백에서 인사이트를 얻을 수 있습니다.

파일 제한 사항

마지막으로 Copilot Agents와 Copilot Studio가 지원하는 파일 형식과 크기 제한을 알아 두십시오. 현재 지원 현황은 다음 표에 정리되어 있습니다. https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/copilot-studio-agent-builder-knowledge#file-size-limits

문서 길이에 관해 Microsoft가 공유한 모범 사례도 참고하십시오. https://support.microsoft.com/en-gb/topic/keep-it-short-and-sweet-a-guide-on-the-length-of-documents-that-you-provide-to-copilot-66de2ffd-deb2-4f0c-8984-098316104389

현재 SharePoint Online에서 지원되지 않는 파일 형식: 공식적으로는 위에 나열되지 않은 모든 형식이 공식 지원 대상이 아닙니다.

CSV 파일처럼 일반 텍스트 형식에 가까운 일부 파일 형식은 공식 지원 대상이 아니어도 무리 없이 작동할 수 있습니다. 그러나 대부분의 다른 파일 형식, 특히 CAB, EXE, ZIP 같은 컨테이너 파일과 PNG, IMG, MP3, MP4 같은 이미지, 비디오, 오디오 형식은 현재 지원되지 않습니다.

결론

이 권장 사항을 따르면 Copilot Agents가 잘 구조화되고 안전하며 품질 높은 데이터에 접근할 수 있게 되어, 유용성을 극대화하고 우발적인 데이터 노출 위험을 최소화할 수 있습니다. SharePoint 환경 준비에 시간을 투자하는 것은 조직 내 AI 에이전트의 성공적인 배포와 정착을 위한 탄탄한 기반이 됩니다.

실제로 우리의 “Build-an-Agent” 프로젝트 중 상당수가 바로 여기서 시작합니다. 에이전트를 만드는 것이 아니라, AI에 사용할 좋은 품질의 데이터를 확보하도록 인프라와 지식을 준비하는 것입니다. 에이전트는 그 아래에 있는 시스템만큼만 우수하기 때문입니다!