ID 고립 문제: ACS 토큰과 Azure AD 살펴보기

By Mirko Peters · 2026-08-11

블로그에 다시 오신 것을 환영합니다. 제품 로드맵을 보면서 맞춤형 커뮤니케이션 기능을 웹 앱에 직접 넣을지, 아니면 사용자를 Microsoft Teams라는 엔터프라이즈 영역으로 보낼지 고민해 본 적이 있다면 혼자만 그런 고민을 하는 것이 아닙니다. 커뮤니케이션 아키텍처를 잘못 선택하면 막대한 기술 부채, 예상치 못한 라이선스 비용, 채택을 완전히 멈추게 하는 사용자 온보딩 마찰이 생길 수 있습니다. 이 환경을 정리하는 데 도움을 드리고자, Azure Communication Services(ACS)에서 앱이 발급한 토큰을 관리하는 방식과 직원 인증에 Azure AD를 사용하는 방식의 근본적인 차이를 자세히 살펴보고, 커뮤니케이션 아키텍처를 구축할 때 이 두 개의 독립된 ID 체계를 어떻게 연결할지 설명합니

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

Titelbild: Identity Islands: Navigating ACS Tokens vs Azure AD

이 심층 분석은 최신 팟캐스트 에피소드를 바탕으로 합니다. 이러한 실제 상충 관계를 오디오로 자세히 듣고 싶다면 Azure Communication Services vs Teams APIs를 꼭 확인해 보시기 바랍니다.

대상 독자

웹 또는 모바일 앱에 고객 채팅/통화 기능을 제공하는 제품 리더
Microsoft 365, Azure AD, Graph를 아우르는 플랫폼 아키텍트
예상치 못한 규정 준수 문제나 라이선스 문제를 원치 않는 엔지니어링 매니저

핵심 요약

ID가 모든 것을 좌우합니다. ACS는 외부 사용자나 익명 사용자에게 유연하며, Teams API는 내부 사용자의 Azure AD와 맞춰지지만 게스트 온보딩에서 마찰이 생깁니다.
프레즌스가 차이를 만듭니다. Teams API는 Graph를 통해 풍부한 프레즌스 정보를 제공하지만, ACS에는 기본 Teams 프레즌스가 없으므로 사용자 지정 동기화를 구현하거나 일부를 포기해야 합니다.
채팅 기능의 동등성이 중요합니다. Teams는 클라이언트 기능(스레드, 반응, 카드)을 그대로 제공하지만, ACS는 가볍고 쉽게 임베드할 수 있는 대신 누락된 UX는 직접 만들어야 합니다.
통화 경계가 존재합니다. ACS와 Teams 모임 간 상호 운용성은 기본으로 제공되지 않으며, Teams를 통해 게스트가 참여하려면 대개 Azure AD 게스트 초대가 필요합니다.
규정 준수와 비용의 균형. Teams는 M365 규정 준수 기능(eDiscovery, DLP, 법적 보존)을 그대로 활용할 수 있지만, E3/E5와 프리미엄 요금, 제한(스로틀링) 현실이 따릅니다. ACS는 사용량 기반으로 과금되지만 스토리지, 보존, 감사는 직접 관리해야 합니다.
하이브리드는 강력하지만 운영 비용이 큽니다. ID 매핑, 메시지 변환, 프레즌스 동기화, 정책 시행을 위한 미들웨어가 필요할 것입니다.

빠른 가이드: ACS, Teams, 하이브리드 중 무엇을 선택할까?

마찰 없는 B2C 규모, 익명/게스트 채팅, 모바일/Web SDK의 빠른 개발, 세밀한 비용 통제가 필요하고, 그리고 토큰 수명 주기, 스토리지, 보존, 감사를 직접 관리할 의향이 있다면 ACS를 선택하십시오.
핵심 사용자가 프레즌스, 스레드형 채팅, 모임 참여가 필요한 직원이고, 테넌트 정책에 따른 기본 제공 규정 준수가 필요하다면 라이선스와 Graph 권한 관리 부담을 감수하고 Teams API를 선택하십시오.
Teams에서 내부 상담원에게 외부 대화를 노출해야 하거나 공개 채팅/통화를 Teams의 규정 준수 및 상태 기능과 결합해야 한다면 하이브리드 방식을 선택하십시오.

실무에서 겪는 함정(현장 사례)

두 개의 ID 섬: ACS 토큰과 Azure AD 개체가 분리되어 있어 매핑 계층이 필요합니다.
게스트 경험의 비용: AAD 게스트 초대는 빠른 B2C 흐름을 늦춥니다.
프레즌스 불일치: ACS는 상담원이 Teams 모임 중에 바쁘다는 사실을 "볼" 수 없습니다.
첨부 파일 처리: Teams는 OneDrive/SharePoint를 기대하지만, ACS는 흔히 Blob/URL을 사용합니다.
숨은 제한: 대규모에서는 Graph 스로틀링과 프리미엄 엔드포인트가 문제를 일으킬 수 있습니다.
ACS의 규정 준수 부담: 암호화, 보존, 감사 추적, 리전 보장을 직접 책임져야 합니다.

기능별 비교

ID 및 액세스

ACS: 앱에서 발급한 사용자와 토큰이며, 웹사이트 방문자나 계약직에 적합합니다. MFA, 취소, 만료는 직접 관리해야 합니다.
Teams API: 직원에게는 Azure AD SSO를 사용합니다. 게스트에게는 초대와 동의가 필요하며 테넌트 정책과도 맞춰야 합니다.

프레즌스

Teams API: Graph를 통해 테넌트 전체에서 풍부하고 즉각적인 프레즌스를 제공합니다.
ACS: 기본 Teams 프레즌스가 없으며, 사용자 지정 원격 측정과 동기화가 필요합니다.

채팅 및 UX

Teams API: 스레드, 반응, 카드, 답글, 인라인 파일을 제공하며 Teams와 유사한 기능 동등성을 갖습니다.
ACS: 기본적인 메시징만 제공합니다. 스레드, 검색, 사용자 지정 이모지, 저장 기능은 직접 추가해야 합니다.

통화/모임

ACS: 앱에 음성과 영상을 내장할 수 있어 외부 사용자 접근에 유리합니다. 미디어 경로 문제는 직접 해결해야 합니다.
Teams API: 테넌트 사용자에게는 매끄럽게 동작합니다. 다만 외부 참가는 보통 AAD 게스트 온보딩을 수반합니다.

SDK & 개발자 경험

ACS: 웹, iOS, Android용 통합 SDK를 제공하여 빠르게 내장할 수 있습니다.
Teams/Graph/Bot: 기능은 강력하지만 학습 곡선이 가파릅니다(권한, 웹훅, 페이징).

규정 준수 & 라이선스

Teams: eDiscovery, DLP, 법적 보존, 데이터 상주 기능이 기본으로 포함됩니다. M365 라이선스로 비용을 지불하며, 프리미엄 기능이나 제한이 추가될 수 있습니다.
ACS: 사용량 기반 과금입니다. 스토리지 위치, 보존, SIEM, 감사 내보내기는 직접 관리해야 합니다.

참조 아키텍처(사고 모델)

B2C 포털(ACS 우선): ACS 채팅/통화 -> 자체 스토리지 및 보존 -> 선택적으로 봇이나 채널을 통해 Teams로 전달하여 상담원이 처리
내부 헬프데스크(Teams 우선): Teams 채팅/봇 + Graph 프레즌스 -> 직원 SSO -> 선택적으로 양식이나 게스트 온보딩을 통한 외부 접수
하이브리드 브리지: 공개 위젯용 ACS <-> 미들웨어(ID 매핑, 메시지 변환, 프레즌스 동기화, 규정 준수 훅) <-> Teams 채널 및 상담원 경험

구축 체크리스트

주 사용자를 정의합니다: 직원, 계약직, 또는 외부 사용자.
데이터가 저장되는 위치를 결정하고, 보존과 감사를 누가 책임질지 정합니다.
코드를 작성하기 전에 ID 흐름(SSO, 게스트, 익명 사용자)을 정리합니다.
프레즌스 요구 사항을 초기에 검증합니다. 나중에 덧붙이는 일이 없도록 하십시오.
Graph 제한과 ACS 메시지 및 통화 처리량에 대해 부하 테스트를 수행합니다.
라이선스와 운영 비용(미들웨어, 감사, 모니터링)에 대한 예산을 수립합니다.
다음 분기에 요구 사항이 바뀔 경우를 대비해 롤백 및 이탈 계획을 세웁니다.

간단한 FAQ

ACS 사용자가 Teams 모임에 기본적으로 참가할 수 있나요? 직접은 어렵습니다. 브리지나 AAD 게스트 흐름이 필요할 것입니다.
ACS 사용자에게 M365 라이선스가 필요한가요? 아닙니다. ACS는 사용량 기반입니다.
Teams API가 외부 익명 사용자를 처리할 수 있나요? 깔끔하게는 어렵습니다. 보통 AAD 게스트 온보딩이 필요합니다.
ACS에서 프레즌스를 사용할 수 있나요? Teams 사용자에게는 불가능합니다. 별도의 동기화나 우회 방법이 필요합니다.

실행 단계

가장 중요한 요구 사항 3가지를 정합니다(예: 익명 채팅, Teams 프레즌스, eDiscovery).
두 갈래로 스파이크를 진행합니다. 공개 채팅용 ACS PoC와 내부 상담원용 Teams PoC입니다.
두 가지가 모두 필요하다면 미들웨어 MVP의 범위를 정합니다: ID 매핑, 메시지 중계, 최소한의 프레즌스 동기화, 감사 로깅.
예산을 맞춥니다: M365 좌석 대 ACS 사용량 및 규정 준수 운영 인력.

마무리하자면, Azure Communication Services와 Azure AD 사이의 ID 섬을 잇는 아키텍처를 설계하려면 대상 사용자를 분명히 이해해야 합니다. 공개 소비자 포털을 만들든 내부 기업 헬프데스크를 만들든, ID를 최우선으로 고려하면 나중에 많은 어려움을 줄일 수 있습니다. 이러한 선택에 대해 더 깊이 알고 싶다면 Azure Communication Services vs Teams APIs 후속 에피소드를 들어 보시고, Microsoft 365 및 Azure 아키텍처에 관한 최신 소식을 놓치지 않도록 구독해 주십시오!