컨텍스트 엔지니어링으로 설계하는 JIT 검색과 런타임 조립

프롬프트보다 먼저 설계해야 할 것

모든 지시와 배경 정보를 프롬프트에 미리 채워 넣으면 요청과 무관한 내용까지 매번 토큰을 소비한다. 정보가 바뀌었을 때 자동으로 반영하기도 어렵다. 2026년 LLM 애플리케이션 설계의 무게 중심이 선행 주입(Upfront Stuffing)에서 저스트-인-타임(JIT) 검색으로 이동하는 이유다.

Andrej Karpathy가 2025년 중반 대중화한 컨텍스트 엔지니어링이라는 개념은 Anthropic·DataHub·deepset 등 주요 AI 기업이 2026년 핵심 개념으로 채택했다. DataHub의 2026 컨텍스트 관리 현황 보고서에서는 IT 및 데이터 리더의 82%가 프롬프트 엔지니어링만으로 AI를 프로덕션 규모에서 운영하기에는 충분하지 않다는 데 동의했다.

프롬프트 엔지니어링의 중심 질문은 모델이 이해하도록 어떻게 표현할 것인가에 가깝다. 컨텍스트 엔지니어링은 모델이 무엇을 알아야 하는지, 정보가 어디에 있는지, 어떤 순서와 비용으로 전달할지를 묻는다. 검색(Retrieval)만 잘 구성한다고 끝나는 작업도 아니다. 메모리 관리, 도구 오케스트레이션, 토큰 예산, 컨텍스트 압축, 멀티턴 상태 지속성까지 하나의 시스템으로 다룬다.

⤢✕

필요한 청크를 런타임에 고르는 검색 구조

JIT 검색은 쿼리가 발생한 뒤 필요한 청크만 선택한다. 출발점은 쿼리를 임베딩 벡터로 변환한 다음, 사전에 인덱싱한 지식 베이스에서 코사인 유사도가 높은 청크를 찾는 의미 검색이다. 임베딩 모델이 검색 품질에 직접 영향을 준다. 2026년 기준 주요 선택지로는 OpenAI의 text-embedding-3-large와 Google의 Gemini Embedding이 있으며, 한국어 특화 모델로 CLOVA Embedding이 활용된다.

의미 검색만으로는 정확한 키워드 일치를 놓칠 수 있다. BM25나 전문 검색(Full-Text Search)을 함께 사용하는 하이브리드 검색은 대부분의 프로덕션 환경에서 순수 의미 검색보다 높은 Recall을 달성한다. 서로 다른 결과 순위는 RRF(Reciprocal Rank Fusion)로 결합한다.

검색 결과를 곧바로 모델에 넘기지 않고 재순위화하는 단계도 필요하다. 먼저 Bi-encoder 기반 근사 검색으로 후보 50~~100개를 확보한 뒤, Cohere Rerank나 BGE Reranker 같은 Cross-encoder 기반 모델로 평가해 상위 5~~10개를 고른다. 첫 단계는 속도를, 두 번째 단계는 정밀도를 담당한다.

⤢✕

의미 유사도가 높다는 이유만으로 모든 청크를 사용할 수는 없다. 날짜, 출처 신뢰도, 문서 유형, 언어, 접근 권한 같은 메타데이터를 검색 조건에 포함해야 한다. 가령 “2026년 Kubernetes 보안 정책”을 묻는 요청에서는 2024년 이전 문서를 제외해 오래된 정보가 노출되는 상황을 막는다.

선별한 청크도 그대로 넣으면 컨텍스트 창의 토큰 예산을 넘을 수 있다. LLMLingua와 Selective Context 같은 압축 기법은 모델 성능에 영향을 주지 않는 부분을 제거해 원본 대비 2~5배의 토큰을 절감한다. 긴 문서에서 관련 문장을 그대로 추출하는 Extractive 방식과 의미를 보존해 다시 생성하는 Abstractive 방식은 태스크 특성에 따라 선택한다.

토큰 배분도 명시적으로 관리한다. 일반적인 배분 비율은 시스템 프롬프트 10%, 검색 컨텍스트 40%, 대화 히스토리 30%, 출력 예비분 20%다. 예산을 초과하면 대화 히스토리를 먼저 압축하고, 그래도 부족할 때 검색 컨텍스트 수를 줄인다.

검색을 모델이 호출할 수 있는 도구로 만든다

2026년 JIT 검색 구현에서는 검색 기능을 LLM이 호출할 수 있는 도구로 제공한다. 컨텍스트 전체를 요청 전에 밀어 넣는 대신, 모델이 정보가 필요한 시점에 검색 도구를 선택하도록 구성하는 방식이다.

Anthropic의 Agent Skills가 이 패턴을 보여준다. 에이전트는 경량 참조만 유지하고 실제 데이터는 런타임에 동적으로 불러온다. 초기 토큰 비용을 줄이면서 모델이 태스크에 필요한 정보만 선택적으로 조회할 수 있다. JIT 검색이 대부분의 태스크에서 선행 로드 방식보다 높은 성능을 보인다는 것이 2026년의 실증적 결론이다.

이 구조에서 검색은 단순한 전처리가 아니다. 모델의 판단과 도구 호출, 결과 평가, 추가 검색이 이어지는 실행 과정의 일부가 된다.

불변 지시와 동적 데이터를 분리하는 법

정적 컨텍스트는 시스템 프롬프트에 지시, 예시, 배경 정보를 모두 하드코딩한다. 구현은 단순하고 별도의 검색 레이턴시가 없지만, 지식이 바뀌어도 자동으로 갱신되지 않는다. 요청과 관계없는 정보도 항상 입력 토큰으로 소비한다.

동적 컨텍스트는 쿼리 유형과 실행 상황에 맞춰 런타임에 내용을 조립한다. 구현 복잡도와 검색 레이턴시는 늘지만, 최신 정보를 반영하고 태스크와 관련된 데이터만 제공할 수 있다.

설계 항목	정적 방식	동적 방식
지식 업데이트	재배포 필요	실시간 반영
토큰 효율	낮음 (항상 전체 주입)	높음 (필요분만 주입)
구현 복잡도	낮음	높음
레이턴시	낮음 (검색 없음)	검색 레이턴시 추가
개인화	어려움	용이

시스템 프롬프트에는 변하지 않는 내용만 남기는 편이 낫다. 항상 적용되는 역할, 톤, 기본 제약은 L1 핵심 페르소나(Core Persona)로 묶어 약 200500 토큰 규모로 고정한다. 코드 리뷰, 문서 작성, 데이터 분석처럼 현재 태스크에 따라 달라지는 지시는 L2 기능별 지시(Feature Instructions)로 분리하고 약 300800 토큰 범위에서 선택한다.

JIT 검색 결과, 대화 히스토리, 사용자 선호도는 L3 컨텍스트 데이터(Context Data)에 배치한다. 이 계층이 나머지 토큰 예산을 사용한다. 레이어를 분리하면 각 부분을 독립적으로 캐싱하기도 쉽다.

⤢✕

캐시와 MCP가 차지하는 토큰까지 계산한다

Anthropic Claude의 프롬프트 캐싱과 Google Gemini의 Context Caching은 반복되는 시스템 프롬프트나 대형 문서의 동일한 프리픽스를 한 번 처리한 뒤 다음 쿼리에서 재사용한다. 입력 토큰 비용을 최대 90% 줄일 수 있으므로, 캐시할 수 있는 불변 컨텍스트를 입력 앞부분에 배치해야 한다.

MCP는 에이전트가 런타임에 외부 도구와 데이터 소스에 접근할 수 있게 하는 표준 프로토콜이지만, 도구 정의 자체가 토큰을 소비한다. 단일 복합 JSON 스키마가 500토큰 이상을 차지할 수 있고, 90개 도구를 등록하면 사용자와 상호작용하기 전에 50k 토큰이 소진된다. 한 개발자는 MCP 풀 설정에서 200k 토큰 창의 72%인 143k를 MCP 도구 정의가 차지했다고 보고했다.

따라서 2026년 실무에서는 모든 MCP 서버를 시작부터 연결하지 않는다. 태스크 유형을 바탕으로 관련 도구를 동적으로 발견(Dynamic Tool Discovery)하고, 실제로 필요한 도구만 지연 로딩(Lazy Loading)한다.

RAG를 포함하되 검색에 머물지 않는다

RAG(Retrieval Augmented Generation)는 컨텍스트 엔지니어링 안에 포함되는 검색 패턴이다. 기존 RAG가 검색된 문서를 모델에 제공하는 데 집중한다면, 컨텍스트 엔지니어링은 도구 결과와 메모리, 실행 상태까지 입력으로 관리한다.

항목	기존 RAG	컨텍스트 엔지니어링
검색 방식	벡터 검색 중심	하이브리드 + 에이전틱 검색
컨텍스트 범위	검색된 문서	문서 + 도구 결과 + 메모리 + 상태
업데이트 방식	인덱스 재구축	실시간 동적 주입
메모리 관리	없음 (스테이트리스)	단기·장기 메모리 계층
상태 지속성	없음	멀티턴 세션 지속
도구 연동	제한적	MCP/함수 호출 풀 통합

SmartScope의 2026 컨텍스트 엔지니어링 비교 가이드에 따르면 정적 문서를 대상으로 하는 Q&A는 기존 RAG만으로 충분하다. 동적 데이터, 외부 API, 사용자 상태가 함께 작동하는 에이전트 시나리오에는 더 넓은 컨텍스트 엔지니어링이 필요하다.

비용 구조와 검색 품질을 함께 측정한다

JIT 검색은 요청마다 벡터 DB 조회가 발생하므로 검색 비용만 보면 비싸게 느껴질 수 있다. 하지만 전체 입력 토큰까지 포함하면 계산이 달라진다.

선행 전체 주입 방식은 모든 요청에 전체 지식 베이스를 넣으므로 비용이 1M 토큰 × 요청 수 × $1.50/1M으로 쌓인다. JIT 검색은 관련 청크 5~~10개만 주입해 평균 5k 토큰 × 요청 수 × $1.50/1M + 벡터 검색 비용이 된다. 이 구조에서는 200배 이상의 토큰 절감이 가능하며, 약 $0.0001~~0.001/쿼리인 벡터 DB 조회 비용은 무시할 수준이다. 장문 컨텍스트의 $6/1M 토큰 초과 구간에서는 절감 효과가 더 커진다.

비용을 줄였더라도 필요한 문서를 제대로 찾지 못하면 시스템 품질은 떨어진다. 검색 파이프라인은 다음 지표로 지속해서 확인한다.

Recall@K는 관련 문서 가운데 상위 K개 결과에 포함된 비율이며, 보통 Recall@5와 Recall@10을 측정한다.
**MRR(Mean Reciprocal Rank)**은 첫 번째 관련 결과 순위의 역수를 평균한 값이다.
**NDCG(Normalized Discounted Cumulative Gain)**는 결과 순서를 반영해 관련도를 평가한다.
Context Utilization은 Attribution 분석을 통해 LLM이 제공된 컨텍스트를 실제로 활용한 비율을 본다.
Faithfulness는 RAGAS 프레임워크로 응답이 컨텍스트에 얼마나 근거했는지 측정한다.

컨텍스트를 운영하는 데 필요한 역량

이 역할의 중심은 프롬프트 문장을 다듬는 능력보다 검색과 실행 시스템을 설계하는 능력에 있다. 검색 측면에서는 Pinecone, Weaviate, pgvector 같은 벡터 DB의 설계와 최적화, 임베딩 모델 선택과 파인튜닝, 고정 크기·의미 기반·계층적 청킹 전략을 다룬다.

운영 단계에서는 비용 모델링과 토큰 예산 설계, MCP 서버 설계와 통합, 스트리밍과 비동기 처리 패턴이 필요하다. 평가 파이프라인에는 RAGAS와 TruLens를 적용하고, A/B 테스트와 레이턴시 프로파일링을 통해 품질과 실행 비용을 함께 확인한다.

2026년 LLM 개발의 중심 질문은 “어떤 모델을 쓸 것인가”에서 “어떤 컨텍스트를 제공할 것인가”로 옮겨가고 있다. 같은 모델도 컨텍스트를 무엇으로 구성하고 어떤 순서로 전달하느냐에 따라 모델 교체보다 큰 성능 차이가 날 수 있다. JIT 검색, 런타임 조립, MCP 도구 주입, 캐시와 토큰 예산은 따로 떨어진 최적화 항목이 아니라 하나의 운영 아키텍처로 설계해야 한다.