50개 이상 계정의 알림 지옥을 해결하는 Chaplin

월요일 아침, 50개가 넘는 AWS 계정을 관리하는 기업 운영팀은 쏟아지는 헬스 알림에 직면한다. Amazon Linux 2 지원 종료, RDS 버전 지원 중단, EC2 인스턴스 교체 같은 알림이 수십 개 계정에서 동시에 발생하기 때문이다. 어떤 이벤트가 실제 운영 시스템에 영향을 주는지, 긴급 건과 장기 계획 건을 구분하는 작업에 많은 시간이 소요된다. AWS는 이러한 반복적인 분석 작업을 AI 에이전트로 전환해 운영자가 직접 답을 찾는 자가 서비스 체계인 Chaplin(Customer Health and Planned Lifecycle Intelligence Nexus)을 오픈소스로 공개했다.

그동안 운영팀은 헬스 이벤트의 의미와 비즈니스 영향도를 파악하기 위해 기술 계정 관리자(TAM, Technical Account Manager)의 해석을 기다려야 했다. 분석 결과가 나올 때까지 의사결정이 지연되어 적기 대응 시점을 놓치는 경우가 많았고, 팀 리소스는 신규 기능 개발보다 사후 대응에 더 많이 투입되었다.

Chaplin은 Amazon Bedrock과 MCP(Model Context Protocol)를 활용해 이 병목을 제거한다. 운영자는 자연어로 질문하여 향후 60일 내 예정된 RDS 수명 주기 이벤트 확인, 긴급도 순으로 정렬된 EC2 이벤트 요약, 운영 환경에 영향을 주는 보안 패치 확인 같은 분석 결과를 즉각적으로 얻을 수 있다. 상세한 배포 지침과 코드는 Chaplin AWS Health Agentic Assistant 저장소에서 확인할 수 있다.

데이터 수집부터 MCP 서버까지의 3계층 구조

데이터 계층은 AWS Health API에서 시작해 Amazon EventBridge가 실시간 트리거를 발생시키고 AWS Lambda 수집 함수가 교차 계정 IAM 역할을 통해 이벤트를 가져오는 구조다. 수집된 데이터는 Amazon S3 데이터 레이크에 계정, 날짜, 이벤트 유형별로 파티셔닝되어 저장된다. 이후 S3 이벤트 알림이 다시 AWS Lambda를 작동시켜 JSON 형식의 헬스 이벤트를 Amazon DynamoDB로 로드한다. 이는 멀티 계정 데이터를 중앙 집중화해 AI 분석이 가능하게 만드는 전처리 작업이다.

중간 계층은 원시 데이터를 AI가 읽을 수 있는 정보로 변환해 MCP 서버로 노출한다. MCP는 AI 모델이 외부 데이터나 도구에 표준화된 방식으로 접근하게 돕는 오픈 규약이다. Amazon DynamoDB는 이벤트 유형, 심각도, 날짜, 계정 ID와 같은 구조화된 메타데이터를 저장하고 인덱싱한다. AI 에이전트는 이 MCP 서버의 표준 인터페이스를 통해 필요한 정보를 요청하고 수신하며, 운영자가 복잡한 DB 쿼리문을 작성하지 않아도 정확한 필터링과 집계를 수행할 수 있다.

클라이언트 계층은 사용자가 마주하는 접점으로 Claude Code나 Kiro CLI 같은 MCP 호환 AI 어시스턴트가 수행한다. 운영자가 터미널이나 채팅창에서 자연어로 질문하면 AI 어시스턴트가 MCP 서버에 요청을 보내 DynamoDB에서 정제된 답변을 받아온다. [Figure 1]에서 볼 수 있듯 전체 흐름은 데이터 수집, MCP 서버의 변환, AI 어시스턴트의 응답이라는 3단계로 이어진다.

이 구조의 이점은 데이터 수집 경로와 AI 분석 도구를 분리해 유연성을 확보했다는 점이다. 파이프라인을 한 번 구축하면 AI 모델을 Amazon Bedrock에서 OpenAI나 로컬 모델인 Ollama로 변경하더라도 수집 체계를 다시 설계할 필요가 없다. 또한 MCP 표준 규격을 사용해 특정 AI 어시스턴트에 종속되지 않고 분석 접점을 확장하기 쉽다.

RAG의 수치 환각을 잡는 '구조화 쿼리 에이전트'

기존의 RAG(Retrieval-Augmented Generation)는 벡터 유사도 검색에 의존한다. 이 방식은 의미적으로 유사한 내용을 찾는 데는 능숙하지만 수치 집계에서는 확률적인 한계를 보인다. 예를 들어 958건의 헬스 이벤트가 발생했음에도 AI가 이를 190건으로 보고하는 식의 환각 현상이 발생한다. 이는 확률 기반의 토큰 예측과 유사도 중심 검색 메커니즘이 결합하며 발생하는 오차로, 운영 환경에서는 잘못된 의사결정 리스크가 된다.

AWS 헬스 이벤트 데이터는 구조화된 메타데이터(이벤트 유형, 서비스 이름, 리소스, 타임스탬프, 심각도, 계정 ID)와 비구조화된 텍스트 설명(문제 설명, 영향 평가, 권장 조치)으로 나뉜다. 모든 데이터를 벡터화해 유사도 검색으로만 처리하면 메타데이터 영역에서 수치 환각이 발생할 가능성이 매우 높다.

이를 해결하기 위해 Chaplin은 Natural Language to Structured Query Agent를 도입했다. 이 에이전트는 사용자의 자연어 질문을 DynamoDB의 정확한 필드 필터로 변환한다. `event_type`이나 `affected_accounts` 같은 데이터베이스 스키마를 기반으로 질문 의도에 맞는 필터를 구성한다. 예를 들어 운영 계정의 EC2 교체 이벤트를 요청하면 해당 필드에 정확한 값을 대입하는 구조화 쿼리를 생성해 데이터베이스에 요청함으로써, 계산을 AI가 아닌 데이터베이스가 수행하게 만든다.

결과적으로 수치 집계와 필터링은 결정론적인 데이터베이스 쿼리에 맡기고, 추출된 결과에 대한 해석과 요약만 Amazon Bedrock의 Claude 모델이 담당한다. 이렇게 처리하면 AI의 수치 환각을 차단하고 불필요한 AI 추론 비용을 줄일 수 있다.

자연어 질의로 바꾸는 운영 워크플로의 실질적 변화

수십 개의 계정에서 쏟아지는 알림 메일을 열어보고 엑셀에 정리해 공유하던 수동 필터링 과정은 운영팀의 주요 피로 요인이었다. 이제는 AI 어시스턴트에게 평소 쓰는 말로 질문해 실행 가능한 인사이트를 즉시 뽑아낼 수 있다.

여기서 얻은 분석 결과는 JIRA, GitHub, ServiceNow 같은 기존 협업 도구와 연동된다. 헬스 이벤트 분석부터 티켓 발행과 담당자 할당까지의 흐름을 하나의 워크플로로 묶어, 분석 결과가 곧바로 작업 지시서로 이어지는 환경을 구축할 수 있다.

또한 리소스 태그, 환경 분류, 소유자 정보 같은 메타데이터를 헬스 이벤트 분석에 결합한다. 단순히 RDS 버전이 종료된다는 사실을 넘어, 해당 리소스가 어떤 서비스의 소유인지, 실제 운영 환경의 어떤 핵심 모듈에 영향을 주는지 정확히 식별한다. 시스템 중심의 알림을 비즈니스 영향도 분석으로 전환하여 운영팀이 자체적으로 마이그레이션 계획을 세울 수 있게 한다.

도입 시에는 분석 결과가 실제 티켓팅 시스템으로 얼마나 빠르게 전달되는지를 살펴야 한다. MCP를 통해 기존 워크플로에 헬스 분석을 직접 통합함으로써 단순 알림 확인에 드는 리소스를 줄이고, 기술 계정 관리자가 제공하던 인사이트를 내부 시스템으로 내재화해 운영 자립도를 높이는 것이 핵심이다.

비용 최적화와 모델 선택의 유연성

Chaplin은 모든 요청을 LLM으로 처리하지 않고 패턴 우선 처리 방식을 사용한다. 규칙 기반 분류기를 통해 정형화된 이벤트를 먼저 처리하며 AI 호출 비용을 낮춘다. 또한 30일, 60일, 120일 단위의 윈도우 필터를 적용한 사전 정의 뷰를 제공해, 수백 개의 계정 알림 중 즉각 대응이 필요한 항목만 빠르게 걸러낸다.

특정 벤더에 종속되지 않는 모델 불가지론적 설계도 특징이다. 기본적으로 Amazon Bedrock의 Claude를 사용하지만, 설정에 따라 OpenAI, Anthropic, Ollama 같은 로컬 모델까지 지원한다. 특히 Ollama를 통한 로컬 모델 운영은 데이터 외부 유출이 민감한 폐쇄망 환경에서 실질적인 대안이 된다. 운영자는 보안 정책과 예산에 맞춰 추론 모델을 선택해 토큰당 비용을 직접 제어할 수 있다.

효율을 높이기 위해 지능형 캐싱 기술을 적용해 동일하거나 유사한 질문에 대한 API 호출과 대기 시간을 줄였다. 수치 집계나 정확한 필터링이 필요한 분석은 AI 추론을 거치지 않고 AWS Health API 스키마 기반의 구조화 쿼리를 DynamoDB에서 직접 실행해 정확도를 확보하고 비용을 제거했다. 규칙으로 처리할 영역과 AI가 해결할 영역을 명확히 나누어 운영 효율을 극대화한 구조다.

수십 개의 AWS 계정에서 쏟아지는 알림을 일일이 확인하던 운영팀의 피로감은 이제 자연어 질의와 구조화 쿼리 에이전트의 조합으로 해결 가능하다. 단순한 챗봇 도입보다 MCP를 통해 JIRA나 GitHub 같은 기존 협업 도구에 분석 기능을 직접 통합하는 것이 실질적인 운영 효율을 결정한다. 기술 계정 관리자의 답변을 기다리는 수동적 구조에서 내부 시스템으로 인사이트를 내재화하는 능동적 구조로 전환하는 것이 핵심이다. Chaplin 저장소의 배포 지침을 따라 MCP 서버를 구축하며 우리 팀의 운영 자립도를 직접 확인해 보길 권한다.