코딩 에이전트에서 클라우드 자동화로: Azure Functions에서의 AI를 활용한 고객 인시던트 대응

제가 MS의 공식 블로그로서 동료 두 명과 함께 작성했기에, 기왕 하는 김에 일본어로 옮겨 두었습니다.

APPS ON AZURE BLOG | 약 10분 소요

저자: Tsuyoshi_Ushio (Microsoft)

공개일: 2026년 5월 20일 | 업데이트일: 2026년 5월 19일

원문: https://techcommunity.microsoft.com/blog/appsonazureblog/from-coding-agents-to-cloud-automation-ai-assisted-customer-related-incidents-in/4516112

태그: azure functions, azure sre agent, customer zero

Microsoft의 「Customer Zero」 블로그 시리즈에서는 Microsoft가 자사의 신뢰할 수 있는 엔터프라이즈급 IQ 플랫폼을 사용하여 어떻게 구축하고 운영하는지를 내부에서 소개합니다. 엔지니어링 팀의 베스트 프랙티스(Best Practice), 실제 현장에서 얻은 교훈, 아키텍처 패턴, 그리고 AI 앱 및 에이전트 플릿(Agent Fleet)을 조직 전체에서 구축, 운영, 스케일링하기 위한 검증된 솔루션의 운영 전략을 배워보세요.

Azure Functions 팀에서는 AI가 고객으로부터 보고된 인시던트(Incident) 조사, 근본 원인 분석(RCA, Root Cause Analysis), 그리고 인시던트 완화에 어떻게 도움이 될 수 있는지 탐구해 왔습니다. 이 글에서는 초기 RCA 에이전트에서 코딩 에이전트를 활용한 조사, 그리고 클라우드 호스트형 자동화에 이르기까지의 우리의 여정과 그 과정에서 얻은 교훈을 공유합니다. Azure Functions와 같은 Microsoft 엔지니어링 팀은 고객이 보고한 문제와 병행하여 운영 환경의 라이브 사이트(Live Site) 문제도 다루고 있으며, 이는 이 업무에서 가장 중요하고 보람 있는 부분 중 하나입니다.

Azure Functions 팀에서는 복잡한 고객 인시던트에 대해 깊이 있는 조사가 필요합니다. 엔지니어는 Azure Data Explorer (Kusto)의 쿼리 결과, 소스 코드, GitHub Issues, 과거 인시던트, 공개 문서, 사내 트러블슈팅 가이드, 그리고 서비스 고유의 운영 지식을 검토합니다. 목표는 항상 고객에 대한 영향을 신속하게 완화하고, 근본 원인을 식별하며, 거기서 배운 내용을 플랫폼에 피드백하고, 필요에 따라 개선 작업을 위한 워크 아이템(Work Item)으로 기록하는 것입니다.

이 작업은 가치가 있지만 시간도 많이 소요됩니다. AI의 능력이 향상됨에 따라 우리는 실질적인 질문을 던지게 되었습니다. AI가 인시던트 조사의 운영 부담을 줄이면서도, 조사를 유의미하게 만드는 학습과 엔지니어링 측면의 판단을 유지할 수 있을까?

이것은 우리의 접근 방식이 초기 RCA 에이전트에서 코딩 에이전트 기반의 워크플로(Workflow)로, 그리고 최종적으로 클라우드 호스트형 자동화로 진화해 온 이야기입니다.

2024년 5월경, 우리는 Microsoft Research의 동료들과 함께 사내 RCA 에이전트 실험을 시작했습니다. 첫 번째 버전은 정식 서비스 개발을 위한 비공식적인 접근 방식이었습니다. 우리 자신의 조사를 지원하기 위한 개인적인 도구였습니다.

초기 실험은 매우 유익했습니다. 에이전트에게 인시던트를 전달하고, 몇 분간 동작시킨 후 분석 결과를 검토하는 프로세스였습니다. 항상 완벽한 근본 원인을 식별할 수 있었던 것은 아니지만, 여러 쿼리를 실행하고 다양한 가설을 검증하며 해결 범위를 충분히 좁혀 시간을 절약할 수 있었습니다.

그 후, Azure SRE Agent가 정식 사내 서비스로 등장했습니다. 우리는 초기 실험에서 배운 내용을 바탕으로 이에 기여했습니다. 그 시점에서 AI를 사용하여 고객이 보고한 인시던트를 해결하는 것이 팀의 주요 포커스가 되었습니다.

AI를 활용한 인시던트 워크플로의 제1세대는 고도로 구조화되어 있었습니다. 사용 가능한 모델을 이용한 초기 실험에서는 특히 복잡한 Kusto 쿼리 생성에 있어 신중한 설계가 필요했습니다. 많은 경우, 고정된 Kusto 쿼리를 도구로 공개하고, 모델이 명확하게 정의된 파라미터(Parameter)를 통해 이를 호출할 수 있도록 해야 했습니다.

그림 1 Kusto 쿼리 도구

이를 통해 실행의 예측 가능성과 재현성이 높아졌지만, 동시에 한계도 명확해졌습니다. 상세한 에이전트 워크플로 (Agent Workflow)는 인시던트가 사전에 정의된 경로와 일치할 경우에는 잘 작동했습니다. 하지만 그 경로를 벗어나면 유연성이 저하되었습니다. 또한, 엔지니어들은 이러한 워크플로를 정의하고 유지보수하는 것이 부담이며, 결과물이 대시보드와 거의 차이가 없다고 느끼기도 했습니다.

그림 2 에이전트 워크플로 (Agent Workflow)

이 경험을 통해 중요한 교훈을 얻었습니다. 복잡한 운영 조사에서는 구조만큼이나 유연성이 중요하다는 점입니다.

2025년 말경, 우리는 GitHub Copilot과 스킬 (Skill)을 활용한 사내 도구를 사용하기 시작했습니다. 이 도구를 통해 VS Code 워크스페이스 (Workspace)를 정의하고 공유할 수 있게 되었습니다. 워크스페이스에는 에이전트 정의, 지시 사항 (Instructions), 프롬프트 (Prompts), 스킬 (Skills), MCP 설정, 그리고 리포지토리 (Repository)를 포함할 수 있습니다.

그림 3 GitHub Copilot 사내 도구

품질의 차이는 극명했습니다. 새로운 모델과 결합함으로써 코딩 에이전트는 훨씬 더 유연하게 인시던트를 조사할 수 있게 되었습니다. Kusto 쿼리 실행, 코드 검사, CLI 및 MCP 도구 사용, 그리고 다양한 접근 방식을 빠르게 시도할 수 있습니다.

팀은 이 모델을 신속하게 채택했습니다. 이전의 워크플로 기반 시스템에서는 상세한 워크플로 정의에 많은 노력이 들고 보상이 제한적이었기 때문에 엔지니어들이 온보딩 (Onboarding)에 소극적이었습니다. 하지만 이 사내 도구는 시스템 확장이 용이하기 때문에, 엔지니어들이 에이전트 정의와 스킬에 적극적으로 기여하게 되었습니다. 시간이 흐르면서 Azure Functions 팀은 에이전트 정의, 스킬, MCP 도구, 지시 사항, 리포지토리로 구성된 AI-Ready 자산을 축적해 나갔습니다.

그 과정에서 몇 가지 중요한 교훈이 도출되었습니다.

현대의 코딩 에이전트는 모든 단계를 세세하게 지정하지 않아도 충분히 잘 작동합니다. 오히려 지시 사항이 너무 많으면 시스템이 취약해지거나 구식이 될 수 있습니다. 방대한 세부 정보를 프롬프트에 직접 삽입하는 것보다, 간결한 가이드를 제공하고 잘 관리된 신뢰할 수 있는 정보원을 가리키는 것이 더 효과적이라는 것을 알게 되었습니다.

지시 사항, 도구 정의, 대화 기록, 도구 출력은 모두 모델의 컨텍스트 (Context)를 점유하기 위해 경쟁합니다. 무관하거나 모순된 정보는 품질을 저하시킬 수 있습니다. 도구 설계도 중요합니다. 도구가 대량의 데이터를 모델에 직접 반환하면 많은 토큰 (Token)을 소비하여 에이전트를 혼란스럽게 할 수 있습니다. 큰 출력의 경우, 결과를 파일에 쓰고 간결한 포인터 (Pointer)를 반환하는 것이 더 효과적입니다.

장기적인 조사에서는 단순한 패턴이 유효합니다. 계획 및 체크리스트 파일을 생성하고, 작업 진행 상황에 따라 이를 업데이트하며, 필요할 때 에이전트가 다시 읽어들일 수 있도록 합니다. 이를 통해 에이전트는 컨텍스트 압축 (Context Compression)으로부터 회복할 수 있으며, 조사가 워크스페이스 내에서 지속적인 상태를 가질 수 있게 됩니다.

에이전트 정의와 스킬에는 도메인 지식 (Domain Knowledge)이 포함됩니다. 사내 트러블슈팅 가이드, 제품 동작 방식, 운영 이력, 전문가의 판단 등이 이에 해당합니다. 이러한 정보를 모두 프롬프트에 직접 기술하는 대신, 지식이 어디에 있는지에 대한 참조와 이를 언제 사용할지에 대한 가이드를 제공하는 것이 더 효과적임을 확인했습니다.

코딩 에이전트는 코드 읽기에 능숙합니다. 우리의 시나리오에서는 여러 리포지토리에 걸친 워크스페이스가 특히 강력했습니다. 에이전트가 관련 리포지토리를 묶어서 참조할 수 있으면, 컴포넌트 간의 동작을 추적하고 의존 관계를 이해하며 더 나은 분석을 생성할 수 있습니다.

최고의 에이전트 자산은 AI 전문가가 아니라, 제품과 운영에 대한 깊은 경험을 가진 엔지니어가 만드는 경우가 많았습니다. 핵심 기술은 전문 지식을 에이전트가 활용할 수 있는 지시 사항, 참조, 리포지토리 레이아웃으로 변환하는 것이었습니다.

에이전트가 완벽하게 대응하지 못한 인시던트는 모두 학습의 기회입니다. 컨텍스트 엔지니어링 (Context Engineering)의 플라이휠 (Flywheel)을 계속 돌리십시오. 조사하고, 격차를 찾아내고, 에이전트 가이드를 업데이트하고, 재테스트하십시오. 이 사이클을 빠르고 간편하게 유지하는 것이 중요합니다.

코딩 에이전트는 매우 유용했지만, 여전히 인터랙티브 (Interactive)한 도구였습니다. 엔지니어가 조사를 시작해야 하며, 많은 경우 이를 유도해야 했습니다.

인시던트 대응(Incident Response)에 있어서는 더 나아가고 싶었습니다. 인시던트가 특정 기능 영역에 진입했을 때, 시스템이 자동으로 조사를 시작하고 관련 분석을 실행하여 유용한 결과를 인시던트에 반환할 수 있기를 바랐습니다. 분석이 완벽하지 않더라도, 초기 단계에서 문제 공간(Problem Space)을 좁힘으로써 완화 시간(Mitigation Time)을 단축할 수 있습니다. 일부 시나리오에서는 궁극적으로 자동 완화(Automated Mitigation) 또는 적절한 팀으로의 자동 전달을 지원할 수도 있을 것입니다.

로컬 코딩 에이전트 워크플로우는 사용자로 인증될 수 있다는 장점이 있습니다. 하지만 신뢰할 수 있는 자동화의 기반으로서 몇 가지 중요한 제약 사항도 있었습니다.

첫째, 여전히 인간의 개입에 의존하고 있었습니다. AI는 개인의 생산성을 극적으로 향상시켰지만, 인시던트 대응의 병목 현상(Bottleneck)은 많은 경우 인간의 주의력과 시간이었습니다. 에이전트의 기동이 쉽더라도 엔지니어가 실행을 시작해야 한다는 점은 컨텍스트 스위칭(Context Switching)을 유발하며 희소한 리소스를 소비합니다.

둘째, 사용자의 자격 증명(Credentials)에 의존하고 있었습니다. 코딩 에이전트는 사용자의 권한으로 실행되지만, 이는 자동화 관점에서는 권한이 너무 광범위할 수 있으며, 브라우저 기반의 재인증과 같은 인간 중심의 플로우를 상속받게 됩니다. 지속적인 자동화를 위해서는 관리형 ID(Managed Identity)와 같이 무인 실행(Unattended Execution)에 적합한 ID 모델이 필요했습니다.

셋째, 실행 환경과 보안에 관한 우려가 있었습니다. 로컬 환경은 강력하지만, 안전한 자동화를 위해 필요한 샌드박스(Sandbox)를 자연스럽게 제공하지 않습니다. 사용자 액세스로 실행되기 때문에, 자동화된 인시던트 워크플로우에 바람직한 수준 이상으로 광범위한 파일이나 리소스에 접근할 가능성이 있습니다. 로컬 및 dev-box 환경에는 운영상의 결점도 있습니다. 재부팅이 필요하거나 다른 워크로드와 충돌할 수 있어, 지속적인 실행, 장애 복구(Disaster Recovery) 또는 페일오버(Failover)에는 적합하지 않습니다. 자동화를 위해서는 엔지니어의 머신에 의존하지 않는 전용 실행 환경이 필요했습니다.

마지막으로, 토큰 관리(Token Management)가 운영상의 우려 사항이 되었습니다. 사용자에게 귀속된 토큰 소비는 제한에 도달하면 불안정해질 수 있으며, 자동화로 인해 한 명의 사용자가 불균형적으로 많은 AI 용량을 소비하는 것처럼 보이는 사용 패턴이 발생할 수 있습니다. 이는 운영 분석에 노이즈를 더하고 거버넌스(Governance)를 어렵게 만듭니다.

이 모든 이유로 인해 클라우드 실행이 올바른 방향이라고 생각했습니다. 관리형 ID, 보안 샌드박스, 지속적인 실행, 그리고 누군가의 로컬 머신에 의존하지 않는 시스템이 필요했습니다.

우리 중 다수는 코딩 에이전트의 강력한 지지자였으며, 이를 계속 사용하고 싶어 했습니다. 마찬가지로 중요한 점은 이미 검증된 자산(Assets)을 축적해 왔다는 것입니다. 에이전트 정의, 지시 사항(Instructions), 프롬프트(Prompts), 스킬(Skills), MCP 설정, 그리고 팀이 점진적으로 구축하고 개선해 온 리포지토리 레이아웃(Repository Layout) 등이 그것입니다.

즉, 클라우드 자동화로의 전환은 코딩 에이전트를 완전히 다른 것으로 대체하는 것을 의미하지 않았습니다. 코딩 에이전트를 성공시킨 자산을 유지 및 재사용하면서, 자동화에 적합한 실행 모델로 전환하는 것이 목표였습니다.

동시에 코딩 에이전트는 높은 품질 기준을 설정해 두었습니다. 실제로 잘 작동하고 있었기 때문에, 클라우드 서비스가 자동으로 동일한 수준의 품질을 제공할 수 있다고 가정하지 않았습니다. 그래서 클라우드 전환을 위해 두 가지 구체적인 목표를 세웠습니다.

• 집중된 일회성 조사로 실행했을 경우, 기존 코딩 에이전트 워크플로우에서 볼 수 있었던 것과 동등한 품질을 달성할 것.
• 이미 구축한 자산을 계속해서 사용하고 개선할 수 있도록 할 것.

다시 말해, 단순히 다른 클라우드 AI 시스템을 찾고 있었던 것이 아닙니다. 코딩 에이전트의 강점을 계승하면서, 자동화에 필요한 운영 특성을 갖춘 클라우드 자동화의 길을 찾고 있었습니다.

이러한 요구 사항을 충족할 수 있는 접근 방식을 평가하기 위해 병렬 비교를 실시했습니다.

다른 한 가지 접근 방식은 프로토타입 형태의 헤드리스 코딩 에이전트 실행 서비스 (Headless Coding Agent Execution Service)입니다. 엔지니어가 로컬에서 사용하던 사내 도구의 워크스페이스 정의를 재사용하지만, 인간의 개입(Human-in-the-loop) 없이 실행됩니다. 인시던트가 대상 루프에 진입하면, 시스템은 에이전트 워크스페이스를 생성하고, 리포지토리를 준비하며, 초기 프롬프트로 GitHub Copilot CLI를 실행하여 분석을 수집한 뒤 그 결과를 인시던트에 반환합니다. 또한 엔지니어가 나중에 조사를 검토하거나 재개할 수 있도록 세션 아티팩트 (Session Artifacts)를 유지합니다.

図4 에이전트 지원 트렌드 – 코딩 에이전트의 사용, 헤드리스 코딩 에이전트 실행 서비스 및 SRE 에이전트의 도입으로 인해 유용성 비율이 증가하고 있음을 보여줍니다.

또 다른 접근 방식으로는 Azure SRE Agent를 사용했습니다. 이전 실험 이후 프리뷰 고객의 피드백을 통해 개선되었으며, 일반 제공 (GA, General Availability) 단계에 가까워지고 있었습니다. 새로운 모델, 더욱 강력한 커스텀 에이전트 동작, MCP 및 내장 도구, 리포지토리 액세스, 인시던트 트리거 실행 등을 지원하게 되었습니다. 우리는 코딩 에이전트 자산에서 Azure SRE Agent 자산으로의 일회성 이전을 실시했습니다. 이는 GitHub Copilot CLI와 기존 코딩 에이전트를 사용하여 단 하루 만에 달성되었습니다.

비교는 의도적으로 실무적인 방식으로 진행했습니다. 사내 코딩 에이전트 환경이 엔지니어들로부터 신뢰와 지지를 받는 결과를 만들어낸다는 것은 이미 알고 있었습니다. 그것이 품질 기준이 되었습니다. Azure SRE Agent가 그 기준을 충족하거나 능가하면서 클라우드 자동화의 운영 요구 사항도 충족할 수 있다면, 이는 더 강력한 장기적 경로가 될 것입니다.

헤드리스 코딩 에이전트 실행 서비스의 초기 결과는 매우 유망했습니다. 첫 번째 인시던트 세트에서 에이전트가 안전하게 처리할 수 있었던 케이스의 경우, RCA (Root Cause Analysis, 근본 원인 분석)가 SME (Subject Matter Expert, 분야 전문가)의 결론과 일치했습니다. 이는 로컬 코딩 에이전트용으로 구축한 자산을 헤드리스 시나리오에 효과적으로 전용할 수 있음을 보여주었습니다.

Azure SRE Agent 역시 처음부터 강력한 성능을 발휘했습니다. 헤드리스 코딩 에이전트 실행 서비스가 일부 영역에서 초기에 약간 더 우수한 분석을 보여주기도 했지만, Azure SRE Agent는 이미 운영상 충분히 유용한 수준에 도달해 있었습니다.

그 후, 우리는 다음 사항들을 비교하는 평가 프레임워크를 구축했습니다.

• 각 에이전트의 RCA, 신뢰 점수, 완화 절차 (Mitigation Procedures)
• 이후 인간이 제공한 RCA 및 완화 근거
• 자동 완화 권장 사항 (Automated Mitigation Recommendations)
• 자동 완화로 가는 경로
• 자동 전달 권장 사항 (Automated Escalation Recommendations)
• 세션 수준의 실행 문제

이 평가가 피드백 루프가 되었습니다. 엔지니어들이 흥미로운 인시던트를 검토하여 약점을 식별하고, 에이전트 정의와 기술을 개선하며, 풀 리퀘스트 (Pull Request, PR)를 제출했습니다. 또한 비교 보고서로부터 개선 PR을 생성하기 위해 에이전트 지원을 활용하기도 했습니다.

図5 LLM as Judge를 통한 헤드리스 코딩 에이전트 실행 서비스 (파란색) vs Azure SRE Agent (초록색)의 병렬 평가

몇 주 이내에 Azure SRE Agent의 품질은 헤드리스 코딩 에이전트 실행 서비스의 베이스라인을 지속적으로 상회하게 되었습니다. 그 시점에서 우리는 헤드리스 결과를 인시던트에 반환하는 것을 중단하고, Azure SRE Agent 경로의 개선에 집중했습니다. 또한 사내 코딩 에이전트 자산으로부터의 동기화를 자동화하여, 개선 사항이 풀 리퀘스트를 통해 지속적으로 반영되도록 했습니다.

이 전환은 중요한 의미를 가집니다. Azure SRE Agent는 단순한 흥미로운 대안이 아니라, 코딩 에이전트에서 작동했던 것을 계승하면서 자동화를 위한 더 나은 기반을 제공하는 클라우드로 가는 길이 된 것입니다.

코딩 에이전트에 대한 일반적인 반응은 이전의 클라우드 AI 경험보다 크게 개선되었다는 것입니다. 우리의 경험에 따르면, 이는 주로 두 가지 이유 때문이라고 생각됩니다. 더 강력한 모델과 적절한 컨텍스트 (Context)에 대한 액세스 개선입니다.

코딩 에이전트 (Coding Agent)는 워크스페이스를 볼 수 있습니다. 지시 사항, 기술 (Skills), 도구 (Tools), 리포지토리 (Repositories), 파일을 사용할 수 있습니다. 기존의 클라우드 AI 시스템은 동일한 리소스에 대한 액세스 권한을 갖지 못하는 경우가 많았습니다. Azure SRE Agent가 유사한 자산, 즉 적절한 리포지토리, 적절한 도구, 적절한 도메인 특화 지식 (Domain-specific knowledge)을 참조할 수 있게 되면서, 동등하거나 그 이상의 품질에 도달할 수 있었습니다.

컨텍스트 압축 (Context compression), 도구 실행 (Tool execution), 오케스트레이션 (Orchestration)의 세부 사항은 중요합니다. 하지만 핵심 원칙은 더 단순합니다. 에이전트는 불필요한 컨텍스트를 항상 안고 있는 것이 아니라, 적절한 타이밍에 적절한 지식에 액세스해야 합니다.

즉, 가장 중요한 작업은 단순히 모델을 선택하거나 도구를 구축하는 것만이 아닙니다. 고품질의 AI-Ready 자산을 만드는 것입니다. 간결한 지시 사항, 유용한 기술, 정확한 참조, 적절하게 구조화된 리포지토리 액세스, 그리고 과거에는 사람들의 머릿속에만 존재했던 도메인 지식입니다.

클라우드 호스팅형 자동화 경로는 즉각적으로 큰 이점을 가져다주었습니다. 문제 분석이 클라우드에 저장되어 개발자의 머신뿐만 아니라 누구나 액세스할 수 있게 된 것입니다. 즉, 결론과 조사 내용이 언제든 참조할 수 있는 형태로 저장되며, 채팅 인터페이스를 통한 인간과의 상호작용도 가능해집니다.

図6 Azure SRE Agent의 채팅 인터페이스 예시

우리의 여정은 개인적인 RCA 어시스턴트에서 시작하여, 구조화된 에이전트 워크플로 (Agent workflow)를 거쳐, 코딩 에이전트로 가속화되었고, 최종적으로 클라우드 호스팅형 자동화라는 길로 돌아왔습니다.

교훈은 코딩 에이전트나 클라우드 에이전트가 보편적으로 우월하다는 것이 아닙니다. 에이전트의 품질은 에이전트가 무엇을 참조할 수 있는지, 얼마나 무관한 컨텍스트를 피할 수 있는지, 그리고 도메인 전문가가 자신의 지식을 사용하기 쉬운 자산으로 변환하고 있는지에 크게 달려 있다는 것입니다.

우리에게 열쇠는 코딩 에이전트를 버리는 것이 아니었습니다. 그 강점을 Azure SRE Agent와 자동화에 더 적합한 클라우드 실행 모델로 계승하는 것이었습니다.

현대의 에이전트는 그 노력을 가치 있게 만들 만큼 충분한 능력을 갖추고 있습니다. 인시던트 대응 (Incident response)에 있어서는 더 신속한 조사, 더 안전한 자동화, 그리고 궁극적으로 고객의 인시던트 완화 시간 (Mitigation time) 단축을 위한 문을 열어줍니다.

Azure Functions 팀은 이 경험이 복잡한 엔지니어링 운영에 AI를 적용하는 방법을 모색하는 다른 팀들에게 유익하기를 바랍니다.

다음 기사에서는 평가 프레임워크 (Evaluation framework)와 이러한 개선의 배후에 있는 피드백 루프 (Feedback loop)를 어떻게 자동화했는지에 대해 더 깊이 파고들 예정입니다.