AI-DLC for Enterprise (1): Bedrock Knowledge Bases로 사내 지식 연결하기

AI-DLC 워크플로우에서 AI가 사내 코딩 표준과 규칙을 자동으로 참조할 수 있도록 Amazon Bedrock Knowledge Bases를 구성하고 연결하는 방법을 다룹니다.

Series: AI-DLC for Enterprise (4 articles)

1
AI-DLC for Enterprise: 거버넌스 아키텍쳐 가이드
2
AI-DLC for Enterprise (1): Bedrock Knowledge Bases로 사내 지식 연결하기 This article
3
AI-DLC for Enterprise (2): MCP Server로 도구 통제하기

Suyeon Kim

Published Jul 8, 2026

Last modified Jul 9, 2026

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

AI-Driven Development Lifecycle(AI-DLC)는 AI를 개발 라이프사이클의 핵심 협업자로 두는 방법론입니다. 자세한 소개는 AI-DLC 공식 사이트 와 원본 블로그 를 참고하세요. 이 시리즈에서는 AI-DLC를 엔터프라이즈 환경에 적용하는 구체적인 방법을 다룹니다.

서론: "AI가 우리 회사를 몰라요"

AI 코딩 도구를 써보셨다면, 이런 경험 한 번쯤 있으실 겁니다:

AI가 생성한 코드가 돌아가긴 하는데, 팀의 코딩 컨벤션과 완전히 다른 스타일이다.
매번 프롬프트에 회사 규칙을 붙여넣는 건 현실적이지 않다.
Confluence에 수백 개의 표준 문서가 있는데, AI는 그 존재조차 모른다.

많은 팀이 같은 문제에 직면합니다. AI-DLC 워크플로우를 도입해서 코드 생성 속도는 빨라졌는데, 생성된 코드가 사내 코딩 표준을 전혀 모르는 겁니다. 결국 사람이 전부 고치는 상황이 발생합니다.

이 문제를 **"지식 단절(Knowledge Disconnect)"**이라고 합니다. 조직 단위로 AI 도구를 도입할 때, 코드 품질과 신뢰성에 대한 우려가 가장 큰 장벽이 되는 근본 원인이기도 합니다. AI가 일반적인 모범 사례는 잘 따르지만, 조직 고유의 결정, 예를 들면, "금액은 정수 원(KRW) 단위로만", "모든 외부 API에 3초 타임아웃 + 지수 백오프" 같은 규칙은 가르쳐주지 않으면 알 수 없습니다.

이 문제는 사내 지식을 AI가 자동으로 참조할 수 있는 구조를 만들어 해결할 수 있습니다. 이 글에서는 그 구체적인 구축 방법을 다룹니다. Amazon Bedrock Knowledge Bases를 사용해 사내 지식을 AI가 검색 가능한 형태로 만들고, AI-DLC 워크플로우에 자동으로 연결하기 위한 전체 과정을 다룹니다.

전체 아키텍쳐

전체 아키텍쳐에 대한 개요는 AI-DLC for Enterprise: 거버넌스 아키텍쳐 가이드 를 참조 하세요.

이 시리즈는 AI-DLC를 엔터프라이즈에 적용하기 위한 5개 빌딩 블록 중 첫 번째 블록인 Knowledge Base 를 다루며(파란색 영역), 사내 표준을 AI가 코드 생성 시점에 자동으로 참조할 수 있게 만드는 기반 인프라에 집중합니다.

전체 흐름을 한눈에 보면 다음과 같습니다.

다이어그램에서 볼 수 있듯이 사내 표준이나 지식 등을 포함한 수많은 문서들을 쉽게 검색하고 참조할 수 있도록 하기 위해 Amazon Bedrock Knowledge Bases 를 사용할 수 있습니다.

문서가 Knowledge Base로 수집되는 과정(왼쪽→오른쪽)과, 개발자가 코드를 생성할 때 표준을 검색하는 과정(오른쪽→왼쪽)이 분리되어 있습니다. 전자는 문서가 추가/변경될 때만 실행되고, 후자는 개발자가 코드를 짤 때마다 실행됩니다.

Amazon Bedrock Knowledge Bases란?

Amazon Bedrock Knowledge Bases 는 완전 관리형 RAG(Retrieval Augmented Generation) 서비스입니다. 엔터프라이즈 데이터 소스를 연결하면, 문서 수집(Ingestion)부터 벡터 저장, 검색 최적화까지의 전체 파이프라인을 자동으로 처리할 수 있습니다.

본 시리즈에서는 데이터소스로는 Confluence라고 가정하고, Vector Store로는 Amazon OpenSearch Serverless 를 사용하였습니다.

핵심 특징은 다음과 같습니다.

기능	설명
완전 관리형 파이프라인	문서 파싱 → 청킹 → 임베딩 → 벡터 저장까지 자동화. 커스텀 파이프라인 개발 불필요
다양한 데이터 소스	S3, Confluence, SharePoint, Google Drive, OneDrive, Web Crawler 등 직접 연결 가능
파싱 모델 선택	기본 파서 또는 Foundation Model 파서(Amazon Nova, Claude 등)로 이미지/표 포함 멀티모달 문서 처리
청킹 전략	고정 크기, 시멘틱, 계층형 청킹 중 선택 가능
메타데이터 필터링	JSON 메타데이터를 기반으로 검색 범위를 좁혀 정확도 향상
벡터 스토어	Amazon OpenSearch Serverless, Aurora, Pinecone 등 선택 가능

즉, 일반적인 RAG 시스템을 구축할 때 필요한 임베딩 파이프라인, 벡터 DB 관리, 검색 API 구현 등을 모두 관리형으로 제공하기 때문에, 검색 인프라 구축이 아닌 "어떤 문서를, 어떻게 구조화할 것인가"에 집중할 수 있습니다.

이 글에서는 이 서비스를 활용해 사내 코딩 표준을 AI-DLC 워크플로우에 연결하는 구체적인 방법을 다룹니다.

상세 문서: How Amazon Bedrock Knowledge Bases work | 공식 제품 페이지

상세 아키텍쳐: Knowledge Pipeline

왜 파이프라인이 필요한가

"Confluence 커넥터를 직접 연결하면 되지 않나요?" — 맞습니다. Bedrock KB는 Confluence 커넥터를 네이티브로 지원합니다. 하지만 엔터프라이즈 환경에서는 몇 가지 이유로 커스텀 파이프라인을 구성하는 것이 유리합니다:

PII 마스킹: 사내 문서에 개인정보(이메일, 전화번호)가 포함된 경우, 수집 전에 Bedrock Guardrails로 마스킹해야 합니다
선별적 수집: 수천 개의 Confluence 페이지 중 코딩 표준 관련 페이지만 골라서 수집
메타데이터 자동 부여: 도메인, 언어, 포맷 정보를 자동으로 태깅
변경 감지 최적화: 변경된 페이지만 증분 처리하여 비용 절감

위 예시의 파이프라인은 다음과 같이 동작합니다.

EventBridge Rule을 통해 주기적으로 Knowledge Base 구성 워크플로우 실행
StepFunctions에서는 Confluence 문서 변경 사항 조회 (변경사항 없을시 종료)
StepFunctions의 Map State 를 사용하여 추가 및 변경된 문서별 병렬 처리 (부분 실패 시 해당 문서만 재시도)

1) 다향한 형식을 포함한 문서 Export (표/이미지 포함)

2) Bedrock Guardrails(ApplyGuardrail)를 통해 민감정보 감지 및 Masking

3) 메타데이터 JSON 생성 및 S3 업로드

- 태깅된 메타데이터는 추후 지식 검색시 메타데이터 필터링 기능에 사용할 수 있으며, 검색 속도와 정확도를 높이는데 도움을 줍니다.

Bedrock Knowledge Base에 지식 동기화
Bedrock Knowledge Base에서 자동으로 OpenSearch Serverless Vector Store 업데이트

핵심 구현: Map State로 병렬 처리

Step Functions의 Map State가 이 파이프라인의 핵심입니다. 변경된 페이지가 50개든 500개든, 각 문서를 독립적으로 병렬 처리합니다.

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
{
  "Type": "Map",
  "ItemsPath": "$.changedPages",
  "MaxConcurrency": 10,
  "Iterator": {
    "StartAt": "ExportPage",
    "States": {
      "ExportPage": {
        "Type": "Task",
        "Resource": "arn:aws:lambda:{region}:{account-id}:function:export-confluence-page",
        "Next": "PreProcess"
      },
      "PreProcess": {
        "Type": "Task",
        "Resource": "arn:aws:lambda:{region}:{account-id}:function:preprocess-document",
        "Next": "ApplyGuardrail"
      },
      "ApplyGuardrail": {
        "Type": "Task",
        "Resource": "arn:aws:states:::bedrock:applyGuardrail",
        "Parameters": {
          "GuardrailIdentifier": "arn:aws:bedrock:{region}:{account-id}:guardrail/abc123",
          "GuardrailVersion": "1",
          "Source": "INPUT",
          "Content": [
            {
              "Text": {
                "Text.$": "$.documentContent"
              }
            }
          ]
        },
        "Next": "UploadToS3"
      },
      "UploadToS3": {
        "Type": "Task",
        "Resource": "arn:aws:lambda:{region}:{account-id}:function:upload-to-s3",
        "End": true
      }
    }
  }
}

PII 마스킹: Bedrock Guardrails 활용

사내 문서에 개인정보(담당자 이메일, 전화번호 등)가 포함되는 경우가 많습니다. Bedrock Guardrails의 ApplyGuardrail API를 Step Functions에서 직접 호출하면, Lambda 함수 없이도 PII를 마스킹할 수 있습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Lambda에서 직접 호출하는 경우의 예시
import boto3

bedrock_runtime = boto3.client("bedrock-runtime")

response = bedrock_runtime.apply_guardrail(
    guardrailIdentifier="abc123",
    guardrailVersion="1",
    source="INPUT",
    content=[{"text": {"text": document_content}}]
)

# 마스킹된 결과 추출
masked_content = response["outputs"][0]["text"]

Tip: Guardrails의 Sensitive Information Filter에서 PII 유형별로 ANONYMIZE(익명화) 또는 BLOCK(차단)을 선택할 수 있습니다. 코딩 표준 문서에서는 이메일/전화번호만 ANONYMIZE하고, 나머지는 그대로 두는 것이 검색 품질에 유리합니다.

EventBridge Rule: 트리거 설정

1
2
3
4
5
6
7
8
9
10
{
  "ScheduleExpression": "cron(0 0 * * ? *)",
  "Description": "Knowledge Pipeline will be triggered daily at 09:00 KST",
  "Targets": [
    {
      "Arn": "arn:aws:states:{region}:{account-id}:stateMachine:knowledge-pipeline",
      "RoleArn": "arn:aws:iam::{account-id}:role/eventbridge-sfn-role"
    }
  ]
}

Confluence webhook을 연결하면 페이지 저장 즉시 트리거할 수도 있지만, 일 1회 배치가 더 적합한 경우가 많습니다. 이유는:

표준 문서는 하루에 수십 번 수정되지 않음
실시간 동기화 시 한 페이지를 여러 번 수집하는 비용 낭비 발생
새벽에 동기화하면 아침 출근 시 최신 표준이 반영됨

검색 품질 높이기 — Parser, Chunking, Embedding, Metadata

Knowledge Pipeline으로 문서를 S3에 올렸으면, 이제 Bedrock KB가 이를 벡터로 변환합니다. 이 과정의 설정이 검색 품질을 좌우합니다.

데이터 소스 옵션

데이터 소스	연결 방식	적합한 경우
Amazon S3	버킷의 문서 파일 직접 수집	커스텀 파이프라인 사용 시 (이 구축의 선택)
Confluence 커넥터	네이티브 커넥터로 스페이스/페이지 동기화	단순 구성, PII 이슈 없는 경우
웹 크롤러	사내 포털·문서 사이트 URL 크롤링	사내 개발자 포털이 웹으로 운영되는 경우
SharePoint 등	각 커넥터로 동기화	해당 SaaS에 문서가 있는 경우

이 구축에서는 Confluence에서 Step Functions를 거쳐 S3에 정제된 문서를 올리는 방식을 사용합니다. PII 마스킹과 메타데이터 자동 부여가 가능하기 때문입니다.

Parser 선택: 기본 vs Foundation Model

파서 유형	처리 방식	적합한 문서
기본 파서	텍스트 레이어만 추출	순수 텍스트 Markdown, 단순 PDF
Foundation Model 파서	이미지·표·다이어그램을 모델이 해석해 텍스트화	아키텍처 문서, 표 많은 규정집

본 프로젝트에서는 아래와 같이 Parser 옵션을 선택하였습니다.

Markdown 형식: 기본 파서 (텍스트 위주)
PDF 등의 아키텍쳐 문서: Foundation Model Parser (다이어그램, 표 해석 필요)

프로젝트에 사용된 Knowledge 문서 예시:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
knowledge-source/
  ├── api-design-guide.md
  ├── api-specification.pdf
  ├── architecture-standards.pdf
  ├── backend-standards.pdf
  ├── code-review-checklist.md
  ├── coding-standards.pdf
  ├── data-privacy-policy.md
  ├── frontend-standards.pdf
  ├── git-branching-strategy.md
  ├── incident-response-guide.md
  ├── infrastructure-standards.md
  ├── reference-architecture.pdf
  ├── security-checklist.txt
  ├── security-policy.pdf
  ├── testing-standards.md
  └── user-story-guide.md

S3에 문서를 또한, 아래와 같이 S3 접두사를 사용하여 문서의 유형을 분리하면, 위와 같이 각각 다른 파서를 사용할 수 있습니다.

Tip: 모든 문서에 FM 파서를 쓰면 비용이 급증합니다. S3 접두사별로 데이터 소스를 분리해서 각각 다른 파서를 적용하면 비용을 절감할 수 있습니다:

s3://kb-bucket/coding/ → 기본 파서 데이터 소스
s3://kb-bucket/architecture/ → FM 파서 데이터 소스

Chunking 전략

청킹 전략	동작	판단 기준
고정 크기	N 토큰마다 기계적으로 분할	규칙 중간이 잘릴 위험
시멘틱 청킹	의미가 연결된 문장끼리 묶음	코딩 표준에 최적
계층적 청킹	부모-자식 청크로 구조 보존	복잡하지만 장문 설계 문서에 유리

코딩 표준처럼 "각 규칙이 독립된 항목"으로 구성된 문서에는 시멘틱 청킹이 가장 적합합니다. 예를 들어 보안 체크리스트가 이런 식일 때:

1
2
3
4
5
6
7
8
9
### 1.1 SQL 인젝션 방지
- 모든 SQL은 파라미터 바인딩 사용
- 문자열 연결(concatenation)로 쿼리 구성 금지
- 이유: SQL 인젝션 공격 방지

### 1.2 사용자 입력 검증
- 모든 사용자 입력은 서버 사이드에서 검증
- 클라이언트 검증만으로는 불충분
- 허용된 문자 세트를 화이트리스트로 정의

고정 크기 청킹(예: 300 토큰)은 1.1과 1.2 사이를 잘라버릴 수 있습니다. 그러면 "입력 검증"을 검색했을 때 항목의 절반만 반환됩니다. 시멘틱 청킹은 의미 단위(=각 규칙)로 묶으므로 한 항목이 온전히 한 청크에 담깁니다.

청크 크기 경험치:

항목이 짧고 명확한 표준 문서: 300~500 토큰
맥락이 길게 이어지는 설계 문서: 800~1,000 토큰

Embedding 모델: Amazon Titan Text Embeddings v2

1
2
3
모델: amazon.titan-embed-text-v2:0
차원: 1024 (production) / 512 (dev/test)
특성: 다국어 지원 (한·영·일 혼합 문서 대응)

차원	정밀도	저장 비용	권장 용도
256	○	최소	PoC, 소규모 문서
512	◎	중간	개발/테스트 환경
1,024	◉	최대	프로덕션 (이 구축의 선택)

Tip: Titan Embeddings v2는 100+ 언어를 지원합니다. 한국어 표준 문서와 영어 표준 문서를 같은 임베딩 공간에 두면, 한국어로 검색해도 의미가 통하는 영어 문서를 찾을 수 있습니다. 글로벌 조직에서 특히 유용합니다.

메타데이터 설계: 검색 범위를 좁히는 핵심

문서를 S3에 올릴 때, 접두사(prefix) 구조와 메타데이터를 함께 설계합니다:

1
2
3
4
5
6
7
8
9
S3 접두사: {domain}/{language}/{format}/{filename}

예시:
  security/ko/md/coding-standards.md
  security/ko/md/coding-standards.md.metadata.json
  architecture/en/pdf/microservice-patterns.pdf
  architecture/en/pdf/microservice-patterns.pdf.metadata.json
  payment/ja/pdf/settlement-policy.pdf
  payment/ja/pdf/settlement-policy.pdf.metadata.json

각 문서에는 동일한 이름에 .metadata.json을 붙인 메타데이터 파일을 함께 둡니다:

1
2
3
4
5
6
7
8
9
10
{
  "metadataAttributes": {
    "domain": "security",
    "language": "ko",
    "format": "markdown",
    "version": "2.1.0",
    "region": "APAC",
    "last_updated": "2026-06-15"
  }
}

왜 이렇게까지?

17개의 사내 표준 문서를 도메인(security, api, architecture, infrastructure, coding, process)으로 태깅한 KB에서, 동일한 질의 "입력 검증 방법"을 필터 유무에 따라 검색한 실제 결과입니다:

검색 조건	반환된 문서	특징
필터 없음	testing-standards, api-design-guide, security-checklist, user-story-guide	4개 도메인 혼재 — 절반이 노이즈
domain=security	security-checklist, data-privacy-policy, security-policy, incident-response-guide	보안 문서만 정확히 반환 ✅
domain=coding	testing-standards, code-review-checklist, backend-standards	코딩 문서만 정확히 반환 ✅

필터가 주는 효과:

정확도 향상: 관련 없는 문서 배제
비용 절감: AI 컨텍스트에 들어가는 토큰량 감소
속도 개선: 더 적은 문서에서 검색

MCP를 사용하여 AI-DLC 워크플로우에 연결

Knowledge Base를 구성했다면, 이제 AI 코딩 도구가 이를 자동으로 활용하도록 연결합니다.

MCP 도구 구현

Model Context Protocol(MCP) 을 사용하면 AI가 Knowledge Base를 검색하는 도구를 표준화된 방식으로 호출할 수 있습니다. Knowledge Base에서 지식을 검색할 수 있는 search_knowledge라는 도구를 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
50
51
52
53
54
55
56
# mcp_server/tools/search_knowledge.py
import boto3
from typing import Optional

agent_runtime = boto3.client("bedrock-agent-runtime", region_name="{region}")

KNOWLEDGE_BASE_ID = "ABCDEFGHIJ"  # 실제 KB ID로 교체

def search_knowledge(
    query: str,
    domain: Optional[str] = None,
    language: Optional[str] = None,
    max_results: int = 5,
) -> list[dict]:
    """사내 코딩 표준과 설계 가이드를 검색합니다.

    Args:
        query: 검색할 내용 (자연어)
        domain: 도메인 필터 (security, api, architecture, coding, infrastructure, process)
        language: 언어 필터 (ko, en, ja)
        max_results: 반환할 최대 결과 수

    Returns:
        관련 문서 청크 목록 (텍스트, 출처, 유사도 점수 포함)
    """
    # 메타데이터 필터 구성
    filters = []
    if domain:
        filters.append({"equals": {"key": "domain", "value": domain}})
    if language:
        filters.append({"equals": {"key": "language", "value": language}})

    vector_config = {"numberOfResults": max_results}
    if filters:
        vector_config["filter"] = (
            filters[0] if len(filters) == 1 else {"andAll": filters}
        )

    # Bedrock KB Retrieve API 호출
    response = agent_runtime.retrieve(
        knowledgeBaseId=KNOWLEDGE_BASE_ID,
        retrievalQuery={"text": query},
        retrievalConfiguration={"vectorSearchConfiguration": vector_config},
    )

    # 결과 정형화
    results = []
    for r in response["retrievalResults"]:
        results.append({
            "text": r["content"]["text"],
            "source": r.get("location", {}).get("s3Location", {}).get("uri", ""),
            "score": r.get("score", 0),
            "metadata": r.get("metadata", {}),
        })

    return results

Steering으로 검색 타이밍 제어

도구를 만들었다면, AI가 적절한 시점에 이 도구를 호출하도록 안내해야 합니다. Kiro 의 Steering 기능을 사용합니다.

AI-DLC Workflow를 사용 중이라면, 다음과 같은 단계에서 search_knowledg를 호출하도록 Steering을 수정할 수 있습니다.

Inception Phase
- Requirements Analysis 단계: 질문지에 사내 지식 기반 추천 답변 작성
- Application Design 단계: 사내 표준 아키텍쳐 참고하여 설계 반영
Construction Phase
- Functional/Non Functional Design 단계: 사내 성능/보안 요건 충족하도록 반영
- Code Generation 단계: 코딩 표준 준수하도록 강제
- 코드 생성 완료 후 표준 준수 여부 검증 가능

위와 같이 동작하도록 Steering을 수정하면, AI-DLC Workflow는 다음과 같이 동작합니다.

1) Inception - Requirements Analysis

AI가 생성한 질문지에 사내 표준 기반의 권장 답변을 질문지에 추가로 작성해 줍니다.

MCP 호출 과정:

생성된 질문지:

2) Construction - Code Generation

Code Generation 단계에서도 AI가 자동으로 사내 표준 가이드를 적절히 참조하여 코드 구현 계획을 세웁니다.

MCP Call_Construction_Code Generation Summary

3) Construction - Code Review

Knowledge Base를 참조하여 코드 생성이 완료 되었으면, 사내 표준과 가이드에 맞게 코드가 생성되었는지 한번 더 자동으로 검증하도록 구성할 수도 있습니다.

Tip: 코드 리뷰를 위한 Skills를 만들어 두면, 원하는 때에 해당 Skill을 사용하여 언제든지 사내 표준 기반의 코드 리뷰를 수행할 수 있습니다.

[code-review.md]

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
---
name: code-review
description: 사내 지식을 참조하여 표준 기반 코드 리뷰 수행
---

# /code-review

사내 코딩 표준, API 가이드, 보안 체크리스트를 참조하여 코드를 리뷰합니다.

## Steps

1. 리뷰 대상 코드를 확인 (현재 파일 또는 선택 영역)
2. `search_knowledge` MCP tool로 해당 코드 도메인의 사내 표준 검색 (에러 처리, 네이밍, 보안, API 설계 등)
3. `search_knowledge` MCP tool로 보안 체크리스트 검색
4. 검색된 표준 대비 코드 비교
5. 결과를 아래 형식으로 보고:

```
## 📋 Code Review Results

### ✅ Compliant
- [표준 참조]: [준수 사항]

### ⚠️ Suggestions
- [표준 참조]: [개선 가능한 부분과 방법]

### ❌ Violations
- [표준 참조]: [위반 사항과 수정 방법]

### 🔒 Security
- [보안 체크리스트 항목]: [결과]
```

6. 각 위반 사항에 대해 수정된 코드 스니펫 제공

code-review Skill 호출:

코드 리뷰 결과:

운영 고려사항

Knowledge Base 동기화 주기

전략	구현	적합한 경우
일 배치	EventBridge cron (매일 00:00 UTC)	표준 문서 — 변경 빈도 낮음 (이 구축의 선택)
이벤트 기반	Confluence webhook → EventBridge	빈번히 업데이트되는 가이드
수동 트리거	관리자가 필요 시 실행	대규모 문서 구조 변경 시

표준 문서는 매일 바뀌지 않으므로 일 1회 배치로 충분합니다. 새벽에 동기화하면 아침 출근 시 최신 표준이 반영됩니다.

다국어 지원 (글로벌 조직)

Titan Embeddings v2의 다국어 지원 덕분에, 하나의 KB에서 한·영·일 문서를 함께 관리할 수 있습니다:

1
2
3
4
5
검색 질의 (한국어): "결제 금액 저장 방식"
반환 결과:
  1. [ko] backend-standards.md — "금액은 정수 원(KRW) 단위로 저장" (score: 0.92)
  2. [en] payment-standards.md — "Store amounts as integer cents" (score: 0.85)
  3. [ja] settlement-policy.pdf — "金額は整数円で保存" (score: 0.78)

메타데이터 language 필터를 사용하면 특정 언어 문서만 반환할 수도 있고, 필터 없이 검색하면 크로스 링구얼 검색이 됩니다. 조직의 상황에 따라 선택하면 됩니다.

검색 품질 튜닝 가이드

처음부터 완벽한 검색 품질이 나오지는 않습니다. 다음 순서로 튜닝합니다:

대표 질의 10~20개를 준비하고 기대 결과를 정의
검색해보고 관련 없는 문서가 섞이면 → 메타데이터 필터 강화
항목이 잘려서 반환되면 → 시멘틱 청킹으로 변경하거나 청크 크기 조정
표/다이어그램 내용이 검색되지 않으면 → 해당 문서에 FM 파서 적용
반환 결과가 너무 많거나 적으면 → numberOfResults 조정
유사도 점수가 전반적으로 낮으면 → 임베딩 차원 상향 고려

결론

사내 지식을 Bedrock KB로 통합하는 것은 AI-DLC 하네스(Harness)의 첫 번째 기둥입니다. 개발자는 평소대로 작업하지만, 백그라운드에서 조직의 표준이 자동으로 적용됩니다. 사람은 "표준을 지켰는가"가 아니라 "이 설계가 올바른가"라는 더 가치 있는 판단에 집중할 수 있게 됩니다.

구축 과정을 요약하면:

단계	핵심 결정	이 프로젝트의 선택
데이터 소스	직접 연결 vs 커스텀 파이프라인	Step Functions 파이프라인 (PII 마스킹 필요)
파서	기본 vs Foundation Model	문서 유형별 분리 적용
청킹	고정 vs 시멘틱 vs 계층적	시멘틱 (코딩 표준에 최적)
임베딩	차원 선택	1,024차원 (프로덕션 정밀도)
메타데이터	플랫 vs 구조적 접두사	{domain}/{language}/{format} + JSON
워크플로우 연결	수동 참조 vs 자동 검색	MCP + Steering 자동화

이 기반이 갖춰지면, AI는 "사내 표준을 몰라서" 잘못된 코드를 만드는 일이 줄어들고, 개발자는 표준 준수 여부 대신 설계의 올바름에 집중할 수 있습니다.

하지만 KB만으로는 충분하지 않습니다. AI가 표준을 참조하더라도 반드시 따르게 강제하려면? 그리고 허용된 작업만 수행하도록 거버넌스를 걸려면? 이것이 다음 편의 주제입니다.

다음 단계

직접 해보기:

사내 표준 문서 3~5개를 선정하여 S3에 업로드
Amazon Bedrock Knowledge Bases 시작하기 로 첫 KB 생성
시멘틱 청킹 + Titan Embeddings v2 (1024)로 구성
대표 질의 10개로 검색 품질 확인
MCP 서버에 search_knowledge 도구 구현

참고 자료:

이 글은 AI-DLC for Enterprise 시리즈의 Part 1입니다. 실제 구축 사례를 바탕으로 작성되었으며, 구체적인 수치와 비용은 2026년 7월 기준입니다. 최신 정보는 AWS 공식 문서를 참고하세요.

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

Series: AI-DLC for Enterprise (4 articles)

1
AI-DLC for Enterprise: 거버넌스 아키텍쳐 가이드
2
AI-DLC for Enterprise (1): Bedrock Knowledge Bases로 사내 지식 연결하기 This article
3
AI-DLC for Enterprise (2): MCP Server로 도구 통제하기

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 (1): Bedrock Knowledge Bases로 사내 지식 연결하기

Series: AI-DLC for Enterprise (4 articles)

Suyeon Kim

서론: "AI가 우리 회사를 몰라요"

전체 아키텍쳐

Amazon Bedrock Knowledge Bases란?

상세 아키텍쳐: Knowledge Pipeline

왜 파이프라인이 필요한가

핵심 구현: Map State로 병렬 처리

PII 마스킹: Bedrock Guardrails 활용

EventBridge Rule: 트리거 설정

검색 품질 높이기 — Parser, Chunking, Embedding, Metadata

데이터 소스 옵션

Parser 선택: 기본 vs Foundation Model

Chunking 전략

Embedding 모델: Amazon Titan Text Embeddings v2

메타데이터 설계: 검색 범위를 좁히는 핵심

MCP를 사용하여 AI-DLC 워크플로우에 연결

MCP 도구 구현

Steering으로 검색 타이밍 제어

운영 고려사항

Knowledge Base 동기화 주기

다국어 지원 (글로벌 조직)

검색 품질 튜닝 가이드

결론

다음 단계

Series: AI-DLC for Enterprise (4 articles)