위임된 권한과 애플리케이션 권한: 앱에 맞는 모델 선택하기

By Mirko Peters · 2026-08-11

팟캐스트와 Microsoft 365, Azure 및 현대 클라우드 생태계를 뒷받침하는 개발자 도구를 다루는 시리즈에 다시 오신 것을 환영합니다. Microsoft Graph API를 사용해 통합을 구축하거나, 스크립트를 작성하거나, 엔터프라이즈 자동화를 배포해 본 적이 있다면 권한의 벽에 부딪혀 본 적이 있을 것입니다. 테넌트를 보호하면서 기능이 동작하는 애플리케이션을 만드는 일은 관리자나 개발자가 마주하는 가장 중요한 균형 작업 중 하나입니다. 어떤 권한 모델을 선택하느냐에 따라 보안 태세, 배포 속도, 그리고 전체 시스템 아키텍처가 직접적인 영향을 받습니다.

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

Titelbild: Delegated vs. Application Permissions: Choosing the Right Model for Your App

이 주제를 더 자세히 살펴보기 위해 최근 심층 에피소드를 녹음했습니다. Microsoft Graph Permissions and Consent Models Explained에서 전체 오디오 대담을 꼭 확인해 보십시오. 이 블로그 글에서는 해당 개념을 확장하여 위임된 권한과 애플리케이션 권한의 핵심 차이, 동의 모델, 모범 사례를 살펴보고, 앱을 안전하고 규정을 준수하는 상태로 유지하기 위한 포괄적인 프레임워크를 제시하겠습니다.

Microsoft Graph API 권한 개요

특정 권한 부여 흐름의 세부 사항으로 들어가기 전에, Microsoft Graph API 권한이 실제로 무엇인지 이해하는 것이 도움이 됩니다. Microsoft Graph는 본질적으로 Exchange Online, SharePoint, Microsoft Teams, OneDrive, Azure Active Directory(Microsoft Entra ID)를 포함한 Microsoft 365 서비스 전반에 있는 데이터에 접근하는 통합 게이트웨이 역할을 합니다. 개발자가 여러 개의 분리된 엔드포인트에 각각 인증하도록 하는 대신, Microsoft Graph는 단일 REST API 엔드포인트를 제공합니다. 다만 이 API는 조직의 디지털 자산 거의 모든 영역에 대한 접근 권한을 열어 주므로, 이를 안전하게 보호하려면 견고하고 세분화된 권한 프레임워크가 필요합니다.

위임된 권한과 애플리케이션 권한 비교

Microsoft 아이덴티티 플랫폼에 애플리케이션을 등록할 때는 앱이 리소스와 어떻게 상호 작용할지를 명시적으로 선언해야 합니다. 이는 근본적으로 두 가지 기본 권한 유형, 즉 위임된 권한과 애플리케이션 권한 중 하나를 선택하는 것으로 귀결됩니다. 이 선택에 따라 애플리케이션의 인증 방식, 누구 또는 무엇을 대표하는지, 그리고 앱이 검색할 수 있는 데이터의 범위가 결정됩니다.

위임된 권한은 로그인한 사용자가 실제로 함께 있는 클라이언트 측 또는 사용자 대면 애플리케이션, 예를 들어 단일 페이지 웹 앱, 모바일 앱, 데스크톱 유틸리티를 위해 설계되었습니다. 이 모델에서 앱은 사용자를 *대신하여* 동작합니다. 애플리케이션은 해당 사용자가 직접 수행할 권한이 있는 데이터에만 접근하고 작업을 수행할 수 있습니다. 사용자가 앱을 실행하면 로그인하고 명시적으로 동의하라는 메시지가 표시되며, 이때 사용자의 ID와 동의된 범위(scope)를 모두 포함한 OAuth 2.0 액세스 토큰이 발급됩니다.

반면 애플리케이션 권한은 사용자 컨텍스트와 무관하게 독립적으로 동작하는 백그라운드 서비스, 데몬, 웹 작업, 자동화된 런북에서 사용합니다. 여기서 앱은 자체 ID로 실행됩니다. 클라이언트 비밀, 공개/개인 인증서 키 쌍, 또는 관리 ID 같은 클라이언트 자격 증명을 사용하여 Azure AD에서 앱 전용 액세스 토큰을 얻습니다. 인증을 위해 키보드 앞에 앉아 있는 사용자가 없으므로, 이러한 권한은 테넌트 전체 리소스에 걸쳐 적용됩니다. 따라서 보안 위험이 훨씬 높으며, 항상 테넌트 관리자의 명시적 동의가 필요합니다.

주요 차이점과 사용 사례

각 권한 모델을 언제 적용해야 하는지 이해하면 아키텍처 병목과 보안 취약점을 예방할 수 있습니다. 간단한 비교표를 살펴보겠습니다.

위임된 권한: 앱이 사용자를 대신하여 작동합니다. 사용자가 로그인하고 동의해야 합니다. 앱은 사용자가 볼 수 있는 항목만 볼 수 있습니다. 이 모델은 개인 캘린더나 이메일처럼 개인 데이터를 읽거나 쓰는 클라이언트 앱에 적합합니다.
애플리케이션 권한: 앱이 자체적으로 작동합니다. 사용자가 로그인할 필요가 없습니다. 관리자가 동의해야 합니다. 앱은 테넌트 전체의 데이터를 보고 수정할 수 있습니다. 이 모델은 백그라운드 동기화, 관리 보고, 자동화된 거버넌스 작업에 적합합니다.

올바른 모델을 선택하는 것은 전적으로 애플리케이션의 아키텍처에 달려 있습니다. 예를 들어 사용자의 프로필과 개인 받은 편지함을 표시하는 대화형 대시보드를 만든다면 위임된 권한을 사용해야 합니다. 반대로 규정 준수 감사를 위해 매일 자정에 조직 내 모든 사서함을 검사하는 자동화 스크립트를 개발한다면 애플리케이션 권한이 필요합니다.

Microsoft Graph의 위임된 권한

위임된 권한의 작동 방식

위임된 액세스는 사용자 ID와 밀접하게 연결되어 있습니다. 애플리케이션이 위임된 권한을 요청하면, 이는 본질적으로 정의된 범위 내에서 로그인한 사용자를 대신하는 권한을 인증 서버에 요청하는 것입니다. OAuth 권한 부여 코드 흐름을 통해 반환된 액세스 토큰에는 사용자가 본래 가진 권한과 애플리케이션이 요청한 권한을 모두 반영하는 특정 범위 클레임이 포함됩니다.

위임된 액세스는 앱이 사용자 본인으로서 직접 동작한다는 뜻입니다.
애플리케이션 등록과 개별 사용자 모두 적절한 기본 권한을 가지고 있어야 합니다.
범위는 앱이 사용자를 대신하여 수행할 수 있는 작업의 정확한 상한선을 정의합니다.
결과로 생성된 액세스 토큰은 애플리케이션 ID와 사용자 컨텍스트를 함께 묶습니다.

위임된 권한의 일반적인 시나리오

위임된 권한은 일상적인 생산성 통합 대부분을 뒷받침합니다. 예를 들어 기업용 메모 앱이 사용자의 OneDrive 계정에 파일을 동기화해야 한다면 Files.ReadWrite 범위를 요청합니다. 사용자에게 특정 문서에 접근할 권한이 없으면, 앱의 범위가 기술적으로 허용하더라도 Graph API는 요청을 거부합니다. 마찬가지로 Microsoft Graph SDK를 사용해 사용자를 대신하여 자동 이메일 알림을 보내는 앱은 Mail.Send와 같은 위임된 범위를 활용합니다.

보안 및 동의 고려 사항

위임된 권한은 사용자의 제약을 받기 때문에 테넌트 전체 대상의 애플리케이션 권한보다 본질적으로 안전하지만, 여전히 고유한 보안 문제를 안고 있습니다. 사용자 사서함 전체와 디렉터리 프로필에 대한 전체 액세스처럼 지나치게 광범위한 범위를 애플리케이션이 요청하면, 성공한 피싱 공격이나 앱 침해로 민감한 개인 데이터가 노출될 수 있습니다. 개발자는 최소 권한 원칙을 엄격히 준수하여, 당장의 기능에 필요한 특정 범위만 요청해야 합니다.

Microsoft Graph의 애플리케이션 권한

애플리케이션 권한의 작동 방식

애플리케이션 권한은 인증 과정에서 사람의 요소를 완전히 제거합니다. 로그인 창과 상호 작용하는 대신, 애플리케이션이 클라이언트 자격 증명을 사용해 Microsoft Entra ID로 직접 인증합니다. 결과 토큰에는 위임된 범위가 아니라 앱 역할이 포함되며, 이를 통해 서비스 프린시펄은 테넌트 전체 리소스에 대한 광범위하고 제약 없는 액세스 권한을 얻습니다.

애플리케이션 권한은 로그인한 사용자 없이 전적으로 작동합니다.
애플리케이션은 리소스를 조회하기 위해 앱 전용 토큰을 획득합니다.
액세스는 개별 사용자 권한이 아니라 서비스 프린시펄에 할당된 앱 역할에 의해 관리됩니다.

애플리케이션 권한을 사용해야 하는 경우

애플리케이션 권한은 백엔드 워크로드, 사용자 상주 없이 실행되는 데몬, 시스템 간 통합에만 엄격히 제한해야 합니다. 예로는 자동 사용자 프로비저닝 엔진, 중앙 집중식 백업 시스템, 보안 사고 대응 도구, 테넌트 마이그레이션 스크립트 등이 있습니다.

관리자 동의 및 보안 영향

애플리케이션 권한은 개별 사용자의 제약을 우회하고 테넌트 전체에 대한 액세스를 부여하므로, 일반 사용자는 이에 동의할 수 없습니다. 애플리케이션 권한에 대한 동의는 권한이 있는 관리자만 부여할 수 있습니다. Directory.ReadWrite.All 또는 Mail.ReadWrite.All을 신뢰할 수 없거나 코드 품질이 낮은 백그라운드 앱에 잘못 부여하면, Microsoft 365 테넌트 전체가 완전히 침해될 위험에 노출될 수 있습니다. 엔터프라이즈 애플리케이션 서비스 프린시펄을 항상 정기적으로 감사하십시오.

Microsoft Graph API 권한의 장단점

장점

통합 권한 모델: 모든 Microsoft 365 서비스에 걸쳐 단일하고 일관된 권한 부여 프레임워크를 제공하여 관리를 단순화합니다.
세분화된 범위: 세밀한 위임 및 애플리케이션 범위를 통해 정확한 최소 권한 아키텍처를 구현할 수 있습니다.
표준 OAuth2/OpenID Connect: 업계 표준 보안 프로토콜을 활용하여 간편한 ID 통합을 지원합니다.
RBAC 통합: Azure AD 역할 및 조건부 액세스 정책과 원활하게 연동되어 중앙 집중식 규정 준수를 지원합니다.
점진적 동의: 앱이 모든 권한을 처음부터 요구하지 않고, 시간이 지나면서 필요한 추가 권한을 요청할 수 있습니다.

단점

복잡성: 위임된 범위, 앱 역할, 관리자 동의 모델이 서로 얽혀 있어 처음 접하는 사람은 혼란을 느낄 수 있습니다.
높은 권한의 위험: Sites.FullControl.All과 같은 광범위한 권한을 잘못 구성하면 방대한 양의 기업 데이터가 노출될 수 있습니다.
관리자 동의 병목: 영향도가 큰 권한에 관리자 승인을 요구하면 빠른 개발 주기가 늦어질 수 있습니다.
문서 분산: 개발자는 정확한 API 동작을 파악하기 위해 여러 Microsoft 문서 저장소를 교차 확인해야 하는 경우가 많습니다.

동의 모델과 모범 사례

Microsoft Graph에서의 사용자 동의와 관리자 동의

동의를 어떻게 받는지 관리하는 것은 조직의 거버넌스에서 매우 중요합니다. 사용자 동의는 개인이 앱에 자신의 개인 데이터 접근을 허용할 수 있게 합니다. 관리자 동의는 승인 절차를 IT 관리자에게 넘기며, 관리자가 조직 전체를 대신해 앱 요청을 검토합니다. 최근의 엔터프라이즈 보안 기준선에서는 사용자 동의를 아예 비활성화하고, 모든 앱 도입을 공식적인 관리자 사전 승인 절차를 거치도록 하는 경우가 많습니다.

테넌트 정책이 권한에 미치는 영향

엔터프라이즈 테넌트 정책은 런타임에 앱의 동작 방식을 근본적으로 바꿀 수 있습니다. 관리자가 다중 인증(MFA)이나 규정을 준수하는 하이브리드 Azure AD 가입 디바이스를 요구하는 것과 같은 엄격한 조건부 액세스 정책을 적용했다면, 이 조건을 충족하지 않은 상태에서 Graph 토큰을 가져오려는 앱은 차단됩니다. 개발자는 토큰 획득 실패를 원활하게 처리하고, 명확한 오류 해결 단계를 제공하도록 앱을 설계해야 합니다.

원활한 동의 흐름을 위한 전략

사용자 불편과 관리상의 병목을 막으려면 코드를 작성하기 전에 권한 전략을 먼저 계획하십시오. 기본 ID 범위는 처음에 요청하고, 사용자가 특정 기능으로 이동할 때에만 전문적인 리소스 권한을 요청하는 점진적 동의 패턴을 구현하십시오. 또한 Microsoft Entra ID의 자동 사전 승인 워크플로를 활용하면 엄격한 보안 감독을 유지하면서도 개발을 효율적으로 진행할 수 있습니다.

Microsoft Graph API 권한에 관해 흔히 저지르는 실수

위임 권한과 애플리케이션 권한을 혼동하고 사용자 컨텍스트 요구 사항을 잘못 이해하는 경우.
최소 권한 원칙을 따르지 않고 처음부터 과도한 권한을 요청하는 경우.
백그라운드 서비스를 배포할 때 관리자 동의 요구 사항을 고려하지 않는 경우.
Azure Portal에서 권한을 변경한 뒤 토큰을 갱신하지 않아도 즉시 적용된다고 가정하는 경우.
클라이언트 자격 증명 토큰이 필요한 상황에서 위임된 액세스 토큰을 제시하는 경우.
런타임에 Graph API 요청을 차단하는 조건부 액세스 정책을 무시하는 경우.
런타임에 애플리케이션 코드에서 범위 클레임을 검증하지 않는 경우.
시간이 지나도 부여된 애플리케이션 권한과 서비스 주체를 감사하지 않는 경우.

Microsoft Graph API 권한 체크리스트

아래 실행 가능한 체크리스트를 참고하여 팀이 Microsoft Graph API 권한을 안전하게 설계, 구현, 감사하도록 이끌어 보십시오.

결론

Microsoft Graph API 권한을 이해하는 일이 좌절의 연속일 필요는 없습니다. 로그인한 사용자가 있어야 하고 사용자 권한 범위 안에서 동작하는 위임 권한과, 백그라운드에서 제약 없이 실행되며 관리자 동의가 필요한 애플리케이션 권한의 운영상 차이를 명확히 이해하면, 안전하고 확장 가능한 솔루션을 설계할 수 있습니다. 최소 권한 원칙을 따르고, 엄격한 감사를 수행하며, 엔터프라이즈 거버넌스 도구를 활용하면 혁신을 늦추지 않으면서도 Microsoft 365 환경을 안전하게 지킬 수 있습니다.

더 많은 전문가 가이드, 실제 전략, 클라우드 환경 보안에 대한 심층 분석은 관련 에피소드의 전체 오디오 해설을 들어 보십시오: Microsoft Graph Permissions and Consent Models Explained. 권한은 엄격하게, 자격 증명은 안전하게, 그리고 즐거운 코딩 되십시오!