AWS Kiro CLI 시리즈 1부로, RDS/Aurora 장애 분석을 IDE 에서 자동화하는 KIDA(Kiro Database Analyzer)를 다룬다. DBA 가 콘솔 7곳을 30분 넘게 수동으로 뒤지던 분석을, Kiro IDE 의 Steering·Hook·MCP 조합으로 버튼 한 번에 데이터 수집부터 근본 원인 도출·HTML 보고서까지 자동화한다.
핵심 포인트- 기존 장애 분석은 RDS 콘솔·CloudWatch·로그·Database Insights·CloudTrail 등 7단계 수동 작업에 평균 30분 넘게 걸렸다.
- KIDA 는 Kiro IDE + Steering 파일 + Hook + MCP 서버 3개로 데이터 수집·해석·보고서를 자동화한다.
- MCP 3종은 aws-mcp(범용 CLI), cloudwatch-mcp(통계 분석), aws-knowledge-mcp(문서 검색)로 역할을 나눈다.
- Steering 파일이 자원 확인→시간 범위→데이터 수집→근본 원인→보고서→검증의 6단계를 정의한다.
- Aurora 는 공유 스토리지라 인스턴스별 메트릭을 개별 수집해야 Reader CPU 스파이크가 평균에 묻히지 않는다.
상세 정리- 문제: 장애 분석이 콘솔 7곳(RDS·CloudWatch·로그·Database Insights·CloudTrail·Health·파라미터 그룹)을 도는 수동 작업이라 데이터 수집에만 평균 30분 이상 걸렸다.
- 한계: 시간대 오류·Writer/Reader 혼동·메트릭 누락 같은 휴먼 에러와, 분석 후 보고서를 처음부터 다시 작성하는 부담이 컸다.
- 근본 원인: 데이터 수집은 자동화 가능해도 수집 데이터의 해석·근본 원인 도출 단계가 비어 있었다.
- 구성: Kiro IDE(VS Code 기반), 행동 가이드인 Steering 파일, userTriggered Hook, 15개 이상 AWS API 를 부르는 MCP 서버 3개로 짜였다.
- MCP 역할: aws-mcp 는 describe-db-clusters·CloudTrail·PI API·SES 호출, cloudwatch-mcp 는 get_metric_data·analyze_metric 으로 트렌드·이상탐지, aws-knowledge-mcp 는 공개 문서 검색을 맡는다.
- 보안: autoApprove 는 aws___call_aws 가 쓰기 API 위험이라 IAM ReadOnlyAccess+aws:ViaAWSMCPService 로 제한하고, 과금되는 Logs Insights 쿼리는 수동 승인으로 남긴다.
- Steering 6단계: 자원 확인(로그 export·slow_query_log 검증), 시간 범위, 데이터 수집, 근본 원인 분석, 보고서 구조, 자체 검증으로 구성된다.
- Aurora 수집 규칙: 공유 스토리지라 CPU·Memory·Connections 는 인스턴스별, VolumeBytesUsed 는 클러스터 레벨로 수집해야 Reader 스파이크가 평균에 묻히지 않는다.
- 보고서: 일일 점검(다크 테마 12섹션)과 장애 분석(라이트 테마 9탭)을 Tailwind 로 생성하고 Critical/Warning/Info 색상 코딩을 쓴다.
- Hook 팁: prompt 에 "생성해줘"라 쓰면 spec 모드로 새 위험이 있어 "분석해줘"·"수행해줘" 동사를 쓴다.
- 실측: Cross Join Full Scan(JOIN 조건 없는 Cartesian Product)이 110,000행을 스캔해 Reader CPU 를 12%에서 61.6%로 411초간 올린 걸 직접 원인으로 짚고, Writer/Reader 파라미터 그룹 불일치도 운영 위험으로 잡았다.
왜 읽나RDS/Aurora 장애 분석을 IDE 안에서 자동화하려는 DBA·플랫폼 엔지니어에게, Steering·Hook·MCP 설계와 실제 슬로우 쿼리 진단 사례 레퍼런스.
AWS Korea Tech·
GitLab Blog·