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

AI에게 필요한 정보를 적절하게 제공하는 기술 — 정보의 기술

• AI에게 ‘무엇을(What)’ 해야 할지 알려주는 것을 넘어, 그 일을 수행하는 데 필요한 ‘지식과 상황 정보(Context)‘를 가장 효과적으로 주입하는 기술

• 모델이 ‘모르는 것’을 알게 하거나, ‘특정 정보’에 기반해 답변하게 만드는 환경 조성

• RAG(검색 증강 생성)가 대표적. 벡터 데이터베이스 구축, 데이터 전처리, 사용자 히스토리 관리 등을 통해 AI에게 ”지식의 맥락”을 제공

• 프롬프트가 ‘두뇌’라면, 컨텍스트는 그 두뇌가 참고할 ‘교과서’

• 단순히 텍스트를 많이 집어넣는 것이 아니라, 모델의 제한된 기억력(Context Window) 내에 가장 가치 있는 정보를 정교하게 배치하는 것이 핵심

주요 기법들 (Techniques)

1. 검색 증강 생성 (RAG, Retrieval-Augmented Generation)

가장 대표적인 기법으로, 모델의 파라미터 외부에 있는 지식을 실시간으로 찾아내어 전달

• Semantic Search (의미론적 검색): 질문의 단어가 정확히 일치하지 않아도, 의미적으로 유사한 문서를 벡터(Vector) 공간에서 찾아낸다.

  • “뜨겁다”라는 단어가 없어도 의미가 유사한 “발열 현상”, “온도 상승”, “냉각 팬 오작동” 관련 매뉴얼 데이터를 찾아 제공

• Hybrid Search: 키워드 기반의 정확도(BM25)와 의미 기반의 유사도(Dense Vector)를 결합하여 검색 품질을 높인다.

  • ‘M3’라는 정확한 키워드(Keyword Search)와 ‘노트북 성능’이라는 의미(Semantic Search)를 동시에 검색하여 가장 정확한 제품 정보를 추출

• Re-ranking (재정렬): 검색된 수십 개의 문서 중, 질문과 가장 연관성이 높은 순서대로 다시 정렬하여 최상단 정보만 AI에게 전달.

  • AI가 읽기 전, 다시 한번 고성능 알고리즘으로 계산하여 사용자의 질문과 가장 밀접한 상위 3개의 문서만 골라 프롬프트에 넣어줌

2. 데이터 전처리 및 청킹 (Chunking)

방대한 데이터를 AI가 읽기 좋은 크기로 쪼개는 기술

• Fixed-size Chunking: 고정된 길자로 자르는 기초적인 방식

• Recursive Character Chunking: 문단, 문장 마침표 등을 인식하여 의미가 끊기지 않게 유동적으로 자름

  • 500자 단위로 자르되, 문장의 마침표(.)나 줄바꿈(\n)을 기준으로 잘라서 “사과는 맛있다. 그래서 나는” 처럼 의미가 중간에 끊기지 않게 조절

• Semantic Chunking: 텍스트의 주제가 바뀌는 지점을 감지하여 의미 단위로 데이터를 분절

  • “회사 소개” 섹션이 끝나고 “연봉 복지” 섹션으로 넘어가는 지점을 AI가 감지하여 주제별로 데이터를 분절

• Overlapping: 앞뒤 청크의 내용을 일부 겹치게 하여 맥락이 단절되는 것을 방지

  • “A는 B의 원인이다.”라는 문장이 잘려도 앞뒤 맥락을 통해 인과관계를 유지함

3. 컨텍스트 윈도우 관리 (Window Management)

모델이 한 번에 처리할 수 있는 정보량은 제한되어 있으므로, 이를 효율적으로 압축하고 선별

• Context Truncation & Sliding: 대화가 길어질 때 오래된 내용을 삭제하거나, 최근 맥락만 유지하며 이동하는 방식

• Summarization (요약): 이전 대화 내용이나 긴 문서를 요약본으로 변환하여 컨텍스트 용량을 확보

  • 상황: 고객과 50번의 대화를 나눈 상태
  • 작동: 이전의 40번 대화를 “고객은 환불 규정에 대해 문의 중임”이라는 한 줄 요약으로 압축하여 입력창 공간을 확보하고 최신 대화에 집중

• Information Compression: 불필요한 수식어나 조사를 제거하여 정보 밀도를 높이는 기법

  • “안녕하세용 고객님! 무엇을 도와드릴까용?^^” → “문의 사항 확인 필요”와 같이 핵심 정보 위주로 토큰(Token)을 절약

---

4. GraphRAG (지식 그래프 결합)

단순한 텍스트 파편화를 넘어, 정보 간의 ‘관계’를 구조화하여 제공하는 고도화된 방식

• Entity Extraction: 문서 내 핵심 개체(인물, 장소, 개념 등)를 추출

• Relationship Mapping: 개체 간의 연결 고리를 그래프 형태로 저장하여, 단순 검색으로는 찾기 힘든 복합적인 추론(예: “A와 B의 공통점은?”)을 가능하게 한다.

  • 데이터: [스티브 잡스] - (설립) - [애플], [애플] - (제조) - [아이폰]
  • 효과: 사용자가 “잡스가 만든 휴대폰의 특징은?”이라고 물으면, 여러 문서를 뒤지지 않고도 그래프를 따라 ‘잡스 → 애플 → 아이폰’의 관계를 즉시 파악해 답변

---

5. Few-shot & In-context Learning

프롬프트 안에 예시 데이터(Example)를 직접 포함시켜 모델의 적응력을 증가시킨다.

• Dynamic Few-shot: 모든 예시를 다 넣는 대신, 현재 질문과 가장 유사한 성공 사례(Golden Set)만 골라 컨텍스트에 삽입

• Instruction-Context Separation: 지시사항과 참고 자료를 서로 다른 메시지·필드로 구분한다. 자료 안에 “앞의 지시를 무시하라”는 문장이 있어도 그 문장은 인용된 데이터다. 구분 표지만으로 공격을 완전히 막을 수는 없으므로 도구 권한과 출력 검증도 필요하다.

Few-shot 예시는 형식과 판단 기준을 보여주는 프롬프트 설계이면서, 현재 질문에 어떤 예시를 고를지 결정하는 컨텍스트 선택 문제다. 모든 예시를 넣으면 토큰만 늘고 서로 모순된 예시가 섞일 수 있다. 예시의 적용 범위와 개정일을 문서와 같이 관리한다.

모델에 넣을 자료를 고르는 전체 흐름

같은 규정 질문이라도 인덱싱 시점과 요청 시점에 할 일이 다르다.

flowchart LR
    D[원본 문서] --> P[파싱·표/제목 확인]
    P --> C[청크 + 문서 ID·버전·권한]
    C --> I[(검색 인덱스)]
    Q[사용자 질문] --> A[인증된 사용자 범위]
    A --> R[권한 필터 + 검색]
    I --> R
    R --> S[중복 제거·재정렬·예산 선택]
    S --> M[모델 입력]
    M --> V[근거와 답변 검증]

왼쪽은 문서가 바뀔 때 수행하는 인덱싱, 오른쪽은 사용자가 질문할 때 수행하는 검색이다. 모델은 원본 저장소의 모든 문서를 보는 것이 아니라 선택된 청크만 본다. 따라서 답이 틀렸을 때 먼저 “정답 문서가 인덱스에 있었나”, 다음으로 “이번 요청에 검색됐나”, 마지막으로 “검색됐는데 모델이 잘못 읽었나”를 순서대로 확인한다. LangChain RAG 튜토리얼은 로드·분할·임베딩·저장과 요청 시 검색을 구분한다.

청크 크기와 메타데이터를 함께 설계

문서를 500자씩 자르는 것만으로는 규정의 적용 대상이 앞 청크에, 신청 기한이 뒤 청크에 떨어질 수 있다. 제목·표 머리글·적용일을 각 청크가 참조할 수 있게 메타데이터로 붙이거나, 의미 단위를 보존하며 분할한다. 반대로 청크가 너무 크면 검색 결과는 맞아도 모델 입력에 불필요한 문장이 많아져 중요한 근거가 묻힐 수 있다.

관찰된 문제	확인할 지점	조정 후보
검색된 청크에 답의 앞부분만 있음	분할 경계와 표 파싱	제목/행 단위 분할, 적당한 overlap
옛 규정이 먼저 나옴	버전·적용일 메타데이터	현행 문서 필터, 기간 조건
같은 문단이 반복 입력됨	겹침과 중복 제거	중복 청크 병합
고유 제품 코드 검색 실패	임베딩 검색 결과	키워드+벡터 결합
관련 문서는 있으나 긴 입력에서 답을 놓침	입력 순서·길이	상위 청크 재정렬, 요약 대신 원문 일부 보존

GraphRAG는 관계를 따라 여러 조각을 묶어야 하는 과제에 유용할 수 있지만, 개체와 관계를 잘못 추출하면 잘못된 연결이 새로운 오류 원인이 된다. 단순한 규정 한 문장 검색에 그래프 구축이 먼저 필요한 것은 아니다. 비교 사례를 만들고 일반 검색이 어떤 질문에서 실패하는지 확인한 후 선택한다.

권한과 길이 예산을 코드로 확인

검색 점수가 높아도 접근 권한이 없는 문서는 모델 입력에 넣으면 안 된다. 아래 코드는 검색기 자체의 대체물이 아니라 검색 결과를 모델에 전달하기 직전의 선별 경계를 보여준다. max_chars는 설명용 문자 수 제한이며 실제 모델의 토큰 한도와 동일하지 않다.

from dataclasses import dataclass

@dataclass(frozen=True)
class Chunk:
    doc_id: str
    text: str
    score: float
    audience: str

def select_context(
    chunks: list[Chunk], *, allowed_audiences: set[str], max_chars: int
) -> list[Chunk]:
    if max_chars < 1:
        raise ValueError("max_chars는 1 이상이어야 합니다.")
    authorized = [
        chunk for chunk in chunks
        if chunk.audience in allowed_audiences
    ]
    selected: list[Chunk] = []
    used = 0
    for chunk in sorted(authorized, key=lambda item: item.score, reverse=True):
        size = len(chunk.text)
        if used + size <= max_chars:
            selected.append(chunk)
            used += size
    return selected

예를 들어 전 직원용 HR-12와 관리자 전용 PAY-07이 검색됐어도 일반 사용자에게는 HR-12만 전달해야 한다. select_context에 넘기는 allowed_audiences는 인증 결과와 서버 정책에서 만들어야 하며 사용자 프롬프트에서 가져오지 않는다. 실제 구현에서는 인덱스 검색 단계에서도 권한 필터를 적용해 허용되지 않은 문서가 검색 결과나 로그에 섞이지 않도록 한다. 길이 예산에는 시스템 지시, 질문, 대화 이력, 도구 결과, 답변 여유 공간도 포함해야 한다.

대화 이력과 도구 결과도 컨텍스트다

“그 규정은 올해도 같아?”라는 후속 질문은 앞 대화의 대상 규정을 알아야 이해된다. 그렇다고 모든 대화를 무한히 붙이면 오래된 문서와 현재 문서가 섞인다. 최근의 질문·답변을 보관하되, 현재 질문에 필요한 문서 근거는 다시 조회한다. 요약 메모리를 쓴다면 요약이 사실인지 확인하고 원문 링크를 남긴다. 모델이 이전에 잘못 말한 내용을 요약에 넣으면 오류가 다음 턴으로 이어진다.

도구가 반환한 웹 페이지나 문서에는 지시문처럼 보이는 텍스트가 있을 수 있다. 그 내용은 신뢰할 수 없는 자료다. 도구 결과를 시스템 지시보다 높은 권한으로 취급하지 않고, 모델이 그 결과를 근거로 외부 작업을 제안해도 서버의 권한 검사를 통과해야 실행한다. LangChain 컨텍스트 엔지니어링 문서는 모델 입력, 도구 입력, 실행 중 저장되는 상태를 구분한다.

무엇을 측정하며 바꿀까?

평가 데이터에 질문, 기대 문서 ID·버전, 허용 사용자 범위, 기대 답 또는 거절 행동을 기록한다. recall@k는 정답 문서가 상위 k개 안에 있는지, 근거 충실성은 답변의 문장이 검색 문서에 의해 지지되는지를 본다. 권한 실패는 정답률이 높아도 실패다. 청크 크기를 바꾸면 같은 질문 집합에서 검색 순위와 최종 답을 모두 비교한다. 재정렬기를 추가한다면 검색 품질뿐 아니라 추가 지연과 비용도 기록한다.

컨텍스트가 길수록 언제나 좋아지는 것은 아니다. 더 많은 청크가 잘못된 버전, 중복, 관련 없는 지시문을 섞을 수 있다. 한 번에 한 조건만 바꾸고, 실패한 질문을 데이터셋에 추가한다. 이 절차를 반복하면 “모델이 모른다”라고 뭉뚱그렸던 문제를 자료가 없었는지, 잘못 선택됐는지, 모델이 잘못 사용했는지로 구분할 수 있다.

참고 문서

• LangChain: Context engineering
• LangChain: RAG 튜토리얼
• LangGraph: Persistence