Claude로 Microsoft 365를 사용하는 3가지 경로를 35개의 권한 요청을 확인한 후 다시 선택한 이야기

서론: 동의 화면에서 멈춰 서다

"Claude와 Microsoft 365를 연결하면, 메일도 캘린더도 AI로 한 번에 조작할 수 있다."

그 말을 듣고, Softeria제 MS365 MCP 서버를 Claude Code에 추가했다.

그런데 동의 화면을 열고 나서 멈춰버렸다.

권한 요청(Permission requests)이 35개나 줄지어 나열되어 있었다. 일부를 발췌하면 다음과 같다.

Read your mail
Read mail you can access
Read all users' full profiles
Read your mailbox settings
Read your calendars
Read your files
Read your OneNote notebooks
Read your tasks and task lists
Read directory data
Read all groups
Read your chat messages
Read user chat messages
Read your channel messages
Read items in all site collections
Read all transcripts of online meetings
Read all recordings of online meetings
Read presence information of all users in your organization
Maintain access to data you have given it access to

전부 「Read(읽기)」이기 때문에 쓰기 사고는 발생하지 않는다.

하지만 요구 범위가 너무 넓다.

게다가 화면 하단에는 「조직을 대리하여 동의함(Consent on behalf of your organization)」이라는 체크박스가 있다.

조직에 속한 모든 사용자에게 이 35개의 권한을 일괄적으로 부여할지 여부를, 화면을 보고 있는 단 한 사람이 결정할 수 있는 구조다.

우리 회사는 내가 전권을 관리하고 있기 때문에 판단하여 동의했다.

다만, 이것이 「정보 시스템(IT) 부서가 있는 기업」이었다면 확실히 제지당했을 수준의 권한 요청이다.

그리고 다음 날, 다른 선택지가 있다는 것을 알게 되었다.

Anthropic이 2026년 5월 11일에 Claude for Microsoft 365를 일반 제공(GA) 시작했다.

이것은 경로도 권한 모델(Permission model)도 근본적으로 다르다.

나는 일단 보안 업계 종사자로서, 이러한 「앱으로의 권한 위임(Delegation of authority)」은 업무에서도 몇 번이고 보아왔다. 기왕 하는 김에, Claude로 MS365를 사용하는 3가지 경로를 정리하고, 각각에서 「어디로 무엇이 전송되는지」를 비교해 보려 한다. 기밀 데이터를 다루는 업무를 하는 사람에게 있어, 경로를 선택하는 방법은 무시할 수 없는 논점이라고 생각한다.

Claude로 Microsoft 365를 사용하는 3가지 경로

경로	메커니즘	경유하는 API	주로 할 수 있는 일	권한 부여 방식
1. MCP 연동	Claude가 외부 MCP 서버를 통해 Graph API를 호출	Microsoft Graph API	메일·캘린더·OneDrive·Excel 범위·Teams 회의록 읽기, 데이터 교차 처리	OAuth 동의를 통해 30개 전후의 권한을 일괄 부여
...

3가지는 완전히 다른 기술 스택과 다른 권한 모델로 동작한다.

「Claude가 Microsoft 365에 액세스할 수 있다」라고 한마디로 말해도, 경로에 따라 전달하는 정보의 범위와 경로가 크게 다르다.

MCP 연동의 권한 요청 35개를 분석하기

서드파티(Third-party) MCP 서버는 여러 개 존재하지만, 이번에 다룬 것은 Softeria제의 MS 365 MCP Server이다.

특별히 선정한 것은 아니며, MS365용 MCP 구현체로서 가장 널리 알려진 것을 채택했다.

그 외에도 커뮤니티 구현 MCP 서버가 GitHub상에 여러 개 있으며, 기업 도입 시에는 자사에서 MCP 서버를 구축하여 권한 범위(Scope)를 업무 범위로 좁히는 것이 본래의 최적해이다. 서드파티 구현체를 사용할 경우에는 권한 요청을 하나씩 정밀하게 검토할 필요가 있다.

동의 화면에서 확인할 수 있는 권한을 영향 범위별로 분류하면 다음과 같다.

개인 스코프 (본인의 데이터만)

메일 (Read your mail / Read your mailbox settings)
캘린더 (Read your calendars)
파일 (Read your files)
OneNote (Read your OneNote notebooks)
작업 (Read your tasks and task lists)
연락처 (Read your contacts)
프로필 (Sign you in and read your profile)
채팅 (Read your chat messages)
채널 게시물 (Read your channel messages)
온라인 회의 (Read your online meetings)
상태 (Read your presence information)
관련 인물 목록 (Read your relevant people list)

여기까지는 "사용자 본인의 데이터를 읽어오는" 범위이므로 어느 정도 이해할 수 있다.

조직 전체 스코프 (영향 범위가 넓어짐)

주의해서 살펴봐야 할 것은 바로 이것이다.

Read all users' full profiles … 조직 내 모든 사용자의 프로필 읽기
Read directory data … 디렉터리 정보 전반 읽기
Read all groups … 조직 내 모든 그룹 읽기
Read group memberships … 그룹 멤버십 읽기
Read user chat messages … 다른 사용자의 채팅 메시지 읽기
Read items in all site collections … 모든 SharePoint 사이트의 아이템 읽기
Read all transcripts of online meetings … 모든 온라인 회의의 전사(Transcript) 읽기
Read all recordings of online meetings … 모든 온라인 회의의 녹화본 읽기
Read presence information of all users in your organization … 조직 내 모든 사용자의 상태 정보 읽기
Read all company places … 회사의 모든 장소 정보 읽기

조직에 사용자가 100명 있는 중견 기업에서 이 동의가 통과되었다면 어떤 일이 벌어질까?

단 한 명이 실수로 MCP 서버에 어떠한 취약점을 만들어낸다면, 조직 전체의 채팅, 회의 녹화본, SharePoint까지 접근 가능한 상태가 된다.

"조직을 대신하여 동의" 체크박스의 의미

여기에 체크를 하면 조직 내 모든 사용자를 대신하여 일괄 동의한 것이 된다.

단 한 번의 조작으로 조직 전체에 대한 권한 위임(Delegation)이 완료된다.

반대로, 체크를 하지 않으면 동의한 개인의 데이터 범위로만 한정된다.

all 계열의 권한도 자신의 테넌트(Tenant) 내에서 실제로 접근할 수 있는 범위는 계약 내용과 RBAC (역할 기반 액세스 제어)에 의해 제한된다.

나는 회사 규모가 작고 영향 범위가 한정적이기 때문에 체크 없이 동의했다.

중규모 이상의 조직에서 같은 시도를 하려 한다면, 우선 정보시스템(情シス) 부서의 심사를 통과해야 할 수준이다.

5월 11일 일반 제공 시작 Claude for Microsoft 365

Anthropic이 2026년 2월에 PowerPoint용 애드인(Add-in) 베타, 4월에 Word, 그리고 5월 11일에 Excel, PowerPoint, Word 모두를 일반 제공(GA, General Availability) 시작한다.

이것은 MCP와는 완전히 다른 경로로 Microsoft 365에 접근하는 방식이다.

작동 방식

Microsoft AppSource를 통해 제공되는 Office 애드인.

PowerPoint의 "홈 > 애드인"에서 "Claude"를 검색하여 추가한다. 설치하면 PowerPoint 내 사이드바에 Claude가 표시된다.

기술적으로는 Office JavaScript API를 경유한다. Microsoft 공식의 애드인 배포 기반을 통해 Office 앱 내의 객체(슬라이드, 시트, 문서)를 직접 조작하는 방식이다.

할 수 있는 일

슬라이드 마스터, 레이아웃, 폰트, 컬러를 읽어 들여 템플릿을 준수한 슬라이드 생성
기존 슬라이드의 선택적 편집 ("이 부분을 더 간결하게"와 같은 지시로 대응)
이미지가 아닌 네이티브 PowerPoint 요소로 출력 (편집 가능)
Excel, PowerPoint, Word 간의 크로스 앱 컨텍스트 (Cross-app context) (4월에 Word가 추가되면서 3종 세트 완성)
Skills (재사용 가능한 워크플로우) 및 Connectors (외부 데이터 연동)

MCP와 무엇이 다른가

액세스 범위: Office 앱 내로 한정됨. 메일, 캘린더, SharePoint에는 접근하지 않음
권한 위임: Office Add-in으로서의 표준 권한 (Microsoft AppSource 심사 완료)
이용 조건: Microsoft 365 구독 + Claude Pro/Max/Team/Enterprise

"모든 Teams 회의의 전사(Transcription)"
와 같은 큰 권한을 부여하지 않아도, 문서 편집 용도라면 애드인(Add-in)을 통해 완결된다.

용도별 선택 방법

판단 기준은 심플하며, "Claude에게 무엇을 시키고 싶은가"뿐이다.

문서 편집 (슬라이드 작성, Excel 조작, Word 문서)이 주 목적이라면 Claude for Microsoft 365 애드인이 유일한 선택지다. MCP의 큰 권한을 부여할 필요가 없다.

데이터 횡단 및 자동화 (메일 일괄 처리, 캘린더 조작, Teams 회의록 자동 취득)가 필요하다면 MCP 연동이 필요하다. 단, 권한 요청 범위에 대한 정밀한 검토가 필요하다.

두 가지 모두 하고 싶다면, 애드인과 MCP의 병용이다. 권한이 중복되는 범위도 있으므로, 용도에 따라 나누어 사용하는 설계가 필요하다.

단발성으로 사용하거나 가끔 파일을 처리하는 정도라면, 웹 앱(Web App)에서 매번 업로드하는 것이 권한을 최소화(Minimum)하는 방법이다.

어떤 것을 사용하면 무엇이 어디로 전송되는가

편리함의 이면에서 "데이터가 어디로 전송되는가"를 정리해 두어야 한다. 세 가지 입구 각각에서 전송 경로가 다르다.

공통: 모두 Anthropic으로 전송됨

세 가지 방식 모두 Claude의 백엔드(Backend)는 Anthropic이 운영한다.

따라서 "Claude에게 무언가를 처리시킨 순간, 그 정보는 Anthropic의 서버로 전송된다"는 점은 공통 사항이다.

"로컬에서 완결되는 선택지는 없다"는 점을 이해해 두어야 한다.

이는 Microsoft Copilot을 사용할 때의 Microsoft, ChatGPT를 사용할 때의 OpenAI와 같은 구조다. AI를 사용하는 이상, 어딘가의 벤더(Vendor)에게 정보를 전달하게 된다.

MCP 연동 경로

Claude (Anthropic) → MCP Server (Softeria) → Microsoft Graph API라는 3단계 경로를 거친다.

Claude가 "메일을 읽고 싶다"고 판단하면, 먼저 MCP 서버가 Graph API를 호출한다. 그 결과를 Claude에게 반환한다. 이 과정에서 데이터 경로에 MCP 서버 운영 회사(이번 사례에서는 Softeria)가 중계로서 개입한다.

MCP 서버가 오픈 소스(OSS)라 하더라도, 호스트 환경에서 변조되지 않았는지는 확인할 수 없다.

리스크로는, MCP 서버 측에 의도하지 않은 처리(로그 취득, 별도 호스트 전송)가 있을 경우, 35개 권한 분량의 데이터가 유출될 가능성이 있다.

대책은 세 가지다. 신뢰할 수 있는 MCP 서버를 선택할 것, 사내에서 MCP 서버를 셀프 호스팅(Self-host)할 것, 별도의 로그 감사(Audit) 메커니즘을 갖출 것.

Claude for Microsoft 365 경로

PowerPoint 애드인에서 Anthropic Server로 직접 통신한다. Anthropic과 PowerPoint 사이에는 서드 파티(Third-party)가 개입하지 않는다 (Microsoft AppSource는 배포를 위한 스토어일 뿐, 데이터가 지나가는 통로가 아니다).

전송되는 데이터는 Office 앱 내에서 조작하고 있는 문서의 내용이다. 슬라이드 본문, 셀 범위, Word 본문 등이 그대로 Anthropic에 전달된다.

리스크는, 기밀 데이터를 포함한 슬라이드를 열어둔 상태에서 Claude에게 "요약해줘"라고 요청하면, 그 기밀 데이터가 Anthropic으로 전송된다는 점이다.

대책은, 열기 전에 마스킹(Masking) 처리를 할 것, 보안성이 높은 자료에서는 애드인을 실행하지 않을 것, 조직의 생성형 AI 이용 정책에 따라 판단할 것.

웹 앱 (claude.ai) 경로

사용자가 직접 파일을 선택하여 업로드한다. 경로는 심플하며, 브라우저에서 Anthropic Server로 직송된다.

전송하는 데이터의 범위를 매번 컨트롤할 수 있다. 다른 루트와 달리 "권한 위임" 개념이 없는 대신, 휴먼 에러(잘못된 파일을 업로드하는 실수)가 직접적인 원인이 될 수 있다.

대책은 업로드 전 육안 확인, 마스킹(Masking) 처리된 파일을 사용하는 것이다.

리스크 비교표

입구	데이터 송신처	경유하는 제3자	한 번의 동의로 전달되는 범위	기밀 데이터 취급 용이성
MCP 연동	Anthropic	MCP 서버 운영 회사	약 35개의 권한 (동의 시 확정)	주의: 권한을 부여한 범위는 상시 액세스 가능
...

채용 업무·전문직 등 기밀 정보를 다루는 업무에서의 판단

나는 채용 컨설턴트가 본업이며, 후보자의 직무경력서, 면접 기록, 계약서, 제안서와 같은 기밀 데이터를 매일 다룬다.

이러한 업무에서 Claude를 사용할 경우, 입구 선택은 '편리함'만으로 결정할 수 없다.

마스크 툴과 Claude for M365의 조합

기밀 정보가 포함된 후보자 정보나 제안서를 AI로 다룰 때, 가장 먼저 해야 할 일은 마스킹(Masking)이다.

개인명, 소속 기업, 연락처, 연봉 등을 비식별화한 후 AI에 전달한다.

이때, 마스킹 처리된 데이터를 Claude for Microsoft 365로 편집한다면, Anthropic에 전송되는 것은 마스킹된 데이터뿐이다.

반대로 MCP를 통해 '전체 파일 횡단 검색'과 같은 방식으로 사용하면, 마스킹되지 않은 원본 데이터가 전달될 가능성이 있다.

즉, 업무의 전 단계에 마스크 툴이 있다면, Claude for M365는 상당히 안전하게 사용할 수 있는 조합이 된다.

우리 회사에서는 자체 개발한 마스크 툴을 사용하고 있지만, 시판되는 마스킹 서비스로도 동일한 사상으로 설계할 수 있다.

MCP 연동으로 데이터를 횡단 처리하는 경우

이메일 처리나 Teams 회의록 추출 등을 MCP로 자동화하는 경우에는 마스크 툴을 거칠 수 없는 경로가 된다.

이 부분은 '조직 내 데이터가 Anthropic 및 MCP 서버 운영 회사에 전달된다는 전제하에 허용할 수 있는가'에 대한 조직적 판단의 영역이다.

우리 회사와 같은 소규모 체제라면 판단은 단순하다.

중규모 이상의 조직이라면 정보보안(情シス) 및 보안 담당자의 합의가 필요한 수준이다.

보안을 유지하며 AI를 능숙하게 활용하기

우리 회사에서는 AI 전문 엔지니어와 협력하여 '보안을 유지하며 AI를 능숙하게 활용하기'를 테마로 한 서비스 검토를 진행하고 있다.

그곳에서 논의하고 있는 것이 바로 이 '입구의 선택'이다.

데이터를 외부로 내보내지 않아도 되는 업무는 로컬 LLM (Local LLM)으로 완결한다.
마스킹을 하면 외부로 내보내도 문제가 없는 업무는 마스크 툴을 경유하여 클라우드 LLM (Cloud LLM)으로 보낸다.
마스킹을 하지 않아도 되는 업무는 클라우드 LLM을 그대로 사용한다.

Claude로 MS365를 사용하는 경우도 마찬가지로, 용도와 기밀도에 따라 입구를 분리하는 설계가 필요하다.

'편리하니까 도입한다'는 식으로는 사고가 발생한다.

Claude Code(CLI) 병용 패턴

마지막으로, 내가 일상적으로 수행하고 있는 하이브리드 운용 방식을 소개한다.

기존의 운용: python-pptx 스크립트 + 수동 수정

PPTX 자료 작성은 Claude Code(CLI)에 python-pptx를 사용하여 스크립트를 작성하게 하여 구조를 한꺼번에 생성했다.

그 후, 세부적인 문구와 레이아웃은 PowerPoint에서 수동으로 수정하는 흐름이었다.

문제는 수정한 후에 '텍스트를 조금 더 변경하고 싶다'고 요청하면, Claude Code가 재생성하면서 수동으로 수정한 부분을 덮어씌워 버리는 사고가 빈번하게 발생했다는 점이다. 부끄럽게도 나도 여러 번 실수를 저질렀다.

새로운 운용: Claude Code + Claude for PowerPoint

앞으로는 다음과 같이 역할을 나눈다.

구조 생성 및 대규모 변경은 Claude Code(CLI)로 한다. 20페이지 분량의 PPTX를 한꺼번에 생성하거나, 모든 슬라이드의 표 형식을 통일하고, 여러 파일을 횡단(git 연동 포함)하여 편집하는 등의 대량 편집은 이 방식이 특기다.

세부적인 편집은 Claude for PowerPoint(애드인)로 한다. '이 슬라이드의 이 부분을 간결하게', '템플릿에 맞춰 레이아웃을 다시 정리해줘'와 같은 대화 기반의 수정은 PowerPoint 내에서 Claude와 대화하며 고치는 편이 더 빠르다.

두 가지를 모두 허브로 사용하는 운용이라면, python-pptx 스크립트의 덮어쓰기 사고도 일어나지 않는다.

단, Claude Code 측의 생성 스크립트와 PowerPoint 측에서 수동 편집한 내용을 일치시키는 운용 규칙은 별도로 필요하다. 나는 몇 번의 시행착오 끝에, 최종적으로 '사용자가 수정하면 Claude 측에서 다시 반영한다'는 흐름으로 정착했다.

요약

Claude와 Microsoft 365를 연결하는 루트는 3가지가 있다. 각각 전송되는 데이터의 경로와 권한 모델이 다르다.

용도	권장 루트
문서 편집 중심	Claude for Microsoft 365 애드인 (Add-in)
...

"편리하니까 설치한다"가 아니라, "어떤 입구를 통해 무엇을 전달할 것인가"를 설계 단계에서 판단해야 한다.

특히 기밀 정보를 다루는 업무에서는 마스킹 도구 (Masking tool)나 로컬 LLM (Local LLM)과의 조합을 포함하여, 용도별로 입구를 분리하는 설계가 필요하다.

AI 에이전트 (AI Agent) 도입이 늘어날수록, 이러한 권한 설계 (Permission design)를 판단할 수 있는 인재가 필요해진다.

이는 공격을 방어하는 계열의 보안 (Security)과는 다른 역할로, AI 시대에 새롭게 요구되는 스킬셋 (Skill set)이라고 생각한다.

채용 업계에 있는 사람의 관점에서도, "AI 도입의 권한 설계를 논할 수 있는 보안 인재"는 명백히 부족하다. 향후 채용 니즈의 중심이 이곳으로 이동할 것이라고 보고 있다.

IT 커리어 · 보안 커리어에 대한 개별 상담은 당사가 운영하는 세코네 커리어 (Secone Career)에서 접수하고 있습니다.