AI-DLC for Enterprise (2): MCP Server로 도구 통제하기

Kiro를 사용하여 AI-DLC 환경에서 AI가 접근할 수 있는 도구의 경계를 정의하고 강제하는 사내 MCP Server 및 MCP Registry를 구성하는 방법을 다룹니다.

Series: AI-DLC for Enterprise (4 articles)

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

Suyeon Kim

Published Jul 8, 2026

Last modified Jul 9, 2026

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

서론: "MCP, 연결은 쉬운데 통제는 어렵다"

앞서 1편 에서 AI-DLC를 사내 표준 워크플로우로 정의한 뒤, Knowledge Base를 워크플로우에 연결함으로써 개발자들의 AI 도구 사용 역량과 산출물의 품질 및 신뢰도가 크게 향상 되었습니다. 그렇지만, AI 코딩 도구를 조직에 도입하면서 가장 빠르게 마주치는 또 다른 문제가 있습니다.

"외부 MCP 서버를 통해 사내 코드가 어디로 나가는지 추적이 안 된다"
"같은 목적의 MCP를 팀마다 다른 걸 쓰니까 결과가 제각각이다"
"새로운 MCP가 매주 나오는데, 뭘 믿고 연결해야 하는지 기준이 없다"

AI 코딩 도구가 Model Context Protocol(MCP) 을 통해 외부 도구와 연결되면서, 개발 속도는 확실히 빨라졌습니다. 하지만 속도가 빨라진 만큼 조직이 통제할 수 없는 데이터 흐름도 함께 만들어집니다.

1편에서 Knowledge Base를 구축하고 search_knowledge MCP 도구로 AI-DLC 워크플로우에 연결하는 방법을 다뤘다면, 이번에는 그 MCP 서버 자체를 어떻게 구축하고 통제하는지를 다룹니다. "AI가 무엇을 알아야 하는가"의 다음 질문으로 "AI가 어떤 도구에 접근할 수 있는가"에 대한 답입니다.

이 글에서는 사내 Compliance MCP 패턴으로 해결하는 방법을 다룹니다. Compliance MCP 서버와 Approved MCP Registry 이 두 가지 메커니즘으로 "보안 및 표준 검증 부재"와 "거버넌스 부재" 문제를 동시에 해결하는 방법을 살펴봅니다.

통제 없는 MCP 사용의 3가지 시나리오

MCP는 AI 모델이 외부 도구와 표준화된 방식으로 통신하게 해주는 프로토콜입니다. 데이터베이스 조회, 파일 시스템 접근, 외부 API 호출 등을 AI가 도구처럼 사용할 수 있게 해줍니다. 매우 유용하지만, 조직 차원의 통제가 없으면 다음 세 가지 시나리오가 현실이 됩니다.

[시나리오 1] 데이터 경로의 불투명성

한 개발자가 "코드를 분석해주는" 외부 MCP 서버를 발견해 연결합니다. 이 서버는 분석을 위해 코드를 외부 엔드포인트로 전송합니다. 개발자는 편의를 위해 연결했을 뿐이지만, 조직 입장에서는 사내 코드가 검토되지 않은 외부로 나간 것입니다.
더 큰 문제는 이를 추적할 방법조차 없다는 점입니다. CloudTrail에도 남지 않고, 네트워크 로그에서도 잡기 어렵습니다. AI 코딩 도구가 직접 외부와 통신하기 때문입니다.

[시나리오 2] 도구 동작의 불일치

같은 목적의 MCP를 개발자마다 다르게 연결합니다. A 팀은 X MCP로 DB를 조회하고, B 팀은 Y MCP를 씁니다. 두 도구의 권한 범위와 동작이 달라서, 같은 AI-DLC 워크플로우를 돌려도 팀마다 다른 결과가 나옵니다.
거버넌스 관점에서 "우리 조직의 AI가 무엇을 할 수 있는가"를 한마디로 답할 수 없게 됩니다. 감사(audit) 때 "개발자 300명이 각자 다른 MCP를 쓰고 있어서 전수 조사가 필요합니다"라는 상황은 누구도 원하지 않을 겁니다.

[시나리오 3] MCP 공급망 리스크

외부 MCP 서버는 업데이트될 때마다 동작이 바뀔 수 있습니다. 어제까지 안전했던 도구가 오늘 업데이트 후 추가 데이터를 수집하거나, 다른 엔드포인트로 전송할 수도 있습니다. npm 패키지의 supply chain attack과 같은 맥락이지만, MCP는 AI가 사용하므로 그 영향 범위가 더 넓습니다.
검증 없이 외부 MCP를 신뢰하면, AI 도구가 의존하는 공급망 전체가 통제 밖에 놓입니다.

세 시나리오의 공통점은 "AI가 접근할 수 있는 도구의 경계가 정의되지 않았다"는 것입니다. 경계를 정의하고 강제하는 것이 거버넌스의 출발점입니다.

Compliance MCP 서버 아키텍처

해법은 사내 전용 MCP 서버를 두는 것입니다. 사내 MCP는 두 가지 핵심 역할을 담당합니다:

사내 시스템과의 안전한 연결 — 사내 표준 검색, 정책 검증 같은 도구를 사내망 안에서 제공
거버넌스 규칙의 단일 진입점 — 승인된 MCP 목록 제공, 정책 버전 검증 등 거버넌스 도구 집중

전체 아키텍처 (파란색 영역)

이 아키텍처는 두 가지 흐름으로 구성됩니다:

관리자 흐름 (Admin Lambda): 정책과 Registry를 업데이트하는 경로
개발자 흐름 (MCP Lambda): 개발 중 도구를 호출하는 경로

또한, 서버리스 아키텍쳐로 구성하여 사용량이 없을 때는 비용이 거의 발생하지 않고, 개발자 수가 늘어도 자동으로 확장되며, 구성 요소는 다음과 같습니다.

구성 요소별 역

구성 요소	역할
Amazon API Gateway	MCP 도구 호출 엔드포인트 (Tools API) + 관리 엔드포인트 (Admin API)
AWS Lambda (MCP)	개발자 요청 처리 - 정책 검증, KB 검색, 설정 조회
AWS Lambda (Admin)	플랫폼 팀 요청 처리 - 정책/Registry 업데이트
Amazon DynamoDB	정책(Policies), 컴플라이언스 이력(History), 위반 기록(Violations) 저장
Amazon S3	MCP Registry JSON + Knowledge Base 데이터 소스 저장
Amazon CloudFront	Registry JSON을 CDN으로 배포 - Kiro Admin Console에서 설정한 URL
AWS WAF	사내망 IP만 허용 - Registry와 MCP 도구 호출 모두 사내에서만 접근 가능

주요 구현 사항

MCP Registry 구성

핵심 거버넌스 메커니즘은 '승인된 MCP 레지스트리'입니다. 회사가 검토하고 승인한 MCP 서버만 목록으로 관리하고, AI 코딩 도구가 이 목록의 MCP만 사용하도록 가이드하는 패턴입니다. 이것은 "어떤 MCP를 허용할지"를 정의하는 단계에 해당합니다.

Kiro MCP Governance

Kiro는 조직의 MCP 사용 여부와 MCP 허용 목록을 관리할 수 있는 MCP Governance 기능을 제공합니다.

Kiro MCP Registry 형식

Kiro의 MCP Registry는 JSON 형태로 관리합니다. MCP 사양의 서버 정의를 따르되, 거버넌스에 필요한 메타데이터를 추가할 수 있습니다.

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
{
  "version": "2.1.0",
  "lastUpdated": "2026-07-01T09:00:00Z",
  "servers": [
    {
      "server": {
        "name": "compliance-mcp",
        "title": "Compliance MCP",
        "description": "사내 표준 검색 및 정책 검증",
        "version": "1.0.0",
        "remotes": [
          {
            "type": "streamable-http",
            "url": "https://compliance-mcp.internal.example.com/prod"
          }
        ]
      },
      "governance": {
        "owner": "platform-team",
        "approvedDate": "2026-05-15",
        "nextReviewDate": "2026-08-15",
        "riskLevel": "low",
        "dataClassification": "internal"
      }
    },
    {
      "server": {
        "name": "github-mcp",
        "title": "GitHub Enterprise MCP",
        "description": "사내 GitHub Enterprise 연동 (PR, Issue 관리)",
        "version": "2.3.1",
        "remotes": [
          {
            "type": "streamable-http",
            "url": "https://github-mcp.internal.example.com/prod"
          }
        ]
      },
      "governance": {
        "owner": "devops-team",
        "approvedDate": "2026-04-20",
        "nextReviewDate": "2026-07-20",
        "riskLevel": "medium",
        "dataClassification": "confidential",
        "restrictions": ["read-only for non-owned repos"]
      }
    }
  ]
}

이 JSON이 S3에 저장되고 CloudFront를 통해 배포됩니다. Kiro Admin Console에서 설정한 MCP Registry URL이 바로 이 파일을 가리킵니다.

설정 관리: enterprise-aidlc-config 프로젝트

Compliance MCP가 제공하는 도구들과 정책은 enterprise-aidlc-config 프로젝트에서 관리됩니다. 이 프로젝트는 단일 소스에서 여러 AI 도구별 형식으로 변환하는 구조입니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
enterprise-aidlc-config/
├── version.json              ← 전체 버전 관리
├── source/                   ← YAML 기반 단일 소스 (Single Source of Truth)
│   ├── registry.yaml         ← MCP Registry 정의
│   ├── agents.yaml           ← Custom Agents 정의
│   ├── steering.yaml         ← AI-DLC Workflow 규칙
│   ├── skills/               ← Custom Skills (code-review, api-design 등)
│   └── extensions/           ← AI-DLC Extension
└── generated/                ← 도구별 변환 결과
    ├── kiro/                 ← Kiro 형식 (.kiro/ 구조)
    │   ├── registry.json     ← CloudFront로 배포되는 Registry
    │   ├── manifest.json     ← 전체 파일 목록
    │   └── version.json
    └── other tools...

핵심 설계 원칙: 정책과 설정을 YAML 한 곳에서 관리하고, Generator가 각 AI 도구 형식에 맞게 변환합니다. Kiro의 경우 generated/kiro/registry.json이 S3에 업로드되고 CloudFront를 통해 배포됩니다. 이것이 바로 Admin Console에 설정하는 Registry URL의 원본입니다.

버전 관리와 데이터 흐름

설정의 버전은 version.json에서 중앙 관리됩니다:

1
2
3
4
5
6
7
8
9
10
11
{
  "version": "1.0.0",
  "updatedAt": "2026-06-30",
  "components": {
    "workflow": "2.3.0",
    "steering": "1.0.0",
    "extensions": "1.0.0",
    "agents": "1.0.0",
    "registry": "1.0.0"
  }
}

개발자가 세션을 시작할 때 check_all 또는 get_latest_config 도구를 호출하면, MCP Lambda가 DynamoDB에 저장된 최신 버전과 비교합니다. 로컬 설정이 오래된 경우 업데이트를 안내합니다.

1
2
3
4
5
6
7
[source/YAML] → [Generator] → [generated/kiro/] → [S3] → [CloudFront]
                                                              ↓
                                                  [Kiro Admin Console에 URL 등록]
                                                              ↓
                                              [개발자 IDE: Registry에 등록된 MCP만 표시]

[source/YAML 변경] → [DynamoDB 버전 업데이트] → [개발자 세션 시작 시 버전 체크]

이 구조의 장점:

한 곳에서 수정하면 모든 AI 도구에 반영 (Kiro뿐 아니라 Cursor, Claude Code 등도 지원 가능)
버전으로 변경 이력 추적 가능
DynamoDB에 Compliance 확인 이력이 저장되어 "누가 언제 어떤 버전을 사용했는지" 감사 추적 가능

3. 관리자 흐름: MCP Registry 구성 및 운영

Admin Lambda 정책 업데이트 흐름

① Admin API 호출 (GitHub Actions 등으로 자동화 가능)

② DynamoDB에 표준 워크플로우 및 정책 업데이트

③ S3에 MCP Registry(registry.json) 업데이트

④ CloudFront 캐시 무효화 (Kiro Admin에 설정한 Registry URL이 즉시 반영)

Admin Console에서 MCP Registry URL 설정

Kiro Admin Console (AWS Console > Kiro > Settings) 에서 MCP Registry URL을 설정할 수 있습니다.

이 URL은 이 편에서 구축한 CloudFront 배포 주소를 가리킵니다: https://{distribution}.cloudfront.net/generated/kiro/registry.json

이 URL이 가능한 이유: registry.json을 S3에 호스팅하고 CloudFront로 배포했기 때문입니다. WAF에서 사내망 IP만 허용하므로 외부에서는 접근 불가합니다.

승인 운영 프로세스

레지스트리는 한 번 만들고 끝나는 것이 아닙니다. 새로운 MCP 요청을 처리하는 운영 프로세스가 있어야 합니다.

운영 프로세스 예시:

단계	담당	활동
1. 요청	개발자	필요한 외부 MCP와 사용 목적을 플랫폼 팀에 제출
2. 검토	플랫폼/보안 팀	데이터 흐름, 권한 범위, 라이선스, 공급사 신뢰도 평가
3. 승인	플랫폼 팀	레지스트리에 추가 (또는 거절 사유 회신)
4. 배포	자동화(GitOps)	변경이 전 조직에 전파
5. 주기 점검	플랫폼/보안 팀	승인된 MCP의 업데이트·동작 변화 재검토 (분기별)

이 프로세스는 "사람의 판단(검토/승인)"과 "기계적 배포(레지스트리+GitOps)"를 결합합니다. 사람은 새로운 도구의 위험을 평가하는 가치 있는 판단에 집중하고, 일단 승인된 후의 일관된 적용은 자동화가 담당합니다. 이것이 휴먼 인 더 루프와 하네스의 역할 분담입니다.

이 URL은 앞서 구축한 CloudFront 배포 주소를 가리킵니다: https://{distribution}.cloudfront.net/generated/kiro/registry.json

이 URL이 가능한 이유: registry.json을 S3에 호스팅하고 CloudFront로 배포했기 때문입니다. WAF에서 사내망 IP만 허용하므로 외부에서는 접근 불가합니다.

4. 개발자 흐름: MCP Registry 사용

MCP Lambda 도구 호출 흐름

개발자가 Kiro에서 AI-DLC 워크플로우를 실행할 때, compliance-mcp의 도구들이 호출됩니다:

① 프로젝트 시작 시 Compliance MCP를 통해 워크플로우 규정 준수 확인

② Compliance MCP를 통해 워크플로우 및 설정 준수 확인

③ DynamoDB에 Compliance 확인 이력 저장 (프로젝트/유저 단위 정챙 위반 이력 기록)

④ AI-DLC Workflow가 사내 Knowledge Base를 참조하여 동작

주요 MCP Tools:

check_all: 전체 컴플라이언스 항목(steering, extensions, mcp config, agents, workflow version) 검증
search_knowledge: 사내 Knowledge Base 시맨틱 검색
get_standard: 특정 사내 표준 문서 조회
list_available_mcps: 승인된 MCP 서버 목록 조회
get_latest_config: 최신 프로젝트 설정 다운로드

개발자에게는 어떻게 보이는가

Organization 레벨에서 MCP Registry가 설정되면, 개발자의 Kiro IDE에서는 다음과 같이 사용 가능한 MCP만 표시됩니다.

Kiro CLI를 사용하는 경우에도 MCP Registry를 조회하고 설치할 수 있습니다.

해당 MCP를 선택 후 [OK] 버튼을 선택하면, MCP Registry에 등록된 MCP가 자동으로 설치됩니다.

설치가 완료되면, MCP 목록에 compliance-mcp가 설치된 것을 확인할 수 있으며, 사용 가능한 모든 도구들이 표시 됩니다.

이 때, Registry에 등록된 MCP만 표시됩니다.

개발자의 로컬 환경에 mcp.json이 존재 하더라도, Registry에 없으면 사용할 수 없습니다.
"19 servers hidden MCP Registry active"와 같이 승인되지 않은 MCP는 숨겨집니다.

일반적으로 AI 코딩 도구에서는 규칙 파일 등으로 특정 MCP 사용을 가이드할 수는 있지만, 강제할 수는 없습니다. 개발자가 무시하면 그만이기 때문입니다. Kiro Enterprise의 MCP Registry는 이를 아키텍처 수준에서 해결하며, allowlist에 없는 MCP는 연결 자체가 차단됩니다.

MCP 사용 예시

MCP 연동이 완료되면, 다음과 같이 필요한 때에 사내 지식을 검색하여 표준 및 정책이 프로젝트에 적용하도록 수 있습니다.

Registry의 위치: 정의와 강제의 구분

이 편에서 구축한 Approved MCP Registry는 "어떤 MCP를 허용할지"의 정의이자, S3+CloudFront 인프라를 통한 배포 메커니즘입니다. Kiro Admin Console에서 이 CloudFront URL을 MCP Registry로 등록하면, 아키텍처 수준에서 강제됩니다.

이 Registry를 Kiro Enterprise에서 조직 정책으로 활용하는 상세 설정(Organization 레벨 정책, 하위 조직 상속, 예외 처리 등)은 3편에서 다룹니다.

다중 계층 보안

사내 MCP 거버넌스는 여러 보안 계층과 함께 동작할 때 효과적입니다. 본 프로젝트와 같이 단일 계층에 의존하지 않고 여러 계층을 두면, 한 계층이 뚫려도 다른 계층이 방어합니다.

Architecture Detail_Multi Layer Security

계층	메커니즘	방어 대상	실패 시 영향
네트워크	AWS WAF (사내망 IP만 허용)	외부에서의 직접 접근	다른 계층이 인증으로 차단
인증	AWS IAM Identity Center (SSO)	미인가 사용자	네트워크 계층이 1차 차단
전송 암호화	TLS 1.2+ (전송 중 암호화)	통신 도청	네트워크 내부이므로 영향 제한
저장 암호화	AWS KMS (고객 관리형 키)	저장 데이터 노출	접근 제어가 데이터 보호
감사	AWS CloudTrail + CloudWatch	사후 추적·이상 탐지	다른 계층이 사전 차단

각 계층은 독립적으로 동작하면서도 전체로서 심층 방어(Defense in Depth)를 구성합니다. WAF가 사내망 IP만 허용하므로, 사내 MCP는 외부 인터넷에서 접근할 수 없습니다. 모든 요청은 TLS 1.2 이상으로 암호화되며, CloudTrail로 모든 API 호출을 감사할 수 있습니다.

네트워크 수준 접근 제어

위 아키텍처에서 네트워크 계층의 보호는 두 가지 핵심 구성 요소에 각각 적용됩니다.

Architecture Detail_Access Control and Network Security

구성 요소	접근 제한	메커니즘
MCP Registry (registry.json)	사내망 IP에서만 접근 가능	CloudFront + WAF (IP allowlist)
Compliance MCP 도구 호출	사내망 IP에서만 호출 가능	API Gateway + WAF (IP allowlist)

MCP Registry는 S3에 저장된 JSON 파일을 CloudFront로 배포하되, WAF에서 사내망 IP 대역만 허용한다. 외부에서는 Registry 내용 자체를 열람할 수 없으므로, 사내 MCP 정책(어떤 MCP가 승인되었는지, 어떤 엔드포인트를 사용하는지)이 외부에 노출되지 않는다.

Compliance MCP 서버(API Gateway + Lambda)도 동일하게 WAF에서 사내망 IP만 허용한다. MCP 도구를 실제로 호출하는 행위 자체가 사내망에서만 가능하므로, 외부에서 MCP 도구를 악용하거나 정책을 우회할 경로가 원천 차단된다.

전체 흐름: 개발자 관점에서 보기

실제 개발자가 경험하는 전체 흐름을 정리해 보면 다음과 같습니다.

순서	단계	동작	MCP 도구
1	세션 시작	MCP Registry에 의해 승인된 MCP만 사용 가능	—
2	프로젝트 검증	워크플로우/설정이 조직 표준과 일치하는지 확인	check_all
3	규정 위반 처리	DynamoDB에 로깅 + 최신 설정 자동 다운로드	get_latest_config
4	Inception	요구사항/설계 시 사내 표준 참조	search_knowledge
5	Construction	코드 생성 중 사내 규칙 실시간 검색	search_knowledge
6	코드 리뷰	규정 준수 최종 확인 + 결과 기록	check_compliance

개발자 입장에서는 평소처럼 코드를 작성할 뿐입니다. 거버넌스와 보안 검증은 백그라운드에서 자동으로 이루어집니다. 이와 같이 Knowledge Base와 Compliance MCP 구축을 통해 개발자의 생산성을 유지하면서도 조직의 규칙을 자동으로 준수할 수 있습니다.

핵심 정리

이 편에서는 Compliance MCP 서버를 구축하고, Approved MCP Registry로 허용 목록을 정의하는 방법을 다뤘습니다. Registry를 호스팅하는 인프라(S3 + CloudFront + WAF)를 구축했고, 이를 Kiro Enterprise Admin Console에 등록하면 개발자 IDE에서 승인된 MCP만 사용할 수 있도록 강제됩니다.

문제	해법	핵심 메커니즘
데이터 경로 불투명	사내 MCP 서버	사내망 안에서만 동작, CloudTrail 감사
도구 동작 불일치	Approved MCP Registry	단일 승인 목록 + MCP Registry 강제
공급망 리스크	검토·승인 프로세스	사람의 판단 + 주기적 재검토
설정 동기화	GitOps 배포	세션 시작 시 자동 동기화

결론

AI 코딩 도구의 진정한 가치는 속도가 아니라, 조직의 표준을 일관되게 적용하면서도 속도를 유지하는 데 있습니다. Compliance MCP와 MCP Registry는 그 균형점을 만드는 인프라입니다. 3편에서는 이 MCP 통제를 포함한 Kiro Enterprise의 전체 거버넌스 기능을 살펴봅니다.

다음 단계

이 편은 MCP 통제까지를 범위로 합니다. 3편에서는 이를 넘어 Kiro Enterprise의 조직 거버넌스(모델 통제, 프롬프트 로깅, 네트워크 보안, Organization 레벨 정책 상속 등)를 다룹니다.

# ai-dlc # ai-for-developers # kiro # software-development # developer-tools

Series: AI-DLC for Enterprise (4 articles)

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

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 (2): MCP Server로 도구 통제하기

Series: AI-DLC for Enterprise (4 articles)

Suyeon Kim

서론: "MCP, 연결은 쉬운데 통제는 어렵다"

통제 없는 MCP 사용의 3가지 시나리오

[시나리오 1] 데이터 경로의 불투명성

[시나리오 2] 도구 동작의 불일치

[시나리오 3] MCP 공급망 리스크

Compliance MCP 서버 아키텍처

전체 아키텍처 (파란색 영역)

주요 구현 사항

Kiro MCP Governance

Kiro MCP Registry 형식

설정 관리: enterprise-aidlc-config 프로젝트

버전 관리와 데이터 흐름

3. 관리자 흐름: MCP Registry 구성 및 운영

Admin Lambda 정책 업데이트 흐름

Admin Console에서 MCP Registry URL 설정

4. 개발자 흐름: MCP Registry 사용

MCP 사용 예시

다중 계층 보안

네트워크 수준 접근 제어

전체 흐름: 개발자 관점에서 보기

핵심 정리

결론

다음 단계

Series: AI-DLC for Enterprise (4 articles)