길리랩blog

컨텍스트 엔지니어링 설계: JIT 어셈블리로 RAG·MCP·파인튜닝 통합하기

컨텍스트 엔지니어링이 프롬프트, RAG, MCP, 파인튜닝을 JIT 어셈블리와 토큰 예산 관리로 통합하는 방식과 거버넌스를 설명한다.

2026-08-14 · 최초 발행 2026-06-10

모델 호출 직전의 정보 구성이 품질을 좌우한다

2026년 AI 엔지니어링에서 빠르게 부상한 컨텍스트 엔지니어링(Context Engineering)은 프롬프트 엔지니어링, RAG, MCP, 파인튜닝을 서로 떨어진 기법으로 다루지 않는다. 모델이 추론하는 순간 필요한 정보를 컨텍스트 윈도우에 정확하게 배치한다는 하나의 목표 아래 이들을 통합한다.

RAG 공동 창시자 Douwe Kiela가 주창하고 arXiv 2603.09619에서 학술적 정의가 공식화된 패러다임이다. 개발자의 65%가 AI 코드 품질 저하의 원인을 모델 성능보다 컨텍스트 누락에서 찾았다는 설문 결과도 이러한 전환이 현장의 요구와 맞닿아 있음을 보여준다.

기술의 초점은 단계적으로 이동했다. 2024년에는 Few-shot 예시와 Chain-of-Thought 유도를 포함한 프롬프트 엔지니어링이 주류였다. 지시를 어떤 문장과 형식으로 전달할지가 핵심이었지만, 모델이 모르는 도메인 지식이나 최신 정보에는 접근할 수 없었다.

2025년에는 RAG(Retrieval-Augmented Generation)가 외부 지식을 런타임에 주입하며 이 공백을 메웠다. 벡터 데이터베이스를 이용한 의미론적 검색에서 하이브리드 검색과 재순위화 파이프라인까지 발전했고, 기업 AI 시스템의 표준 아키텍처로 정착했다. 다만 지식에 접근하는 문제를 해결했을 뿐, 검색한 정보를 어떻게 조합할지는 여전히 경험과 직관에 의존했다.

2026년의 질문은 다르다. 무엇을 검색할지가 아니라, 모델의 추론 시점에 컨텍스트 윈도우 안에 무엇이 존재해야 하는지를 설계한다.

⤢✕2024년: 프롬프트 엔지니어링Few-shot /Chain-of-Thought한계: 도메인 지식 부재2025년: RAG 아키텍처벡터 DB 기반 외부 지식 주입한계: 컨텍스트 구성 전략 부재2026년: 컨텍스트 엔지니어링JIT 어셈블리 + 멀티소스 융합RAG / MCP / 파인튜닝 / 캐시통합컨텍스트 윈도우 최적 구성AI 출력 품질 극대화

arXiv 2603.09619는 컨텍스트 엔지니어링을 “LLM이 태스크를 수행하는 데 필요한 모든 정보를 적시에, 적절한 형식으로, 적절한 양만큼 컨텍스트 윈도우에 배치하는 학문 및 실천 체계”로 정의한다. 정의의 중심에는 적시성(timeliness), 형식 적합성(format appropriateness), 양적 최적화(quantity optimization)가 있다.

Douwe Kiela는 이를 단순한 프롬프트 최적화의 확장판이 아니라 상위 개념으로 배치한다. 프롬프트 엔지니어링이 정적인 텍스트 조작에 집중했다면, 컨텍스트 엔지니어링은 동적 런타임 조립과 다중 소스 통합, 토큰 예산 최적화까지 포괄하는 시스템 공학적 접근이다.

산업계의 움직임도 이어졌다. 2026년 상반기 기준 Salesforce, Microsoft, Google의 엔터프라이즈 AI 팀은 내부적으로 컨텍스트 엔지니어링 역할을 별도 직군으로 정의하기 시작했고, 여러 스타트업은 컨텍스트 관리 전용 미들웨어 플랫폼을 출시했다.

정적 프롬프트만으로는 확장할 수 없다

프롬프트는 작성 시점에 고정된다. 사용자의 세션 이력이나 현재 시스템 상태, 최신 도메인 지식이 바뀌어도 요청마다 동일한 맥락을 제공한다면 변화한 조건을 실시간으로 반영하기 어렵다.

방어적으로 확장한 시스템 프롬프트는 또 다른 문제를 만든다. 태스크와 관계없는 정보까지 컨텍스트 윈도우를 차지하면서 유용한 정보의 밀도가 낮아지고, 모델이 관련 정보에 집중할 수 있는 주의력도 희석된다.

도메인 지식이 늘어날수록 프롬프트 자체도 비대해진다. 일정 규모를 넘으면 수작업으로 관리할 수 없으며, 자동화된 컨텍스트 선택 메커니즘 없이 엔터프라이즈 규모로 확장하기도 어렵다. 컨텍스트 엔지니어링은 이 세 문제를 모델 호출 전의 동적 조립 과정으로 옮겨 해결한다.

요청에 맞춰 조립하는 JIT 컨텍스트

JIT(Just-In-Time) 컨텍스트 어셈블리는 컨텍스트를 미리 고정하지 않는다. 소프트웨어 공학의 JIT 컴파일 개념처럼 모델을 호출하기 직전에 해당 요청에 맞는 정보를 찾아 조립한다.

사용자 쿼리를 분석한 뒤 필요한 정보를 사실적 지식(factual knowledge), 절차적 지식(procedural knowledge), 컨텍스트적 지식(contextual knowledge)으로 나눈다. 사실적 지식은 벡터 DB와 구조화 DB, 절차적 지식은 코드베이스와 문서, 컨텍스트적 지식은 세션 이력과 사용자 프로파일에서 병렬로 검색한다.

검색 결과를 유사도 순서대로 넣는 것만으로는 충분하지 않다. 의미가 같은 청크는 중복 제거(Deduplication)로 합치고, MMR(Maximal Marginal Relevance)을 적용해 관련성과 정보 다양성을 함께 확보한다. 선택한 청크가 다른 전제 정보를 참조한다면 의존성 그래프 추적(Dependency Tracking)을 통해 해당 정보도 포함해야 한다.

관련성 점수 역시 임베딩 유사도 하나로 결정하지 않는다. 쿼리와 청크의 의미 유사도, 태스크 유형 적합도, 소스 권위성에 따른 청크 신뢰도, 시간적 최신성을 가중 합산한다.

def compute_relevance_score(chunk, query, task_type, alpha=0.4, beta=0.3, gamma=0.2, delta=0.1):
    semantic_sim  = embed_similarity(chunk.embedding, query.embedding)
    type_fit      = task_type_alignment(chunk.content_type, task_type)
    authority     = source_authority_score(chunk.source)
    recency       = time_decay(chunk.timestamp, half_life_days=30)
    return alpha * semantic_sim + beta * type_fit + gamma * authority + delta * recency

토큰 예산은 컨텍스트의 정보 밀도를 결정한다

컨텍스트 윈도우는 무한한 저장 공간이 아니다. 시스템 프롬프트, 검색 컨텍스트, 세션 이력, 사용자 입력, 출력 예비 공간으로 영역을 나누고 태스크에 따라 동적으로 예산을 배정해야 한다.

⤢✕전체 컨텍스트 윈도우(예: 128K 토큰)시스템 프롬프트(5-10%)검색 컨텍스트(40-50%)세션 히스토리(20-30%)사용자 입력(10-15%)출력 예비 공간(10-20%)RAG 청크MCP 도구 결과압축된 대화 요약핵심 의사결정 히스토리

예산을 넘으면 관련성 점수가 낮은 청크부터 제거한다. 시스템 프롬프트와 사용자 입력은 고정 영역으로 보호한다.

압축 방식은 데이터 성격에 따라 달라진다. 추출적 압축(Extractive Compression)은 긴 문서에서 쿼리와 관련성이 높은 문장만 골라 원문 표현을 유지한다. LLMLingua와 Selective Context가 이 방식을 구현하며, 평균 3~5배의 압축률과 90% 이상의 정보 보존율을 달성한다.

생성적 압축(Abstractive Compression)은 소형 LLM으로 검색 문서를 쿼리 맥락에 맞게 요약한다. 원문보다 정보 밀도를 높일 수 있지만, 요약 중 발생할 수 있는 환각을 별도로 검증해야 한다.

코드와 테이블, JSON에는 구조적 압축(Structural Compression)이 맞는다. 반복 패턴을 제거하고 핵심 스키마와 대표 예시를 남기는 방식이다. 코드베이스에서는 관련 함수 시그니처와 독스트링만 선택하는 코드 스켈레톤 형태로 널리 활용된다.

RAG·MCP·파인튜닝·캐시를 병렬로 묶는다

하나의 소스에만 의존하면 그 소스의 약점이 곧 전체 컨텍스트 품질의 병목이 된다. 멀티소스 파이프라인은 RAG, MCP, 파인튜닝, 인메모리 캐시를 병렬로 조합한다.

RAG는 도메인 특화 문서와 기업 내부 KB처럼 방대한 외부 지식에 접근하거나 실시간 갱신이 필요한 정보를 가져오는 데 유리하다. 대신 검색 지연과 관련성 노이즈를 감수해야 한다.

MCP(Model Context Protocol)는 현재 시스템 상태, API 응답, 코드 실행 결과처럼 동적인 정보를 실시간 도구 실행을 통해 주입한다. 2025년 Anthropic의 표준화 이후 에이전트 시스템의 핵심 인터페이스로 자리 잡았다.

파인튜닝은 정보를 컨텍스트가 아닌 모델 가중치에 내재화한다. 컨텍스트 엔지니어링에서는 이를 암묵적 컨텍스트(implicit context)의 원천으로 해석한다. 반복되는 도메인 패턴이나 형식 규칙을 모델에 체화하면 명시적으로 투입할 컨텍스트를 줄일 수 있다.

인메모리 캐시는 세션 안에서 반복 참조하는 청크와 사용자 프로파일, 시스템 설정을 메모리에 보관해 반복 검색 비용을 없앤다. KV 캐시 프리필링(KV Cache Prefilling)과 결합하면 추론 비용도 절감할 수 있다.

⤢✕사용자 쿼리JIT 컨텍스트 오케스트레이터RAG 검색 엔진MCP 도구 실행파인튜닝 모델(암묵적 컨텍스트)인메모리 캐시벡터 DB 결과(의미 검색)BM25 결과(키워드 검색)실시간 API 응답코드 실행 결과세션 히스토리 청크사용자 프로파일신호 융합 레이어토큰 예산 최적화컨텍스트 압축최종 컨텍스트 윈도우LLM 추론

서로 다른 신호를 연결하기 전에 충돌부터 다룬다

멀티소스 결과를 단순 연결(concatenation)하면 중복 정보와 상충하는 정보가 그대로 섞인다. 신호 융합(Signal Fusion) 레이어는 출처의 신뢰도와 최신성을 비교해 이 문제를 조정한다.

먼저 소스마다 기준 신뢰도 점수를 부여한다. 공식 기술 문서는 높은 권위 점수를 받고, 사용자 생성 콘텐츠에는 상대적으로 낮은 점수가 적용된다. MCP가 실시간으로 가져온 데이터는 최신성 측면에서 높은 가중치를 받는다.

시간적 가치가 큰 정보에는 최신성 가중도 필요하다. 변화가 빠른 기술 분야에서는 6개월 전 정보와 최신 정보의 가치가 크게 다를 수 있다. 지수 감쇠(Exponential Decay) 함수로 정보의 연령에 따라 관련성 점수를 조정한다.

import math

def time_weighted_score(base_score, created_at, half_life_days=30):
    days_elapsed = (datetime.now() - created_at).days
    decay_factor = math.exp(-0.693 * days_elapsed / half_life_days)
    return base_score * decay_factor

서로 다른 소스가 상충하면 신뢰도와 최신성 점수를 합친 우선순위로 충돌을 해소한다. 다만 충돌 사실 자체를 감추지 않는 편이 신뢰성에 유리하다. “두 소스가 상충하는 정보를 제공합니다”라는 메타 컨텍스트를 전달하면 모델이 답변의 불확실성을 드러낼 수 있다.

인텐트·스펙·하네스가 컨텍스트를 완성한다

컨텍스트 엔지니어링은 검색과 압축만을 가리키는 독립 기법이 아니다. 인텐트 엔지니어링, 스펙 엔지니어링, 하네스 엔지니어링을 상위에서 연결한다.

인텐트 엔지니어링(Intent Engineering)은 표면적인 쿼리 뒤에 있는 실제 의도를 추출하고 명확히 한다. “파이썬 코드 고쳐줘”라는 요청이 디버깅인지, 리팩토링인지, 성능 최적화인지에 따라 수집할 컨텍스트가 달라진다. 의도가 선명할수록 검색 쿼리가 정밀해지고 불필요한 노이즈가 줄어든다.

스펙 엔지니어링(Spec Engineering)은 AI 시스템의 행동 요구사항을 형식적으로 명세한다. 자연어 지시를 형식적 명세로 변환해 컨텍스트 생성의 일관성을 확보한다. Constitutional AI의 원칙 명세와 OpenAI의 모델 스펙이 대표적인 구현이다.

하네스 엔지니어링(Harness Engineering)은 AI 시스템이 실제로 작동하는 실행 환경 전체를 설계한다. 컨텍스트 어셈블러, 모델 호출 레이어, 결과 검증 레이어, 피드백 루프를 유기적으로 연결해 파이프라인의 신뢰성을 확보한다.

⤢✕컨텍스트 엔지니어링(상위 패러다임)인텐트 엔지니어링(의도 추출·명확화)스펙 엔지니어링(행동 요구사항 명세)하네스 엔지니어링(실행 환경 설계)쿼리 분해의도 분류기Constitutional AI 원칙모델 스펙 문서컨텍스트 어셈블러모델 호출 레이어결과 검증 레이어피드백 루프컨텍스트 어셈블리(JIT 동적 구성)LLM 추론

기업 운영에서는 컨텍스트도 통제 대상이다

기업이 컨텍스트 엔지니어링을 도입하려면 파이프라인 구현과 거버넌스를 함께 설계해야 한다.

컨텍스트 감사 추적(Context Audit Trail)은 모델 호출마다 윈도우에 들어간 정보의 출처, 선택 이유, 적용한 변환을 기록한다. AI 결과를 재현하고 편향을 탐지하는 기반이며, 금융·의료 등 규제 산업에서는 컴플라이언스 요건이기도 하다.

컨텍스트 접근 제어(Context Access Control)는 사용자 역할과 권한에 따라 이용 가능한 소스를 구분한다. 일반 사용자와 관리자, 내부 감사인에게 서로 다른 컨텍스트 접근 범위를 부여하도록 RBAC(Role-Based Access Control) 원칙을 컨텍스트 레이어에 적용한다.

품질 모니터링에서는 관련성 점수 분포와 토큰 예산 활용률, 소스 다양성 지수 같은 메트릭을 대시보드로 확인한다. 임계값을 벗어나면 알림을 트리거해 컨텍스트 구성의 이상을 탐지한다.

시스템 프롬프트와 검색 전략, 압축 정책도 버전 관리 대상이다. A/B 테스트로 구성 전략의 효과를 정량 비교하고, 성능이 떨어졌을 때 이전 버전으로 롤백할 수 있어야 한다.

컨텍스트 엔지니어링의 핵심은 더 많은 정보를 모델에 넣는 데 있지 않다. JIT 어셈블리, 멀티소스 융합, 토큰 예산 최적화를 통해 추론에 필요한 정보를 제때 구성하는 데 있다. 인텐트·스펙·하네스 엔지니어링과 거버넌스까지 연결해야 이 구조가 지속 가능한 AI 운영 역량으로 이어진다.

Sources

컨텍스트 엔지니어링RAGMCP파인튜닝LLM