Part 1: Kiro로 RDS/Aurora 장애 분석 자동화하기 — IDE에서 분석하기

이 글은 “Kiro로 RDS/Aurora 장애 분석 자동화하기” 시리즈의 첫 번째 글입니다.

Part 1 (해당글): “Kiro로 RDS/Aurora 장애 분석 자동화하기 — IDE에서 분석하기”
Part 2: “Kiro로 RDS/Aurora 장애 분석 자동화하기 — 터미널에서 분석하기”
Part 3: “Kiro로 RDS/Aurora 장애 분석 자동화하기 — 매일 자동으로 보고서 받기”

이 시리즈에서는 Kiro와 MCP(Model Context Protocol) 서버를 활용하여, 버튼 하나로 Amazon RDS/Amazon Aurora 장애 원인 분석부터 HTML 보고서 생성까지 자동화하는 방법을 단계별로 다룹니다. 이 글에서는 편의상 이 자동화 솔루션을 KIDA(Kiro Database Analyzer)라고 부르겠습니다. KIDA는 AWS 공식 솔루션이나 오픈소스 프로젝트가 아니며, Kiro IDE + Steering + Hook + MCP 서버를 조합해 구성한 활용 예시입니다.

Kiro IDE는 AWS가 제공하는 AI 기반 개발 환경으로, VS Code 기반의 친숙한 UI에 Agent, Spec, Hook, MCP 서버 통합 기능을 제공합니다. Steering 파일로 AI 에이전트의 행동 가이드를 정의하고, Hook으로 자주 쓰는 작업을 버튼 하나로 실행할 수 있어 DBA의 반복적인 장애 분석 작업을 자동화하기에 적합합니다. 자세한 내용과 다운로드는 Kiro 공식 사이트에서 확인할 수 있습니다.

배경: 왜 RDS 장애 분석은 이렇게 고된가?

데이터베이스 관리자(DBA)에게 장애 원인 분석은 가장 중요하면서도 시간이 많이 소요되는 업무입니다. Amazon CloudWatch 메트릭 확인, 로그 분석, Amazon CloudWatch Database Insights 조회, AWS Personal Health Dashboard 확인 등 여러 서비스를 개별적으로 확인해야합니다. 다음 문단에서 실제 DBA가 장애 원인 분석을 진행하는 과정을 간략하게 살펴보겠습니다.

DBA의 장애 분석 업무 현실

새벽 시간대, 운영팀에서 “RDS Aurora 응답 지연” 알람 메시지가 도착하면, 담당 DBA가 랩탑을 열고 시작하는 작업은 대략 이런 순서입니다.

1. AWS Console의 RDS 대시보드 로그인 → 해당 클러스터 선택 → Writer / Reader 구성 확인
2. Amazon CloudWatch Metrics 콘솔로 이동 → CPU, Memory, Connections, IOPS 지표를 인스턴스별로 하나씩 확인
3. RDS 대시보드의 logs 탭으로 이동 → error 로그, slowquery 로그를 서로 다른 로그 그룹에서 각각 체크
4. Database Insights 콘솔로 이동 → Wait Event, Top SQL 확인
5. AWS CloudTrail 이벤트 기록 확인 → 해당 시간대 API 호출 이력 조회
6. AWS Personal Health Dashboard 확인 → AWS 측 이벤트 유무 확인
7. 파라미터 그룹 비교, Pending Maintenance 확인 등 추가 항목

각 단계마다 콘솔을 오가며 시간대를 일일이 맞추고, 스크린샷을 찍어 임시 문서에 붙여넣고, 메모장에 메트릭 수치를 옮겨 적습니다. 단일 장애 분석 데이터 수집에만 평균 30분 이상이 소요되는 것은 흔한 일이며, 이 과정에는 몇 가지 뚜렷한 한계가 있습니다.

기존 방식의 한계

• 시간 소요: 여러 콘솔을 오가며 수동으로 지표를 확인하는 데 상당한 시간이 소요됩니다. 장애 발생 직후처럼 촌각을 다투는 상황에서 이 시간은 곧 서비스 영향 시간으로 이어질 수 있습니다.
• 휴먼 에러: 시간대를 잘못 지정하거나, Writer 대신 Reader 인스턴스를 조회하거나, 중요한 메트릭을 누락하는 실수가 생기기 쉽습니다. Aurora처럼 공유 스토리지 기반 아키텍처에서는 인스턴스별(Writer vs Reader) 지표 비교가 필수인데, 바쁜 상황에서 이를 놓치기 쉽습니다.
• 보고서 작성 부담: 분석이 끝나면 다시 처음부터 결과를 정리하여 Markdown, HTML, 또는 슬라이드 형태의 보고서를 작성해야 합니다. 사내 공유용, 고객 공유용, AWS Support 케이스용으로 각각 포맷이 다를 수도 있습니다.
• 지식 재사용의 어려움: 분석 노하우가 개인의 암묵지로 남아 팀에 공유되지 않으면, 비슷한 장애가 재발했을 때 같은 시행착오를 반복하게 됩니다.

“이걸 자동화할 수 없을까?”

자연스럽게 떠오르는 질문입니다. “콘솔을 돌아다니며 하는 작업을 스크립트화하면 되지 않을까?” 하지만 기존의 Bash 스크립트나 Python boto3 자동화에는 또 다른 한계가 있습니다. 수집한 데이터를 해석하고 근본 원인을 찾는 단계가 빠져있기 때문입니다. 숫자만 모아봐도, 그 숫자가 무엇을 의미하는지 해석하는 것은 결국 사람의 몫이었습니다.

Kiro IDE와 MCP 서버의 등장은 이 마지막 퍼즐 조각을 채워줍니다. AWS API 호출로 데이터를 수집하는 것은 MCP 서버가 담당하고, 수집된 데이터를 해석하여 근본 원인을 짚어내고 권장 조치까지 제시하는 것은 Kiro의 AI Agent가 담당합니다. DBA는 버튼 하나만 누른 뒤, AI가 정리해준 분석 결과를 검토하고 최종 의사결정에 집중할 수 있습니다.

솔루션 개요

Kiro + MCP 기반 자동 분석

Kiro IDE는 MCP 서버를 통해 AWS 리소스에 직접 접근하여 분석을 수행합니다. 핵심 구성 요소는 다음과 같습니다.

• Steering 파일: 분석 가이드(Context)를 .kiro/steering/ 디렉토리에 저장하면 자동 또는 수동으로 적용됩니다.
• MCP 서버: AWS API, CloudWatch, Knowledge Base 등 다양한 MCP 서버를 통해 15개 이상의 AWS API를 자동 호출합니다.
• Hook 자동화: userTriggered 이벤트를 사용하여 버튼 하나로 전체 분석 파이프라인을 실행합니다.
• HTML 보고서: Tailwind CSS 기반의 시각적 보고서를 자동 생성하고, 브라우저에서 바로 열어줍니다.

아키텍처

위 아키텍처의 데이터 흐름은 다음과 같습니다.

1. 사용자가 Hook 버튼을 클릭하면 Hook에 정의된 prompt가 Kiro AI Agent에 전달됩니다.
2. Steering 파일이 Agent에 컨텍스트를 제공합니다. 어떤 MCP 도구를 사용할지, 어떤 메트릭을 인스턴스별로 수집할지, 보고서 구조는 어떻게 할지 등의 가이드라인이 포함됩니다.
3. Kiro AI Agent가 3개의 MCP 서버를 통해 AWS 리소스에 접근하며, 자세한 역할은 Step 2 참고
4. Agent가 수집한 데이터를 분석하고, Steering에 정의된 REPORT STRUCTURE에 따라 Tailwind CSS 기반 HTML 보고서를 생성합니다.
5. 보고서 파일을 저장하고, open 명령으로 브라우저에서 열도록 요청합니다.

사전 준비

Step 1: Kiro IDE 설치

kiro.dev/downloads에서 다운로드하여 설치합니다.

Step 2: MCP 서버 구성

.kiro/settings/mcp.json 파일을 직접 편집하거나 MCP Server 패널에서 UI로 관리합니다.

{
  "mcpServers": {
    "aws-mcp": {
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://aws-mcp.us-east-1.api.aws/mcp",
        "--metadata", "AWS_REGION=us-east-1"
      ],
      "disabled": false,
      "autoApprove": [
        "aws___call_aws",
        "aws___search_documentation",
        "aws___read_documentation"
      ]
    },
    "cloudwatch-mcp": {
      "command": "uvx",
      "args": ["awslabs.cloudwatch-mcp-server@latest"],
      "env": {
        "AWS_REGION": "us-east-1",
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": [
        "get_metric_data",
        "get_metric_metadata",
        "analyze_metric",
        "get_active_alarms",
        "get_alarm_history",
        "get_recommended_metric_alarms",
        "describe_log_groups",
        "analyze_log_group",
        "execute_log_insights_query",
        "get_logs_insight_query_results"
      ]
    },
    "aws-knowledge-mcp-server": {
      "command": "uvx",
      "args": ["fastmcp", "run", "https://knowledge-mcp.global.api.aws"],
      "disabled": false,
      "autoApprove": ["*"]
    }
  }
}

위 설정에서 3개의 MCP 서버는 각각 다른 역할을 담당합니다.

aws-mcp는 AWS CLI 명령을 실행하는 범용 MCP 서버입니다. aws rds describe-db-clusters, aws cloudtrail lookup-events 등 RDS API, CloudTrail, Database Insights (PI API), SES 이메일 발송 등에 사용됩니다.

cloudwatch-mcp는 CloudWatch 전용 분석 MCP 서버입니다. 단순 메트릭 조회(get_metric_data)뿐 아니라 트렌드/시즌성 자동 분석(analyze_metric), 알람 임계값 추천(get_recommended_metric_alarms), 로그 이상 탐지(analyze_log_group)까지 제공합니다. aws-mcp의 aws cloudwatch get-metric-statistics로는 원시 데이터만 가져올 수 있지만, cloudwatch-mcp의 analyze_metric은 통계 분석까지 자동으로 수행합니다.

aws-knowledge-mcp-server는 AWS 공식 문서를 검색하는 MCP 서버입니다. 근본 원인 조사 시 “Aurora MySQL CPU 스파이크 원인”과 같은 질문으로 관련 트러블슈팅 문서를 찾을 수 있습니다.

autoApprove에 등록된 도구들은 실행 시 매번 승인을 요청하지 않고 자동으로 진행됩니다. 도구별로 위험도가 다르므로 분석 자동화 용도로 사용할 때는 다음 세 가지 포인트를 이해하고 쓰는 것을 권장합니다.

1.aws-mcp의 aws___call_aws는 쓰기 작업도 수행 가능

aws___call_aws는 AWS CLI 전체 명령을 실행할 수 있으므로 describe-, list- 같은 조회 명령뿐 아니라 create-, modify-, delete- 같은 쓰기 작업도 수행할 수 있습니다. 실제로 관리형 AWS MCP Server(mcp-proxy-for-aws)를 사용할 때 aws sns create-topic 같은 쓰기 API도 IAM 권한이 있으면 그대로 성공합니다. 장애 분석 용도라면 읽기 전용으로 제한하는 것이 안전하며, 세 가지 통제 방법이 있습니다.

• IAM 정책으로 통제: AWS CLI가 사용하는 프로필을 ReadOnlyAccess 관리형 정책이 부여된 IAM 역할로 설정하면 쓰기 API 호출이 IAM 레벨에서 차단됩니다. MCP 경유 호출에만 별도 제약을 걸고 싶다면 aws:ViaAWSMCPService 컨텍스트 키를 IAM 정책에 활용할 수 있습니다.
• autoApprove 명시적 축소: aws___call_aws를 autoApprove에서 제외하고 매 호출마다 승인받는 방식도 가능합니다. 속도는 느려지지만 LLM이 쓰기 명령을 시도할 때 사용자가 직접 거부할 수 있습니다.

2. cloudwatch-mcp의 Logs Insights 쿼리 실행은 과금에 주의

cloudwatch-mcp의 대부분의 도구는 조회/분석 전용이므로 autoApprove에 넣어도 안전합니다. 이 중 analyze_metric은 GetMetricData로 수집한 시계열을 MCP 서버 내부에서 통계 분석(트렌드, 시즌성)하는 클라이언트 사이드 분석 도구로, AWS 쪽에 상태 변경을 일으키지 않습니다.

다만 execute_log_insights_query는 CloudWatch Logs Insights 쿼리를 실행하는 도구로 내부적으로 logs:StartQuery API를 호출하며, 쿼리가 스캔한 데이터 양에 따라 CloudWatch Logs Insights 요금이 청구됩니다. 자동 승인 대상에 포함하면 LLM이 실수로 무거운 쿼리를 반복 실행할 때 비용이 누적될 수 있으므로, autoApprove에서 제외하고 필요할 때 수동으로 승인하는 것을 권장합니다.

3.aws-knowledge-mcp-server는 자격증명이 필요 없는 공개 문서 서비스

aws-knowledge-mcp-server는 AWS 공식 문서, What’s New, Well-Architected 가이드 등을 검색/조회하는 도구만 제공하며, 사용자 AWS 자격증명 없이 동작하는 공개 서비스입니다(엔드포인트: https://knowledge-mcp.global.api.aws). 아무런 상태 변경도 일으킬 수 없으므로 autoApprove로 설정 해도 안전합니다.

Step 3: Steering 파일 구성

프로젝트 루트의 .kiro/steering/ 디렉토리에 파일을 생성합니다. inclusion: manual로 설정하면 채팅에서 # 키로 필요할 때만 적용할 수 있습니다. 아래의 컨텍스트는 분석에 필요한 메트릭을 수집하고 분석하는 예제입니다. 각 환경의 필요에 맞게 추가하거나 수정하여 사용할 수 있습니다.

rds-troubleshoot.md:

---
inclusion: manual
---

### Persona
You are a top-tier AWS Database expert. Your core competency goes beyond 
merely listing metrics; it involves finding tangible clues within the data 
and presenting immediately actionable solutions.

### MCP Tool Usage Guide
- Use **cloudwatch-mcp** tools for metrics and logs:
  get_metric_data, analyze_metric, get_recommended_metric_alarms,
  get_active_alarms, get_alarm_history, describe_log_groups,
  analyze_log_group, execute_log_insights_query
- Use **aws-mcp** (call_aws) for RDS API, CloudTrail, Database Insights (PI API), SES
- Use **aws-knowledge-mcp-server** for AWS documentation search

### Analysis PHASE

#### PHASE 1: Resource Verification
- Run describe-db-clusters (via aws-mcp) to get cluster info and member list
- Identify all instances: Writer(s) and Reader(s) with their DBInstanceIdentifier
- Classify the query type (performance issue / incident / general guide)
- Check EnabledCloudwatchLogsExports to verify which logs are exported (error, slowquery, audit)
- If slowquery log is exported, check cluster parameter group for slow_query_log and long_query_time values
- If logs are NOT exported, note this as a finding and recommend enabling log exports

#### PHASE 2: Time Range Setup
- Use the region's timezone if not specified in the prompt

#### PHASE 3: Data Collection

**CRITICAL: Aurora Metric Collection Rules**
- Aurora uses shared storage. Some metrics are cluster-level only, others are instance-level only.
- For clusters with multiple instances, you MUST collect instance-level metrics for EACH instance separately.

**CloudWatch MCP tools (cloudwatch-mcp):**
- get_metric_data: Per-instance CPUUtilization, FreeableMemory, DatabaseConnections, ReadIOPS, WriteIOPS, SwapUsage, BufferCacheHitRatio, Deadlocks
- get_metric_data: Reader only — AuroraReplicaLag
- get_metric_data: Cluster level — VolumeBytesUsed
- analyze_metric: Per-instance CPUUtilization trend/seasonality/statistics
- get_recommended_metric_alarms: CPUUtilization alarm recommendations
- get_active_alarms: Currently active alarms in the account
- describe_log_groups + analyze_log_group: Log anomaly detection
- execute_log_insights_query: Error pattern analysis

**AWS API MCP tools (aws-mcp call_aws):**
- aws rds describe-events: Cluster and instance events
- aws cloudtrail lookup-events: API call history
- aws pi get-resource-metrics: Database Insights (if Advanced mode enabled)
- aws rds describe-db-recommendations: RDS recommendations
- aws rds describe-pending-maintenance-actions: Pending maintenance
- aws health describe-events: Health Dashboard

#### PHASE 4: Root Cause Analysis
- Use aws-knowledge-mcp-server for investigation
- If a recommendation includes 'check', execute it yourself
- Compare Writer vs Reader metrics when multiple instances exist

#### PHASE 5: Report Structure

Generate a single self-contained HTML report using Tailwind CSS CDN. Report layout depends on the query type classified in PHASE 1.

**Common format:**
- File naming: kida-daily-report-{YYYYMMDD}.html (daily) or kida-issue-analysis-{YYYYMMDD}.html (issue)
- Severity colors: Critical=red-500, Warning=yellow-500, Info=blue-500, OK=green-500
- Report body text in Korean; section headings, variable/code names, and CLI references in English
- HTML will be 350-500 lines. Use fsWrite for skeleton, then fsAppend for remaining sections
- After writing, run `open <filename>` to launch browser

**A. Daily Check Report — Dark theme, 12 sections, vertical scroll:**
1. Executive Summary — 4 KPI numbers + key findings bullets
2. Cluster Config — 8-field grid + EnabledCloudwatchLogsExports + slow_query_log/long_query_time
3. Instance Metrics (24h) — Per Writer/Reader (Current/Avg/Max/Status/Trend): CPU, FreeableMemory, DBConnections, ReadIOPS, WriteIOPS, BufferCacheHitRatio, SwapUsage, Deadlocks + Reader-only AuroraReplicaLag
4. CPU Trend Analysis (14-day) — analyze_metric output: Trend, Seasonality, Min/Median/Max, StdDev, CV, DataPoints
5. Database Insights Summary — pi get-resource-metrics: Top 5 Wait Events + Top 3 SQL
6. Alarm Recommendations — get_recommended_metric_alarms + get_active_alarms + get_alarm_history
7. Events (Last 24h) — describe-events + cloudtrail lookup-events (merged chronological timeline)
8. Pending Maintenance Actions — describe-pending-maintenance-actions
9. AWS Personal Health Dashboard — aws health describe-events (single-line status)
10. Log Analysis — analyze_log_group (error log) + execute_log_insights_query (slow query)
11. Cluster Volume — VolumeBytesUsed with progress bar
12. Recommendations — prioritized action cards (P1 Critical → P4 Info)
- Theme: bg=#0f172a, card=#1e293b, border=#334155

**B. Issue Analysis Report — Light theme, 9 tabs in left sidebar:**
1. Overview — summary cards + 9-item checklist + Critical/Warning/Info cards
2. Cluster Info — describe-db-clusters, instance list, parameter groups, EnabledCloudwatchLogsExports
3. CloudWatch Metrics — per-instance time-series tables (same columns as A§3) + VolumeBytesUsed + analyze_metric
4. Database Insights — DB Load, Top Wait Events, Top SQL (show warning if Database Insights disabled)
5. CloudWatch Logs — analyze_log_group + execute_log_insights_query
6. RDS Events & CloudTrail — describe-events + cloudtrail lookup-events
7. Alarms & Health — get_active_alarms + get_alarm_history + aws health describe-events
8. Recommendations — describe-db-recommendations + describe-pending-maintenance-actions
9. Root Cause & Action — 3-paragraph RCA + prioritized actions (Priority/Action/Owner/Timeline)

#### PHASE 6: Verification
- Verify all 9 tabs are present in the HTML report
- Verify per-instance time-series data is shown (not just summary)
- Verify instance-level metrics were collected per instance, not just cluster-level
- Verify CloudWatch MCP analyze_metric was used
- Verify the report opens correctly in browser

위 Steering 파일의 각 섹션을 설명합니다.

inclusion: manual은 이 Steering 파일이 Kiro IDE 채팅에서 # 키로 필요할 때만 적용된다는 의미입니다. auto로 변경하면 모든 대화에 자동 적용됩니다.

Persona 섹션은 Kiro AI Agent의 역할을 정의합니다. 단순히 메트릭을 나열하는 것이 아니라, 데이터에서 실질적인 단서를 찾아 즉시 실행 가능한 솔루션을 제시하도록 지시합니다.

MCP Tool Usage Guide는 어떤 MCP 서버의 어떤 도구를 사용할지 명시합니다. CloudWatch 관련 작업은 cloudwatch-mcp의 전용 도구를, RDS API나 CloudTrail은 aws-mcp를 사용하도록 구분합니다.

PHASE 1의 로그 내보내기 검증이 중요합니다. describe-db-clusters의 응답에 포함된 EnabledCloudwatchLogsExports 필드를 확인하여 error, slowquery, audit 로그가 CloudWatch로 내보내지고 있는지 검증합니다. 내보내기가 비활성화되어 있으면 CloudWatch MCP의 analyze_log_group이 동작하지 않으므로, 이를 발견사항으로 기록하고 로그 내보내기 활성화를 권장합니다. 또한 슬로우 쿼리 로그가 활성화되어 있더라도 파라미터 그룹에서 slow_query_log = 1과 long_query_time 값이 적절히 설정되어 있는지도 확인합니다.

PHASE 3의 Aurora Metric Collection Rules가 핵심입니다. Aurora는 공유 스토리지를 사용하므로 CPU, Memory, Connections 같은 메트릭은 인스턴스별로(DBInstanceIdentifier 기준) 개별 수집해야 하고, VolumeBytesUsed 같은 스토리지 메트릭은 클러스터 레벨로(DBClusterIdentifier 기준) 수집해야 합니다. Writer + Reader가 있는 클러스터에서 클러스터 레벨로만 수집하면 Writer의 CPU 스파이크가 Reader 평균에 묻혀서 보이지 않을 수 있습니다.

PHASE 5의 REPORT STRUCTURE는 HTML 보고서의 필수 구조를 용도별로 정의합니다. PHASE 1에서 분류된 쿼리 타입에 따라 두 가지 레이아웃으로 나뉩니다. Daily Check 리포트(일일 점검용)는 다크 테마에 12개 섹션을 세로 스크롤 단일 페이지로 배치하여 매일 아침 3분 안에 훑어볼 수 있도록 구성합니다. Issue Analysis 리포트(장애 분석용)는 라이트 테마에 좌측 사이드바 9탭 구조로, Overview 탭의 9항목 체크리스트와 Root Cause & Action 탭의 우선순위 액션까지 깊이 있는 분석을 담습니다. 두 리포트 모두 HTML이 300줄 이상이 되므로, fsWrite로 한번에 쓰지 않고 fsWrite로 skeleton을 만든 뒤 fsAppend로 각 섹션/탭을 이어 붙이도록 지시합니다. Critical=red, Warning=yellow, Info=blue, OK=green의 심각도 색상 코딩은 두 리포트에 공통 적용됩니다.

PHASE 6의 Verification은 보고서 생성 후 필수 항목이 누락되지 않았는지 자체 검증하는 단계입니다.

Step 4: Hook 버튼 설정

일일 점검 보고서 Hook (.kiro/hooks/rds-daily-report.kiro.hook)

{
  "name": "RDS 일일 점검 보고서",
  "version": "4.0.0",
  "description": "CloudWatch MCP 전용 분석 도구를 활용한 일일 점검 HTML 보고서 생성",
  "when": { "type": "userTriggered" },
  "then": {
    "type": "askAgent",
    "prompt": "RDS 일일 점검을 수행해줘. 먼저 주요 리전에서 모든 RDS/Aurora 리소스를 조회하고 번호를 매겨서 보여줘. 사용자가 선택하면 cloudwatch-mcp와 aws-mcp를 사용하여 인스턴스별로 분석하고, .kiro/steering/rds-troubleshoot.md의 REPORT STRUCTURE를 따라 HTML 보고서를 저장한 후 브라우저에서 열어줘."
  }
}

이슈 원인 분석 Hook (.kiro/hooks/rds-issue-analysis.kiro.hook):

{
  "name": "RDS 이슈 원인 분석",
  "version": "4.0.0",
  "description": "CloudWatch MCP 전용 분석 도구를 활용한 이슈 원인 분석 HTML 보고서 생성",
  "when": { "type": "userTriggered" },
  "then": {
    "type": "askAgent",
    "prompt": "RDS 이슈 원인 분석을 수행해줘. 먼저 주요 리전에서 모든 RDS/Aurora 리소스를 조회하고 번호를 매겨서 보여줘. 사용자가 선택하면 시간대를 물어보고, cloudwatch-mcp와 aws-mcp를 사용하여 인스턴스별로 분석하고, .kiro/steering/rds-troubleshoot.md의 REPORT STRUCTURE를 따라 근본 원인 + 권장 조치를 포함한 HTML 보고서를 저장한 후 브라우저에서 열어줘."
  }
}

팁: Hook prompt에서 spec 모드 회피하기 Hook의 prompt에 “보고서를 생성해줘”와 같은 표현을 사용하면 Kiro가 “새 기능 개발 요청”으로 해석하여 spec 모드로 진입할 수 있습니다. “생성해줘” 대신 “수행해줘”, “분석해줘”와 같은 동사를 사용하면 Kiro가 즉시 실행 모드로 동작합니다.

Hook 버튼을 누르면 다음과 같은 인터랙티브 플로우가 실행됩니다.

1. Agent Hooks 패널에서 Hook 선택 후, Start Hook 클릭, 아래 이미지는 RDS 일일 점검 보고서 기준입니다.

2. Kiro가 주요 리전에서 describe-db-clusters + describe-db-instances 실행

3. 클러스터 리스트가 표시되면 클러스터를 선택하여 데이터를 수집

4. HTML 보고서 파일이 생성되며 open 명령에 의해 브라우저에서 보고서를 확인

참고: 해당 보고서의 형식은 사용자 마다 다를 수 있습니다.

KIDA가 생성한 Executive Summary탭은 클러스터 1개·인스턴스 2개·보류 중인 유지보수 2건·주의 이벤트 1건과 함께 Failover/Slow Query 411초/OS 패치 보류 등 핵심 발견사항을 자동 요약합니다. 아래 Instance Metrics 테이블은 Writer는 안정적이지만 Reader CPU에서 평균 14.5% 대비 최댓값 61.6% 스파이크가 감지됐음을 즉시 보여줍니다.

해당 이미지에서는 14일치 CPU 데이터를 통계 분석해 Writer는 안정적(CV 0.22), Reader는 Positive (Increasing) 추세(CV 0.67)로 자동 판정하고, 현재 알람이 없는 상태에서 CPUUtilization > 90% for 5 minutes 알람을 권고합니다

** 공개된 Steering 파일과 Hook 설정은 예시이며, 실운영 환경에 맞게 수정이 필요할 수 있습니다.

실제 테스트-시나리오 : 슬로우 쿼리에 의한 Reader CPU 스파이크 분석

실제 Aurora MySQL 클러스터(kida-test, us-east-1)를 대상으로 테스트했습니다. 의도적으로 슬로우 쿼리를 실행하여 부하를 발생시킨 후, KIDA가 이를 자동으로 감지하고 근본 원인을 분석하는 과정을 보여줍니다.

테스트 환경

Reader 인스턴스에서 JOIN 조건 없는 Cross Join 쿼리와 SELECT SLEEP() 테스트 쿼리를 실행하여 CPU 스파이크를 발생시켰습니다. KIDA의 “RDS 이슈 원인 분석” Hook 버튼을 클릭하고, kida-test 클러스터를 선택한 후 “최근 1시간”을 분석 시간대로 지정했습니다.

Kiro가 수집한 CloudWatch 메트릭 (Reader: kida-test-reader-us-east-1a):

Kiro가 수집한 Slow Query Log (12건):

Writer 인스턴스 동시 관찰 (kida-test-instance-1-us-east-1d):

Kiro의 원인 분석 결과:

• Cross Join Full Scan (CRITICAL): products × orders 테이블을 JOIN 조건 없이 Cartesian Product로 조회하여 110,000행을 스캔. 411초 동안 Reader CPU를 12% → 61.6%로 급등시킨 직접 원인
• SLEEP 테스트 쿼리 (WARNING): SELECT SLEEP(11~25) 10건이 동시 실행되어 커넥션 수가 3 → 11로 급증. CPU 영향은 미미하나 커넥션 풀 고갈 위험
• 파라미터 그룹 불일치 (OPERATIONAL RISK): Writer(pitest)와 Reader(default.aurora-mysql8.0)가 서로 다른 파라미터 그룹 사용 중. RDS Recommendations에서 활성 권고사항으로 감지됨

Kiro의 권장 조치:

• Cross Join 쿼리에 적절한 JOIN 조건 추가 (즉시)
• Writer/Reader 파라미터 그룹 통일 (이번 주)
• CPUUtilization > 90% CloudWatch 알람 설정 (이번 주)

해당 분석에 대한 이슈 보고서

Executive Summary 부분에서는 Reader CPU 스파이크가 Slow Query 발생 시각과 어떻게 연결되는지를 요약해줍니다.. 하단 차트는 Writer CPU(안정), Reader CPU(SPIKE Badge), Writer WriteIOPS(BURST Badge)를 시각화하여 어느 인스턴스의 어느 시점에서 무엇이 발생했는지를 한눈에 보여줍니다.

Steering 파일 작성 팁

1. 영어로 작성: LLM의 인식률이 더 높습니다. 한국어로 초안을 작성한 후 번역하는 것을 추천합니다.
2. Markdown 형식 사용: 구조화된 형식이 누락 방지에 효과적입니다.
3. PHASE 단계 구분: 분석 과정을 단계별로 명확히 기술하면 Kiro가 체계적으로 분석합니다.
4. 검증 단계 포함: 마지막에 필수 항목 누락 여부를 확인하는 단계를 추가합니다.
5. inclusion 설정 활용: auto(일일 점검용)와 manual(장애 분석용)을 용도에 맞게 선택합니다.

정리

이 글에서는 Kiro IDE의 Steering 파일로 분석 가이드를 정의하고, 3개의 MCP 서버(AWS API, CloudWatch, AWS Knowledge)로 15개 이상의 AWS API를 자동 호출하며, Hook 버튼 하나로 클러스터 선택부터 HTML 보고서 생성까지 전체 파이프라인을 실행하는 방법을 다뤘습니다. 실제 Aurora MySQL 클러스터에서 슬로우 쿼리로 Reader CPU 스파이크를 발생시키고, KIDA가 Cross Join Full Scan을 근본 원인으로 자동 식별하는 과정도 확인했습니다.

Kiro IDE를 설치하고, 이 글의 MCP 서버 설정, Steering 파일, Hook 설정을 적용하면 바로 KIDA를 사용할 수 있습니다. RDS/Aurora 장애 분석 시간을 줄이고 싶다면 지금 시작해 보세요. Kiro에 대한 자세한 내용은 Kiro 공식 사이트에서 확인할 수 있습니다.

다음 글에서는 Kiro CLI를 사용하여 터미널에서 동일한 분석을 수행하는 방법과, Replication Lag 분석 시나리오를 다룹니다.