필요한 기능이 Copilot에 존재하더라도 귀하의 조직에는 접근이 불가능할 수 있습니다. 이는 해당 기능이 다른 라이선스 범위(licensing contour)에 속해 있기 때문입니다. 이것은 오류나 지역적 제한이 아니라 제품 라인업의 구조적 특징입니다. Microsoft라는 하나의 이름 아래 여러 가지 서로 다른 제품이 존재하며, 그중 하나를 사용할 권한이 인접한 다른 제품으로 전이되지 않습니다.

IT 관리자에게 이는 구체적인 재무적 리스크입니다. Copilot 시연에서는 SharePoint의 문서를 읽고 그에 대해 답변합니다. 이 기능을 파일럿 계획에 포함하고 "Copilot"이라는 이름의 라이선스를 구매했지만, 첫 번째 API 요청에서 권한 거부 응답을 받게 됩니다. 예산은 소진되었고, 파일럿 기간은 끝났으며, 구매한 서비스 범위가 적절하지 않았기 때문에 필요한 시나리오는 결국 실행되지 못합니다.

이 분석의 입장은 간단합니다. 제품 이름만 보고 구매를 시작해서는 안 됩니다. 먼저 구체적인 작업(task)을 특정 API 인터페이스(surface) 및 이를 실제로 활성화하는 라이선스와 대조한 후에 결제해야 합니다.

만약 작업이 Microsoft 환경 내의 기업 자동화보다 단순하고, 조직이 단순히 루블화로 결제 가능한 하나의 API를 통해 모델에 접근하기를 원한다면, 이는 Copilot 라이선스와는 별개의 문제입니다. 이후의 내용은 접근 권한이 코드뿐만 아니라 사용 권한에 의해서도 결정되는 Microsoft 환경에 관한 것입니다.

Microsoft가 "Copilot"이라는 단어로 여섯 가지 서로 다른 제품을 부르는 이유

Microsoft는 공식적으로 Copilot 브랜드 아래 최소 6개의 별도 제품을 구분하고 있으며, 각 제품은 고유한 라이선스 소유자와 목적을 가집니다. Microsoft Learn의 제품 선택 페이지(2026년 7월 15일 업데이트 기준)는 다음과 같은 제품들을 나열합니다: Microsoft 365 Copilot Chat (적절한 구독에 포함됨, 웹 채팅 및 워크 채팅), 유료 애드온(add-on)인 Microsoft 365 Copilot (애플리케이션 내 내장 기능 및 에이전트), 소비자용 Microsoft Copilot (무료, 개인용), Microsoft Security Copilot (보안 서비스를 위해 별도 라이선스 필요), GitHub Copilot (개발자용 별도 제품), 그리고 Microsoft Copilot Studio (별도의 로우코드(low-code) 에이전트 구축 도구).

문서는 이를 명확히 기록하고 있습니다: 이 라이선스들 중 어느 것도 다른 라이선스를 대체하지 않습니다. 조직이 세 가지 Copilot 제품을 보유하고 있더라도, 파일럿(pilot)을 시작했던 네 번째 시나리오를 실행할 권한이 없을 수 있습니다.

'Copilot'이라는 단어는 라이선스 범위를 넘어 과도하게 사용되고 있습니다. 두 가지 실제 검색어를 예로 들어보겠습니다: 'microsoft copilot api'는 개발자용 인터페이스인 Graph로 연결되지만, 'microsoft surface pro 12 copilot pc 태블릿'은 NPU(신경망 처리 장치)와 로컬 기능을 갖춘 장치 클래스로 연결됩니다 (Copilot+ PC라는 용어 자체는 소프트웨어 권한이 아닌 하드웨어를 의미합니다). 두 검색어 모두 'Copilot'이라는 단어를 포함하고 있지만, 그 사이에는 라이선스 측면의 연결 고리가 없습니다. 즉, 태블릿을 구매한다고 해서 API에 대한 접근 권한이 생기는 것이 아니며, API 라이선스를 보유하고 있다고 해서 해당 장치의 기능을 사용할 수 있는 것도 아닙니다.

여기서 Microsoft의 경고가 아닌, 실무적인 검증 규칙이 도출됩니다: 단순히 시연에서 마음에 드는 기능을 보았을 때 구매하는 것이 아니라, 수행할 작업과 라이선스를 대조한 후에 구매해야 합니다. 이 오류는 특히 API에서 가장 큰 비용을 초래하므로, 검증은 API부터 시작하는 것이 좋습니다.

Microsoft 365 Copilot API 라이선스가 실제로 허용하는 것

Microsoft 365 Copilot API 제품군(Retrieval API, Search API, Chat API, Interaction Export API, Meeting Insights API, 사용 보고서 등)은 graph.microsoft.com/v1.0/copilot 및 .../beta/copilot 주소에 위치합니다. Microsoft Learn의 Copilot APIs 개요 페이지(2026년 7월 2일 업데이트 기준)에 따르면, API를 통한 접근에는 사용자당 Microsoft 365 Copilot 애드온(add-on)이 필요하며, 데이터의 기반으로서 그 하위에는 Microsoft 365 E3 또는 E5 수준의 기본 구독이 있어야 합니다. 이를 위해 표준 Microsoft Graph 라이선스만으로는 충분하지 않습니다.

이것이 바로 전형적인 계획상의 오류입니다. 엔드포인트(Endpoint)가 시각적으로 Graph 제품군에 속해 있고, 개발자들은 Graph가 표준 권한으로 열린다는 점에 익숙하기 때문에 이미 보유하고 있는 라이선스를 기준으로 통합을 설계합니다. Microsoft는 이를 명시적으로 구분하고 있습니다. Graph API는 표준 Microsoft 365 라이선스 조건으로 사용할 수 있지만, Copilot API는 Microsoft 365 Copilot 라이선스를 요구합니다. 동일한 엔드포인트 제품군이라도 요청이 AI 추론(Copilot)을 호출하는지, 아니면 일반적인 데이터 CRUD(Create, Read, Update, Delete) 액세스(Graph)를 호출하는지에 따라 두 가지 요금제로 분리됩니다.

일부 관리자들이 기대하는 우회 방법도 별도로 차단되어 있습니다. 2026년 7월 2일자 문서 개정본에 따르면, Copilot API는 Microsoft 365 Copilot 라이선스를 가진 사용자에게는 추가 비용 없이 제공되지만, 해당 라이선스가 없는 사용자에 대한 지원은 현재 불가능합니다. 애드온(Add-on) 없이 API를 열어줄 수 있는 종량제(Pay-as-you-go) 모델은 문서에 명시되어 있지 않습니다.

형식적으로는 "구독에 포함되어" 있는 Copilot Chat 무료 계층을 완전한 액세스와 혼동하는 경우가 가장 빈번합니다. 라이선스 페이지와 가격표를 보면, 이는 웹 채팅과 Graph에 연결된 워크(Work) 채팅에 대한 선택적 종량제(Pay-as-you-go) 액세스를 제공하지만, Word, Excel, Outlook, Teams 내의 내장된 Copilot 기능이나 Copilot API에 대한 액세스는 포함하지 않습니다. 내장 기능과 API 모두 유료 애드온(Add-on)으로 제한되어 있습니다. 동일한 엔드포인트라도 두 가지 다른 권한 수준을 가집니다. Copilot이 SharePoint를 읽는 데모를 보여준다고 해서, 귀하의 조직을 통한 동일한 호출이 API를 통해 열릴지는 알 수 없습니다.

"작업-접점-라이선스-제한" 매트릭스의 모습

Copilot 제품 카드를 이름만으로 평가해서는 안 됩니다. 이를 네 가지 질문으로 분해해야 합니다: 무엇을 해야 하는가, 어떤 접점(Surface)을 통해 수행되는가, 어떤 라이선스가 이를 활성화하는가, 그리고 라이선스가 있더라도 남아있는 제한 사항은 무엇인가. 아래 매트릭스는 Microsoft Learn의 공식 페이지를 바탕으로 작성되었습니다. 이는 매칭 방법론이며, 특정 테넌트(Tenant)의 권한을 선언하는 것이 아닙니다.

구매 결정은 첫 번째 열이 아닌 행 전체를 기준으로 내려져야 합니다. 만약 해당 행이 조직이 보유하고 있거나 구매할 예정인 라이선스와 필요한 시나리오를 연결하지 못한다면, 구매를 시작하기에는 아직 이릅니다.

Copilot Studio는 그 이중 라이선스 구조 때문에 별도의 설명이 필요합니다. Copilot Studio 요구 사항 페이지(2026년 5월 5일 업데이트)에 따르면, Microsoft 365 Copilot과는 별도로 구매해야 하는 두 가지 라이선스가 필요합니다: 테넌트 라이선스(Tenant License) 형태의 Copilot Studio(조직이 한 번 구매하며 특정 사용자에게 할당하지 않음)와 에이전트를 구축하는 각 개인을 위한 Copilot Studio User 라이선스입니다. 반면, 이미 게시된 에이전트와 단순히 대화하는 사용자에게는 Studio 라이선스가 전혀 필요하지 않으며, Teams, SharePoint 또는 웹사이트와 같은 게시 채널에 대한 액세스 권한만 있으면 됩니다.

여기서 Microsoft 생태계 외부의 다른 비교 대상도 언급할 가치가 있습니다. 러시아 개발자들은 이 매트릭스를 보며 M365에 내장된 자동화가 아니라, 단일 키를 통한 모델에 대한 예측 가능한 접근 방식을 찾는 경우가 있습니다. 이는 동일한 표의 행이 아니라 선택의 또 다른 축입니다. provod.ai (OpenRouter의 러시아 대안)는 이런 의미에서 Microsoft Copilot 라이선스가 아니라, 키와 base_url 변경을 통해 OpenAI 및 Anthropic SDK와 프로토콜 호환이 가능한 별도의 루블화 API 경로로 비교되어야 합니다. 이 두 가지 문제를 구분하는 것은, 단순한 API 경로만으로 충분한 곳에서 Copilot 라이선스를 구매하거나 그 반대의 상황이 발생하는 것을 방지하기 위해 매우 유용합니다.

라이선스 외에 비용이 누수되는 지점

라이선스를 올바르게 구매했더라도 간과하기 쉬운 두 번째 비용 계층이 존재합니다. 바로 소모되는 Copilot Credit (Copilot 크레딧)과 에이전트 호스팅 (hosting) 비용입니다. 이 계층 때문에 비용 표의 "무료"라는 표현은 조건부일 뿐입니다.

공식적인 비용 고려 사항 (cost considerations) 매트릭스(2026년 7월 2일 업데이트 기준)에 따르면, 비용은 에이전트의 유형과 호출하는 사용자의 라이선스에 따라 달라집니다. 선언적 에이전트 (Declarative agents)는 M365 Copilot 애드온 (add-on) 또는 Copilot Chat에 대한 액세스가 필요하지만, Copilot Credit에 따른 과금은 에이전트가 테넌트 (tenant)의 공용 데이터인 SharePoint 또는 Copilot 커넥터 (connectors)에 접근할 때만 발생합니다. 자체 엔진 (custom engine) 기반의 에이전트는 Copilot 라이선스 액세스를 요구하지 않지만, 에이전트가 테넌트의 공용 데이터에 접근할 수 있다면 권한이 없는 사용자라 할지라도 Copilot Credit 과금을 발생시킬 수 있습니다. 호스팅 (Azure AI Foundry, Azure App Service, Azure Bot Service 또는 Copilot Studio 및 Power Platform 플랜)은 모든 M365 Copilot 라이선스와 별개의 독립적인 비용 항목으로 발생합니다.

여기서 예산 계획 시 가장 흔히 실수하게 되는 기본 설정에 대한 중요한 주의 사항이 도출됩니다. "추가 비용 없음"이라는 문구는 에이전트가 테넌트의 공용 데이터에 접근하지 않을 때만 유효합니다. 일단 SharePoint나 Copilot 커넥터를 통해 데이터에 접근하게 되면, 라이선스 요금제 수준과 관계없이 Copilot Credit 과금이 시작됩니다.

예산을 위한 실질적인 결론은 다음과 같습니다. 에이전트 유형, 호출 사용자의 라이선스, 공용 데이터 접근 여부, 그리고 호스팅 비용은 네 가지의 독립적인 비용 승수 (multipliers)입니다. 라이선스는 이 중 첫 번째 요소만을 해결합니다. 이 네 가지를 모두 계산해야 하며, 그렇지 않으면 최종 구매 금액이 과소 산정될 수 있습니다.

구매 후가 아닌 구매 전 권한을 확인하는 방법

라이선스 명칭만으로 논쟁하는 것은 무의미합니다. 특정 계정의 실제 권한을 확인해야 합니다. Microsoft는 이를 위해 공식 도구를 제공합니다. Microsoft Learn의 라이선스 페이지를 통해 관리자는 포털이나 프로그래밍 방식으로 Copilot License Details (aka.ms/CopilotLicenseDetails) 진단 도구를 사용하여 특정 사용자에게 Copilot 기능에 필요한 권한이 있는지 확인할 수 있습니다. Microsoft는 배포 전에 라이선스 준수 여부와 기능을 확인하기 위해 이 도구 사용을 권장합니다.

예산과 파일럿(Pilot) 기간을 절약하는 단계별 절차:

1. 브랜드가 아닌 기능적 관점에서 과제를 정의합니다: "Copilot이 필요합니다"가 아니라 "AI 랭킹(AI-ranking) 기능이 포함된 Retrieval API를 통해 SharePoint를 읽어야 합니다"라고 정의해야 합니다.
2. 위의 매트릭스에서 필요한 행을 찾아 라이선스와 그 제한 사항을 기록합니다.
3. aka.ms/CopilotLicenseDetails를 통해 테스트 계정의 실제 권한을 확인하고 이를 해당 행과 대조합니다.
4. 시나리오가 테넌트(Tenant)의 공통 데이터를 다루는 경우, Copilot Credit과 커스텀 엔진(Custom engine) 기반 에이전트의 호스팅 비용을 계산에 포함합니다.
5. 과제, 라이선스, 그리고 확인된 권한이 모두 일치할 때만 파일럿과 구매를 시작합니다.

요청 형식을 터미널에서도 확인할 수 있습니다. 다음은 Copilot API 호출을 보여주는 예시이며, 실제 비밀 키(Secret)를 사용한 작동 예시는 아닙니다:

# Copilot API 호출 형식 예시 (Microsoft 365 Copilot)
curl -X POST "https://graph.microsoft.com/v1.0/copilot/retrieval" \
  -H "Authorization: Bearer <token>" \
...

이러한 형식에서 발생하는 403 거부(Forbidden) 오류는 통합(Integration)의 결함이 아니라 라이선스 경계의 응답입니다. 즉, 코드는 정상이나 권한이 없다는 뜻입니다. 이 두 가지 사례를 구분하는 것이 이 단계에서 관리자가 수행해야 할 핵심 업무입니다.