장애 대응의 첫 시간을 줄이다: Microsoft Smart DRI Agent의 월 600시간 절감 사례
서비스 장애가 발생하면 담당 엔지니어는 해결책을 찾기 전에 먼저 상황을 모아야 합니다. 모니터링 포털, 로그 대시보드, 장애 대응 가이드, SharePoint, OneNote를 오가다 보면 정작 문제를 해결할 시간이 줄어듭니다. 처음 맡는 서비스라면 누구에게 물어야 하는지부터 찾아야 합니다.
Microsoft의 사내 IT 조직인 Microsoft Digital과 HR 조직의 엔지니어들은 이 문제를 Smart DRI Agent로 풀었습니다. 여러 시스템에 흩어진 운영 정보를 모으고, 유사 장애와 대응 절차를 제시하며, 엔지니어가 일하는 Teams 안에서 필요한 맥락을 전달하는 에이전트입니다.
2026년 10월 15일 UTC, 한국 시간 10월 16일에 공개된 Inside Track 사례에 따르면, 이 에이전트는 40개 넘는 팀을 지원하며 월 약 600 엔지니어링 시간을 절감한 것으로 추정됩니다. 이 글은 상용 제품의 GA 발표가 아니라 Microsoft 내부 구현·운영 사례입니다.
DRI가 찾는 것은 답변 한 줄이 아니라 판단할 맥락
DRI는 Designated Responsible Individual, 즉 운영 상황을 책임지는 담당자를 뜻합니다. Microsoft Digital에서는 엔지니어가 순환 근무로 프로덕션 장애 조사, 서비스 상태 점검, 보안 관련 작업 검토와 다른 운영 이슈를 맡습니다.
문제는 정보가 분산되어 있다는 점입니다. 여러 포털과 대시보드에 접속하고, 필요한 운영 권한을 활성화하고, 문서를 찾고, 과거 사례와 대조해야 합니다. 이 과정에서 맥락이 누락되거나 인수인계 시간이 길어집니다.
원문에서 Payal Awasthi는 새 장애가 들어올 때 통찰을 얻기 위해 여러 프로덕션 권한을 활성화해야 하는 상황을 설명합니다. 팀이 원한 것은 정보를 한곳에 모아 탐색과 전환 시간을 줄이는 것이었습니다. 이를 에이전트가 보안 권한을 우회하거나 엔지니어에게 불필요한 권한을 부여한다는 의미로 해석해서는 안 됩니다.
성과: 40개 넘는 팀, 7,800회 이상의 AI 지원 상호작용
| 지표 | 원문에 공개된 규모 |
|---|---|
| 지원 팀 | 40개 초과 |
| AI 지원 상호작용 | 7,800회 초과 |
| 선제적 장애 알림 | 약 6,000건 |
| 시간 절감 | 월 약 600 엔지니어링 시간으로 추정 |
상호작용·알림 수의 집계 기간은 원문에서 구체적으로 제시하지 않았습니다. 따라서 두 수치를 월간 실적으로 표시하지 않습니다. 600시간 역시 Microsoft 내부의 추정 절감치이며, 모든 조직에 같은 효과가 보장되는 수치는 아닙니다.
의미 있는 부분은 장애를 모두 자동 복구했다는 것이 아니라, 담당자가 이미 정리된 정보를 가지고 대응을 시작하게 되었다는 점입니다. 정보 수집과 컨텍스트 전환을 줄여 사람이 더 빨리 판단하도록 한 것입니다.
해커톤 시제품을 여러 팀의 공통 도구로 바꾸기
초기에는 Microsoft Digital과 HR 조직이 서로 다른 해법을 검토했습니다. 같은 운영 문제를 풀고 있다는 사실을 확인한 뒤 힘을 합쳤고, 해커톤에서 첫 버전을 만들었습니다.
이후에는 목표와 30·60·90일 계획을 세워 여러 서비스가 온보딩할 수 있는 형태로 발전시켰습니다. 원문에서 내부 오픈소스 프로젝트로 언급되지만, 이는 외부에 소스코드가 공개되어 누구나 설치할 수 있다는 발표는 아닙니다.
여러 DRI 팀을 인터뷰하면서 서비스별 대응 방식과 인수인계 보고서 요구가 달라졌고, 팀은 2~3개월간 이 차이를 다루는 데 어려움을 겪었습니다. 해결 방향은 요청마다 하드코딩을 늘리는 것이 아니었습니다.
핵심 로직과 설정을 분리하고, 팀이 인수인계 보고 같은 워크플로의 템플릿을 제공하도록 바꿨습니다. 공통 운영 기능은 재사용하면서 서비스별 차이는 설정으로 수용한 것입니다.
구현의 중심: Semantic Kernel과 Azure AI Search
요청에 맞는 운영 함수를 고르는 오케스트레이션
팀은 Microsoft Semantic Kernel을 오케스트레이터로 사용했습니다. 장애 관리와 Service 360 같은 운영 도메인마다 별도의 함수 집합을 두고, 요청에 따라 호출할 함수를 결정합니다.
프레임워크만 연결한 것은 아닙니다. 좋은 결과와 시스템 내 탐색 경험을 위해 상당한 사용자 정의 코드를 함께 구현했습니다. 원문은 구체적인 모델명, 인증 구현, 배포 템플릿이나 API 스키마를 공개하지 않으므로, 특정 모델이나 완성형 구축 절차를 이 사례에서 단정할 수는 없습니다.
인덱싱만으로 부족했던 유사 장애 검색
유사 장애 검색에는 Azure AI Search를 사용해 장애 정보를 인덱싱했습니다. 그러나 검색 인덱스만으로 항상 유용한 사례가 나오지는 않았습니다. 개발팀은 유사성을 판단하는 별도의 로직을 추가해 DRI에게 제공할 결과의 관련성을 개선했습니다.
이 지점은 사내 에이전트 개발자가 특히 주목할 만합니다. 검색 연결 여부와 실제 업무에 도움이 되는 검색 품질은 다릅니다. 과거 장애를 찾아도 서비스 맥락이나 증상 패턴이 맞지 않으면 대응 판단에 쓰기 어렵습니다. 원문은 추가 로직의 구체적인 알고리즘이나 정확도 수치를 공개하지 않았습니다.
장애 발생부터 아침 브리핑까지
현재 사례에서 에이전트가 돕는 흐름은 다음과 같습니다.
- 장애 맥락 수집: 제목, 설명과 다른 장애 정보를 바탕으로 상황을 파악합니다.
- 대응 자료 연결: troubleshooting guide에서 관련 패턴을 찾고 대응 방법을 설명합니다.
- 과거 사례 제공: 비슷한 문제의 이력과 맥락을 함께 보여줍니다.
- 최근 텔레메트리 조회: 최근 몇 분간의 관련 trace, log, exception을 가져옵니다.
- Teams로 전달: 분석과 권장 조사 절차를 엔지니어가 일하는 환경에 제공합니다.
에이전트는 질문에 답하는 방식만 지원하지 않습니다. 아침에 그날 처리할 일을 정리한 요약을 보내는 것처럼 선제적인 정보 전달도 수행합니다. 반응형 질의와 자동 알림을 한 업무 흐름 안에서 함께 설계한 것입니다.
자동 조치는 아직 미래 계획: 사람의 승인이 경계선
원문은 향후 버전에서 에이전트가 일부 장애 완화 조치를 실제로 수행하고, DRI가 과정에 참여하며 조치에 승인할 수 있도록 발전시키고 싶다고 설명합니다.
따라서 현재 공개된 정보 수집·분석·권고 기능과 앞으로의 실행 계획은 구분해야 합니다. 이 사례를 이미 사람 없이 프로덕션을 자동 복구하는 시스템이라고 소개하면 과장입니다.
더 중요한 전제는 live site 운영 문화입니다. 서비스의 신뢰성과 상태를 우선하고, 담당자가 제공된 정보를 검토하고 행동하는 체계가 있어야 합니다. 에이전트의 목적은 운영 책임자를 없애는 것이 아니라 그 사람이 더 잘 일하도록 돕는 것입니다.
한국 기업의 도입 체크포인트
다음은 원문의 경험을 한국 조직에 적용할 때의 실무 제안입니다. Microsoft가 이 사례의 세부 보안·운영 사양으로 공개한 내용과는 구분합니다.
| 영역 | 시작 전에 확인할 사항 |
|---|---|
| 문제 정의 | 담당자가 정보를 모으는 데 오래 걸리는 단계와 반복 작업부터 찾습니다. |
| 데이터 연결 | 장애 이력, 대응 가이드, 서비스 문서, 텔레메트리의 소유자와 접근 범위를 정합니다. |
| 검색 평가 | 실제 장애 사례로 관련성·누락·잘못된 유사 사례를 평가하고 도메인 로직을 보완합니다. |
| 팀별 차이 | 인수인계 보고서와 작업 흐름을 템플릿·설정으로 분리합니다. |
| 전달 방식 | 질의응답과 선제 알림을 함께 설계하되 중복·불필요한 알림을 관리합니다. |
| 운영 책임 | 권고 검토자, 실행 승인자, 오류 시 대응 주체를 명확히 합니다. |
| 성과 측정 | 정보 수집 시간, 인수인계 소요, 알림의 유용성과 실제 대응 결과를 따로 봅니다. |
작게 시작한다면 한 서비스의 장애 맥락 수집과 인수인계 보고가 후보가 될 수 있습니다. 먼저 조회·요약의 정확성과 유용성을 확인한 다음, 변경·복구 같은 실행 권한은 별도의 승인·감사 체계와 함께 검토하는 편이 합리적입니다.
또한 탐지부터 맥락 수집, 장애 완화, 개선 활동까지 담당자가 어느 단계에서든 도움을 받을 수 있어야 합니다. 특정 질문에만 답하는 데 그치지 않고, 운영 기능을 분리해 다른 에이전트 경험에서도 재사용할 수 있도록 설계하는 것이 원문의 교훈입니다.
시작하기와 마무리
구현 기술은 Semantic Kernel 공식 문서와 Azure AI Search 제품 안내에서 살펴볼 수 있습니다. 다만 이것이 Smart DRI Agent 자체의 외부 배포나 Copilot Studio용 완성 템플릿을 제공한다는 뜻은 아닙니다.
이번 사례의 핵심은 화려한 자율 실행보다 필요한 운영 맥락을 제때 모으는 것입니다. 검색 품질을 실제 장애로 검증하고, 팀별 차이를 설정으로 수용하며, 사람의 운영 책임을 유지했을 때 에이전트가 실질적인 시간을 돌려줄 수 있음을 보여줍니다.
출처: Automating engineering operations at Microsoft with a Smart DRI Agent — Microsoft Inside Track, 2026년 10월 15일 UTC(한국 시간 10월 16일). 자세한 내용은 원문 참조.