Kiro IDE 자동화와 확장

자동화 5장치

다섯 장치가 규칙 → 자동화 → 확장 3계층으로 AI를 제어하는 구조

핵심 기능 자동화 파이프라인

규칙 주입에서 외부 도구 연결까지 일관된 흐름

1. 1
   Steering

   • 마크다운 규칙을 AI 컨텍스트에 항상 주입
   • 코딩 표준, 아키텍처 결정, 보안 정책
   • 프로젝트 규칙의 단일 소스
2. 2
   Hooks

   • 이벤트(파일 저장, 도구 호출, 태스크 완료) 시 자동 실행
   • 린트, 테스트, 빌드를 사람 개입 없이 반복
   • JSON으로 선언적 정의
3. 3
   Skills

   • description 매칭으로 필요한 지식만 JIT 로딩
   • 컨텍스트 윈도우 절약하며 전문성 제공
   • 도메인 가이드, API 레퍼런스 관리
4. 4
   MCP

   • 외부 도구를 프로토콜 표준으로 연결
   • AWS, GitHub, Figma 등 API를 에이전트가 직접 호출
   • Powers = MCP + Steering + 문서 패키지
5. 5
   Custom Agents

   • 전문 역할 하위 에이전트 정의
   • 복잡한 작업을 메인 에이전트가 자동 위임
   • 최소 권한 원칙으로 안전한 분업

3계층 제어 구조

규칙 → 자동화 → 확장

Steering

프로젝트 규칙을 AI 컨텍스트에 주입하는 방법 — 적용 시점을 가르는 4가지 모드

Steering 4가지 모드

규칙 적용 시점을 제어하는 방법

Steering 실전 예시

팀의 코드 리뷰 피드백을 규칙으로 코드화

---
inclusion: always
description: 프로젝트 코딩 규칙
---

# 코딩 규칙

## TypeScript
- strict 모드 필수, any 금지
- 함수 반환 타입 명시
- enum 대신 const assertion

## React
- CloudScape 컴포넌트 우선
- CSS Modules 사용 (Tailwind 금지)
- 접근성: aria-label 필수

## 테스트
- 새 기능에 unit test 동반
- mock보다 실제 구현 우선
- describe 블록으로 시나리오 그루핑

Hooks

이벤트가 발생하면 자동으로 실행 — trigger와 action의 조합

Hooks 이벤트와 액션

PostFileSave부터 Stop까지 trigger 10종 — 발생 시점별 활용 예시

Hook JSON 구조 — trigger + action

.kiro/hooks/ 디렉토리에 JSON으로 정의하는 version v1 + hooks 배열 — 저장 시 린트(command)와 타입 에러 점검(agent) 두 예시

{
  "version": "v1",
  "hooks": [
    {
      "name": "lint-on-save",
      "trigger": "PostFileSave",
      "matcher": ".*\\.tsx?$",
      "action": {
        "type": "command",
        "command": "npx eslint --fix ."
      }
    },
    {
      "name": "typecheck-on-save",
      "trigger": "PostFileSave",
      "matcher": "src/.*",
      "action": {
        "type": "agent",
        "prompt": "수정된 파일의 타입 에러를 확인하고 고쳐주세요"
      }
    }
  ]
}

command vs agent

action의 2가지 유형 — 서로 다른 실행 방식

Skills

필요할 때만 로딩되는 지식 — description 매칭 기반 JIT 패턴

Skills 동작 흐름

프롬프트 입력 → description 매칭 → JIT 로딩 → 응답 생성의 4단계

1. 1
   프롬프트 입력

   • 사용자가 질문이나 요청을 입력
   • "DynamoDB 테이블 설계해줘"
   • "Lambda 배포 방법 알려줘"
2. 2
   description 매칭

   • Skills 메타데이터(description)와 프롬프트 매칭
   • "DynamoDB" → dynamodb-guide.md 활성화
   • 매칭 안 되면 로딩하지 않음
3. 3
   JIT 로딩

   • 매칭된 Skills만 컨텍스트에 추가
   • 다른 Skills는 토큰을 소비하지 않음
   • Steering(항상)과의 핵심 차이점
4. 4
   응답 생성

   • Skills 지식을 참조하여 정확한 응답 생성
   • 최신 API, 모범 사례가 자동 적용
   • 할루시네이션 감소

Steering vs Skills

항상 적용 vs 상황별 활성화

Skill 파일 구조

.kiro/skills/*.md — 프론트매터 + 본문

---
name: dynamodb-guide
description: DynamoDB 테이블 설계와 쿼리 최적화 가이드 —
  NoSQL 단일 테이블 설계, 파티션 키 선택, GSI 설계 시 활성화
---
# keywords 필드는 없음 — 매칭 단서는 description에 녹여 쓴다

# DynamoDB 설계 가이드

## 단일 테이블 설계 원칙
- 접근 패턴을 먼저 정의하고, 그에 맞게 키를 설계
- PK(파티션 키) + SK(정렬 키) 조합으로 1:N 관계 표현
- GSI는 최대 20개 — 쿼리 패턴마다 하나씩

## 파티션 키 선택 기준
- 높은 카디널리티 (고유 값이 많을수록 좋음)
- 균등한 접근 분포 (핫 파티션 방지)
- 예: userId, orderId, deviceId

## 비용 최적화
- On-Demand: 트래픽 예측 어려울 때
- Provisioned + Auto Scaling: 안정적 트래픽
- TTL로 불필요한 항목 자동 삭제

MCP

외부 도구를 표준 프로토콜로 연결 — 로컬 stdio와 원격 streamable-http

MCP 2가지 전송 방식

stdio는 로컬 프로세스 실행, streamable-http는 OAuth 원격 연결 — 기준은 도구의 위치

Powers — 원클릭 확장 패키지

MCP + Steering + 문서를 한 번에 설치

Custom Agents

역할·도구·권한을 파일로 정의하는 전문 에이전트 — 최소 권한 분업

Custom Agent 정의 파일

.kiro/agents/*.md로 전문 에이전트 생성

---
description: 보안 취약점을 분석하는 읽기 전용 리뷰어
tools:
  - read
  - web
permissions:
  rules:
    - capability: fs_write
      effect: deny
    - capability: shell
      effect: deny
---

# 보안 리뷰어

## 역할
코드 변경에서 보안 취약점을 식별합니다.

## 지시사항
- OWASP Top 10 기준으로 검증
- 인증/인가 로직에 집중
- 발견 시 심각도(Critical/High/Medium/Low)와 수정 제안 포함
- 코드를 직접 수정하지 않음 (읽기 전용)

에이전트별 역할과 도구

최소 권한 원칙으로 안전한 분업