전사 Kiro 하네스 steering · mcp · skills · knowledge
enterprise harness · IDE + CLI

전사 Kiro 하네스,
하나의 표준으로.

Steering · MCP · Skills · Knowledge를 전사 표준으로 세팅하고, 중앙 · 팀 · 개인 3계층으로 공유하는 생태계. 모든 개발자가 같은 규칙과 도구 위에서 일합니다.

하네스란?

하네스 = AI에게 주는 규칙 · 도구 · 지식

Kiro의 하네스(harness)는 AI 에이전트가 우리 회사 방식대로 일하도록 잡아주는 설정의 총칭입니다. IDE와 CLI가 동일한 파일 구조(~/.kiro/, .kiro/)를 공유하므로, 한 번 정의하면 양쪽에서 그대로 동작합니다.

Steering .kiro/steering/*.md

에이전트가 항상 따르는 규칙·컨벤션. 코딩 표준, PR 규칙, 보안 정책.

규칙

MCP .kiro/settings/mcp.json

외부 도구·시스템 연결. 사내 API, DB, GitHub, Jira 등을 도구로 노출.

도구

Skills ~/.kiro/skills/**/SKILL.md

온디맨드로 로딩되는 전문 지침 패키지. 필요할 때만 컨텍스트에 올라옴.

지침

Knowledge (RAG) knowledgeBase resource

사내 문서를 시맨틱/키워드로 검색. 에이전트별 격리된 로컬 인덱스.

검색
워크플로우 · 자동화 · 패키징

Specs .kiro/specs/<name>/

요구사항 → 설계 → 태스크 3단계 스펙 주도 개발. 태스크 병렬 실행·추적.

워크플로우

Agent Hooks .kiro/hooks/*.json

파일 저장·툴 호출·태스크 실행 등 이벤트에 에이전트/명령을 자동 실행.

자동화

Powers kiro.dev/powers · 자체 발행

MCP + Steering + Hooks를 하나의 번들로 패키징해 키워드로 온디맨드 활성화. 공유의 핵심 단위.

패키징
3계층 공유 모델

계층을 클릭해 무엇이 어디에 사는지 확인하세요

모든 하네스 설정은 중앙(전사 강제), 팀(프로젝트 공유), 개인(로컬) 세 계층 중 하나에 놓입니다. 우선순위는 워크스페이스가 전역을 덮어씁니다.

파일 구조

IDE와 CLI가 공유하는 단 하나의 구조

~/.kiro/ (전역 · 개인 & 중앙 전파 대상)tree
~/.kiro/
├── steering/        # 전역 규칙 (MDM/GPO로 전파)
│   └── *.md
├── agents/          # 전역 에이전트
│   └── *.json
├── skills/          # 전역 스킬
│   └── /SKILL.md
└── settings/
    └── mcp.json     # 전역 MCP 서버
.kiro/ (워크스페이스 · 팀 공유 · Git 커밋)tree
my-project/.kiro/
├── steering/        # 프로젝트 규칙
│   ├── product.md   # 파운데이션
│   ├── tech.md
│   └── structure.md
├── agents/*.json
├── skills/**/SKILL.md
└── settings/mcp.json # 워크스페이스가 전역을 덮어씀

우선순위 규칙: 같은 이름이면 워크스페이스(.kiro/) 설정이 전역(~/.kiro/)을 덮어씁니다. 전역엔 전사·개인 공통을, 워크스페이스엔 프로젝트 특화 규칙을 둡니다.

Kiro 기능 전체 맵

Kiro 공식 명칭으로 보는
하네스 & 기능 레퍼런스

Kiro의 모든 구성 요소를 공식 명칭대로 정리했습니다. 각 항목은 무엇인지 · 파일 위치 · 언제 쓰는지 · 어느 계층에서 공유하는지 · 예시를 담습니다. 모두 IDE와 CLI에서 동일하게 동작합니다.

규칙 · 컨텍스트 도구 · 연결 워크플로우 · 패키징

언제 무엇을 쓰나?

한 줄 기준: 항상 지켜야 할 규칙 → Steering · 가끔 쓰는 전문 절차 → Skill · 복잡한 기능 구현 → Spec · 외부 시스템 연결 → MCP · 이벤트 자동화 → Hook · 이 묶음 배포 → Power.

요소언제 쓰나로딩 시점주 공유 계층
Steering항상 지켜야 할 규칙·컨벤션·정책항상(또는 조건부)전사 · 팀
Skill가끔 필요한 전문 절차·도메인 지식온디맨드(설명 매칭)팀 · 개인
Spec복잡한 기능/버그를 구조화해 구현작업 중팀(Git)
MCP외부 API·DB·시스템에 접근할 때세션 내내전사 레지스트리
Hook저장·커밋 등 이벤트에 반복 작업 자동화이벤트 발생 시팀(Git)
Knowledge사내 문서를 검색해 근거로 쓸 때질의 시중앙 RAG · 팀
Agent특정 역할·도구셋을 캡슐화할 때에이전트 선택 시팀 · 개인
PowerMCP+Steering+Hook을 한 묶음으로 배포키워드 매칭 시전사 · 개인 발행
Kiro 실제 화면
Kiro Steering 문서 화면
Steering — 규칙 파일 & inclusion 모드
Kiro Specs 문서 화면
Specs — 요구사항→설계→태스크
Kiro Agent Hooks 문서 화면
Agent Hooks — 이벤트 트리거

출처: kiro.dev/docs (Kiro 공식 문서 화면 캡처)

무엇: 에이전트가 항상 따르는 규칙·컨벤션을 담는 마크다운. 코딩 표준, 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 기반을 기본으로 한다

무엇: 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} 참조(하드코딩·커밋 금지).

.kiro/settings/mcp.jsonjson
{
  "mcpServers": {
    "internal-api": {
      "url": "https://mcp.corp.example.com/mcp",
      "oauthScopes": ["read", "write"],
      "autoApprove": ["search_tickets"]
    }
  }
}

무엇: 사내 문서·코드를 시맨틱/키워드로 검색하는 RAG 인덱스. Fast(BM25 키워드) vs Best(all-MiniLM-L6-v2 임베딩). 에이전트별 격리, 로컬 저장(클라우드 동기화 없음).

활성화: CLI: kiro-cli settings chat.enableKnowledge true. 에이전트 resourcesknowledgeBase 타입으로 선언하면 로드 시 자동 인덱싱.

공유: 인덱스 자체는 로컬이라 원본 문서를 Git/S3에 두고 agent 설정으로 각자 자동 인덱싱하는 패턴. 팀 · Git 원본

.kiro/agents/support.json, resourcesjson
"resources": [{
  "type": "knowledgeBase",
  "source": "file://./docs",
  "name": "CompanyDocs",
  "indexType": "best",
  "include": ["**/*.md"],
  "autoUpdate": true
}]

두 가지 방식: (A) 위처럼 로컬 knowledgeBase(개발자별 인덱스, 클라우드 동기화 없음) · (B) Amazon Bedrock Knowledge Base (S3 Vectors)를 만들어 MCP 서버로 연결. B는 전사가 하나의 중앙 RAG를 공유하고 인덱싱·최신화를 서버에서 관리, 대규모·거버넌스·최신성에 유리합니다. 연결은 탭 참고.

무엇: 온디맨드로 로딩되는 전문 지침 패키지. 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 리뷰 체크리스트
- 파티션 키 카디널리티와 핫 파티션 위험을 먼저 검토한다 ...

무엇: 스펙 주도 개발. 아이디어를 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. 결제 실패 롤백 시나리오

무엇: IDE 이벤트에 에이전트 프롬프트나 셸 명령을 자동 실행. 저장 시 린트, 커밋 전 보안 검사, 스펙 태스크 전후 훅 등 팀 프로세스를 표준화합니다.

트리거: SessionStart · UserPromptSubmit · Pre/PostToolUse · Pre/PostTaskExec · PostFileCreate/Save/Delete · Stop. 일부는 실행을 차단(block)할 수 있습니다.

위치·공유: .kiro/hooks/(워크스페이스) 또는 ~/.kiro/hooks/(전역). 팀 · Git

.kiro/hooks/lint-on-save.jsonjson
{ "version": "v1", "hooks": [{
  "name": "lint-on-save",
  "trigger": "PostFileSave",
  "matcher": "\\.ts$",
  "action": { "type": "command", "command": "npm run lint" }
}]}

무엇: 커스텀 에이전트 구성(JSON): prompt · tools/allowedTools · resources · hooks · mcpServers · model. 특정 역할(예: aws-ops, rust-dev)을 캡슐화합니다.

주의: 커스텀 에이전트는 steering을 자동 로드하지 않습니다. resourcesfile://.kiro/steering/**/*.md를 명시하세요(기본 에이전트는 자동).

공유: 팀 · Git / 개인. 로컬(.kiro)이 전역(~/.kiro) 동명 에이전트를 덮어씀.

무엇: 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한 파일 = 한 주제, 간결하게(매 턴 컨텍스트 소비), 결정의 "이유"까지, 비밀정보 금지agentsmd/agents.md(60k+ repos, Linux Foundation) · awesome-cursorrules
Skills명확한 name/description, 한 가지 일, 온디맨드, 예시·안티패턴 포함anthropics/skills · microsoft/skills · impeccable
MCP최소 권한, 신뢰 가능한 소스만, ${ENV} 비밀 관리, autoApprove 신중Playwright MCP(Microsoft) · GitHub MCP(공식·최다) · modelcontextprotocol/servers · awslabs/mcp · awesome-mcp-servers(500+)
Specs요구사항을 먼저 합의, 작은 태스크로 추적, 회귀 방지Kiro 고유(EARS 표기) — Rackspace · SmugMug · Netsmart 도입 사례(kiro.dev/blog)
Hooks빠르고 멱등하게, matcher로 범위 좁게, 실패해도 안전하게Kiro Hooks 예제 · ECC hooks
Powers응집도 높은 번들(MCP+Steering+Hook), 키워드 명확, 최소 도구Amazon Aurora powers · Miro powers · kiro.dev/powers
Agents역할·도구 최소화, 커스텀 에이전트는 steering 명시 로드ECC(67 agents) · Kiro built-in(default/plan/guide)

종합 벤치마크 · 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 하네스, steering 파일, Spec/Vibe 화면
실제 Kiro IDE — .kiro/(agents·skills·steering·settings) + 우리가 만든 steering + Spec/Vibe
Kiro IDE의 MCP 설정 편집기(User/Workspace Config)와 reviewer.json, mcp.json 탭
실제 Kiro IDE — MCP 설정 편집기(User/Workspace Config) + agent·mcp 파일
Kiro IDE Explorer에 .kiro의 steering·skills·agents·hooks·specs·settings 전체가 생성된 화면
실제 Kiro IDE — .kiro/에 steering·skills·agents·hooks·specs·settings 전부 생성됨

① 워크스페이스에 하네스 생성

유명 사례의 패턴을 그대로 따 사내용으로 만든 4개 파일입니다(실제 생성).

/tmp/kiro-e2e-demo/.kiro/tree
.kiro/
├── steering/team-conventions.md   # 규칙 (AGENTS.md 계보)
├── skills/api-review/SKILL.md     # 스킬 (anthropics/skills 계보)
├── agents/reviewer.json           # 에이전트 (steering+skill 로드)
└── settings/mcp.json              # MCP (aws-docs / awslabs 사례)

② kiro-cli로 실제 로드·검증 (E2E)

터미널 — 실제 출력bash
$ 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 규칙을 근거로 리뷰했습니다.

kiro-cli 실제 호출 — reviewer 에이전트가 SKILL.md를 읽고 규칙 근거로 응답한 터미널 화면
실제 호출 화면 — 에이전트가 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로 내려보내는 두 갈래

중앙 저장소 steering · mcp · hooks MDM / GPO Jamf · Intune · Kandji · GPO 자동 push ↓ 개발자 PC~/.kiro/steering/ 개발자 PC~/.kiro/steering/ 개발자 PC~/.kiro/steering/

관리자가 정책으로 지정 → 전 직원 기기에 강제·자동 배포. 온보딩·오프보딩과 함께 관리되어 이탈이 없습니다.

kiro-harness repo git · 버전관리 · 리뷰 pull 동기화 스크립트 / 온보딩 $ kiro-harness sync → ~/.kiro/ 로 복사

개발자가 주기적으로 pull(설치 스크립트·CI·온보딩 문서). 강제성은 낮지만 도입이 가볍고 Enterprise 없이도 가능.

권장: 강제가 필요한 보안·컴플라이언스 규칙은 MDM push, 빠르게 시작하거나 옵트인 성격은 Git pull. 둘을 병행하세요(공통 원본 repo → MDM이 배포, 원하는 팀은 직접 pull).

전사 MDM 도입

MDM으로 전사에 파일을 배포하는 법

이미 사내에 MDM이 있으면 그대로 활용하고, 없으면 IT/보안팀이 도입합니다. 목표는 Kiro 사용자 그룹의 모든 기기에 전역 steering 파일을 자동 배치하는 것입니다.

솔루션대상 OS파일 배포 방식기기 등록
Microsoft IntuneWin · macOSPowerShell / shell 스크립트(사용자 컨텍스트)Autopilot · Entra 조인
Jamf PromacOSPolicy + Script 또는 .pkg 패키지ABM/ADE 자동 등록
KandjimacOSCustom Script / Library ItemABM/ADE
Group Policy(GPO)Windows(AD)로그온 스크립트 · GPP 파일 복사AD 도메인 조인

MDM 확보 · 테넌트 구성

기존 MDM 활용 또는 신규 도입. macOS는 Apple Business Manager + APNs 인증서, Windows는 Entra/Autopilot 또는 AD 도메인을 준비합니다.

기기 자동 등록(enrollment)

온보딩 시 자동 등록(ADE/Autopilot)으로 신규 기기가 자동 편입되게 구성. 기존 기기는 일괄 등록.

대상 그룹 스코핑

Kiro 사용자만 담은 스마트 그룹 / Entra 그룹으로 적용 범위를 한정(IdC 그룹과 정렬).

배포 스크립트 등록

중앙 git repo(SoT)에서 steering 파일을 받아 ~/.kiro/steering/에 배치하는 스크립트를 등록. 로그인 사용자 컨텍스트로 실행해야 사용자 홈에 기록됩니다.

파일럿 후 전사 확대

소수 파일럿 그룹에 먼저 적용해 검증한 뒤 확대. repo 갱신 시 스크립트가 재실행되어 자동 동기화됩니다.

팁, KIRO_HOME: 사용자 홈에 직접 쓰는 대신 환경변수 KIRO_HOME=/opt/company/kiro를 MDM으로 설정하고 그 경로에 파일을 배치하면, 관리형 시스템 경로로 깔끔하게 중앙 관리할 수 있습니다(사용자별 홈 쓰기 회피).

Jamf/Intune 배포 스크립트 예 (macOS · 로그인 사용자 컨텍스트)bash
#!/bin/bash
# 중앙 저장소의 전사 steering 을 각 기기 ~/.kiro/steering 로 동기화
USER=$(stat -f%Su /dev/console)
HOME_DIR=$(dscl . -read /Users/"$USER" NFSHomeDirectory | awk '{print $2}')
DEST="$HOME_DIR/.kiro/steering"
mkdir -p "$DEST"
git -C /tmp/kiro-harness pull || git clone https://git.corp.example/kiro-harness /tmp/kiro-harness
rsync -a --delete /tmp/kiro-harness/steering/ "$DEST/"
chown -R "$USER" "$HOME_DIR/.kiro"

주의: 스크립트는 루트로 실행되더라도 파일 소유권은 로그인 사용자로 맞추세요(chown). 비밀값·토큰은 steering에 넣지 마세요. Windows는 %USERPROFILE%\.kiro\steering에 로그온 스크립트로 배치합니다.

중앙 Repo Pull 도입

Git으로 당겨오는 방식 (MDM 없이)

Enterprise·MDM이 없어도 시작할 수 있는 가벼운 방식입니다. 중앙 kiro-harness 저장소를 단일 원천(SoT)으로 두고, 개발자가 스크립트로 ~/.kiro/에 동기화합니다. 옵트인 성격이라 MDM과 병행하기 좋습니다.

kiro-harness/ (중앙 저장소 구조)tree
kiro-harness/
├── steering/        # 전사 규칙 *.md
├── skills/          # 공유 스킬
├── agents/          # 공유 에이전트
├── hooks/           # 공유 훅
├── settings/mcp.json  # 공용 MCP(비밀값은 ${ENV})
├── VERSION            # 버전 스탬프
└── install.sh         # 동기화 스크립트

중앙 repo 구성

하네스를 저장소로 관리하고 PR 리뷰로 변경. 비밀값은 커밋 금지(${ENV}).

동기화 스크립트 제공

clone/pull 후 ~/.kiro/로 복사하는 멱등(idempotent) 스크립트. 개인 파일은 보존.

온보딩에 포함

신규 입사자 셋업 문서/스크립트에 한 줄로 넣어 최초 1회 자동 적용.

주기 자동 갱신

cron(리눅스) · launchd(mac) · Task Scheduler(win) 또는 셸 rc 훅으로 하루 1회 pull.

install.sh, 개인 설정을 보존하며 전사 하네스 동기화bash
#!/usr/bin/env bash
set -euo pipefail
REPO="https://git.corp.example/platform/kiro-harness.git"
SRC="${TMPDIR:-/tmp}/kiro-harness"
DEST="$HOME/.kiro"
git -C "$SRC" pull --ff-only 2>/dev/null || git clone --depth 1 "$REPO" "$SRC"
# 전사 파일은 회사 네임스페이스로 격리 배치 → 개인 파일과 충돌 방지
for d in steering skills agents hooks; do
  mkdir -p "$DEST/$d/company"
  rsync -a --delete "$SRC/$d/" "$DEST/$d/company/"
done
mkdir -p "$DEST/settings"
cp "$SRC/settings/mcp.json" "$DEST/settings/mcp.company.json"
echo "kiro-harness $(cat "$SRC/VERSION") 동기화 완료"

개인 설정 보존: 전사 파일을 ~/.kiro/steering/company/처럼 하위 네임스페이스에 두면 개인 파일과 섞이지 않습니다(steering은 하위 폴더까지 재귀 로드). 또는 KIRO_HOME을 분리.

자동화·알림: 셸 rc에 install.sh를 하루 1회 조건 실행하도록 걸고, repo 변경 시 CI가 사내 채널에 공지하면 최신성이 유지됩니다.

강제성 차이: Pull은 사용자가 실행해야 반영되는 옵트인입니다. 반드시 강제해야 하는 보안·컴플라이언스 규칙은 MDM push로, 나머지는 pull로 병행하세요.

거버넌스 (Enterprise)

무엇을 허용할지 중앙에서 통제

IDE·CLI 양쪽에 결정적으로(deterministic) 적용됩니다. IAM Identity Center·API key 사용자 대상(Builder ID·소셜 로그인 제외).

MCP 레지스트리 allow-list

승인 서버 목록(JSON)을 HTTPS 호스팅 → Kiro Profile에 URL 등록. 사용자는 목록 내 서버만 사용.

모델 거버넌스

개발자가 사용할 수 있는 모델을 제한. 규정·비용 정책에 맞춰 통제.

MCP On/Off 토글

Kiro 콘솔 > Shared settings에서 조직/계정 단위로 MCP 전체를 차단(계정이 조직을 우선).

mcp-registry.json, HTTPS로 호스팅 후 Kiro Profile에 URL 등록json
{
  "servers": {
    "internal-api": {
      "url": "https://mcp.corp.example.com/mcp",      # remote(HTTP)
      "headers": { "Authorization": "Bearer ${CORP_TOKEN}" }
    },
    "aws-docs": { "command": "uvx", "args": ["awslabs.aws-documentation-mcp-server"] }
  }
}

한계: 토글·레지스트리는 클라이언트 측에서 강제됩니다. 로컬 관리자 권한이 있는 사용자는 우회할 수 있으므로, 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 설정을 파일로 import
kiro-cli mcp import --file team-servers.json --scope workspace
# 2) 스킬/에이전트는 폴더 복사 또는 git
cp -R ~/.kiro/skills/db-review  ./.kiro/skills/
# 3) 가장 깔끔: Power 로 묶어 발행 (MCP+steering+hooks)
공유 매트릭스

요소별 · 계층별 공유 방법 한눈에

요소중앙 (전사)팀 (프로젝트)개인
SteeringMDM/GPO push · repo pull.kiro/steering/ git~/.kiro/steering/
MCPEnterprise 레지스트리 allow-list.kiro/settings/mcp.json gitmcp import · ~/.kiro
SkillsMDM · repo.kiro/skills/ git폴더 복사
Agentsrepo pull.kiro/agents/ git~/.kiro/agents/
Specs없음.kiro/specs/ git (핵심)로컬 초안
HooksMDM · repo.kiro/hooks/ git~/.kiro/hooks/
Knowledge원본 repo/S3 · Bedrock KB(S3 Vectors)+MCPknowledgeBase 리소스 + 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·Lambda AgentCore Gateway OpenAPI·Smithy·Lambda → MCP endpoint MCP Kiro (전사) 🔒 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

상시 연결·세션 상태·무거운 의존성이 필요할 때 컨테이너로 상시 구동. 스케일링·네트워킹 직접 제어.

Kiro에 연결

remote MCP로 붙이고, 전사에 배포

.kiro/settings/mcp.json, remote + OAuth(PKCE)json
{ "mcpServers": {
  "internal-api": {
    "url": "https://gateway.bedrock-agentcore.ap-northeast-2.amazonaws.com/.../mcp",
    "oauth": { "clientId": "<cognito-app-client-id>" },   # 공개 클라이언트(PKCE)
    "oauthScopes": ["openid", "api/read"]
  }
}} 

인증: 원격 MCP는 OAuth를 지원(DCR 자동). 미지원 서버는 oauth.clientId공개 클라이언트(PKCE, client_secret 없음)만 가능, Cognito·Okta·Entra/IdC. 서버는 /.well-known/oauth-authorization-server를 서빙하고 JWKS로 Bearer 토큰을 검증해야 합니다. 간단히는 headers${ENV} 토큰도 가능.

중앙 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로 묶기.

PHASE 3 · 분기

전사 거버넌스, Enterprise

Kiro Enterprise(IAM Identity Center) 도입, IdP 연결, 티어 할당. MCP 레지스트리 allow-list·모델 정책 적용, 전역 steering을 MDM/GPO로 전파. 대시보드·per-user 리포트로 채택·비용 모니터링.

체크리스트

역할별 실행 체크리스트

클릭해 체크하세요. 진행 상황은 브라우저에 저장됩니다.

개발자

  • Kiro 설치 · ~/.kiro/steering에 개인 preferences
  • 팀 저장소 clone → 워크스페이스 하네스 자동 적용 확인
  • 유용한 Skill/Power 하나 도입해보기

팀 리드

  • 파운데이션 steering(product/tech/structure) 작성·커밋
  • .kiro/ 리뷰 규칙 수립(비밀값 금지)
  • 사내 API 1개 MCP화 + Power로 패키징

플랫폼 / 보안팀

  • Kiro Enterprise + IAM Identity Center 활성화
  • IdP(Okta/Entra/IdC) 연결 · 티어 할당
  • MCP 레지스트리 allow-list HTTPS 호스팅 → Profile 등록
  • 모델 거버넌스 정책 설정
  • 전역 steering MDM/GPO 전파 파이프라인 구성
  • 대시보드·per-user CSV로 채택/비용 모니터링

참고 문서

공식 근거 자료