Azure MCP Server 2.0으로 클라우드 점검 에이전트를 만들기 전, 먼저 줄일 것들

Azure MCP Server 2.0은 "AI가 클라우드를 운영하게 하는 도구"라기보다, 먼저 읽기·점검·권고 범위로 제한한 뒤 권한과 도구 목록을 검증해야 하는 연결 지점입니다.

들어가며 — 독자가 지금 이 문제를 검색하는 이유

Azure 리소스가 늘어날수록 운영자는 비슷한 질문을 반복하게 됩니다.

"이 구독에 어떤 리소스가 있지?"

"최근 설정 중 위험한 항목은 없나?"

"장애가 났을 때 어디부터 봐야 하지?"

"이걸 AI 에이전트가 대신 점검하게 만들 수 없을까?"

Azure MCP Server 2.0은 이런 질문과 맞닿아 있습니다. Microsoft의 microsoft/mcp 저장소에는 Azure MCP Server가 포함되어 있고, 리서치 기준으로 Azure MCP Server 2.0 GA가 명시되어 있습니다. 기존 Azure/azure-mcp 저장소는 보관 처리되었고 microsoft/mcp로 이전된 상태입니다. 저장소 상태는 microsoft/mcp GitHub 저장소와 GitHub API 응답에서 확인할 수 있습니다.

다만 이 글의 초점은 "AI에게 Azure를 마음껏 맡기는 법"이 아닙니다.

오히려 처음에는 얼마나 못 하게 만들 것인가에 가깝습니다.

클라우드 운영 에이전트를 잘못 연결하면 편리한 점검 도구가 아니라 권한이 넓은 운영 계정이 됩니다. 그래서 첫 적용 목표는 자동 조치가 아니라 "Azure 리소스 권한·도구 범위 검증표"를 만드는 쪽이 안전합니다.

Azure MCP Server 2.0은 무엇을 연결하는가

Azure MCP Server는 MCP를 지원하는 AI 클라이언트가 Azure 리소스와 상호작용할 수 있게 해주는 서버입니다. 공식 문서는 Azure MCP Server README에서 확인할 수 있습니다.

여기서 중요한 점은 MCP가 단순 검색 API가 아니라는 것입니다. 에이전트는 MCP 서버가 노출한 도구를 호출할 수 있습니다. 즉, 어떤 도구를 열어두느냐가 곧 에이전트의 행동 범위가 됩니다.

이번 적용 시나리오는 이렇게 잡는 편이 안전합니다.

• 목적: Azure 리소스 상태를 조회하고 운영 점검 브리프를 만든다.
• 제외: 리소스 생성, 삭제, 변경, 데이터 수정, 운영 반영 자동화
• 산출물: "Azure 리소스 권한·도구 범위 검증표"
• 검증 기준: 에이전트가 실제로 어떤 도구를 호출했고, 어떤 권한에서 실패하거나 성공했는지 기록한다.

특히 리서치에 따르면 Azure MCP Server의 일부 도구에는 destructive 또는 non-read-only 성격이 명시되어 있습니다. DB query 같은 도구가 여기에 포함될 수 있습니다. 따라서 "조회니까 괜찮겠지"라고 묶어 보면 안 됩니다. 읽기처럼 보이는 작업도 데이터베이스 질의 방식에 따라 위험도가 달라질 수 있습니다.

준비물: 설치보다 먼저 정해야 할 권한 범위

Azure MCP Server를 붙이기 전에 먼저 네 가지를 정해야 합니다.

첫째, 어떤 Azure 계정으로 로그인할지 정합니다.

공식 문서와 문제 해결 문서에서는 az login 흐름을 확인해야 합니다. 다만 실제 사용 가능 범위는 조직의 Azure RBAC, 테넌트, 구독 설정에 따라 달라집니다. 이 부분은 확인 필요 항목으로 두어야 합니다.

둘째, 처음부터 관리자 권한을 쓰지 않습니다.

PoC 단계에서 가장 쉬운 방법은 권한이 넓은 계정을 붙이는 것입니다. 하지만 클라우드 운영 에이전트에서는 이 방식이 가장 위험합니다. 처음에는 리소스 조회와 점검에 필요한 최소 권한으로 시작해야 합니다.

셋째, MCP 서버가 노출하는 도구 목록을 확인합니다.

에이전트가 "무엇을 할 수 있는지"는 프롬프트보다 도구 목록이 더 직접적으로 결정합니다. Azure MCP Server README에서 현재 제공되는 도구와 사용 조건을 확인하고, 조직에서 허용할 도구와 막을 도구를 나눠야 합니다.

넷째, 실패 로그를 일부러 남깁니다.

연결이 한 번에 성공하는지만 보면 운영 준비가 된 것처럼 착각하기 쉽습니다. 실제로는 권한 부족, 구독 선택 오류, 테넌트 불일치, 인증 만료 같은 실패가 어떻게 드러나는지가 더 중요합니다. 문제 해결 기준은 Azure MCP Server TROUBLESHOOTING 문서를 기준으로 잡을 수 있습니다.

최소 적용 단계: "점검 브리프" 하나만 만든다

처음부터 장애 대응, 비용 최적화, 보안 점검, 리소스 변경까지 한 번에 연결하지 않는 편이 좋습니다. 첫 업무 결과물은 하나면 충분합니다.

예를 들어 "Azure 리소스 점검 브리프"를 목표로 잡습니다.

브리프에 들어갈 내용은 다음 정도로 제한합니다.

• 연결된 구독 또는 범위
• 조회 가능한 리소스 종류
• 에이전트가 호출한 MCP 도구
• 성공한 조회와 실패한 조회
• 권한 부족으로 실패한 항목
• 운영자가 직접 확인해야 할 항목
• 변경 작업이 필요한 경우의 승인 요청 문구

적용 순서는 이렇게 가져갈 수 있습니다.

1. 공식 저장소를 확인합니다.

Azure MCP Server의 현재 위치는 microsoft/mcp입니다. 기존 Azure/azure-mcp 저장소가 아니라 현재 유지되는 저장소를 기준으로 문서를 봅니다.

2. Azure MCP Server README에서 설치와 클라이언트 연결 방식을 확인합니다.

클라이언트별 설정은 환경에 따라 달라질 수 있으므로, 공식 README를 기준으로 맞춥니다.

3. az login 인증 흐름을 확인합니다.

로그인된 계정, 테넌트, 구독이 의도한 범위인지 확인합니다. 여기서부터 조직별 확인 필요 항목이 생깁니다.

4. RBAC 권한을 읽기·점검 중심으로 제한합니다.

처음에는 변경 권한을 전제로 잡지 않습니다. 에이전트가 실패해야 하는 작업은 실패해야 합니다.

5. MCP 도구 목록을 검토합니다.

도구 이름만 보지 말고, 해당 도구가 read-only인지, non-read-only인지, destructive 가능성이 있는지 확인합니다. DB query처럼 주의가 필요한 도구는 별도 표시합니다.

6. 에이전트에게 한 가지 결과물만 요청합니다.

"현재 구독의 리소스를 점검하고, 변경 없이 확인 결과와 확인 필요 항목만 정리해줘"처럼 범위를 좁힙니다.

7. 실패 로그를 검토합니다.

인증, 권한, 구독 선택, 도구 호출 실패가 어떻게 나타나는지 TROUBLESHOOTING 문서를 기준으로 확인합니다.

이 과정을 거치면 "AI가 답을 잘했는가"보다 더 중요한 것이 보입니다.

에이전트가 어디까지 접근했고, 어디서 막혔고, 어떤 도구를 실제로 호출했는지입니다.

권한·도구 범위 검증표 예시

아래 표는 첫 적용 때 그대로 복사해 점검표로 쓸 수 있는 형태입니다. 실제 값은 조직 Azure 환경에서 확인해야 합니다.

점검 항목	확인 내용	상태
공식 저장소	microsoft/mcp 기준 문서를 사용했는가	확인 필요
이전 저장소 혼동	기존 Azure/azure-mcp가 아니라 이전된 저장소를 기준으로 했는가	확인 필요
인증 방식	az login 계정이 의도한 사용자 또는 서비스 계정인가	확인 필요
테넌트	연결된 테넌트가 운영 대상과 일치하는가	확인 필요
구독 범위	에이전트가 접근 가능한 구독이 필요한 범위로 제한되어 있는가	확인 필요
RBAC	처음 적용 권한이 읽기·점검 중심인가	확인 필요
도구 목록	Azure MCP Server가 노출한 도구 목록을 확인했는가	확인 필요
위험 도구	destructive 또는 non-read-only 성격의 도구를 별도 표시했는가	확인 필요
DB query	데이터 조회·질의 도구의 위험도를 별도 검토했는가	확인 필요
변경 작업	생성·수정·삭제 작업을 기본 차단했는가	확인 필요
실패 로그	권한 부족과 인증 실패가 운영자가 이해할 수 있게 남는가	확인 필요
승인 단계	변경이 필요한 경우 사람 승인 단계가 있는가	확인 필요
결과물	에이전트의 산출물이 "점검 브리프"로 제한되어 있는가	확인 필요

이 표의 핵심은 "가능한 기능 목록"이 아닙니다.

운영에 넣기 전에 "막혀야 할 것이 실제로 막히는지" 보는 것입니다.

바로 적용하는 체크리스트

Azure MCP Server 2.0을 클라우드 점검 에이전트에 붙이기 전, 최소한 아래 항목은 확인하는 편이 좋습니다.

• [ ] 현재 문서 기준 저장소가 microsoft/mcp인지 확인했다.
• [ ] Azure MCP Server 공식 README를 기준으로 설치·연결 방식을 확인했다.
• [ ] az login 계정, 테넌트, 구독 범위를 확인했다.
• [ ] 조직 Azure RBAC 기준으로 읽기·점검 권한부터 시작했다.
• [ ] MCP 서버가 노출하는 도구 목록을 확인했다.
• [ ] destructive 또는 non-read-only 성격의 도구를 별도 분류했다.
• [ ] DB query 등 데이터 접근 도구의 위험도를 검토했다.
• [ ] 에이전트의 첫 업무를 "리소스 점검 브리프 작성" 하나로 제한했다.
• [ ] 변경 작업은 기본 차단하고, 필요한 경우 사람 승인 단계를 두었다.
• [ ] 실패 로그를 TROUBLESHOOTING 문서와 대조했다.
• [ ] 실제 사용 가능 도구와 권한은 조직 테넌트·구독·RBAC 설정별로 확인 필요라고 표시했다.

마무리 + 생각해볼 질문 1개

Azure MCP Server 2.0을 붙이면 AI 에이전트가 Azure 운영 정보를 더 쉽게 다룰 수 있습니다. 하지만 첫 목표를 "자동 운영"으로 잡으면 위험합니다. 먼저 볼 것은 에이전트가 답을 잘하는지가 아니라, 에이전트가 하지 말아야 할 일을 못 하게 만들 수 있는지입니다.

처음 산출물은 단순할수록 좋습니다.

"Azure 리소스 점검 브리프" 하나를 만들고, 그 과정에서 인증, RBAC, 도구 목록, 실패 로그를 검증합니다. 더 넓은 운영 자동화는 그다음에 논의해도 늦지 않습니다.

생각해볼 질문은 이것입니다.

우리 조직의 Azure 환경에서 AI 에이전트가 "조회는 가능하지만 변경은 못 하는 상태"를 실제로 증명할 수 있는가?