Steering
Steering은 워크스페이스의 규칙·관례·기술 선택을 마크다운 파일에 담아 Kiro가 매 세션마다 일관되게 참고하도록 만드는 영구적인 컨텍스트 시스템입니다.
Steering이 해결하는 문제
새 채팅을 시작할 때마다 "우리 팀은 이런 라이브러리를 쓰고, 폴더 구조는 이렇고, 테스트는 이렇게 작성한다"를 반복해서 설명하기는 번거롭습니다. Steering 파일을 두면 Kiro가 해당 규칙을 자동으로 읽어 들여 컴포넌트, API, 테스트 코드가 팀의 패턴에 맞게 생성됩니다.
- 일관된 코드 생성 — 컴포넌트·엔드포인트·테스트가 팀 스타일을 따릅니다.
- 반복 설명 감소 — 한 번 적어두면 모든 대화에서 재사용됩니다.
- 팀 정렬 — 모든 개발자가 동일한 기준 위에서 작업합니다.
- 지식의 누적 — 코드와 함께 문서가 자라납니다.
Steering 파일의 적용 범위
- Workspace Steering — 프로젝트 루트의
.kiro/steering/에 두며 해당 워크스페이스에만 적용됩니다. - Global Steering — 사용자 홈의
~/.kiro/steering/에 두며 모든 워크스페이스에서 공유됩니다. - Team Steering — MDM, 그룹 정책, 사내 저장소 등을 통해
~/.kiro/steering으로 배포해 팀 전체에 동일한 규칙을 강제할 수 있습니다.
기본 제공 Foundation 파일
Steering 패널의 Generate Steering Docs 버튼이나 + → Foundation steering files를 누르면 다음 세 파일이 자동 생성됩니다. 세 파일은 기본적으로 모든 상호작용에 포함됩니다.
product.md— 제품의 목적, 주요 사용자, 핵심 기능, 비즈니스 목표tech.md— 사용 중인 프레임워크·라이브러리·도구·기술적 제약structure.md— 폴더 구성, 명명 규칙, import 순서, 아키텍처 결정
커스텀 Steering 파일 만들기
- 좌측 Steering 패널을 엽니다.
- + 버튼을 클릭합니다.
- 워크스페이스용인지 글로벌용인지 범위를 고릅니다.
api-standards.md처럼 의미가 분명한 파일명을 사용합니다.- 마크다운으로 자연어 규칙을 작성합니다.
- 워크스페이스 파일이라면 Refine 기능으로 다듬을 수 있습니다.
AGENTS.md 지원
Kiro는 AGENTS.md 표준을 인식합니다. 워크스페이스 루트나 ~/.kiro/steering/에 두면 됩니다.
Inclusion Mode
각 파일 최상단의 YAML front matter로 포함 방식을 지정합니다. front matter 앞에는 어떠한 빈 줄이나 다른 내용도 와서는 안 됩니다.
Always (기본값)
---
inclusion: always
---
워크스페이스 전반의 코딩 규칙, 보안 정책, 기술 선택 등 항상 적용해야 하는 내용에 적합합니다.
Conditional (fileMatch)
특정 파일을 다룰 때만 자동으로 끌어옵니다.
---
inclusion: fileMatch
fileMatchPattern: "components/**/*.tsx"
---
여러 패턴을 배열로 지정할 수도 있습니다.
---
inclusion: fileMatch
fileMatchPattern: ["**/*.ts", "**/*.tsx", "**/tsconfig.*.json"]
---
자주 쓰는 패턴: "*.tsx", "app/api/**/*", "**/*.test.*", "src/components/**/*", "*.md".
Manual
---
inclusion: manual
---
채팅에서 #steering-file-name으로 직접 참조하거나 / 슬래시 커맨드로 불러옵니다. 트러블슈팅 가이드처럼 가끔만 필요한 문서에 적합합니다.
Auto
---
inclusion: auto
name: api-design
description: REST API design patterns and conventions. Use when creating or modifying API endpoints.
---
Skills와 비슷한 방식으로 동작하며 Kiro가 사용자의 요청과 description을 매칭해 자동 포함 여부를 판단합니다.
name— 표시 및 매칭에 사용되는 식별자(필수)description— 언제 이 파일을 끌어올지 알려주는 설명(필수)
워크스페이스 파일 참조
Steering 문서 안에서 실제 파일을 살아있는 형태로 인용하려면 다음 문법을 사용합니다.
#[[file:<relative_file_name>]]
예: #[[file:api/openapi.yaml]], #[[file:components/ui/button.tsx]], #[[file:.env.example]].
운영 팁
- 한 파일은 한 주제로 — 도메인을 섞지 않습니다.
- 이름이 곧 설명 —
api-rest-conventions.md,testing-unit-patterns.md처럼 역할이 드러나도록 짓습니다. - 이유를 적습니다 — 결정의 배경을 함께 남기면 추후 변경이 쉬워집니다.
- 예제를 곁들입니다 — 좋은 코드와 나쁜 코드를 비교해 보여주면 효과가 큽니다.
- 비밀은 절대 금지 — API 키·비밀번호·토큰을 Steering 파일에 절대 적지 않습니다.
- 주기적으로 정비 — 스프린트마다 점검하고, 폴더 구조가 바뀌면 파일 참조가 깨지지 않았는지 확인합니다.
자주 만드는 Steering 파일
api-standards.md— REST 규칙, 오류 포맷, 인증 흐름, 버저닝testing-standards.md— 단위·통합 테스트 패턴, 모킹 전략, 커버리지 목표code-conventions.md— 명명 규칙, 파일 배치, import 순서security-policies.md— 인증 요구사항, 입력 검증, 새니타이즈 규칙deployment-workflow.md— 빌드 절차, 환경 설정, CI/CD 세부사항