AWS 기술 블로그

Part2: 삼성계정 서비스의 Agentic AIOps, 운영환경에서 Multi-Agent 시스템으로 RCA 자동화 하기

이번 포스팅은 삼성전자 서비스의 핵심, 삼성계정 서비스에서 서비스 운영에 실질적인 문제를 해결하는데 GenAI를 어떻게 활용하는지 소개하는 2부작 시리즈 포스팅입니다. 사례가 AWS 기술블로그를 통해 세상에 알려질 수 있게 도움주신 모든 분들에게 감사의 마음을 전합니다.

서론: 대규모 서비스 운영에서 장애 대응의 현실

대규모 글로벌 서비스를 운영하는 환경에서 장애 대응은 단순한 기술 문제 해결을 넘어선 복합적인 도전입니다. 알림은 빠르게 도착하지만, 왜 문제가 발생했는지를 파악하는 과정은 여전히 운영자의 경험과 직관에 의존하는 경우가 많습니다. Samsung Account 서비스 역시 이러한 한계를 안고 있었습니다.

Datadog, Amazon CloudWatch, Amazon EKS 로그 등 풍부한 Observability 데이터가 이미 존재함에도 불구하고, 장애 발생 시 이 데이터들을 하나의 맥락으로 연결해 일관된 Root Cause Analysis(RCA)와 실행 가능한 조치 가이드로 전환하는 과정은 자동화되어 있지 않았습니다. 분석 품질과 대응 속도는 담당자의 숙련도에 따라 크게 달라졌고, 평균 복구 시간(MTTR)과 평균 탐지 시간(MTTD)을 안정적으로 줄이기 어려운 구조가 고착화되어 있었습니다.

이 글에서는 이상 탐지에서 근본 원인 분석, 조치 제안까지의 전 과정을 5분 이내로 자동화하기 위해 설계·구현·운영한 Agentic AIOps Multi-Agent 시스템의 실제 적용 사례를 다룹니다. 특히 Strands Agents SDK의 Agents as Tools 패턴을 활용한 계층적 위임(Hierarchical Delegation) 구조와 FastMCP 기반 Custom MCP 서버 구축 과정을 중심으로 기술적 구현 상세를 공유합니다.

해결하고자 한 과제

본 프로젝트의 목표는 명확했습니다.

첫째, MTTR과 MTTD를 구조적으로 단축하는 것이었습니다. 이상 탐지 발생 후 5분 이내에 근본 원인 후보와 그에 대한 근거를 제시할 수 있어야 했습니다. 둘째, 500 에러가 발생했을 경우 관련 서비스와 추정 원인, 그리고 우선적으로 검토해야 할 조치 가이드를 자동으로 제공하는 것이었습니다. 셋째, 코드 변경이나 재배포로 인한 문제와 성능 저하 또는 인프라 문제를 구분해 자동 진단할 수 있어야 했습니다. 마지막으로, 이 모든 결과가 Slack 기반 실시간 워크플로우 안에서 자연스럽게 공유되어야 했습니다.

AIOps의 진화와 Agentic AI의 부상

전통적 AIOps의 한계

AIOps(Artificial Intelligence for IT Operations)라는 용어는 Gartner가 2016년에 처음 제안한 이후, IT 운영에 AI와 머신러닝을 적용하는 접근 방식의 대명사가 되었습니다. 전통적인 AIOps 플랫폼은 이벤트 상관관계 분석, 이상 탐지, 알림 노이즈 감소 등에서 상당한 성과를 거두었습니다. Gartner에 따르면 AIOps를 도입한 기업들은 평균 복구 시간(MTTR)을 최대 40% 단축하고 프로세스 자동화를 30% 향상시킬 수 있다고 합니다.

그러나 전통적인 AIOps에는 근본적인 한계가 존재합니다. 대부분의 AIOps 플랫폼은 미리 정의된 규칙과 통계적 모델에 의존합니다. 이상 탐지는 가능하지만, 왜 이상이 발생했는지에 대한 맥락적 추론은 여전히 사람의 몫이었습니다. 여러 데이터 소스의 정보를 종합하여 인과관계를 파악하고, 상황에 맞는 조치를 제안하는 것은 자동화되지 않았습니다. 결국 AIOps는 문제를 더 빨리 발견하게 해주었지만, 문제를 더 빨리 해결하게 해주지는 못했습니다.

이러한 한계는 현대 IT 인프라의 복잡성이 증가하면서 더욱 부각되었습니다. 마이크로서비스 아키텍처, 멀티클라우드 환경, 컨테이너 오케스트레이션 시스템은 관리해야 할 구성요소의 수를 기하급수적으로 늘렸습니다. Wall Street Journal에 따르면 중소기업에서 대기업까지 평균 8개의 서로 다른 클라우드 제공업체와 파트너십을 맺고 있습니다. 이렇게 분산된 환경에서 장애가 발생하면, 문제의 근본 원인을 찾기 위해 여러 시스템을 교차 분석해야 하는 복잡한 작업이 필요합니다.

AIOps 시장의 폭발적 성장

이러한 복잡성에 대한 해결책으로 AIOps 시장은 급격히 성장하고 있습니다. Fortune Business Insights에 따르면 글로벌 AIOps 시장 규모는 2024년 18.7억 달러에서 2032년 86.4억 달러로 연평균 21.4%의 성장률을 기록할 것으로 예상됩니다. Research and Markets의 다른 분석에서는 더 공격적인 성장을 예측하여, 2025년 111.6억 달러에서 2029년 325.6억 달러로 연평균 30.7%의 성장을 전망합니다.

이 성장의 핵심 동력 중 하나는 생성형 AI(Generative AI)와 AIOps의 통합입니다. 2024년 기준으로 AIOps 벤더의 80%가 생성형 AI를 구현했거나 구현 계획을 가지고 있다고 합니다. 생성형 AI는 AIOps에 새로운 가능성을 열어줍니다. 단순히 패턴을 감지하는 것을 넘어, 근본 원인을 추론하고, 해결책을 제안하며, 심지어 새로운 워크플로우를 생성할 수 있게 되었습니다.

Gartner는 “IT 운영의 미래에서 AIOps가 포함되지 않는 시나리오는 없다”고 단언합니다. 2026년까지 대기업의 60%가 AIOps를 표준으로 도입할 것으로 예측되며, 이는 단순한 트렌드가 아닌 필수적인 전환으로 자리잡고 있습니다.

2025년, Agentic AI의 해

2023년이 생성형 AI 챗봇의 해였고 2024년이 AI 어시스턴트의 해였다면, 2025년은 명백히 Agentic AI의 해입니다. IBM과 Morning Consult의 조사에 따르면 엔터프라이즈용 AI 애플리케이션을 구축하는 개발자 1,000명 중 99%가 AI 에이전트를 탐색하거나 개발 중이라고 응답했습니다. McKinsey의 2025년 AI 현황 조사에서도 응답자의 62%가 자신의 조직이 최소한 AI 에이전트를 실험하고 있다고 밝혔습니다.

Agentic AI는 기존의 AI 시스템과 근본적으로 다릅니다. AI 어시스턴트가 사용자의 프롬프트에 반응하여 정보를 제공하고 작업을 보조하는 반응형(reactive) 시스템이라면, AI Agent는 스스로 추론하고, 계획하며, 도구를 사용하여 복잡한 다단계 목표를 자율적으로 달성하는 능동형(proactive) 시스템입니다. Deloitte는 이러한 시스템을 “perceive, reason, and act”할 수 있는 지능형 시스템으로 정의합니다.

Gartner의 예측에 따르면 2028년까지 일상 업무 결정의 15%가 Agentic AI에 의해 자율적으로 이루어질 것이며, 이는 2024년의 0%에서 급격한 증가입니다. 또한 2026년까지 엔터프라이즈 애플리케이션의 40%가 작업별 AI 에이전트를 통합할 것으로 예측되는데, 이는 2025년의 5% 미만에서 급격히 증가한 수치입니다.

이러한 급격한 채택은 실질적인 비즈니스 성과에 기반합니다. AI를 성공적으로 확장한 기업들은 20-30%의 생산성 향상, 15-25%의 EBITDA 성장, 최대 40% 빠른 의사결정 사이클을 보고하고 있습니다. 특히 MTTR의 극적인 개선이 주목할 만합니다. 한 기업은 AIOps 도입 후 문제 해결 시간이 66% 감소했다고 보고했습니다.

Multi-Agent 시스템의 부상

Agentic AI의 발전과 함께 Multi-Agent 시스템에 대한 관심이 폭발적으로 증가하고 있습니다. Gartner는 Multi-Agent 시스템에 대한 문의가 2024년 1분기에서 2025년 2분기 사이에 1,445% 급증했다고 보고했습니다. 이는 단순히 호기심 차원의 관심이 아니라, 엔터프라이즈 AI 아키텍처의 근본적인 전환을 반영합니다.

Multi-Agent 시스템이 주목받는 이유는 명확합니다. 단일 범용 AI가 복잡한 워크플로우를 처리하는 데 한계가 있기 때문입니다. 마치 모놀리식 애플리케이션이 마이크로서비스 아키텍처로 진화한 것처럼, 단일 AI 에이전트도 특화된 에이전트들의 협업 네트워크로 진화하고 있습니다. 각 에이전트는 특정 작업에 최적화되고, Orchestrator가 이들을 조율하여 복잡한 문제를 해결합니다.

MarketsandMarkets에 따르면 Agentic AI 시장은 2025년 78억 달러에서 2030년 526억 달러로 성장할 것으로 예측되며, 이는 연평균 46%에 달하는 놀라운 성장률입니다. 이 성장의 상당 부분은 Multi-Agent 시스템의 엔터프라이즈 도입에서 비롯될 것입니다.

Multi-Agent 시스템은 AIOps 영역에서 특히 강력한 잠재력을 보여줍니다. 장애 분석은 본질적으로 다학제적 문제입니다. 메트릭 분석, 로그 해석, 인프라 상태 확인, 과거 사례 참조 등 서로 다른 전문성이 필요한 작업들이 결합되어야 합니다. 이러한 작업들을 단일 AI에게 맡기는 것보다, 각 영역에 특화된 Agent들이 협업하도록 설계하는 것이 더 효과적이고 신뢰할 수 있는 결과를 만들어냅니다.

Agentic AIOps: 왜 지금인가

전통적 AIOps의 한계, Agentic AI의 성숙, Multi-Agent 시스템의 부상이라는 세 가지 흐름이 만나는 지점에서 Agentic AIOps가 등장합니다. Agentic AIOps는 단순히 AIOps에 생성형 AI를 얹은 것이 아닙니다. 이는 IT 운영의 패러다임을 “시스템이 문제를 감지하고 사람이 분석한다”에서 “시스템이 문제를 감지하고, 분석하고, 조치를 제안하며, 사람은 최종 의사결정과 실행을 담당한다”로 전환하는 것입니다.

이 전환이 지금 가능해진 데에는 몇 가지 기술적 성숙이 뒷받침됩니다. 첫째, Foundation Model의 추론 능력이 실용적 수준에 도달했습니다. Claude, GPT-4 등의 모델은 복잡한 기술 문서를 이해하고, 여러 데이터 소스의 정보를 종합하며, 논리적 추론을 수행할 수 있습니다. 둘째, Agent 프레임워크가 프로덕션 수준으로 성숙했습니다. Strands Agents SDK, LangGraph, CrewAI, AutoGen 등의 프레임워크는 Multi-Agent 시스템의 개발과 배포를 크게 단순화했습니다. 셋째, Model Context Protocol(MCP)과 같은 표준이 등장하여 AI 에이전트와 외부 도구의 통합이 용이해졌습니다.

그러나 기술적 가능성만으로 도입이 정당화되지는 않습니다. Agentic AIOps의 진정한 가치는 운영 조직의 구조적 문제를 해결하는 데 있습니다. 장애 대응 능력이 특정 개인의 경험에 의존하는 상황, 분석 품질이 담당자에 따라 크게 달라지는 상황, 지식이 개인에게 축적되어 조직으로 이전되지 않는 상황—이러한 문제들은 더 똑똑한 도구로 해결되지 않습니다. 분석의 과정을 구조화하고, 그 과정이 시스템에 기록되며, 일관된 품질로 반복 가능하게 만드는 것이 필요합니다. Agentic AIOps는 바로 이 구조화를 가능하게 합니다.

솔루션 아키텍처 진화 과정

Week 1-2: 오픈소스 MCP 서버의 한계 발견

프로젝트 초기에는 Datadog에 축적된 풍부한 Observability 데이터를 활용하고자 오픈소스 MCP 서버 구현체들을 검증했습니다. Datadog에는 이미 Application 로그, 메트릭, APM 데이터가 풍부하게 축적되어 있었고, 운영자 역시 Datadog 대시보드와 모니터에 익숙한 상태였기 때문에 자연스러운 선택이었습니다.

그러나 실제 검증 과정에서 여러 문제들이 발견되었습니다. 가장 큰 문제는 Dashboard 위젯이 담고 있는 수치 데이터를 Agent가 제대로 해석하지 못한다는 점이었습니다. 대시보드 위젯의 맥락은 사람이 시각적으로 해석하기에는 적합했지만, API를 통해 전달되는 숫자만으로 동일한 의미를 전달하기에는 한계가 있었습니다. 기준선 대비 변화, 시간 구간별 추세, 태그와 서비스 맥락이 숫자만으로는 충분히 표현되지 않았기 때문입니다.

이 한계는 단순히 데이터 양의 문제가 아니라 데이터 표현 방식의 문제였습니다. 운영자가 판단할 때 사용하는 사고 단위와, 시스템이 받아들이는 입력 단위 사이에 근본적인 간극이 존재했습니다. 예를 들어 운영자는 “평소보다 에러율이 급격히 증가했다”고 판단하지만, API가 반환하는 것은 단순히 “15%”라는 숫자일 뿐이었습니다. 이 숫자가 급격한 증가인지, 정상 범위 내 변동인지를 판단하려면 과거 데이터와의 비교, 시간대별 패턴, 서비스 특성 등의 맥락이 필요했습니다.

Week 3: Custom MCP 서버 구축과 단일 Agent의 구조적 위험

오픈소스 MCP 서버의 한계를 인식한 후, FastMCP를 기반으로 Custom Datadog MCP 서버를 직접 구축했습니다. 이 서버는 Datadog API를 단순히 노출하는 계층이 아니라, 운영자가 실제로 판단하는 단위에 가깝게 데이터를 재구성해 전달하는 역할을 맡도록 설계되었습니다.

그러나 데이터 입력 품질이 개선되자 또 다른 문제가 드러났습니다. 단일 Agent가 데이터 수집부터 해석, 근본 원인 분석, 조치 제안까지 모든 단계를 담당하는 구조가 실제 운영 환경에서는 불안정하다는 점이었습니다. 충분한 데이터가 주어질수록 Agent는 더 그럴듯한 결론을 빠르게 만들어낼 수 있었지만, 그 결론을 검증할 수 있는 구조가 부족했습니다. 이는 모델의 성능 문제가 아니라 설계상의 문제였습니다.

단일 Agent는 모든 책임을 동시에 지는 구조였고, 그 결과 분석 과정의 투명성과 검증 가능성이 떨어질 수밖에 없었습니다. 운영 환경에서 가장 위험한 상황은, 빠르게 도출된 결론이 검증되지 않은 상태로 조치로 이어지는 경우입니다. 이 지점에서 본 프로젝트는 “더 똑똑한 Agent”를 만드는 방향이 아니라 “분석 책임을 분리하는 구조”를 만드는 방향으로 전환했습니다.

Week 4: Multi-Agent 아키텍처 완성 – Agents as Tools 패턴 도입

분석의 각 단계를 분리하고, 각 단계의 결과가 다음 단계에서 검증 가능한 형태로 전달되도록 설계하는 것이 핵심 과제가 되었습니다. 이 과정에서 Strands Agents SDK의 Agents as Tools 패턴이 필연적인 선택이 되었습니다.

Agents as Tools 패턴은 전문화된 Agent를 @tool 데코레이터를 통해 호출 가능한 함수(Tool)로 변환하여, Orchestrator Agent가 필요에 따라 적절한 전문가 Agent를 호출할 수 있게 하는 아키텍처입니다. 이는 인간 팀이 작동하는 방식과 유사합니다—프로젝트 매니저가 모든 것을 알 필요 없이 각 전문가에게 적절히 위임하는 것처럼, Orchestrator Agent는 어떤 전문가를 언제 호출해야 하는지만 알면 됩니다.

Agents as Tools 패턴의 기술적 이해

패턴의 핵심 개념

Agents as Tools는 Strands Agents SDK가 제공하는 Multi-Agent 협업 패턴 중 하나로, 계층적 위임(Hierarchical Delegation)을 구현합니다. 이 패턴에서는 두 가지 유형의 Agent가 존재합니다.

Orchestrator Agent

사용자 또는 외부 시스템과 상호작용하며, 들어온 요청을 분석하여 어떤 전문가 Agent를 호출할지 결정합니다. Orchestrator는 모든 도메인 지식을 갖출 필요가 없으며, 대신 각 전문가의 역할과 능력을 이해하고 적절히 라우팅하는 역할을 수행합니다.

Specialist Agent (전문가 Agent)

특정 도메인에 특화된 시스템 프롬프트와 도구를 갖추고, Orchestrator로부터 위임받은 작업을 수행합니다. 각 전문가 Agent는 @tool 데코레이터를 통해 Python 함수로 래핑되어, Orchestrator가 일반 도구처럼 호출할 수 있게 됩니다.

이 패턴의 핵심적인 특징은 모델 기반 오케스트레이션(Model-driven Orchestration)입니다. Strands Agents SDK는 실행 흐름을 하드코딩하는 대신, Foundation Model(FM)의 추론 능력을 활용하여 다음에 어떤 도구를 호출할지 결정하도록 합니다. 이를 통해 복잡한 분기 로직 없이도 동적인 작업 위임이 가능해집니다.

Graph 패턴과의 차이점

Strands Agents SDK는 Agents as Tools 외에도 Graph, Swarm, Workflow 등 다양한 Multi-Agent 패턴을 제공합니다. 본 프로젝트에서 Agents as Tools를 선택한 이유를 명확히 하기 위해 Graph 패턴과의 차이점을 짚어보겠습니다.

Graph 패턴은 결정론적 방향 그래프 기반 오케스트레이션 시스템입니다. Agent들은 그래프의 노드가 되고, 엣지 의존성에 따라 정해진 순서대로 실행됩니다. 실행 순서가 그래프 구조에 의해 명시적으로 정의되며, 한 노드의 출력이 연결된 노드의 입력으로 자동 전달됩니다. Graph 패턴은 실행 순서가 사전에 결정되어 있고 예측 가능한 워크플로우에 적합합니다.

반면 Agents as Tools 패턴은 Orchestrator Agent의 추론에 의해 동적으로 실행 흐름이 결정됩니다. 어떤 전문가 Agent를 호출할지, 몇 번 호출할지, 어떤 순서로 호출할지가 모두 런타임에 FM의 판단에 의해 결정됩니다. 이는 장애 분석과 같이 상황에 따라 필요한 정보와 분석 방향이 달라지는 작업에 더 적합합니다.

본 프로젝트에서 Agents as Tools 패턴을 선택한 이유는 다음과 같습니다. 장애 상황은 매번 다른 양상을 보이며, 어떤 데이터를 먼저 수집해야 하는지, 어떤 분석이 필요한지가 상황에 따라 달라집니다. 예를 들어 배포 직후 발생한 장애라면 코드 변경 이력 분석이 우선되어야 하고, 특정 리전에서만 발생한 장애라면 인프라 상태 확인이 우선되어야 합니다. Agents as Tools 패턴은 Orchestrator가 상황을 파악한 후 적절한 전문가를 동적으로 호출할 수 있게 하여, 이러한 유연성을 제공합니다.

기술 구현 상세

FastMCP 기반 Custom Datadog MCP 서버

FastMCP는 Model Context Protocol(MCP) 서버를 빠르고 Pythonic하게 구축할 수 있는 프레임워크입니다. MCP는 AI 에이전트가 외부 도구와 데이터에 안전하고 표준화된 방식으로 연결할 수 있게 해주는 프로토콜로, “AI를 위한 USB-C 포트”라고 불리기도 합니다. FastMCP는 이 프로토콜의 복잡한 세부사항을 추상화하여, 개발자가 비즈니스 로직에만 집중할 수 있게 해줍니다.

FastMCP를 선택한 이유

FastMCP를 선택한 이유는 몇 가지가 있습니다. 첫째, @mcp.tool 데코레이터만으로 일반 Python 함수를 MCP 도구로 변환할 수 있어 개발 속도가 빠릅니다. 함수의 docstring과 타입 힌트를 자동으로 분석하여 도구 명세(Tool Specification)를 생성하므로, 별도의 스키마 정의가 필요 없습니다. 둘째, 파라미터 검증, 타입 변환, 프로토콜 준수를 FastMCP가 자동으로 처리하므로 비즈니스 로직에 집중할 수 있습니다. 셋째, STDIO와 SSE(Server-Sent Events) 두 가지 전송 방식을 지원하여 로컬 개발과 프로덕션 배포 모두에 적합합니다.

핵심 설계 원칙

Custom MCP 서버의 핵심 설계 원칙은 “숫자가 아닌 상태 변화를 전달한다”는 것이었습니다. Datadog API가 반환하는 원시 메트릭 값을 그대로 전달하는 대신, 기준선 대비 변화율, 이상 징후 여부, 관련 배포 이력 등의 맥락 정보를 함께 구조화하여 전달하도록 설계했습니다.

Datadog은 메트릭 쿼리를 위한 강력한 API를 제공합니다. api.Metric.query 메서드를 사용하면 특정 시간 범위의 메트릭 데이터를 가져올 수 있으며, Datadog의 쿼리 언어를 통해 태그 필터링, 집계, 함수 적용 등이 가능합니다. 또한 Datadog의 anomaly detection 기능은 basic, agile, robust 세 가지 알고리즘을 제공하여 메트릭의 이상 패턴을 감지할 수 있습니다. 이러한 기능들을 Custom MCP 서버에서 활용하여 Agent에게 더 풍부한 맥락을 제공했습니다.

# FastMCP Custom Datadog MCP 서버 - Pseudo Code

Server "Datadog Observability Server":

    Configuration:
        - Datadog API 인증 (환경 변수에서 API_KEY, APP_KEY 로드)
        - FastMCP 서버 인스턴스 생성

    Tool: get_service_health_status(service_name, time_range, comparison_window)
        """서비스 상태와 기준선 대비 변화 분석"""

        1. 현재 메트릭 수집:
           - Datadog Metrics API로 최근 N분간 에러율 쿼리
           - 쿼리: "avg:trace.error_rate{service:<name>}"

        2. 기준선 계산:
           - 과거 24시간 데이터로 median 기반 baseline 산출
           - robust 알고리즘: 이상치에 강건한 중앙값 사용

        3. 이상 탐지:
           - deviation = (current - baseline) / baseline * 100
           - severity: critical(>200%), warning(>50%), normal

        4. 맥락 정보 추가:
           - 최근 배포 이력 확인 (Datadog Event API)
           - 시간적 상관관계 분석

        5. Return:
           {
             current_metrics: { error_rate, data_points },
             baseline_metrics: { error_rate, comparison_window },
             anomaly_detection: { is_anomaly, deviation_%, severity },
             recent_deployments: [...],
             interpretation: "사람이 읽기 쉬운 상황 해석"
           }

    Tool: get_log_patterns(service_name, log_level, time_range)
        """에러 로그 패턴 추출 및 빈도 분석"""

        1. 로그 수집:
           - Datadog Logs API로 에러 로그 쿼리
           - 쿼리: "service:<name> status:error"

        2. 패턴 추출:
           - UUID, IP, 타임스탬프를 플레이스홀더로 대체
           - 유사 로그 그룹화

        3. Return:
           {
             total_logs_analyzed,
             top_patterns: [{ template, count, percentage, samples }],
             analysis_insight: "주요 에러 패턴 요약"
           }

    Run: mcp.run(transport="sse", port=8000)

Strands Agents SDK로 Agents as Tools 패턴 구현하기

Strands Agents SDK에서 Agents as Tools 패턴을 구현하는 핵심은 @tool 데코레이터입니다. 이 데코레이터는 일반 Python 함수를 Agent가 호출할 수 있는 도구로 변환합니다. 전문가 Agent를 이 도구 함수 내부에서 생성하고 호출함으로써, Orchestrator Agent가 전문가 Agent를 마치 일반 도구처럼 사용할 수 있게 됩니다.

# Strands Agents as Tools 패턴 - Pseudo Code

Configuration:
    - Amazon Bedrock Claude Sonnet 4.0 모델 설정
    - 리전: <REGION_CODE>

# ============================================
# 전문가 Agent들을 @tool로 래핑
# ============================================

@tool
function collect_infrastructure_data(incident_context: string) -> string:
    """
    장애 컨텍스트를 기반으로 관련 인프라 데이터를 수집합니다.

    사용 시점:
    - 장애 알림 후 메트릭/로그 수집이 필요할 때
    - RCA 분석을 위한 원시 데이터가 필요할 때

    절대 금지: 가짜 데이터 생성, 추측, 분석
    """

    DataCollector Agent 생성:
        system_prompt = DATA_COLLECTOR_SYSTEM_PROMPT
        tools = [get_service_health_status, get_eks_cluster_status, get_log_patterns]

    Agent 호출 → MCP 도구들을 사용해 실제 데이터 수집

    Return: 구조화된 인프라 데이터 (JSON)


@tool
function analyze_root_cause(collected_data: string) -> string:
    """
    수집된 데이터를 기반으로 근본 원인 분석(RCA)을 수행합니다.

    분석 프로세스 (Chain-of-Thought):
    1. 데이터 검증 → 2. 시간 축 정렬 → 3. 이상 징후 식별
    4. 상관관계 분석 → 5. 인과관계 추론 → 6. 가설 수립

    신뢰도 기준:
    - high: 3개+ 독립적 증거
    - medium: 2개 증거 또는 강한 시간적 상관관계
    - low: 1개 증거 또는 간접적 연관성
    """

    Analyzer Agent 생성:
        system_prompt = ANALYZER_SYSTEM_PROMPT
        tools = []  # 순수 추론만 수행, 외부 도구 없음

    Return: RCA 분석 결과 (JSON)


@tool
function suggest_solutions(analysis_result: string) -> string:
    """
    RCA 분석 결과를 기반으로 실행 가능한 조치 가이드를 제안합니다.

    조치 유형:
    - immediate_actions: 즉시 수행 (5분 이내)
    - short_term_actions: 단기 조치 (1시간 이내)
    - long_term_recommendations: 장기 개선 권장사항
    """

    SolutionProvider Agent 생성:
        system_prompt = SOLUTION_PROVIDER_SYSTEM_PROMPT
        tools = [search_similar_incidents]

    Return: 조치 가이드 (JSON)


# ============================================
# Orchestrator Agent 구성
# ============================================

Orchestrator Agent 생성:
    system_prompt = """
    당신은 AIOps 장애 대응 Orchestrator입니다.

    표준 작업 흐름:
    1. collect_infrastructure_data → 데이터 수집
    2. analyze_root_cause → 원인 분석
    3. suggest_solutions → 조치 제안

    각 단계의 결과를 다음 단계의 입력으로 전달하세요.
    """
    tools = [collect_infrastructure_data, analyze_root_cause, suggest_solutions]


# ============================================
# 실행
# ============================================

function run_aiops_analysis(incident_alert: string) -> dict:
    response = orchestrator_agent(incident_alert)
    Return: { analysis_result, elapsed_time, timestamp }

실제 활용 사례: AWS us-east-1 Large Scale Event 대응

사건 개요

2025년 10월 19일, AWS us-east-1 리전에서 Large Scale Event(LSE)가 발생했습니다. 한국 시간 16:05분에 Datadog에서 이상 탐지 알림이 Slack 채널로 전송되었고, Agentic AIOps 시스템이 자동으로 분석을 시작했습니다.

AI Agent의 자동 대응 과정

1단계: DataCollector Agent의 데이터 수집

Orchestrator Agent가 먼저 collect_infrastructure_data 도구를 호출했습니다. DataCollector Agent는 Datadog MCP 서버를 통해 서비스 메트릭, EKS 클러스터 상태, 에러 로그 패턴을 수집했습니다.

수집된 핵심 데이터는 다음과 같았습니다:

  • Datadog에서 Error rate가 기준선 대비 +850% 급증
  • anomaly_detection 결과: severity: critical
  • EKS: Pod restart count 증가, 노드 리소스 압박 상태 아님
  • CloudWatch: us-east-1 리전 API Gateway 응답 지연 확인
  • 중요: 분석 기간 내 내부 배포 이력 없음 → 내부 코드 변경 원인 아님

2단계: Analyzer Agent의 근본 원인 분석

Orchestrator Agent는 수집된 데이터를 analyze_root_cause 도구에 전달했습니다. Analyzer Agent는 Chain-of-Thought 방식으로 단계별 분석을 수행했습니다.

## 아래는 실제 Agent의 분석 답변 입니다. 

시간 축 정렬:

- 16:02 - CloudWatch에서 API 응답 지연 시작
- 16:03 - 서비스 에러율 상승 시작
- 16:05 - Datadog 알림 발생

상관관계 분석:

- 내부 배포 이력 없음 → 내부 코드 변경 원인 배제
- CloudWatch API 지연 시작과 에러율 상승이 1분 차이로 일치
- 영향받은 서비스들이 모두 us-east-1 리전 의존성

도출된 근본 원인:

- Root Cause Candidate: AWS us-east-1 리전 인프라 이슈로 인한 서비스 영향
- 신뢰도: high (3개 독립적 증거)
- 인과 관계 체인: AWS us-east-1 인프라 이슈 → API 응답 지연 → 타임아웃 증가 → 에러율 급증

3단계: SolutionProvider Agent의 조치 제안

마지막으로 suggest_solutions 도구가 호출되어 실행 가능한 조치 가이드가 생성되었습니다.

## 아래는 실제 Agent의 응답 입니다. 

즉시 조치 (priority 1):

- AWS Health Dashboard 확인 → 공식 장애 상황 파악 (예상 소요: 2분, 리스크: low)
- 리전 failover 준비 (priority 2, 리스크: medium - 부분적 서비스 중단 가능)

단기 조치:

- AWS us-east-1 의존 서비스 타임아웃 임계값 임시 상향 (30초 → 60초)
- 사용자 대면 에러 메시지 개선 ("일시적 서비스 지연" 안내)

장기 권장사항:

- Multi-region Active-Active 아키텍처 도입 검토
- Cross-region 자동 failover 메커니즘 구축

성과

전체 분석 과정은 3분 47초 만에 완료되었습니다. 운영자가 Slack 알림을 확인하는 시점에 이미 1차 RCA 결과와 조치 가이드가 준비되어 있었습니다. 내부 원인과 외부 원인의 빠른 구분으로 불필요한 내부 코드 리뷰나 배포 롤백 검토 시간이 절감되었고, 구조화된 분석 결과로 의사결정 속도가 향상되었습니다.

Key Takeaways

1. “가짜 데이터 생성 금지” 원칙의 구조적 구현

단순히 프롬프트에 “가짜 데이터 생성 금지”를 추가하는 것으로는 환각(Hallucination)을 완벽히 방지할 수 없습니다. 본 프로젝트에서 실제로 효과를 낸 것은 Agent 간 역할 분리와 책임 경계였습니다.

DataCollector Agent는 실제 MCP 도구에서 반환된 관측 데이터만 수집하고, Analyzer Agent는 그 데이터만을 근거로 분석을 수행하며, SolutionProvider Agent는 검증된 분석 결과와 과거 사례만 참조하도록 설계되었습니다. 각 Agent의 역할이 명확히 제한되어 있기 때문에, 데이터 없이 그럴듯한 결론을 만들어내는 것이 구조적으로 어려워졌습니다.

이 경험을 통해 얻은 교훈은 명확합니다. 환각을 줄이는 가장 효과적인 방법은 더 많은 규칙을 프롬프트에 추가하는 것이 아니라, 잘못된 행동이 불가능한 구조를 만드는 것입니다.

2. Custom MCP 서버의 필요성

오픈소스 MCP 서버는 범용적이지만 특정 도메인 요구사항에는 한계가 있습니다. Datadog API가 반환하는 원시 숫자를 Agent에게 그대로 전달하면, Agent는 그 숫자의 맥락을 이해하기 어렵습니다. “15%”라는 에러율이 높은 것인지 낮은 것인지, 급격히 증가한 것인지 점진적으로 변한 것인지를 판단하려면 추가적인 맥락이 필요합니다.

FastMCP를 사용하면 이러한 도메인 특화 MCP 서버를 빠르게 구축할 수 있습니다. 핵심은 운영자가 판단하는 단위에 가깝게 데이터를 재구성하는 것입니다. 기준선 대비 변화율, 이상 징후 여부, 관련 이벤트와의 시간적 연관성 등을 함께 제공하면, Agent는 운영자와 유사한 수준의 상황 인식을 가질 수 있습니다.

3. Agents as Tools 패턴의 유연성

Agents as Tools 패턴은 Graph나 Workflow 패턴과 달리 실행 흐름이 사전에 고정되지 않습니다. Orchestrator Agent의 LLM이 상황을 판단하여 어떤 전문가를 어떤 순서로 호출할지 동적으로 결정합니다. 이는 장애 분석과 같이 상황에 따라 필요한 정보와 분석 방향이 달라지는 작업에 적합합니다.

또한 이 패턴은 점진적 확장이 용이합니다. 새로운 전문가 Agent가 필요하면 @tool 데코레이터로 래핑하여 Orchestrator의 도구 목록에 추가하기만 하면 됩니다. 기존 코드를 수정할 필요 없이 새로운 능력을 추가할 수 있습니다.

4. 시스템 프롬프트 설계의 중요성

효과적인 시스템 프롬프트는 Agent의 출력 품질을 결정짓습니다. 본 프로젝트에서 적용한 핵심 기법들은 다음과 같습니다:

    • 역할과 책임의 명확한 정의: “당신은 ~입니다”로 시작하여 Agent의 정체성과 역할을 명확히 합니다.
    • Structured Output 명시: JSON 스키마를 시스템 프롬프트에 포함하여 일관된 출력 형식을 보장합니다.
    • Chain-of-Thought 유도: “다음 단계를 순서대로 수행하세요”와 같이 명시적인 추론 단계를 제시합니다.
    • Negative Prompting: “~하지 마세요”를 통해 금지 사항을 명확히 합니다.

5. 자동화와 거버넌스의 균형

Agentic AIOps 시스템은 자동 분석과 조치 제안을 제공하지만, 최종 실행 권한은 항상 사람에게 남겨두었습니다. 이는 기술적 한계가 아니라 운영 거버넌스의 핵심 원칙입니다. 각 Agent와 MCP 서버는 최소 권한 원칙에 따라 설계되었으며, 실제 환경에 영향을 미치는 권한(서비스 재시작, 배포 롤백 등)은 의도적으로 배제되었습니다.

이러한 설계는 자동화의 이점을 유지하면서도, 예기치 않은 행동으로 인한 위험을 최소화합니다.

사용된 기술 스택

Category Technology
AI/ML Amazon Bedrock (Claude Sonnet 4.0)
Agent Framework Strands Agents SDK (Agents as Tools 패턴)
MCP FastMCP (Custom Datadog MCP Server)
Infrastructure Amazon EKS, Amazon CloudWatch
Monitoring Datadog (Metrics, Logs, APM)
Communication Slack (Bolt SDK)
Vector DB Amazon OpenSearch (과거 RCA 문서 검색용)

결론

Agentic AIOps의 목표는 더 많은 자동화를 도입하는 것이 아닙니다. 핵심은 운영 의사결정의 품질을 지속적으로 개선하는 데 있습니다. 자동 분석은 사람을 대체하기 위한 수단이 아니라, 사람이 더 나은 판단을 내릴 수 있도록 돕는 구조적 장치입니다.

Samsung Account 사례에서 Agentic AIOps는 분석을 자동화했지만, 책임을 자동화하지는 않았습니다. 그 결과 운영 조직은 더 빠르고 일관된 판단을 내릴 수 있게 되었고, 운영 경험은 개인의 기억이 아닌 시스템의 지식으로 축적되기 시작했습니다.

이 사례는 특정 기술 스택이나 모델의 우수성을 증명하기 위한 이야기가 아닙니다. 오히려 어떤 문제를 어떻게 정의하고, 어떤 원칙으로 구조를 설계했는지가 운영 자동화의 성패를 좌우한다는 점을 보여주는 사례입니다. Agentic AIOps는 단번에 완성되는 해법이 아니라, 운영 조직과 함께 진화해 나가는 구조입니다.

참고 자료

Strands Agents SDK

FastMCP & Model Context Protocol

Datadog API & Monitoring

Amazon Bedrock

AIOps 시장 및 기술 트렌드

 

임민승 삼성전자 Sr. Engineer

임민승

임민승 프로는 삼성계정 서비스 개발팀의 Sr. Engineer로서 삼성어카운트의 백엔드 서버 개발을 담당하고 있습니다. 안드로이드 앱 개발, 삼성클라우드 프론트엔드 웹 개발, 광고 서비스의 DevOps 및 빅데이터 ETL 개발 등 다양한 영역을 경험해왔습니다. 이러한 폭넓은 실무 경험을 바탕으로 최근에는 AI를 실제 서비스와 운영 환경에 적용하는 방향에 관심을 두고, 효과적으로 활용하기 위한 시도와 연구에 집중하고 있습니다.

Kyutae Park, Ph.D

Kyutae Park, Ph.D

박규태 솔루션즈 아키텍트는 머신러닝과 MLOps 전문성을 기반으로 삼성전자 고객들의 클라우드 전환, 머신러닝 워크로드 구축을 지원하며, 최근에는 생성형 AI와 Agentic AI를 활용한 지능형 자동화 및 운영 혁신에도 집중하고 있습니다. AWS AI/ML 서비스 기반의 MLOps 환경 구축과 최신 생성형 AI·Agentic AI 기술의 인더스트리 적용을 통해 고객의 AI 혁신과 비즈니스 경쟁력 강화를 이끌고 있습니다.

Youngmin Joung

Youngmin Joung

정영민 솔루션스 아키텍트는 클라우드에 기반한 대 규모 서비스의 DevOps 및 SRE 엔지니어 경험을 통해 엔터프라이즈 고객이 비즈니스 목표를 달성하기위해 적절한 아키텍트를 제안하고, 고객의 기술적 문제를 해결하는데 도움을 드리는 역할을 수행합니다. 특히 Observability 도메인에 대한 전문성을 통해 고객 비즈니스의 문제 해결을 지원합니다.