JIT 컨텍스트 조합으로 설계하는 RAG·MCP 에이전트 파이프라인
JIT 컨텍스트 조합과 RAG·MCP·메모리를 결합해 AI 에이전트의 토큰 예산, 정보 품질, 도구 접근을 설계하는 방법을 다룬다.
2026-08-14 · 최초 발행 2026-08-02
프롬프트보다 모델이 보게 될 정보를 설계한다
AI 에이전트의 결과는 지시문 한 줄만으로 결정되지 않는다. 모델이 추론할 때 함께 받는 검색 결과, 대화 이력, 도구 정의, 메모리 상태가 응답의 정확도와 실행 가능성을 좌우한다. 이 입력 전체를 동적으로 조합하고 관리하는 작업이 컨텍스트 엔지니어링이다.
2026년에는 AI 에이전트 개발의 무게중심이 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로 옮겨가고 있다. Anthropic과 Sourcegraph 등이 공개한 실전 가이드도 개별 지시문보다 모델에 공급되는 전체 토큰과 정보 파이프라인을 다룬다. MIT 연구에서는 엔터프라이즈 AI 파일럿의 95%가 ROI 확보에 실패했으며, 핵심 원인으로 모델 성능이 아니라 비즈니스 컨텍스트의 부재를 지목했다.
요청 시점에 컨텍스트를 조립하는 JIT 방식
JIT(Just-In-Time) 컨텍스트 조합은 사용자 요청이 들어온 뒤 해당 작업에 필요한 정보만 골라 컨텍스트 창에 넣는다. 모든 자료를 미리 적재하는 정적 프롬프트와 달리 불필요한 토큰과 노이즈를 줄이고, 제한된 예산을 중요한 정보에 배분하는 방식이다.
조합 대상에는 먼저 에이전트의 역할과 행동 방침을 규정하는 지시사항이 있다. 시스템 프롬프트처럼 고정된 요소도 멀티에이전트 환경에서는 하위 에이전트의 역할에 따라 다시 구성된다.
RAG(Retrieval-Augmented Generation)는 벡터 검색, 키워드 검색, 구조화 쿼리, 코드 그래프 탐색을 병렬로 수행하고 결과를 후보 집합으로 합친다. 2026년 Q1 VentureBeat 조사에서 하이브리드 검색 도입 의향은 3개월 사이 10.3%에서 33.3%로 증가했다.
메모리는 단기 대화 상태인 In-Context Memory, 장기 영구 상태인 External Memory, 에이전트 사이에서 사용하는 Shared Memory로 나뉜다. MCP(Model Context Protocol) 도구 정의는 함수 호출 인터페이스를 표준화한다. 다만 MCP 도구 메타데이터가 컨텍스트 창의 40~50%를 차지할 수 있으므로, 요청에 필요한 도구만 선택하고 스키마를 압축하는 설계가 필요하다.
토큰 예산은 입력 정보의 우선순위 문제다
SWE-bench 수준의 에이전틱 코딩 태스크는 재시도를 포함해 태스크당 평균 1~3.5백만 토큰을 소비한다. 컨텍스트를 많이 넣는 것보다 어떤 정보를 남기고 언제 불러올지 정하는 편이 중요하다.
관련성 순위는 단순 휴리스틱부터 학습된 랭킹 모델까지 단계적으로 적용할 수 있다. 오래된 대화는 자동 요약을 통해 청크 단위로 압축하고, 컨텍스트 창의 한계에 닿으면 우선순위가 낮은 청크부터 동적으로 제거한다. 당장 필요하지 않은 정보는 지연 로딩해 실제 사용 시점까지 적재를 미룬다. 이 과정이 JIT 조합의 토큰 예산 관리자에 해당한다.
RAG와 MCP를 한 파이프라인에서 나누어 쓰는 법
RAG와 MCP는 같은 기능을 경쟁적으로 수행하지 않는다. RAG는 문서와 데이터에서 지식을 찾아 모델 입력으로 공급하고, MCP는 에이전트가 API나 데이터베이스 같은 외부 도구를 호출하도록 연결한다.
| 구분 | RAG | MCP |
|---|---|---|
| 역할 | 문서·데이터 검색 및 주입 | 도구·서비스 통합 표준화 |
| 컨텍스트 유형 | 지식 베이스, 기업 문서, 코드 스니펫 | API, 데이터베이스 쿼리, 외부 서비스 |
| 갱신 주기 | 배치/실시간 인덱싱 | 실시간 API 호출 |
| 토큰 소비 | 청크 크기에 따라 가변 | 도구 스키마 정의 고정 비용 |
| 적합 시나리오 | 비구조화 텍스트 기반 Q&A | 액션 실행, 구조화 데이터 조회 |
2026년 프로덕션 시스템에서는 RAG, MCP, 장기 메모리를 하나의 파이프라인으로 묶는 하이브리드 아키텍처가 표준으로 자리 잡고 있다. NVIDIA AI Blueprint도 얕은 문서 요약과 깊은 문서 요약, 추론 예산 설정, 쿼리 분해, 동적 메타데이터 필터링을 포함한 엔터프라이즈 파이프라인 블루프린트를 제시한다.
멀티에이전트에서는 공유와 격리를 함께 설계한다
오케스트레이터는 태스크 정의와 전역 상태를 하위 에이전트에 전달한다. 여러 에이전트가 함께 알아야 하는 정보는 벡터 DB나 KV 스토어 같은 공유 메모리에 두고, MCP A2A(Agent-to-Agent) 프로토콜을 통해 에이전트 사이에서 컨텍스트를 직접 전달할 수 있다.
모든 정보가 공유 대상은 아니다. 하위 에이전트마다 독립된 컨텍스트 창을 유지하면 보안에 민감한 정보를 역할별로 분리할 수 있다. 여기에 컨텍스트 대상 역할 기반 접근 제어(RBAC over Context)를 적용하고, 태스크가 끝난 뒤 임시 컨텍스트를 폐기해 다른 작업의 상태가 섞이는 일을 막는다.
컨텍스트 품질은 무엇으로 측정할까
평가 범위는 검색 정확도에 머물지 않는다. 컨텍스트 관련성 점수(Context Relevance Score)는 주입한 청크가 쿼리 의도와 맞는지를 측정하고, 컨텍스트 충실도(Context Fidelity)는 검색 결과가 원본 소스를 얼마나 정확하게 반영하는지 확인한다.
토큰 효율성(Token Efficiency)은 전체 입력 중 유용한 정보가 차지하는 비율, 즉 시그널과 노이즈의 관계를 보여준다. 컨텍스트 부재로 발생하는 환각의 빈도는 환각율(Hallucination Rate)로 추적한다. 여기에 검색부터 조합까지 파이프라인 전체에 걸린 지연시간(Latency)을 함께 봐야 품질과 운영 비용 사이의 균형을 판단할 수 있다.
프롬프트와 컨텍스트, 파인튜닝의 경계
세 접근법은 모델 성능을 개선한다는 목적은 같지만 변경하는 대상이 다르다.
┌──────────────────┬──────────────────────┬──────────────────────┬──────────────────────┐
│ 구분 │ 프롬프트 엔지니어링 │ 컨텍스트 엔지니어링 │ 파인튜닝(Fine-tuning)│
├──────────────────┼──────────────────────┼──────────────────────┼──────────────────────┤
│ 핵심 접근 │ 입력 지시문 최적화 │ 동적 정보 파이프라인 │ 모델 가중치 재학습 │
│ 범위 │ 단일 추론 호출 │ 시스템 전체 설계 │ 모델 자체 변경 │
│ 비용 │ 낮음 │ 중간 │ 매우 높음 │
│ 유연성 │ 높음 │ 매우 높음 │ 낮음(재학습 필요) │
│ 최신 정보 반영 │ 불가(컷오프 한계) │ 실시간 가능(RAG) │ 불가(학습 시점 고정) │
│ 기업 도입 난이도 │ 낮음 │ 중간 │ 높음 │
│ 효과 범위 │ 특정 태스크 │ 전체 에이전트 시스템 │ 도메인 전반 │
│ 2026년 트렌드 │ 기반 기술로 통합 │ 주요 투자 영역 │ 소규모 전문화 모델 │
└──────────────────┴──────────────────────┴──────────────────────┴──────────────────────┘
프롬프트 엔지니어링은 사라지는 기술이라기보다 컨텍스트 엔지니어링의 지시사항 레이어로 들어간다. 컨텍스트 엔지니어링은 시스템 전반에서 모델이 접근할 정보를 관리하는 1차 투자 영역이다. 2026 State of Context Management Report에서는 IT 리더의 82%가 프롬프트 엔지니어링만으로는 부족하다고 응답했다.
파인튜닝은 모델 가중치를 바꿔야 하는 선택이다. RAG와 도구 연결, 메모리 구성으로 해결하기 어려운 도메인 특화 언어나 출력 형식이 필요할 때 제한적으로 적용한다.
컨텍스트 엔지니어가 맡는 시스템 범위
프롬프트 엔지니어가 모델과 소통할 지시문을 다뤘다면, 컨텍스트 엔지니어는 응답 생성 시 모델이 어떤 정보에 접근할지를 설계한다. 업무 범위에는 지식 베이스 구조화와 검색 파이프라인 설계, 청킹 전략, 임베딩 모델 선택, 하이브리드 검색 튜닝이 들어간다.
MCP 영역에서는 도구 정의와 토큰 효율적인 스키마를 설계한다. 메모리는 단기·장기·공유 계층으로 나누고, 관련성·충실도·효율성을 측정할 평가 체계를 운영한다.
재교육 로드맵은 RAG 기초에서 시작해 MCP와 멀티에이전트, 엔터프라이즈 파이프라인으로 확장된다.
- 1단계(3개월): RAG 기초 — 임베딩, 청킹, 벡터 DB 실습
- 2단계(3개월): MCP 통합 — 도구 스키마 설계, API 통합 패턴
- 3단계(3개월): 멀티에이전트 컨텍스트 — 공유/격리 패턴, 오케스트레이션
- 4단계(3개월): 엔터프라이즈 파이프라인 — 토큰 예산 관리, 평가 자동화
조직의 파이프라인도 한 번에 JIT 구조로 전환되지는 않는다. 정적 시스템 프롬프트와 수동 컨텍스트 관리가 중심인 레벨 1 - 기본(Prompt)에서 출발해, 벡터 검색과 기본 하이브리드 검색을 갖춘 레벨 2 - 검색(RAG)으로 이동한다. 레벨 3 - 도구(MCP)에서는 표준화된 도구 통합과 동적 선택을 적용하고, 레벨 4 - 메모리(Memory)에서는 다계층 메모리와 세션 간 상태 지속을 다룬다. 레벨 5 - 최적화(Optimized)는 JIT 조합, 자동 토큰 예산, 컨텍스트 품질 자동 평가까지 포함한다.
2026년 하반기에 이어질 변화
자율 컨텍스트 최적화(Autonomous Context Optimization)는 에이전트가 필요한 컨텍스트를 스스로 추론하고 조합 전략을 동적으로 선택하는 방향이다. 이를 위한 강화학습 기반 컨텍스트 선택 정책도 도입되고 있다.
긴 입력을 효율적으로 줄이는 전용 소형 언어 모델은 파이프라인의 중간 계층에 배치되는 패턴이 늘어난다. 컨텍스트 요약 모델이 검색 결과나 대화 이력을 압축한 뒤 주 모델에 전달하는 구조다.
MCP가 사실상 표준으로 자리 잡으면서 기업 SaaS 도구의 MCP 서버 제공이 확대되고, 컨텍스트 마켓플레이스(Context Marketplace)라는 개념도 등장하고 있다. 평가 영역에서는 RAGAS와 Arize Phoenix 같은 프레임워크가 CI/CD 파이프라인에 들어가 컨텍스트 품질을 자동 회귀 테스트 대상으로 삼는다.
규제 대응 역시 파이프라인 설계에 포함된다. EU AI Act와 국내 AI기본법 시행에 맞춰 컨텍스트 감사 로그, 민감 정보 필터링, 컨텍스트 출처 추적(Provenance Tracking)이 규정 준수 요건으로 부상한다.
컨텍스트 엔지니어링은 프롬프트 작성 기법을 넘어 JIT 조합, RAG와 MCP의 역할 분담, 멀티에이전트 메모리, 토큰 예산, 품질 평가를 하나로 묶는 시스템 공학 영역이다. 모델을 바꾸기 전에 모델이 무엇을 보고 어떤 도구에 접근하는지부터 설계해야 한다.
Sources
- https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- https://sourcegraph.com/blog/context-engineering
- https://futureagi.com/blog/context-engineering-genai-2025/
- https://www.meta-intelligence.tech/en/insight-context-engineering
- https://venturebeat.com/data/context-architecture-is-replacing-rag-as-agentic-ai-pushes-enterprise-retrieval-to-its-limits
- https://neo4j.com/blog/agentic-ai/context-engineering-vs-prompt-engineering/
- https://datahub.com/blog/context-engineering-vs-prompt-engineering/
- https://smartscope.blog/en/blog/context-engineering-overview/
- https://arxiv.org/pdf/2603.09619
- https://atlan.com/know/what-is-context-engineering/
- https://rustcodeweb.medium.com/prompt-engineering-is-dead-why-context-engineering-is-the-only-skill-that-matters-in-2026-cdb1fe0b349b