맞춤형 인증과 UX 직접 구현이 M365 앱의 컴플라이언스를 깨뜨리는 이유

By Mirko Peters · 2026-08-11

팟캐스트 블로그에 다시 오신 것을 환영합니다! 맞춤형 OAuth 흐름과 씨름하며 몇 주를 보내거나, 원인을 알 수 없는 토큰 만료 오류를 디버깅하거나, 자체 CSS로 Microsoft의 디자인과 느낌을 맞추느라 고생해 본 적이 있다면, 여러분만 그런 것이 아닙니다. Microsoft 365와 연동되는 최신 애플리케이션을 만드는 일은 쉽게 엄청난 엔지니어링 부담으로 번질 수 있습니다. 많은 개발 팀이 직접 만든 방식이 완전한 통제권을 준다는 좋은 의도로 시작하지만, 결국 감사 공백, 사용자 불신, 과중한 보안 부담에 파묻히게 됩니다. 이번 글에서는 인증과 사용자 경험 계층을 처음부터 직접 구현하는 것이 왜 컴플라이언스 함정인지 깊이 살펴보고, 기술 스택을 현대화하는 방법을 소개하겠습니다.

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

Titelbild: Why DIY Auth and UX Break Compliance in M365 Apps

이 글은 최신 팟캐스트 에피소드 Build Consistent M365 Apps with Microsoft Graph Toolkit의 내용을 더 자세히 다룹니다. 이 글을 읽은 뒤 전체 에피소드를 들으면 이 개념들을 오디오로 함께 따라갈 수 있습니다!

개요

대부분의 M365 앱은 인증, 디렉터리 검색, 캘린더 UX에서 무너지며, 이 과정에서 Microsoft 브랜드와도 어긋나 보입니다. Microsoft Graph Toolkit은 Graph에 연결되고 토큰과 동의를 처리하는, 지속적으로 관리되는 Microsoft 브랜드 React 컴포넌트를 제공합니다. 별도 설정 없이도 신뢰할 수 있고 컴플라이언스를 충족하는 경험을 제공하며, 필요한 부분은 안전하게 커스터마이즈할 수 있습니다.

이 글이 도움이 되는 대상

Microsoft 365와 연동되는 앱을 만드는 프런트엔드 개발자 및 기술 리드
빠르고 컴플라이언스를 충족하는 인증과 디렉터리 기능이 필요한 제품 팀
위험한 맞춤형 OAuth와 UI 불일치에 지친 보안 및 컴플라이언스 담당자

직접 구현하면 생기는 문제 (그리고 컴플라이언스 위험)

개발자가 인증과 디렉터리 검색 기능을 직접 만들기로 하면, Microsoft ID 생태계의 복잡성을 과소평가하는 경우가 많습니다. 직접 만든 솔루션은 거의 항상 세 가지 주요 위험을 내포합니다.

OAuth 드리프트: 직접 구성한 MSAL 연동, 토큰 저장, 갱신, 동의 예외 상황이 조용히 실패하거나 보안 토큰을 로컬 스토리지에 노출시킵니다.
UX 불일치: Microsoft와 다른 글꼴, 색상, 아이콘, 흐름으로 인해 로그인 창에서 사용자의 불신과 혼란을 초래합니다.
감사 공백: 일관되지 않은 동의 화면, 내부 데이터 거버넌스를 위반하는 무분별한 사람 검색, 기업 컴플라이언스 점검에 실패하는 낮은 접근성 점수가 발생합니다.

Graph Toolkit이 제공하는 것

모든 것을 처음부터 만드는 대신 표준화된 라이브러리를 활용하면 판도가 완전히 달라집니다. Microsoft Graph Toolkit은 프런트엔드 코드와 Microsoft Graph API 사이의 다리 역할을 하며, 다음을 제공합니다.

맞춤형 API 클라이언트 래퍼 없이도 Graph와 바로 작동하는 Microsoft 브랜드 React 컴포넌트.
내부적으로 MSAL을 사용하는 내장 인증 및 동의(토큰, 갱신, 범위)로, Microsoft 모범 사례에 따라 안전하게 관리됩니다.
캐싱, 제한(throttling), 오류 상태를 기본 제공으로 처리합니다.
키보드 탐색, 화면 낭독기 지원, 오른쪽에서 왼쪽으로 쓰는 언어(RTL) 레이아웃을 포함한 Fluent UI 디자인과 접근성.
사용자가 진위를 확인하는 데 쓰는 컴플라이언스 표시를 깨뜨리지 않는 안전한 커스터마이즈 후크(props, CSS 파트/클래스).

첫날부터 사용할 핵심 컴포넌트

툴킷을 도입하면 풍부한 사전 구축 UI 위젯 라이브러리를 바로 사용할 수 있습니다. 그중에서도 모든 엔터프라이즈 애플리케이션에 꼭 필요한 몇 가지가 두드러집니다.

Login: Microsoft 로그인/로그아웃, 프로필, 토큰, 동의 흐름을 바로 넣을 수 있으며, 복잡한 맞춤형 OAuth 코드가 필요 없습니다.
PeoplePicker: 디바운스 처리를 적용한 빠른 Azure AD 디렉터리 조회를 제공하며, 아바타와 다중 선택을 지원합니다. 맞춤형 구현에서 자주 부딪히는 속도 제한과 페이징 함정을 피할 수 있습니다.
Agenda: Outlook 일정을 익숙한 M365 표시(반복 규칙, 업데이트, 시간대)와 함께 보여주며, 최적의 성능을 위한 스마트 캐싱을 제공합니다.

툴킷과 맞춤형 코드, 언제 무엇을 선택할까

도구 키트를 쓸 범위와 직접 코드를 작성해야 할 범위의 경계를 아는 것이 중요합니다. 보안 로그인, 디렉터리 검색, 캘린더, 작업, 파일, 프레즌스, 사용자 프로필처럼 빠르고 브랜드 일관성이 필요한 기능에는 도구 키트를 사용해야 합니다. 반면, 매우 맞춤화된 데이터 혼합, 특수한 시각화, 또는 Graph가 아닌 시스템을 애플리케이션의 주요 데이터 원본으로 삼아야 한다면 직접 코드를 작성해야 합니다.

빠른 시작 (부담 없는 진행 경로)

Entra ID 앱을 만들고(개발/테스트/운영) MSAL을 활성화합니다. 최소 권한 원칙에 따라 Graph 범위를 부여합니다.
React에 공급자를 설치하고 연결합니다(MSAL 공급자 + Graph Toolkit 공급자).
구성 요소를 배치합니다: <Login />, <PeoplePicker />, <Agenda />.
페이지별로 범위를 설정하고(예: User.Read, Calendars.Read, People.Read) 동의 요구 사항을 확인합니다.
테마 토큰과 CSS 파트를 적용하되 Microsoft 패턴은 그대로 유지하여 안전하게 스타일을 입힙니다.
소규모 사용자 그룹에 파일럿을 배포하고 UX 및 성능 피드백을 수집한 뒤 롤아웃을 확대합니다.

운영 환경 점검 목록(보안 및 안정성)

애플리케이션을 운영 환경에 배포하기 전에 아래 점검 목록을 확인하여, 엔터프라이즈 부하에서도 구현이 안전하고 안정적으로 유지되는지 점검합니다.

최소 권한 범위를 적용하고, 사용자 위임 권한과 앱 권한을 신중하게 구분합니다.
비밀 값과 인증서를 안전하게 보관합니다(해당하는 경우 Azure Key Vault 활용).
토큰 수명 및 재시도 로직: 새로 고침 흐름을 검증하고, 429 또는 503 오류에 대해 지수 백오프를 구현합니다.
조건부 액세스: 도구 키트 흐름에 대해 다단계 인증과 기기 규정 준수 정책을 테스트합니다.
원격 분석: 효과적인 모니터링을 위해 요청 ID, 지연 시간 지표, 캐시 적중, Graph API 오류를 기록합니다.
접근성 점검: 키보드 탐색, 구조적 랜드마크, 색 대비 비율을 확인합니다.
브랜드 검토: Fluent UI 스타일과 자체 브랜드 셸이 시각적으로 일관되게 유지되는지 확인합니다.

성능 참고 사항

성능은 사용자 도입을 좌우할 수 있습니다. 다행히 구성 요소는 최적화를 염두에 두고 만들어졌습니다. 지연 데이터 로딩과 클라이언트 캐싱을 사용하여 사용자 인터페이스가 빠르게 반응하도록 유지합니다. 도구 키트에 내장된 목록 구성 요소를 활용해 N+1 API 호출을 피하고, 검색 결과를 보강하거나 긴 목록을 페이지로 나눌 때는 사용자 조회를 일괄 처리합니다.

신뢰를 해치지 않는 맞춤 설정

개발자들은 사전 구축된 구성 요소를 사용하면 애플리케이션을 브랜드화하는 능력이 제한될까 봐 우려하는 경우가 많습니다. 그러나 보안을 희생하지 않고도 경험을 쉽게 맞춤 설정할 수 있습니다. 코드를 포크하기보다 제공되는 속성(날짜 범위, 쿼리 필터 등)을 사용합니다. Fluent 토큰과 CSS 변수로 앱에 테마를 적용하고, 로그인 및 동의 대화 상자 같은 핵심 Microsoft 패턴은 사용자가 익숙하게 알아볼 수 있도록 항상 유지합니다.

흔한 함정(및 해결 방법)

“로컬에서는 작동하고 운영에서는 실패” → 대부분 리디렉션 URI 또는 범위 불일치가 원인입니다. Azure Entra ID 앱 등록 설정을 다시 확인하십시오.
사람 검색 결과가 비어 있음 → People.Read 또는 User.ReadBasic.All 범위가 누락되었거나, 테넌트의 디렉터리 설정이 지나치게 제한적인 경우입니다.
일정이 비어 있음 → Calendars.Read 범위에 대한 동의가 없거나, 조회 중인 사서함 유형이 지원되지 않는 경우입니다.
로그인 창이 계속 반복해서 표시됨 → 타사 쿠키가 차단되었거나 조건부 액세스의 세션 제어가 지나치게 엄격한 경우입니다. 비공개 창에서 테스트하고 CA 정책을 검토하십시오.

성과를 입증하기 위한 KPI 아이디어

엔지니어링 리더십에 이번 아키텍처 전환의 타당성을 설명하려면, 첫 기능 출시까지 걸리는 시간(도구 키트 도입 전후로 인증, 일정, 선택기를 구현하는 데 드는 시간), 사용자 1,000명당 인증 실패 건수와 헬프 데스크 지원 티켓, 캘린더 및 사람 보기의 페이지 상호 작용 가능 시간, 릴리스마다 발견되는 접근성 문제 수, 보안 검토 중 제기된 규정 준수 예외 같은 지표를 추적합니다.

마이그레이션 경로(위험도가 높은 사용자 지정 요소부터 교체)

직접 구현한 OAuth 처리를 표준 Login 구성 요소로 교체합니다.
최적화되지 않은 맞춤형 디렉터리 검색을 PeoplePicker 구성 요소로 교체합니다.
사용자 지정 캘린더 위젯을 Agenda 구성 요소로 교체합니다.
제품 로드맵에 따라 Files, Tasks, Presence 같은 부가 기능을 추가합니다.

핵심 요약

Microsoft 인프라를 처음부터 다시 구축할 필요는 없습니다. Microsoft Graph Toolkit은 사용자가 이미 신뢰하고 컴플라이언스 감사인도 쉽게 수용하는 안전하고 브랜드 일관성 있는 M365 빌딩 블록을 제공합니다. 이를 통해 엔지니어링 팀은 시장에서 비즈니스를 실제로 차별화하는 제품 기능에 집중할 수 있습니다.

견고하고 규정을 준수하는 Microsoft 365 앱 개발에 대해 더 깊이 알고 싶으신가요? Microsoft Graph Toolkit로 일관된 M365 앱 만들기 에피소드를 팟캐스트에서 전체 들어보세요!