Chapter 3. Knowledge & Context Engineering (**수정)

1. Context Engineering 개념 체계 (**수정)

1.1 Context Engineering이란? (**수정)

Context Engineering(컨텍스트 엔지니어링)은 LLM에게 **"무엇을 줄까"**를 다루는 맥락 공급 파이프라인입니다. LLM 추론(inference) 시 최적의 토큰 집합을 큐레이션(curation)하고 유지하는 전략의 집합으로, 단순한 프롬프트 작성을 넘어 LLM에 전달되는 전체 정보를 설계하고 관리하는 엔지니어링 분야입니다. (**수정)

Ch.2에서 다룬 프롬프트 엔지니어링이 **"어떻게 말할까(표현 기법)"**에 집중한다면, 컨텍스트 엔지니어링은 **"무엇을 줄까(맥락 공급)"**에 집중합니다. 아무리 프롬프트를 잘 작성해도 적절한 맥락이 제공되지 않으면 LLM은 최신 정보나 조직 내부 지식을 활용할 수 없습니다. (**수정)

Gartner(2025)는 "Context engineering is in, and prompt engineering is out"이라고 표현하며, 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로의 패러다임 전환을 강조하였습니다. (**수정)

[출처: Gartner, "Agentic AI: 55 Predictions for 2025 and Beyond", 2025] [출처: Andrej Karpathy, "Context Engineering" 개념 제시, 2025 (x.com/karpathy)]

1.2 Context Engineering의 체계 (**수정)

Context Engineering은 LLM에게 맥락을 제공하는 모든 기법을 포괄하며, 다음과 같은 체계로 분류됩니다. (**수정)

Context Engineering (LLM에게 맥락을 제공하는 모든 기법)
├── 정적 컨텍스트 (Static Context)
│   ├── System Prompt — 역할, 규칙, 제약 조건 정의
│   ├── Few-shot Examples — 입력-출력 예시 쌍 제공
│   └── Fine-Tuning (내재화) — 모델 파라미터에 지식을 내재화 (Ch.1 참조)
├── 동적 컨텍스트 (Dynamic Context)
│   ├── RAG (Retrieval-Augmented Generation) — 외부 문서 검색 기반 지식 주입
│   ├── Knowledge Graph — 엔티티 간 관계 기반 구조화된 지식
│   ├── Tool/API 연동 — 실시간 외부 시스템 호출을 통한 정보 획득
│   └── Memory — 대화 이력, 사용자 선호도, 장기 기억 관리
└── 컨텍스트 관리 (Context Management)
    ├── 윈도우 최적화 — 컨텍스트 윈도우 내 정보 배치 전략
    ├── 압축/요약 — 대화 이력 및 문서의 효율적 압축
    └── 품질 검증 — 제공된 컨텍스트의 정확성·관련성 평가

(**수정)

1.3 Knowledge Engineering과 Context Engineering의 관계 (**추가)

Knowledge Engineering은 지식을 체계적으로 수집, 구조화, 관리하는 공학 분야로, AI 이전부터 존재해온 개념입니다. Context Engineering은 이 지식을 LLM이 활용할 수 있는 형태로 전달하는 과정까지 포함하는 확장된 개념입니다. (**추가)

구분	Knowledge Engineering	Context Engineering
초점	지식의 수집·구조화·저장	지식의 선별·가공·전달·관리
범위	온톨로지, 지식 그래프, 규칙 체계	KE + 검색, 압축, 윈도우 관리, 실시간 주입
LLM과의 관계	지식의 원천(Source)	지식의 파이프라인(Pipeline)

(**추가)

RAG는 Knowledge Engineering(지식 구조화)과 Context Engineering(맥락 전달)이 만나는 교차점에 위치하며, 이 챕터에서 가장 비중 있게 다루는 핵심 기법입니다. (**추가)

[출처: Anthropic, "Building Effective Agents", 2024 (anthropic.com/research/building-effective-agents)] [출처: Anthropic, "Effective context engineering for AI agents" (anthropic.com/engineering/effective-context-engineering-for-ai-agents)]

1.4 컨텍스트의 핵심 구성 요소 (**수정)

Anthropic의 공식 가이드에 따르면, LLM에 전달되는 컨텍스트는 다음 네 가지 요소로 구성됩니다. (**수정)

1) 시스템 프롬프트 (System Prompt) — 정적 컨텍스트

LLM의 역할, 규칙, 제약 조건을 정의
일반적인 판단 원칙과 구체적 규칙의 균형이 핵심

2) 도구 정의 (Tools) — 동적 컨텍스트 연결

LLM이 외부 시스템과 상호작용할 수 있도록 정의된 함수/API 목록
도구 설명의 품질이 에이전트 성능에 직접적 영향

3) 예시 (Examples) — 정적 컨텍스트

Few-shot 예시로 제공되는 입력-출력 쌍
도구 호출 방식, 응답 형식, 판단 기준 등을 시범으로 제시

4) 메시지 이력 (Message History) — 동적 컨텍스트

이전 대화 내용, 도구 호출 결과, 중간 추론 과정
가장 동적인 요소로, 대화 진행에 따라 지속적 관리가 필요

(**수정)

[출처: Anthropic, "Effective context engineering for AI agents" (anthropic.com/engineering/effective-context-engineering-for-ai-agents)]

2. RAG: 동적 컨텍스트의 핵심 구현 (**수정)

2.1 RAG란? (**수정)

RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 외부 데이터베이스에서 정보를 검색(Retrieval)한 후, LLM이 이를 활용하여 답변을 생성(Generation)하는 기법입니다. Context Engineering 체계에서 동적 컨텍스트의 가장 대표적이고 핵심적인 구현 방식입니다. (**수정)

기존 LLM은 학습된 데이터만을 기반으로 답변을 생성하는 반면, RAG를 활용하면 최신 데이터나 내부 문서를 추가적으로 검색하여 활용할 수 있기 때문에 보다 정확하고 문맥에 맞는 답변을 제공할 수 있습니다.

이는 특히 기업 내부 문서 검색, 최신 뉴스 기반의 챗봇, 기술 지원 시스템 등에서 중요한 역할을 할 수 있습니다.

2.2 기존 LLM의 한계를 보완하는 RAG (**수정)

LLM은 강력한 자연어 생성 능력을 가지고 있지만, 몇 가지 한계가 있습니다. RAG는 이러한 한계를 보완하여 보다 실용적인 AI 시스템을 구축하는 데 도움을 줄 수 있습니다.

LLM은 최신 정보를 반영하기 어렵습니다.

기존 LLM은 학습이 완료된 시점의 데이터까지만 알고 있음. 이후 발생한 새로운 정보는 모델이 알지 못하기 때문에 최신 데이터를 기반으로 한 답변이 어려움
RAG는 외부데이터 검색을 통해 최신정보를 반영하여 이를 해결할 수 있음

LLM은 특정 도메인의 세부 정보를 잘 모를 수 있습니다.

일반적인 LLM은 광범위한 데이터를 학습하지만, 특정 기업 내부 문서나 전문적인 기술 문서 등의 세부 정보를 학습하는 것은 어려움
RAG를 활용하면 기업 내부 데이터베이스, 논문, 기술 문서 등의 정보를 검색하여 보다 정확한 답변을 생성할 수 있음

LLM은 Hallucination(환각)이 발생할 수 있습니다.

LLM은 때때로 학습된 데이터에 없는 내용을 창작하여 사실과 다른 정보를 생성할 수 있음
RAG는 검색된 실제 문서를 바탕으로 답변을 생성하기 때문에 환각 문제를 줄이는 데 도움이 됨

이러한 한계들은 결국 LLM에 "적절한 컨텍스트"를 제공하지 못하기 때문에 발생하는 문제입니다. Context Engineering은 이 문제를 근본적으로 해결하기 위한 체계적 접근법이며, RAG는 그 실현 수단입니다.

3. RAG 핵심 구성 요소

RAG를 효과적으로 수행하기 위해서는 데이터를 검색하고 처리하는 과정이 최적화되어야 하며, 이 과정에서 여러 가지 핵심 기술이 사용됩니다. 아래에서 RAG가 원활하게 동작하기 위해 필요한 주요 구성 요소를 단계별로 살펴보겠습니다.

Context Engineering 관점에서 이 구성 요소들은 "지식을 어떻게 준비하고 구조화할 것인가"에 해당하는 영역입니다. 데이터 전처리부터 인덱싱까지의 과정은 양질의 컨텍스트를 생성하기 위한 기반 작업이라 할 수 있습니다.

3.1 데이터 전처리

3.1.1 데이터 전처리의 중요성

RAG의 성능을 높이기 위해서는 검색할 문서가 구조적으로 정리되어 있어야 하며, 불필요한 정보가 제거된 상태여야 합니다.

데이터가 정제되지 않은 상태에서는 검색 성능이 저하될 수 있으며, 정확하지 않은 정보가 검색될 가능성이 높아집니다.
데이터 전처리는 문서의 일관성을 유지하고, 검색 및 임베딩 과정에서 불필요한 정보를 배제하는 것을 목표로 합니다.
데이터의 품질이 낮으면 RAG의 검색 과정에서 불필요한 문서가 반환되거나, 필요한 정보가 검색되지 않을 가능성이 커지므로, 데이터 전처리는 필수적인 과정입니다.

데이터 전처리의 과정을 살펴보겠습니다.

3.1.2 텍스트 정제

문서의 텍스트를 정제하는 과정에서는 데이터의 일관성을 유지하고 불필요한 요소를 제거하는 작업이 포함됩니다. 대표적인 텍스트 정제 작업은 다음과 같습니다.

불필요한 기호 및 특수 문자 제거: 텍스트 내의 HTML 태그, 이모지, 기호 등의 불필요한 요소를 제거하여 가독성을 높입니다.
불필요한 공백 정리: 여러 개의 연속된 공백, 줄바꿈 등을 하나로 정리하여 문장의 일관성을 유지합니다.
대소문자 통일: 검색 시 대소문자가 일치하지 않아 검색 성능이 저하될 수 있으므로, 소문자로 변환하여 일관성을 유지합니다.

3.1.3 중복 데이터 제거

완전히 동일한 문서 제거: 동일한 내용이 여러 번 포함된 경우, 하나의 문서만 유지하고 나머지는 삭제합니다.
의미적으로 유사한 문서 필터링: 문서가 완전히 동일하지 않더라도, 90% 이상 동일한 내용을 포함하는 경우 하나만 유지할 수 있습니다.

3.1.4 데이터 형식 변환

문서의 원본 데이터가 PDF, Word 파일, 스캔된 이미지 등 다양한 형식으로 존재할 수 있습니다. 이러한 데이터를 RAG에서 활용하려면 텍스트 기반으로 변환하는 과정이 필요합니다.

OCR(Optical Character Recognition) 활용: 이미지 기반 문서를 텍스트로 변환하는 과정입니다. 스캔된 문서나 사진에 포함된 텍스트를 추출할 때 유용합니다.
PDF 및 Word 문서 변환: PDF나 Word 문서를 직접 처리할 수 있도록 텍스트로 변환하는 과정이 필요합니다.
JSON, CSV 등의 구조화된 데이터 활용: 데이터가 테이블 형식으로 저장된 경우, 이를 적절한 문장 형식으로 변환하여 검색할 수 있도록 처리합니다.

3.1.5 메타데이터 추가

검색 성능을 더욱 향상시키기 위해, 각 문서에 **메타데이터(Metadata)**를 추가하는 방식이 사용될 수 있습니다. 메타데이터는 문서의 분류, 날짜, 작성자 등과 같은 추가 정보를 포함하며, 보다 정교한 검색 필터링이 가능하도록 도와줍니다.

문서의 출처 (Source): 문서가 어디에서 온 것인지(내부 문서, 위키, 논문 등)를 저장합니다.
날짜 (Date): 최신 문서를 우선적으로 검색할 수 있도록 타임스탬프 정보를 추가합니다.
주제 태그 (Tags): 문서의 주요 주제를 태그로 저장하여 검색 시 활용할 수 있습니다.

3.2 청킹 (Chunking)

**청킹(Chunking)**은 문서를 작은 단위로 나누어 검색 성능을 향상시키는 과정입니다.

문서 전체를 검색 대상으로 삼을 경우 불필요한 정보가 함께 검색될 가능성이 높고, 연산 비용이 증가할 수 있습니다. 따라서 문서를 적절한 크기로 나누어 검색 성능을 최적화하는 것이 중요합니다.

3.2.1 청킹이 필요한 이유

검색의 정확도 향상
- 문서 전체를 검색하는 대신, 더 적절한 문서 청크만 검색할 수 있음
- 검색된 청크가 작을수록, 필요한 정보를 더 적절하게 찾을 가능성이 높아짐. 청크가 너무 작은 경우 청크 내의 문맥을 파악하기 힘들기 때문에 적절한 크기로 청킹해야함
연산 비용 절감
- 검색할 데이터가 작아지면, 벡터 검색 및 인덱싱에 필요한 연산량이 감소
- 검색 속도가 빨라지고, 모델이 처리해야 하는 데이터의 양이 줄어듦
LLM의 응답 품질 개선
- 문장이 적절한 크기로 나누어지면, 검색된 정보가 LLM의 답변 생성에 더 적절하게 활용될 수 있음
- 너무 긴 문서는 검색 후에도 LLM이 중요한 내용을 추출하는 데 어려움을 겪을 수 있음

Context Engineering 관점에서 청킹은 "컨텍스트 윈도우(Context Window)를 얼마나 효율적으로 활용할 것인가"와 직결됩니다. LLM의 컨텍스트 윈도우는 유한하므로, 가장 관련성 높은 정보를 적절한 크기로 제공하는 것이 핵심입니다.

3.2.2 청킹 기법

문서의 내용과 검색 목적에 맞게 적절한 방식으로 청킹해야합니다. 다양한 청킹 기법 중 가장 기본적인 기법들에 대해 알아보겠습니다. 아래 문장을 예시로 각각의 청킹 기법을 비교하겠습니다.

고정 길이 청킹 (Fixed-size Chunking)

일정한 문자 수 또는 토큰 수를 기준으로 문서를 나누는 방식입니다. 예를 들어, 500자 또는 256개 토큰 단위로 문서를 청킹할 수 있습니다.

청킹 결과 예시:

"RAG는 검색과 생성을 결합한 모델입니다. 이를 통해 "
"LLM은 외부 데이터를 활용하여 보다 정확한 답변을 생"
"성할 수 있습니다. RAG는 여러 산업에서 사용되고 "
"있습니다."

항목	내용
장점	구현이 쉽고 빠름, 검색 성능이 비교적 안정적
단점	문장이 중간에서 끊길 위험이 있어 문맥이 손실될 가능성 있음
적합한 경우	대량의 문서를 빠르게 처리해야 하는 경우

문장 단위 청킹 (Sentence-based Chunking)

문장을 기준으로 나누는 방식입니다.

청킹 결과 예시:

"RAG는 검색과 생성을 결합한 모델입니다."
"이를 통해 LLM은 외부 데이터를 활용하여 보다 정확한 답변을 생성할 수 있습니다."
"RAG는 여러 산업에서 사용되고 있습니다."

항목	내용
장점	문맥이 유지되며, 청크가 의미 단위로 구성됨
단점	문장 길이가 일정하지 않아 검색 효율이 일정하지 않을 수 있음
적합한 경우	문서의 문장 구조가 중요한 경우

의미 기반 청킹 (Semantic Chunking)

AI 모델을 활용하여 의미적으로 연관된 문장들을 하나의 청크로 묶는 방식입니다. 유사한 개념이나 주제를 다루는 문장들을 같은 청크로 분류합니다.

청킹 결과 예시:

"RAG는 검색과 생성을 결합한 모델입니다. 이를 통해 LLM은 외부 데이터를 활용하여 보다 정확한 답변을 생성할 수 있습니다."
"RAG는 여러 산업에서 사용되고 있습니다."

항목	내용
장점	문맥이 완벽하게 유지되며, 검색 결과가 더욱 정확함
단점	AI 모델을 활용해야 하므로 연산 비용이 증가함
적합한 경우	문맥이 중요한 문서 (논문, 기술 문서 등)

실제 시스템에서는 고정 길이 청킹과 문장 단위 청킹을 함께 사용하는 방식도 가능합니다. 예를 들어, 문장을 기준으로 나눈 후, 일정 크기(예: 300자) 이하의 청크를 병합하여 최적의 검색 성능을 도출할 수 있습니다.

3.3 임베딩 (Embedding) & 벡터 DB (Vector DB)

RAG는 보다 정확한 정보를 제공하기 위해 **임베딩(Embedding)**과 **벡터 데이터베이스(Vector DB)**를 활용합니다. 위에서 청킹한 결과들을 각각 임베딩을 통해 텍스트를 의미 기반의 벡터로 변환하고, 벡터 데이터베이스를 사용하여 가장 관련성이 높은 문서를 빠르게 검색합니다.

3.3.1 임베딩 (Embedding)

임베딩이란 텍스트(문장이나 단어)를 숫자로 변환하는 기술입니다.

컴퓨터는 문자나 단어를 직접 이해할 수 없습니다. 대신, 숫자(벡터)로 변환하면 컴퓨터가 이를 분석하고 비교할 수 있습니다. 따라서 자연어를 숫자로 변환하여 문맥을 이해할 수 있도록 하는 과정이 필요하고, 이것이 임베딩입니다.

임베딩을 활용하면 의미적으로 유사한 단어와 문장이 비슷한 숫자로 표현됩니다.

위의 왼쪽 숫자(벡터)들은 각각의 단어를 의미하는 임베딩 값이고, 비슷한 단어일수록 숫자가 비슷하게 표현됩니다. 이처럼, 텍스트 간의 의미적 관계를 수치적으로 표현하는 것이 임베딩의 핵심입니다.

임베딩 모델이란?

임베딩을 만들기 위해서는 임베딩 모델이 필요합니다. 이 모델은 텍스트를 숫자로 바꿔주는 역할을 합니다.

대표적인 임베딩 모델

#	모델	개발사	특징
1	`text-embedding-3`	OpenAI	의미 기반 검색, 유사 문서 찾기 등에 최적화. 다국어 지원 및 비용 대비 높은 성능 제공
2	`Embed v3`	Cohere	영어 및 100개 이상의 언어를 지원하며, 검색(RAG), 분류, 클러스터링에 강점. 유사한 문서 및 의미 기반 검색에 최적화
3	`BGE-M3` (*수정)	BAAI (Beijing Academy of AI)	한국어 지원이 우수하며, 다국어 검색에 최적화. `Dense`, `Sparse`, `Multi-vector` 세 가지 검색 방식을 동시에 지원
4	`Voyage AI Embeddings`	Voyage AI	코드 검색 및 법률/금융 등 전문 도메인에 특화된 모델 제공
5	`Jina Embeddings v3`	Jina AI	8K 토큰 길이의 긴 문서 임베딩 지원, 다국어 지원 우수

[출처: MTEB Leaderboard (huggingface.co/spaces/mteb/leaderboard)]

임베딩 모델을 선택할 때 고려할 점

정확도: 단어, 문장, 문서 간의 의미적 유사성을 얼마나 정확하게 반영하는가?
속도: 임베딩을 생성하고 유사도를 비교하는 속도가 얼마나 빠른가?
비용: 모델을 운영하는 데 필요한 컴퓨팅 자원과 API 호출 비용이 많이 드는가?

3.3.2 벡터DB (Vector DB)

벡터 DB(Vector DB)란?

**벡터 데이터베이스(Vector DB)**는 임베딩된 데이터를 벡터 공간에 저장하는 데이터베이스입니다. RAG에서는 문서나 질문을 벡터로 변환한 후, 벡터 DB를 이용해 가장 관련성이 높은(의미 기반) 문서를 검색하여 AI 모델이 활용할 수 있도록 합니다.

벡터 DB의 주요 역할

임베딩된 문서 저장: 미리 변환된 벡터 데이터를 데이터베이스에 저장
유사 벡터 검색: 사용자의 질문을 벡터로 변환하고, 가장 유사한 벡터(문서)를 빠르게 찾아 제공
문맥 기반 검색 지원: 키워드 검색보다 의미적으로 가까운 문서를 찾을 수 있음

기존 데이터베이스와의 차이

벡터 DB는 기존 데이터베이스와 달리, 문서 간 의미적 유사성을 고려한 검색을 수행하여 RAG의 검색 성능을 극대화하는 핵심 기술입니다.

구분	기존 데이터베이스	벡터 DB
데이터 유형	정형 데이터 (텍스트, 숫자)	벡터 (고차원 수치 데이터)
검색 방식	키워드, 필터 기반 검색	의미적 유사도를 기반으로 검색
사용 사례	전통적인 웹 서비스, CRUD 애플리케이션	의미 기반 검색, 추천 시스템, RAG

대표적인 벡터DB

전용 벡터 데이터베이스 — 벡터 데이터를 저장, 관리, 검색하는 완전한 DB 시스템

벡터 DB	특징
`Pinecone`	클라우드 기반, 대규모 벡터 데이터를 빠르게 검색 가능
`Weaviate`	AI 기능 내장, 의미 기반 검색 및 데이터 필터링 기능 제공
`ChromaDB`	오픈소스 벡터 DB, 간편한 로컬 실행 지원
`Qdrant` (*수정)	Rust 기반 고성능 벡터 DB, 필터링과 벡터 검색을 동시 지원, 대규모 프로덕션 환경에 적합 [출처: qdrant.tech]
`Milvus`	대규모 벡터 데이터를 위한 오픈소스 벡터 DB, 분산 아키텍처 지원, 수십억 개의 벡터 처리 가능 [출처: milvus.io]

기존 DB + 벡터 검색 기능 — AI 및 벡터 검색 수요가 증가하면서 기존DB에서 벡터 검색 기능을 추가 지원함

벡터 DB	특징
`AWS OpenSearch` (Elasticsearch 기반)	(*수정) 기존 텍스트 검색 엔진에서 벡터 검색을 기본 지원하는 통합 검색 플랫폼으로 발전, `k-NN`(근접 이웃 검색) 기반의 벡터 검색을 네이티브 지원, 대규모 로그, 문서, AI 검색 시스템에서 많이 사용
`Redis`	빠른 인메모리 데이터베이스로 벡터 검색 기능 추가됨. 초고속 벡터 검색이 필요할 때 적합
`PostgreSQL`	`pgvector` 확장 기능을 통해 벡터 검색을 지원, SQL 기반의 벡터 검색을 수행할 수 있어 기존 RDB와 AI 시스템을 함께 운영할 때 유용

3.4 인덱싱 (Indexing)

**인덱싱(Indexing)**은 검색 속도를 높이기 위해 청킹된 문서를 빠르게 검색할 수 있도록 정리하는 과정입니다. 문서의 양이 많아질수록 원하는 정보를 신속하게 찾기 어려워지므로, 적절한 인덱싱 기법을 활용하여 검색 속도를 최적화해야 합니다.

RAG에서는 검색을 수행하기 전에, 문서를 적절한 방식으로 인덱싱하여 검색 속도를 높이고 검색 성능을 최적화합니다.

3.4.1 인덱싱이 필요한 이유

검색 속도 향상
- 문서의 양이 많아질수록, 모든 문서를 하나씩 비교하면 시간이 너무 오래 걸릴 수 있음
- 인덱싱을 수행하면, 검색해야 할 문서의 범위를 좁혀 검색 속도를 크게 향상시킬 수 있음
검색 성능 최적화
- 키워드 검색이 필요한 경우, 미리 단어별 색인을 생성하여 빠르게 검색 가능
- 의미 기반 검색이 필요한 경우, 벡터 검색을 최적화하여 가장 유사한 문서를 빠르게 찾을 수 있음
효율적인 문서 관리
- 새로운 문서가 추가되거나 수정될 때, 기존 인덱스에 반영하여 최신 정보를 검색할 수 있도록 유지 가능

3.4.2 인덱싱 방식

(1) 역색인 (Inverted Index)

역색인은 전통적인 검색 엔진에서 사용하는 방식으로, 문서 내의 단어(토큰)를 색인화합니다. 이 방식은 벡터 DB가 아닌 일반적인 DB나 검색엔진 전용 데이터베이스(ex. Elasticsearch)에 저장되어 키워드 기반 검색에 사용됩니다. (3.3의 Keyword Search)

예를 들어, 다음과 같은 두 개의 문서가 있다고 가정합니다.

문서 1: "RAG는 검색과 생성을 결합한 모델입니다."
문서 2: "검색 엔진은 키워드 기반으로 동작합니다."

이를 역색인으로 저장하면 다음과 같이 정리됩니다.

키워드	포함된 문서
RAG	문서 1
검색	문서 1, 문서 2
생성	문서 1
키워드	문서 2

이렇게 색인을 구축하면, 사용자가 "검색"이라는 키워드를 입력했을 때 사전에 색인된 정보를 바탕으로 문서 1과 문서 2를 빠르게 찾아낼 수 있습니다.

(2) 벡터 인덱싱 (Vector Indexing)

벡터 인덱싱은 문서를 벡터(수치화된 데이터)로 변환하여 저장하는 방식입니다. 앞서 배운 임베딩 → 벡터DB 저장 과정이 이 벡터 인덱싱을 위한 과정입니다. 이 방식은 의미 기반의 검색에 사용됩니다. (4.2의 Vector Search)

벡터 인덱싱은 아래와 같은 순서로 동작합니다.

문서를 임베딩(Embedding) 모델을 사용하여 벡터로 변환
변환된 벡터를 **벡터 데이터베이스(Vector DB)**에 저장
사용자가 질문을 입력하면, 해당 질문도 벡터로 변환 후 가장 유사한 벡터를 검색하여 관련 문서를 반환

예를 들어, 사용자가 "RAG의 개념이 무엇인가?"라는 질문을 입력하면, 이 질문도 벡터로 변환된 후 가장 유사한 벡터를 가진 문서를 검색하여 반환합니다.

4. RAG의 동작 방식

앞서 설명한 데이터 전처리, 임베딩, 인덱싱은 문서를 검색하기 위한 사전 준비 과정입니다. 이제 RAG가 실제로 어떻게 검색을 수행하고, 검색된 정보를 활용하여 응답을 생성하는지에 대해 설명하겠습니다.

4.1 RAG의 핵심 동작 단계

RAG는 크게 Retrieval → Augmentation → Generation의 3단계로 동작합니다.

4.1.1 Retrieval (문서 검색)

사용자의 질문(Query)에 대해 가장 관련성이 높은 문서를 검색하는 과정
앞서 설명한 인덱싱된 문서 데이터에서 검색을 수행
Vector Search(의미 기반 검색), Keyword Search(키워드 검색), Hybrid Search(결합 검색) 중 하나를 활용하여 검색
검색된 문서가 정확할수록 최종 응답의 품질도 향상됨

4.1.2 Augmentation (정보 보강)

검색된 문서를 LLM이 활용할 수 있도록 가공하는 과정
불필요한 정보를 제거하고, LLM이 사용할 수 있도록 텍스트를 정리
프롬프트에 정리한 텍스트를 제공하여 모델이 보다 정확한 응답을 생성할 수 있도록 지원

Context Engineering 관점에서, Augmentation 단계는 가장 핵심적인 영역입니다. 검색된 원시 정보를 LLM이 최적으로 활용할 수 있는 형태의 컨텍스트로 재구성하는 과정이기 때문입니다. 이 단계에서 정보의 우선순위 결정, 중복 제거, 문맥 연결 등의 Context Engineering 기법이 적용됩니다.

4.1.3 Generation (응답 생성)

Augmentation 단계에서 제공된 정보를 바탕으로 LLM이 최종 응답을 생성

4.2 Retrieval(검색) 방식

앞서 3.4에서 설명한 인덱싱은 검색을 빠르게 수행하기 위한 과정이었습니다. 이제, 인덱싱된 문서에서 실제로 어떤 방식으로 문서를 검색할 것인지에 대해 알아보겠습니다.

RAG에서 Retrieval(문서 검색) 단계는 전체 동작 흐름에서 가장 중요한 부분입니다. 검색된 문서의 품질이 낮으면, LLM이 부정확한 정보를 바탕으로 응답을 생성할 가능성이 높아지기 때문입니다.

RAG에서 주로 사용되는 검색 방식은 다음과 같습니다.

4.2.1 Vector Search (벡터 검색, 의미 기반 검색)

문서를 임베딩(Embedding) 모델을 활용하여 벡터로 변환한 후, 가장 유사한 벡터를 검색하는 방식입니다. 문맥적인 의미를 기반으로 검색할 수 있기 때문에 키워드가 정확히 일치하지 않아도 유사한 문서를 찾을 수 있습니다.

동작 과정:

질문(Query)을 벡터로 변환
데이터베이스에 저장된 벡터들과 비교하여 가장 유사한 벡터를 검색
가장 유사한 문서를 찾아 반환

구분	내용
장점	문맥을 고려한 검색이 가능 — 키워드가 다르더라도 의미가 유사한 문서를 찾을 수 있음. 동의어나 문장 구조가 다른 경우에도 검색 성능이 우수함
단점	벡터 연산이 필요하므로 키워드 검색보다 연산 비용이 높음. 특정 키워드가 포함된 문서를 정확히 찾는 데는 적합하지 않음

4.2.2 Keyword Search (키워드 검색, 역색인 기반 검색)

문서에서 특정 키워드를 기반으로 검색하는 방식입니다. **역색인(Inverted Index)**을 활용하여, 특정 단어가 포함된 문서를 빠르게 찾을 수 있습니다.

동작 과정:

질문(Query)에서 주요 키워드를 추출
역색인(Inverted Index)에서 해당 키워드가 포함된 문서를 검색
일치하는 문서를 반환

구분	내용
장점	검색 속도가 빠름 — 특정 키워드가 포함된 문서를 빠르게 찾을 수 있음. 인덱싱된 데이터가 많을수록 검색 효율성이 증가
단점	문맥을 고려하지 않음 — 동의어나 유사한 표현을 검색할 수 없음. 키워드가 정확히 일치해야 검색 가능 — 다른 표현이나 문장 구조가 다르면 검색되지 않을 수 있음

4.2.3 Hybrid Search (하이브리드 검색, 키워드 + 벡터 검색 결합)

Vector Search(벡터 검색)와 Keyword Search(키워드 검색)를 결합하여, 두 방식의 장점을 동시에 활용하는 방식입니다. 일반적으로는 키워드 검색 → 벡터 검색 순으로 진행되나, 도메인과 목적에 따라 반대 순서로 진행하거나 병렬로 진행하는 방법을 고려할 수 있습니다.

동작 과정:

Keyword Search로 문서 검색
Vector Search를 적용하여 문서 검색
두 검색 결과를 결합 및 정렬

구분	내용
장점	검색 속도와 정확도를 동시에 개선할 수 있음. 키워드 검색의 정확성과 벡터 검색의 문맥 이해 능력을 조합하여 최적의 검색 결과 제공
단점	두 가지 검색 방식이 모두 필요하므로, 설계가 복잡해지고 연산 비용이 증가할 수 있음

4.2.4 검색 방식 비교 종합

구분	Vector Search	Keyword Search	Hybrid Search
검색 원리	임베딩 벡터 유사도 비교	역색인 기반 키워드 매칭	벡터 + 키워드 결합
문맥 이해	우수	불가	우수
검색 속도	중간	빠름	중간
연산 비용	높음	낮음	높음
적합한 상황	의미 기반 유사 문서 검색	정확한 키워드 매칭	정확성 + 문맥 이해 모두 필요 시

5. RAG의 한계

RAG는 검색을 통해 실시간 정보를 활용하여 더 정확하고 최신의 응답을 생성하는 강력한 기술입니다. 그러나, 부정확한 문서 검색, 검색된 정보와 LLM 응답 간의 불일치 등의 한계가 존재할 수 있습니다. 이제 RAG의 주요 한계와 이를 해결하기 위한 보완 전략을 살펴보겠습니다.

5.1 검색 결과의 신뢰성 문제

부정확한 문서가 검색될 가능성이 있음
**벡터 검색(Vector Search)**이 문맥적으로 유사하지만 정확하지 않은 문서를 반환할 수 있음
**키워드 검색(Keyword Search)**이 필요한 문서를 놓칠 가능성이 있음
정확한 문서를 검색하지 못하면, LLM이 부정확한 정보를 바탕으로 응답을 생성할 수 있음

보완 방법:

검색 결과 재조정 (Re-ranking) 기법: 첫 번째 검색 결과를 보정하여 더 정확한 문서를 상위에 배치하는 방식. 예를 들어, 벡터 검색에서 반환된 문서들을 다시 키워드 검색을 활용해 가중치를 조정하는 방식 적용 가능
인덱싱 최적화 (색인 업데이트 & 필터링 강화): 검색 빈도가 높은 문서에 우선순위를 부여하여 검색 속도 향상. 특정 도메인에서는 카테고리 기반 인덱싱 적용 (예: 법률, 의료, 기술 문서 등)

5.2 문맥 연결 부족 (검색된 정보와 LLM 응답의 자연스러움 문제)

검색된 정보가 LLM의 응답과 자연스럽게 연결되지 않을 수 있음
검색된 문서가 여러 개일 경우, LLM이 어떤 정보를 중점적으로 반영해야 할지 판단하기 어려울 수 있음
LLM이 제공하는 응답이 검색된 문서의 내용을 왜곡할 가능성도 있음

보완 방법:

검색된 문서를 더 효과적으로 Augmentation하는 기법 적용
- LLM이 검색된 정보를 더 정확하게 반영할 수 있도록, 검색된 문서를 요약 및 정제하여 컨텍스트로 제공
- 검색된 문서에서 가장 중요한 정보를 추출하여 LLM이 효율적으로 활용하도록 보조
Retrieval & Generation 단계 조정
- 검색 결과가 많을 경우, 우선순위를 부여하여 가장 신뢰할 만한 문서를 먼저 반영
- 문맥 연결성을 높이기 위해 LLM이 여러 검색 결과를 조합하여 하나의 응답을 생성하는 방식 적용

5.3 컨텍스트 윈도우 한계와 정보 손실

LLM의 컨텍스트 윈도우에는 물리적 한계가 있어, 검색된 모든 문서를 한꺼번에 제공할 수 없음
컨텍스트 윈도우가 커지더라도 "Lost in the Middle" 현상으로 인해 중간에 위치한 정보가 무시될 수 있음

보완 방법:

검색된 문서의 중요도에 따라 컨텍스트 내 배치 순서를 최적화 (가장 관련성 높은 문서를 앞뒤에 배치)
Map-Reduce 방식으로 긴 문서를 요약 후 통합하여 컨텍스트 효율성 향상
필요한 정보만 선별적으로 추출하여 컨텍스트를 구성하는 Context Compression 기법 적용

[출처: Liu et al., "Lost in the Middle: How Language Models Use Long Contexts", 2023 (arxiv.org/abs/2307.03172)]

6. Advanced RAG 패턴

기본 RAG를 넘어, 검색과 생성의 품질을 더욱 향상시키기 위한 고급 RAG 패턴들이 발전하고 있습니다.

6.1 GraphRAG (지식 그래프 기반 RAG)

GraphRAG는 문서를 단순히 벡터로 저장하는 대신, **지식 그래프(Knowledge Graph)**를 구축하여 엔티티 간의 관계를 활용하는 RAG 기법입니다.

핵심 원리: 문서에서 엔티티(인물, 조직, 개념 등)와 관계를 추출하여 그래프로 구축한 후, 질문에 대해 관련 엔티티와 그 연결 관계를 함께 검색
장점: 여러 문서에 걸친 복합적 질문(Multi-hop Reasoning)에 강함
예시: "A 회사의 CEO가 참여한 프로젝트에서 사용된 기술은?" → 여러 관계를 추적하여 답변

[출처: Microsoft Research, "GraphRAG: Unlocking LLM Discovery on Narrative Private Data", 2024]

GraphRAG와 Knowledge Graph에 대한 더 상세한 내용은 아래 섹션 8에서 심화하여 다룹니다. (**수정)

6.2 Agentic RAG (에이전트 기반 RAG)

Agentic RAG는 AI 에이전트가 검색 전략을 자율적으로 계획하고 실행하는 방식의 RAG입니다.

핵심 원리: 에이전트가 질문을 분석하고, 어떤 데이터 소스에서 무엇을 검색할지 스스로 판단하여 실행
장점: 복잡한 질문에 대해 다단계 검색을 자동으로 수행, 필요시 검색 전략을 수정
활용 예시: 여러 데이터베이스(사내 문서, 외부 API, 웹 검색)를 조합한 복합 질의 처리

→ Agentic RAG의 에이전트 관점에서의 상세 아키텍처와 실무 적용 사례는 Ch.4 Section 6에서 다룹니다. (**수정)

[출처: LangChain, "Agentic RAG Guide" (python.langchain.com)]

6.3 Corrective RAG (자기 수정 RAG)

Corrective RAG는 검색 결과의 품질을 자동으로 평가하고, 부적절한 경우 재검색을 수행하는 RAG 기법입니다.

핵심 원리: 검색된 문서가 질문과 관련이 있는지 LLM이 판단하고, 관련성이 낮으면 검색 쿼리를 수정하여 재검색
장점: 잘못된 정보에 기반한 응답 생성을 방지, 답변의 신뢰성 향상
구성: 검색 평가기(Retrieval Evaluator) + 쿼리 재작성기(Query Rewriter) + 지식 정제기(Knowledge Refiner)

7. RAG 평가 지표

RAG 시스템의 성능을 객관적으로 평가하기 위한 프레임워크와 지표들이 있습니다.

7.1 주요 평가 지표

평가 지표	설명	측정 대상
Faithfulness (충실도)	생성된 답변이 검색된 문서에 기반하는 정도	답변의 사실 정확성
Answer Relevance (답변 관련성)	생성된 답변이 질문에 얼마나 적절한지	답변-질문 정합성
Context Relevance (컨텍스트 관련성)	검색된 문서가 질문에 얼마나 관련 있는지	검색 품질
Answer Correctness (답변 정확도)	생성된 답변이 실제 정답과 일치하는 정도	전반적 정확도

7.2 RAGAS 프레임워크

RAGAS(Retrieval Augmented Generation Assessment)는 RAG 시스템의 품질을 자동으로 평가하는 오픈소스 프레임워크입니다.

LLM을 활용하여 위 평가 지표를 자동으로 측정
별도의 정답 데이터 없이도 평가 가능 (Reference-free Evaluation)
CI/CD 파이프라인에 통합하여 RAG 시스템의 품질을 지속적으로 모니터링 가능

[출처: RAGAS Documentation (docs.ragas.io)]

8. Knowledge Graph & GraphRAG 심화 (**추가)

8.1 Knowledge Graph란? (**추가)

**Knowledge Graph(지식 그래프)**는 현실 세계의 엔티티(Entity)와 그들 간의 관계(Relation)를 그래프 구조로 표현한 지식 저장 체계입니다. 노드(Node)는 엔티티를, 엣지(Edge)는 관계를 나타냅니다. (**추가)

[삼성전자] ---(CEO)--→ [이재용]
     |                      |
  (제조)              (졸업)
     |                      |
[Galaxy S25] ←--         [서울대]

(**추가)

Knowledge Graph는 RAG의 벡터 검색이 놓칠 수 있는 엔티티 간 관계 정보를 제공하여, LLM이 보다 정확한 추론을 수행할 수 있도록 지원합니다. Context Engineering 체계에서 동적 컨텍스트의 구조화된 지식 기반 역할을 합니다. (**추가)

[출처: Google, "Introducing the Knowledge Graph", 2012 (blog.google)] [출처: Neo4j, "What is a Knowledge Graph?" (neo4j.com/use-cases/knowledge-graph)]

8.2 Knowledge Graph 구축 방법 (**추가)

단계	설명	대표 도구/기술
엔티티 추출 (NER)	문서에서 인물, 조직, 장소, 개념 등을 식별	`spaCy`, LLM 기반 추출
관계 추출 (RE)	엔티티 간의 관계를 파악 (예: "A는 B의 CEO이다")	LLM 프롬프팅, `OpenIE`
그래프 저장	추출된 트리플(주어-관계-목적어)을 그래프 DB에 저장	`Neo4j`, `Amazon Neptune`
온톨로지 설계	도메인별 엔티티 유형과 관계 유형을 정의	`OWL`, `RDF Schema`

(**추가)

8.3 GraphRAG 심화 (**추가)

GraphRAG는 단순 벡터 검색의 한계를 극복하기 위해 Knowledge Graph와 RAG를 결합한 기법입니다. (**추가)

GraphRAG의 동작 방식: (**추가)

문서 → 그래프 구축: 문서에서 엔티티와 관계를 추출하여 Knowledge Graph 생성
커뮤니티 탐지: 관련 엔티티들을 클러스터(커뮤니티)로 그룹화
커뮤니티 요약: 각 커뮤니티에 대한 요약 정보를 LLM으로 사전 생성
질의 처리: 사용자 질문에 대해 관련 커뮤니티의 요약과 엔티티 관계를 함께 검색

벡터 검색(RAG) vs GraphRAG 비교: (**추가)

구분	벡터 기반 RAG	GraphRAG
검색 단위	텍스트 청크	엔티티 + 관계 + 커뮤니티 요약
강점	의미적 유사성 기반 검색	멀티홉 추론, 전체 데이터셋 요약
약점	엔티티 간 관계 파악 어려움	그래프 구축 비용, 실시간 업데이트 어려움
적합한 질문	"RAG란 무엇인가?"	"A 부서에서 B 프로젝트에 참여한 사람들의 전문 분야는?"

(**추가)

[출처: Microsoft Research, "GraphRAG: Unlocking LLM Discovery on Narrative Private Data", 2024 (microsoft.com/en-us/research/blog/graphrag)] [출처: Neo4j, "GraphRAG Manifesto" (neo4j.com/blog/graphrag-manifesto)]

9. Tool/API 기반 동적 지식 접근 (**추가)

→ Tool/API 연동의 표준화된 프로토콜(MCP, A2A)과 에이전트 프레임워크 수준의 도구 활용은 Ch.4 Section 4~5에서 다룹니다. (**수정)

9.1 Tool/API 연동의 개념 (**추가)

RAG가 사전 수집된 문서에서 지식을 검색하는 방식이라면, Tool/API 연동은 실시간으로 외부 시스템을 호출하여 최신 정보를 동적으로 획득하는 방식입니다. Context Engineering 체계에서 동적 컨텍스트의 또 다른 핵심 구현입니다. (**추가)

사용자 질문 → LLM 판단 → Tool/API 호출 → 실시간 결과 획득 → 컨텍스트에 주입 → 응답 생성

(**추가)

9.2 Tool/API 연동의 유형 (**추가)

유형	설명	활용 예시
웹 검색 API	실시간 웹 검색을 통해 최신 정보 획득	`Google Search API`, `Bing Search API`
데이터베이스 쿼리	SQL/NoSQL DB에서 실시간 데이터 조회	고객 정보 조회, 재고 확인
외부 서비스 API	날씨, 환율, 뉴스 등 외부 서비스 호출	날씨 API, 금융 데이터 API
내부 시스템 API	사내 ERP, CRM, ITSM 등 연동	`SAP`, `Salesforce`, `ServiceNow`
코드 실행 엔진	계산, 데이터 분석 등 코드 실행	Python 인터프리터, 계산기

(**추가)

9.3 RAG vs Tool/API 연동 비교 (**추가)

구분	RAG	Tool/API 연동
데이터 시점	인덱싱 시점의 데이터	호출 시점의 실시간 데이터
데이터 원천	사전 수집·임베딩된 문서	외부 시스템의 라이브 데이터
지연 시간	벡터 검색 (밀리초 단위)	API 호출 (수백 밀리초~초 단위)
적합한 상황	내부 문서, 지식 베이스 검색	실시간 데이터, 트랜잭션 처리

실무에서는 RAG와 Tool/API를 함께 조합하여 사용하는 것이 일반적입니다. 예를 들어, 사내 정책 문서는 RAG로 검색하고, 고객의 현재 계약 상태는 CRM API로 실시간 조회하는 방식입니다. (**추가)

[출처: OpenAI, "Function Calling Guide" (platform.openai.com/docs/guides/function-calling)] [출처: Anthropic, "Tool Use Guide" (docs.anthropic.com/en/docs/build-with-claude/tool-use)]

10. Memory & Conversation Management (**추가)

10.1 Memory의 개념과 중요성 (**추가)

Memory는 LLM이 이전 대화, 사용자 선호도, 장기적 맥락을 기억하고 활용할 수 있도록 하는 Context Engineering 구현 방식입니다. LLM은 기본적으로 상태가 없는(stateless) 모델이므로, 대화 간 연속성을 유지하려면 별도의 메모리 시스템이 필요합니다. (**추가)

10.2 Memory의 유형 (**추가)

유형	설명	저장 방식	활용 예시
단기 메모리 (Short-term)	현재 대화 세션 내의 메시지 이력	컨텍스트 윈도우 내 유지	대화 맥락 유지
작업 메모리 (Working)	현재 작업에서 발견된 핵심 사실·결정사항	구조화된 노트 형태	에이전트의 작업 상태 추적
장기 메모리 (Long-term)	세션을 넘어 지속되는 사용자 선호도·이력	외부 DB/벡터 스토어	개인화된 응답 제공
의미 메모리 (Semantic)	학습된 사실과 개념적 지식	Knowledge Graph/벡터 DB	도메인 지식 축적

(**추가)

10.3 컨텍스트 부패 (Context Rot)와 대응 (**추가)

**컨텍스트 부패(Context Rot)**는 컨텍스트 윈도우 내 토큰 수가 증가함에 따라 LLM의 정보 회상 능력이 저하되는 현상입니다. (**추가)

원인: LLM의 주의(attention) 메커니즘이 모든 토큰에 동일한 가중치를 부여하지 않음 (**추가)
증상: 초기 지시사항 무시, 중요 정보 누락, 일관성 없는 응답 (**추가)
비유: "상사가 지시 후 사라지고, 동료들이 끊임없이 다른 이야기를 하면 원래 지시를 잊게 되는 것과 유사" (**추가)

대응 기법: (**추가)

기법	설명
컨텍스트 압축 (Compaction)	LLM을 활용하여 대화 이력을 요약, 중요 정보만 보존
구조화된 메모리 (Agentic Memory)	핵심 결정사항·발견 사실을 별도 구조화 저장
하위 에이전트 분리	독립 하위 에이전트로 작업을 분리, 깨끗한 컨텍스트에서 실행
슬라이딩 윈도우	최근 N개의 메시지만 유지하고 오래된 메시지는 요약 후 제거

(**추가)

[출처: Anthropic, "Effective context engineering for AI agents" (anthropic.com/engineering/effective-context-engineering-for-ai-agents)] [출처: LangChain, "Memory" (python.langchain.com/docs/concepts/memory)]

11. Document Intelligence (비정형 문서 지식 추출) (**추가)

11.1 Document Intelligence란? (**추가)

Document Intelligence는 PDF, 이미지, 스캔 문서, 스프레드시트 등 비정형·반정형 문서에서 구조화된 지식을 추출하는 기술입니다. RAG 파이프라인의 전처리 단계를 고도화하여, 단순 텍스트 추출을 넘어 문서의 구조와 의미까지 파악합니다. (**추가)

11.2 핵심 기술 (**추가)

기술	설명	대표 도구
OCR (Optical Character Recognition)	이미지/스캔 문서에서 텍스트 추출	`Tesseract`, `Azure AI Document Intelligence`
레이아웃 분석 (Layout Analysis)	표, 그림, 캡션, 헤더 등 문서 구조 파악	`Unstructured.io`, `DocTR`
표 추출 (Table Extraction)	표 형태의 데이터를 구조화된 형식으로 변환	`Camelot`, `Tabula`
멀티모달 문서 이해	Vision LLM을 활용한 문서 전체 이해	`GPT-4o`, `Claude` (Vision)

(**추가)

11.3 SI 기업에서의 활용 (**추가)

계약서/RFP 분석: 수백 페이지의 계약서에서 핵심 조항, 의무사항, 리스크 요소를 자동 추출 (**추가)
기술 문서 처리: 설계 도면, 사양서에서 기술 스펙을 구조화하여 검색 가능하도록 변환 (**추가)
규정/컴플라이언스 문서: 법규, 내부 규정 문서를 파싱하여 항목별로 검색·비교 가능하도록 처리 (**추가)
레거시 문서 디지털화: 기존 종이 문서, 팩스, 오래된 PDF를 디지털 지식 베이스로 변환 (**추가)

[출처: Microsoft, "Azure AI Document Intelligence" (azure.microsoft.com/en-us/products/ai-services/ai-document-intelligence)] [출처: Unstructured.io (unstructured.io)]

12. 지식 라이프사이클 관리 (**추가)

12.1 지식 라이프사이클이란? (**추가)

지식 라이프사이클 관리는 RAG 및 Knowledge Graph에 활용되는 지식을 생성부터 갱신, 폐기까지 체계적으로 관리하는 프로세스입니다. 한 번 구축한 지식 베이스를 방치하면 시간이 지남에 따라 정보가 부정확해지거나 불완전해져 LLM의 응답 품질이 저하됩니다. (**추가)

12.2 라이프사이클 단계 (**추가)

[생성] → [검증] → [배포] → [모니터링] → [갱신] → [폐기/아카이빙]
  ↑                                              |
  └──────────────── 피드백 루프 ─────────────────┘

(**추가)

단계	설명	핵심 활동
생성 (Creation)	새로운 지식을 문서/데이터에서 추출·수집	크롤링, Document Intelligence, 수동 큐레이션
검증 (Validation)	추출된 지식의 정확성·완전성 확인	SME(Subject Matter Expert) 리뷰, 자동 팩트 체크
배포 (Deployment)	검증된 지식을 벡터 DB/Knowledge Graph에 인덱싱	임베딩, 그래프 구축, 메타데이터 부여
모니터링 (Monitoring)	지식의 활용도와 정확도를 지속 추적	검색 로그 분석, 사용자 피드백, 답변 품질 평가
갱신 (Update)	변경된 정보를 반영하여 지식 업데이트	증분 업데이트, 재임베딩, 버전 관리
폐기 (Retirement)	더 이상 유효하지 않은 지식을 제거·아카이빙	만료 정책 적용, 아카이브 이동

(**추가)

12.3 실무 고려사항 (**추가)

증분 업데이트 vs 전체 재인덱싱: 문서 변경 시 변경 부분만 재처리하는 증분 방식이 효율적이지만, 임베딩 모델 변경 시에는 전체 재인덱싱이 필요 (**추가)
버전 관리: 지식 베이스의 특정 시점 스냅샷을 유지하여 과거 검색 결과를 재현할 수 있어야 함 (**추가)
만료 정책: 법규, 정책 문서 등은 유효 기간을 메타데이터로 관리하여 자동 만료 알림 구현 (**추가)
품질 대시보드: 검색 적중률, 사용자 만족도, 할루시네이션 발생률 등을 실시간 모니터링 (**추가)

[출처: LangChain, "Indexing" (python.langchain.com/docs/how_to/indexing)] [출처: Pinecone, "Vector Database Best Practices" (docs.pinecone.io)]

13. 기업 환경 RAG 구축 고려사항

SI 기업이 고객사에 RAG 시스템을 구축할 때 고려해야 할 핵심 사항입니다.

13.1 데이터 보안

사내 문서가 외부 LLM API로 전송되는 것에 대한 보안 정책 수립
필요 시 온프레미스(On-premise) LLM 또는 프라이빗 클라우드 환경에서 운영
임베딩 데이터에도 민감 정보가 포함될 수 있으므로 벡터 DB의 접근 제어 필수

13.2 데이터 갱신 전략

문서가 추가/수정/삭제될 때 임베딩과 인덱스를 자동으로 갱신하는 파이프라인 구축
증분 업데이트(Incremental Update): 변경된 문서만 재처리하여 효율성 확보
데이터 버전 관리를 통해 특정 시점의 검색 결과를 재현 가능하도록 설계

13.3 멀티 테넌시 (Multi-tenancy)

여러 고객사 또는 부서가 하나의 RAG 시스템을 공유하는 경우, 데이터 격리가 필수
네임스페이스(Namespace) 또는 메타데이터 필터링을 활용한 논리적 격리 구현
테넌트별 접근 권한 관리 및 감사 로그(Audit Log) 기능 구현

13.4 한국어 특화 사항

한국어의 교착어 특성을 고려한 토크나이저 및 임베딩 모델 선택이 중요
한국어 성능이 우수한 임베딩 모델 활용 권장 (예: BGE-M3, multilingual-e5-large)
한국어 형태소 분석기 적용으로 키워드 검색 성능 향상 (예: Nori, Mecab-ko)

14. Context Engineering 실무 가이드 (**수정)

RAG를 넘어, LLM 기반 시스템에서 컨텍스트를 효과적으로 설계하고 관리하기 위한 실무 가이드입니다. (**수정)

14.1 컨텍스트 설계 원칙

원칙	설명	적용 예시
관련성 우선(Relevance First)	질문과 가장 관련 있는 정보를 최우선으로 배치	검색 결과를 관련성 점수로 정렬 후 상위 N개만 포함
간결성(Conciseness)	불필요한 정보를 제거하여 컨텍스트 효율성 극대화	검색된 문서에서 핵심 문장만 추출하여 제공
구조화(Structure)	정보를 체계적으로 구조화하여 LLM이 쉽게 파싱할 수 있도록 구성	XML 태그, 구분자, 번호 매기기 등으로 정보 구분
출처 명시(Attribution)	각 정보의 출처를 명확히 표시하여 신뢰성 확보	검색 결과에 문서명, 페이지, 날짜 등 메타데이터 포함

14.2 컨텍스트 윈도우 관리 전략

LLM의 컨텍스트 윈도우는 유한하므로, 이를 효율적으로 활용하는 전략이 필요합니다.

시스템 프롬프트 최적화: 시스템 프롬프트를 간결하게 유지하여 검색 결과에 더 많은 공간 확보
동적 컨텍스트 할당: 질문의 복잡도에 따라 검색 결과의 수와 길이를 동적으로 조절
계층적 컨텍스트 구성: 요약 → 상세 순으로 정보를 계층적으로 배치하여 LLM이 필요한 깊이만큼 참조하도록 유도
컨텍스트 캐싱(Context Caching): 반복적으로 사용되는 컨텍스트(시스템 프롬프트, 공통 참조 문서 등)를 캐싱하여 비용 절감 및 응답 속도 향상

[출처: Google, "Context Caching", 2024 (ai.google.dev/gemini-api/docs/caching)] [출처: Anthropic, "Prompt Caching", 2024 (docs.anthropic.com/en/docs/build-with-claude/prompt-caching)]

14.3 동적 컨텍스트 조합 전략 (**추가)

실무에서는 단일 컨텍스트 소스가 아닌, 여러 동적 컨텍스트 소스를 조합하여 최적의 맥락을 구성합니다. (**추가)

컨텍스트 소스	역할	조합 예시
RAG (문서 검색)	사전 수집된 지식 베이스에서 관련 정보 검색	사내 정책 문서, 기술 매뉴얼
Knowledge Graph	엔티티 간 관계와 구조화된 사실 정보 제공	조직도, 제품 관계, 기술 의존성
Tool/API	실시간 외부 데이터 획득	고객 현황, 재고, 날씨, 환율
Memory	대화 이력과 사용자 맥락 유지	이전 질문, 선호도, 작업 상태

(**추가)

조합 패턴 예시 -- 고객 상담 시스템: (**추가)

Memory에서 고객의 이전 상담 이력과 선호도 로드
CRM API로 고객의 현재 계약 상태와 최근 활동 조회
RAG로 관련 상품 정보와 FAQ 문서 검색
Knowledge Graph에서 상품 간 관계(업그레이드 경로, 호환성) 조회
위 정보를 구조화하여 LLM 컨텍스트에 주입 → 응답 생성

(**추가)

14.4 SI 기업에서의 Context Engineering 활용 (**수정)

활용 영역	컨텍스트 엔지니어링 적용 방식
AI 기반 고객 상담	Memory + CRM API + RAG(FAQ) + Knowledge Graph(상품 관계) 조합
코딩 에이전트	프로젝트 구조, 코딩 컨벤션, 관련 파일을 동적으로 컨텍스트에 주입
문서 분석 시스템	Document Intelligence + RAG로 대용량 문서의 관련 섹션만 선별 포함
멀티 에이전트 시스템	각 에이전트에 역할별 최적화된 컨텍스트를 분리 제공
장기 실행 워크플로우	컨텍스트 압축과 구조화된 메모리로 일관성 유지

(**수정)

[출처: Anthropic, "Effective context engineering for AI agents" (anthropic.com/engineering/effective-context-engineering-for-ai-agents)] [출처: Prompt Engineering Guide, "Context Engineering Guide" (promptingguide.ai/guides/context-engineering-guide)]

한눈에 정리하는 이번 챕터 (**수정)

주제	핵심 내용
Context Engineering	LLM에게 "무엇을 줄까"를 다루는 맥락 공급 파이프라인 — 정적/동적/관리의 3개 축으로 구성
RAG	동적 컨텍스트의 핵심 구현 — 외부 문서 검색 → 정보 보강 → 응답 생성의 3단계로 동작
RAG 핵심 구성 요소	데이터 전처리, 청킹, 임베딩, 인덱싱 — 각 단계가 검색 품질에 직접 영향
검색 방식	벡터 검색, 키워드 검색, 하이브리드 검색 — 목적에 따라 선택·조합
Advanced RAG	GraphRAG, Agentic RAG, Corrective RAG를 통해 기본 RAG의 한계 극복
Knowledge Graph	엔티티 간 관계를 그래프로 구조화하여 멀티홉 추론과 전체 데이터 요약에 강점
Tool/API 연동	실시간 외부 시스템 호출로 최신 데이터를 동적으로 컨텍스트에 주입
Memory	대화 이력·사용자 선호도·작업 상태를 관리하여 LLM의 연속성과 개인화 확보
Document Intelligence	비정형 문서에서 구조화된 지식을 추출하여 RAG 파이프라인의 입력 품질 향상
지식 라이프사이클	지식의 생성→검증→배포→모니터링→갱신→폐기를 체계적으로 관리
컨텍스트 설계 원칙	관련성, 간결성, 구조화, 출처 명시의 4대 원칙으로 컨텍스트 품질 확보

(**수정)

마무리 (**수정)

이번 챕터에서는 LLM에게 **"무엇을 줄까"**라는 관점에서, Context Engineering의 전체 체계와 그 핵심 구현 방식들을 살펴보았습니다. (**수정)

Context Engineering은 단순히 RAG만을 의미하지 않습니다. 정적 컨텍스트(System Prompt, Few-shot, Fine-Tuning)부터 동적 컨텍스트(RAG, Knowledge Graph, Tool/API, Memory)까지, 그리고 이 모든 것을 효율적으로 관리하는 컨텍스트 관리(윈도우 최적화, 압축/요약, 품질 검증)까지 아우르는 포괄적인 엔지니어링 분야입니다. (**수정)

RAG는 이 체계에서 동적 컨텍스트의 가장 핵심적인 구현으로, 외부 문서 검색을 통해 LLM의 한계(최신성, 도메인 지식, 환각)를 보완합니다. 하지만 RAG만으로는 부족한 영역이 있으며, Knowledge Graph(관계 기반 추론), Tool/API(실시간 데이터), Memory(대화 연속성), Document Intelligence(비정형 문서 처리)를 함께 활용하여 보다 완전한 맥락 공급 파이프라인을 구축할 수 있습니다. (**수정)

Ch.2의 프롬프트 엔지니어링(표현 기법)과 이번 챕터의 컨텍스트 엔지니어링(맥락 공급)은 LLM 활용의 두 축입니다. 다음 챕터에서는 이 두 축 위에서 자율적으로 판단하고 행동하는 AI Agent에 대해 다룹니다. (**수정)

Chapter 3. Knowledge & Context Engineering (**수정) ​

1. Context Engineering 개념 체계 (**수정) ​

1.1 Context Engineering이란? (**수정) ​

1.2 Context Engineering의 체계 (**수정) ​

1.3 Knowledge Engineering과 Context Engineering의 관계 (**추가) ​

1.4 컨텍스트의 핵심 구성 요소 (**수정) ​

2. RAG: 동적 컨텍스트의 핵심 구현 (**수정) ​

2.1 RAG란? (**수정) ​

2.2 기존 LLM의 한계를 보완하는 RAG (**수정) ​

LLM은 최신 정보를 반영하기 어렵습니다. ​

LLM은 특정 도메인의 세부 정보를 잘 모를 수 있습니다. ​

LLM은 Hallucination(환각)이 발생할 수 있습니다. ​

3. RAG 핵심 구성 요소 ​

3.1 데이터 전처리 ​

3.1.1 데이터 전처리의 중요성 ​

3.1.2 텍스트 정제 ​

3.1.3 중복 데이터 제거 ​

3.1.4 데이터 형식 변환 ​

3.1.5 메타데이터 추가 ​

3.2 청킹 (Chunking) ​

3.2.1 청킹이 필요한 이유 ​

3.2.2 청킹 기법 ​

고정 길이 청킹 (Fixed-size Chunking) ​

문장 단위 청킹 (Sentence-based Chunking) ​

의미 기반 청킹 (Semantic Chunking) ​

3.3 임베딩 (Embedding) & 벡터 DB (Vector DB) ​

3.3.1 임베딩 (Embedding) ​

임베딩 모델이란? ​

대표적인 임베딩 모델 ​

임베딩 모델을 선택할 때 고려할 점 ​

3.3.2 벡터DB (Vector DB) ​

벡터 DB(Vector DB)란? ​

벡터 DB의 주요 역할 ​

기존 데이터베이스와의 차이 ​

대표적인 벡터DB ​

3.4 인덱싱 (Indexing) ​

3.4.1 인덱싱이 필요한 이유 ​

3.4.2 인덱싱 방식 ​

(1) 역색인 (Inverted Index) ​

(2) 벡터 인덱싱 (Vector Indexing) ​

4. RAG의 동작 방식 ​

4.1 RAG의 핵심 동작 단계 ​

4.1.1 Retrieval (문서 검색) ​

4.1.2 Augmentation (정보 보강) ​

4.1.3 Generation (응답 생성) ​

4.2 Retrieval(검색) 방식 ​

4.2.1 Vector Search (벡터 검색, 의미 기반 검색) ​

4.2.2 Keyword Search (키워드 검색, 역색인 기반 검색) ​

4.2.3 Hybrid Search (하이브리드 검색, 키워드 + 벡터 검색 결합) ​

4.2.4 검색 방식 비교 종합 ​

5. RAG의 한계 ​

5.1 검색 결과의 신뢰성 문제 ​

5.2 문맥 연결 부족 (검색된 정보와 LLM 응답의 자연스러움 문제) ​

5.3 컨텍스트 윈도우 한계와 정보 손실 ​

6. Advanced RAG 패턴 ​

6.1 GraphRAG (지식 그래프 기반 RAG) ​

6.2 Agentic RAG (에이전트 기반 RAG) ​

6.3 Corrective RAG (자기 수정 RAG) ​

7. RAG 평가 지표 ​

7.1 주요 평가 지표 ​

7.2 RAGAS 프레임워크 ​

8. Knowledge Graph & GraphRAG 심화 (**추가) ​

8.1 Knowledge Graph란? (**추가) ​

8.2 Knowledge Graph 구축 방법 (**추가) ​

8.3 GraphRAG 심화 (**추가) ​

9. Tool/API 기반 동적 지식 접근 (**추가) ​

9.1 Tool/API 연동의 개념 (**추가) ​

9.2 Tool/API 연동의 유형 (**추가) ​

9.3 RAG vs Tool/API 연동 비교 (**추가) ​

10. Memory & Conversation Management (**추가) ​

10.1 Memory의 개념과 중요성 (**추가) ​

10.2 Memory의 유형 (**추가) ​

10.3 컨텍스트 부패 (Context Rot)와 대응 (**추가) ​

11. Document Intelligence (비정형 문서 지식 추출) (**추가) ​

11.1 Document Intelligence란? (**추가) ​

11.2 핵심 기술 (**추가) ​

11.3 SI 기업에서의 활용 (**추가) ​

12. 지식 라이프사이클 관리 (**추가) ​

12.1 지식 라이프사이클이란? (**추가) ​

12.2 라이프사이클 단계 (**추가) ​

Chapter 3. Knowledge & Context Engineering (**수정)

1. Context Engineering 개념 체계 (**수정)

1.1 Context Engineering이란? (**수정)

1.2 Context Engineering의 체계 (**수정)

1.3 Knowledge Engineering과 Context Engineering의 관계 (**추가)

1.4 컨텍스트의 핵심 구성 요소 (**수정)

2. RAG: 동적 컨텍스트의 핵심 구현 (**수정)

2.1 RAG란? (**수정)

2.2 기존 LLM의 한계를 보완하는 RAG (**수정)

LLM은 최신 정보를 반영하기 어렵습니다.

LLM은 특정 도메인의 세부 정보를 잘 모를 수 있습니다.

LLM은 Hallucination(환각)이 발생할 수 있습니다.

3. RAG 핵심 구성 요소

3.1 데이터 전처리

3.1.1 데이터 전처리의 중요성

3.1.2 텍스트 정제

3.1.3 중복 데이터 제거

3.1.4 데이터 형식 변환

3.1.5 메타데이터 추가

3.2 청킹 (Chunking)

3.2.1 청킹이 필요한 이유

3.2.2 청킹 기법

고정 길이 청킹 (Fixed-size Chunking)

문장 단위 청킹 (Sentence-based Chunking)

의미 기반 청킹 (Semantic Chunking)

3.3 임베딩 (Embedding) & 벡터 DB (Vector DB)

3.3.1 임베딩 (Embedding)

임베딩 모델이란?

대표적인 임베딩 모델

임베딩 모델을 선택할 때 고려할 점

3.3.2 벡터DB (Vector DB)

벡터 DB(Vector DB)란?

벡터 DB의 주요 역할

기존 데이터베이스와의 차이

대표적인 벡터DB

3.4 인덱싱 (Indexing)

3.4.1 인덱싱이 필요한 이유

3.4.2 인덱싱 방식

(1) 역색인 (Inverted Index)

(2) 벡터 인덱싱 (Vector Indexing)

4. RAG의 동작 방식

4.1 RAG의 핵심 동작 단계

4.1.1 Retrieval (문서 검색)

4.1.2 Augmentation (정보 보강)

4.1.3 Generation (응답 생성)

4.2 Retrieval(검색) 방식

4.2.1 Vector Search (벡터 검색, 의미 기반 검색)

4.2.2 Keyword Search (키워드 검색, 역색인 기반 검색)

4.2.3 Hybrid Search (하이브리드 검색, 키워드 + 벡터 검색 결합)

4.2.4 검색 방식 비교 종합

5. RAG의 한계

5.1 검색 결과의 신뢰성 문제

5.2 문맥 연결 부족 (검색된 정보와 LLM 응답의 자연스러움 문제)

5.3 컨텍스트 윈도우 한계와 정보 손실

6. Advanced RAG 패턴

6.1 GraphRAG (지식 그래프 기반 RAG)

6.2 Agentic RAG (에이전트 기반 RAG)

6.3 Corrective RAG (자기 수정 RAG)

7. RAG 평가 지표

7.1 주요 평가 지표

7.2 RAGAS 프레임워크

8. Knowledge Graph & GraphRAG 심화 (**추가)

8.1 Knowledge Graph란? (**추가)

8.2 Knowledge Graph 구축 방법 (**추가)

8.3 GraphRAG 심화 (**추가)

9. Tool/API 기반 동적 지식 접근 (**추가)

9.1 Tool/API 연동의 개념 (**추가)

9.2 Tool/API 연동의 유형 (**추가)

9.3 RAG vs Tool/API 연동 비교 (**추가)

10. Memory & Conversation Management (**추가)

10.1 Memory의 개념과 중요성 (**추가)

10.2 Memory의 유형 (**추가)

10.3 컨텍스트 부패 (Context Rot)와 대응 (**추가)

11. Document Intelligence (비정형 문서 지식 추출) (**추가)

11.1 Document Intelligence란? (**추가)

11.2 핵심 기술 (**추가)

11.3 SI 기업에서의 활용 (**추가)

12. 지식 라이프사이클 관리 (**추가)

12.1 지식 라이프사이클이란? (**추가)

12.2 라이프사이클 단계 (**추가)