직접 만든 인증과 UX가 M365 앱을 망가뜨리는 이유

By Mirko Peters · 2026-08-11

블로그에 다시 오신 것을 환영합니다! 빈 화면을 바라보며 직접 만든 Microsoft 365 애플리케이션에서 갑자기 조용한 인증 오류가 발생해 원인을 모르겠거나, 보안 컴플라이언스 팀을 애태우게 만든 경험이 있다면 여러분만 그런 것이 아닙니다. 사용자를 인증하고, Azure Active Directory를 검색하고, 캘린더 위젯을 렌더링할 때마다 바퀴를 새로 발명해야 한다면 최신 엔터프라이즈 소프트웨어를 만드는 일은 그것만으로도 충분히 어렵습니다. 그럼에도 전 세계 개발 팀들은 여전히 사용자 지정 OAuth 흐름과 자체 제작 UI 구성 요소를 처음부터 만드는 함정에 빠지곤 합니다.

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

Titelbild: Why DIY Auth and UX Break M365 Apps

블로그에 다시 오신 것을 환영합니다! 커스텀으로 만든 Microsoft 365 애플리케이션에서 이유 없이 조용한 인증 오류가 발생해 화면만 멍하니 바라보았거나, 보안 컴플라이언스 팀을 골치 아프게 만든 적이 있다면 여러분만 그런 것은 아닙니다. 현대적인 엔터프라이즈 소프트웨어를 만드는 일은 그 자체로도 어렵습니다. 사용자를 인증할 때, Azure Active Directory를 검색할 때, 캘린더 위젯을 렌더링할 때마다 바퀴를 다시 발명해야 한다면 더욱 그렇습니다. 그럼에도 전 세계 개발 팀들은 여전히 커스텀 OAuth 흐름과 자체 제작 UI 컴포넌트를 처음부터 만드는 함정에 빠지곤 합니다.

이 글에서는 직접 만드는 방식이 M365 앱을 왜 번번이 망치는지 깊이 살펴보겠습니다. OAuth 드리프트, 사용자 불신, 컴플라이언스 감사 공백 같은 숨은 위험을 짚어 보겠습니다. 더 중요한 것은, 검증된 사전 구축 솔루션을 활용해 이런 큰 골칫거리를 어떻게 피할 수 있는지 알아보겠습니다. 위험한 사용자 지정 보일러플레이트 작성을 멈추고, 보안이 확보된 프로덕션 준비 상태의 M365 프런트엔드를 그 어느 때보다 빠르게 배포하는 방법을 함께 정리하겠습니다.

개요

대부분의 Microsoft 365 애플리케이션은 결국 세 가지 핵심 통합 지점, 즉 인증, 디렉터리 검색, 캘린더 사용자 경험에서 무너집니다. 기능이 깨질 뿐 아니라, 그 과정에서 브랜드 일관성까지 크게 떨어지는 경우가 많습니다. 다행히 더 나은 방법이 있습니다. Microsoft Graph Toolkit는 Microsoft Graph에 직접 연결되고, 복잡한 토큰과 동의 워크플로를 기본으로 처리하며, 신뢰할 수 있고 컴플라이언스를 충족하는 사용자 경험을 제공하는 Microsoft 브랜드 React 구성 요소를 유지 관리되는 형태로 제공합니다. 필요할 때는 팀이 안전하게 사용자 지정할 수도 있습니다.

이 글이 도움이 되는 대상

프런트엔드 엔지니어링의 최전선에서 일하든 엔터프라이즈 보안 컴플라이언스를 관리하든, 최신 통합 패턴을 이해하는 것은 매우 중요합니다. 이 가이드는 특히 다음과 같은 분들을 위해 작성되었습니다.

M365와 연결된 웹 애플리케이션을 만드는 프런트엔드 개발자와 테크 리드
스프린트 주기를 부풀리지 않으면서 빠르고 컴플라이언스를 준수하는 인증 및 디렉터리 기능이 필요한 제품 팀
위험한 사용자 지정 OAuth 구현과 임의적인 UI 불일치를 관리하는 데 지친 보안 및 컴플라이언스 담당자

직접 만들면 왜 깨지고 컴플라이언스에 위험이 되는가

처음에는 늘 단순하게 시작합니다. 개발자는 "간단한 로그인 버튼과 사용자를 빠르게 찾는 방법만 있으면 됩니다. 사용자 지정 래퍼를 작성하는 데 오래 걸리지 않을 겁니다."라고 말합니다. 그러나 3개월이 지나면 애플리케이션에는 미묘하고 반복적인 오류가 쌓이게 됩니다.

OAuth 드리프트: 자체 제작한 MSAL 연결, 사용자 지정 토큰 저장소, 깨진 새로 고침 토큰 루프, 처리되지 않은 동의 예외 상황이 조용히 사용자를 시스템에서 차단합니다.
UX 불일치: Microsoft의 기본 인터페이스와 어긋나는 글꼴, 색 구성표, 아이콘, 상호 작용 패턴이 즉각적인 사용자 불신과 혼란을 불러옵니다.
감사 공백: 일관되지 않은 동의 화면, 권한이 없는 데이터를 노출하는 사람 검색 메커니즘, 엔터프라이즈 보안 검토에서 탈락하는 부족한 접근성 준수가 문제가 됩니다.

Graph Toolkit가 제공하는 것

원시 엔드포인트와 사용자 지정 상태 관리에 매달리는 대신, 표준화된 툴킷을 도입하면 판도가 완전히 달라집니다. 바로 사용할 수 있는 기능은 다음과 같습니다.

Microsoft Graph 데이터와 자연스럽게 연결되어 "그냥 작동하는" Microsoft 브랜드 React 구성 요소
내부적으로 안정적으로 작동하는 MSAL을 기반으로 한 내장 인증 및 동의 관리(토큰, 새로 고침 주기, 정밀한 범위)
자동 캐싱, 지능형 조절, 표준화된 오류 상태를 대신 처리
Fluent UI 룩앤필과 포괄적인 접근성 기능(완전한 키보드 탐색, 스크린 리더 지원, RTL 레이아웃 대응)
중요한 컴플라이언스 및 신뢰 요소를 깨뜨리지 않고 앱을 스타일링할 수 있도록 하는 안전한 사용자 지정 후크(props 및 CSS 파트 또는 클래스 사용)

첫날부터 사용할 핵심 구성 요소

기존의 임시방편 코드를 표준화된 구성 요소로 교체하기 시작하면, 아키텍처의 무거운 작업을 즉시 떠맡을 몇 가지 필수 구성 블록이 있습니다.

Login: 사용자 프로필, 토큰, 전체 동의 흐름을 관리하는 Microsoft 로그인 및 로그아웃 경험을 바로 넣어 사용할 수 있으며, 복잡한 사용자 지정 OAuth 코드가 필요하지 않습니다.
PeoplePicker: 아바타와 다중 선택 기능을 갖춘, 빠르고 디바운스가 적용된 Azure AD 디렉터리 조회 컴포넌트입니다. API 속도 제한과 복잡한 페이징 문제를 피하도록 세심하게 설계되었습니다.
Agenda: 반복 표시기, 실시간 업데이트, 시간대 관리 등 익숙한 M365 시각적 요소로 Outlook 캘린더 일정을 깔끔하게 보여 주며, 스마트 로컬 캐싱으로 뒷받침됩니다.

툴킷과 사용자 지정 코드를 언제 사용할지

프런트엔드를 표준화하는 것은 큰 이점이지만, 플랫폼 컴포넌트와 사용자 지정 엔지니어링의 경계를 어디에 그을지도 알아야 합니다.

툴킷: 보안 로그인, 엔터프라이즈 디렉터리 검색, 캘린더, 작업, 파일, 사용자 프레즌스 또는 프로필 관리를 빠르고 브랜드에 맞게 구현해야 할 때 이 컴포넌트를 사용하십시오.
사용자 지정: 애플리케이션에 매우 맞춤화된 데이터 매시업, 특수한 엔터프라이즈 시각화가 필요하거나, Graph가 아닌 시스템이 주요 기준 원본(source of truth) 역할을 하는 경우에는 사용자 지정 코드를 작성하십시오.

빠른 시작(문제없는 경로)

아키텍처 관련 어려움 없이 바로 시작할 준비가 되셨습니까? 다음의 간단한 절차에 따라 환경을 설정하십시오.

개발, 테스트, 운영 환경 전반에 걸쳐 Entra ID 애플리케이션 등록을 만들고, MSAL 지원을 활성화하며, 필요한 최소 권한의 Graph 범위만 부여하십시오.
React 애플리케이션에 인증 공급자를 설치하고 연결하십시오. MSAL 공급자와 Graph 툴킷 공급자를 함께 구성합니다.
뷰에 핵심 컴포넌트를 추가하십시오: <Login />, <PeoplePicker />, <Agenda />.
페이지별로 정확한 범위(예: User.Read, Calendars.Read, People.Read)를 설정하고 사용자 동의 동작을 확인하십시오.
승인된 테마 토큰과 CSS 파트를 적용해 안전하게 스타일을 입히되, 핵심 Microsoft 시각 패턴은 그대로 유지하십시오.
범위를 넓히기 전에 소규모의 제한된 사용자 그룹에 파일럿 버전을 배포하여 중요한 UX 및 성능 피드백을 수집하십시오.

운영 체크리스트(보안 및 안정성)

새로 만든 M365 애플리케이션을 운영 환경에 배포하기 전에, 다음의 필수 보안 및 안정성 체크리스트를 반드시 확인하십시오.

최소 권한 범위를 적용하고, 사용자 위임 권한과 앱 전용 권한을 엄격하게 구분하십시오.
Azure Key Vault를 활용하여 모든 비밀 정보와 인증서를 안전하게 저장하십시오.
토큰 수명 구성, 새로 고침 흐름, HTTP 429 및 503 오류에 대한 적절한 백오프 처리를 검증하십시오.
툴킷 워크플로에 대해 다단계 인증과 기기 규정 준수 요구 사항을 포함한 조건부 액세스 정책을 테스트하십시오.
요청 ID, 요청 지연 시간, 캐시 적중률, 수신된 Graph 오류를 기록하는 충분한 원격 분석(텔레메트리)을 구현하십시오.
키보드 탐색, 랜드마크 구조, 적절한 색 대비 비율을 포함하여 철저한 접근성 점검을 수행하십시오.
Fluent UI 디자인 표준과 회사 브랜드 셸이 조화를 이루는지 확인하기 위해 브랜드 검토를 실시하십시오.

성능 참고 사항

엔터프라이즈 사용자는 느린 소프트웨어를 전혀 참지 않습니다. 애플리케이션을 매우 빠르게 유지하려면 다음을 고려하십시오.

사용자 인터페이스를 빠르게 유지하도록 지연 데이터 로딩과 지능형 클라이언트 측 캐싱을 사용하는 컴포넌트를 최대한 활용하십시오.
가능한 한 기본 툴킷 목록과 다중 항목 컴포넌트를 우선 사용하여 비용이 많이 드는 N+1 API 호출을 피하십시오.
검색 결과를 보강할 때 사용자 조회를 일괄 처리하고, 긴 엔터프라이즈 목록은 항상 적절히 페이징하십시오.

신뢰를 해치지 않는 사용자 지정

사용자 지정은 회사 정체성에 맞추는 데 매우 중요하지만, 과도한 사용자 지정은 사용자 신뢰를 무너뜨립니다. 다음 경계를 염두에 두십시오.

핵심 소스 코드를 포크해서 수정하기보다는 표준 컴포넌트 속성(예: 날짜 범위, 쿼리 필터)을 사용하십시오.
Fluent 디자인 토큰과 CSS 변수를 사용해 앱에 테마를 적용하되, 익숙한 Microsoft 패턴은 쉽게 알아볼 수 있도록 유지하십시오.
내장 이벤트 훅(예: onSelect 또는 onSignIn)을 통해 기능을 깔끔하게 확장하여 후속 워크플로를 안전하게 실행하십시오.

흔한 함정과 해결 방법

훌륭한 도구가 있어도 개발자는 가끔 문제에 부딪힙니다. 가장 흔한 함정과 해결 방법은 다음과 같습니다.

"로컬에서는 작동하는데 운영 환경에서는 실패함": 보통 리디렉션 URI 또는 범위 불일치가 원인입니다. Azure 포털의 앱 등록 설정을 다시 확인하십시오.
사람 검색 결과가 비어 있음: 일반적으로 People.Read 또는 User.ReadBasic.All 권한이 누락되었거나 디렉터리 가시성 제한이 엄격하게 설정되어 있기 때문입니다.
일정 위젯이 비어 있는 경우: Calendars.Read에 대한 동의가 명시적으로 부여되었는지, 또는 사용자의 사서함 유형이 지원되지 않는지 확인합니다.
로그인 프롬프트가 무한히 반복되는 경우: 타사 쿠키 차단이나 엄격한 조건부 액세스 세션 제어로 인해 발생하는 경우가 많습니다. 비공개 브라우저 창에서 테스트하고 조건부 액세스(CA) 정책을 검토합니다.

성과를 입증하는 KPI 아이디어

표준화된 툴킷으로 전환하는 노력이 가치 있었다는 것을 리더십이나 이해관계자에게 설득해야 한다면 다음 핵심 성과 지표(KPI)를 추적합니다.

인증, 일정, 선택기 같은 핵심 기능을 구축하는 데 걸리는 시간(첫 기능 완성까지)을 툴킷 도입 전후로 비교합니다.
활성 사용자 1,000명당 총 인증 실패 건수와 관련 헬프 데스크 지원 티켓 수입니다.
Agenda와 PeoplePicker 같은 무거운 뷰의 페이지 상호 작용 가능 시점까지의 로드 시간입니다.
릴리스 주기별로 발견된 접근성 결함 또는 위반 건수입니다.
공식 설계 검토 중 제기된 규정 준수 및 보안 예외 건수이며, 목표는 명확하게 0건으로 설정합니다.

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

애플리케이션 전체를 하룻밤 사이에 리팩터링할 필요는 없습니다. 가장 위험한 사용자 지정 코드부터 교체하는 단계적 접근 방식을 취합니다.

취약한 사용자 지정 OAuth 구현을 표준 Login 구성 요소로 교체합니다.
속도 제한이 걸린 자체 디렉터리 검색 로직을 견고한 PeoplePicker 구성 요소로 교체합니다.
수동 일정 위젯을 사전 빌드된 Agenda 구성 요소로 업그레이드합니다.
제품 로드맵에 따라 Files, Tasks, Presence 표시기 같은 보조 기능을 추가합니다.

핵심 정리

소중한 엔지니어링 시간을 들여 Microsoft 기능을 처음부터 다시 만들려고 하지 마십시오. Microsoft Graph Toolkit 같은 도구를 활용하면 엔터프라이즈 사용자가 자연스럽게 신뢰하고 보안 감사자도 흔쾌히 승인하는, 안전하고 브랜드에 맞게 다듬어진 M365 빌딩 블록을 얻을 수 있습니다. 이렇게 하면 개발팀이 경쟁 제품과 실제로 차별화하는 고유한 제품 기능과 비즈니스 로직에 집중할 수 있습니다.

이 주제를 더 깊이 살펴보고 현장의 실제 구현 전략을 듣고 싶다면 동반 팟캐스트 에피소드를 들어 보십시오: Build Consistent M365 Apps with Microsoft Graph Toolkit.