에이전트 시대의 컨텍스트 엔지니어링 아키텍처
프롬프트 최적화를 넘어 도구·메모리·RAG·대화 이력을 조달하고 조합하는 컨텍스트 엔지니어링 아키텍처와 운영 전략을 다룬다.
2026-08-15 · 최초 발행 2026-08-02
프롬프트만 다듬어서는 부족한 이유
IT·데이터 리더의 82%가 프롬프트 최적화만으로는 프로덕션 AI에 부족하다고 응답했다. Gartner는 2026년 말까지 엔터프라이즈 애플리케이션의 40%가 태스크 특화 AI 에이전트를 탑재할 것으로 예측했다. 멀티턴 대화, 여러 에이전트의 협업, 장시간 이어지는 작업에서는 한 번 잘 작성한 입력문보다 실행 중 어떤 정보를 가져오고 남길지가 더 큰 영향을 미친다.
컨텍스트 윈도우도 Claude 3.7 200K, Gemini 1.5 Pro 1M, GPT-4o 128K 토큰까지 확장됐다. 수용량이 커지면서 문제의 초점은 단순히 정보를 더 넣는 데서 벗어났다. 필요한 정보를 고르고, 적절한 위치에 배치하며, 오래되거나 충돌하는 내용을 걷어내는 설계가 필요해졌다.
서브에이전트와 오케스트레이터를 결합한 구조에서는 컨텍스트 전달·유지·요약이 병목이 된다. RAG 환각, 에이전트 루프 오류, 오염된 정보에 따른 품질 저하도 반복됐다. 여기에 MCP(Model Context Protocol) 공개 서버가 2026년 6월 기준 10,000개를 넘으면서 외부 컨텍스트를 표준 방식으로 조달하는 생태계가 형성됐다. Andrej Karpathy를 비롯한 AI 선구자들이 제기한 “프롬프트 엔지니어링은 죽었다(Prompt Engineering is dead)”는 선언은 이런 변화와 맞닿아 있다.
컨텍스트 엔지니어링이 다루는 것
컨텍스트 엔지니어링은 LLM이 추론할 때 참조하는 모든 정보를 동적으로 조달하고 조합하며 압축·관리하는 엔지니어링 분야다. 대상은 시스템 프롬프트에 한정되지 않는다. 도구 정의, 메모리, 검색 결과, 대화 이력, 사용자 상태가 모두 컨텍스트 윈도우의 재료다.
실제 설계 범위에는 시스템 프롬프트의 버전 관리, 도구 함수와 파라미터 스키마의 제공 방식, 단기·장기 메모리 구조, RAG 파이프라인, 토큰 예산 배분, 에이전트 사이의 핸드오프 프로토콜이 포함된다. 이 관점에서 프롬프트 엔지니어링은 독립된 전체가 아니라 시스템 프롬프트를 최적화하는 하위 레이어로 자리 잡는다.
| 구분 | 프롬프트 엔지니어링 | 컨텍스트 엔지니어링 |
|---|---|---|
| 조작 단위 | 단일 텍스트 입력 | 컨텍스트 윈도우 전체 |
| 설계 범위 | 명령 표현 최적화 | 정보 조달·배치·압축·갱신 |
| 적용 시점 | 정적, 실행 전 설계 | 동적, 실행 중 JIT 조합 |
| 필요한 역량 | NLP 언어 감각 | 시스템 설계·데이터 파이프라인·ML |
| 성능 병목 | 표현 품질 | 컨텍스트 정밀도·신선도·예산 효율 |
| 주요 실패 | 지시 불이행·환각 | 컨텍스트 오염·예산 초과·부패 |
| 에이전트 지원 | 단일 턴 중심 | 멀티턴·멀티에이전트 전 구간 |
| MCP 연계 | 미지원 | 네이티브 통합 |
프롬프트·컨텍스트·파인튜닝의 선택 기준
프롬프트 엔지니어링, 컨텍스트 엔지니어링, 파인튜닝은 어느 하나가 나머지를 완전히 대체하는 관계가 아니다. 변경하려는 대상과 문제의 범위가 다르므로 단계에 맞춰 조합한다. 단일 프롬프트 텍스트의 명확성이나 출력 형식을 조정할 때는 프롬프트 엔지니어링을 적용한다. 검색 결과, 메모리, 도구 설명, 대화 이력처럼 실행 중 바뀌는 정보의 조달과 배치가 문제라면 컨텍스트 엔지니어링이 대상이다. 모델 가중치 자체에 도메인 특화 스타일과 형식, 지식 내재화가 필요하고 컨텍스트 설계로 해결되지 않을 때는 파인튜닝을 적용한다.
| 구분 | 프롬프트 엔지니어링 | 컨텍스트 엔지니어링 | 파인튜닝 |
|---|---|---|---|
| 대상 | 단일 프롬프트 텍스트 | 전체 컨텍스트 윈도우 | 모델 가중치 |
| 적용 범위 | 단순 태스크 | 복잡한 에이전트 워크플로우 | 도메인 특화 지식 |
| 개발 비용 | 낮음 | 중간 | 높음 |
| 유지보수 | 쉬움 | 중간 | 어려움 |
| 최신 정보 반영 | 즉시(RAG) | 즉시(JIT) | 재학습 필요 |
성능 개선은 프롬프트, 컨텍스트 엔지니어링(RAG 포함), 파인튜닝, 디스틸레이션 순으로 접근한다.
컨텍스트를 레이어로 나누는 아키텍처
컨텍스트 윈도우를 하나의 긴 문자열로 취급하면 정보의 출처와 우선순위를 관리하기 어렵다. 시스템, 도구, 메모리, 검색, 대화 레이어를 분리하고 예산 관리자가 각 레이어의 투입량을 조정하는 방식이 필요하다.
시스템 레이어에는 역할, 페르소나, 행동 원칙, 출력 형식을 두며 전체 예산의 5~15%를 배정한다. 도구 레이어는 MCP 서버의 함수 시그니처, 파라미터 스키마, 사용 예시를 필요할 때 불러온다.
메모리는 세션 내 대화를 담는 단기 계층, 에이전트 작업 요약을 보관하는 중기 계층, 벡터 DB 검색으로 접근하는 장기 계층의 3계층으로 나뉜다. 검색 레이어에는 RAG 청크, 웹 검색 결과, 구조화 데이터 조회 결과가 들어간다. 대화 레이어는 슬라이딩 윈도우를 적용하거나 이전 이력을 요약해 압축한다.
이 레이어들을 실제 컨텍스트 윈도우에 얼마나 넣을지는 예산 관리자가 결정한다. 단순한 에이전트에서는 레이어별 비율을 고정할 수 있지만, 복잡한 작업에서는 태스크 난도, 남은 단계 수, 도구 호출 빈도에 따라 실시간으로 재분배하는 편이 맞다. 관련성 점수에 기반한 우선순위 큐를 사용하면 중요도가 낮은 청크부터 제거할 수 있다.
예산은 정보의 총량보다 현재 태스크에 기여하는 정보의 밀도로 관리한다. 필요한 레이어부터 점진적으로 노출하고, 태스크에 필요한 최소 도구만 제시하며, 긴 이력은 시맨틱 요약으로 교체한다. 수집한 청크는 관련성 점수에 따라 우선순위 프루닝을 적용해 남기면, 같은 토큰 예산 안에서도 관련 없는 정보가 attention을 분산시키는 컨텍스트 오염을 줄일 수 있다.
예산이 70% 소진된 Warning Zone에서는 중요하지 않은 이력을 요약한다. 85%에 이르는 Critical Zone에서는 강제 요약과 외부 메모리 오프로딩을 수행하고, 95%인 Emergency Zone에서는 핵심 컨텍스트만 남긴다. 투입 효율은 Context Utilization Rate(CUR)로 볼 수 있다.
CUR = 유효 정보 토큰 / 총 투입 토큰
실행 직전에 조립하는 JIT 패턴
컨텍스트를 미리 고정해 두면 최신 상태를 반영하기 어렵고, 사용하지 않을 도구 정의까지 토큰을 차지한다. JIT(Just-In-Time) 어셈블리는 태스크를 받은 뒤 필요한 정보원을 판단하고 실행 직전에 컨텍스트를 구성한다.
먼저 사용자 요청의 태스크 유형, 도메인, 복잡도를 분류한다. 컨텍스트 플래너는 이 결과를 바탕으로 사용할 도구, 검색 쿼리, 메모리 키를 정한다. MCP 호출과 RAG·메모리 검색은 병렬로 실행해 레이턴시를 줄이고, 어셈블리 엔진은 수집한 청크를 중요도 순서로 정렬한다. 예산 검증을 통과한 결과만 LLM 추론에 투입한다.
오래 실행되는 에이전트가 상태를 잃지 않으려면
장기 실행 작업에서는 원본 대화를 끝없이 쌓는 방식이 통하지 않는다. N 스텝마다 실행 상태와 결과 요약을 외부 스토리지에 저장하는 체크포인트가 필요하다. 오래된 대화는 롤링 요약으로 압축하고 원본을 제거한다.
완료된 서브태스크 결과는 에피소딕 메모리에 구조화해 색인한다. 다른 에이전트로 작업을 넘길 때는 핵심 상태를 직렬화하는 핸드오프 규약을 적용하며, MCP context object를 이 전달 형식으로 사용할 수 있다.
반드시 유지해야 하는 사실, 제약, 결정은 핀드(Pinned) 컨텍스트 슬롯에 둔다. 에이전트 루프가 다시 시작되면 이 슬롯부터 복구해 작업 중 망각을 막는다.
멀티에이전트의 작업 맥락과 격리 경계
여러 에이전트가 협력할 때는 모든 정보를 모두에게 전달하지 않는다. 오케스트레이터가 관리하는 작업 목표와 전역 제약조건, 에이전트 사이에 전달해야 하는 중간 결과는 공유 컨텍스트에 둔다. 반면 각 에이전트의 컨텍스트 윈도우에는 해당 작업에 필요한 도구 스키마, 도메인 지식, 작업 이력만 둬야 한다.
위임할 때는 전체 대화 히스토리 대신 관련 내용의 요약, 필요한 도구 목록, 성공 기준을 담은 최소 컨텍스트 패키지를 만든다. 여러 에이전트가 같은 상세 정보에 접근해야 한다면 공유 메모리 버스를 두고, 각 에이전트는 필요한 자료를 외부 메모리 스토어에서 읽는다. 독립적으로 병렬 실행하는 태스크는 서로의 정보가 섞이지 않도록 격리된 컨텍스트를 유지한다.
하위 에이전트의 긴 결과를 원문 그대로 오케스트레이터에 삽입하지 않는다. 작업 결과와 핵심 상태를 구조화한 상태 델타(state delta), 핵심 사실, 액션 아이템만 전달하면 단계가 이어져도 컨텍스트가 불필요하게 팽창하지 않는다.
MCP가 바꾸는 컨텍스트 조달 방식
MCP는 웹 검색, 데이터베이스, 외부 API, 파일시스템, 코드 실행, 메모리 서버를 에이전트와 연결한다. 각 서버의 함수 시그니처와 파라미터 스키마는 재사용할 수 있는 컨텍스트 블록이 된다.
10,000개 서버 생태계의 카테고리별 분포는 웹 검색 18%, DB 커넥터 15%, 코드 실행 12%, 파일시스템 10%, 메모리·지식베이스 9%, 기타 36%다.
서버는 태스크 도메인 매핑을 기준으로 자동 선정할 수 있다. 레이턴시와 신뢰도 점수에 따라 우선순위를 정하고, 장애에 대비해 폴백(Fallback) 체인을 구성한다. 다만 연결한 서버가 많아질수록 도구 정의가 차지하는 토큰도 늘어난다. 필요한 시점에만 도구 정의를 삽입하는 동적 로딩이 필요한 이유다.
내부 MCP 서버 라이브러리를 먼저 구축하면 에이전트 개발 시간이 63% 단축되고 컴플라이언스 감사도 단순화된다는 조사 결과가 있다.
서버 응답 형식이 제각각이면 그대로 컨텍스트에 넣기 어렵다. 응답을 표준 컨텍스트 청크로 변환하는 어댑터 레이어가 이 경계를 맡아야 한다.
쌓인 정보가 추론을 망치는 컨텍스트 부패
컨텍스트 부패(Context Rot)는 장기 실행 중 오래되거나 중복되고 부정확한 정보가 남아 추론 품질을 점진적으로 떨어뜨리는 현상이다.
시간 부패(Temporal Rot)는 최신성을 잃은 데이터가 잔류할 때 발생한다. 중복 부패(Redundancy Rot)는 같은 정보가 반복 삽입돼 유효 정보 밀도를 낮춘다. 모순 부패(Contradiction Rot)는 서로 충돌하는 정보가 함께 남는 문제이며, 오염 부패(Injection Rot)는 프롬프트 인젝션이나 노이즈 데이터가 유입되는 경우다.
| 전략 | 처리 방식 | 적용 시점 |
|---|---|---|
| TTL 기반 만료 | 컨텍스트 청크별 유효 기간을 설정하고 자동 제거 | 실시간 |
| 중복 해시 필터 | 동일 청크의 재삽입 방지(semantic dedup) | 어셈블리 단계 |
| 출처 검증 | RAG 결과 중 신뢰도 임계치 미달 청크 필터링 | 검색 단계 |
| 모순 감지 | LLM으로 상충 정보를 탐지하고 최신 정보 우선 유지 | 주기적 |
| 컨텍스트 감사 로그 | 청크 삽입·제거 이력을 추적해 부패 원인 분석 | 운영 단계 |
RAG 결과도 정제한 뒤 넣어야 한다
유사도 검색 결과를 곧바로 컨텍스트에 삽입하는 기존 RAG 방식은 청크 경계 문제, 정보 오염, 예산 낭비를 일으킨다. 현재 대화 맥락을 반영해 검색 쿼리를 재구성하고, 1차 결과에서 다음 질문을 만들어 2차 검색으로 이어가는 멀티홉 구조가 필요하다.
VentureBeat의 Q1 2026 RAG 인프라 시장 조사에서는 하이브리드 검색 도입 의향이 2026년 1월 10.3%에서 3월 33.3%로 3배 이상 증가했다. IT·데이터 리더의 77%는 RAG만으로 프로덕션 AI의 정확성과 신뢰성 요구를 충족하기 어렵다고 응답했다.
검색 결과는 Cross-encoder 기반 재순위화(Re-ranking)로 관련성을 다시 정렬한다. 삽입 전에는 메타데이터를 제거하고, 중복 문장을 압축하며, 핵심 내용을 추출하는 청크 청소(Chunk Cleaning)를 거친다. 각 청크에 출처 ID를 부여하는 인용 앵커링(Citation Anchoring)은 생성된 답변과 근거를 연결한다.
Agentic RAG에서는 에이전트가 ReAct 루프 안에서 검색 도구를 호출하며 쿼리를 스스로 정제하고 반복한다. 밀집 벡터 검색(Dense Retrieval)과 희소 키워드 검색(BM25)을 결합한 하이브리드 검색은 검색 정밀도를 높이는 방식이다.
품질 평가는 컨텍스트 자체를 향해야 한다
응답 결과만 평가하면 실패 원인이 모델에 있는지, 잘못 조립된 컨텍스트에 있는지 구분하기 어렵다. 프로덕션 모니터링에서 품질 저하를 감지한 뒤 컨텍스트를 평가하고, 원인 분석과 최적화, A/B 테스트를 거쳐 다시 배포하는 순환 구조가 필요하다.
Context Precision은 삽입된 내용 가운데 실제 답변에 활용된 비율이고, Context Recall은 정답에 필요한 정보가 포함된 비율이다. Context Freshness는 정보의 최신성을 나타낸다. Budget Efficiency는 CUR로 본 유효 정보 밀도이며, Response Coherence는 컨텍스트가 바뀌어도 응답이 얼마나 안정적인지를 평가한다.
태스크 관점에서는 컨텍스트를 다시 조합하지 않고 첫 추론에서 작업을 마친 비율인 1회 성공률(First-Pass Success Rate), 정보 부족이나 오류로 재조회한 횟수, 전체 지연 시간에서 조달 단계가 차지하는 비중도 함께 측정한다. 캐싱이나 공유를 통해 다시 사용한 컨텍스트 토큰의 비율은 비용 효율성을 판단하는 기준이 된다.
RAGAS는 RAG 파이프라인의 정밀도와 재현율 측정을 자동화한다. LLM-as-Judge는 평가자 LLM으로 컨텍스트 활용도를 점수화하며, 트레이스 분석은 토큰별 어텐션 가중치를 바탕으로 실제 사용된 컨텍스트를 식별한다. 반복 개선은 2주 스프린트를 기준으로 구성 실험, 지표 측정, 원인 분석, 최적화, 재배포를 잇는다.
정보자원관리와 AI 운영의 접점
조직 관점에서 컨텍스트 엔지니어링은 보유 지식을 LLM이 사용할 수 있는 구조로 바꾸고 관리하는 정보자원관리의 확장이다. 엔터프라이즈 데이터 레이크를 RAG 인덱스와 연결해 검색 레이어를 만들고, 레거시 시스템 API는 MCP 서버로 감싸 에이전트가 접근하도록 구성할 수 있다.
보안 경계도 컨텍스트 단위로 설계해야 한다. 민감 정보는 마스킹 레이어에서 처리하고, 어떤 정보가 언제 삽입됐는지 감사 추적(Audit Trail)에 기록한다. 외부 데이터를 컨텍스트에 넣기 전에는 프롬프트 인젝션 방어를 위한 sanitization이 필요하다.
거버넌스 측면에서는 시스템 프롬프트와 도구 정의를 Git으로 버전 관리한다. 구성 변경 전에는 영향도를 평가하고 롤백 계획을 마련한다. 컨텍스트 조달 레이턴시는 SLA로 관리하며 목표는 P99 < 500ms다. 품질 기준에는 ISO/IEC 25010의 신뢰성(Reliability), 성능 효율성(Performance Efficiency), 유지보수성(Maintainability)을 적용한다.
조직에 적용하는 전환 순서
도입 초기에는 프롬프트 자산과 현재 컨텍스트 흐름부터 파악해야 한다. 이후 RAG와 MCP를 연결하고, 예산 관리와 장기 실행 메모리를 자동화한 뒤 평가 체계로 운영을 고도화한다.
기반 구축은 1~2개월 동안 진행한다. 현행 프롬프트 자산의 인벤토리를 만들고, 시스템 프롬프트를 Git으로 관리하며, 변경 이력을 추적한다. 컨텍스트 품질 지표를 정의하고 기준선(Baseline)도 측정한다.
파이프라인 구축은 3~4개월 구간이다. RAG를 컨텍스트 어웨어 방식으로 고도화하고, MCP 서버를 선정·통합해 도구 정의를 컨텍스트화한다. 시스템·도구·메모리·검색·대화 레이어를 분리하는 아키텍처도 이때 적용한다.
고도화는 5~8개월 동안 예산 관리자를 자동화하고 JIT 어셈블리 엔진을 개발해 A/B 테스트하는 단계다. 장기 실행 에이전트를 위한 체크포인트와 롤링 요약도 구현한다.
최적화는 9~12개월 구간에 해당한다. RAGAS와 LLM-as-Judge를 결합한 평가 자동화 파이프라인을 구축하고, 컨텍스트 부패 탐지와 자동 정화(Purging)를 적용한다. 마지막에는 컨텍스트 엔지니어링 역량을 조직 전체에 내재화한다.
2026년 이후 예상되는 변화
고수준 컨텍스트 명세 언어(Context Specification Language)를 LLM에 적합한 컨텍스트로 변환하는 컨텍스트 컴파일러가 도구 체계로 등장할 전망이다. 텍스트뿐 아니라 이미지, 오디오, 비디오, 코드, 테이블이 같은 윈도우에서 서로를 참조하는 멀티모달 컨텍스트 설계도 표준화 방향으로 움직이고 있다.
Anthropic의 Prompt Cache처럼 반복해서 쓰는 컨텍스트 블록을 서버 수준에서 캐싱해 레이턴시와 비용을 줄이는 방식은 클라우드 3사의 공통 지원 방향이다. 사용자별 장기 메모리는 지식 그래프 형태로 관리돼 개인화 컨텍스트를 자동 조달하는 구조로 발전할 수 있다.
2026 하반기에는 국내외 주요 테크 기업의 JD에 “Context Engineer” 포지션이 공식 등장할 전망이다. EU AI Act와 국내 AI 기본법의 설명가능성(Explainability) 요구에 대응하기 위해 컨텍스트 추적을 의무화하는 논의도 진행 중이다. 에이전트가 자신의 컨텍스트 품질을 평가하고 개선하는 메타인지(Meta-Cognitive) 루프 연구 역시 활성화되고 있다.
컨텍스트 엔지니어링은 프롬프트 작성 기법의 확장이 아니라 LLM을 생산 시스템에 통합하기 위한 소프트웨어 엔지니어링 영역이다. MCP 10,000 서버 생태계가 조달 인프라를 형성한 상황에서는 JIT 어셈블리, 컨텍스트 부패 방지, 평가 기반 반복 개선을 함께 설계해야 한다. 데이터 아키텍처와 정보자원관리, IT 거버넌스의 원칙도 이 운영 체계 안에서 연결된다.
Sources
- Andrej Karpathy, "Context Engineering" (X/Twitter thread, 2025)
- Anthropic, Model Context Protocol Specification, https://modelcontextprotocol.io
- Simon Willison, "Prompt Engineering vs Context Engineering" (2025)
- RAGAS Framework Documentation, https://docs.ragas.io
- Anthropic, "Prompt Caching with Claude" Developer Docs (2025)
- Cobus Greyling, "Context Engineering: The Next Frontier" (Medium, 2025)
- LangChain Blog, "Agentic RAG Patterns" (2025)
- MCP Server Registry, https://mcpservers.org (2026.06 기준 10,000+ 서버)
- EU AI Act Official Text, https://artificialintelligenceact.eu
- 한국 AI 기본법 제정안, 과학기술정보통신부 (2026)