GS리테일, AIOps Agent로 운영 자동화 혁신

GS리테일은 전국 18,000여 개 매장과 O4O 플랫폼, 홈쇼핑까지 아우르는 대규모 유통 서비스를 24/7로 운영하고 있다. 하지만 인시던트가 나면 운영자는 Datadog, Bitbucket, Confluence, AWS, EKS, DB 등 평균 5~6개 도구를 오가며 원인을 찾아야 했고, 분석에는 평균 30분 이상이 걸렸다.

이 문제를 풀기 위해 클라우드인프라팀은 숙련된 SRE의 사고방식을 AI에 주입한 AIOps Agent를 구축했다. 핵심은 Amazon Bedrock Converse API와 **Model Context Protocol(MCP)**를 결합해, AI가 상황에 맞는 도구를 스스로 고르고 결과를 해석하며 근본 원인을 끝까지 추적하도록 만든 점이다.

설계 기준은 세 가지였다.

• 도구 활용 능력: 모델이 외부 도구를 직접 호출하고 추론을 이어갈 수 있어야 함
• 비용과 품질의 균형: 반복 조사에는 빠른 Claude Sonnet 계열, 최종 판단에는 Claude Opus 4.5 활용
• 기존 운영 도구 연동: Datadog, Bitbucket, Confluence, AWS, EKS, PostgreSQL, OpenSearch 등 7개 이상 도구를 AI가 직접 사용

운영 흐름은 인시던트 감지부터 리포트 작성까지 자동화됐다. Datadog Webhook이 Amazon EventBridge로 이벤트를 보내고, ECS Fargate의 Data Filter Worker가 중복 제거와 심각도 분류를 수행해 DynamoDB에 저장한다. 이후 AI Orchestration Worker가 NEW 상태를 감지해 분석을 시작하고, 도구 호출 루프를 돌며 로그·메트릭·트레이스·커밋 이력·EKS 상태·DB 쿼리를 종합한다.

에이전트의 핵심은 동적 도구 로딩과 자율적 Thinking 로직이다. 인시던트가 DB 장애면 PostgreSQL 도구를, K8s 이슈면 EKS 도구를, 코드 이슈면 Bitbucket 도구를 선택적으로 로딩해 토큰 비용과 혼란을 줄였다. 또한 시스템 프롬프트에 “증상 나열이 아니라 왜 발생했는지 끝까지 추적하라”, “의심되면 반드시 직접 확인하라”, “추측과 사실을 구분하라” 같은 원칙을 넣어 5 Whys 방식의 근본 원인 분석을 반복하게 했다.

분석이 끝나면 결과는 Confluence에 RCA 보고서로 저장되고, Microsoft Teams 채널에 요약 알림이 자동 발송된다. 운영자는 별도 대시보드 없이 Teams에서 인시던트의 원인과 권장 조치를 바로 확인할 수 있다.

구현된 기술 스택은 다음과 같다.

• Datadog MCP: 16개 조직의 메트릭, 로그, APM 트레이스를 공식 서버로 직접 조회
• Bitbucket MCP: 최근 커밋, PR 변경사항, 코드 검색으로 배포 원인 추적
• AWS / EKS / PostgreSQL / OpenSearch MCP: 인프라 상태, Pod 이벤트, 슬로우쿼리, 로그 패턴 분석
• RAG: Amazon S3 Vectors와 Titan Embeddings v2로 과거 인시던트 유사 사례를 검색

이 구조의 결과, 인시던트 분석 시간은 평균 30분에서 약 2분으로 줄어 93% 단축됐다. 사람이 도구를 하나씩 넘나들던 운영 방식에서, AI가 스스로 증거를 수집하고 원인을 좁혀 가는 자율 운영 체계로 전환한 셈이다.