감사관이 당신의 AI 거버넌스 검토 현장에 들어옵니다. 당신은 40페이지 분량의 정책 문서, 리스크 레지스터(risk register), 그리고 승인된 모델 목록이 담긴 스프레드시트를 건넵니다. 그들은 예의 바르게 미소 지으며 단 한 가지 질문을 던집니다. "이것이 런타임(runtime)에서 어떻게 강제되는지 보여주세요."

그 순간, 체크박스식 거버넌스(checkbox governance)는 종말을 맞이합니다.

문서는 의도를 설명할 뿐입니다. 문서는 개발자가 가공되지 않은 모델 엔드포인트(model endpoint)를 호출하는 것을 막지 못하며, 조용히 세 개의 하위 에이전트(sub-agents)를 생성하는 에이전트를 포함하지도 않고, 어떤 통제(control)가 실제로 작동했는지에 대한 단 한 줄의 증거도 생성하지 못합니다. 컴플라이언스(Compliance) 담당자들은 이를 알고 있습니다. 감사관들도 이를 알고 있습니다. 그리고 문서철과 실행 중인 시스템 사이의 간극이 바로 다음 보안 침해(breach)가 발생하는 지점입니다.

이 글의 나머지 부분에서 옹호할 논지는 다음과 같습니다.

Microsoft Azure에서 모든 AI 거버넌스 프레임워크를 구축할 때 가장 중대한 결정은, 필수적인 AI 게이트웨이(AI gateway)를 보편적인 컨트롤 플레인(control plane)으로 만드는 것입니다. 문서가 아닙니다. 위원회도 아닙니다. 모든 모델 호출과 모든 에이전트 동작이 반드시 통과해야 하는 아키텍처의 일부입니다. 이를 정책 코드화(policy-as-code)된 페이브드 로드(paved roads)로 감싸면, 컴플라이언스는 속도를 저해하는 세금이 아니라 가장 저항이 적은 경로가 됩니다.

Microsoft Azure에서 AI 거버넌스 프레임워크 설계하기: 세 가지 플레인(planes)

Microsoft는 아이덴티티(identity), 데이터(data), 모델(model)이라는 세 가지 플레인이 하나의 메시(mesh)로 서로 맞물리는 깔끔한 이야기를 마케팅합니다. 이 이야기는 대체로 사실입니다. 하지만 마케팅 자료가 얼버무리는 방식으로 불완전하기도 하며, 그 불완전함에 대해 솔직해지는 것이 거버넌스 설계가 현실과 맞닥뜨렸을 때 살아남게 만드는 핵심입니다.

이 세 가지 플레인은 세 가지 제품에 매핑됩니다. 게이트웨이는 이 세 가지 모두의 상단에 위치하며, 각각의 분리된 신호들을 하나의 집행 및 증거 지점으로 전환합니다.

계층 (Plane)	제품 (Product)	네이티브 런타임 집행 (Native runtime enforcement)	게이트웨이 연동 (Gateway tie-in)
ID (Identity)	Microsoft Entra	RBAC, 조건부 액세스 (Conditional Access), 관리형 및 워크로드 ID (managed and workload identities). 스택 내에서 가장 강력하게 맞물려 있음.	게이트웨이는 모델에 도달하기 전, 모든 호출자를 Entra 주체 (principal)로 인증함.
...

해당 표를 면밀히 살펴보십시오. 맞물림(interlock)은 Microsoft Entra ID 경계와 Azure Policy 배포 계층에서 강력하게 작동합니다. 반면, 커스텀 애플리케이션을 위한 데이터 흐름 차단(data-flow interception) 단계에서는 느슨하며, 이 지점이 Microsoft Purview의 집행력이 약해지는 부분입니다. 이러한 느슨함은 불평해야 할 결함이 아닙니다. 그것은 당신이 그 주변을 설계하며 고려해야 할 설계상의 제약 조건(design constraint)입니다.

그 제약 조건을 중심으로 구축하는 방법이 바로 게이트웨이입니다.

게이트웨이는 세 가지 문제를 동시에 해결합니다

필수적인 AI 게이트웨이를 도입하는 것은, 그 어떤 문서도 해낼 수 없는 세 가지 역할을 수행하는 하나의 아키텍처 결정입니다.

그것은 섀도우 모델 (shadow models)을 제거합니다. 모델 엔드포인트로의 송신(egress)이 게이트웨이를 통해서만 허용된다면, 승인되지 않은 모델을 사용하는 것은 나중에 발견되는 정책 위반 사항이 아닙니다. 그것은 아예 연결되지 않는 네트워크 호출이 됩니다.

그것은 에이전트 확산 (agent sprawl)을 억제합니다. 모든 에이전트 작업은 인증, 권한 부여 및 로그 기록이 가능한 제어 지점(control point)을 통해 라우팅됩니다. 에이전트는 병목 지점(chokepoint)을 우회하여 스스로 권한을 부여할 수 없습니다.

그것은 지속적인 감사 증거 (continuous audit evidence)를 생성합니다. 게이트웨이를 통하는 모든 호출은 감사 이벤트가 되므로, 검토 시점에 증거를 억지로 만들어내는 대신 시스템이 지속적으로 컴플라이언스 증거를 방출하게 됩니다.

이것이 바로 보상입니다. 하나의 제어 계층 (control plane), 당신의 가장 어려운 세 가지 문제, 그리고 부산물로서 따라오는 증거의 흐름입니다.

다음은 단순한 주장이 아닌, Azure API Management 정책으로서 구현된 병목 지점의 예시입니다. 이 코드 조각은 Entra 인증을 거친 호출자를 강제하고, 요청을 허용 목록(allowlisted)에 있는 백엔드에 고정하며, 토큰 사용량을 제한합니다.

<!-- mrd_ai_gateway_inbound_policy -->
<policies>
  <inbound>
...

그리고 배포 계층(deployment-plane)의 안전장치로서, 퍼블릭 엔드포인트에 노출된 모든 Foundry 또는 Azure OpenAI 계정을 거부하는 Azure Policy 효과의 예시입니다.

{
  "policyRule": {
    "if": {
...

검토 위원회(review board)가 아닌 파이프라인 단계에서 위반 사항을 차단하는 더 광범위한 패턴에 대해서는 Azure Policy as code for AI guardrails에 대한 가이드를 참조하세요.

게이트웨이 패턴(gateway pattern)은 Microsoft의 스택이 즉시 사용할 수 있는 형태(turnkey)로 제공하지 않는 비네이티브(non-native) 투자 영역입니다. AI 게이트웨이 기능을 갖춘 Azure API Management 또는 자체 호스팅되는 유사 솔루션을 구축하는 것이 조립 작업(assembly work)입니다. 이를 단순한 기능 활성화(toggle on)가 아닌, 아키텍처(architecture)로서 예산을 편성하십시오.

규제를 런타임 제어(runtime control)로 매핑하십시오, 아무도 대조표(crosswalk)를 건네주지 않기 때문입니다

어떤 벤더의 슬라이드보다 더 큰 신뢰를 주는 사실이 하나 있습니다: ISO 42001 조항이나 EU AI Act(EU 인공지능법) 조항을 특정 Azure 제어 항목으로 연결해 주는 공식적인 Microsoft 대조표(crosswalk)는 존재하지 않습니다. Defender for Cloud는 AI를 위한 네이티브 규제 팩(regulatory pack)을 제공하지 않습니다. 사용자가 직접 커스텀 이니셔티브(custom initiatives)를 작성해야 합니다. 즉시 사용 가능한 규제 팩이 있다는 모든 주장을 의심하십시오.

따라서 직접 매핑을 구축해야 합니다. 아래는 방어 가능한 시작점입니다. 이는 귀하의 법률 및 컴플라이언스(compliance) 검토를 대체할 수는 없지만, 구성해야 할 표의 형태를 제시합니다.

위험 계층 (Risk tier)	필수 런타임 제어 (Mandatory runtime controls)
고위험 (EU AI Act Annex III)	Azure AI Foundry 평가 게이트 (실패 시 차단) + 불변의 WORM 로깅 + 인간 참여 (human-in-the-loop) + Microsoft Purview 계보 유지 (lineage retention) + 중대한 조치를 위한 이중-LLM 패턴 (dual-LLM pattern)
...

대부분의 기사가 완전히 생략하는 미묘한 차이가 있습니다: 공급자(provider)와 배포자(deployer) 간의 책임 분할에 따라 실제로 소유하게 되는 제어 항목이 달라진다는 점입니다. 만약 모델을 미세 조정(fine-tune)하고 서비스한다면, 귀하는 공급자로서의 의무를 집니다. 만약 앱에서 타인의 모델을 소비한다면, 귀하는 배포자로서의 의무를 지며, 영향 평가(impact assessment)의 부담도 다르게 적용됩니다.

RACI 차트를 그리기 전에 이 분할을 먼저 해결하십시오. 모델의 동작에 대해 누가 책임을 지는지 알기 전에 제어 항목을 설계하는 것은, 잘못된 당사자를 보호하는 아름다운 프레임워크를 만드는 길입니다.

Microsoft의 네이티브 도구가 메우지 못하는 네 가지 격차

마케팅 서사에서 생략되는 네 가지 격차. 각각은 실재하며, 완화 가능하지만, 그 어느 것도 즉시 해결 가능한(turnkey) 솔루션은 아닙니다.

1. 에이전트 ID 확산 (Microsoft Entra)

Entra Agent ID는 현재 프리뷰(preview) 단계이며, 서드파티 (third-party) 프레임워크를 지원하지 않습니다. 만약 팀이 LangChain이나 CrewAI를 기반으로 구축한다면, 해당 에이전트들은 일급 시민(first-class) 수준의 Entra ID를 부여받지 못하며, 에이전트 간의 신뢰 체인(trust chains)은 감사(audit) 가능한 곳 어디에도 그래프로 그려지지 않습니다.

이를 완화하십시오. 모든 에이전트 기능에 기능별 최소 권한 원칙(least-privilege)을 적용한 관리형 ID (managed identity)를 부여하십시오. 에이전트 레지스트리(agent registry)를 위키(wiki) 페이지가 아닌, 엄격한 거버넌스 산출물(governance artifact)로 유지하십시오. 등록된 ID가 없는 에이전트는 실행되지 않아야 합니다.

2. 섀도우 모델 (Shadow models) (Azure AI Foundry)

이 문제는 오늘날 해결 가능하며, 저는 이에 대해 솔직하게 말씀드리고 싶습니다. 섀도우 모델 (Shadow models)은 도구의 격차가 아닙니다. 이는 아키텍처 규율(architecture-discipline)의 실패입니다.

게이트웨이(gateway)를 통한 송신(egress)을 강제하면 네트워크 계층에서 문제가 사라집니다. 모델 엔드포인트(endpoint)가 제어 평면(control plane)을 통해서만 도달 가능하다면, 추적해야 할 섀도우는 존재하지 않습니다. 이를 탐지(detection)의 문제로 취급하는 것을 멈추십시오. 이것은 라우팅(routing) 결정의 문제입니다.

3. 거버넌스 실패로서의 프롬프트 인젝션 (Prompt injection)

Microsoft는 프롬프트 인젝션 (prompt injection)을 보안 문제로 취급하며, 프롬프트 실드 (Prompt Shields)는 실질적인 완화책입니다. 하지만 보안 프레임워크는 거버넌스 질문을 놓치고 있습니다: 주입된 명령어가 침해 사고를 일으켰을 때, 누가 책임을 지는가? 그 책임의 격차는 네이티브 스택(native stack)에서 다뤄지지 않고 있습니다.

아키텍처 측면의 해답은 고위험 작업(high-consequence actions)을 LLM의 자기 권한 부여 루프(self-authorization loop) 외부에 두는 것입니다. 이중 LLM (dual-LLM) 또는 격리 (quarantine) 패턴을 사용하십시오: 신뢰할 수 없는 콘텐츠를 읽는 모델은 절대로 그 콘텐츠에 대해 실행할 수 있는 권한을 가져서는 안 됩니다. 별도의 제한된 경로가 중대한 작업에 대한 권한을 부여해야 합니다. 이에 대한 더 자세한 내용은 에이전트 워크플로에서의 프롬프트 인젝션 억제(containing prompt injection in agentic workflows)에서 다룹니다.

만약 주입된 프롬프트(injected prompt)가 인간 또는 결정론적 게이트(deterministic gate)를 거치지 않고 권한이 있는 작업(privileged action)에 도달할 수 없다면, 책임의 문제는 "필터가 잡아내길 바라는 것"에서 "아키텍처가 이를 불가능하게 만든 것"으로 전환됩니다.

4. 교차 테넌트 및 RAG 계보 단절 (Microsoft Purview)

데이터가 벡터 스토어(vector store)를 통해 흐르거나 테넌트 경계를 넘는 순간 Purview의 계보(lineage) 정보는 저하됩니다. RAG가 검색된 컨텍스트(retrieved context)를 프롬프트에 주입하는 바로 그 지점에서 엔드 투 엔드(end-to-end) 계보 그래프는 끊기게 됩니다.

민감도 레이블(sensitivity labels)을 임베딩 레이어(embedding layer)까지 유지하십시오. 검색 시점에 보안 트리밍(security trimming)을 강제하여 사용자가 권한이 없는 컨텍스트를 절대 볼 수 없도록 해야 합니다. 벡터 스토어에서 멈춰버리는 계보는 감사를 통과하지 못하는 계보입니다.

배포: 세 단계의 단계적 적용, 한꺼번에 바꾸지 마십시오

거버넌스를 한 번에 켜는 것이 아닙니다. 단계적으로 높여가야 합니다. 그렇지 않으면 첫날부터 조직 전체의 반발을 불러올 것입니다. 각각 특정 Azure 제어 기능과 연결된 세 단계로 실행하십시오.

1. 탐색 (감사 모드 정책) Azure Policy 이니셔티브와 게이트웨이 라우팅(gateway routing)을 감사 모드(audit mode)로 배포하십시오. Microsoft Purview DSPM for AI를 실행하여 민감한 데이터 흐름을 드러내십시오. 아직은 아무것도 차단하지 마십시오. 여러분은 인벤토리를 구축하고 있으며, 이미 존재하는 섀도우 모델(shadow models), 관리되지 않는 에이전트(ungoverned agents), 그리고 계보 단절 지점들을 찾아내는 과정에 있습니다. 이 단계는 향후 강제 조치를 취할 수 있는 신뢰를 쌓는 단계입니다.
2. 강제 게이트 (차단 + CI/CD 평가 게이트 + PIM) Azure Policy를 차단(deny) 모드로 전환하고, Foundry 엔드포인트에 대한 Entra 조건부 액세스(Conditional Access)를 강화하십시오. Azure AI Foundry 평가 게이트(eval gates)를 CI/CD에 연결하여, 규정을 준수하지 않는 모델이 배포 시점이 아닌 PR(Pull Request) 시점에 실패하도록 만드십시오. 권한이 있는 액세스는 Entra PIM 뒤에 배치하십시오. 이 단계에서 컴플라이언스(compliance)는 단순한 지향점이 아닌 런타임(runtime)에서 강제되는 실체가 됩니다.
3. 지속적인 증거 (불변 로그 + 자동화된 워크북) WORM 불변 로깅(immutable logging)과 Azure Policy 상태 및 게이트웨이 텔레메트리(telemetry)를 기반으로 구축된 자동화된 컴플라이언스 워크북을 활성화하십시오. 특정 시점의 승인 방식을 지속적인 증명(continuous attestation) 방식으로 교체하십시오. 이제 감사자의 런타임 질문에 대해 실시간 답변이 가능해집니다.

각 단계(phases)를 책임 소재를 흐리지 않는 RACI 모델과 결합하십시오. 각 행은 해당 단계를 구동하는 ISO 42001 조항 또는 EU AI Act(EU AI 법) 조항에 매핑됩니다.

활동 (Activity)	아키텍트 (Architect)	MLOps	컴플라이언스 (Compliance)	근거 (Drives)
리스크 등급 분류 (Risk-tier classification)	C	I	A/R	EU AI Act Art. 6, Annex III
...

모두가 거버넌스에 책임을 지면, 아무도 책임을 지지 않는 것과 같습니다. 행당 한 명의 책임 있는 소유자(accountable owner)를 지정하고, 이를 확정하기 전에 제공자(provider) 대 배포자(deployer) 간의 분리 문제를 해결하십시오.

속도를 저해하지 않으면서 확장하기

모든 엔지니어링 조직이 가진 두려움은 거버넌스가 개발자와 배포 사이를 가로막는 검토 위원회를 의미한다는 것입니다. 반드시 그럴 필요는 없습니다. 가드레일(guardrails)을 유지하면서도 속도를 높게 유지하는 네 가지 관행이 있습니다.

정책을 코드로서 왼쪽으로 이동(Shift policy-as-code left)시키십시오. 거버넌스 위반은 3주 뒤의 회의가 아니라, 개발자의 자체 피드백 루프 내인 PR(Pull Request) 단계에서 실패해야 합니다. 게이트(gate)가 앞단에 있을수록 수정 비용은 저렴해지고, 통제(gatekeeping)라는 느낌도 덜하게 됩니다.

게이팅(gating)에 계층을 두십시오. 사람에 의한 검토는 비용이 많이 듭니다. 고위험 시스템에만 검토를 할애하십시오. 최소 위험(minimal-risk) 배포는 자동화된 체크를 통과하여 바로 배포됩니다. 모든 모델 앞에 사람을 배치하면, 사람이 병목 현상(bottleneck)이 되고 사람들은 그들을 우회하려 할 것입니다.

소유권을 연방화(Federate ownership)하십시오. 중앙 플랫폼 팀은 가드레일을 소유합니다. 도메인 팀은 각자의 AI를 소유합니다. 이것이 중앙 팀이 헬프 데스크(help desk)로 전락하지 않으면서 몇 가지 유스케이스(use cases) 이상으로 확장할 수 있는 유일한 모델입니다.

시점 승인(point-in-time approvals)을 지속적인 증명(continuous attestation)으로 교체하십시오. 배포 시점에 유효했던 승인은 오늘 실행 중인 시스템에 대해 아무것도 알려주지 않습니다. 게이트웨이(gateway)로부터 얻는 지속적인 증거(continuous evidence)가 폴더 안에 서명된 양식보다 훨씬 가치 있습니다.

요약 (The takeaway)

문서 속에만 존재하는 거버넌스는 잘못된 안도감을 만들어내며, 이를 감사(audit)하는 업무를 맡은 사람들은 그 바인더의 허점을 즉각 간파할 수 있습니다. 해결책은 더 많은 문서화가 아닙니다. 단 하나의 아키텍처 결정입니다. 즉, 필수적인 AI 게이트웨이(AI gateway)를 Microsoft Entra, Microsoft Purview, 그리고 Azure AI Foundry 전반에 걸친 보편적인 제어 평면(control plane)으로 만들고, 이를 코드형 정책(policy-as-code) 기반의 잘 닦인 길(paved roads)로 감싸서, 컴플라이언스(compliance)가 가장 저항이 적은 경로가 되도록 만드는 것입니다.

그렇게 하면 섀도 모델(shadow models)의 연결이 차단되고, 에이전트 확산(agent sprawl)은 병목 지점에 도달하며, 시스템은 지속적으로 감사 증거(audit evidence)를 생성합니다. 감사자의 질문은 더 이상 위협이 아니라 데모(demo)가 됩니다.

검증 참고 사항: 여기서 언급된 여러 기능(Entra Agent ID, Purview-Foundry 추적 캡처, 벡터 스토어 계보(vector-store lineage))은 2025년 초 기준으로 프리뷰(preview) 상태이거나 빠르게 변화하고 있습니다. 아키텍처를 확정하기 전에 Microsoft 문서를 통해 현재 상태를 확인하십시오. 거버넌스 원칙은 어떤 프리뷰 기능이 출시되든 상관없이 유효하지만, 기능 명칭은 변경될 수 있습니다.

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