
AWS에서 에이전트 기반 On-Call Copilot 구축하기 (파트 1: 이유와 범위)
요약
AWS Bedrock과 Claude를 활용하여 운영 알람을 분석하고 대응 방안을 제안하는 에이전트 기반 On-Call Copilot 구축 과정을 다룹니다. RAG를 통해 런북과 과거 사례를 검색하고, 사용자의 승인 하에 진단 도구를 실행하는 안전한 에이전트 설계에 집중합니다.
핵심 포인트
- 단순 로그 요약을 넘어 근본 원인 추론 및 진단 제안 수행
- RAG를 활용한 런북 및 과거 인시던트 데이터 검색
- 안전성을 위해 읽기 전용 도구 및 사용자 승인 단계 포함
- MVP 단계로서 특정 알람 유형과 제한된 범위 설정
저는 재미를 위해 에이전트 (agents)를 만들고, 그것들이 어디서 깨지는지 알아내기 위해 일부러 망가뜨려 봅니다. 이것은 제가 올해 Amazon Bedrock, AWS Strands, Bedrock AgentCore, 그리고 Kiro를 사용하여 진행하는 3가지 프로젝트 중 첫 번째 프로젝트이며, 주의사항 (gotchas)을 포함한 전체 구축 과정을 게시하고 있습니다.
요약 버전
대부분의 "DevOps를 위한 AI" 데모는 로그를 요약하고 거기서 멈춥니다. 저는 그 반대를 원합니다. Incident Copilot은 실제 운영 알람 (production alert)을 읽고, 이와 관련된 런북 (runbooks) 및 과거 인시던트 (incidents)를 가져오며, 가능한 근본 원인 (root cause)에 대해 추론하고, 제가 다음에 확인해야 할 사항을 추천합니다. 그리고 무언가를 실행하기 전에 저에게 먼저 물어봅니다.
제가 만들고 있는 것
Incident Copilot은 하나의 운영 알람을 가져와 에이전트 루프 (agent loop)를 실행합니다:
- 알람을 분류하고 요약합니다.
- RAG (Retrieval-Augmented Generation)를 통해 런북 (runbooks)과 과거의 사후 분석 (postmortems)을 검색합니다.
- 근본 원인 가설을 제안합니다.
- 최근 배포를 확인하거나 에러율 지표 (error-rate metric)를 쿼리하는 것과 같은 한두 가지의 읽기 전용 진단 작업 (read-only diagnostic actions)을 제안합니다.
- 제가 승인할 때까지 기다립니다.
- 승인된 도구 (tools)를 실행하고 요약 및 권장되는 다음 단계를 반환합니다.
버전 1은 자동 복구 (auto-remediation)를 수행하지 않습니다. 이는 의도적으로 선택한 사항입니다.
성패를 결정짓는 결정: 범위 축소
저는 이 프로젝트에 일주일에 2~4시간을 할애할 수 있습니다. 사이드 프로젝트를 망치는 것은 추론 능력이 떨어지는 모델이 아닙니다. 3주 차에 포기하게 만들 정도로 너무 큰 범위입니다. 따라서 MVP (Minimum Viable Product)는 작게 유지합니다:
- 하나의 알람 유형, 높은 API 지연 시간 (latency). "모든 인시던트"가 아닙니다.
- 읽기 전용 도구 (Read-only tools). 에이전트는 살펴볼 뿐, 건드리지 않습니다.
- 어떤 도구가 실행되기 전에 제가 승인합니다.
재미있는 부분은 안전장치 (safety rails)가 있음에도 불구하고 그것이 아니라, 바로 그 안전장치 자체입니다. 묻지도 않고 kubectl delete를 실행할 수 있는 On-call 에이전트는 그 자체가 사후 분석 (postmortem)의 대상이 될 종류의 것입니다. 에이전트의 범위를 정하고 그 동작을 제어하는 것이 제가 여기서 실제로 해결하고 싶었던 퍼즐입니다.
아키텍처 (Architecture)
Alert -> Strands 에이전트 (Bedrock / Claude 추론 (reasoning))
- 경고 (alert) 분류 및 요약
- 런북 (runbooks) 및 과거 인시던트 (incidents) 검색 (RAG)
...
AWS Strands가 루프 (loop)와 도구 호출 (tool calls)을 실행합니다. Claude가 탑재된 Amazon Bedrock은 1, 3, 4단계에서 추론 (reasoning)을 수행합니다. RAG는 2단계를 근거 (grounding) 있게 만들어 가설이 실제 런북 (runbook)을 인용하도록 합니다. Bedrock AgentCore는 제가 8월에 이를 배포할 곳이며, 이를 통해 프로덕션 (production) 스토리를 제공할 예정입니다.
이미 배운 점
코드를 작성하기 전에 범위를 명시한 덕분에, 일주일 동안 매달렸을 법한 세 가지 기능을 사전에 제거할 수 있었습니다. 빌드 로그 (build log)는 그 가치를 두 배로 증명합니다. 제가 기록하는 모든 결정 사항과 주의 사항 (gotcha)은 매주 올리는 포스트와 최종 Devpost 작성 자료가 됩니다. 콘텐츠는 빌드 과정과 저녁 시간을 두고 경쟁하는 것이 아니라, 빌드 과정 자체에서 나옵니다.
다음 단계
2주 차: Strands 에이전트의 스켈레톤 (skeleton)과 첫 번째 도구 계약 (tool contract). 코드를 공개하겠습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기