Claude로 엔터프라이즈 RAG 시스템 구축하는 방법: 직원 질문에 답하는 지식 기반
사내 지식의 문제: 왜 RAG가 필요한가
대부분의 조직에서 지식은 흩어져 있다. 인사 규정은 Confluence에, 기술 문서는 Notion에, 계약 관련 정보는 Google Drive에, 프로젝트 히스토리는 Slack 스레드에 묻혀 있다. 신입 직원이 “유급휴가는 며칠인가요?” 같은 단순한 질문에 답을 찾으려면, 여러 시스템을 뒤지거나 옆자리 동료에게 물어봐야 한다.
이 문제에 대한 기존 해법은 대부분 부분적이다. 사내 위키를 만들면 문서가 금세 오래된 정보로 채워진다. 검색 시스템을 도입해도 키워드 매칭의 한계에 부딪힌다. “재택근무 정책”을 검색하면 “원격 근무 가이드라인”이라는 제목의 문서는 찾지 못한다.
RAG(Retrieval-Augmented Generation)는 이 문제를 근본적으로 해결한다. 사용자의 질문을 의미적으로 이해하고, 관련된 문서 조각을 벡터 유사도로 찾아내며, 그 문서를 근거로 자연어 답변을 생성한다. 키워드가 정확히 일치하지 않아도, 의미가 유사하면 찾아낸다.
이 글에서는 Claude API를 중심으로 엔터프라이즈급 RAG 시스템을 처음부터 끝까지 구축하는 과정을 안내한다. 단순한 개념 증명(PoC)이 아니라, 실제 직원들이 매일 사용할 수 있는 수준의 시스템을 목표로 한다.
아키텍처 개요
전체 구조
엔터프라이즈 RAG 시스템은 크게 두 개의 파이프라인으로 구성된다.
인덱싱 파이프라인(Indexing Pipeline): 문서를 수집하고, 전처리하고, 청킹하고, 임베딩하여 벡터 데이터베이스에 저장하는 오프라인 프로세스다. 새 문서가 추가되거나 기존 문서가 수정될 때 실행된다.
검색-생성 파이프라인(Retrieval-Generation Pipeline): 사용자 질문을 받아 관련 문서를 검색하고, Claude가 답변을 생성하는 온라인 프로세스다. 실시간으로 동작해야 하므로 지연 시간이 중요하다.
구성 요소를 나열하면 다음과 같다.
- 문서 커넥터: Confluence, Notion, Google Drive, SharePoint 등에서 문서를 가져오는 모듈
- 전처리기: PDF, DOCX, HTML, Markdown 등 다양한 형식에서 텍스트를 추출
- 청커(Chunker): 긴 문서를 적절한 크기의 조각으로 분할
- 임베딩 모델: 텍스트를 벡터로 변환 (Voyage AI, OpenAI Embeddings 등)
- 벡터 데이터베이스: 임베딩을 저장하고 유사도 검색을 수행 (Pinecone, Weaviate, Qdrant, pgvector 등)
- 검색기(Retriever): 사용자 질문과 관련된 문서 조각을 벡터 데이터베이스에서 가져오기
- 생성기(Generator): Claude API를 사용하여 검색된 문서를 바탕으로 답변 생성
- 평가기(Evaluator): 답변 품질을 모니터링하고 피드백을 수집
기술 스택 선택
임베딩 모델은 Voyage AI의 voyage-3를 권장한다. Anthropic이 공식적으로 추천하는 임베딩 모델이며, 다국어 성능이 우수하다. OpenAI의 text-embedding-3-large도 좋은 선택이다.
벡터 데이터베이스는 규모에 따라 선택한다. 소규모(문서 1만 건 미만)에서는 pgvector로 PostgreSQL에 통합하는 것이 관리 부담이 적다. 중규모(1만~100만 건)에서는 Pinecone이나 Weaviate의 매니지드 서비스가 편리하다. 대규모(100만 건 이상)에서는 Qdrant나 Milvus의 자체 호스팅을 고려한다.
생성 모델은 Claude Sonnet이 비용과 성능의 균형이 가장 좋다. 복잡한 기술 문서를 다루거나 추론이 필요한 답변에는 Claude Opus를 사용할 수도 있다.
문서 수집과 전처리
문서 커넥터
사내 문서는 다양한 시스템에 분산되어 있으므로, 각 시스템에 맞는 커넥터를 구현해야 한다.
from abc import ABC, abstractmethod
from dataclasses import dataclass
from datetime import datetime
@dataclass
class Document:
id: str
title: str
content: str
source: str # "confluence", "notion", "google_drive" 등
url: str # 원본 문서 링크
updated_at: datetime
metadata: dict # 부서, 태그, 접근 권한 등
class DocumentConnector(ABC):
@abstractmethod
def fetch_all(self) -> list[Document]:
"""모든 문서를 가져옵니다."""
pass
@abstractmethod
def fetch_updated_since(self, since: datetime) -> list[Document]:
"""특정 시점 이후 업데이트된 문서만 가져옵니다."""
pass증분 업데이트(fetch_updated_since)를 지원하는 것이 중요하다. 전체 문서를 매번 다시 인덱싱하면 비용과 시간이 낭비된다. 대부분의 경우 매일 한 번 증분 업데이트를 실행하면 충분하다.
텍스트 추출
PDF, DOCX, HTML 등 다양한 형식에서 텍스트를 추출해야 한다.
import fitz # PyMuPDF
from docx import Document as DocxDocument
from bs4 import BeautifulSoup
def extract_text(file_path: str, file_type: str) -> str:
if file_type == "pdf":
doc = fitz.open(file_path)
text = ""
for page in doc:
text += page.get_text() + "\n"
return text
elif file_type == "docx":
doc = DocxDocument(file_path)
return "\n".join([para.text for para in doc.paragraphs])
elif file_type == "html":
with open(file_path, "r", encoding="utf-8") as f:
soup = BeautifulSoup(f.read(), "html.parser")
# 스크립트, 스타일 태그 제거
for tag in soup(["script", "style", "nav", "footer"]):
tag.decompose()
return soup.get_text(separator="\n", strip=True)
elif file_type in ("md", "txt"):
with open(file_path, "r", encoding="utf-8") as f:
return f.read()
else:
raise ValueError(f"지원하지 않는 파일 형식: {file_type}")PDF 추출은 특히 까다롭다. 스캔된 PDF는 OCR이 필요하고, 표 형태의 데이터는 텍스트 추출 시 구조가 깨진다. 스캔 PDF가 많은 환경에서는 AWS Textract이나 Google Document AI 같은 전용 서비스를 사용하는 것이 좋다.
전처리
추출된 텍스트는 그대로 사용하기 어려운 경우가 많다. 기본적인 정제 작업을 수행한다.
import re
def clean_text(text: str) -> str:
# 연속된 공백과 빈 줄 정리
text = re.sub(r'\n{3,}', '\n\n', text)
text = re.sub(r' {2,}', ' ', text)
# 헤더/푸터 반복 패턴 제거 (PDF에서 흔히 발생)
lines = text.split('\n')
if len(lines) > 20:
# 첫 5줄과 마지막 5줄이 반복되면 제거
header_candidate = '\n'.join(lines[:3])
if text.count(header_candidate) > 2:
text = text.replace(header_candidate, '')
# 특수 문자 정규화
text = text.replace('\u200b', '') # zero-width space
text = text.replace('\xa0', ' ') # non-breaking space
return text.strip()청킹과 임베딩
청킹 전략
청킹은 RAG 시스템의 성능을 좌우하는 핵심 단계다. 너무 작게 자르면 맥락이 손실되고, 너무 크게 자르면 검색 정밀도가 떨어진다.
실무에서 가장 많이 사용되는 접근법은 의미 단위 분할(semantic chunking)이다. 문서의 구조(제목, 소제목, 문단)를 인식하여 의미 단위로 나누는 방식이다.
from dataclasses import dataclass
@dataclass
class Chunk:
id: str
document_id: str
content: str
metadata: dict # 제목, 섹션명, 위치 등
token_count: int
def chunk_by_sections(document: Document, max_tokens: int = 512, overlap_tokens: int = 50) -> list[Chunk]:
"""제목/소제목 기준으로 섹션을 나누고, 긴 섹션은 추가 분할합니다."""
sections = split_by_headings(document.content)
chunks = []
for section in sections:
section_tokens = count_tokens(section["content"])
if section_tokens <= max_tokens:
chunks.append(Chunk(
id=f"{document.id}_{len(chunks)}",
document_id=document.id,
content=section["content"],
metadata={
"title": document.title,
"section": section["heading"],
"source": document.source,
"url": document.url
},
token_count=section_tokens
))
else:
# 긴 섹션은 문단 단위로 추가 분할
sub_chunks = split_long_section(
section, max_tokens=max_tokens, overlap_tokens=overlap_tokens
)
chunks.extend(sub_chunks)
return chunksmax_tokens는 512가 일반적인 출발점이다. 임베딩 모델의 최대 입력 크기와 검색 정밀도를 모두 고려해야 한다. 짧은 FAQ 형태의 문서에는 256이 적합하고, 기술 명세서처럼 긴 단락이 많은 문서에는 1024까지 늘릴 수 있다.
overlap은 50~100토큰 정도로 설정한다. 경계에서 맥락이 잘리는 것을 방지하는 역할을 한다.
메타데이터의 중요성
청크에 풍부한 메타데이터를 첨부하는 것은 검색 품질을 높이는 숨겨진 열쇠다. 벡터 유사도만으로는 부족한 상황에서 메타데이터 필터링이 결정적인 차이를 만든다.
예를 들어, “마케팅팀 재택근무 정책”이라는 질문에 대해 벡터 검색이 전사 재택근무 정책과 마케팅팀 재택근무 정책을 모두 반환했다면, department 메타데이터로 마케팅팀 문서에 가중치를 줄 수 있다.
chunk_metadata = {
"title": "마케팅팀 원격 근무 가이드라인",
"section": "근무 시간 및 보고",
"department": "marketing",
"document_type": "policy",
"last_updated": "2026-02-15",
"access_level": "all_employees",
"source_url": "https://wiki.company.com/marketing/remote-work"
}임베딩 생성
import voyageai
voyage_client = voyageai.Client()
def embed_chunks(chunks: list[Chunk], batch_size: int = 128) -> list[list[float]]:
"""청크들을 벡터로 변환합니다."""
all_embeddings = []
for i in range(0, len(chunks), batch_size):
batch = chunks[i:i + batch_size]
texts = [c.content for c in batch]
result = voyage_client.embed(
texts,
model="voyage-3",
input_type="document"
)
all_embeddings.extend(result.embeddings)
return all_embeddingsinput_type 파라미터에 주의한다. 문서를 인덱싱할 때는 “document”를, 검색 질의를 임베딩할 때는 “query”를 사용한다. 이 구분이 검색 품질에 영향을 미친다.
벡터 저장소 구축
Pinecone 예시
from pinecone import Pinecone
pc = Pinecone(api_key="your-api-key")
index = pc.Index("company-knowledge-base")
def upsert_chunks(chunks: list[Chunk], embeddings: list[list[float]]):
"""청크와 임베딩을 벡터 데이터베이스에 저장합니다."""
vectors = []
for chunk, embedding in zip(chunks, embeddings):
vectors.append({
"id": chunk.id,
"values": embedding,
"metadata": {
**chunk.metadata,
"content": chunk.content, # 검색 결과에서 원문 접근용
"token_count": chunk.token_count
}
})
# Pinecone은 한 번에 100개까지 upsert 가능
for i in range(0, len(vectors), 100):
batch = vectors[i:i + 100]
index.upsert(vectors=batch)metadata에 content를 포함시키는 이유는, 검색 결과를 받은 후 별도의 데이터베이스 조회 없이 바로 원문에 접근하기 위해서다. 다만 메타데이터 크기 제한(Pinecone은 40KB)에 유의해야 한다.
인덱스 관리
문서가 수정되거나 삭제되면 벡터 데이터베이스도 동기화해야 한다.
def sync_document(document: Document):
"""문서의 변경사항을 벡터 데이터베이스에 반영합니다."""
# 기존 청크 삭제
existing_ids = get_chunk_ids_by_document(document.id)
if existing_ids:
index.delete(ids=existing_ids)
# 새로 청킹 및 임베딩
chunks = chunk_by_sections(document)
embeddings = embed_chunks(chunks)
# 저장
upsert_chunks(chunks, embeddings)검색 파이프라인
기본 검색
def retrieve(query: str, top_k: int = 5, filters: dict = None) -> list[dict]:
"""사용자 질문과 관련된 문서 조각을 검색합니다."""
# 질문을 벡터로 변환
query_embedding = voyage_client.embed(
[query],
model="voyage-3",
input_type="query"
).embeddings[0]
# 벡터 유사도 검색
search_params = {
"vector": query_embedding,
"top_k": top_k,
"include_metadata": True
}
if filters:
search_params["filter"] = filters
results = index.query(**search_params)
return [
{
"content": match.metadata["content"],
"score": match.score,
"metadata": match.metadata
}
for match in results.matches
]하이브리드 검색
벡터 유사도 검색만으로는 특정 키워드나 고유명사를 정확히 찾아내기 어렵다. 예를 들어 “HR-2024-015 문서”를 찾으려면 정확한 문자열 매칭이 필요하다. 이를 보완하기 위해 키워드 검색(BM25)과 벡터 검색을 결합하는 하이브리드 검색을 사용한다.
from rank_bm25 import BM25Okapi
class HybridRetriever:
def __init__(self, vector_index, chunks: list[Chunk]):
self.vector_index = vector_index
self.chunks = chunks
# BM25 인덱스 구축
tokenized = [self._tokenize(c.content) for c in chunks]
self.bm25 = BM25Okapi(tokenized)
def _tokenize(self, text: str) -> list[str]:
# 한국어는 형태소 분석기 사용 권장 (KoNLPy 등)
return text.split()
def search(self, query: str, top_k: int = 5, alpha: float = 0.7) -> list[dict]:
"""하이브리드 검색. alpha는 벡터 검색의 가중치 (0~1)"""
# 벡터 검색
vector_results = self._vector_search(query, top_k=top_k * 2)
# BM25 검색
bm25_results = self._bm25_search(query, top_k=top_k * 2)
# 점수 정규화 및 결합
combined = self._combine_scores(vector_results, bm25_results, alpha)
return sorted(combined, key=lambda x: x["score"], reverse=True)[:top_k]alpha 값은 0.7(벡터 70%, 키워드 30%)이 일반적인 출발점이다. 문서의 특성에 따라 조정한다. 정책 문서처럼 의미 검색이 중요한 경우 alpha를 높이고, 코드 문서나 식별자가 많은 경우 alpha를 낮춘다.
쿼리 확장
사용자의 질문이 짧거나 모호할 때, 질문을 확장하면 검색 품질이 올라간다.
def expand_query(query: str) -> str:
"""Claude를 사용하여 검색 질의를 확장합니다."""
response = client.messages.create(
model="claude-haiku-3-5-20241022",
max_tokens=200,
system="사용자의 질문을 검색에 적합한 형태로 확장하세요. 동의어, 관련 용어, 다른 표현을 추가하세요. 확장된 질의만 출력하세요.",
messages=[{"role": "user", "content": query}]
)
return response.content[0].text“재택근무”라는 질문이 “재택근무 원격근무 리모트워크 재택 정책 가이드라인”으로 확장되면, 다양한 용어로 작성된 문서를 더 잘 찾아낼 수 있다.
Claude 응답 생성
시스템 프롬프트
RAG_SYSTEM_PROMPT = """당신은 회사의 사내 지식 기반을 활용하여 직원들의 질문에 답변하는 AI 어시스턴트입니다.
## 핵심 원칙
1. 제공된 문서에 근거하여 답변합니다. 문서에 없는 내용은 답변하지 않습니다.
2. 답변에 사용한 문서의 출처를 반드시 명시합니다.
3. 문서의 정보가 불충분하면 "제공된 문서에서 해당 정보를 찾을 수 없습니다"라고 솔직하게 답합니다.
4. 여러 문서의 정보가 상충하면 가장 최근에 업데이트된 문서를 우선합니다.
5. 추측하지 않습니다. 확실하지 않으면 확인이 필요하다고 안내합니다.
## 답변 형식
- 핵심 답변을 먼저 제시하고, 필요하면 세부 내용을 추가합니다.
- 출처는 [출처: 문서명] 형식으로 표기합니다.
- 관련 문서 링크가 있으면 함께 제공합니다.
## 주의사항
- 인사 규정, 급여, 법적 사항에 대해서는 정확한 문서 내용만 전달하고, 해석이나 조언은 하지 않습니다.
- 개인정보가 포함된 문서는 해당 정보를 제외하고 답변합니다.
- 문서의 내용을 왜곡하거나 과장하지 않습니다."""응답 생성 함수
def generate_answer(query: str, retrieved_chunks: list[dict]) -> dict:
"""검색된 문서를 바탕으로 답변을 생성합니다."""
# 검색 결과를 컨텍스트로 구성
context_parts = []
for i, chunk in enumerate(retrieved_chunks):
source_info = f"[문서 {i+1}] {chunk['metadata'].get('title', '제목 없음')}"
if chunk['metadata'].get('section'):
source_info += f" > {chunk['metadata']['section']}"
source_info += f" (최종 수정: {chunk['metadata'].get('last_updated', '알 수 없음')})"
context_parts.append(f"{source_info}\n{chunk['content']}")
context = "\n\n---\n\n".join(context_parts)
user_message = f"""다음 사내 문서를 참고하여 질문에 답변해주세요.
## 참고 문서
{context}
## 질문
{query}"""
response = client.messages.create(
model="claude-sonnet-4-20250514",
max_tokens=2048,
system=RAG_SYSTEM_PROMPT,
messages=[{"role": "user", "content": user_message}]
)
return {
"answer": response.content[0].text,
"sources": [
{
"title": chunk["metadata"].get("title"),
"url": chunk["metadata"].get("source_url"),
"relevance_score": chunk["score"]
}
for chunk in retrieved_chunks
],
"tokens_used": {
"input": response.usage.input_tokens,
"output": response.usage.output_tokens
}
}환각 방지와 인용 처리
환각의 원인과 대응
RAG 시스템에서 환각(hallucination)은 검색된 문서에 없는 내용을 Claude가 지어내는 현상이다. 환각이 발생하는 주요 원인과 대응 전략은 다음과 같다.
첫째, 검색 결과가 질문과 관련이 없는 경우다. 벡터 유사도가 높아도 실제로는 다른 주제의 문서일 수 있다. relevance threshold를 설정하여 유사도가 낮은 결과를 필터링한다.
RELEVANCE_THRESHOLD = 0.75
def filter_relevant_chunks(chunks: list[dict]) -> list[dict]:
return [c for c in chunks if c["score"] >= RELEVANCE_THRESHOLD]둘째, 질문이 문서 범위 밖인 경우다. 시스템 프롬프트에서 “모르면 모른다고 답하라”는 지시를 강화한다.
셋째, Claude가 일반 지식으로 답변을 보충하는 경우다. 이를 방지하기 위해 “제공된 문서만 사용하라”는 지시를 반복한다.
인용 검증
답변에 포함된 인용이 실제 문서 내용과 일치하는지 자동으로 검증하는 후처리 단계를 추가할 수 있다.
def verify_citations(answer: str, source_chunks: list[dict]) -> dict:
"""답변의 인용이 실제 문서와 일치하는지 검증합니다."""
verification_prompt = f"""다음 답변이 참고 문서의 내용을 정확하게 반영하는지 검증해주세요.
답변:
{answer}
참고 문서:
{chr(10).join([c['content'] for c in source_chunks])}
검증 결과를 JSON으로 출력해주세요:
{{
"is_grounded": true/false,
"unsupported_claims": ["문서에서 근거를 찾을 수 없는 주장 목록"],
"accuracy_score": 0.0-1.0
}}"""
response = client.messages.create(
model="claude-haiku-3-5-20241022",
max_tokens=512,
messages=[{"role": "user", "content": verification_prompt}]
)
return json.loads(response.content[0].text)이 검증 단계는 추가 비용이 발생하지만, 엔터프라이즈 환경에서는 정확성이 비용보다 중요하다. 특히 인사 정책, 법률 관련 질문에 대해서는 검증을 필수로 적용하는 것을 권한다.
배포
API 서버
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
app = FastAPI()
class QuestionRequest(BaseModel):
question: str
department: str | None = None
top_k: int = 5
class AnswerResponse(BaseModel):
answer: str
sources: list[dict]
confidence: float
@app.post("/ask", response_model=AnswerResponse)
async def ask_question(request: QuestionRequest):
# 1. 검색
filters = {}
if request.department:
filters["department"] = request.department
chunks = retrieve(request.question, top_k=request.top_k, filters=filters)
# 2. 관련성 필터링
relevant_chunks = filter_relevant_chunks(chunks)
if not relevant_chunks:
return AnswerResponse(
answer="죄송합니다. 질문과 관련된 사내 문서를 찾을 수 없습니다. 질문을 다시 표현하거나, 담당 부서에 직접 문의해주세요.",
sources=[],
confidence=0.0
)
# 3. 답변 생성
result = generate_answer(request.question, relevant_chunks)
# 4. 인용 검증
verification = verify_citations(result["answer"], relevant_chunks)
return AnswerResponse(
answer=result["answer"],
sources=result["sources"],
confidence=verification.get("accuracy_score", 0.8)
)접근 권한 관리
엔터프라이즈 환경에서는 문서별 접근 권한이 다를 수 있다. 경영진만 볼 수 있는 문서의 내용이 일반 직원에게 노출되면 안 된다.
def retrieve_with_access_control(query: str, user_role: str, department: str) -> list[dict]:
"""사용자의 접근 권한에 맞는 문서만 검색합니다."""
access_filter = {
"$or": [
{"access_level": "all_employees"},
{"access_level": user_role},
{"department": department}
]
}
return retrieve(query, filters=access_filter)문서를 인덱싱할 때 접근 권한 정보를 메타데이터에 포함시키고, 검색 시 사용자의 권한에 맞는 문서만 반환하도록 필터링한다.
모니터링
품질 지표
프로덕션 RAG 시스템에서 추적해야 할 핵심 지표는 다음과 같다.
응답 정확도: 사용자 피드백(좋아요/싫어요)을 수집하여 측정한다. 주간 단위로 무작위 샘플을 사람이 검토하여 정확도를 교차 검증한다.
검색 적합도(retrieval relevance): 검색된 문서가 질문과 실제로 관련이 있는지 측정한다. 유사도 점수 분포를 모니터링하고, threshold 이하의 비율이 높아지면 임베딩이나 청킹을 개선한다.
“모름” 비율: “해당 정보를 찾을 수 없습니다” 응답의 비율. 이 수치가 높으면 문서 커버리지가 부족하거나 검색 품질이 낮다는 신호다.
지연 시간: 질문부터 답변까지의 소요 시간. 3초 이내를 목표로 한다. 검색에 500ms, 생성에 2초 정도가 일반적이다.
흔한 문제와 해결
문서가 오래된 경우: 인덱스의 last_updated 메타데이터를 활용하여 오래된 문서에 경고를 표시한다. “이 정보는 2025년 3월 기준입니다. 최신 정보는 HR팀에 확인해주세요.”
같은 질문이 반복되는 경우: FAQ 캐시를 구축하여 빈번한 질문에 대한 응답을 미리 생성해둔다. API 비용과 지연 시간을 모두 줄일 수 있다.
복잡한 질문: “A 정책과 B 정책의 차이점은?” 같은 비교 질문은 여러 문서를 동시에 참고해야 한다. top_k를 높이거나 멀티쿼리 검색을 사용한다.
마무리
엔터프라이즈 RAG 시스템을 성공적으로 구축하기 위한 핵심 교훈을 정리한다.
청킹이 모든 것의 기초다. 나머지 구성 요소가 아무리 좋아도 청킹이 잘못되면 검색 품질이 바닥을 친다. 문서의 구조를 존중하는 의미 단위 분할을 기본으로 하고, 문서 유형에 따라 전략을 조정한다.
환각 방지는 시스템 프롬프트와 후처리 검증의 조합으로 달성한다. 한 곳에만 의존하면 불충분하다.
메타데이터는 과소평가되는 자산이다. 부서, 문서 유형, 최종 수정일, 접근 권한 등의 메타데이터가 풍부할수록 검색 품질과 답변 정확도가 높아진다.
하이브리드 검색은 벡터 전용 검색보다 거의 항상 낫다. BM25와 벡터 검색의 결합은 구현 복잡도 대비 효과가 매우 크다.
접근 권한 관리는 기능이 아니라 요구사항이다. 엔터프라이즈 환경에서 접근 권한을 무시하면 시스템을 배포할 수 없다.
모니터링과 피드백 루프가 장기적 성공을 결정한다. 배포 후 6개월이 지나면 문서도, 사용자의 질문 패턴도, 조직 구조도 바뀐다. 시스템이 이 변화에 적응하려면 지속적인 모니터링과 개선이 필수다.