컨텍스트 엔지니어링으로 설계하는 JIT·RAG·MCP 통합 아키텍처

프롬프트만으로 프로덕션을 운영하기 어려운 이유

2026년 IT·데이터 리더의 82%는 프롬프트 엔지니어링만으로 프로덕션 AI를 구현하기에 충분하지 않다고 응답했다. 실제 운영 환경에서 모델의 품질을 좌우하는 것은 지시문 하나가 아니다. 시스템 프롬프트와 대화 이력, 검색 문서, 툴 실행 결과, 장기 메모리가 함께 모델의 추론 공간을 만든다.

프롬프트 엔지니어링은 텍스트 입력을 다듬어 모델의 추론 방향을 유도한다. 초기 개발이나 단순한 작업에는 효과적이지만, 운영 단계에서는 정적 지식이라는 한계가 드러난다. 프롬프트에 넣은 정보는 작성 시점에 고정되므로 계속 변하는 비즈니스 데이터, 법령, 제품 정보를 따라가지 못한다. 내부 문서가 수만 건에 이르면 관련 자료를 모두 프롬프트에 넣는 것도 토큰 예산상 불가능하다.

컨텍스트 창이 커졌다고 문제가 사라지는 것은 아니다. 관련성이 낮은 정보가 많이 섞이면 모델이 핵심을 놓치는 lost-in-the-middle 현상이 나타난다. 128K~1M 토큰 규모의 컨텍스트 창에서도 불필요한 자료가 누적되면 중요한 정보의 활용률은 급감한다.

감사 가능성도 걸림돌이다. 개인의 직관에 의존해 프롬프트를 조정하면 버전과 변경 이력을 관리하기 어렵고, 어떤 근거로 출력이 만들어졌는지 추적하기도 힘들다. 출력 근거를 확인해야 하는 금융·의료·법률 환경에서는 이 문제가 운영 요건과 직접 충돌한다.

모델이 읽는 정보 공간을 설계한다

컨텍스트 엔지니어링은 LLM을 호출할 때 전달되는 전체 정보 공간을 설계하고 조합하며 최적화하는 엔지니어링 규율이다. 다루는 대상은 프롬프트 텍스트에 한정되지 않는다.

컨텍스트 소스는 시스템 프롬프트와 지시사항, 사용자 입력과 대화 히스토리, RAG나 웹 검색에서 가져온 외부 검색 결과, MCP 서버와 API가 반환한 툴 실행 결과, 장기 메모리와 사용자 프로파일이라는 다섯 유형으로 구분할 수 있다. 실무에서는 이 가운데 무엇을 선택하고, 어떤 순서로 배치하며, 어디까지 압축할지 결정해야 한다.

청크 선택 전략(Chunk Selection Strategy), 관련성 점수화(Relevance Scoring), 토큰 예산 관리(Token Budget Management), 컨텍스트 압축(Context Compression), 컨텍스트 캐싱(Context Caching)은 이 결정을 구현하는 하위 체계다. 각각을 따로 적용하는 데서 끝나지 않고 런타임 파이프라인으로 연결해야 한다.

⤢✕

컨텍스트를 조립하기 전에 사용자의 의도와 실행 사양부터 정제해야 한다. 인텐트 엔지니어링(Intent Engineering)은 표면적인 요청 뒤에 있는 목적을 구조화한다. 사용자가 “매출 보고서 작성해줘”라고 요청했다면 원하는 기간, 비교 기준, 결과 형식, 수신자가 누구인지 추론하거나 명시하는 과정이 여기에 해당한다. 의도가 분명해야 어셈블러가 검색할 소스와 정보를 정할 수 있다.

스펙 엔지니어링(Spec Engineering)은 에이전트나 파이프라인이 실행할 작업을 사양으로 만든다. 입력 조건, 출력 형식, 제약사항, 품질 기준, 폴백 로직을 함께 정의하며, 멀티 에이전트 환경에서는 에이전트 간 협력과 컨텍스트 공유 방식도 명세에 포함한다.

이 구조에서는 인텐트가 스펙으로 구체화되고, 스펙이 컨텍스트 어셈블리를 이끌며, 조립된 정보가 LLM 추론에 투입된다. 프롬프트 엔지니어링은 이 흐름 안에서 세부 입력을 최적화하는 기법으로 자리 잡는다.

질의마다 달라지는 JIT 컨텍스트

JIT(Just-In-Time) 컨텍스트 어셈블리는 LLM 호출 직전에 필요한 정보를 검색하고 선택한다. 사전에 고정된 프롬프트 템플릿과 달리 입력 질의에 따라 매 호출마다 다른 컨텍스트를 만든다.

검색 문서를 어떤 단위로 나눌지는 결과 품질에 직접 영향을 준다. Fixed-Size Chunking은 일정 토큰 수로 문서를 자른다. 예를 들어 512토큰으로 고정 분할하면 구현은 단순하지만 의미 경계가 끊길 수 있다.

Semantic Chunking은 문장이나 단락의 의미적 경계를 따라 분할한다. 임베딩 유사도를 이용해 의미가 전환되는 지점을 찾는 방식이다. Hierarchical Chunking은 문서→섹션→단락 구조를 보존한다. 요약과 세부 내용을 함께 검색하고, 거친 필터링 뒤 세밀한 검색으로 이어지는 2단계 처리에 적합하다.

Contextual Retrieval은 각 청크가 전체 문서에서 차지하는 맥락을 LLM으로 생성해 덧붙인 뒤 인덱싱하는 Anthropic의 기법이다. 기존 방식보다 검색 정밀도가 49% 향상된다고 보고된다.

원본 질의 하나에만 의존하지 않는 방법도 있다. LLM이 동의어 질의와 관련 질의를 생성하고, 복수 쿼리를 병렬로 검색한 뒤 결과를 합치면 단일 쿼리보다 재현율(Recall)을 높일 수 있다.

방법	설명	장점	단점
BM25	키워드 기반 희소 벡터 매칭	빠른 속도, 정확한 키워드 매칭	의미적 유사도 미반영
Dense Retrieval	임베딩 코사인 유사도	의미적 유사도 반영	정확한 용어 매칭 취약
Hybrid Search	BM25 + Dense 결합(RRF)	두 방식 장점 결합	가중치 튜닝 필요
Cross-Encoder Reranking	LLM 기반 관련성 재평가	최고 정밀도	지연시간·비용 증가

RAG·MCP·파인튜닝·캐시를 함께 쓰는 구조

엔터프라이즈 시스템에서는 한 종류의 컨텍스트 소스만으로 요구사항을 충족하기 어렵다. RAG, MCP, 파인튜닝, 인메모리 캐시는 서로 대체하는 수단이라기보다 다른 역할을 맡는 입력 채널이다.

RAG(Retrieval-Augmented Generation)는 외부 지식 베이스에서 관련 문서를 동적으로 검색한다. 모델을 다시 학습하지 않고도 지식을 갱신할 수 있어 최신 정보와 도메인 지식 확장에 유리하지만, 검색 품질이 응답 품질을 좌우한다.

MCP(Model Context Protocol)는 Anthropic이 제안했으며 2025년 이후 업계 표준으로 자리 잡은 오픈 프로토콜이다. LLM 에이전트가 외부 툴, 데이터 소스, 서비스와 표준화된 방식으로 상호작용하도록 한다. MCP 서버는 파일 시스템, 데이터베이스, API, 웹 검색, 코드 실행 환경 등을 툴로 노출하고, 에이전트는 런타임에 필요한 툴을 호출한다. RAG가 검색한 정보를 읽는 경로라면 MCP는 액션을 실행하고 그 결과를 컨텍스트로 사용하는 경로다.

파인튜닝(Fine-tuning)은 도메인 지식이나 응답 스타일을 모델 가중치에 주입한다. 법률 용어 정의, 사내 약어 체계, 특정 출력 형식처럼 반복되는 정형 지식은 매번 RAG로 검색하기보다 모델에 내재화하는 편이 지연시간과 비용에 유리하다. 대신 지식을 갱신하는 비용이 크고 유연성이 낮다.

인메모리 캐시는 오늘의 요금표, 현재 재고 상태, 사용자 세션 상태처럼 자주 참조하는 조각을 Redis나 Memcached에 저장한다. 반복 검색 없이 밀리초 단위의 지연시간으로 최신 데이터를 제공할 수 있지만, 저장 가능한 정보량에는 한계가 있다.

⤢✕

서로 다른 신호를 하나의 기준으로 평가한다

멀티소스 결과를 그대로 이어 붙이면 중복과 모순이 생기고 관련성이 희석된다. 신호 융합(Signal Fusion)은 각 소스에서 수집한 정보를 공통 점수 체계로 평가해 컨텍스트를 구성한다.

관련성 점수(Relevance Score)는 질의와 정보 사이의 의미적 유사도를 0~1로 정규화한다. 최신성 가중치(Recency Weight)는 정보 생성 시점과 현재의 차이에 따라 w_recency = e^(-λ·Δt) 형태로 감쇠하며, λ는 도메인에 맞게 조정한다. 실시간 주가 데이터에는 큰 λ를, 법률 조문에는 매우 작은 λ를 적용한다.

신뢰도 가중치(Confidence Weight)는 소스의 권위와 신뢰성을 반영한다. 공식 내부 문서는 높게, 웹 스크래핑 결과는 낮게 설정한다. 다양성 패널티(Diversity Penalty)는 이미 선택한 청크와 의미적으로 중복되는 후보의 점수를 낮춰 정보의 다양성을 확보한다.

최종 점수 = α·관련성 + β·최신성 + γ·신뢰도 - δ·중복도

α, β, γ, δ는 작업 유형과 도메인 특성에 맞춰 조정하는 하이퍼파라미터다.

점수만으로 모순이 사라지지는 않는다. 제품 가격처럼 벡터 DB의 RAG 결과와 실시간 API를 호출한 MCP 결과가 다를 수 있다. 이때는 최신성 가중치가 높은 소스를 우선하되, 값이 충돌한다는 사실도 LLM 컨텍스트에 명시해 모델이 불확실성을 인지하도록 설계하는 편이 안전하다.

컨텍스트도 접근 통제와 감사가 필요하다

컨텍스트 엔지니어링이 운영 체계로 자리 잡으면 모델에 넣는 정보 자체가 거버넌스 대상이 된다. 컨텍스트 거버넌스(Context Governance)는 어떤 데이터를 LLM 컨텍스트에 포함할 수 있는지 정책으로 정하고 감사하는 체계다.

접근 제어(Access Control)는 사용자 역할에 따라 사용할 수 있는 소스를 제한한다. RBAC나 ABAC를 적용해 재무 담당자는 재무 데이터 컨텍스트에, 고객 서비스 담당자는 CRM 컨텍스트에만 접근하도록 구성할 수 있다.

데이터 분류(Data Classification)는 기밀·내부·공개 등 민감도에 따라 외부 LLM API로 보내면 안 되는 데이터를 차단하거나 마스킹한다. 감사 로그(Audit Log)는 각 LLM 호출에 포함된 컨텍스트 조각과 검색 출처를 기록해 사후 분석과 규제 보고에 사용한다.

하네스 엔지니어링(Harness Engineering)은 LLM 에이전트를 둘러싼 실행 환경을 설계한다. 컨텍스트 어셈블리뿐 아니라 에러 처리, 재시도, 출력 검증, 비용 모니터링을 한곳에서 관리한다. Claude Code와 같은 AI 코딩 에이전트에서는 파일 시스템 접근, 코드 실행, 테스트 결과를 다시 컨텍스트로 보내는 순환 루프도 하네스가 담당한다.

이 구조를 개선하려면 컨텍스트 히트율, 토큰 활용 효율, 소스별 기여도, 레이턴시 분해를 지속해서 관찰해야 한다. 컨텍스트 히트율은 검색된 청크가 실제 응답 생성에 쓰인 비율이며, 토큰 활용 효율은 컨텍스트 토큰 대비 응답 품질 점수의 비율이다. 소스별 기여도는 각 입력 채널이 최종 응답에 미친 정도를 보여주고, 레이턴시 분해는 JIT 어셈블리 단계별 지연시간 분포를 드러낸다. 이 지표를 피드백 루프에 연결해야 파이프라인을 지속적으로 조정할 수 있다.

2026년 엔터프라이즈 컨텍스트 스택의 인프라 계층에는 벡터 데이터베이스인 Pinecone, Weaviate, pgvector와 캐시인 Redis, 스트림 처리용 Kafka가 놓인다. 그 위에서는 MCP 서버 레지스트리와 RAG 파이프라인 오케스트레이터가 컨텍스트를 조합한다. 최상위 계층은 컨텍스트 거버넌스 정책 엔진과 감사 시스템이 맡으며, LLMOps 플랫폼이 전체 계층을 관찰하는 사이드카로 운영된다.

프롬프트는 여전히 필요하지만 프로덕션 LLM의 전체 설계를 대신하지는 못한다. 어떤 정보를 어느 시점에 불러오고, 무엇을 제외하며, 충돌하는 신호를 어떻게 다루고, 사용한 근거를 어디에 기록할지가 응답 품질과 비용 효율을 함께 좌우한다. JIT 어셈블리와 멀티소스 통합을 운영하려면 컨텍스트 거버넌스와 하네스 엔지니어링도 같은 시스템 경계 안에서 다뤄야 한다.

컨텍스트 엔지니어링으로 설계하는 JIT·RAG·MCP 통합 아키텍처

프롬프트만으로 프로덕션을 운영하기 어려운 이유

모델이 읽는 정보 공간을 설계한다

질의마다 달라지는 JIT 컨텍스트

관련성에 따라 고르고 토큰 예산에 맞춘다

RAG·MCP·파인튜닝·캐시를 함께 쓰는 구조

서로 다른 신호를 하나의 기준으로 평가한다

컨텍스트도 접근 통제와 감사가 필요하다

Sources

프롬프트만으로 프로덕션을 운영하기 어려운 이유

모델이 읽는 정보 공간을 설계한다

질의마다 달라지는 JIT 컨텍스트

관련성에 따라 고르고 토큰 예산에 맞춘다

RAG·MCP·파인튜닝·캐시를 함께 쓰는 구조

서로 다른 신호를 하나의 기준으로 평가한다

컨텍스트도 접근 통제와 감사가 필요하다

Sources

함께 읽기