Microsoft가 자가 치유(Self-Healing) CI/CD 청사진을 발표했습니다. Observe-Analyze-Act 루프의 실제 작동

파이프라인 실패는 모든 엔지니어링 팀이 제거할 수 없는 마찰로 받아들이는 문제 중 하나입니다. 새벽 2시에 무언가 고장 나면, 누군가는 호출을 받고, 누군가는 디버깅하며, 누군가는 수정합니다. Microsoft는 이러한 초기 대응 루프에서 인간을 완전히 배제하는 작동 가능한 아키텍처를 방금 발표했습니다.

해결하려는 문제
표준 CI/CD 파이프라인은 실패하면 스택 트레이스(stack trace)를 보내고 기다립니다. 백엔드 풀 멤버 IP의 작은 오타 하나가 배포를 망칠 수 있습니다. 디버깅 사이클은 설계상 수동적입니다. 로그를 읽고, 문맥을 이해하고, 무엇이 고장 났는지 파악하고, 수정을 푸시하고, 다시 실행합니다. 예를 들어 레거시 로드 밸런서 설정을 Azure ILB 규칙으로 마이그레이션하는 것과 같이 인프라를 마이그레이션하는 팀의 경우, 이 사이클은 며칠을 잡아먹을 수 있습니다.

Microsoft가 Azure Infrastructure Blog에서 설명한 자가 치유(self-healing) 파이프라인 아키텍처는 해당 사이클을 에이전트 루프(agentic loop)로 대체합니다. 파이프라인은 여전히 실패합니다. 하지만 사람이 에러를 읽을 때까지 기다리는 대신, AI 에이전트가 에러를 읽고, 인프라 문맥(context) 내에서 이를 이해하며, 수정안을 제안(또는 실행)합니다.

실제 작동 방식
자가 치유 워크플로우는 관찰(Observe), 분석(Analyze), 실행(Act)의 세 단계로 구성된 에이전트 루프(agentic loop)입니다. 프로세스는 이벤트 기반 트리거(event-driven trigger)로 시작됩니다. Azure DevOps 파이프라인이 실패하면, 웹훅(webhook)이 텔레메트리(telemetry)와 빌드 로그를 Azure Function으로 전송합니다. 그런 다음 로그는 Microsoft AI Foundry 엔드포인트를 통해 GPT-4o로 전달됩니다. 이 마지막 부분이 핵심입니다. 모델은 단순히 에러 코드만 찾는 것이 아니라 인프라 문맥을 이해합니다.

해당 수정 사항은 GitHub Pull Request (PR)를 트리거하거나 Azure DevOps 파이프라인 업데이트를 자동으로 실행할 수 있으며, 이것이 바로 루프를 완성하는 "Act (실행)" 단계입니다. Microsoft AI Foundry는 Azure OpenAI를 호출하는 표준화된 방식을 제공합니다. 이는 서비스별로 직접적인 OpenAI 엔드포인트 설정을 관리하는 대신, 환경 전반에 걸쳐 일관된 API 표면 (API surface)을 유지하고자 하는 팀에게 매우 중요합니다. 왜 특히 GPT-4o인가에 대해 설명하자면, 네이티브 도구 사용 (native tool use) 기능 덕분에 함수 호출 (function calling)에 특화되어 있어, 에이전트가 Azure DevOps API 및 GitHub와 원활하게 상호작용할 수 있기 때문입니다. 퍼스트 파티 (first-party) 서비스로서 Azure OpenAI는 프로덕션급 에이전트를 실행하는 데 가장 비용 효율적인 경로이며, GPT-4o는 복잡한 로그를 몇 초 만에 처리하여 사람이 한 줄씩 스캔하는 것보다 훨씬 빠르게 오류를 식별합니다.

실제로 팀들이 이를 활용하는 방식: Microsoft의 게시물은 구체적인 인프라 마이그레이션 시나리오를 설명합니다. 예를 들어, fastest-app-response나 source-address persistence와 같은 레거시 로드 밸런서 설정을 Azure ILB 규칙으로 매핑하는 과정에서, 백엔드 풀 멤버 IP의 단 하나의 오타가 배포를 완전히 망칠 수 있습니다. 이제 에이전트는 파이프라인이 실행되기 전에 해당 구성들을 스캔하여 불일치를 표시하고, 올바른 Azure 네이티브 대응 방안을 제안합니다. 이를 통해 팀은 며칠간의 시행착오 디버깅 시간을 절약할 수 있었습니다. 이것이 바로 장애 발생 전 (pre-failure) 애플리케이션의 역할입니다. 즉, 단순히 장애 발생 후에 대응하는 것이 아니라, 구성 드리프트 (configuration drift)가 배포 실패로 이어지기 전에 이를 포착하는 것입니다. 장애 발생 후 (post-failure)에는 로그만으로 수정이 가능한 모든 상황을 루프가 처리합니다. 의존성 불일치, 잘못 설정된 환경 변수, 새로 배포된 리소스의 상태 확인 (health check) 실패 등이 이에 해당합니다. 에이전트는 실패 텔레메트리 (telemetry)를 읽고 오류 카테고리를 식별한 뒤, 검토를 위한 PR로 바로 전달되거나 "Act" 단계의 설정에 따라 직접 실행되는 복구 방안을 제안합니다. 이는 Microsoft의 플랫폼 엔지니어링 팀이 문서화해 온 더 넓은 패턴과 연결됩니다.

배포 상태가 저하되면, Argo CD가 GitHub Actions로 웹훅 (webhook)을 발송하며, GitHub Actions는 클러스터 이름, 리소스 그룹, 초기 텔레메트리 (telemetry) 등 실패 상세 정보를 포함한 GitHub 이슈 (issue)를 생성합니다. 에이전트 (agent)는 해당 이슈를 읽고, 워크로드 ID 페더레이션 (Workload Identity Federation)을 통해 Azure에 인증한 뒤, 영향을 받은 클러스터에 대해 kubectl 명령어를 실행하고, 더 심층적인 텔레메트리를 위해 AKS MCP 서버에 쿼리를 보냅니다. 이러한 자가 치유 (self-healing) CI/CD 아키텍처는 동일한 개념을 Azure DevOps 네이티브 버전으로 구현한 것입니다.

이것이 보기보다 더 중요한 이유
아키텍처 자체는 복잡하지 않습니다 — 웹훅 (webhook), Azure Function, GPT-4o 호출, 조건부 액션 (conditional action)으로 구성됩니다. 중요한 점은 이것이 이제 Microsoft의 Azure 인프라 팀에서 실제 사용 사례와 함께 문서화한 퍼스트 파티 (first-party) 패턴이라는 것입니다. 이는 개념 증명 (proof-of-concept)과는 다릅니다. AI 에이전트 (AI agents)가 망가진 엔지니어링 관행을 마법처럼 고쳐주는 것은 아닙니다 — 대신 그것들을 확장(scale)합니다. 만약 귀하의 CI/CD 파이프라인이 취약하다면, 에이전트는 그것을 더 빠르게 망가뜨릴 것입니다. 만약 테스트 커버리지 (test coverage)가 부족하다면, 에이전트는 검증되지 않은 코드를 더 높은 속도로 배포할 것입니다. 자가 치유 아키텍처는 파이프라인 실패가 로그로부터 진단 가능하다는 것을 전제로 합니다. 잘 구조화된 관측성 (observability)을 갖춘 팀에게는 대부분의 실패가 이에 해당합니다. 하지만 이것이 없는 팀에게 이 패턴은 격차를 빠르게 드러낼 것입니다.

또한 파이프라인 실패를 분류하는 방식에도 변화가 있습니다. 전통적인 CI/CD 파이프라인은 이진 단언 (binary assertions) — 즉, 'X == Y'를 확인하는 방식에 의존합니다. 하지만 AI 에이전트는 확률적 (probabilistic)입니다. 자가 치유 루프는 결정론적 (deterministic)인 실패 영역, 즉 설정 오류, 누락된 종속성, 일치하지 않는 API 파라미터 등에서 잘 작동합니다. 더 어려운 문제는 에이전트가 제안한 수정 사항이 배포되기 전에 이를 테스트하고 검증하는 것이며, 이 지점에서 아키텍처는 더 복잡해집니다. 현재로서는 '출력으로서의 PR (PR-as-output)' 모델을 통해 최종 액션 단계에서 인간이 루프에 참여(human in the loop)하도록 유지하고 있는데, 이는 운영 시스템 (production systems)을 위한 올바른 결정입니다. 초기 문제 해결의 부담을 자동화된 에이전트로 전환함으로써, 팀은 단순히 시간을 절약하는 것을 넘어 전체 스택의 신뢰성을 높이고 있습니다.

그러한 프레임워크 설정은 정확하지만, 신뢰성 향상은 "실행 (Act)" 단계의 범위를 어떻게 설정하느냐에 전적으로 달려 있습니다. PR (Pull Request)을 생성하는 에이전트는 복구가 가능합니다. 하지만 프로덕션 파이프라인 (Production Pipelines)에 직접적인 쓰기 권한을 가진 에이전트는, 감독 없이 실행하기 전에 더욱 세심한 가드레일 (Guardrails)이 필요합니다.

가용성 및 액세스 (Availability and Access)
이 패턴은 AI Foundry를 통해 Azure DevOps, Azure Functions, 그리고 Azure OpenAI 상에서 실행됩니다. 프리뷰 프로그램 (Preview program)은 필요하지 않으며, 이들은 모두 일반적으로 사용 가능한 서비스 (Generally Available services)입니다. ChatCompletionsClient 설정 및 웹훅-투-함수 (Webhook-to-function) 연결을 포함한 전체 구현 단계는 Microsoft Tech Community 게시물에 나와 있습니다.

이 아키텍처 (Architecture)는 적응할 수 있을 만큼 충분히 모듈식 (Modular)입니다. 웹훅을 수신할 수 있는 서버리스 컴퓨팅 (Serverless compute)이라면 무엇이든 Azure Functions를 교체할 수 있고, 강력한 함수 호출 (Function-calling) 지원을 갖춘 모델이라면 무엇이든 GPT-4o를 교체할 수 있으며, "실행 (Act)" 단계의 범위는 조직의 변경 관리 정책 (Change management policy)이 허용하는 범위 내로 설정할 수 있습니다.

수동적 실행자로서의 파이프라인 (Pipeline-as-passive-executor) 시대는 끝나가고 있습니다. 스스로의 실패를 읽고, 이에 대해 추론하며, 조치를 취할 수 있는 파이프라인이 차세대 기본값이 될 것이며, Microsoft는 방금 그 청사진을 공개했습니다. MCP, 에이전틱 AI (Agentic AI), 그리고 AI 인프라 (AI infrastructure)에 대한 더 많은 소식을 위해 팔로우해 주세요.