Chapter 3. Knowledge & Context Engineering

Knowledge(지식)의 개념

AI에서 Knowledge란?

AI 시스템에서 **Knowledge(지식)**란 모델이 올바른 추론과 응답을 생성하기 위해 활용하는 구조화된 정보를 의미합니다. 데이터(Data)가 가공되지 않은 원시 사실이라면, 정보(Information)는 맥락이 부여된 데이터이고, 지식(Knowledge)은 정보 간의 관계와 패턴을 이해하여 의사결정에 활용할 수 있는 상태를 말합니다.

계층	정의	예시
데이터 (Data)	가공되지 않은 원시 사실	"매출: 150억원"
정보 (Information)	맥락이 부여된 데이터	"2025년 3분기 매출이 전분기 대비 20% 증가"
지식 (Knowledge)	정보 간 관계를 이해하고 판단에 활용 가능한 상태	"신제품 출시와 마케팅 캠페인이 매출 증가의 주요 원인이며, 4분기에도 유사한 전략이 유효할 것"

이러한 데이터 → 정보 → 지식의 계층 구조를 **DIKW 피라미드(Data-Information-Knowledge-Wisdom)**라고 하며, AI 시스템이 단순 데이터 처리를 넘어 지식 기반의 추론을 수행하기 위한 핵심 개념입니다.

Knowledge의 유형

AI에 제공되는 지식은 두 가지 기준으로 분류할 수 있습니다.

전달 가능성에 따른 분류

유형	설명	예시
명시적 지식 (Explicit Knowledge)	문서, 매뉴얼, DB 등 형식화되어 쉽게 전달 가능한 지식	사내 규정집, 기술 문서, FAQ, API 문서
암묵적 지식 (Tacit Knowledge)	경험과 노하우에 기반한 비형식 지식으로, 언어화가 어려움	베테랑 엔지니어의 트러블슈팅 노하우, 영업 협상 전략

데이터 형태에 따른 분류

유형	설명	예시
구조화된 지식 (Structured)	테이블, 그래프 등 정형화된 형태로 저장된 지식	관계형 DB, 지식 그래프(Knowledge Graph), 온톨로지
비구조화된 지식 (Unstructured)	자유 형식의 텍스트, 이미지 등 비정형 데이터	PDF 문서, 회의록, 이메일, 슬랙 대화, 영상

이 두 분류 축은 독립적입니다. 예를 들어, 명시적 지식이 구조화된 형태(DB)일 수도 있고 비구조화된 형태(PDF 매뉴얼)일 수도 있습니다.

기업 데이터의 약 80~90%는 이메일, 문서, 회의록, 이미지와 같은 비구조화 데이터 형태로 존재하는 것으로 알려져 있습니다. 이러한 데이터에는 조직의 경험과 노하우와 같은 암묵적 지식과 문서화된 명시적 지식이 혼재되어 있으며, 이를 AI가 활용 가능한 형태로 변환하는 과정이 Knowledge Engineering과 RAG 시스템 구축의 핵심 과제입니다.

AI에 Knowledge를 제공하는 방법

LLM은 사전 학습(Pre-training) 데이터에 포함된 지식만 보유하며, 기업 내부 정보나 최신 데이터는 별도로 제공해야 합니다. AI에 지식을 제공하는 주요 방법은 다음과 같습니다.

방법	설명	장점	단점
RAG (Retrieval-Augmented Generation)	외부 지식 저장소에서 관련 정보를 검색하여 프롬프트 컨텍스트에 주입	재학습 불필요, 최신 정보 반영 용이	검색 품질에 의존, 컨텍스트 윈도우 제한
Fine-tuning (미세 조정)	특정 도메인 데이터로 모델 파라미터를 추가 학습	도메인 특화 성능 향상, 추론 시 외부 검색 불필요	학습 비용 높음, 데이터 업데이트 시 재학습 필요
Knowledge Graph (지식 그래프)	엔티티와 관계를 그래프 구조로 표현하여 지식을 구조화	복잡한 관계 추론, 설명 가능성 높음	구축·유지 비용, 비정형 데이터 처리 한계

위 세 가지가 지식을 제공하는 구체적 기법이라면, **Context Engineering(컨텍스트 엔지니어링)**은 이들을 포함한 LLM 입력 컨텍스트 전체를 체계적으로 설계·관리하는 상위 개념입니다. 프롬프트, RAG 검색 결과, 메모리, 도구 출력 등을 어떻게 구성하고 전달할 것인가를 다루며, 위 기법들을 조합하여 최적의 컨텍스트를 만드는 설계 원칙에 해당합니다.

이 챕터에서는 위 방법 중 Retrieval 기반 접근 방식인 RAG와 Context Engineering을 중심으로 다루며, Knowledge Graph는 GraphRAG 아키텍처를 통해 RAG와 결합하여 활용하는 방법을 살펴봅니다.

RAG (Retrieval-Augmented Generation)

RAG란?

RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 외부 데이터베이스에서 정보를 **검색(Retrieval)**한 후, LLM이 이를 활용하여 답변을 **생성(Generation)**하는 기술입니다. 기존 LLM은 학습된 데이터만을 기반으로 답변을 생성하는 반면, RAG를 활용하면 최신 데이터나 내부 문서를 추가적으로 검색하여 보다 정확한 답변을 제공할 수 있습니다.

LLM의 한계	RAG의 보완
최신 정보 반영 어려움 — 학습 완료 시점 이후 정보 부재	외부 데이터 검색으로 최신 정보 반영
도메인 세부 정보 부족 — 기업 내부 문서 등 미학습	내부 DB, 기술 문서 등에서 검색하여 활용
할루시네이션(Hallucination) — 사실과 다른 정보 생성	검색된 실제 문서 기반 답변으로 환각 감소

RAG는 모델 재학습 없이 외부 지식 베이스만 업데이트하면 최신 정보를 반영할 수 있어 파인튜닝 대비 비용 효율적이며, 검색된 문서의 출처를 함께 제공하여 **투명성(Transparency)**을 확보할 수 있습니다.

RAG 핵심 구성 요소

RAG 파이프라인은 다음 4가지 핵심 구성 요소로 이루어집니다.

구성 요소	설명	핵심 포인트
데이터 전처리	텍스트 정제, 중복 제거, 형식 변환(PDF→텍스트 등), 메타데이터 추가	데이터 품질이 검색 정확도의 기반
청킹 (Chunking)	문서를 검색에 적합한 작은 단위로 분할 (고정 길이 / 문장 단위 / 의미 기반)	일반적으로 200~1,000 토큰 범위, 10~20% 오버랩으로 문맥 손실 완화
임베딩 (Embedding)	텍스트를 고차원 벡터로 변환하여 의미적 유사성을 수치로 표현. 코사인 유사도(Cosine Similarity)로 벡터 간 유사도 측정	코사인 유사도(Cosine Similarity)가 대표적이며, Dot Product 등도 사용 (OpenAI text-embedding-3-small/large, Cohere Embed v4)
벡터 DB & 인덱싱	임베딩된 벡터를 저장하고 유사 벡터를 빠르게 검색. 역색인(Keyword Search용)과 벡터 인덱싱(Vector Search용)을 활용하며, ANN(Approximate Nearest Neighbor) 알고리즘으로 대규모 검색 수행	ANN 알고리즘(HNSW 등)으로 대규모 유사도 검색 수행 (Pinecone, ChromaDB, PostgreSQL(pgvector))

청킹 (Chunking)

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

청킹이 필요한 이유

검색의 정확도 향상

• 문서 전체를 검색하는 대신, 더 적절한 문서 청크만 검색할 수 있음
• 청크가 적정 크기일 때 필요한 정보를 정확히 찾을 가능성이 높아짐. 다만 청크가 너무 작으면 문맥이 손실되고, 너무 크면 불필요한 정보가 포함되므로 균형이 중요함

연산 비용 절감

• 검색할 데이터가 작아지면, 벡터 검색 및 인덱싱에 필요한 연산량이 감소
• 검색 속도가 빨라지고, 모델이 처리해야 하는 데이터의 양이 줄어듦

LLM의 응답 품질 개선

• 문장이 적절한 크기로 나누어지면, 검색된 정보가 LLM의 답변 생성에 더 적절하게 활용될 수 있음
• 너무 긴 문서는 검색 후에도 LLM이 중요한 내용을 추출하는 데 어려움을 겪을 수 있음

청킹 기법

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

청킹 기법	설명	장점	단점	적합한 경우
고정 길이 청킹 (Fixed-size Chunking)	일정한 문자 수 또는 토큰 수를 기준으로 문서를 나누는 방식. 예를 들어, 500자 또는 256개 토큰 단위로 문서를 청킹할 수 있음	구현이 쉽고 빠름, 검색 성능이 비교적 안정적	문장이 중간에서 끊길 위험이 있어 문맥이 손실될 가능성 있음	대량의 문서를 빠르게 처리해야 하는 경우
문장 단위 청킹 (Sentence-based Chunking)	문장을 기준으로 나누는 방식	문맥이 유지되며, 청크가 의미 단위로 구성됨	문장 길이가 일정하지 않아 검색 효율이 일정하지 않을 수 있음	문서의 문장 구조가 중요한 경우
의미 기반 청킹 (Semantic Chunking)	AI 모델을 활용하여 의미적으로 연관된 문장들을 하나의 청크로 묶는 방식. 유사한 개념이나 주제를 다루는 문장들을 같은 청크로 분류	문맥이 완벽하게 유지되며, 검색 결과가 더욱 정확함	AI 모델을 활용해야 하므로 연산 비용이 증가함	문맥이 중요한 문서 (논문, 기술 문서 등)

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

청크 오버랩(Chunk Overlap) 기법도 실무에서 널리 사용됩니다. 인접한 청크 간에 일정 부분(일반적으로 청크 크기의 10~20%)을 겹치도록 설정하여, 청크 경계에서 문맥이 끊기는 문제를 완화할 수 있습니다. 예를 들어 500자 청크에 100자 오버랩을 적용하면, 이전 청크의 마지막 100자가 다음 청크의 시작 부분에 포함됩니다. 다만 오버랩이 클수록 중복 데이터가 증가하여 저장 공간과 연산 비용이 늘어나는 단점이 있습니다.

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

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

임베딩 (Embedding)

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

컴퓨터는 문자나 단어를 직접 이해할 수 없습니다. 대신, 숫자(벡터)로 변환하면 컴퓨터가 이를 분석하고 비교할 수 있습니다. 따라서 자연어를 숫자로 변환하여 문맥을 이해할 수 있도록 하는 과정이 필요하고, 이것이 임베딩입니다. 임베딩을 활용하면 의미적으로 유사한 단어와 문장이 비슷한 숫자로 표현됩니다.

비슷한 단어일수록 숫자가 비슷하게 표현됩니다. 이처럼, 텍스트 간의 의미적 관계를 수치적으로 표현하는 것이 임베딩의 핵심입니다.

임베딩 모델이란?

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

임베딩 모델이 출력하는 벡터의 **차원(Dimension)**은 숫자의 개수를 의미합니다. 예를 들어 1,536차원이면 하나의 텍스트가 1,536개의 숫자로 표현됩니다. 차원이 높을수록 더 세밀한 의미 차이를 표현할 수 있지만, 그만큼 저장 공간과 검색 비용이 증가합니다. 반대로 차원이 낮으면 처리 속도와 비용 면에서 유리하지만, 미세한 의미 차이를 놓칠 수 있습니다.

대표적인 임베딩 모델 3가지

(1) OpenAI text-embedding-3

OpenAI에서 제공하는 최신 임베딩 모델 (small: 1,536차원 / large: 3,072차원) 의미 기반 검색, 유사 문서 찾기 등에 최적화됨 다국어 지원 및 비용 대비 높은 성능 제공

(2) Cohere Embed v4

Cohere에서 제공하는 최신 임베딩 모델 (최대 1,536차원, 128K 컨텍스트) 영어 및 100개 이상의 언어를 지원하며, 검색(RAG), 분류, 클러스터링에 강점 텍스트뿐 아니라 이미지, PDF 등 멀티모달 임베딩 지원

(3) Google Gemini Embedding 2

Google의 최신 멀티모달 임베딩 모델 (최대 3,072차원, 8,192 토큰) 텍스트뿐 아니라 이미지, 비디오, 오디오, PDF까지 하나의 임베딩 공간에서 처리하는 네이티브 멀티모달 모델 100개 이상의 언어를 지원하며, 검색, 분류, 클러스터링 등 다양한 태스크 유형(Task Type)을 지정하여 최적화 가능

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

• 정확도: 단어, 문장, 문서 간의 의미적 유사성을 얼마나 정확하게 반영하는가?
• 차원(Dimension): 벡터 차원이 높을수록 세밀한 의미 표현이 가능하지만, 저장 공간과 검색 비용이 증가한다. 용도에 맞는 차원을 선택해야 한다.
• 최대 입력 길이(Max Tokens): 한 번에 임베딩할 수 있는 텍스트의 최대 길이. 긴 문서를 다룬다면 입력 토큰 한도가 큰 모델이 유리하다.
• 다국어 지원: 한국어 등 비영어권 텍스트를 다룬다면, 해당 언어에서의 임베딩 품질을 반드시 확인해야 한다.
• 멀티모달 지원: 텍스트뿐 아니라 이미지, 문서(PDF) 등을 함께 검색해야 한다면, 멀티모달 임베딩을 지원하는 모델을 고려한다.
• 속도: 임베딩을 생성하고 유사도를 비교하는 속도가 얼마나 빠른가?
• 비용: 모델을 운영하는 데 필요한 컴퓨팅 자원과 API 호출 비용이 많이 드는가?

벡터DB (Vector DB)

벡터 DB(Vector DB)란?

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

벡터 DB의 주요 역할

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

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

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

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

대표적인 벡터DB

구분	설명	벡터 DB	특징
전용 벡터 데이터베이스	벡터 데이터를 저장, 관리, 검색하는 완전한 DB 시스템	Pinecone	클라우드 기반, 대규모 벡터 데이터를 빠르게 검색 가능
		Weaviate	AI 기능 내장, 의미 기반 검색 및 데이터 필터링 기능 제공
		ChromaDB	오픈소스 벡터 DB, 간편한 로컬 실행 지원
기존 DB + 벡터 검색 기능	AI 및 벡터 검색 수요가 증가하면서 기존DB에서 벡터 검색 기능을 추가 지원함	AWS OpenSearch (Elasticsearch 기반)	기존 텍스트 검색 엔진이었지만, 최근 k-NN 기반의 벡터 검색을 지원. 대규모 로그, 문서, AI 검색 시스템에서 많이 사용
		Redis	빠른 인메모리 데이터베이스로 벡터 검색 기능 추가됨. 초고속 벡터 검색이 필요할 때 적합
		PostgreSQL	pgvector 확장 기능을 통해 벡터 검색을 지원. SQL 기반의 벡터 검색을 수행할 수 있어 기존 RDB와 AI 시스템을 함께 운영할 때 유용

인덱싱 (Indexing)

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

인덱싱이 필요한 이유

검색 속도 향상

• 문서의 양이 많아질수록, 모든 문서를 하나씩 비교하면 시간이 너무 오래 걸릴 수 있음
• 인덱싱을 수행하면, 검색해야 할 문서의 범위를 좁혀 검색 속도를 크게 향상시킬 수 있음

검색 성능 최적화

• 키워드 검색이 필요한 경우, 미리 단어별 색인을 생성하여 빠르게 검색 가능
• 의미 기반 검색이 필요한 경우, 벡터 검색을 최적화하여 가장 유사한 문서를 빠르게 찾을 수 있음

효율적인 문서 관리

• 새로운 문서가 추가되거나 수정될 때, 기존 인덱스에 반영하여 최신 정보를 검색할 수 있도록 유지 가능

인덱싱 방식

(1) 역색인 (Inverted Index)

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

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

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

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

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

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

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

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

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

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

RAG의 핵심 동작 방식

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

Retrieval (문서 검색)

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

Augmentation (정보 보강)

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

Generation (응답 생성)

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

예시: "2025년 3분기 매출이 전년 대비 얼마나 증가했나요?"

1. Retrieval: 사내 재무 보고서 DB에서 "2025년 3분기 매출" 관련 문서 3건 검색

2. Augmentation: 검색된 문서에서 핵심 수치(매출액, 전년 동기 매출액)를 추출하여 프롬프트에 포함

3. Generation: LLM이 "2025년 3분기 매출은 180억 원으로, 전년 동기(150억 원) 대비 20% 증가했습니다"라고 답변 생성

Retrieval(검색) 방식

앞서 설명한 인덱싱은 검색을 빠르게 수행하기 위한 과정이었습니다. 이제, 인덱싱된 문서에서 실제로 어떤 방식으로 문서를 검색할 것인지에 대해 알아보겠습니다. RAG에서 Retrieval(문서 검색) 단계는 전체 동작 흐름에서 가장 중요한 부분입니다. 검색된 문서의 품질이 낮으면, LLM이 부정확한 정보를 바탕으로 응답을 생성할 가능성이 높아지기 때문입니다.

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

검색방식	설명	동작 방식	장점	한계
Vector Search (벡터 검색, 의미 기반 검색)	문서를 임베딩 모델을 활용하여 벡터로 변환한 후, 가장 유사한 벡터를 검색하는 방식. 문맥적인 의미를 기반으로 검색할 수 있기 때문에 키워드가 정확히 일치하지 않아도 유사한 문서를 찾을 수 있음	1. 질문(Query)을 벡터로 변환 2. 데이터베이스에 저장된 벡터들과 비교하여 가장 유사한 벡터를 검색 3. 가장 유사한 문서를 찾아 반환	문맥을 고려한 검색이 가능. 동의어나 문장 구조가 다른 경우에도 검색 성능이 우수함	벡터 연산이 필요하므로 키워드 검색보다 연산 비용이 높음. 특정 키워드가 포함된 문서를 정확히 찾는 데는 적합하지 않음
Keyword Search (키워드 검색, 역색인 기반 검색)	문서에서 특정 키워드를 기반으로 검색하는 방식. 역색인(Inverted Index)을 활용하여, 특정 단어가 포함된 문서를 빠르게 찾을 수 있음	1. 질문(Query)에서 주요 키워드를 추출 2. 역색인에서 해당 키워드가 포함된 문서를 검색 3. 일치하는 문서를 반환	검색 속도가 빠름. 인덱싱된 데이터가 많을수록 검색 효율성이 증가	문맥을 고려하지 않음. 키워드가 정확히 일치해야 검색 가능
Hybrid Search (하이브리드 검색)	Vector Search와 Keyword Search를 결합하여, 두 방식의 장점을 동시에 활용하는 방식	1. Keyword Search로 문서 검색 2. Vector Search를 적용하여 문서 검색 3. 두 검색 결과를 결합 및 정렬	검색 속도와 정확도를 동시에 개선할 수 있음	두 가지 검색 방식이 모두 필요하므로, 설계가 복잡해지고 연산 비용이 증가할 수 있음

GraphRAG (그래프 기반 RAG)

기본 RAG를 넘어, **지식 그래프(Knowledge Graph)**를 활용하여 검색과 생성의 품질을 향상시키는 그래프 기반 RAG 패턴들이 발전하고 있습니다. 문서를 단순히 벡터로 저장하는 대신, 엔티티와 관계를 그래프 구조로 구축하여 복합적 추론과 전체 코퍼스 요약에 강점을 보입니다.

GraphRAG의 개념과 동작 방식

GraphRAG는 문서를 단순히 벡터로 저장하는 대신, **지식 그래프(Knowledge Graph, KG)**를 구축하여 엔티티 간의 관계를 활용하는 RAG 기법입니다. 기존 벡터 기반 RAG가 어려워하는 전체 문서 집합에 대한 요약·추론 질문과 **다단계 관계 추적(Multi-hop Reasoning)**에 강점을 보입니다.

구축 과정

대부분의 GraphRAG 구현체는 다음과 같은 공통 파이프라인을 따릅니다.

단계	설명
① 엔티티·관계 추출 (Entity & Relation Extraction)	LLM을 활용하여 문서에서 인물, 조직, 장소, 개념 등의 엔티티(Entity)와 엔티티 간 관계(Relation)를 추출
② 지식 그래프 구축 (Graph Construction)	추출된 엔티티를 노드(Node), 관계를 엣지(Edge)로 연결하여 지식 그래프를 구성. 동일 엔티티는 병합(Entity Resolution)하여 중복 제거
③ 그래프 기반 검색 (Graph-based Retrieval)	사용자 질문에 대해 그래프를 탐색하여 관련 엔티티·관계·문서를 검색. 구현체마다 검색 전략이 다름
④ 답변 생성 (Generation)	검색된 그래프 정보와 원본 텍스트를 LLM에 전달하여 최종 답변을 생성

구현체별 차이는 주로 ②와 ③ 단계에서 발생합니다. 그래프 구축 시 **커뮤니티 감지(Community Detection)**를 수행하는지, 검색 시 어떤 전략을 사용하는지가 핵심 차별점입니다.

예시: GraphRAG 적재와 검색 흐름

원본 문서: "김철수는 AI사업부 소속이다. AI사업부는 프로젝트X를 수행한다. 프로젝트X는 금융 도메인에 해당한다."

적재(Ingestion)

• 엔티티 추출: 김철수(인물), AI사업부(조직), 프로젝트X(프로젝트), 금융(도메인)
• 관계 추출: 김철수 →[소속]→ AI사업부, AI사업부 →[수행]→ 프로젝트X, 프로젝트X →[도메인]→ 금융
• 그래프 저장: 4개 노드 + 3개 엣지로 지식 그래프에 저장

검색(Retrieval) — 질문: "금융 관련 프로젝트에 참여하는 사람은?"

• 그래프 탐색: 금융 → 프로젝트X → AI사업부 → 김철수 (3-hop 관계 추적)
• 벡터 기반 RAG는 "금융"과 "김철수"가 같은 청크에 없으면 연결하기 어렵지만, GraphRAG는 엔티티 간 관계를 따라가며 답을 도출

주요 구현체 비교

구분	Microsoft GraphRAG	LightRAG
개발	Microsoft Research (2024)	University of Hong Kong (2024, EMNLP 2025)
성격	그래프 기반 RAG 방법론	경량 그래프 기반 RAG 방법론
그래프 구축 특징	Leiden 알고리즘으로 커뮤니티 감지 후 LLM이 커뮤니티별 요약 생성	커뮤니티 감지 생략 — 엔티티·관계를 직접 검색 대상으로 활용
검색 방식	Global Search (커뮤니티 요약 기반 종합 답변) / Local Search (특정 엔티티 이웃 탐색)	High-Level (상위 개념·주제 검색) / Low-Level (특정 엔티티 중심 검색)
증분 업데이트	지원 (단, 글로벌 요약본 유지를 위한 재계산 비용 발생)	지원 (신규 데이터 병합 및 관계 재구축 최적화)
비용	높음 (커뮤니티 감지·요약에 대량 LLM 호출)	낮음 (커뮤니티 단계 생략으로 비용 대폭 절감)
적합 시나리오	복잡한 전체 문서군 요약/추론	빈번한 문서 업데이트, 비용 효율 중시

프로젝트 도입 시 고려할 점

고려 항목	설명
그래프 구축 비용	엔티티·관계 추출에 대량의 LLM 호출이 필요하며, 문서량에 비례하여 초기 구축 시간과 비용이 증가
엔티티 품질 관리	동일 엔티티의 다양한 표현(예: "LG CNS/엘지씨엔에스/LG씨엔에스")을 병합(Entity Resolution)하는 전략이 검색 품질을 좌우
증분 업데이트 전략	문서가 빈번히 변경되는 환경에서는 전체 재구축 대신 증분 업데이트를 지원하는 구현체가 유리
벡터 RAG와의 역할 분담	모든 질문에 GraphRAG가 필요하지는 않음. 단순 사실 검색은 벡터 RAG, 관계 추론이 필요한 질문은 GraphRAG로 분담하는 Hybrid 구성이 실무적
도메인 특성 반영	추출할 엔티티 유형과 관계 스키마를 도메인에 맞게 사전 정의하면 그래프 품질이 크게 향상

Hyper Edge (하이퍼엣지)

앞서 살펴본 GraphRAG는 엔티티 간의 관계를 **두 노드 사이의 엣지(이진 관계)**로 표현합니다. 그러나 실제 도메인에서는 세 개 이상의 엔티티가 동시에 관여하는 관계도 빈번합니다. **하이퍼엣지(Hyper Edge)**는 이러한 한계를 확장하여, 세 개 이상의 노드를 하나의 엣지로 동시에 연결할 수 있는 하이퍼그래프(Hypergraph)의 구성 요소입니다.

• 다자 관계(N-ary Relation) 표현: "연구자 A, 기관 B, 프로젝트 C가 공동으로 참여한 논문 D"처럼 여러 엔티티가 동시에 관여하는 관계를 하나의 하이퍼엣지로 표현
• GraphRAG와의 연결: 기존 지식 그래프가 이진 관계(Binary Relation)만 표현하는 한계를 극복하여, 복잡한 다자 관계를 그래프 구조에 반영 가능
• 적용: 생물의학(유전자-질병-약물 관계), 학술 네트워크, 공급망 분석 등 복잡한 관계 모델링에 활용

Hybrid RAG (하이브리드 RAG)

Hybrid RAG는 기존 벡터 기반 RAG와 GraphRAG를 복합적으로 결합하여 검색 품질을 극대화하는 파이프라인입니다.

복합 파이프라인 구조

Hybrid RAG는 사용자의 질문 유형에 따라 벡터 검색과 그래프 검색을 병렬 또는 순차적으로 실행하고, 결과를 통합하여 LLM에 전달합니다.

구성 요소	역할
벡터 검색 경로	임베딩 기반으로 의미적으로 유사한 청크를 검색
그래프 검색 경로	지식 그래프에서 엔티티 관계를 추적하여 구조화된 정보를 검색
결과 통합 (Fusion)	두 경로의 결과를 Re-ranking 또는 가중 병합하여 최종 컨텍스트 구성

장점 및 적용 시나리오

• 장점: 단순 유사도 검색의 한계(문맥 단절)와 그래프 검색의 한계(세부 텍스트 누락)를 상호 보완
• 적용 시나리오: 기업 지식 관리 시스템, 복잡한 규제·컴플라이언스 질의, 기술 문서 + 조직 구조가 결합된 질문 처리

RAG의 한계와 평가

RAG의 한계

RAG는 강력한 기술이지만 다음과 같은 한계가 존재합니다. 이러한 문제를 완화하기 위해 Re-ranking, Query Expansion, Agentic Retrieval, GraphRAG 등 다양한 Advanced RAG 패턴이 활용됩니다. 특히 Multi-hop reasoning과 관계 기반 질의에서는 GraphRAG와 같은 접근이 활용될 수 있습니다.

검색 결과의 신뢰성 문제

벡터 검색이 문맥적으로 유사하지만 정확하지 않은 문서를 반환하거나, 키워드 검색이 필요한 문서를 놓칠 가능성이 있습니다. 정확한 문서를 검색하지 못하면 LLM이 부정확한 정보를 바탕으로 응답을 생성할 수 있습니다.

보완 방법:

• Re-ranking (검색 결과 재조정): Cross-Encoder 기반 리랭킹으로 1차 검색 결과(상위 50~100개)의 관련성을 재평가하는 Two-Stage Retrieval 방식이 프로덕션 환경에서 일반적. (Cohere Rerank, cross-encoder/ms-marco-MiniLM)
• Advanced RAG 패턴 활용: GraphRAG는 지식 그래프 기반 관계 추적으로 Multi-hop 질문에 대응

문맥 연결 부족

검색된 정보가 LLM의 응답과 자연스럽게 연결되지 않거나, 여러 문서 중 어떤 정보를 중점 반영할지 판단하기 어려울 수 있습니다.

보완 방법:

• 검색된 문서를 요약·정제하여 Augmentation 품질 향상
• AI 에이전트 기반 반복적 검색과 추론을 통해 문맥에 적합한 정보 수집
• GraphRAG로 문맥적으로 연결된 정보를 함께 검색하여 응답 일관성 향상

"Lost in the Middle" 문제

LLM에 긴 컨텍스트가 제공될 때, 컨텍스트의 시작과 끝 부분 정보는 잘 활용하지만 중간 부분의 정보는 놓치는 경향이 있습니다. 가장 관련성이 높은 문서를 컨텍스트의 앞쪽에 배치하는 전략이 도움이 됩니다.

이 현상은 Liu et al.이 2023년 7월 발표한 "Lost in the Middle" 논문(TACL 2024 게재)에서 처음 체계적으로 보고되었습니다. 이후 MIT(2025년 6월)의 분석에서는 이 현상의 근본 원인이 Transformer 아키텍처의 Causal Masking과 위치 인코딩(Positional Encoding) 설계 방식에 있음을 밝혔으며, 마스킹 기법 변경, 어텐션 레이어 간소화, 위치 인코딩의 전략적 활용 등으로 완화할 수 있다고 제안했습니다. Veseli et al.(2025년 8월, COLM 2025)은 위치 편향의 양상이 입력 길이에 따라 달라짐을 확인했습니다. 컨텍스트 윈도우의 약 50% 이하를 사용할 때는 앞·뒤 정보를 잘 기억하고 중간을 놓치는 전형적인 Lost in the Middle(U자형 패턴)이 뚜렷하고, 50%를 초과하면 이 U자형 패턴은 약해지지만 입력 끝에 가까운 정보를 더 잘 기억하는 **거리 기반 편향(distance-based bias)**이 새롭게 나타납니다. 즉, 편향이 사라지는 것이 아니라 형태가 전환되는 것입니다. Du et al.(2025년 10월, EMNLP 2025 Findings)은 LLM이 관련 정보를 완벽하게 검색하더라도 입력 길이가 증가하는 것만으로 전체 성능이 13.9%~85% 하락함을 확인하여, 최신 모델에서도 위치 편향이 완전히 제거되지 않았음을 보여주었습니다. 따라서 관련 정보를 컨텍스트 앞쪽에 배치하는 전략은 여전히 유효합니다.

RAG 평가 지표

RAG 시스템의 성능을 객관적으로 평가하기 위한 프레임워크와 지표들이 있습니다. RAG 파이프라인은 검색(Retrieval) 단계와 생성(Generation) 단계로 구분되므로, 각 단계를 독립적으로 평가한 뒤 End-to-End 성능을 종합 판단하는 것이 중요합니다.

검색 단계(Retrieval) 평가 메트릭

검색 단계에서는 질문에 대해 관련 문서를 얼마나 정확하고 빠르게 찾아오는지를 평가합니다. 전통적인 정보 검색(Information Retrieval, IR) 분야의 메트릭을 활용합니다.

메트릭	설명	특징
Precision@K	상위 K개 검색 결과 중 관련 문서의 비율	검색 결과의 정밀도 측정
Recall@K	전체 관련 문서 중 상위 K개에 포함된 비율	검색의 포괄성 측정
MRR (Mean Reciprocal Rank)	첫 번째 관련 문서가 등장하는 순위의 역수를 평균한 값	사용자가 원하는 결과를 얼마나 빨리 찾는지 측정
NDCG (Normalized Discounted Cumulative Gain)	검색 결과의 순위별 관련도를 가중 반영한 종합 점수 (0~1)	순위가 낮을수록 할인(discount) 적용, 다단계 관련도 반영 가능
MAP (Mean Average Precision)	Average Precision(AP)를 쿼리 평균한 값	검색 결과 전체의 순위 품질을 종합 평가
Hit Rate (적중률)	상위 K개 결과에 관련 문서가 1개 이상 포함된 쿼리의 비율	가장 직관적인 검색 성공 여부 지표

생성 단계(Generation) 평가 지표

생성 단계에서는 검색된 문서를 바탕으로 LLM이 생성한 답변의 품질을 평가합니다.

지표	설명	측정 내용
Faithfulness (충실도)	생성된 답변이 검색된 문서에 기반하는 정도	답변의 사실 정확성 (환각 방지)
Answer Relevance (답변 관련성)	생성된 답변이 질문에 얼마나 적절한지	답변-질문 정합성
Answer Correctness (답변 정확도)	생성된 답변이 실제 정답과 일치하는 정도 (정답 데이터 필요)	전반적 정확도

RAGAS 프레임워크

**RAGAS(Retrieval Augmented Generation Assessment)**는 RAG 시스템의 품질을 자동으로 평가하는 오픈소스 프레임워크입니다. LLM을 활용하여 검색 품질과 생성 품질을 자동으로 측정하며, CI/CD 파이프라인에 통합하여 지속적 모니터링이 가능합니다.

RAGAS 핵심 메트릭	설명	채점 방식	예시
Faithfulness (충실도)	생성된 답변이 검색된 문서의 내용에만 기반하는 정도. 환각(Hallucination) 탐지 핵심 지표	Reference-free — LLM이 답변과 검색 문서를 비교	검색 문서에 없는 수치를 답변에 포함하면 감점
Answer Relevance (답변 관련성)	생성된 답변이 질문의 의도에 얼마나 적절하게 대응하는지 측정	Reference-free — LLM이 답변과 질문을 비교	"커피 원산지"를 물었는데 "커피 효능"을 답하면 감점
Context Precision (컨텍스트 정밀도)	검색된 문서 중 관련 항목이 상위에 랭크되었는지 측정 (signal-to-noise ratio)	기본값은 Reference 사용, Reference-free 변형도 제공	10건 검색 중 관련 문서 3건이 1·2·3위면 고점, 8·9·10위면 저점
Context Recall (컨텍스트 재현율)	정답 도출에 필요한 정보가 검색된 컨텍스트에 빠짐없이 포함되었는지 측정	Reference 필수 — 정답과 비교해야 누락 판단 가능	정답에 필요한 사실 5개 중 3개만 검색되면 Recall 60%

RAGAS는 정답 데이터(Ground Truth)가 없어도 평가할 수 있으며, LLM이 답변과 검색된 컨텍스트를 비교하여 자동으로 판정합니다. 단, Context Recall·Answer Correctness·Answer Semantic Similarity는 정답 데이터(Reference)가 필수입니다. (LLM-as-a-Judge 상세 → Ch.5 AI Agent 품질 및 보안의 "LLM-as-a-Judge 평가 방법론" 섹션)

RAG 시스템 운영에서는 검색 단계와 생성 단계를 **분리 평가(Component-wise Evaluation)**하여 성능 병목을 진단하는 것이 중요합니다. 예를 들어, Faithfulness 점수가 낮을 때 Context Precision이나 Context Recall도 함께 낮다면 생성이 아닌 검색 단계가 근본 원인일 수 있습니다. 따라서 검색 메트릭(Precision@K, MRR, NDCG 등)과 생성 메트릭(Faithfulness, Answer Relevance 등), 그리고 RAGAS의 Context Precision·Context Recall을 함께 모니터링하는 것이 핵심입니다.

컨텍스트 엔지니어링 (Context Engineering)

프롬프트 엔지니어링이 **"무엇을 어떻게 질문할 것인가"**에 집중한다면, 컨텍스트 엔지니어링(Context Engineering)은 LLM이 추론할 때 사용할 전체 정보 집합(토큰)을 어떻게 구성하고 관리할 것인가에 집중하는 보다 포괄적인 개념입니다. 특히 AI 에이전트 환경에서는 모델이 도구를 호출하고 외부 데이터를 가져오는 과정에서 새로운 정보가 지속적으로 생성되기 때문에, 이러한 정보를 선별·압축·갱신하며 컨텍스트를 관리하는 것이 핵심 과제가 됩니다. Anthropic은 컨텍스트 엔지니어링의 핵심을 컨텍스트 윈도우 내에서 노이즈를 줄이고 고신호(high-signal) 정보를 최대화하는 것으로 설명합니다.

컨텍스트 엔지니어링의 정의

컨텍스트(Context)란 LLM이 응답을 생성할 때 입력으로 사용하는 전체 토큰 집합을 의미하며, 컨텍스트 엔지니어링은 이러한 토큰의 유용성을 모델의 제약(예: 컨텍스트 윈도우 크기) 내에서 최적화하여 일관된 결과를 얻도록 설계하는 엔지니어링 문제입니다.

구분	프롬프트 엔지니어링	컨텍스트 엔지니어링
초점	단일 프롬프트의 효과적 작성	LLM에 전달되는 전체 토큰 상태 관리
범위	사용자 메시지, 시스템 프롬프트	시스템 프롬프트 + 도구 정의 + 예시 + 대화 이력 + 외부 데이터
시점	설계 시점(Design-time) 중심	설계 시점 + 런타임(Runtime) 동적 관리
적용 대상	일회성 단일 LLM 호출	다중 턴 대화, 장기 실행 에이전트
핵심 과제	명확하고 효과적인 질문	정보의 선별, 압축, 갱신, 일관성 유지

컨텍스트 부패와 Attention Budget

컨텍스트 부패 (Context Rot)

컨텍스트 부패(Context Rot)는 컨텍스트 윈도우 내 토큰 수가 증가함에 따라 모델이 중요한 정보를 효과적으로 활용하지 못하는 현상을 의미합니다.

대표적인 증상은 다음과 같습니다.

• 초기 지시사항을 무시
• 중요한 정보 누락
• 일관성 없는 응답 생성

연구에 따르면 긴 컨텍스트에서 모델은 문서의 중간 부분 정보를 잘 활용하지 못하는 "Lost-in-the-middle" 현상을 보이기도 합니다. 이러한 성능 저하는 일반적으로 점진적으로 나타나지만, 모델이 학습된 컨텍스트 길이를 크게 초과할 경우 급격한 성능 저하가 발생할 수도 있습니다. 특히 장기 실행(long-running) AI 에이전트에서는 대화 기록, 도구 결과, 검색 결과 등이 계속 누적되면서 컨텍스트 부패 문제가 더욱 심각해질 수 있습니다.

Attention Budget (주의 예산)

컨텍스트 부패의 한 가지 원인은 LLM이 처리할 수 있는 **Attention Budget(주의 예산)**의 제약입니다. Transformer 아키텍처에서는 각 토큰이 다른 모든 토큰에 주목(attend)하므로, 토큰 수가 n일 때 약 n²개의 관계 계산이 필요합니다. 따라서 컨텍스트가 길어질수록

• attention 계산량 증가
• 중요한 정보에 집중해야 할 attention이 분산
• 신호 대비 노이즈 비율 감소

와 같은 문제가 발생할 수 있습니다. 또한 위치 인코딩은 모델이 학습한 시퀀스 길이를 기준으로 설계되기 때문에, 이를 크게 초과하는 긴 문맥에서는 위치 정보를 정확히 해석하기 어려워 성능이 저하될 수 있습니다. 이러한 이유로 컨텍스트에 추가되는 모든 토큰은 제한된 attention 자원을 소비하므로, 컨텍스트는 한계 수익이 체감하는 유한한 자원으로 관리해야 합니다.

효과적인 컨텍스트 설계

Anthropic에 따르면, LLM에 전달되는 컨텍스트는 시스템 프롬프트, 도구 정의, 예시, 메시지 이력의 네 가지 요소로 구성됩니다. 각 요소의 설계 시 핵심 포인트는 다음과 같습니다.

시스템 프롬프트 — Right Altitude (올바른 높이)

시스템 프롬프트는 LLM의 역할, 규칙, 제약 조건을 정의합니다. Anthropic은 **"Right Altitude(올바른 높이)"**라는 개념으로, 너무 상세하지도 너무 추상적이지도 않은 최적의 지시 수준을 찾는 것이 중요하다고 강조합니다.

실패 모드	설명	문제점
너무 상세함	복잡한 if-else 로직으로 모든 상황을 규정	취약하고 유지보수 어려움, 예외 상황에 대응 불가
너무 추상적	모호한 고수준 지침만 제공	구체적 행동 유도 신호 부족
최적점 (Right Altitude)	행동을 효과적으로 안내할 만큼 구체적이면서, 강력한 휴리스틱을 제공할 만큼 유연함	—

도구 정의 (Tools)

도구의 이름, 설명, 파라미터는 모두 컨텍스트의 일부로 포함되며, 도구 설명의 품질이 에이전트의 성능에 직접 영향을 미칩니다. Anthropic이 제시하는 도구 설계 원칙은 다음과 같습니다.

• Self-contained: 도구가 스스로 완결적이고, 오류에 견고하며, 명확한 의도를 가져야 함
• 토큰 효율적: 반환 정보가 토큰을 낭비하지 않도록 설계
• 중복 최소화: 기능이 겹치는 도구가 많으면 모델이 혼란
• 핵심 기준: "인간 엔지니어가 어떤 상황에서 어떤 도구를 써야 하는지 확실히 말할 수 없다면, AI 에이전트도 마찬가지"

예시 (Few-shot Examples)

Few-shot 예시는 원하는 행동을 시범으로 보여주는 입력-출력 쌍입니다. 도구 호출 방식, 응답 형식, 판단 기준 등을 예시로 제공합니다.

• 다양하고 규범적인(canonical) 예시를 선택하여 원하는 행동 패턴을 보여줌
• 엣지 케이스를 과도하게 나열하지 않음 — 핵심 패턴을 보여주는 것이 더 효과적

메시지 이력 (Message History)

이전 대화 내용, 도구 호출 결과, 중간 추론 과정으로 구성됩니다. 네 요소 중 가장 동적인 요소로, 대화가 진행됨에 따라 지속적으로 증가하며 관리가 필요합니다. 에이전트가 루프 안에서 도구를 반복 호출하면서 생성되는 데이터가 누적되므로, 주기적으로 정제하지 않으면 컨텍스트 부패의 주요 원인이 됩니다.

컨텍스트 검색 전략

적시 검색 (Just-in-Time Context)

모든 데이터를 미리 컨텍스트에 로드하는 대신, **경량 식별자(파일 경로, 저장된 쿼리, 웹 링크 등)**를 유지하고 런타임에 도구를 통해 필요한 시점에 동적으로 로드하는 전략입니다. 인간이 방대한 정보를 외우는 대신 파일 시스템·북마크·검색 엔진으로 필요할 때 검색하는 것과 동일한 원리입니다. RAG(Retrieval-Augmented Generation)가 이를 구현하는 대표적 기술입니다.

점진적 발견 (Progressive Disclosure)

에이전트가 탐색을 통해 관련 컨텍스트를 점진적으로 발견해 나가는 방식입니다. 한 번에 모든 정보를 수집하는 것이 아니라, 메타데이터(파일 크기, 명명 규칙, 타임스탬프 등)를 신호로 활용하여 층층이 이해를 쌓아가는(layer by layer) 접근법입니다.

• 파일 크기 → 복잡도 추정
• 명명 규칙 → 목적 파악
• 타임스탬프 → 관련성 판단
• 장점: 에이전트가 스스로 컨텍스트 윈도우를 관리
• 단점: 런타임 탐색으로 인한 속도 저하

하이브리드 전략

실무에서는 정적 주입과 동적 검색을 결합하는 하이브리드 전략이 일반적입니다. 설계 시점에 미리 고정된 규칙·컨벤션은 정적으로 로드하고(예: CLAUDE.md 파일), 변동 데이터는 도구를 통해 적시에 검색합니다.(예: glob, ripgrep(rg)로 코드베이스 탐색)

장기 작업을 위한 컨텍스트 관리

수십 분에서 수시간 지속되는 장기 작업(대규모 코드 마이그레이션, 종합 리서치 등)에서는 토큰 수가 컨텍스트 윈도우 한계를 초과할 수 있습니다. 이를 해결하는 세 가지 핵심 기법이 있습니다.

기법	설명	적합 시나리오
① 컨텍스트 압축 (Compaction)	컨텍스트 한계에 근접한 대화를 LLM으로 요약하여 압축하고, 요약본으로 대체하여 계속 진행. 핵심은 무엇을 보존하고 무엇을 버릴지 선택하는 것 — 아키텍처 결정, 미해결 버그, 구현 세부사항은 보존하고, 중복된 도구 출력은 제거	광범위한 왕복이 필요한 작업 (대화 흐름 유지)
② 구조화된 노트 (Structured Note-Taking)	에이전트가 작업 중 핵심 정보를 컨텍스트 윈도우 외부의 파일에 주기적으로 기록하고, 필요 시 다시 읽어오는 기법. 진행 상태, 핵심 결정사항, 발견된 사실 등을 정리하여 보관	명확한 마일스톤이 있는 반복적 개발
③ 하위 에이전트 아키텍처 (Sub-Agent)	복잡한 작업을 독립적인 하위 에이전트로 분리하여 각각 깨끗한 컨텍스트에서 실행. 하위 에이전트는 많은 토큰을 사용한 뒤 **축약된 요약(1,000~2,000 토큰)**만 메인 에이전트에 반환	병렬 탐색이 효과적인 복잡한 리서치·분석

Anthropic은 Server-side Compaction을 API 기능으로 공식 제공(Claude Opus 4.6/Sonnet 4.6, 베타)하며, 입력 토큰이 설정 임계값(예: 150,000 토큰)을 초과하면 자동으로 이전 대화를 요약·압축하여 컨텍스트 한도를 넘는 장기 대화를 지원합니다.

토큰 예산 관리 (Token Budget Management)

컨텍스트 윈도우는 유한한 자원이므로, **토큰 예산(Token Budget)**을 체계적으로 배분하는 것이 컨텍스트 엔지니어링의 핵심 실무입니다.

최대 유효 컨텍스트 윈도우 (Maximum Effective Context Window)

모델이 공시하는 최대 컨텍스트 윈도우(MCW)와 실제로 안정적인 성능을 유지하는 **최대 유효 컨텍스트 윈도우(MECW, Maximum Effective Context Window)**는 다릅니다.

최근 연구들은 컨텍스트를 많이 채울수록 성능이 비선형적으로 저하됨을 보여주고 있습니다.

2026년 기준 주요 모델의 공시 컨텍스트 윈도우 크기는 다음과 같습니다.

모델	컨텍스트 윈도우	비고
Claude Opus 4.6, Sonnet 4.6	1M 토큰 (GA)	2026.03.13부터 일반 가용(GA), 프리미엄 요금 없이 표준 요금 적용
Claude Sonnet 4.5, Sonnet 4	200K 토큰 (기본) / 1M 토큰 (베타)	200K 초과 시 프리미엄 요금 적용, Usage Tier 4 이상 필요
GPT-5.4	1M 토큰	2026년 3월 출시, 추론+비추론 통합 모델
GPT-5.4 mini / nano	400K 토큰	GPT-5.4의 경량 변형
GPT-4.1	1M 토큰	GPT-4o(128K)의 후속, 2025년 4월 출시
Gemini 2.5 Pro	1M 토큰	—

연구	핵심 발견
Context Rot (Chroma Research, 2025)	컨텍스트 길이가 증가하면 성능이 비균등하게(non-uniform) 저하되는 "컨텍스트 부패(Context Rot)" 현상이 발생하며, 저하 양상은 모델마다 다름. 컨텍스트를 희소 자원으로 취급하고 외과적으로 관리해야 함
MECW 연구 (Paulsen, 2025)	공시 컨텍스트 윈도우(MCW)와 실제 유효 윈도우(MECW) 사이에 상당한 격차 존재. 일부 모델은 1,000 토큰만으로도 성능이 크게 저하되며, 작업 유형에 따라 MECW가 달라짐
EMNLP 2025 (Du et al.)	검색이 완벽해도 입력 길이 자체가 성능을 13.9%~85% 하락시킴. 불필요한 토큰을 공백으로 대체해도 성능 저하 발생

실무 권장 사항:

• 컨텍스트 윈도우의 100%를 채우지 않는다 — 실무적으로 60~75% 이하 사용이 권장되며, Paulsen(2025)에 따르면 일부 모델은 공시 윈도우의 1%만 채워도 성능이 저하됨
• 긴 문서는 컨텍스트 상단에 배치하고, 질의(query)는 하단에 배치하면 정확도가 최대 30% 향상 (Anthropic 권장)
• LLM에게 관련 정보를 인용(recite)한 뒤 답변하도록 유도하면 긴 컨텍스트에서의 정확도가 약 4% 향상 (Du et al., EMNLP 2025)
• Extended Thinking 사용 시 thinking 토큰도 컨텍스트 윈도우에 포함되나, 이전 턴의 thinking 블록은 API가 자동 제거하여 토큰 낭비를 방지함

토큰 배분 전략 예시

LLM은 입력 토큰(Input)과 출력 토큰(Output)의 합이 모델의 최대 컨텍스트 길이(Context Window)를 초과할 수 없습니다. 따라서 시스템을 설계할 때는 컨텍스트 윈도우를 여러 요소에 계획적으로 분배(Token Budgeting) 해야 합니다.

컨텍스트 구성 요소	권장 비율	설명
시스템 프롬프트	5~15%	역할, 규칙, 제약 조건 정의
도구 정의	5~10%	사용 가능한 도구의 이름, 설명, 파라미터
검색된 컨텍스트 (RAG)	30~50%	외부 검색 결과, 관련 문서
대화 이력	10~20%	이전 대화 내용, 중간 결과
응답 생성 여유	20~30%	LLM이 응답을 생성할 충분한 공간 확보

※ 위 배분 비율은 일반적인 설계 예시일 뿐이며, 모델의 컨텍스트 길이, 응답 길이 요구사항, RAG 문서 크기, 에이전트 구조 등 프로젝트 요구사항에 따라 조정이 필요합니다.

토큰 관리 기법

기법	설명
우선순위 기반 삭제	토큰 한도 초과 시 오래된 대화 이력부터 순차적으로 제거
요약 압축	긴 대화 이력을 LLM으로 요약하여 토큰 절약 (컨텍스트 압축과 동일 원리)
동적 할당	질문 유형에 따라 검색 결과와 대화 이력의 비율을 동적으로 조정
청크 크기 최적화	RAG 검색 시 반환하는 청크의 수와 크기를 토큰 예산에 맞게 조절
컨텍스트 인식 (Context Awareness)	Claude Sonnet 4.6/4.5, Haiku 4.5는 남은 토큰 예산을 실시간으로 추적하는 Context Awareness 기능을 보유. 모델이 잔여 컨텍스트를 인식하여 장기 실행 에이전트 작업 시 토큰을 효율적으로 배분. Anthropic은 이를 "시계 없이 요리 대회에 참가하는 것"에 비유하여, 잔여 시간(토큰)을 아는 것의 중요성을 강조

컨텍스트 엔지니어링 활용

활용 분야	설명
AI 기반 고객 상담	고객 이력, 상품 정보, FAQ를 적시 검색하여 컨텍스트 구성
코딩 에이전트	프로젝트 구조, 코딩 컨벤션, 관련 파일을 동적으로 컨텍스트에 주입
문서 분석 시스템	대용량 문서의 관련 섹션만 선별적으로 컨텍스트에 포함
멀티 에이전트 시스템	각 에이전트에 역할별 최적화된 컨텍스트를 분리 제공
장기 실행 워크플로우	컨텍스트 압축과 구조화된 노트로 일관성 유지

한눈에 정리하는 이번 챕터

• AI에서 Knowledge는 모델이 추론에 활용하는 구조화된 정보(DIKW 피라미드)이며, RAG·Fine-tuning·Knowledge Graph·Context Engineering 등의 방법으로 LLM에 제공된다.
• RAG는 외부 DB에서 관련 정보를 검색(Retrieval)하여 LLM 답변을 보강(Generation)하는 기술로, 데이터 전처리→청킹→임베딩→벡터DB 파이프라인으로 구성되며 Vector/Keyword/Hybrid 검색 방식을 사용한다.
• GraphRAG는 지식 그래프를 구축하여 엔티티 간 관계를 활용하는 기법으로, Microsoft GraphRAG(커뮤니티 감지), LightRAG(경량·증분 업데이트) 등의 구현체가 있다.
• RAG에는 검색 신뢰성, 문맥 연결 부족, Lost in the Middle 등의 한계가 있으며, Re-ranking과 GraphRAG 패턴으로 보완한다.
• RAGAS 프레임워크는 Faithfulness·Answer Relevance를 정답 없이(Reference-free) LLM-as-a-Judge로 자동 판정하며, Context Recall 등 일부 메트릭은 정답 데이터(Reference)가 필수이다.
• 컨텍스트 엔지니어링은 "원하는 결과의 가능성을 최대화하는 가장 작은 고신호 토큰 집합을 찾는 것"이 핵심이며, 시스템 프롬프트(Right Altitude)·도구 정의·예시·메시지 이력의 4대 요소를 설계한다.
• 컨텍스트 윈도우 내 토큰이 증가하면 Attention Budget 제약으로 정보 회상이 저하되는 컨텍스트 부패(Context Rot)가 발생한다.
• 장기 작업에서는 컨텍스트 압축(Compaction), 구조화된 노트(Structured Note-Taking), 하위 에이전트(Sub-Agent)로 대응한다.
• 토큰 예산 관리 측면에서 공시 컨텍스트 윈도우(MCW)와 실제 유효 윈도우(MECW) 사이에 격차가 있어 60~75% 이하 사용이 권장된다.

참고자료 (References)

• DataCamp, "The Data-Information-Knowledge-Wisdom Pyramid"
• Gartner, "2024 Strategic Roadmap for World-Class Security of Unstructured Data", 2024
• Microsoft Research, "From Local to Global: A Graph RAG Approach to Query-Focused Summarization", 2024
• Guo, Z. et al., "LightRAG: Simple and Fast Retrieval-Augmented Generation", EMNLP 2025 Findings
• Sarmah, B. et al., "HybridRAG: Integrating Knowledge Graphs and Vector Retrieval Augmented Generation for Efficient Information Extraction", ACM ICAIF 2024
• Luo, H. et al., "HyperGraphRAG: Retrieval-Augmented Generation via Hypergraph-Structured Knowledge Representation", NeurIPS 2025
• Pinecone, "Rerankers and Two-Stage Retrieval"
• Liu, N. et al., "Lost in the Middle: How Language Models Use Long Contexts", TACL 2024
• MIT, "Unpacking the bias of large language models", 2025.06
• Veseli, B. et al., "Positional Biases Shift as Inputs Approach Context Window Limits", COLM 2025
• Du, Y. et al., "Context Length Alone Hurts LLM Performance Despite Perfect Retrieval", EMNLP 2025 Findings
• Manning, C. et al., "Introduction to Information Retrieval", Cambridge University Press
• RAGAS Documentation
• RAGAS Documentation, "Metrics - Context Precision / Context Recall"
• Anthropic, "Effective context engineering for AI agents"
• Anthropic, "Context Windows"
• OpenAI, "Introducing GPT-4.1 in the API"
• Chroma Research, "Context Rot", 2025
• Paulsen, "Context Is What You Need: The Maximum Effective Context Window", 2025
• Anthropic, "Long Context Prompting Tips"
• Anthropic, "Compaction"