컨텍스트 엔지니어링으로 설계하는 MCP 기반 에이전틱 AI

프롬프트만 다듬어서는 해결되지 않는 문제

에이전트가 틀린 답을 내놓았을 때 원인이 언제나 지시문에 있는 것은 아니다. 필요한 문서가 빠졌거나 오래된 상태가 남아 있고, 현재 작업과 무관한 정보가 판단을 흐렸을 수도 있다. 이 경우 프롬프트를 다시 쓰는 것만으로는 같은 실패를 막기 어렵다.

2024년 프롬프트 엔지니어, 2025년 RAG 아키텍트에 이어 2026년 AI 실무에서는 컨텍스트 엔지니어라는 역할이 요구되고 있다. 성능을 좌우하는 초점도 프롬프트의 문장 품질에서 모델에 어떤 정보를 어떤 순서와 형태로 전달할 것인지로 옮겨갔다. Model Context Protocol(MCP)이 런타임 컨텍스트 조립의 사실상 표준으로 자리 잡으면서 이러한 변화는 에이전틱 AI의 구현 구조에 직접 반영되고 있다.

컨텍스트 엔지니어링(Context Engineering)은 LLM을 호출하기 전에 컨텍스트 윈도우 전체를 설계하고 구성하며 최적화하는 접근 방식이다. 프롬프트 엔지니어링이 “어떻게 물을 것인가”를 다룬다면, 컨텍스트 엔지니어링은 “판단 시점에 모델이 무엇을 알고 있어야 하는가”를 다룬다. 이 정보 환경은 5개 레이어로 나눌 수 있다.

지시와 예시가 행동의 경계를 만든다

첫 번째 레이어인 시스템 프롬프트는 단순한 페르소나 설정이 아니다. 에이전트의 역할 범위와 제약 조건, 출력 형식에 관한 계약을 담는 운영 헌장에 가깝다. 어떤 조건에서 도구를 사용해야 하는지, 모델이 직접 판단할 사안과 사람에게 넘길 사안을 어떻게 구분할지도 여기에 반영된다.

두 번째 레이어는 **인컨텍스트 학습(In-Context Learning, ICL)**이다. 파인튜닝 없이 몇 가지 예시(few-shot examples)를 컨텍스트에 넣어 모델의 행동을 조정한다. 에이전틱 시스템에서는 도구를 사용하는 방식, 오류에서 복구하는 과정, 도메인에 맞는 추론 체계를 예시로 전달할 수 있다.

ICL의 효과는 예시의 질과 현재 작업에 대한 관련성에 직접 좌우된다. 따라서 예시를 많이 넣는 것보다 어떤 사례를 선택해 어느 호출에 제공할지를 결정하는 일이 더 중요한 설계 문제가 된다.

도구 명세와 메모리는 실행 상태를 연결한다

세 번째 레이어는 **도구 스펙(Tool Specification)**이다. 함수 시그니처와 파라미터 설명, 사용 조건, 반환 형식을 얼마나 정확하게 작성했는지가 에이전트의 도구 선택 정밀도에 영향을 준다. arXiv 논문 2602.14878은 MCP 도구 설명의 품질이 에이전트 효율성에 직접 영향을 준다는 사실을 실험적으로 입증했으며, 보강된 도구 설명(augmented tool descriptions)이 원본보다 태스크 성공률을 유의미하게 높였다고 보고했다.

네 번째 레이어인 **메모리 레이어(Memory Layer)**는 여러 호출에 걸친 작업의 상태를 이어 준다. 장기 작업을 수행하는 에이전트에는 단일 요청과 응답만으로는 확보할 수 없는 지속성이 필요하다.

메모리는 개별 상호작용을 기록하는 에피소드 메모리, 일반화된 지식을 담는 시맨틱 메모리, 작업 수행 방법을 보존하는 절차적 메모리, 현재 컨텍스트의 상태를 유지하는 워킹 메모리로 구분된다. 각 유형을 무조건 함께 넣는 것이 아니라, 필요한 시점과 조건을 정해 컨텍스트에 주입해야 한다.

RAG는 더 큰 조립 파이프라인에 들어간다

다섯 번째 레이어는 RAG(Retrieval-Augmented Generation) 파이프라인이다. 2025년 RAG 아키텍트가 주목받은 배경에는 LLM의 정적 지식 한계를 외부 검색으로 보완했을 때 얻는 실질적인 성능 향상이 있었다.

2026년의 컨텍스트 엔지니어링에서는 RAG를 독립된 검색 기능으로 두지 않고 더 큰 컨텍스트 어셈블리 파이프라인의 일부로 취급한다. 검색 문서의 리랭킹(reranking), 요약과 압축, 스키마 주입, 토큰 예산 관리가 하나의 흐름으로 조정되며, 이 과정은 LLM을 호출할 때마다 실시간으로 실행된다.

다음 구조는 5개 레이어가 런타임에 모여 하나의 컨텍스트 윈도우를 만드는 과정을 보여 준다.

⤢✕

정적 최적화와 런타임 조립의 차이

프롬프트 최적화는 배포 전에 정해 둔 문장이 일정한 조건에서 반복해서 쓰인다는 점에서 정적(static)이다. 잘 만든 프롬프트도 실행 조건이 달라지면 성능이 급격히 떨어질 수 있다. 프로덕션 에이전틱 AI의 실패를 분석하면 모델이 잘못된 지시를 받은 것이 아니라 잘못된 정보를 가진 채 판단한 사례가 반복된다.

두 접근 방식의 책임 범위는 다음처럼 다르다.

구분	정적 프롬프트 최적화	런타임 컨텍스트 조립
설계 시점	배포 전 (오프라인)	호출 시 (실시간)
소유 주체	개인 개발자 / AI 팀	플랫폼 팀 / 인프라
적응성	낮음 (고정)	높음 (동적)
실패 원인	지시 불명확	정보 부재 · 오염
핵심 기술	프롬프트 패턴	검색·압축·라우팅 인프라
확장 가능성	제한적	API 서버·파이프라인과 동급

Elasticsearch Labs, Neo4j, Roadie 등 주요 엔터프라이즈 AI 플랫폼은 컨텍스트 엔지니어링을 프롬프트 엔지니어링을 포함하는 상위 개념으로 설명한다. 프롬프트는 전체 컨텍스트를 이루는 한 요소이고, 컨텍스트 엔지니어링은 검색과 메모리, 도구, 상태를 포함한 생태계 전체를 설계하는 역할이다.

MCP가 도구 선택을 런타임으로 옮긴다

Model Context Protocol(MCP)은 Anthropic이 2024년 11월 공개한 오픈 프로토콜이다. 2025년 12월에는 Linux Foundation의 Agentic AI Foundation에 기증됐다. 2026년 3월 기준 월간 SDK 다운로드 수는 9,700만 건을 돌파했고, 공개 MCP 서버는 1만 개 이상 배포되어 있다.

MCP의 핵심 가치는 동적 도구 선택(dynamic tool selection)을 표준화된 방식으로 지원하는 데 있다. 기존에는 에이전트가 사용할 도구를 코드에 하드코딩했다. MCP에서는 에이전트가 서버에 연결할 때 디스커버리 메커니즘을 통해 사용 가능한 도구 목록 전체를 받고, 실행 중인 컨텍스트에 따라 호출할 도구를 선택한다.

이 구조에는 다음 역할이 참여한다.

MCP 호스트는 Claude Desktop, IDE, AI 애플리케이션처럼 LLM이 실행되는 환경이다.
MCP 클라이언트는 호스트 안에서 MCP 서버와 1:1 세션을 유지한다.
MCP 서버는 도구(Tools), 리소스(Resources), 프롬프트(Prompts)를 JSON-RPC 2.0 기반으로 노출하는 경량 프로세스다.
Tool Description Router는 설정에 따라 도구 설명을 동적으로 선택하거나 교체한다.

MCP가 도입되면서 도구 스펙 레이어는 미리 고정한 명세에서 동적 발견(discovery)을 활용하는 구조로 이동했다. 에이전트는 모든 도구를 사전에 알 필요 없이 현재 컨텍스트에 맞는 MCP 서버에 연결한 후, 그 시점에 제공되는 도구를 파악해 선택할 수 있다. 이 변화는 컨텍스트 엔지니어링을 프롬프트 작성 기법이 아니라 소프트웨어 아키텍처의 문제로 확장한다.

장기 작업에는 컨텍스트 거버넌스가 필요하다

에이전트가 자율적으로 긴 작업을 수행하면 컨텍스트에는 도구 결과와 사용자 지시, 검색 문서, 중간 판단이 계속 쌓인다. 관리되지 않은 컨텍스트는 노이즈 누적과 정보 오염, 일관성 붕괴를 일으켜 시스템 신뢰성을 낮춘다. 엔터프라이즈 AI 팀이 다루는 거버넌스 원칙은 4가지로 정리된다.

**관련성 우선(Relevance-First)**은 현재 태스크와 직접 관련된 정보를 선별해 넣는 원칙이다. 컨텍스트 윈도우의 용량은 제한되어 있으며, 가능한 정보를 모두 밀어 넣으면 모델의 집중력이 분산되고 성능이 저하될 수 있다.

**신선도 관리(Freshness Management)**는 변화한 상태를 즉시 반영하는 문제다. 이전 도구 호출 결과와 갱신된 환경 정보, 수정된 사용자 지시를 최신 상태로 유지하고 오래된 컨텍스트가 현재 판단에 개입하지 않도록 갱신 메커니즘을 마련해야 한다.

**오염 방지(Contamination Prevention)**는 외부 검색 결과나 도구 출력에 악의적이거나 부정확한 내용이 포함될 가능성을 다룬다. 주입할 정보의 출처를 검증하고 신뢰도 점수를 부여하며, 의심스러운 내용을 격리하는 처리가 여기에 포함된다.

**감사 가능성(Auditability)**은 어떤 시점에 어떤 컨텍스트가 주입됐는지 추적할 수 있게 만드는 원칙이다. 컨텍스트에 의존해 내려진 결정을 분석하려면 이 기록이 필요하며, 오류 분석과 규제 준수, 성능 개선을 위한 기반으로도 쓰인다.

큰 윈도우도 선별과 압축이 필요하다

컨텍스트 윈도우의 물리적 크기는 128K → 200K → 1M+ 토큰으로 증가하는 추세지만, 크기만으로 운영 문제가 사라지지는 않는다. 대용량 컨텍스트는 지연 시간과 비용을 늘린다. 컨텍스트 중반의 정보를 모델이 간과하는 ‘잃어버린 중간(Lost in the Middle)’ 현상도 완전히 해소되지 않았다.

**청크 압축(Chunk Compression)**은 검색된 문서 전체를 넣는 대신 내용을 요약하고 압축해 토큰 사용량을 줄이면서 핵심 정보를 보존한다.

**계층적 요약(Hierarchical Summarization)**은 긴 대화 기록을 실시간으로 요약해 메모리 레이어로 옮기고, 현재 컨텍스트 윈도우에는 최근 상호작용을 중심으로 남긴다.

**선택적 메모리 주입(Selective Memory Injection)**은 현재 태스크와 관련된 기억만 골라 전달한다. 리트리버(retriever) 모델이 메모리 풀을 먼저 필터링한 뒤 필요한 항목을 컨텍스트에 넣는다.

**서브에이전트 위임(Sub-Agent Delegation)**은 한 에이전트가 감당할 컨텍스트가 지나치게 커졌을 때 독립된 서브에이전트에 작업을 맡기고 결과만 반환받는 방식이다. MCP 기반 시스템에서는 이러한 위임이 프로토콜 레벨에서 표준화된다.

Salesforce의 2026년 에이전틱 AI 트렌드 보고서는 컨텍스트 엔지니어링이 에이전틱 시스템의 생산 안정성을 결정하는 핵심 역량으로 자리 잡고 있다고 분석한다. 선도적인 AI 네이티브 조직은 제품 스펙과 아키텍처 문서, API 문서, 데이터베이스 스키마, 코딩 표준, 보안 기준, 배포 프로세스, 과거 인시던트 요약을 체계화한 내부 지식 시스템에 투자하고 있으며, 이를 컨텍스트 엔지니어링 인프라의 중심에 두고 있다.

모델보다 정보 환경을 설계하는 역량

컨텍스트 엔지니어링은 프롬프트 엔지니어링을 없애는 개념이 아니다. 시스템 프롬프트를 포함해 도구 명세와 메모리, 검색 결과, 상태 정보를 하나의 실행 환경으로 조립하는 상위 설계 패러다임이다.

MCP가 런타임 컨텍스트 조립을 위한 표준 인터페이스로 확립되면서 이 작업은 개인의 프롬프트 작성 기술을 넘어 조직이 운영해야 할 인프라 역량이 되고 있다. 2026년 이후 에이전틱 AI의 경쟁력은 어떤 모델을 선택하느냐보다 정밀하고 신뢰할 수 있는 컨텍스트를 어떻게 설계하고 운영하느냐에 의해 결정될 것이다.