AI-DLC for Enterprise (3): Kiro Enterprise로 거버넌스 완성하기

AI-DLC를 조직 수준에서 운영하기 위한 Kiro Enterprise의 Model Governance, MCP Registry, Observability 기능을 다룹니다.

Series: AI-DLC for Enterprise (4 articles)

1
AI-DLC for Enterprise: 거버넌스 아키텍쳐 가이드
…
4
AI-DLC for Enterprise (3): Kiro Enterprise로 거버넌스 완성하기 This article

Suyeon Kim

Published Jul 8, 2026

Last modified Jul 9, 2026

이 글은 2026년 5월 기준 서비스 기능과 콘솔 UI를 기반으로 작성되었습니다.

서론: "AI 코딩 도구 자체를 조직 수준에서 어떻게 관리할 것인가?"

AI-DLC를 적용하여 소프트웨어 라이프사이클을 AI 네이티브로 전환하면서 AI와 사람의 협업모델, 그리고 사람과 사람의 협업 모델이 체계화 되었습니다. 그렇지만, 여전히 다른 어려움들이 존재했고 이러한 어려움들을 해결하기 위해 1편 에서 AI에게 사내 지식을 가르쳤고, 2편 에서 AI가 접근할 수 있는 도구를 통제했습니다. 그럼에도 실무에서는 이런 질문들이 끊이질 않습니다:

"누가 어떤 모델을 쓰고 있는지 파악이 되나?"
"프롬프트에 민감한 정보가 들어가면?"
"검증 안 된 MCP가 연결되면?"
"개발자마다 AI 활용 역량 차이가 크면?"

KB로 "무엇을 알려줄지", MCP Registry로 "어떤 도구를 쓰게 할지"는 정했습니다. 하지만 도구 자체가 통제되지 않아서 개발자가 임의의 모델을 쓰거나, 회사 데이터가 외부로 나가거나, 프롬프트 기록이 남지 않으면 거버넌스에 구멍이 생깁니다.

이 글에서는 Kiro Enterprise의 거버넌스 기능과 AI-DLC 워크플로우를 자동화하는 방법을 다룹니다.

Kiro Enterprise Governance 기능

Kiro Enterprise는 개인 사용자용 Kiro 위에 조직 수준의 거버넌스 계층을 얹은 것입니다. 개발자 경험은 동일하지만, 관리자가 보이지 않는 곳에서 경계를 설정합니다. Kiro의 Enterprise 기능을 사용하면, 별도의 LLM Gateway나 MCP Gateway를 자체 구축할 필요 없이 바로 적용할 수 있습니다.

1. User/Group/Subscription Management

Kiro Console에서는 IAM Identity Center를 사용하여 사용자별/그룹별 구독 관리를 할 수 있습니다.

Users: 사용자별 구독 플랜 설정
Groups: 그룹별 구독 플랜 설정 (그룹 내에 속한 모든 사용자에게 구독 플랜 일괄 설정)
Subscriptions: 전체 구독 목록

[Users]

[Groups]

[Subscriptions]

2. Model Governance

기본적으로 사용자는 Kiro가 지원하는 모든 모델에 접근할 수 있지만, 관리자는 이를 제한할 수 있습니다:

모델 접근 관리 활성화(Toggle): Model access management를 켜면 조직 전체에 모델 제한이 적용됩니다.
허용 모델 목록(Approved List): 조직에서 사용 가능한 모델만 선택합니다. 목록에 없는 모델은 개발자 IDE에서 선택 자체가 불가능합니다.
기본 모델(Default Model): 모든 클라이언트(IDE, CLI)에 자동 적용되는 기본 모델을 설정합니다. 개발자가 별도로 모델을 선택하지 않으면 이 모델이 사용됩니다.
Cross-Region 제어: 데이터 주권 요건에 따라 특정 리전의 모델만 허용합니다.

개발자가 "더 좋은 모델을 쓰고 싶다"며 외부 API를 연결하는 순간, 회사 코드가 통제 밖으로 나갑니다. Model Governance는 그 가능성을 아키텍처 수준에서 제거합니다.

3. MCP Governance

2편 에서 구축한 MCP Registry가 실제로 강제되는 지점입니다. Kiro Enterprise에서는 MCP 사용을 통제할 수 있습니다:

MCP 완전 비활성화: 조직 전체에서 MCP 사용 자체를 끌 수 있습니다. 모든 외부 도구 연결을 원천 차단하는 가장 강력한 옵션입니다.
MCP Registry (allowlist): 승인된 MCP 서버만 허용합니다. MCP Registry URL을 지정하면 등록된 MCP만 IDE에 표시됩니다.
Organization 레벨 정책: 조직 전체에 적용하거나, 계정(Account)별로 오버라이드 가능합니다. 예를 들어 보안 팀은 MCP를 비활성화하고, 개발 팀은 Registry 기반 allowlist를 적용하는 식입니다.

로컬 mcp.json에 아무리 다른 MCP를 추가해도, Organization 레벨 MCP Registry에 없으면 사용할 수 없습니다. 이것이 2편에서 구축한 Registry의 최종 강제 메커니즘입니다.

4. Observability

사용량 대시보드 (Dashboard)

관리자 콘솔에서 조직 전체의 AI 사용 현황을 확인할 수 있습니다.

지표	설명	갱신 주기
구독 현황 (Tier별)	Pro, Pro+, Pro Max, Power별 총/활성/대기 구독 수	시간별
활성 사용자	일별/주별/월별 고유 사용자 수, 클라이언트(IDE vs CLI)별 분류	일별
크레딧 소비	일별/주별/월별 총 소비, Tier별 + 클라이언트별 분류	시간별

날짜 범위와 프로그래밍 언어별 필터링도 가능합니다.

[Kiro 구독 현황]

조직의 Kiro 구독 현황을 한눈에 보여줍니다. Pending(대기), Active(활성), Total(전체) 구독 수를 Tier별(Pro, Pro+, Pro Max, Power)로 확인할 수 있습니다. 아직 사용을 시작하지 않은 Pending 구독은 과금되지 않습니다.

[Client 타입/구독 별 크레딧 소비량]

Client 별 소비량: Kiro 크레딧 소비량을 클라이언트 유형별(CLI, IDE, WEB)로 일별 추이를 보여줍니다. 어떤 사용 방식이 크레딧을 가장 많이 소비하는지 파악하여 비용 예측과 최적화에 활용할 수 있습니다.

Kiro Dashboard_Credit usage by client type

구독 Tier별(Pro, Pro+, Pro Max, Power) 크레딧 소비 추이를 보여줍니다. 특정 Tier의 소비가 급증하거나, Tier 간 불균형이 발생하면 라이선스 재배분을 검토할 근거가 됩니다.

Kiro Dashboard_Credit usage by plan type

[Client 타입/구독 플랜 별 활성 사용자 수]

일별 활성 사용자 수를 클라이언트 유형별(CLI, IDE, WEB)로 표시합니다. CLI 사용이 갑자기 증가하거나 IDE 사용이 줄어드는 패턴을 감지하여 도구 채택 현황을 모니터링할 수 있습니다.

Kiro Dashboard_Active users by client type

Tier별 활성 사용자 수를 일별로 보여줍니다. 특정 Tier 사용자가 활발히 쓰고 있는지, 비활성 라이선스가 많은지 파악하여 라이선스 할당을 최적화할 수 있습니다.

Kiro Dashboard_Active users by plan type

[Client 별 사용량]

전체 사용량 중 클라이언트별 비중을 파이 차트로 보여줍니다. 이 예시에서는 CLI(4,909)가 IDE(263)보다 압도적으로 많은데, 자동화 파이프라인에서의 CLI 사용량을 별도로 추적하는 데 유용합니다.

대시보드가 제공하는 가치는 크게 두 가지입니다:

1. 투자 대비 효과 증명 — "AI 도구에 투자한 만큼 효과가 있는가?"라는 질문에 데이터로 답할 수 있습니다. 팀별 활용도, 크레딧 소비 패턴 등을 경영진에게 보고할 수 있는 근거가 됩니다.

2. 이상 패턴 감지 — 갑자기 특정 사용자의 크레딧 사용량이 급증하거나, 비정상적인 시간대에 대량 요청이 발생하면 보안 이슈의 징후일 수 있습니다.

상세 문서: Kiro Enterprise Dashboard

사용자별 활동 리포트 (User Activity)

일별 CSV 리포트가 지정한 S3 버킷에 자동 생성됩니다:

1
s3://bucket/prefix/AWSLogs/accountId/KiroLogs/user_report/region/year/month/day/00/clientType_report.csv

포함 지표:

필드	설명
Date	리포트 날짜
UserId	사용자 고유 식별자
Client_Type	IDE / CLI / Plugin
Chat_Conversations	일별 채팅 대화 수
Credits_Used	소비 크레딧
Overage_Cap	초과 사용 상한
Overage_Credits_Used	초과 사용 크레딧
Overage_Enabled	초과 사용 허용 여부
Subscription_Tier	구독 티어
Total_Messages	총 메시지 수 (프롬프트 + 도구 호출 + 응답)

이 데이터를 Amazon Athena로 쿼리하거나 Amazon Quick으로 시각화할 수 있습니다. 기존 분석 파이프라인에 연동하는 것도 가능합니다.

활용 예시:

"어떤 팀이 AI를 가장 적극적으로 활용하고 있는가?" → 교육/확산 전략 수립
"크레딧 소비 패턴이 갑자기 변한 사용자는?" → 이상 행동 감지
"CLI vs IDE 사용 비율은?" → 도구 투자 방향 결정

상세 문서: Kiro Enterprise User Activity

프롬프트 로깅 (Prompt Logging)

모든 AI 상호작용의 입출력을 고객의 S3 버킷에 기록합니다:

인라인 제안: leftContext, rightContext, fileName, 생성된 completions
채팅: 사용자 프롬프트, Kiro 응답, 도구 호출 내역
메타데이터: userId, timeStamp, requestId

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
  "records": [{
    "generateCompletionsEventRequest": {
      "leftContext": "import * cdk from 'aws-cdk-lib';...",
      "rightContext": "// end of stack",
      "fileName": "cdk-stack.ts",
      "userId": "d-92675051d5.b8f1f340-...",
      "timeStamp": "2026-01-06T15:09:16.412719Z"
    },
    "generateCompletionsEventResponse": {
      "completions": ["synth() { return cdk.App... }"],
      "requestId": "797c70ee-..."
    }
  }]
}

프롬프트 로깅의 핵심 가치:

감사(Audit): 규정 준수 요건(금융, 의료 등)에서 요구하는 AI 사용 기록. "3개월 전에 AI가 생성한 코드의 근거가 뭐였는지?" — 프롬프트 기록에서 확인 가능합니다.
패턴 분석: 팀 전체의 프롬프트 패턴을 분석하여 Steering 규칙이나 에이전트 프롬프트 개선에 활용할 수 있습니다.
보안 모니터링: 프롬프트에 민감 정보가 포함되는 패턴 감지 → Bedrock Guardrails 정책 조정 근거로 활용합니다.

S3 저장 비용 + 선택적 KMS 암호화 비용 외 추가 과금은 없습니다.

상세 문서: Kiro Enterprise Prompt Logging

5. Security

보안 계층	구현
인증	IAM Identity Center (SSO) 기존 IdP 연동, MFA 강제
인가	팀·역할별 권한 분리, 퇴사 시 자동 차단
전송 암호화	TLS 1.2+
저장 암호화	AWS KMS (고객 관리형 키 지원)
감사	CloudTrail 연동, 프롬프트 로깅

IdP에서 계정을 비활성화하면 Kiro 접근도 즉시 차단되므로, 퇴사자 처리시 별도 관리 포인트가 없습니다.

6. 기타

API Key Management

Kiro CLI 사용을 위한 API 키 생성 권한을 관리합니다. 기본값은 비활성화 — 관리자가 명시적으로 허용해야 개발자가 CLI용 API 키를 생성할 수 있습니다. CLI를 통한 자동화 파이프라인을 허용할지 여부를 조직 정책으로 결정하는 것입니다.

Web Tools Governance

web_search와 web_fetch 도구의 사용 여부를 조직 단위로 제어합니다. 보안 요건에 따라 AI가 외부 웹에 접근하는 것을 원천 차단할 수 있습니다. 금융이나 방위산업처럼 외부 데이터 유입 자체가 문제가 되는 환경에서 필수적인 설정입니다.

네트워크 & 접근 제어 아키텍처

Enterprise 환경에서는 "기능적 통제"만으로 부족합니다. 네트워크 수준에서 경계를 설정해야 보안팀이 안심합니다.

Kiro는 PrivateLink를 통해 인터넷망을 통하지 않고, 사내 네트워크 내부에서 안전하게 AI 도구를 사용할 수 있도록 구성할 수 있습니다.

참고: Kiro and interface endpoints (AWS PrivateLink)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
┌─────────────────────────────────────────────────────────────────┐
│  Corporate Network (사내망)                                      │
│                                                                 │
│  Developer Workstation                                         │
│       │                                                         │
│       ▼                                                         │
│  ┌─────────┐                                                    │
│  │   WAF   │ ← IP Allowlist (사내 IP 대역만 허용)                  │
│  └────┬────┘                                                    │
│       │                                                         │
└───────┼─────────────────────────────────────────────────────────┘
        │ (PrivateLink)
        ▼
┌─────────────────────────────────────────────────────────────────┐
│  AWS Cloud                                                      │
│                                                                 │
│  ┌──────────────┐    ┌──────────────┐    ┌────────────────┐     │
│  │ Kiro Backend │───▶│ Bedrock      │───▶│ S3 (Logs)      │     │
│  │              │    │ (Models)    │     │ (직접접근차단)    │     │
│  └──────────────┘    └──────────────┘    └────────────────┘     │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

WAF (Web Application Firewall)

IP 기반 접근 제어: 사내 IP 대역에서만 Kiro에 접근 가능
Rate Limiting: 비정상적 대량 요청 차단
Geographic Restriction: 필요 시 국가 단위 차단

PrivateLink Endpoints

Kiro Backend ↔ AWS 서비스 간 트래픽이 퍼블릭 인터넷을 거치지 않음
VPC 내부 엔드포인트를 통해 Bedrock, S3 등에 접근
네트워크 팀이 트래픽 흐름을 완전히 파악 가능

S3 직접 접근 차단

프롬프트 로그와 활동 리포트가 저장되는 S3 버킷은:

Public Access Block 활성화
OAC(Origin Access Control) 적용 — Kiro 서비스 경유만 허용
VPC Endpoint Policy로 특정 VPC에서만 접근

핵심: 개발자가 S3 URL을 직접 알아도 접근할 수 없습니다. 반드시 Kiro 서비스를 거쳐야 합니다.

Enhanced Architecture: Prompt Logging + Bedrock Guardrails + Data Redaction

여기서부터 "있으면 좋은 것"이 아니라 "규제 산업에서 필수인 것"입니다.

Prompt Logging & Activity Reports

1
2
3
4
5
6
7
8
9
10
11
12
Developer → Kiro → Bedrock (AI 모델)
                ↓
         Prompt Logging
                ↓
         S3 Bucket (암호화)
                ↓
     ┌──────────────────┐
     │ Activity Reports │
     │ - 사용자별 이력      │
     │ - 모델별 통계       │
     │ - 이상 패턴 감지     │
     └──────────────────┘

모든 AI 상호작용(입력 프롬프트 + 출력 응답)이 S3에 기록됩니다. 이것이 왜 중요한지:

감사 대응: "3개월 전에 AI가 생성한 코드의 근거가 뭐였지?" — 프롬프트 기록에서 확인 가능
이상 감지: 특정 사용자가 갑자기 민감 데이터를 대량으로 프롬프트에 넣으면 알림
품질 개선: 어떤 프롬프트가 좋은 결과를 내는지 팀 전체가 학습
규제 준수: 금융·의료 등 규제 산업에서 AI 의사결정의 추적 가능성(Traceability) 요건 충족

Bedrock Guardrails: Data Redaction

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
{
  "guardrail": {
    "name": "enterprise-code-guardrail",
    "sensitiveInformationPolicy": {
      "piiEntities": [
        {"type": "AWS_ACCESS_KEY", "action": "BLOCK"},
        {"type": "AWS_SECRET_KEY", "action": "BLOCK"},
        {"type": "CREDIT_CARD_NUMBER", "action": "ANONYMIZE"},
        {"type": "EMAIL", "action": "ANONYMIZE"},
        {"type": "PHONE", "action": "ANONYMIZE"}
      ],
      "regexPatterns": [
        {
          "name": "internal-api-key",
          "pattern": "sk-[a-zA-Z0-9]{32}",
          "action": "BLOCK"
        },
        {
          "name": "database-connection-string",
          "pattern": "mongodb\\+srv://[^\\s]+",
          "action": "BLOCK"
        }
      ]
    }
  }
}

개발자가 실수로 (혹은 모르고) 민감 정보를 프롬프트에 포함시켜도:

BLOCK: AWS 키, 시크릿 등은 AI에 전달되지 않고 차단
ANONYMIZE: 이메일, 전화번호 등은 마스킹되어 전달

이 부분은 "개발자를 믿지 않는다"가 아니라 "실수를 시스템이 잡아준다"입니다. 사람은 실수로 .env 파일 내용을 프롬프트에 넣을 수 있지만, Guardrails은 그 것을 막아줍니다.

세 계층의 조합

1
2
3
요청 → WAF (네트워크 필터) → Guardrails (데이터 필터) → AI 모델 → 응답
                                                              ↓
                                                       Prompt Logging (감사)

이 세 계층이 합쳐지면:

WAF: 어디서 접근하는지 통제
Guardrails: 무엇을 보내는지 통제
Prompt Logging: 무엇이 오갔는지 기록

"접근 경로 → 전송 데이터 → 사후 감사" 전 구간이 커버됩니다. 한 계층이 우회되더라도 다른 계층에서 탐지하거나 기록할 수 있어, 단일 장애점(Single Point of Failure) 없이 보안 체계가 유지됩니다.

결론

이 편에서는 Kiro Enterprise의 거버넌스 기능으로 AI 코딩 도구를 조직 수준에서 관리하는 방법을 다뤘습니다. Model Governance로 허용된 모델만 사용하게 하고, MCP Registry 강제로 승인된 도구만 연결하게 하며, Observability 대시보드로 사용 현황을 실시간으로 파악하고, Network Security로 데이터 유출 경로를 원천 차단하는 것이 핵심입니다.

# ai-dlc # kiro # governance # ai-for-developers # software-development

Series: AI-DLC for Enterprise (4 articles)

1
AI-DLC for Enterprise: 거버넌스 아키텍쳐 가이드
…
4
AI-DLC for Enterprise (3): Kiro Enterprise로 거버넌스 완성하기 This article

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

AI-DLC for Enterprise (3): Kiro Enterprise로 거버넌스 완성하기

Series: AI-DLC for Enterprise (4 articles)

Suyeon Kim

서론: "AI 코딩 도구 자체를 조직 수준에서 어떻게 관리할 것인가?"

Kiro Enterprise Governance 기능

1. User/Group/Subscription Management

2. Model Governance

3. MCP Governance

4. Observability

사용량 대시보드 (Dashboard)

사용자별 활동 리포트 (User Activity)

프롬프트 로깅 (Prompt Logging)

5. Security

6. 기타

API Key Management

Web Tools Governance

네트워크 & 접근 제어 아키텍처

WAF (Web Application Firewall)

PrivateLink Endpoints

S3 직접 접근 차단

Enhanced Architecture: Prompt Logging + Bedrock Guardrails + Data Redaction

Prompt Logging & Activity Reports

Bedrock Guardrails: Data Redaction

세 계층의 조합

결론

Series: AI-DLC for Enterprise (4 articles)