문서 100만 건, 에이전트 300개: 엔터프라이즈급 Microsoft 365 Copilot 커넥터를 만들며 배운 것
대부분의 조직 지식은 사람들이 신뢰하지만 정작 잘 방문하지 않는 포털과 저장소에 잠들어 있습니다. Microsoft 365 Copilot 커넥터는 바로 이 간극을 메우기 위해 존재합니다.
Microsoft는 사내 문서를 지원되는 Copilot 경험 전반에서 근거 있는 컨텍스트(grounded context) 로 활용할 수 있도록, 엔터프라이즈급 Microsoft 365 Copilot 커넥터를 직접 구축해 운영하고 있습니다. 이 커넥터는 현재 프로덕션에서 가동 중이며, 엔지니어링·지원·현장 조직을 아우르는 팀에 서비스되고 있습니다. 규모는 이렇습니다.
- 문서 100만 건
- 월 10만 명 이상의 사용자
- 300개 이상의 Copilot Studio 에이전트
이 글은 프로토타입 단계를 지나 프로덕션을 고민하는 플랫폼 팀·개발자·커넥터 오너를 위해, 설계 선택·보안/거버넌스·스키마 결정·운영 패턴·검색 품질 확보 방법을 정리한 실전 기록입니다.
커넥터가 왜 중요한가: “한 번 넣으면, 여러 표면에서 재사용”
커넥터의 진짜 힘은 데이터 수집(ingestion) 자체가 아니라, 콘텐츠가 플랫폼에 들어온 뒤 가능해지는 것들에 있습니다. 커넥터가 라이브가 되면, 콘텐츠는 다음 표면에서 근거 컨텍스트로 활용됩니다.
- Copilot Chat: 사용자가 자연어로 질문하면 이메일·파일·Teams 메시지와 나란히, 사내 콘텐츠에 근거한 답변을 받습니다. 포털 방문이 필요 없습니다.
- Microsoft 365 앱의 Copilot: Word·PowerPoint·Excel에서 초안 작성·요약·자료 생성 시 사내 지식이 컨텍스트로 등장합니다.
- Copilot Studio 에이전트: 적절한 권한·라이선스를 가진 사용자가 커넥터 콘텐츠 범위로 커스텀 에이전트를 만듭니다. 실제로 300개 이상의 에이전트(인시던트 대응 도우미, 온보딩 코파일럿, 도메인 Q&A 봇 등)가 커넥터 팀의 추가 작업 없이 만들어졌습니다.
- Copilot CLI·개발자 도구: 엔지니어가 터미널·IDE에서 동일한 권위 있는 콘텐츠에 근거한 답을 얻습니다.
- Copilot Retrieval API: 색인된 지식을 프로그래밍 방식으로 조회해, 예상치 못한 커스텀 경험까지 구축합니다.
핵심 통찰: 커넥터는 단순 수집 파이프라인이 아니다. 깔끔한 스키마, 신뢰할 수 있는 수집, 올바른 접근 제어에 투자하면, 지원되는 Copilot 경험들이 표면마다 별도 연동 없이 그 콘텐츠를 재사용합니다.
참고로 이 글이 다루는 것은 콘텐츠를 Microsoft 365 substrate에 색인하는 동기(sync) 커넥터(구 Graph 커넥터)로, 콘텐츠를 원격에서 그대로 질의하는 페더레이션(federated) 커넥터와는 다릅니다.
문서가 알려주지 않는 ‘프로덕션 격차’ 4가지
공개 문서는 “0에서 동작하는 커넥터”까지는 데려다줍니다. 하지만 동작하는 커넥터에서 프로덕션 커넥터로 가는 과정에서, 계획에 없던 네 가지 격차가 드러났습니다.
1. 테넌트 구성을 일찍 검증하라
- 크로스 테넌트 데이터 흐름: 오늘날 Entra ID 테넌트 간 데이터 흐름에 대한 지원 모델은 없습니다. 커넥터 운영을 단일 테넌트로 통합해 해결했습니다.
- “Draft” 상태 늪: 권한이 올바른데도 커넥터가 “Draft”에 멈추는 경우가 있습니다. 플랫폼 팀 에스컬레이션이 가장 빠른 해제 경로였습니다.
- 오너십 공백: 여러 플랫폼 팀의 책임이 겹치고 단일 오너가 없을 수 있습니다. 에스컬레이션 경로를 미리 확인하세요.
- 개발 테넌트 수명: 개발 테넌트에 문서화되지 않은 자동 삭제 정책이 있을 수 있습니다. 장기 스테이징 환경으로 의존하지 마세요.
2. 보안·규정 준수를 코드보다 먼저 시작하라
앱 등록과 권한 설정은 쉬운 부분입니다. 엔터프라이즈 규모의 크로스 테넌트 커넥터에는 다음이 추가로 필요했습니다.
- 위협 모델링(Threat model)
- 개인정보 검토(Privacy review)
- 책임 있는 AI 검토(Responsible AI review)
- 플랫폼 팀 설계 검토
- 보안 예외 승인
템플릿도, 체크리스트도, 정해진 경로도 없었습니다. 코드를 쓰기 훨씬 전부터 시작해야 하는 상당한 작업이었습니다.
3. 커넥터 콘텐츠를 발견 가능하게 만들어라
수집에 성공해도 Copilot이 그 콘텐츠를 우선하지 않을 수 있습니다. 기본적으로 이메일과 사용자 파일이 더 높게 랭크되고, 커넥터 콘텐츠 랭킹은 클라이언트마다 다르며, 왜 특정 결과가 노출/누락됐는지 가시성이 없습니다. Microsoft 팀은 색인 항목에 사용자 ID를 붙여 그 사용자의 이메일·파일과 동일한 신호로 랭크되도록 하는 UserPrincipal 지원을 중요한 개선으로 보고 향후 도입을 계획하고 있습니다.
4. 스로틀링과 공유 한도를 전제로 설계하라
약 100만 문서 지점에서 스로틀링이 중요한 설계 변수가 됐습니다. 재시도 로직, 지수 백오프, 429 응답 모니터링, 운영 알림으로 대응했습니다. Copilot 커넥터 플랫폼에는 테넌트 내 모든 커넥터가 공유하는 전역 속도 제한이 있어, 다른 커넥터가 수집을 몰아치면 내 커넥터가 스로틀링됩니다. 공유 쿼터에 대한 가시성·우선순위·용량 예약이 없으므로, 예기치 못한 백프레셔를 견디도록 파이프라인을 설계하는 것이 좋습니다.
확장을 위한 아키텍처: 데이터와 컴퓨트를 분리하라
아키텍처의 단 하나의 원칙은 원본 콘텐츠와 수집 컴퓨트를 분리하는 것이었습니다. 이 선택이 파이프라인을 재시도·모니터링·진화하기 쉽게 만들었습니다.
- Blob Change Feed: Azure Blob Storage의 변경 피드가 문서 생성·수정·삭제 시 이벤트를 발생시킵니다. 이것이 모든 수집 작업의 트리거입니다. 폴링도, 예약된 전체 크롤도 없습니다.
- Azure Function (이벤트 기반): 변경 피드를 수신해 각 이벤트를 처리합니다. Blob을 읽고 콘텐츠를 변환하고 메타데이터를 보강해 Graph 커넥터 API로 항목을 푸시합니다. 함수는 무상태(stateless) 이며, 모든 상태는 저장소 계층과 Graph 플랫폼에 존재합니다.
- 경계로서의 저장소: 함수는 Blob에 읽기 권한만 가지며 되쓰지 않습니다. 데이터는
저장소 → 함수 → Graph API한 방향으로만 흐르므로, Blob 이벤트 재처리는 항상 멱등(idempotent) 합니다. - Graph API 수집: 재시도 로직, 429 백오프, Application Insights 관측성과 함께 항목을 푸시합니다.
이 분리 덕분에 ▲문서 플랫폼은 저장소를 독립적으로 진화시킬 수 있고 ▲파이프라인은 Azure Functions 소비 플랜으로 수평 확장되며 ▲하나의 불량 Blob이 다른 수집을 막지 않는 장애 격리가 가능합니다.
스키마 설계는 가장 레버리지가 큰 결정
스키마 설계를 가장 높은 레버리지의 결정으로 다뤘고, 네 번의 반복을 통해 순전히 스키마·메타데이터 정제만으로 검색 품질을 크게 끌어올렸습니다.
- 문서 유형(TSG, 런북, 아키텍처 문서, 온보딩 가이드)을 서로 다른 속성 집합에 매핑
- Copilot 랭킹에 최적화된 상세한 연결 설명(connection description) 작성
- 신선도(freshness)·오너십 신호를 위한 커스텀 속성 추가
- 합성 데이터가 아닌 실제 사용자 질의로 테스트
보안 인증·배포 패턴
- 프로덕션 서비스 간 통신에 관리 ID(Managed Identity)
- 상용·소버린 클라우드 전반의 일관 배포를 위한 코드형 인프라(IaC)
- 처음부터 추상화한 환경별 구성
검색 품질 측정과 상태 모니터링
Copilot 팀의 Search Evaluation 프레임워크에 접근할 수 있었던 것이 큰 이점이었습니다. 실제 사용자 질의에 대한 정밀도·재현율을 측정해, 변경이 사용자에게 도달하기 전에 회귀를 잡아냈습니다. 또한 수집 실패·스로틀링 급증에 대한 알림과 재수집 복구 자동화를 구축했습니다.
실제 임팩트: 포털에서 플랫폼으로
커넥터가 라이브가 된 뒤 세 가지가 두드러졌습니다.
- 포털에서 플랫폼으로: 문서 플랫폼이 “사람들이 방문하는 목적지”에서 “AI 경험을 구동하는 지식 소스”로 바뀌었습니다. 지식이 Copilot Chat, Word의 Copilot, VS Code의 Copilot, Azure Copilot에 직접 떠오르고, 소비는 기존 워크플로에 스며든 형태(ambient·contextual)가 됐습니다.
- 에이전트 생태계: 한 번 콘텐츠를 넣으니 여러 AI 표면에서 활성화됐습니다. 300개 이상의 Copilot Studio 에이전트가 커넥터 위에 구축됐고, 콘텐츠는 Copilot Chat·Copilot CLI·Work IQ 등으로 확산됐습니다. 커넥터를 “한 번 제대로” 만든 덕분에, 300개 에이전트 중 어느 것도 추가 연동 작업을 요구하지 않았습니다.
- 측정 가능한 품질과 유지된 거버넌스: Retrieval API로 프로그래밍 조회가 가능해졌고, 기존 Microsoft 365 보안·접근 제어에 그대로 의존해 거버넌스는 중앙 관리를 유지했습니다. 이는 소버린 클라우드·규제 환경에 결정적이었습니다.
커넥터를 구축할 때 우선할 권장 사항
프로토타입에서 프로덕션으로 넘어가기 전에 우선순위로 두어야 할 실천입니다.
- 보안·규정 준수 대화를 코드 작성 전에 시작하라 — 예상보다 훨씬 많은 시간을 확보하세요.
- 스키마 설계를 최고 레버리지 결정으로 다뤄라 — 실제 Copilot 질의로 일찍 테스트하고 공격적으로 반복하세요.
- 첫날부터 평가(evaluation)를 구축하라 — Copilot이 콘텐츠를 실제로 잘 쓰는지 측정해야 합니다.
- 파이프라인뿐 아니라 커넥터 자체의 상태 모니터링을 구축하라.
- 생태계를 염두에 두고 설계하라 — 잘 만들면 예상치 못한 방식으로 사람들이 그 위에 무언가를 만듭니다.
마무리와 시작하기
공개 문서는 “무엇(what)”을 다룹니다. 이 글은 “어떻게(how)”와, 더 중요하게는 “왜 그럴 가치가 있는가(why it’s worth it)”를 다뤘습니다. 보안 승인은 수개월, 스키마 반복은 네 번, 운영 준비는 아무도 예산 잡지 않은 오너십을 요구했습니다. 하지만 대가는 분명합니다. 조직의 지식이 권위 있는 콘텐츠에 근거해 AI를 통해 접근 가능해지고, 지원되는 Copilot 경험 전반에서 활용됩니다.
시작에 도움이 되는 공식 리소스:
- Microsoft 365 Copilot 커넥터 개요
- Copilot 커넥터 API로 작업하기
- 연결 생성·관리 / 스키마 등록·관리
- Copilot Studio에 커넥터를 지식 소스로 추가
- Microsoft Graph 스로틀링 가이드 / Azure Blob Storage 변경 피드
Microsoft 365 Roadmap에서 예정 업데이트를 추적할 수 있으며, 로드맵 날짜는 잠정적이고 변경될 수 있습니다.
출처: 1 million documents to 300+ agents: Building an enterprise-scale Microsoft 365 Copilot connector (Microsoft Tech Community — Microsoft 365 Copilot Blog)
자세한 내용은 원문을 참조하세요.