프롬프트를 넘어 컨텍스트를 설계하는 JIT 에이전트 아키텍처

2026년 IT·데이터 리더 82%가 “프롬프트 엔지니어링만으로는 프로덕션 AI 시스템에 불충분하다”고 응답했다. 같은 시기 MCP(Model Context Protocol) 공개 서버는 1만 개를 넘어섰다. 에이전트의 결과를 좌우하는 범위가 질문 문구에서 시스템 전체의 정보 조달과 배치로 넓어진 배경이다.

질문을 다듬는 일에서 정보 흐름을 설계하는 일로

Context Engineering은 LLM(Large Language Model)이 작업에 필요한 시스템 프롬프트, 도구 정의, 메모리, 검색 결과, 대화 이력을 적절한 형태로 컨텍스트 윈도우에 넣도록 설계하는 방법론이다.

Anthropic 수석 연구원 Amanda Askell은 2025년 말 “LLM 성능의 70% 이상은 프롬프트 문구가 아니라 어떤 컨텍스트를 어떤 순서로 제공하느냐에 달려 있다”고 명시했다. 이 관점에서 프롬프트 엔지니어링이 “어떻게 질문할 것인가”를 다룬다면, 컨텍스트 엔지니어링은 “어떤 정보를 언제, 어떤 형태로 제공할 것인가”를 다룬다.

따라서 필요한 역량도 문장 작성에 머물지 않는다. 소프트웨어 아키텍처, 정보 검색, 메모리 관리와 도구 설계를 하나의 실행 경로로 연결해야 한다.

긴 컨텍스트가 품질을 보장하지 않는 이유

프롬프트 엔지니어링은 단일 턴(single-turn) 상호작용에서 효과적이지만, 현실의 에이전트 시스템은 여러 차례 도구를 호출하고 중간 상태를 이어받는다. 이 과정에서 수십 번의 도구 호출과 수만 토큰의 결과가 쌓이면 문구 최적화만으로 정보를 관리하기 어렵다.

오래 실행된 에이전트에서는 초기 목표와 제약이 희석되고 낡은 정보가 현재 판단에 섞이는 컨텍스트 부패(Context Rot)도 발생한다. 도구, 메모리와 RAG를 따로 최적화하면 각 요소가 잘 작동하더라도 시스템 전체의 일관성과 효율을 보장하기 어렵다.

2026년 기준 Claude 3.7, GPT-4.1, Gemini 2.5 Pro 등 주요 모델은 100만 토큰 이상의 컨텍스트 윈도우를 지원한다. 그러나 정보를 많이 넣는 것만으로 성능이 향상되지는 않는다. LLM이 컨텍스트 중간부의 정보를 상대적으로 경시하는 “Lost in the Middle” 현상도 계속 관찰된다. 컨텍스트의 크기보다 선별, 순서와 배치가 중요한 이유다.

요청에서 평가까지 이어지는 컨텍스트 경로

컨텍스트 라우터는 사용자 요청에 맞춰 시스템 프롬프트, 도구, 메모리, RAG 결과와 대화 이력을 선택한다. 선택된 정보는 JIT 조합 엔진과 예산 관리자를 거쳐 LLM에 전달된다. 출력이 평가 기준을 통과하지 못하면 동일한 입력을 반복하는 대신 컨텍스트 구성을 조정한다.

⤢✕

필요한 순간에 조합하는 JIT 컨텍스트

JIT(Just-In-Time) 컨텍스트는 모든 정보를 정적 시스템 프롬프트에 미리 넣지 않는다. 요청이 도착했을 때 필요한 정보만 골라 즉시 조합한다.

먼저 입력 쿼리의 의도를 분류해 필요한 컨텍스트 유형을 결정한다. 코드 생성 요청이라면 코드 스타일 가이드와 기존 코드베이스 스니펫을 선택하고, 데이터 분석 요청이라면 스키마 정보와 샘플 데이터를 가져온다.

다음으로 벡터 검색(Vector Search), BM25와 교차 인코더(Cross-Encoder)를 결합한 하이브리드 검색을 수행한다. 수집한 정보는 컨텍스트 중요도 점수에 따라 다시 순위를 매긴다.

마지막으로 시스템 프롬프트, 예시, 도구, 메모리와 RAG 결과에 토큰 예산을 배정한다. 슬롯은 우선순위에 따라 채우며, 예산을 넘으면 우선순위가 낮은 항목부터 동적 압축을 적용한다.

토큰 예산은 슬롯별로 다르게 다룬다

모든 컨텍스트가 같은 중요도와 압축 내성을 갖지는 않는다. 현재 작업 정보는 높은 우선순위로 보존해야 하지만, 사용하지 않는 도구 정의나 오래된 대화 이력은 먼저 줄일 수 있다.

컨텍스트 슬롯	기본 토큰 비율	압축 적용 우선순위	압축 방법
시스템 프롬프트	5-10%	최후 적용	핵심 제약만 유지
도구 정의	10-15%	미사용 도구 제거	선택적 도구 로딩
장기 메모리	5-10%	시간 기반 TTL 적용	요약 기반 압축
RAG 결과	20-30%	재랭킹 후 상위 N개	청크 크기 동적 조절
대화 이력	20-30%	중간 턴 요약 우선	롤링 요약 적용
현재 작업 컨텍스트	20-30%	최고 우선순위 유지	핵심 정보만 보존

동적 압축은 토큰을 기계적으로 잘라내는 작업이 아니다. 의미 보존 요약(Semantic Summarization)을 사용해 핵심 관계를 남겨야 한다. LLM을 이용한 재귀적 요약과 핵심 엔티티·관계 추출 방식은 2026년 프로덕션 표준으로 정착되고 있다.

MCP 서버도 컨텍스트 공급자로 설계해야 한다

Model Context Protocol(MCP)은 Anthropic이 2024년 11월 공개한 오픈 표준이다. 2026년 6월 현재 공개 MCP 서버가 1만 개를 돌파했으며, LLM이 외부 데이터 소스, API와 파일 시스템에 표준화된 방식으로 접근하는 기반으로 자리 잡았다.

MCP 서버가 한 번의 도구 호출로 지나치게 많은 데이터를 반환하면 컨텍스트 윈도우가 빠르게 소모된다. 반환 데이터의 세분화 수준(Granularity)과 토큰 상한(Token Cap)을 명시적으로 설계해야 컨텍스트 조각화를 줄일 수 있다.

반환 데이터에는 신선도(Freshness), 신뢰도(Confidence), 출처(Source) 메타데이터를 함께 넣을 수 있다. 컨텍스트 라우터는 이 정보를 재랭킹에 활용한다.

도구 노출 역시 계층화가 필요하다. 자주 쓰는 고수준 도구와 세부 작업용 저수준 도구를 나누고, 기본 컨텍스트에는 고수준 도구를 포함한다. 저수준 도구는 실제로 필요해진 시점에 JIT 방식으로 불러온다.

프롬프트 기술과 컨텍스트 설계가 요구하는 역량

두 접근법은 서로 배타적이라기보다 적용 범위가 다르다. 프롬프트 엔지니어링이 개별 호출의 지시를 다듬는다면, 컨텍스트 엔지니어링은 여러 호출과 외부 시스템을 잇는 정보 구조를 관리한다.

비교 항목	프롬프트 엔지니어링	컨텍스트 엔지니어링
핵심 관심사	문구·지시 최적화	정보 설계·흐름 제어
적용 범위	단일 LLM 호출	멀티턴·멀티에이전트 시스템
주요 기술	Few-shot, Chain-of-Thought	RAG, 메모리, MCP, 토큰 예산 관리
평가 지표	출력 품질, 지시 준수율	컨텍스트 효율성, 에이전트 완료율
유지보수 난이도	낮음 (텍스트 편집 수준)	높음 (시스템 아키텍처 수준)
확장성	제한적 (토큰 한계 도달 시 중단)	높음 (동적 압축·외부 메모리 활용)
팀 역량 요구	언어 직관, 도메인 지식	SW 아키텍처, 정보 검색, ML 운영
2026년 채택률	단독 활용 18%	통합 적용 82%

장기 실행에서 컨텍스트 부패를 막는 장치

에이전트가 수십 단계의 작업을 자율적으로 수행하면 최초 목표, 중간 판단과 과거 기록이 같은 컨텍스트 안에서 경쟁한다. 이때 품질 저하는 목표 희석, 오류 누적과 컨텍스트 오염으로 나타난다.

목표 희석(Goal Dilution)은 하위 작업이 늘어나면서 최초 사용자 목표가 컨텍스트에서 밀리거나 중요도를 잃는 현상이다. 목표 앵커(Goal Anchor)는 매 N턴마다 최초 목표를 컨텍스트 선두에 다시 주입하거나 고정 메모리 슬롯에 상주시켜 이를 방지한다.

오류 누적(Error Accumulation)은 중간 단계의 부정확한 정보가 다음 판단의 근거가 되면서 증폭되는 문제다. 체크포인트(Checkpoint) 기반 상태 검증과 롤백 메커니즘으로 대응한다.

컨텍스트 오염(Context Pollution)은 관련성이 낮아진 대화 이력, 실패한 도구 호출 결과와 중간 스크래치패드가 판단을 방해하는 상태다. 적극적인 컨텍스트 가지치기(Context Pruning)와 롤링 요약(Rolling Summarization)을 적용해 불필요한 기록을 덜어낸다.

평가는 도입 이후가 아니라 설계의 출발점이다

조직에 컨텍스트 엔지니어링을 적용하려면 현재 정보 흐름을 먼저 감사해야 한다. Context Audit에는 1-2주를 두고 기존 프롬프트에 포함된 정보와 누락된 정보를 분석한다. 토큰 사용 분포와 컨텍스트 활용 효율성을 측정할 기준선(Baseline)도 이 단계에서 세운다.

이어 2-4주 동안 Eval Framework를 구축한다. 컨텍스트 효율성, 에이전트 작업 완료율과 할루시네이션 발생률을 지표로 정의하고 자동화된 평가 파이프라인을 만든다. Anthropic의 Claude Eval, LangSmith와 Braintrust 등의 평가 프레임워크가 활용된다.

JIT 컨텍스트 프로토타입에는 4-8주를 배정한다. 가장 자주 사용하는 에이전트 워크플로우부터 JIT 조합을 시범 적용하고, 벡터 DB(Pinecone, Weaviate, pgvector)와 메모리 레이어를 연결한다. MCP 서버를 이용한 외부 컨텍스트 조달도 이 과정에서 구현한다.

프로토타입 이후에는 평가 결과를 설계로 되돌리는 반복 개선 루프를 지속한다. A/B 테스트로 컨텍스트 슬롯 비율과 압축 전략을 조정하고, 신규 MCP 서버를 통합해 조달 가능한 컨텍스트의 품질을 높인다.

AI 정보시스템 아키텍처와의 연결점

정보관리기술사의 인공지능 응용 및 지식정보시스템 영역에서 컨텍스트 엔지니어링은 RAG(Retrieval-Augmented Generation)의 컨텍스트 통합 메커니즘, 에이전트 아키텍처의 메모리·도구·계획, 토큰 경제(Token Economy)와 컨텍스트 윈도우 관리 전략에 연결된다.

MCP(Model Context Protocol)는 AI 시스템 표준화 관점에서 다룰 수 있고, JIT 컨텍스트 조합은 실시간 정보 검색·통합 시스템 설계와 맞닿아 있다. 롤링 요약과 목표 앵커는 AI 시스템 신뢰성 및 품질 관리 체계 안에서 설명할 수 있다. 결국 평가 대상은 개별 프롬프트 작성 능력보다 AI 기반 정보시스템의 아키텍처를 설계하는 역량에 가깝다.

프롬프트 문구는 여전히 필요하다. 다만 프로덕션 에이전트에서는 그것만으로 충분하지 않다. JIT 컨텍스트 조합, 컨텍스트 윈도우 예산 관리, MCP 통합과 컨텍스트 부패 방지를 함께 설계해야 정보가 필요한 시점에 필요한 형태로 모델에 도달한다. 2026년 프로덕션 AI 시스템에서 기술 리더가 다뤄야 할 대상은 단일 프롬프트가 아니라 이 전체 경로다.