Microsoft Purview, Power Automate, Copilot Studio로 AI GRC 에이전트 구축

거버넌스, 리스크, 규정 준수(GRC) 보고는 많은 조직에서 여전히 수작업으로 이루어집니다. 감사 로그를 내보내 엑셀에 붙여 넣고, 필터를 걸고, 피벗 테이블을 만들다 보면 서로 모순되는 시트만 늘어납니다. 다음 주에 새로운 활동이 생기면 어제의 깔끔한 차트는 이미 낡은 자료가 됩니다.

이 글에서는 Microsoft Purview, Power Automate, Copilot Studio를 조합해 감사 로그 수집부터 분석, 자연어 보고서 작성과 배포까지 맡는 AI GRC 에이전트의 구조를 단계별로 설명합니다. 핵심은 에이전트가 추측하지 않고, 사람이 정의한 규칙을 따라 움직인다는 점입니다.

수동 GRC 보고가 한계에 부딪히는 이유

수동 GRC 보고는 문서화를 통찰로 착각할 때 생깁니다. Purview에서 데이터를 내보내 스프레드시트에 늘어놓고 그것을 거버넌스라고 부르는 식입니다. 책임성을 높여야 할 감사 추적이 오히려 담당자의 번아웃만 키웁니다.

더 큰 문제는 Purview를 감사 직전에만 여는 금고처럼 다루는 관행입니다. 감사 로그에는 누가, 어디서, 언제, 무엇을 했는지가 대량으로 쌓입니다. 그런데 각 항목이 중첩된 JSON 덩어리라 사람이 읽기는 거의 불가능합니다. 데이터는 넘쳐나지만 해석할 수단이 없는 것이 근본 원인입니다.

GRC 에이전트란 무엇인가: 세 가지 구성 요소

GRC 에이전트는 지능을 흉내 내는 마법이 아니라 Microsoft 스택 위에 구축한 구조화된 자동화입니다. 역할은 사람의 인지 과정에 빗대어 나눌 수 있습니다.

• Microsoft Purview(원시 메모리): 감사 로그, 분류 데이터, 규정 준수 이벤트를 기록합니다. Microsoft 365 안의 사용자 활동, 문서 공유, 정책 생성, 보존 정책 수정 등이 대상입니다.
• Power Automate(신경계): 정해진 시간에 신호를 수집하고 노이즈를 거르며, 모든 단계를 빠짐없이 실행합니다. 실패하면 조용히 멈추고 원인을 로그로 남깁니다.
• Copilot Studio(번역가): 구조화된 데이터를 사람이 읽을 수 있는 요약으로 바꿉니다. 프롬프트에 내장된 규칙을 따를 뿐 추측하지 않습니다.

규정 준수 업무의 상당 부분은 판단이 아니라 패턴 인식입니다. 이 스택은 사람처럼 생각하는 대신 사람보다 일관되게 분류하고 요약하도록 설계되어 있습니다. 논리, 빈도, 범위, 문구까지 모두 직접 정의하므로 결과도 결정론적입니다. 대시보드는 상황을 보여줄 뿐이지만, 이 에이전트는 패턴을 문장으로 설명합니다.

Purview 데이터 파이프라인 구축하기

에이전트가 생각하려면 먼저 볼 수 있어야 합니다. 이를 위해 Purview 감사 데이터의 필요한 부분에만 접근하는 파이프라인을 만듭니다.

1. 추출과 범위 제한

Purview 내장 커넥터를 쓰거나, HTTP 작업으로 Purview 감사 로그 API를 직접 호출할 수 있습니다. 어느 쪽이든 파일 공유, 권한 변경, 접근 위반, 관리자 로그인 같은 활동 스트림을 얻습니다. 전체 피드를 가져오기보다 규정 준수에 실제로 영향을 주는 이벤트를 먼저 정의하고 범위를 좁히는 편이 효율적입니다.

2. 접근 제어

Power Automate는 부여된 권한 안에서만 동작합니다. 서비스 계정에 Purview의 감사 로그 읽기 역할이 있어야 하고, MFA 때문에 인증이 막히지 않아야 합니다. 자격 증명은 신중하게 할당하고 Azure Key Vault 또는 연결 참조에 저장해 규정을 지키면서 자동화를 유지합니다.

3. 필터링

모든 이벤트가 필요하지는 않습니다. 실제 위험 신호만 골라냅니다.

• 새로운 위치에서의 사용자 로그인
• 역할 할당 변경
• 외부 공유 실행
• 정책 수정

필터링은 API 쿼리 단계에서 해도 되고, Power Automate 조건부 논리로 후속 단계에서 해도 됩니다. 중요한 것은 데이터를 모으는 것이 아니라 선별하는 것입니다.

4. JSON 구문 분석

샘플 Purview 이벤트에서 추출한 스키마로 JSON 구문 분석 작업을 수행해, 사용자 ID, 작업, 워크로드, 결과 상태, 클라이언트 IP 같은 속성을 각각의 변수로 만듭니다. 일부 감사 필드는 값이 하나여도 배열로 나타나고, 어떤 필드는 여러 겹의 중첩 안에 결과를 숨깁니다. 이런 구조는 Power Automate 표현식으로 처리하며, 작은 오타 하나가 나중에 엉터리 데이터를 만들 수 있으니 작은 샘플로 각 추출 과정을 테스트해야 합니다.

5. 저장소와 예약

정리된 데이터는 SharePoint, Dataverse 또는 SQL 데이터베이스에 보관합니다. 이 저장소는 단기 기억 역할을 하며, Purview를 반복 호출하지 않고도 과거 데이터를 비교할 수 있게 해 줍니다. 열 중심 기능이나 데이터 세트 간 관계가 필요하면 Dataverse가 Power Automate와 더 잘 맞고, SharePoint는 쉽지만 수천 행을 넘어가면 다루기 까다롭습니다.

주기는 변화가 많은 환경이면 일일 요약, 안정적인 환경이면 주간 요약으로 정합니다. Recurrence 트리거를 UTC가 아닌 자신의 시간대에 맞춰야 보고서가 엉뚱한 시각에 도착하지 않습니다.

Power Automate로 에이전트의 논리 계층 만들기

Power Automate는 AI가 아닙니다. 추측하거나 위험을 지어내지 않고, 정해진 단계를 그대로 따릅니다. 그 예측 가능한 경직성이 자율성의 바탕입니다. 논리 계층은 다음 순서로 구성합니다.

1. 반복 트리거: 감사인이 있는 시간대에 맞춰 요청 없이 플로우가 시작되게 합니다.
2. 초기화 블록: 총 이벤트 수, 고위험 건수, 보고 날짜 같은 변수와 배열을 선언합니다. 에이전트의 작업 기억이 됩니다.
3. 호출과 필터: Purview 커넥터나 HTTP API를 호출한 뒤 Filter array로 불필요한 데이터를 제거합니다. 예를 들어 사용자 유형이 서비스 주체인 레코드는 무시하고, 데이터 거버넌스나 정책 변경 관련 작업만 남깁니다.
4. 중복 제거: 로그 스트림이 같은 이벤트를 반복하는 경우가 많으므로 union 표현식이나 루프 비교로 중복을 없앱니다.
5. 집계: Compose 또는 Select로 사용자 계정 이름과 작업별로 그룹화하고, Apply to each 루프에서 범주별 합계를 구합니다.
6. 위험 수준 판정: 임계값에 따라 수준을 정합니다.

예를 들어 권한 상승이 3회 발생하면 위험 수준을 높음, 외부 공유가 1회 발생하면 중간, 그 외에는 정상으로 설정합니다. 이 방식은 의미를 꾸며내는 것이 아니라 기준을 코드로 강제하는 것입니다. 중첩 조건 작업으로 높음은 고위험 배열에, 중간은 검토 대기열에 추가합니다.

이상 징후가 없을 때는 침묵하지 말고 "발견 사항 없음" 메시지를 기록해야 합니다. 규정 준수에서는 데이터 누락과 데이터 없음의 차이가 매우 중요하기 때문입니다.

Copilot Studio로 보고서 작성하기

여기까지 만든 에이전트는 효율적이지만 말이 없습니다. Copilot Studio가 JSON 데이터를 사용자 활동, 위험 집계, 이벤트 기록에 대한 읽기 쉬운 문단으로 바꿔 줍니다.

보고서 유형과 프롬프트 설계

먼저 커뮤니케이션 유형을 정합니다. 보통 임원 요약, 기술 부록, 권장 사항의 세 가지입니다. 경영진은 짧은 요약을, 감사인은 증거 추적 자료를, IT 담당자는 모든 항목을 원합니다. 하나의 Copilot 안에 여러 프롬프트를 두고 각각 어조, 형식, 상세 정도를 지정합니다.

Power Automate와 연결

플로우의 HTTP 작업으로 구조화된 JSON 페이로드를 Copilot 엔드포인트 URL에 게시합니다. Copilot은 정의된 시스템 프롬프트로 이를 해석하고, 호출은 Azure AD 인증으로 보호되어 플로우에서만 접근할 수 있습니다. 반환값은 숫자가 아니라 텍스트이며, 그 텍스트가 곧 보고서입니다.

결과는 분석가의 메모와 비슷합니다. 위험 행동이 감지된 사용자와 초과한 임계값을 밝히고, 관리자 역할 검토나 외부 데이터 정책 안내 같은 조치를 권장하며, 마지막에 전체 추세를 정리합니다. 이는 생성형 추측이 아니라 결정론적 프롬프트를 따르는 서식화된 합성입니다.

배포

같은 플로우를 두 갈래로 나눕니다. 한쪽은 Copilot 요약을 Teams 채널에 바로 게시하고, 다른 쪽은 전체 HTML 버전을 SharePoint에 기록합니다. 경영진은 Teams 게시물을, 감사인은 SharePoint 아카이브를 확인하며, 둘 다 동일한 문구와 자동 타임스탬프로 도착합니다.

프롬프트 엔지니어링과 감사 가능성 확보

규정 준수는 개성이 아니라 재현 가능성에서 나옵니다. 지침이 엄격할수록 결과물도 일정해집니다.

• 제목 고정: 개요, 주요 결과, 권장 사항처럼 정확한 제목을 지정합니다.
• 어조 지정: 전문적이고 중립적인 어조를 쓰고 추측성 표현을 피하며 정량화 가능한 지표를 포함하게 합니다.
• 컨텍스트 변수: 보고서 날짜와 레코드 개수 자리 표시자를 사용하면 "생성일", "분석된 감사 이벤트 수" 같은 메타 컨텍스트가 자동으로 들어갑니다.
• 응답 검증: Copilot 응답이 비어 있지 않은지 확인하는 조건을 넣고, 비어 있으면 실패를 로그에 남깁니다.
• 프롬프트 버전 관리: 규정 기준이 바뀔 때마다 시스템 프롬프트에 V1, V1.1 같은 태그를 붙이고, 어떤 버전이 어떤 보고서를 만들었는지 기록합니다.

이렇게 하면 향후 감사에서 무슨 일이 있었는지뿐 아니라 당시 서술 모델이 어떤 지시를 받았는지도 확인할 수 있습니다.

자주 하는 실수와 오류 처리

자동화는 제공한 것만 정확히 수행하고 그 이상은 하지 않습니다. 다음은 대표적인 함정입니다.

• 권한 부족: 서비스 계정에 감사 로그 읽기 역할이 없으면 에이전트는 로그를 읽지 못한 채 "문제 없음"이라고 보고합니다. 이는 안심이 아니라 성공으로 위장한 무지입니다.
• 범위 미설정: 전체 감사 피드를 가져오면 플로우가 스스로 과부하에 빠집니다.
• 표현식 오타: 배열과 중첩 구조를 다루는 표현식의 사소한 오류가 엉터리 데이터로 이어집니다.
• 시간대 불일치: UTC 기준으로 두면 보고서가 예상치 못한 시각에 도착합니다.
• 결과 없음 미기록: 이상 징후가 없다는 사실도 남기지 않으면 누락과 구분할 수 없습니다.
• 프롬프트 지침 부족: 제목과 어조를 지정하지 않으면 Copilot이 감사 보고서에 어울리지 않는 표현을 넣을 수 있습니다.

오류는 발생하기 마련이므로 대비책도 필요합니다. 모든 HTTP 호출을 재시도 정책이 활성화된 범위(Scope) 안에 넣고, 지수 백오프로 3회 시도하게 합니다. 실패 분기에서는 오류 메시지, 타임스탬프, 플로우 실행 ID를 SharePoint 목록이나 Dataverse 테이블에 기록하고, 임계값을 넘으면 Teams 메시지로 알립니다. 감사인은 오류 자체가 아니라 오류에 대한 문서 누락을 문제 삼습니다.

모든 실행에는 증거를 남깁니다. 총 처리 이벤트 수, 최고 위험 사용자, 실행 시간 같은 요약 지표와 함께 실행 ID와 플로우 버전을 저장하면, 기준치가 바뀌어도 어떤 논리가 어떤 결과를 냈는지 추적할 수 있습니다.

실무 적용을 위한 핵심 정리

• Purview는 수집, Power Automate는 실행과 판단, Copilot Studio는 서술을 맡도록 역할을 분리하세요.
• 규정 준수에 영향을 주는 이벤트만 정의해 범위를 좁히세요.
• 서비스 계정의 감사 로그 읽기 역할과 MFA 인증을 먼저 확인하고, 자격 증명은 Azure Key Vault나 연결 참조에 보관하세요.
• JSON은 샘플 이벤트 기반 스키마로 구문 분석하고, 작은 샘플로 반복 테스트하세요.
• 위험 수준은 임계값으로 코드화하고, 이상 없음도 메시지로 기록하세요.
• 모든 HTTP 호출에 재시도 정책을 적용하고, 실패는 로그와 Teams 알림으로 관리하세요.
• 프롬프트에 제목, 어조, 지표 규칙을 명시하고 버전을 관리하세요.
• Teams에는 요약, SharePoint에는 전체 HTML 보고서를 게시해 독자별로 배포하세요.

결론

이 에이전트의 장점은 속도보다 표준화에 있습니다. 보고서마다 같은 어조, 같은 임계값, 같은 메타데이터가 적용되므로 감사인은 형식 검증에 시간을 쓰지 않고 실질적인 내용을 평가할 수 있습니다. Purview가 수집하고 Power Automate가 해석하며 Copilot Studio가 설명하는 구조 덕분에 규정 준수는 감사 직전의 문서 작업에서 상시 가동되는 오케스트레이션으로 바뀝니다. 이 파이프라인을 갖춰 두면 이후 데이터 개인정보 보호 집행 같은 영역으로 확장하는 기반도 마련됩니다.