무엇: 에이전트가 항상 따르는 규칙·컨벤션을 담는 마크다운. 코딩 표준, PR 규칙, 보안 정책, 아키텍처 원칙. 에이전트 프롬프트가 "정체성"이라면 steering은 "우리 팀 규칙"입니다.
언제: 매번 반복 설명하는 규칙을 한 번 고정하고 싶을 때. 파운데이션 3종(product.md·tech.md·structure.md)이 기본 골격입니다.
Inclusion 모드: always(항상) · fileMatch(패턴 일치 파일 작업 시) · manual(#이름으로 호출) · auto(설명 매칭 시 자동). AGENTS.md 표준도 지원(항상 포함).
공유: 워크스페이스는 팀 · Git, 전역은 중앙 · MDM/GPO.
.kiro/steering/api-standards.mdmarkdown
---inclusion: fileMatch
fileMatchPattern: "app/api/**/*"---# API 표준
- 모든 응답은 { data, error } 봉투를 사용한다
- 인증 실패는 401, 권한 부족은 403 으로 구분한다
- 페이지네이션은 cursor 기반을 기본으로 한다
MCP .kiro/settings/mcp.json
무엇: Model Context Protocol. 에이전트에 외부 도구·데이터를 연결합니다. 사내 API, DB, GitHub, Jira, AWS 문서 등. 타입: local(stdio 프로세스) · remote(HTTP+OAuth) · registry(엔터프라이즈 승인 목록).
위치: 워크스페이스 .kiro/settings/mcp.json, 전역 ~/.kiro/settings/mcp.json(둘 다면 워크스페이스 우선 merge), 또는 agent의 mcpServers.
공유: 팀은 팀 · Git, 전사는 중앙 · Enterprise 레지스트리 allow-list. 비밀값은 ${ENV} 참조(하드코딩·커밋 금지).
두 가지 방식: (A) 위처럼 로컬 knowledgeBase(개발자별 인덱스, 클라우드 동기화 없음) · (B)Amazon Bedrock Knowledge Base (S3 Vectors)를 만들어 MCP 서버로 연결. B는 전사가 하나의 중앙 RAG를 공유하고 인덱싱·최신화를 서버에서 관리, 대규모·거버넌스·최신성에 유리합니다. 연결은 탭 참고.
Skills ~/.kiro/skills/<name>/SKILL.md
무엇: 온디맨드로 로딩되는 전문 지침 패키지. steering이 항상 컨텍스트를 차지하는 반면, skill은 메타데이터(name/description)만 상주하다 필요할 때 본문이 로드됩니다. 지침·스크립트·템플릿을 묶은 재사용 단위.
구조: SKILL.md 상단 YAML frontmatter(name, description)가 필수. skill:// 리소스로 참조.
공유: 팀 · Git / 복사. 개인도 자유. (예: 이 가이드를 만든 impeccable 디자인 스킬)
~/.kiro/skills/db-review/SKILL.mdmarkdown
---name: db-review
description: DynamoDB 스키마 설계·리뷰 시 사용하는 사내 지침.---# DynamoDB 리뷰 체크리스트
- 파티션 키 카디널리티와 핫 파티션 위험을 먼저 검토한다 ...
Specs .kiro/specs/<name>/spec-driven
무엇: 스펙 주도 개발. 아이디어를 3단계 문서로 구조화합니다: requirements.md(사용자 스토리·수용 기준) → design.md(아키텍처·시퀀스) → tasks.md(추적 가능한 태스크).
실행: tasks.md는 실시간 상태로 추적되며, "Run all Tasks"는 의존성 그래프를 분석해 독립 태스크를 웨이브 단위로 병렬 실행합니다. Feature Spec(Requirements-First/Design-First/Quick Plan)과 Bugfix Spec을 지원.
공유: 워크스페이스 문서라 팀 · Git, 제품·엔지니어링 협업 산출물로 그대로 리뷰합니다.
.kiro/specs/checkout/tasks.mdmarkdown
## 구현 태스크
- [x] 1. 결제 도메인 모델 정의
- [ ] 2. 장바구니 → 주문 전환 API # wave 2
- [ ] 3. 재고 차감 이벤트 발행 # wave 2
- [ ] 4. 결제 실패 롤백 시나리오
Agent Hooks .kiro/hooks/*.json
무엇: IDE 이벤트에 에이전트 프롬프트나 셸 명령을 자동 실행. 저장 시 린트, 커밋 전 보안 검사, 스펙 태스크 전후 훅 등 팀 프로세스를 표준화합니다.
트리거: SessionStart · UserPromptSubmit · Pre/PostToolUse · Pre/PostTaskExec · PostFileCreate/Save/Delete · Stop. 일부는 실행을 차단(block)할 수 있습니다.
위치·공유: .kiro/hooks/(워크스페이스) 또는 ~/.kiro/hooks/(전역). 팀 · Git
무엇: MCP 서버 + Steering + Hooks를 하나의 번들로 패키징한 재사용 단위. 대화에서 관련 키워드를 언급하면 온디맨드로 활성화되어, 모든 도구를 미리 올려 컨텍스트를 낭비하지 않습니다. 도구 제공사·도메인 전문가의 베스트프랙티스를 캡슐화(예: Amazon Aurora, Miro powers).
왜 중요: 전사·개인 간 공유에서 "낱개 설정"이 아니라 "역량 묶음"을 배포하는 가장 깔끔한 단위입니다. 사내 표준(사내 API MCP + 관련 steering + 검증 hook)을 하나의 Power로 만들어 배포하면 개발자는 키워드만으로 전체 역량을 얻습니다.
공유: 공식 Powers 디렉터리 활용 + 자체 Power 발행. 중앙 발행개인 발행
Powers = MCP + Steering + Hooks 번들. 이 가이드의 및 탭과 함께 보면 "무엇을 어떻게 묶어 배포할지"가 완성됩니다.
원칙 & 실제 유명 사례
좋은 예시로 배우기
각 요소의 핵심 원칙과, 실제로 가장 많이 쓰이는 오픈소스 사례입니다. 사내 하네스를 설계할 때 그대로 참고하세요.
좋은 Skill의 원칙: ① name·description을 명확히("언제 쓰는지"를 description에 담아 자동 활성화 정확도↑) · ② 한 skill = 한 가지 일 · ③ 항상 로드 금지, 온디맨드(핵심은 짧게, 상세는 reference 파일로 progressive disclosure) · ④ 좋은/나쁜 예시와 안티패턴 명시. 대표로 Anthropic frontend-design은 ~30줄 문서로 "최다 설치 디자인 스킬"이 됐고, 이 가이드를 만든 impeccable도 같은 계보입니다.
요소
핵심 원칙
실제 유명 사례
Steering / Rules
한 파일 = 한 주제, 간결하게(매 턴 컨텍스트 소비), 결정의 "이유"까지, 비밀정보 금지
종합 벤치마크 · affaan-m/ECC (github.com/affaan-m/ECC, ★225k): Claude Code · Cursor · Codex · Kiro(.kiro/) 등 여러 하네스용 agents · skills · hooks · rules · mcp를 하나의 저장소로 관리하는 "agent harness OS". 우리가 만들 사내 공유 하네스 repo(중앙 Git pull)의 현실적인 벤치마크입니다.
직접 만들어 테스트 · 실제 Kiro E2E
"유명 사례가 있으니, 우리 것도 이렇게 만든다"
아래는 실제 데모 워크스페이스에 하네스를 만들고 이 컴퓨터의 Kiro IDE로 열어 로드·검증까지 한 화면과 명령 출력입니다. 유명 오픈소스를 그대로 쓸 수도, 같은 패턴으로 사내용을 직접 만들 수도 있습니다.
실제 Kiro IDE — .kiro/(agents·skills·steering·settings) + 우리가 만든 steering + Spec/Vibe실제 Kiro IDE — MCP 설정 편집기(User/Workspace Config) + agent·mcp 파일실제 Kiro IDE — .kiro/에 steering·skills·agents·hooks·specs·settings 전부 생성됨
$ kiro-cli agent list
...
reviewer Workspace 사내 코드 리뷰 에이전트 # ← 방금 만든 로컬 에이전트 발견됨$ kiro-cli agent validate --path .kiro/agents/reviewer.json
# (출력 없음 = 스키마 유효)$ kiro-cli mcp list
📄 workspace:
reviewer # 워크스페이스 하네스 인식
🤖 default:
• aws-docs uvx # settings/mcp.json 로드
결과: 워크스페이스 reviewer 에이전트가 실제로 발견되고(validate 통과), MCP 설정도 로드됨을 확인했습니다. IDE·CLI 어느 쪽에서 만들어도 같은 .kiro/를 공유합니다.
③ 실제 호출 — 에이전트가 하네스를 사용
reviewer 에이전트를 실제 호출하니 스킬 파일을 직접 읽고(tool: read), team-conventions·api-review 규칙을 근거로 리뷰했습니다.
실제 호출 화면 — 에이전트가 SKILL.md를 읽고(tool: read) team-conventions·api-review 근거로 응답
실제 호출 출력 (요약)kiro-cli
$ kiro-cli chat --agent reviewer "이 핸들러를 팀 컨벤션·api-review 기준으로 리뷰" (using tool: read) .kiro/skills/api-review/SKILL.md ✓> 1. 응답 봉투 위반: res.json(rows) → team-conventions·api-review 상
{ data, error } 봉투 필요 → res.json({ data: rows, error: null })
2. 페이지네이션 누락: "cursor 기반" 규칙 → ?cursor= , 응답에 nextCursor
3. 에러 처리 부재: 실패 시 { data: null, error: {...} } (try/catch)
# Credits: 0.31 · Time: 23s → steering + skill 이 실제 로드·사용됨
유명 사례 → 우리 것 매핑 · MCP: Playwright MCP처럼 공개 서버를 그대로 쓰거나, 위 mcp.json처럼 사내 API를 직접 붙인다 · Skill: anthropics/skills를 쓰거나, 위 api-review/SKILL.md처럼 사내 지침을 만든다 · Steering: AGENTS.md 표준을 따르되 사내 규칙은 team-conventions.md처럼 둔다. 유명한 게 있으니 그대로 쓸 수 있고, 없으면 같은 형식으로 자체 제작합니다.
관리자 · 플랫폼/보안팀
중앙에서 강제하고, 전사로 전파하기
개인·팀이 자유롭게 설정하는 위에, 플랫폼팀이 기준선을 강제합니다. 두 축입니다, ① 전파(파일을 개발자 PC로 내려보내기)와 ② 거버넌스(무엇을 허용/차단할지 통제).
인프라팀 초기 설정 가이드, IAM Identity Center & IdP
거버넌스(레지스트리·모델 정책·대시보드)는 IAM Identity Center(IdC) 기반 Kiro Enterprise에서 동작합니다. 미보유라면 인프라팀이 아래 순서로 초기 설정을 진행합니다.
전제: AWS Organizations가 있고 관리 계정 또는 위임 관리자(delegated admin) 계정에 접근할 수 있어야 합니다. IdC는 조직당 하나의 인스턴스를 권장합니다.
IAM Identity Center 활성화
관리(또는 위임 관리자) 계정에서 원하는 리전에 IdC 인스턴스를 활성화합니다. IAM Identity Center > Settings에서 멤버 계정 access를 켜서, 멤버 계정이 조직 IdC 인스턴스를 감지하도록 합니다.
Identity source(IdP) 연결
사용자·그룹의 출처를 정합니다. 아래 3가지 중 하나(추후 변경 가능):
IdC 내장 디렉터리
가장 빠름. IdC에서 사용자·그룹을 직접 생성. 소규모·PoC에 적합.
Okta
SAML 2.0 + SCIM 프로비저닝. 도메인 TXT 레코드로 소유권 검증 후 연결.
Microsoft Entra ID
SAML + SCIM. 기존 Microsoft 365 사용자·그룹을 동기화.
Kiro Enterprise 구독 활성화
대상 멤버 계정에서 Kiro Enterprise 구독을 활성화합니다.
그룹에 구독 티어 할당
Kiro 콘솔 Users & Groups에서 그룹을 선택해 Pro · Pro+ · Pro Max · Power 티어를 부여. 그룹 멤버십 반영에 최대 24시간 소요될 수 있습니다.
거버넌스 프로파일 구성
Kiro Profile에 MCP 레지스트리 allow-list URL과 모델 정책을 설정합니다(아래 거버넌스 섹션). 조직 기본값 위에 계정별 override 가능.
검증
테스트 사용자로 IDE·CLI 로그인 후 티어·MCP 레지스트리·모델 제한 적용을 확인. 이후 대시보드에 활동이 집계됩니다.
크로스 계정(AssumeRole) 구조: 관리 계정에서 IAM Identity Center > Settings의 멤버 계정 access를 켠 뒤, 대상 멤버 계정에 로그인해 그 계정에서 구독을 활성화하세요.
MDM이 뭔가요?: Mobile Device Management. 회사가 직원 PC/노트북을 원격으로 일괄 관리·설정 배포하는 시스템입니다. 대표적으로 Jamf(Mac), Microsoft Intune(Win/Mac), Kandji(Mac), 그리고 Windows의 Group Policy(GPO)가 있습니다. 관리자가 정책·파일을 지정하면 모든 직원 기기에 자동 적용됩니다, 여기서는 ~/.kiro/steering/에 전사 규칙 파일을 자동으로 넣는 용도로 씁니다.
전파 방식
파일을 개발자 PC로 내려보내는 두 갈래
관리자가 정책으로 지정 → 전 직원 기기에 강제·자동 배포. 온보딩·오프보딩과 함께 관리되어 이탈이 없습니다.
kiro-harness repogit · 버전관리 · 리뷰pull동기화 스크립트 / 온보딩$ kiro-harness sync→ ~/.kiro/ 로 복사
한계: 토글·레지스트리는 클라이언트 측에서 강제됩니다. 로컬 관리자 권한이 있는 사용자는 우회할 수 있으므로, MDM 기기 관리·네트워크 정책과 병행하세요.
운영 · 모니터링 · 비용
채택 현황과 라이선스 비용 관리
도입 후에는 사용량 대시보드와 per-user 활동 리포트로 채택을 측정하고 라이선스를 최적화합니다.
사용량 대시보드
Kiro 콘솔에서 구독자의 집계 활동 지표를 확인. 팀별 채택도·활성 사용자·기능 사용을 한눈에.
Console
Per-user 활동 리포트
일일 CSV로 사용자별 활동·크레딧/초과 소비를 제공. 라이선스 할당 최적화·감사에 사용.
Daily CSV
비용 · 빌링
티어별 시트 과금. 한 사용자가 여러 그룹에서 중복 구독돼도 최고 티어 1건만 과금. 미사용 시트는 리포트로 회수.
Billing
개발자 · 팀 리드
팀은 Git으로, 개인은 로컬로
중앙이 기준선을 깔면, 팀과 개인은 그 위에 얹습니다. 핵심은 워크스페이스(.kiro/)를 코드처럼 커밋·리뷰하는 것, 같은 이름이면 워크스페이스가 전역을 덮어씁니다.
전역 ~/.kiro/개인 · 중앙 공통 기준선+ 덮어쓰기 →동명이면 워크스페이스 우선워크스페이스 .kiro/프로젝트 규칙 · git 공유
팀 공유, Git 워크플로우
워크스페이스 .kiro/ 전체를 저장소에 커밋하면 끝. clone하는 모든 팀원이 동일한 steering·specs·hooks·mcp·agents를 얻습니다.
팀 공유 = commitbash
# 프로젝트 하네스를 코드처럼 커밋git add .kiro/
git commit -m "chore: 팀 Kiro 하네스 추가"# 팀원은 clone/pull 하면 자동 적용# 비밀값은 커밋 금지 → mcp.json 은 ${ENV} 참조
워크스페이스 steering·mcp는 코드 리뷰 대상으로 다루고, API 키·토큰 등 비밀값은 절대 커밋하지 마세요(환경변수 참조).
개인 간 공유, 복사 · import · Power
개인 설정(~/.kiro/)이나 유용한 스킬/에이전트를 동료에게 전할 때.
개인 공유 방법들bash
# 1) MCP 설정을 파일로 importkiro-cli mcp import --file team-servers.json --scope workspace
# 2) 스킬/에이전트는 폴더 복사 또는 git
cp -R ~/.kiro/skills/db-review ./.kiro/skills/
# 3) 가장 깔끔: Power 로 묶어 발행 (MCP+steering+hooks)
공유 매트릭스
요소별 · 계층별 공유 방법 한눈에
요소
중앙 (전사)
팀 (프로젝트)
개인
Steering
MDM/GPO push · repo pull
.kiro/steering/ git
~/.kiro/steering/
MCP
Enterprise 레지스트리 allow-list
.kiro/settings/mcp.json git
mcp import · ~/.kiro
Skills
MDM · repo
.kiro/skills/ git
폴더 복사
Agents
repo pull
.kiro/agents/ git
~/.kiro/agents/
Specs
없음
.kiro/specs/ git (핵심)
로컬 초안
Hooks
MDM · repo
.kiro/hooks/ git
~/.kiro/hooks/
Knowledge
원본 repo/S3 · Bedrock KB(S3 Vectors)+MCP
knowledgeBase 리소스 + git 원본
로컬 인덱스
Powers
중앙 Power 발행
팀 Power
개인 Power 발행
Powers로 묶어 배포가 최선: 사내 API MCP + 관련 steering + 검증 hook을 하나의 Power로 발행하면, 낱개 파일을 각자 세팅할 필요 없이 키워드 한 번에 전체 역량이 활성화됩니다. 전사·팀·개인 어느 계층에서든 재사용 단위로 쓰세요.
플랫폼 · 백엔드
사내 API·시스템을 MCP 도구로
사내 REST API, DB, 내부 시스템을 MCP 서버로 감싸면, 모든 개발자의 Kiro가 표준 인터페이스로 그 도구를 호출할 수 있습니다. 한 번 만들어 레지스트리에 올리면 전사가 씁니다.
어떤 방식으로 호스팅할까?, 선택해 보세요
1순위 권장
Amazon Bedrock AgentCore Gateway
기존 API·Lambda를 완전관리형으로 MCP 도구화합니다. 서버 코드를 새로 쓰지 않고, 인증(ingress·egress)을 관리형으로 처리, 가장 빠르고 안전합니다.
사내 자산REST·OpenAPI·LambdaAgentCoreGatewayOpenAPI·Smithy·Lambda→ MCP endpointMCPKiro (전사)🔒 ingress · egress 인증 관리형
타깃 등록
OpenAPI 스펙 / Smithy 모델 / Lambda 함수 / API Gateway를 Gateway 타깃으로 등록.
인증 구성
ingress(클라이언트→Gateway)·egress(Gateway→사내 API) 인증을 관리형으로 설정. Cognito/IdP OAuth 연동.
MCP 엔드포인트를 Kiro에 연결
발급된 MCP URL을 아래처럼 mcp.json에 넣거나, 전사 레지스트리 allow-list에 등록.
대안 A
Lambda + Web Adapter
직접 MCP 서버를 구현해 Streamable HTTP(sessionless)로 Lambda에 배포. 경량·stateless·버스티. Function URL 또는 API Gateway 앞단.
대안 B
ECS / Fargate
상시 연결·세션 상태·무거운 의존성이 필요할 때 컨테이너로 상시 구동. 스케일링·네트워킹 직접 제어.
중앙 RAG도 이 패턴: Amazon Bedrock Knowledge Base (S3 Vectors)를 만들고 그 검색을 MCP 도구로 노출(AgentCore Gateway 또는 Lambda)하면, 전사가 하나의 최신 지식베이스를 Kiro에서 그대로 질의합니다. 로컬 인덱스와 달리 인덱싱·갱신·권한을 서버에서 중앙 관리합니다.
실행 계획
파일럿에서 전사 거버넌스까지
한 번에 전사 강제로 가지 마세요. 작게 검증 → 팀 표준화 → 전사 거버넌스 순으로 신뢰와 자산을 쌓습니다.
PHASE 1 · 2–4주
파일럿, 개인 & 소규모 팀
Kiro(IDE/CLI) 설치, 개인 ~/.kiro에서 steering·skills 실험. 파운데이션 steering(product/tech/structure.md) 작성, 유용한 스킬(예: impeccable) 도입. "무엇이 효과 있는지" 발견.
PHASE 2 · 1–2개월
팀 표준화, Git 공유
.kiro/를 저장소에 커밋해 팀 공유. Specs로 협업, Hooks로 품질 자동화, 팀 mcp.json 표준화. 사내 API 1개를 AgentCore Gateway로 MCP화하고 관련 설정을 Power로 묶기.