AI 에이전트 컨텍스트 엔지니어링과 JIT·RAG·MCP 설계

2026년 AI 개발의 관심사는 프롬프트 문구를 다듬는 작업에서 모델이 추론 순간에 어떤 정보를 받는지 설계하는 작업으로 이동하고 있다. DataHub의 State of Context Management Report 2026에서는 IT·데이터 리더 82%가 프롬프트 엔지니어링만으로 프로덕션 AI 배포를 감당하기 어렵다고 답했다. 데이터 팀의 95%는 2026년 안에 컨텍스트 엔지니어링 역량에 투자할 계획이라고 밝혔다.

MCP(Model Context Protocol) 공개 서버가 10,000개를 넘어선 상황도 같은 변화를 보여준다. 모델에 연결할 데이터와 도구가 늘어날수록 중요한 것은 프롬프트 한 문장이 아니라 정보 검색, 메모리, 도구 스키마와 현재 작업 상태를 어떻게 조합하느냐다.

프롬프트 작성에서 컨텍스트 파이프라인으로

2022년부터 2026년까지 약 4년 동안 AI 개발 방법론은 세 차례 방향을 바꿨다.

**Prompt Engineering(2022~2023)**은 질문 방식에 집중했다. 역할 부여, 소수 샷 예제와 지시 형식 최적화가 주요 기법이었다.
**Context Engineering(2024~2025)**에서는 모델이 행동하는 순간 무엇을 알고, 보고, 기억해야 하는지가 설계 대상이 됐다. 검색 문서뿐 아니라 도구 스키마, 대화 이력과 에이전트 메모리까지 범위가 확장됐다.
**Harness Engineering(2026~)**은 컨텍스트 파이프라인을 코드로 관리하고 에이전트 워크플로우 안에서 자동화·측정·최적화하는 단계다.

2025년 6월 Shopify CEO Tobias Lütke는 컨텍스트 엔지니어링을 LLM이 해결할 수 있는 작업에 필요한 모든 컨텍스트를 제공하는 기술로 설명하며 개념을 주류화했다. 이후 전 Tesla AI 수장이자 OpenAI 공동창업자인 Andrej Karpathy가 범위를 확장해 정의하면서 업계 전반으로 빠르게 퍼졌다.

컨텍스트 엔지니어링은 각 파이프라인 단계에 맞는 정보를 컨텍스트 창에 채우는 실천 행위이며, JIT(Just-in-Time) 지식 로지스틱스로 볼 수 있다. 프롬프트가 하나의 입력 텍스트라면 컨텍스트는 시스템 프롬프트, 검색 문서, 도구 스키마, 이전 상호작용 메모리, 대화 이력과 현재 작업 상태를 모두 포함한다.

필요한 순간에 정보를 조합하는 JIT 구조

추론 전에 관련 자료를 한꺼번에 검색해 넣는 Pre-inference Batch Retrieval은 구현하기 쉽지만 불필요한 문서까지 컨텍스트 창에 담을 수 있다. 토큰 비용이 커지고 가격·재고·상태 같은 실시간 데이터를 반영하기도 어렵다. 컨텍스트 창이 포화되면 Context Rot에 따른 성능 저하도 나타난다.

Chroma의 Context Rot 연구에서는 입력 토큰이 늘어날수록 주요 LLM의 추론 품질이 일관되게 낮아지는 현상이 확인됐다. 2024~2025년 평균 프롬프트 길이는 1.5K에서 6K 토큰으로 4배 증가했으며, 에이전트 워크플로우가 주된 원인으로 지목됐다.

⤢✕

JIT 파이프라인은 정적 정보와 동적 정보를 나눈다. 세션을 시작할 때는 시스템 프롬프트, 캐시된 명령어와 장기 요약 메모리처럼 변하지 않는 요소를 불러온다. 이 영역에는 프롬프트 캐싱을 적용해 비용을 줄일 수 있다.

현재 작업 상태, JIT RAG 검색 결과와 MCP 도구 호출 결과는 런타임에 주입한다. 미리 모든 정보를 적재하지 않고 실제로 필요한 시점에만 가져오는 방식이다.

도구 스키마가 컨텍스트를 잠식할 때

MCP 공개 서버가 10,000개를 돌파하면서 도구 정의 자체가 새로운 오버헤드가 됐다. MCP 도구 스키마만으로 200K 컨텍스트 창의 72%를 사용해 실제 대화와 추론, 출력에는 57,000토큰만 남은 사례도 보고됐다.

한 가지 대응은 지연 스키마 로딩이다. 도구 정의를 항상 넣지 않고 실제 호출 직전에 필요한 스키마만 삽입한다. 작업 단계에 따라 활성 도구를 바꾸는 동적 도구 팔레트도 같은 문제를 줄이는 접근법이다.

컨텍스트 창을 예산처럼 관리하기

컨텍스트 버퍼가 70~80% 이상 찼을 때는 오래된 대화, 관련성이 낮은 문서와 중복 정보를 그대로 유지하기보다 자동 최적화 메커니즘을 작동시켜야 한다.

전략	처리 방식	적합한 상황
슬라이딩 윈도우	최근 N개 메시지만 남기고 오래된 메시지를 삭제	단순 대화형 에이전트
계층적 요약	최근 N턴은 원문으로 유지하고 임계 초과분을 요약	장기 세션·복잡 작업
저신호 청크 제거	관련성이 낮은 문서 청크를 추론 전에 필터링	RAG 기반 시스템
선택적 캐싱	변하지 않는 컨텍스트는 캐시하고 동적 부분만 갱신	반복 호출이 많은 API
컨텍스트 압축	LLM 기반 요약으로 의미를 보존하며 토큰 감축	대용량 문서 처리

저신호 청크를 먼저 제거하면 추론 비용이 약 30% 감소하면서 내부 평가 품질이 향상됐다. 전략적 캐싱, 압축과 컨텍스트 엔지니어링을 함께 적용하면 비용을 50~90% 절감할 수 있다.

Morph Compact는 에이전트 세션에서 50~70% 컨텍스트 압축을 달성하면서 98% 원문 정확도를 유지했고, 초당 약 33,000토큰을 처리했다. 반대로 200K 컨텍스트 창을 2배로 확장하면 응답 시간도 약 2배 증가한다. 전체 2M 토큰을 넣는 대신 RAG로 관련 컨텍스트 50K만 선택하면 비용을 수십 배 절감할 수 있다.

검색과 지속 메모리를 구분해야 한다

프로덕션 에이전트의 메모리는 서로 다른 수명과 역할을 가진 계층으로 나뉜다.

⤢✕

인컨텍스트 메모리는 활성 컨텍스트 창에 존재하는 단기·휘발성 정보다. 에피소딕 메모리는 순서가 있는 과거 상호작용을, 시맨틱 메모리는 사실과 일반화된 지식을 저장한다. 절차적 메모리에는 에이전트가 따라야 할 규칙, 스킬과 코드가 들어간다. 2026년 프로덕션 아키텍처에서는 에피소딕·시맨틱·절차적 메모리를 벡터-그래프 하이브리드 스토리지에 두고 JIT 조합기로 가져오는 구성이 권장된다.

RAG와 에이전트 메모리는 같은 개념이 아니다. RAG는 세션이 끝나면 리셋되는 무상태 검색이고, 에이전트 메모리는 세션 사이에서도 컨텍스트를 보존하고 발전시키는 유상태 지속성이다.

2026년 프로덕션 에이전트에서 가장 흔한 실패 원인은 **메모리 환각(Memory Hallucination)**이다. 에이전트가 자체 이력에서 서로 충돌하거나 오래된 사실을 검색한 뒤 신뢰도 높은 거짓 정보를 합성하는 현상이다.

RAG·MCP·Fine-tuning의 역할 분담

기준	RAG	MCP	Fine-tuning
데이터 유형	비정형 정적 문서	구조화된 실시간 데이터	도메인 특화 패턴
실시간성	낮음 (재인덱싱 필요)	높음 (매초 갱신 가능)	없음 (사전 학습)
액션 실행	불가	가능 (이메일, Jira 등)	불가
초기 비용	중간	낮음	매우 높음
운영 비용	중간	중간	고트래픽 시 ROI
적합 사례	기술 문서, 지원 티켓	가격 데이터, API 연동	특정 스타일·도메인
상태 관리	무상태	유상태	N/A

단순 참조 지식에는 RAG가 맞고, 실시간 데이터 조회나 액션 실행에는 MCP가 적합하다. 고트래픽 반복 작업에는 Fine-tuning을 고려할 수 있다. 2026년에는 이들을 결합한 RAG-MCP 하이브리드 파이프라인이 복잡한 프로덕션 시스템의 표준으로 자리 잡고 있다.

평가와 학습을 컨텍스트에 되돌리는 ACE

ACE(Agentic Context Engineering)는 Generator, Reflector와 Curator가 순환하는 구조다.

⤢✕

Generator는 현재 컨텍스트로 초기 응답을 만든다. Reflector는 품질 기준에 따라 결과를 평가하고 개선안을 제시한다. Curator는 이 과정에서 얻은 인사이트를 추출해 컨텍스트 플레이북을 갱신한다. 이때 요약 기반 메모리 압축을 사용해 핵심 정보는 보존하고 토큰 공간을 확보한다.

멀티에이전트의 공유 경계

모든 에이전트가 같은 컨텍스트를 보는 구조는 간단하지만 실행 중인 세부 상태와 전문 지식, 권한이 뒤섞일 수 있다. 전역 작업 목표, 공통 도구 스키마와 정책, 에이전트가 만든 결과물의 요약은 공유하는 편이 맞다.

반면 에이전트별 세부 작업 상태는 실행 데이터 오염을 막기 위해 분리해야 한다. 전문화된 도메인 메모리도 교차 오염을 피하도록 나누고, 민감 데이터와 권한별 컨텍스트는 보안 경계에 맞춰 격리해야 한다.

ACDL(Agent Context Description Language)은 arXiv:2605.01920에 발표된 형식 언어다. 역할 메시지 시퀀스, 동적 콘텐츠, 시간 인덱스 참조와 조건부·반복 구조를 포함한 컨텍스트 측면을 명세하는 구문을 제공하며, 멀티에이전트 컨텍스트 오케스트레이션 표준화의 핵심 도구로 부상 중이다.

엔터프라이즈 파이프라인에 예산 관리자를 두는 이유

엔터프라이즈 환경에서는 입력이 모델로 바로 넘어가기보다 컨텍스트 오케스트레이터를 거친다. 오케스트레이터는 캐시와 정책 문서, 장기 메모리 같은 정적 레이어와 RAG·MCP·에피소딕 메모리로 구성된 동적 레이어를 결합한다.

⤢✕

이 구조에서는 컨텍스트 예산 관리자가 정적 컨텍스트 20%, 검색 50%, 메모리 20%, 여유 10%로 토큰 할당을 최적화한다. 추론 결과와 품질 평가에서 나온 학습은 Curator를 통해 장기 메모리 요약으로 되돌아간다.

품질은 입력 길이가 아니라 활용도로 측정한다

지표	의미	목표값
Context Relevance Score	삽입한 청크와 쿼리의 의미적 유사도	0.8 이상
Context Utilization Rate	LLM이 실제로 참조한 컨텍스트 비율	70% 이상
Token Efficiency Ratio	유효 정보 토큰 / 전체 토큰	최대화
Memory Hallucination Rate	잘못된 메모리 참조 빈도	1% 미만
Context Freshness Score	동적 컨텍스트의 최신성	SLA에 따라 정의
Retrieval Precision@K	상위 K개 청크 중 실제로 유용한 비율	0.7 이상

VentureBeat Q1 2026 VB Pulse에서는 하이브리드 검색 도입 의향이 1월 10.3%에서 3월 33.3%로 3배 증가했다. 검색 최적화 투자도 19%에서 28.9%로 늘어 처음으로 평가(Evaluation) 지출을 넘어섰다.

프롬프트와 컨텍스트는 설계 단위가 다르다

비교 항목	프롬프트 엔지니어링	컨텍스트 엔지니어링
핵심 질문	"어떻게 질문할 것인가?"	"모델이 무엇을 알고·보고·기억할 것인가?"
설계 범위	입력 텍스트 서식	시스템 전체 정보 흐름
외부 데이터	수동 삽입	RAG·MCP 자동 검색·주입
메모리 관리	없음 (단일 호출)	4계층 메모리 아키텍처
에이전트 적합성	단순 Q&A에 적합	복잡 멀티스텝 워크플로우 필수
비용 최적화	프롬프트 길이 단축	토큰 예산 관리·압축·캐싱
평가 방법	주관적 품질 평가	정량 지표 기반 자동화 평가
확장성	단일 모델 한정	멀티에이전트·분산 시스템 확장
진입 장벽	낮음 (자연어 작성)	높음 (파이프라인 설계·코딩 필요)
2026 프로덕션 적합도	낮음	높음

프롬프트 엔지니어링은 단일 입력 텍스트를 최적화하는 작업이다. 컨텍스트 엔지니어링은 외부 데이터 검색, 메모리, 도구 연결, 토큰 배분과 평가를 포함한 시스템 전체의 정보 흐름을 다룬다. 멀티스텝 에이전트로 갈수록 두 접근법의 차이가 커진다.

장문 컨텍스트의 API 비용

컨텍스트를 얼마나 넣을지 결정하려면 모델별 토큰 비용과 장문 입력 정책을 함께 봐야 한다.

모델	입력 ($/1M 토큰)	출력 ($/1M 토큰)	장문 컨텍스트 추가 요금
GPT-4.1	$2.00	$8.00	별도 정책
o3	$10.00	$40.00	별도 정책
Claude Opus 4.6	$5.00	$25.00	없음
Gemini 3.1 Pro	$2.00	$12.00	200K 초과 시 2배 ($4.00/$18.00)
Gemini 3 Flash	$0.50	$3.00	별도 정책

장문 컨텍스트를 많이 사용하는 에이전트 워크플로우에서는 200K 초과분에 추가 요금이 붙는 모델과 고정 요금 모델 사이의 비용 차이가 수십 배까지 벌어질 수 있다. 전체 2M 토큰을 사용하지 않고 RAG로 관련 컨텍스트 50K만 선택해도 비용을 수십 배 줄일 수 있다는 점이 JIT 조합의 경제적 근거다.

조직 역량도 파이프라인 중심으로 바뀐다

컨텍스트 엔지니어링은 기존 프롬프트 작성법에 기술 몇 개를 더하는 수준이 아니다. 검색, 메모리, 토큰 예산과 멀티에이전트 실행을 다루는 방향으로 조직의 역량 체계를 다시 짜야 한다.

⤢✕

초기 0~3개월에는 현재 사용하는 프롬프트 엔지니어링 자산을 인벤토리로 만들고, RAG 파이프라인의 기초를 도입하면서 벡터 DB를 선정한다. 이 시점에 컨텍스트 품질 평가 지표도 정의한다.

이어지는 3~9개월에는 프롬프트 엔지니어를 RAG, MCP와 메모리 아키텍처를 다루는 컨텍스트 설계자로 재교육한다. 벡터와 키워드를 결합한 하이브리드 검색 파이프라인을 만들고 컨텍스트 윈도우 예산 관리 자동화 도구를 도입한다.

9~18개월에는 ACE 기반 멀티에이전트 시스템을 구축하고 ACDL 기반 컨텍스트 명세를 표준화한다. 스토리지는 벡터-그래프 하이브리드 구조로 전환하며 컨텍스트 엔지니어링 CoE(Center of Excellence)를 운영한다. 전체 로드맵의 범위는 2026~2027년이다.

정보관리기술사 AI 활용 역량 체계에서 컨텍스트 엔지니어링은 단순 활용보다 AI 시스템 설계·아키텍처 역량에 가깝다. 2026년 이후 AI 아키텍트 직무 기술서의 핵심 요건으로 자리 잡을 전망이다. 데이터 팀의 95%가 2026년 중 관련 교육 투자를 계획한다는 조사 결과도 이 전환의 압력을 보여준다.

프로덕션 AI에서는 질문을 잘 쓰는 능력만으로 검색 데이터의 최신성, 도구 권한, 메모리 충돌과 토큰 비용을 통제할 수 없다. JIT 동적 조합과 RAG-MCP 하이브리드 파이프라인, 계층적 메모리, 컨텍스트 예산 관리를 하나의 실행 구조로 묶어야 한다. 조직 차원에서는 기존 프롬프트 자산을 컨텍스트 파이프라인으로 옮기고 ACE와 ACDL을 적용할 역량 재구축 로드맵이 필요하다.