Microsoft Graph의 OAuth 2.0 이해하기: 위임된 권한 vs. 애플리케이션 권한

By Mirko Peters · 2026-08-11 · Updated 2026-08-28

블로그에 다시 오신 것을 환영합니다. Microsoft 365 자동화를 깊이 있게 다뤄 보셨다면 기본 제공 커넥터와 기존 스크립트의 한계에 부딪힌 적이 있으실 겁니다. M365를 자동화할 때는 인증을 구성하는 일이 까다로울 수 있으며, 특히 강력한 보안과 원활한 기능 사이에서 균형을 맞추는 것이 어려운 과제입니다. 사용자 중심 앱을 개발하든 무인 백그라운드 프로세스를 구성하든, 인증 모델을 확실히 이해하는 것은 매우 중요합니다. 이 글에서는 토큰, 범위, 동의 흐름을 살펴보고, 사용자 중심 작업이나 무인 백그라운드 작업에 적합한 모델을 고르는 방법을 설명합니다. 바로 시작해서 OAuth 2.0이 Microsoft Graph API를 어떻게 구동하는지 알아보겠습니다.

Automatically translated with AI from the original post. Read the English original

Titelbild: Demystifying OAuth 2.0 in Microsoft Graph: Delegated vs. Application Permissions

Microsoft Graph 인증 소개

Microsoft Graph는 Microsoft 365 생태계 전체를 연결하는 통합 게이트웨이입니다. Exchange, SharePoint, Teams, Azure Active Directory(현재 Microsoft Entra ID)를 위한 개별적이고 분산된 API와 각각 상호 작용하는 대신, 개발자와 IT 관리자는 단일 엔드포인트를 통해 이 모든 서비스에 액세스할 수 있습니다. 그러나 Graph는 민감한 기업 데이터에 대한 액세스를 제어하므로, 이 게이트웨이를 보호하려면 엄격한 인증 프레임워크가 필요합니다. 아이덴티티, 액세스 토큰, 권한이 어떻게 맞물리는지 이해하는 것이 안정적이고 안전한 자동화를 구축하는 첫걸음입니다. 그래야 자동화가 부하를 견디지 못하고 중단되거나 보안 경고를 유발하는 일을 막을 수 있습니다.

Microsoft 365 환경에서 이해하는 OAuth 2.0

Microsoft Graph는 근본적으로 권한 부여를 위해 OAuth 2.0 프로토콜을 사용합니다. 앱이나 스크립트가 Graph와 통신하려면 자격 증명을 그대로 전송할 수 없습니다. 대신 Microsoft ID 플랫폼(Entra ID)에 액세스 토큰을 요청해야 합니다. 이 액세스 토큰은 안전한 디지털 여권 역할을 합니다. 누가 요청하는지, 어떤 애플리케이션이 사용되는지, 그리고 무엇보다 중요한 것으로 해당 토큰에 어떤 특정 권한(범위)이 부여되었는지를 Microsoft Graph에 알려 줍니다. 유효한 토큰이 없으면 Graph는 표준 비인증 오류와 함께 요청을 즉시 거부합니다.

위임된 권한: 사용자 권한으로 실행해야 할 때

어떤 권한 모델을 선택할지는 작업의 성격에 전적으로 달려 있습니다. 위임된 권한은 로그인한 사용자를 기반으로 실행되는 앱을 위해 설계되었습니다. 애플리케이션이 위임된 권한을 사용하면, 앱은 현재 로그인한 사용자를 대신하여 작동합니다. 사용자가 자신의 캘린더를 읽거나 프로필 사진을 업데이트하는 스크립트를 실행하면, Graph는 해당 앱이 수행할 수 있는 작업뿐 아니라 그 사용자가 액세스할 권한이 있는 항목도 함께 평가하여 요청을 처리합니다. 사용자에게 특정 사서함을 볼 권한이 없다면, 위임된 토큰으로도 그 사서함에 액세스할 수 없습니다. 이 모델은 사용자 대면 애플리케이션, 대화형 도구, 개인 생산성 스크립트에 이상적입니다.

애플리케이션 권한: 무인 백그라운드 작업 구동

반대로, 아무도 키보드 앞에 없는 상태에서 자정에 스크립트나 서비스를 실행해야 하는 경우는 어떨까요? 무인 백그라운드 작업, 데몬 서비스, 테넌트 전체 보고 도구에는 애플리케이션 권한이 필요합니다. 이 모델에서 애플리케이션은 어떤 사용자 컨텍스트와도 독립적으로 작동하며, 자체 아이덴티티로 실행됩니다. 대화형으로 로그인하고 동의를 부여할 사용자가 없으므로, 애플리케이션 권한에는 테넌트 관리자의 명시적인 사전 승인이 필요합니다. 일단 부여되면 앱은 조직 전체의 데이터에 액세스할 수 있으므로, 이 모델은 관리 자동화, 온보딩 스크립트, 규정 준수 모니터링에 매우 강력하지만 엄격한 보안 감독도 함께 요구됩니다.

범위, 토큰, 동의 흐름 살펴보기

인증과 권한 부여 용어는 복잡하게 느껴질 수 있지만, 워크플로를 단계별로 나눠 보면 과정이 명확해집니다. 스코프는 애플리케이션이 요청하는 특정 권한입니다(예: User.Read.All 또는 Mail.Read). 사용자나 관리자가 앱을 승인하면 이들은 이 스코프를 검토하고 승인하는 것입니다. 승인이 끝나면 ID 플랫폼이 JSON Web Token(JWT)을 발급합니다. 코드는 Microsoft Graph로 보내는 모든 요청의 HTTP Authorization 헤더에 이 토큰을 포함합니다. 동의를 올바르게 관리하면 예상치 못한 장애물에 걸리지 않고 앱이 토큰을 원활하게 획득할 수 있습니다.

관리자 동의 대기 상태 피하기

개발자와 관리자가 가장 자주 겪는 어려움 중 하나는 관리자 승인을 기다리며 멈춰 서는 것입니다. 애플리케이션이 고권한 애플리케이션 스코프나 민감한 위임 스코프를 요청하면, Microsoft Entra ID는 토큰을 발급하기 전에 관리자가 애플리케이션에 동의하도록 요구할 수 있습니다. 배포 파이프라인이 사용자가 직접 동의할 수 있다고 가정했는데 테넌트 정책에 막히면 자동화 전체가 멈춥니다. 이런 상황을 피하려면 필요한 권한을 미리 정리하고, 비즈니스상의 근거를 문서화하며, 필요한 경우 전역 관리자나 애플리케이션 관리자와 협력해 테넌트 전체에 대한 동의를 미리 구성해 두어야 합니다.

흔한 함정과 해결 방법

경험이 많은 개발자라도 Microsoft Graph 작업 중 권한 관련 문제에 종종 부딪힙니다. 자주 발생하는 몇 가지 문제와 해결 방법을 살펴보겠습니다.

내 환경에서는 동작하지만 다른 사용자에게는 실패함: 대개 동의가 누락되었거나 스코프가 잘못된 경우에 발생합니다. 해결: 필요한 스코프를 명확히 문서화하고, 적절한 경우 테넌트 전체에 대한 관리자 동의를 구성합니다.
대용량 페이로드 과다 조회: 필터 없이 전체 사용자 목록을 가져오면 시간 초과와 제한이 발생합니다. 해결: $select, $top, 페이징, 델타 쿼리를 사용합니다.
끝없는 401/403 반복: 만료된 토큰을 사용하거나, 사용자가 없는 작업에 위임 권한 유형을 사용하기 때문에 발생합니다. 해결: 견고한 토큰 갱신을 구현하고, 백그라운드 작업에는 애플리케이션 권한으로 전환합니다.
속도 제한에 도달: 429 응답은 요청을 너무 빠르게 보내고 있다는 뜻입니다. 해결: 지수 백오프를 구현하고, Retry-After 헤더를 준수하며, 작업을 일괄 처리합니다.
시크릿 난립: 스크립트에 클라이언트 시크릿을 하드코딩하는 것은 심각한 보안 위험입니다. 해결: Azure Key Vault, 관리 ID 또는 안전한 환경 변수를 활용합니다.

보안 및 거버넌스 모범 사례

API를 통해 Microsoft 365 테넌트의 문을 여는 순간부터 보안이 최우선이어야 합니다. 최소 권한 원칙에 따라 애플리케이션이 작동하는 데 꼭 필요한 최소한의 스코프만 요청해야 합니다. 사용자의 표시 이름 하나를 읽기 위해 Directory.AccessAsUser.All을 요청해서는 안 됩니다. 테넌트에 접근할 수 있는 앱을 명확히 기록한 동의 원장을 유지하고, 개발, 테스트, 운영 애플리케이션 등록을 완전히 분리하며, 클라이언트 시크릿과 인증서를 정기적으로 교체하는 엄격한 일정을 수립해야 합니다.

첫 실전 쿼리 (예제)

인증 모델이 정리되었다면 Graph API에 대한 쿼리를 실행할 수 있습니다. 필요에 맞게 수정해 사용할 수 있는 실용적인 예제는 다음과 같습니다.

특정 날짜 이후 입사자:
GET /users?$filter=createdDateTime ge 2025-10-01T00:00:00Z&$select=id,displayName,mail,department
내 다음 모임 일정:
GET /me/events?$top=10&$select=subject,start,end,organizer,webLink
그룹의 구성원:
GET /groups/{group-id}/members?$select=id,displayName,mail
변경된 사용자(델타):
GET /users/delta?$select=id,displayName,mail

권장 도구

적절한 도구를 활용하면 Microsoft Graph 쿼리를 작성하고 디버깅하는 작업이 훨씬 쉬워집니다. Graph Explorer는 엔드포인트를 테스트하고 동의 힌트를 확인할 수 있는 매우 유용한 웹 기반 실습 도구입니다. 코드를 작성할 때는 Microsoft Graph SDK(.NET, JavaScript, Python)가 기본 HTTP 처리 과정의 상당 부분을 추상화해 줍니다. IDE의 Postman 또는 REST Client 확장 프로그램은 컬렉션과 환경을 관리하는 데 훌륭하며, Power Automate, Logic Apps, PowerShell은 시각적 워크플로와 운영 워크플로 자동화를 탁월하게 처리합니다.

자주 묻는 질문

위임 권한 vs. 애플리케이션 권한, 어떻게 선택하나요?

사용자 중심 작업에는 위임된 권한(Delegated permissions)이 가장 적합합니다. 무인 작업, 백그라운드 데몬, 광범위한 관리 작업에는 적절한 관리자 동의와 함께 애플리케이션 권한(Application permissions)이 필요합니다.

제한(스로틀링)은 어떻게 피하나요?

$select를 사용해 페이로드 크기를 줄이고, 페이징과 델타 쿼리를 구현하며, 가능한 경우 요청을 일괄 처리하세요. 또한 스크립트는 항상 429 상태 코드를 적절히 처리하도록 재시도 로직을 포함해 작성하세요.

코딩 없이도 Graph를 사용할 수 있나요?

네, 가능합니다. Graph Explorer에서 엔드포인트를 시험해 볼 수 있고, Power Automate로 워크플로를 구성할 수 있습니다. 복잡한 로직이 필요하면 공식 SDK나 PowerShell 스크립트로 전환하세요.

Graph는 컴플라이언스 보고서에 충분히 안전한가요?

물론입니다. 최소 권한 원칙, 중앙 집중식 로깅, 감사 가능한 동의 흐름, 안전한 비밀 관리를 적용하면 Microsoft Graph는 엄격한 엔터프라이즈 컴플라이언스 기준을 충족합니다.

결론

Microsoft Graph의 인증을 숙달하는 것은 Microsoft 365의 잠재력을 제대로 활용하려는 모든 관리자, 아키텍트, 개발자에게 핵심적인 열쇠입니다. 위임된 권한과 애플리케이션 권한의 중요한 차이를 이해하고, 범위(스코프)와 토큰을 신중하게 관리하며, 엄격한 보안 거버넌스를 따르면 강력하면서도 안전한 자동화를 구축할 수 있습니다. 이 주제를 더 깊이 살펴보고, 코드 샘플을 탐색하고, 오류 처리와 스로틀링에 대한 고급 전략을 배우려면 관련 팟캐스트 에피소드를 꼭 확인하세요: Automate Microsoft 365 with Microsoft Graph API. 즐거운 자동화 되세요!