AWS 에러 로그를 읽고 무엇이 잘못되었는지 5초 만에 알려주는 AI 시스템을 구축했습니다

문제점

저는 운영 환경에서 약 200개의 Lambda 함수와 몇 개의 Glue 작업을 실행하고 있습니다. 몇 주마다 무언가 고장이 납니다. 그러면 즉시 CloudWatch 알람 이메일을 받습니다. "에러 횟수: 12". 좋습니다, 무언가 잘못되었다는 것은 알 수 있습니다. 하지만 쉬운 부분은 거기서 끝납니다.

이제 무엇(WHAT)이 잘못되었는지 알아내야 합니다. 이 과정이 30~45분이 걸리는 부분입니다:

• CloudWatch를 열고 200개 이상의 로그 그룹 중에서 올바른 로그 그룹을 찾습니다.
• 실제 에러 메시지를 찾기 위해 로그 스트림(log streams)을 스크롤합니다.
• 스택 트레이스(stack trace)를 읽고 무슨 일이 일어났는지 이해하려고 노력합니다.
• 최근에 누군가 배포했는지 확인합니다 (Lambda 콘솔을 열고 타임스탬프를 비교합니다).
• 다른 서비스들도 고장 났는지 확인합니다.
• 에러를 Google에서 검색하여 해결 방법을 찾아냅니다.
• 팀에 무슨 일이 일어났는지 알립니다.

알림은 즉각적이었습니다. 하지만 조사는 그렇지 않았습니다. 저는 로그를 읽고 점들을 연결하는 데 매번 30~45분을 소비했습니다.

저는 그 과정에 지쳤습니다. 에러는 로그에 바로 나와 있습니다. 배포 타임스탬프는 Lambda 설정에 있습니다. 트래픽 지표는 CloudWatch에 있습니다. 모든 정보는 존재합니다. 저는 단지 로그를 읽고, 점들을 연결하여, 저에게 정답을 알려줄 무언가가 필요할 뿐입니다.

그래서 저는 정확히 그 역할을 하는 시스템을 구축했습니다. 이 시스템은 에러를 포착하고, 모든 컨텍스트(context)를 자동으로 수집하여, Amazon Bedrock으로 보내고, 해결 방법과 함께 근본 원인(root cause)을 이메일로 저에게 보내줍니다. 저에게 30~45분이 걸렸던 조사가 이제는 5초 만에 끝납니다.

이 프로젝트가 하는 일

AI Ops Sentinel은 모든 Lambda 함수, Glue 작업, ECS 태스크 등 CloudWatch Logs에 기록되는 모든 것을 감시합니다. 무언가 에러가 발생하면:

1. 에러를 즉시 포착합니다 (폴링 (Polling) 방식이 아닌 푸시 (Push) 모델)
2. 로그에서 모든 자격 증명(Credentials)이나 개인정보(PII)를 제거합니다 (Bedrock Guardrails 사용)
3. 해당 함수가 최근에 배포되었는지 확인합니다
4. 현재 얼마나 많은 트래픽이 영향을 받고 있는지 확인합니다
5. 다른 서비스들도 동시에 장애가 발생했는지 확인합니다
6. 동일한 에러가 이전에 발생한 적이 있는지 확인합니다
7. 근본 원인 분석 (Root Cause Analysis)을 위해 이 모든 컨텍스트를 Bedrock으로 전송합니다
8. 해결 방법이 포함된 진단 결과를 이메일로 전송합니다

단 한 번의 배포로 전체 계정을 커버합니다. 다음 주에 새로 만드는 함수들도 자동으로 포함됩니다. 함수별로 별도의 설정이 필요 없습니다.

왜 단순히 CloudWatch Alarm + SNS를 사용하지 않나요

모두가 이미 사용하고 있는 방식입니다. 에러 수가 0보다 커지면 CloudWatch Alarm이 작동하여 SNS 이메일을 보냅니다. 그 이메일이 제공하는 정보는 다음과 같습니다:

Subject: ALARM: payment-processor-errors

StateChangeTime: 2025-06-19T09:05:03Z
...

그게 전부입니다. 여전히 모든 수동 조사를 직접 수행해야 합니다.

반면 AI Ops Sentinel은 동일한 에러에 대해 근본 원인, 해결 방법, 최근 배포 여부, 영향을 받는 사용자 수, 그리고 조사를 위한 CLI 명령어를 보냅니다. 이 모든 것이 단 5초 만에 하나의 이메일에 담겨 전달됩니다.

알람은 불이 났다는 사실을 알려줍니다. 이 시스템은 어느 방에서 불이 났는지, 무엇이 불을 일으켰는지 알려주고 소화기까지 건네줍니다.

아키텍처 (Architecture)

전체 시스템이 어떻게 결합되는지는 다음과 같습니다:

흐름은 간단합니다:

1. 모든 서비스(Lambda, Glue, ECS 등 무엇이든)는 CloudWatch에 로그를 기록합니다. 이는 별도의 설정 없이 자동으로 수행됩니다.

2. 계정 수준의 구독 필터(Subscription Filter) 하나가 모든 로그 그룹을 감시합니다. 로그 이벤트가 에러 패턴(ERROR, Task timed out, OOM, missing modules 등)과 일치하면, CloudWatch는 즉시 Analyzer Lambda로 이를 푸시(push)합니다. 이는 폴링(poll) 방식이 아닌 푸시 방식이므로 지연이 없습니다.

3. Analyzer Lambda가 두뇌 역할을 합니다. 이 함수는 로그 이벤트를 디코딩하고, 어떤 서비스에서 발생했는지 식별하며, Bedrock Guardrails를 통해 자격 증명(credentials)을 제거하고, 컨텍스트(배포 이력, 영향 범위(blast radius), 과거 사고, 연관된 장애 등)를 수집합니다. 그 후 모든 정보를 Bedrock Nova Lite로 보내 진단을 수행하고, 사고 내용을 DynamoDB에 저장하며, SNS를 통해 알림을 보냅니다.

4. 에러가 발생한 후 약 5초 뒤에 이메일을 받게 됩니다.

또한, 별도의 Weekly Digest Lambda가 매주 월요일 오전 9시에 실행됩니다. 이 함수는 지난 한 주 동안의 모든 사고를 스캔하여 Bedrock에 요약을 요청하고, SES를 통해 서식이 지정된 HTML 보고서를 사용자에게 전송합니다.

모니터링 시스템 자체를 모니터링할 수 있도록 Analyzer의 호출 횟수, 에러, 실행 시간(duration)을 보여주는 CloudWatch Dashboard도 제공됩니다.

사용된 서비스: CloudWatch Logs, CloudWatch Subscription Filter, CloudWatch Metrics, CloudWatch Dashboard, Lambda (3개 함수), Amazon Bedrock Guardrails, Amazon Bedrock Nova Lite, SNS, SES, DynamoDB, SSM Parameter Store, EventBridge, S3, CloudFormation. 총 15개의 서비스를 11개의 모듈형 스택(modular stacks)으로 배포했습니다.

여기서 AI가 잘 작동하는 이유

ChatGPT에 에러 메시지를 붙여넣고 "무엇이 잘못되었나요?"라고 물으면, "입력값을 확인하세요", "페이로드를 검증하세요"와 같은 일반적인 답변을 듣게 됩니다. 별로 도움이 되지 않죠.

AI Ops Sentinel이 유용한 답변을 제공할 수 있는 이유는 단순히 에러만 보내는 것이 아니라, 전체 맥락(full story)을 함께 보내기 때문입니다:

• 에러가 오전 9:05에 발생함
• 이 함수는 오전 8:53에 배포됨 (12분 전)
• 지난 한 주 동안 동일한 에러가 4번 발생함
• 현재 시간당 1,200개의 요청이 이 함수에 유입되고 있으며, 그중 15%가 실패하고 있음
• 다른 두 서비스 (Glue 작업 및 또 다른 Lambda) 또한 지난 5분 이내에 에러를 발생시키기 시작함

이러한 모든 맥락(context)이 있다면, 가장 저렴한 Bedrock 모델(호출당 약 $0.001인 Nova Lite)조차도 진정으로 유용한 근본 원인 분석 (root cause analysis)을 제공합니다. 핵심은 비싼 모델을 사용하는 것이 아니라, 모델에게 올바른 정보를 제공하는 것입니다.

자격 증명 보안 (Credentials Safety)

이 부분은 명확히 짚고 넘어가고 싶습니다. 운영 환경의 에러 로그에는 비밀 정보(secrets)가 포함되어 있습니다. 누군가 가공되지 않은 요청(raw request)을 로그로 남겼기 때문에, 비밀번호가 포함된 데이터베이스 연결 문자열, JWT 토큰, API 키, 이메일 주소, 심지어 신용카드 번호가 에러 메시지에 나타나는 것을 본 적이 있습니다.

만약 이러한 로그를 어떤 AI 모델로든 전송한다면, 이는 자격 증명(credentials)을 유출하는 행위입니다.

Bedrock이 에러 텍스트를 확인하기 전에, 먼저 Bedrock Guardrails를 거치게 됩니다. Guardrail은 민감한 데이터를 플레이스홀더(placeholder)로 교체합니다:

• 데이터베이스 URL은 {DatabaseConnectionString}으로 변경됩니다.
• Bearer 토큰은 {BearerToken}으로 변경됩니다.
• 이메일은 {EMAIL}로 변경됩니다.
• API 키는 {GenericApiKey}로 변경됩니다.

AI는 여전히 "데이터베이스 연결 실패"를 이해할 수 있지만, 실제 비밀번호는 절대 보지 못합니다. 또한 귀하가 받는 이메일에도 가공되지 않은 자격 증명은 포함되지 않습니다.

저는 차단(BLOCK)이 아닌 익명화(ANONYMIZE) 방식을 모든 곳에 사용합니다. 차단하게 되면 AI가 맥락을 얻지 못해 아무것도 진단할 수 없게 됩니다. 익명화는 민감한 부분을 제거하면서도 전체적인 맥락(story)을 온전하게 유지해 줍니다.

스마트 중복 제거 (Smart Deduplication)

만약 함수 하나에서 10분 동안 50번의 에러가 발생한다면, 50통의 이메일을 받고 싶지는 않을 것입니다. 단 한 통의 이메일이면 충분합니다.

하지만 2분 뒤에 동일한 함수에서 다른 유형의 에러가 발생한다면, 그 알림은 반드시 받아야 합니다. 이는 연쇄 장애 (cascading failure)일 수 있기 때문입니다.

규칙: 동일한 함수 + 동일한 에러 유형 = 30분 동안 억제(suppressed). 다른 에러 유형 = 항상 즉시 알림.

주간 요약 (Weekly Digest) (월요일 오전 9시)

실시간 알림과는 별개로, 매주 월요일 아침마다 Weekly Digest (주간 요약) Lambda가 실행됩니다. 이 함수는 DynamoDB에서 지난 7일 동안 발생한 모든 인시던트 (incidents)를 스캔하여 Bedrock으로 보내 요약을 생성한 뒤, SES를 통해 포맷팅된 HTML 보고서를 이메일로 전송합니다.

보고서에는 다음 내용이 포함됩니다:

• 해당 주차의 총 인시던트 (incidents) 수
• 실패율이 가장 높은 상위 5개 함수/작업 (functions/jobs)
• 심각도별 분류 (Critical, High, Medium 각각의 개수)
• AI가 작성한 요약: 패턴, 가장 큰 리스크, 한 가지 권장 사항

대시보드를 확인하거나 인시던트 (incidents)를 검토해야 한다는 사실을 기억할 필요가 없습니다. 요약본이 직접 찾아오기 때문입니다. 만약 별다른 이슈가 없었던 조용한 한 주였다면, 이메일에는 단순히 "인시던트 없음, 모든 시스템 정상"이라고 표시됩니다.

이 과정에서 SNS가 아닌 SES를 사용하는 이유는 SES가 테이블, 색상, 통계와 같은 HTML 포맷팅을 지원하기 때문입니다. 실시간 알림은 포맷팅보다 속도가 중요하므로 계속 SNS를 사용합니다.

배포 방법 (How to Deploy)

이 프로젝트는 오픈 소스입니다. 모든 것은 배포 스크립트와 함께 하나의 리포지토리 (repo)에 들어 있습니다.

사전 요구 사항:

• AWS CLI 설정 완료
• 해당 리전에서 Bedrock Nova Lite 모델 액세스 활성화
• 알림을 받을 이메일 주소

단계:

# Clone
git clone https://github.com/utkarsh-rastogi-aws/ai-ops-sentinel.git
cd ai-ops-sentinel
...

테스트하기 (Testing It)

이 프로젝트에는 의도적으로 에러를 생성하는 테스트용 Lambda와 테스트용 Glue 작업 (job)이 포함되어 있습니다:

# Lambda tests
./test-errors.sh lambda key_error         # 딕셔너리 키 누락 (Missing dictionary key)
./test-errors.sh lambda connection        # DB 비밀번호 로그 기록 (가드레일이 이를 제거함)
...

테스트를 실행한 후 약 10초 뒤에 이메일을 확인해 보세요. AI의 진단 결과가 도착해 있을 것입니다.

connection 테스트는 가드레일 (Guardrails)이 실제로 작동하는 모습을 볼 수 있는 흥미로운 사례입니다. 이 테스트는 비밀번호와 Bearer 토큰이 포함된 전체 데이터베이스 URL을 의도적으로 로그에 기록합니다. 수신된 이메일에서 이러한 정보들은 플레이스홀더 (placeholder)로 대체되어 있을 것입니다. AI는 실제 자격 증명 (credentials)을 전혀 보지 않고도 "데이터베이스 연결 실패"라고 정확하게 진단합니다.

배포되는 항목

11개의 CloudFormation 스택: