Microsoft는 단 하나의 에이전트 거버넌스 프레임워크(agent governance framework)를 발표한 것이 아닙니다. 그들은 각각 고유한 운영 모델(operating model), 거버넌스 태세(governance posture), 그리고 자체적인 지표(metrics)를 가진 6가지의 뚜렷한 에이전트 도입 패턴(agentic adoption patterns)을 발표했습니다. 이러한 편집적 선택이 핵심입니다. 제가 해석하기에, 이는 모든 에이전트에 동일한 통제 세트를 찍어내는 기본 엔터프라이즈 구성(default enterprise configuration)이 이미 현장에서 실패했다는 것을 인정하는 것입니다. 만약 여러분이 Microsoft가 지지하는 AI 거버넌스 프레임워크를 찾고 있다면, 오늘날 Learn에서 얻을 수 있는 정직한 답변은 다음과 같습니다: 단 하나는 존재하지 않습니다. 6가지가 존재하며, 잘못된 것을 선택하는 것은 이제 운이 나쁜 결과가 아니라 문서화된 실패 모드(failure mode)입니다.

여기에는 두 가지 계층이 있으며, 저는 이를 계속 분리하여 다룰 것입니다. 문서화된 계층(documented layer): Microsoft의 에이전트 지침(agentic guidance)은 모든 에이전트를 동일하게 취급하는 대신 패턴에 따라 거버넌스를 차별화합니다. 이는 문서에 명시된 내용입니다. 해석적 계층(interpretive layer): 이를 "인정" 또는 "양보"라고 부르는 것은 왜 이 결과물이 이런 모습인지에 대한 저의 해석이며, Microsoft가 말한 것은 아닙니다. 두 계층 모두 같은 방향을 가리키고 있습니다.

다른 논의로 넘어가기 전 핵심 요점: 만약 여러분의 에이전트 거버넌스가 오늘날 균일하다면, 여러분은 패턴별로 차별화된 지침이 피하도록 유도하는 바로 그 구성을 실행하고 있는 것입니다.

왜 "에이전트"는 거버넌스를 수행하기에 너무 일반적인 범주인가

Microsoft의 플레이북(playbook)은 6가지 패턴을 명시합니다. 저는 6가지 에이전트 도입 패턴에 대한 실무자 해독에서 각 패턴의 이름을 하나씩 살펴보았으므로, 여기에서 목록을 다시 나열하지는 않겠습니다. 거버넌스 측면에서 중요한 것은 왜 6가지나 존재하는가 하는 점입니다.

정반대의 리스크 프로필(risk profiles)을 가진 두 에이전트를 가정해 보십시오. 이 비교는 고객 사례가 아닌 설명을 위한 예시입니다:

외부를 향하는 대화형 에이전트(externally facing conversational agent)는 제한된 폭발 반경(blast radius)을 가집니다. 이 에이전트의 리스크는 환각(hallucination), 출력물로의 개인정보(PII) 유출, 지연 시간(latency), 그리고 평판 리스크입니다. 이 에이전트의 최악의 상황은 당혹스러운 스크린샷이 찍히는 정도입니다.

자율적인 오케스트레이터(orchestrator)는 상시 권한(standing permissions)을 보유하고, 시스템 전반에 걸쳐 도구 호출(tool calls)을 체인화하며, 깔끔하게 되돌릴 수 없는 조치를 취합니다. 이 에이전트의 최악의 상황은 스크린샷이 찍히는 것이 아닙니다. 바로 롤백(rollback) 회의입니다.

이제 하나의 공유된 체크리스트로 이 둘을 모두 관리하십시오. 이 체크리스트는 대화형 에이전트(conversational agent)에 대해서는 승인 게이트(approval gates)를 추가하여 도입을 저해할 정도로 과도하게 통제하는 반면, 오케스트레이터에 대해서는 통제가 부족합니다. 왜냐하면 어떤 일반적인 체크리스트도 "이 에이전트의 행동 중 어떤 것이 되돌릴 수 없는가?"라고 묻지 않기 때문입니다. 한쪽의 실패는 도입 포기로 이어지고, 다른 쪽의 실패는 사고를 초래합니다. 동일한 문서가 이 두 가지 실패를 동시에 만들어냅니다.

프로덕션 에이전트는 하이브리드입니다

문서는 깔끔한 패턴 경계를 제시합니다. 하지만 프로덕션(Production) 환경은 그렇지 않습니다. 티켓을 접수할 수 있는 "지식 어시스턴트(knowledge assistant)"는 그 팀이 무엇이라 부르든 간에 조치를 취하는 에이전트(action-taking agent)입니다. 모든 에이전트를 수행할 수 있는 가장 위험한 작업에 따라 분류하십시오: 읽기 전용(read-only), 상태 변경이 가능하지만 되돌릴 수 있는(state-changing but reversible), 또는 상태 변경이 가능하며 되돌릴 수 없는(state-changing and irreversible) 작업으로 분류하십시오. 친근한 라벨은 마케팅일 뿐입니다. 작업 인벤토리(action inventory)가 바로 거버넌스(governance)입니다.

핵심 요약: 어떻게 관리할지 결정하기 전에, Microsoft의 패턴 어휘를 사용하여 당신이 무엇을 구축하고 있는지 명명하십시오. 라벨이 통제 체제(control regime)를 결정하므로, 팀의 설명이 아닌 기능(capability)으로부터 라벨을 도출하십시오.

대부분의 조직이 건너뛰는 CoE의 중추

Microsoft의 Learn에 게시된 에이전트 중심의 CoE(Center of Excellence) 가이드는 CoE를 거버넌스(govern), 활성화(enable), 최적화(optimize), 확장(scale)이라는 네 가지 기능으로 구성합니다. 이 순서가 핵심입니다. 이것은 메뉴가 아니라 의존성 체인(dependency chain)입니다. 존재하지 않는 가드레일(guardrails) 위에서 팀을 활성화할 수는 없습니다. 아무도 출시하지 않은 워크로드(workload)를 최적화할 수는 없습니다. 거버넌스를 수행하지 않은 것을 확장할 수는 없습니다.

측정된 통계가 아닌 현장 관찰로서 제가 목격하는 흔한 실패 사례는 다음과 같습니다: 리더십은 "확장(scale)"을 명령하고, 팀은 곧바로 확장으로 건너뛰며, 그 결과 파일럿 프로젝트는 중단되고 섀도우 에이전트(shadow-agent)가 확산됩니다. 거버넌스와 활성화 단계는 화려하지 않은 작업들이 머무는 곳이며, 바로 그 점 때문에 사람들이 이를 건너뛰게 됩니다.

CoE(Center of Excellence)의 위치를 정확히 설정해야 합니다. CoE는 플랫폼 제어(platform controls)를 대체하는 것이 아니라, azure ai 레퍼런스 아키텍처 위에 놓이는 인간 운영 모델입니다. 정책(policies), ID(identities), 네트워크 경계(network boundaries)는 플랫폼 계층에 존재합니다. 저는 2026 Azure AI 랜딩 존 레퍼런스 아키텍처에서 이 계층이 어떻게 보여야 하는지 다루었습니다. CoE는 누가 이러한 제어권을 소유하는지, 그리고 그 위에 구축하는 팀들을 누가 막힘없이 진행되도록 할지를 결정합니다. 만약 지금 CoE를 설립할 계획이라면, AI Center of Excellence를 구축하기 전에 이것을 읽으세요를 먼저 읽어야 합니다. 왜냐하면 명칭 부여 과정에서 대부분의 CoE가 조용히 실패하기 때문입니다.

핵심 요약: '활성화(enable)' 권한을 소유할 사람을 지정할 수 없다면, 당신에게는 CoE가 없습니다. 그것은 단지 희망일 뿐입니다.

'안전한 경로가 쉬운 경로여야 한다'는 문장을 훔쳐야 합니다

이 원칙은 Microsoft의 에이전트 기반 가이드라인에서 나온 것으로, CIO들이 플랫폼 팀에게 압박 테스트를 시켜야 할 단 하나의 문장입니다. 정책 커버리지(policy coverage)가 아닙니다. 제어 수(control count)도 아닙니다. 마찰(Friction)입니다.

여기에 메커니즘이 있습니다. 규정을 준수하는 사용 방식이 우회 경로보다 느리다면, 채택은 거버넌스를 피해 돌아가게 되고, 섀도우 에이전트(shadow agents)는 돌아가는 것의 모습이 됩니다. 결과는 거버넌스 정책 자체가 아니라, 거버넌스 마찰에 의해 결정됩니다. 저는 이전에 섀도우 AI 디스커버리와 제어권이 실제로 무엇을 필요로 하는지에 대해 글을 썼습니다. 제가 거기서 설명한 모든 섀도우 배포는 너무 느린 공식 경로에서 시작되었습니다.

플랫폼 팀을 위한 세 가지 합격/불합격 테스트:

1. 승인된 에이전트 템플릿은 원클릭이어야 합니다. 위키 페이지나 티켓 대기열이 아닙니다. 배포 가능한 아티팩트여야 합니다.
2. 가드레일(Guardrails)은 기본적으로 활성화되어 있어야 합니다. Azure Policy 할당, Entra 관리 ID(managed identities), 그리고 랜딩 존 상속(landing-zone inheritance)은 빌더가 옵트인하지 않아도 적용되어야 합니다.
3. 공식 경로가 DIY보다 빨라야 합니다. 개발자가 두 가지 방식으로 에이전트를 설정하는 시간을 측정해 보세요. 만약 DIY가 이긴다면, DIY가 승리할 것입니다.

하나라도 실패하면 우회책(workarounds)이 발생할 것을 예상해야 합니다. 핵심 요점: 정책의 개수가 아니라 마찰(friction)을 측정하십시오. 우회책보다 느린 준수 경로(compliant path)는 거버넌스 연극(governance theater)에 불과합니다.

세 가지 산출물, 하나의 스택

Microsoft의 가이드는 대부분의 독자가 별개의 문서로 취급하는 세 가지 산출물(artifacts)로 제공됩니다: 에이전트 도입 성숙도 모델(agentic adoption maturity model), 6가지 패턴 플레이북(six-pattern playbook), 그리고 CoE(Center of Excellence) 가이드입니다. 다른 것 없이 하나만 읽는 것은 실수입니다. 성숙도 모델은 현재 위치를 알려주고, 패턴은 무엇을 구축하고 있는지를 알려주며, CoE는 이를 어떻게 안전하게 확장(scale)할지를 알려줍니다. 설문 조사 결과가 아닌 저의 평가를 덧붙이자면, 대부분의 조직은 기껏해야 세 가지 중 하나만을 보유하고 있으며, 대개는 스스로 점수를 매기는 재미가 있는 성숙도 모델만을 가지고 있습니다. 만약 귀하의 자가 진단 결과가 여전히 파일럿 단계(pilot-stage)라면, 패턴 플레이북을 건드리기 전에 8가지 차원 전체에 걸친 정직한 AI 준비도 평가(AI readiness assessment)부터 시작하십시오.

이 표는 6가지 원형 리스크 프로필 중 3가지만 보여주는데, 이는 이 세 가지가 읽기 전용(read-only)에서 되돌릴 수 없는(irreversible) 스펙트럼을 포괄하기 때문입니다. 나머지 세 가지 패턴도 아래의 감사(audit) 섹션에 등장하며, 여기서는 에이전트 보유 여부와 관계없이 모든 패턴이 한 행을 차지합니다. 핵심 요점: 세 가지 산출물을 모두 채택하십시오. 그렇지 않으면 나머지 두 차원은 보지 못한 채 하나의 차원만을 최적화하게 됩니다.

Microsoft의 패턴을 기준으로 AI 거버넌스 프레임워크 감사하기

이 부분이 핵심(payload)이며, 이는 문서의 향후 개정 여부와 상관없이 유효합니다. 왜냐하면 이 방식은 문서의 페이지가 아니라 귀하의 자산(estate)을 감사하기 때문입니다. 소규모 자산을 대상으로 하는 워킹 세션(working session)으로 범위를 정하십시오. 시간은 인벤토리(inventory) 규모에 따라 달라지며 실제 상황은 다양할 수 있습니다.

1. 운영 중이거나 파일럿 단계인 모든 에이전트 인벤토리화 (Inventory every agent in production or pilot) Azure AI Foundry 프로젝트, Entra 앱 등록(app registrations), 구독 리소스 스캔(subscription resource scans)을 통해 정보를 가져오십시오. 아무도 등록하지 않은 파일럿 프로젝트까지 포함해야 합니다. 목록에 없는 에이전트는 예외가 아니라 발견 사항(finding)입니다.
2. 각 에이전트에 두 번 태그 지정 (Tag each agent twice) 첫 번째 태그: Microsoft의 플레이북(playbook)에 명시된 공식 패턴 이름. 두 번째 태그: 읽기 전용(read-only), 상태 변경 가능하지만 되돌릴 수 있음(state-changing but reversible), 상태 변경 및 되돌릴 수 없음(state-changing and irreversible)의 3단계 척도 중 가장 높은 위험 동작. 두 태그가 충돌할 경우 두 번째 태그를 우선합니다.
3. 패턴별 제어 매트릭스 구축 (Build the pattern-by-control matrix) 행(Row)은 패턴별로 그룹화된 에이전트입니다. 열(Column)은 권한 모델(permissions model), 인간 승인 지점(human approval points), 로깅 깊이(logging depth), 평가 주기(evaluation cadence), 롤백 능력(rollback capability), 사고 소유권(incident ownership)의 6가지 제어 차원입니다. 정책 문서에 적힌 내용이 아니라 실제로 존재하는 내용을 채우십시오.
4. 균일성을 확인하기 위해 매트릭스 읽기 (Read the matrix for uniformity) 만약 모든 에이전트가 6가지 차원 모두에서 동일한 제어 항목에 매핑된다면, 그 균일성은 엄격함의 증거가 아니라 노출(exposure)입니다. 에이전트가 하나도 없는 패턴 행 또한 발견 사항입니다. 아직 구축하지 않았거나, 자산 중 무언가가 잘못 태그 지정된 것입니다.

균일성 발견 사항(uniformity finding)이 가장 중요합니다. 상반된 위험 프로필(risk profiles)을 가진 에이전트들이 동일한 제어 항목을 가진다는 것은, 대화형 에이전트(conversational agents)가 오케스트레이터(orchestrator)급의 마찰을 겪고 있으며, 오케스트레이터는 챗봇(chatbot)급의 감독을 받고 있음을 의미합니다. 계층화 로직(tiering logic)을 통해 이를 해결하고 싶다면, 저는 실제 배포를 위한 Microsoft의 위험 계층별 에이전트 거버넌스 모델(Microsoft's risk-tiered agent governance model for real deployments)에 각 계층이 시사하는 배포 결정 사항들을 주석으로 달아두었습니다.

감사(Audit)를 통해 에이전트의 리스크가 어디에 집중되어 있는지 확인할 수 있으며, 다음 거버넌스 스프린트(Governance sprint)가 목표로 삼아야 할 것은 정책 바인더(Policy binder)가 아니라 바로 그 리스크의 집중 지점입니다. 에이전트를 가장 높은 리스크를 가진 작업(Highest-risk action)을 기준으로 분류하고, 규정을 준수하는 경로를 가장 빠른 경로로 만드는 조직은, 해당 문서의 명칭이 무엇이든 간에 이미 실무에서 Microsoft의 AI 거버넌스 프레임워크를 구축한 것입니다. 반면, 모든 에이전트를 동일하게 거버넌스하는 조직은 제 관점에서 볼 때, 패턴별로 차별화된 가이드라인이 (문구는 다를지언정) 지향하는 방향과 일치하지 않으며, 아직 계산에 넣지 못한 리스크를 떠안게 됩니다.

이 기사는 원래 az365.ai에 게시되었습니다. 저는 Alex Pechenizkiy이며, Microsoft AI 스택에 대해 정직하고 벤더 중립적인 분석을 작성하는 Azure 및 Power Platform 솔루션 아키텍트입니다. 더 많은 내용은 az365.ai에서 확인하세요.