길리랩blog

MCP로 설계하는 프로덕션 AI 컨텍스트 아키텍처

프로덕션 AI에서 프롬프트, RAG, MCP, 에이전트 메모리와 토큰 예산을 하나의 컨텍스트 아키텍처로 설계하고 운영하는 방법을 다룬다.

2026-08-15 · 최초 발행 2026-08-02

프롬프트 바깥의 정보 환경을 설계해야 한다

2026년 AI 엔지니어링의 초점은 프롬프트 작성에서 추론 시점의 정보 구성으로 이동했다. Anthropic이 정의한 컨텍스트 엔지니어링은 최적의 토큰 정보를 선별하고 조합하며 유지하는 전략의 집합이다. 인스트럭션뿐 아니라 메모리, 도구, 검색 결과와 작업 상태까지 모델이 참조하는 전체 정보 환경이 설계 대상이 된다.

IT·데이터 리더의 82%가 프롬프트 엔지니어링만으로는 프로덕션 AI에 충분하지 않다고 응답했다. 단일 요청에서는 정교한 프롬프트가 효과적이지만, 멀티턴 대화나 에이전트 워크플로우에서는 이전 상태와 외부 데이터, 실시간 도구 결과를 동적으로 결합해야 일관된 품질을 유지할 수 있다.

구분 프롬프트 엔지니어링 컨텍스트 엔지니어링
설계 단위 단일 인스트럭션 텍스트 전체 컨텍스트 윈도우
정보 소스 정적 텍스트 메모리·도구·RAG·상태 동적 통합
적용 범위 단일 쿼리 멀티에이전트·멀티턴 워크플로우
주요 관심사 응답 품질·형식 정보 선별·압축·갱신 전략
프로덕션 확장성 제한적 아키텍처 수준 설계 가능
상태 관리 없음 에이전트 메모리·세션 상태 포함
측정 지표 주관적 품질 평가 컨텍스트 히트율·토큰 효율성

2026년 현재 Claude Sonnet 4.5, GPT-5, Gemini 2.5 Pro 같은 프런티어 모델은 200K~1M 토큰 컨텍스트 윈도우를 지원한다. 그러나 윈도우를 많은 정보로 채우면 “lost in the middle” 현상이 나타나고 추론 비용이 급격히 늘어날 수 있다는 점도 실증 연구에서 확인됐다. 컨텍스트 엔지니어링은 윈도우의 크기보다 그 안에 들어갈 정보의 가치와 배치를 다룬다.

모델이 받는 컨텍스트를 슬롯으로 나눈다

프로덕션 환경의 컨텍스트 윈도우는 7가지 슬롯으로 구분할 수 있다.

  1. System Instructions: 역할, 제약 조건과 출력 형식
  2. Long-term Memory: 사용자 프로파일과 과거 인터랙션 요약
  3. Short-term Memory: 현재 세션에 누적된 대화 기록
  4. Retrieved Knowledge: RAG가 검색한 외부 지식
  5. Tool Outputs: MCP 서버와 API의 호출 결과
  6. Agent State: 작업 진행 상태와 서브에이전트 결과
  7. User Request: 현재 사용자 입력

이렇게 나누면 어떤 정보가 토큰을 차지하는지, 어느 슬롯에서 중복이나 오래된 데이터가 들어오는지 추적할 수 있다. 컨텍스트 최적화는 모든 슬롯을 동일하게 줄이는 작업이 아니라 요청마다 필요한 슬롯을 고르고 우선순위를 조정하는 과정이다.

저장소에서 인터페이스까지 이어지는 계층

컨텍스트를 안정적으로 공급하려면 데이터 저장, 정보 조회, 토큰 배분과 사용자 인터페이스의 책임을 분리해야 한다. 각 계층의 경계를 분명히 하면 요청을 해석하는 오케스트레이터, 정보를 가져오는 공급원, 토큰 예산 안에서 내용을 조립하는 계층, 모델과 피드백 루프를 분리해 운영할 수 있다.

⤢✕Layer 1: Data & StateLayer 2: Context SupplyLayer 3: Context OrchestrationLayer 4: Presentation사용자 인터페이스API 게이트웨이Context ManagerPriority ScorerToken Budget ControllerMCP Server ClusterRAG PipelineMemory StoreTool RegistryVector DB(pgvector/Pinecone)Knowledge Graph (Neo4j)Session State Store (Redis)Document Store (S3)

Layer 1은 원시 데이터와 상태를 보관한다. 벡터 DB는 시맨틱 검색, 지식 그래프는 엔티티 관계, Redis는 세션 상태를 담당한다.

Layer 2에서는 MCP 서버, RAG 파이프라인, 메모리 스토어와 도구 레지스트리가 필요한 컨텍스트를 공급한다. 각 공급원은 독립적으로 동작하고 상위 오케스트레이션 계층이 결과를 모은다. MCP 서버는 외부 API 데이터와 실시간 도구 실행 결과를 제공하고, RAG 파이프라인은 의미론적 유사성을 기준으로 도메인 문서를 검색한다. 에이전트 메모리는 대화 이력과 작업 상태, 사용자 프로파일을 보존하며 지식 그래프는 엔티티 관계를 구조화된 컨텍스트로 전달한다.

Layer 3의 Context Manager는 슬롯별 중요도를 평가한다. Priority Scorer가 우선순위를 정하면 Token Budget Controller가 컨텍스트 윈도우 한도 안에서 토큰을 배분한다. 수집한 정보는 그대로 모델에 넣지 않고 이 지점에서 필터링하거나 압축하며, 마크다운·JSON·텍스트처럼 서로 다른 형식도 정규화한다. 시스템 프롬프트 20%, 메모리 15%, RAG 40%, 도구 결과 20%, 여유 5%로 토큰 예산을 나누는 방식도 이 계층의 정책으로 둘 수 있다.

Layer 4는 이 구조를 사용자나 외부 시스템에 연결하는 인터페이스다. 모델의 출력은 사실성·완결성·관련성 기준으로 평가하고, 품질이 낮은 공급원의 가중치를 조정한다. 성공한 컨텍스트 구성은 메모리와 검색 계층 및 캐시에 반영한다.

MCP가 필요한 정보만 요청 시점에 연결한다

MCP(Model Context Protocol)는 2024년 Anthropic이 표준화한 뒤 2026년 현재 10,000개 이상의 서버 에코시스템을 형성했고, 컨텍스트 공급을 위한 사실상의 표준이 됐다. MCP 기반 시스템은 요청을 먼저 분석한 뒤 도메인 지식, 실시간 데이터, 사용자 이력 가운데 필요한 공급원만 호출한다.

2026년 MCP 생태계에는 Linux Foundation이 관리하는 공개 MCP 서버가 10,000개 이상 존재한다. 서버 범위는 PostgreSQL·MongoDB·Redis 같은 데이터베이스 커넥터, Brave·Bing·Playwright 기반 검색과 브라우징, Python REPL·Node.js sandbox 코드 실행 환경, Salesforce·Jira·GitHub·Slack 기업 시스템 통합, 의료·금융·법률 데이터 서버까지 이어진다. 인증은 OAuth 2.0과 OIDC를 기반으로 하며 2026 Q1에 표준화됐다. MCP v2 사양의 Stateless 코어는 서버 상태 관리를 클라이언트로 이전해 확장성을 크게 높였다.

⤢✕단순 쿼리도메인 지식 필요실시간 데이터 필요사용자 히스토리 필요YesNo사용자 요청 수신컨텍스트필요도 분석Static Context(시스템 프롬프트만)RAG MCP Server호출External APIMCP Server 호출Memory MCP Server호출Context MergerToken BudgetOptimizer토큰 예산초과?우선순위 기반청크 제거LLM 추론응답 생성Memory MCP결과 저장다음 턴 준비

이 구조의 핵심은 동적 바인딩이다. 요청이 들어온 시점에 사용할 컨텍스트 소스를 결정하므로, 정적 RAG 파이프라인보다 불필요한 토큰 소비를 40~60% 줄일 수 있다. Anthropic 내부 사례에서는 데이터 분석 에이전트의 컨텍스트 히트율이 MCP 도입 후 67%에서 91%로 향상됐다고 보고됐다.

운영 환경에서는 MCP 게이트웨이를 단일 진입점으로 두고 서버 접근, 인증과 로드밸런싱을 통합한다. 서로 의존하지 않는 서버 요청은 비동기로 병렬 처리하고, 특정 서버에 장애가 발생하면 서킷 브레이커가 대체 컨텍스트 공급원으로 전환하도록 구성한다. Redis 기반 응답 캐시를 적용하면 레이턴시를 50~80% 줄일 수 있으며, 반복적으로 사용되는 컨텍스트는 주기적인 배치 작업에서 미리 조립해 캐시에 둘 수 있다.

기존 프롬프트 시스템을 단계적으로 전환한다

첫 단계는 진단과 기반 구축이다. 1~2개월 동안 기존 프롬프트 워크플로우를 감사하고, 컨텍스트 슬롯마다 정보가 어디에서 들어와 어디로 전달되는지 매핑한다. 이때 확인할 질문은 “현재 시스템의 컨텍스트 윈도우에는 무엇이 들어가 있는가?”다.

  • 컨텍스트 슬롯 감사 도구 구축
  • 평균 토큰 소비와 슬롯별 비율을 포함한 토큰 사용 패턴 분석
  • 중복되거나 불필요한 컨텍스트 식별

반복해서 삽입되는 정보는 캐시 후보로 분류하고, 이후의 변화를 비교할 수 있도록 컨텍스트 품질 베이스라인을 정한다. RAG를 통합할 때는 도메인 문서를 임베딩해 벡터 DB를 만들고 MRR·NDCG로 검색 품질을 측정하며, Small-to-Big, RAPTOR 같은 청크 전략을 점진적으로 조정한다.

다음 2~4개월에는 핵심 컨텍스트 소스를 MCP 서버로 감싸고 Context Orchestrator를 구현한다.

  • RAG 파이프라인을 MCP 서버로 추상화
  • Redis와 벡터 DB를 이용한 장기·단기 메모리 스토어 구축
  • 우선순위 스코어링 알고리즘을 적용한 Token Budget Controller 구현

MCP를 도입할 때는 우선순위가 높은 외부 시스템의 서버부터 연결하고, 게이트웨이를 단일 진입점으로 만들며 레이턴시 목표와 캐싱 정책을 함께 수립한다. 메모리 계층은 사용자·세션·태스크 수준으로 나누고, 메모리의 프라이버시와 보안 및 삭제권 정책도 설계 범위에 포함한다. 지식 그래프 통합에는 도메인 엔티티와 관계를 표현하는 온톨로지가 필요하며, GraphRAG·MSFT GraphRAG 등을 적용해 지식 그래프를 통한 다중 홉 추론 컨텍스트를 공급한다.

이후에는 컨텍스트 품질을 측정하고 피드백을 반영하는 최적화 작업을 상시 운영한다.

측정 지표 정의 목표값
Context Hit Rate 실제 응답에 기여한 컨텍스트 청크 비율 > 85%
Token Efficiency 유효 토큰 / 총 컨텍스트 토큰 > 70%
Memory Recall Accuracy 메모리 조회 시 관련 정보 정확도 > 90%
Latency Overhead 컨텍스트 수집 추가 지연시간 < 200ms
Context Freshness 최신 정보 반영 비율 > 95%

대화 기록을 구조화된 기억으로 바꾼다

에이전트 메모리를 대화 히스토리의 단순 누적으로만 관리하면 관계 정보와 장기 상태를 활용하기 어렵다. Neo4j나 Amazon Neptune 같은 지식 그래프를 컨텍스트 레이어에 연결하면 엔티티 사이의 관계를 요청에 맞춰 동적으로 공급할 수 있다.

지식 그래프는 RAG와 에이전트 메모리를 대체하는 저장소가 아니라 두 계층이 놓치기 쉬운 관계와 상태를 보완한다. RAG는 외부 지식을 검색하지만 작업의 연속성까지 책임지지는 않고, 에이전트 메모리는 현재 대화와 과거 작업을 보존하지만 필요한 도메인 문서를 대신 찾지는 않는다. 지식 그래프의 엔티티·관계 조회, 벡터 검색의 의미적 관련성, 에이전트 메모리의 사용자·작업 이력을 같은 토큰 예산 안에서 조립해야 검색된 사실과 작업 맥락을 함께 전달할 수 있다.

# 지식 그래프 기반 컨텍스트 공급 예시
class KnowledgeGraphContextProvider:
    def __init__(self, graph_db, vector_store):
        self.graph = graph_db
        self.vector = vector_store

    def get_context(self, query: str, entity_ids: list, token_budget: int) -> str:
        # 1. 관련 엔티티 및 관계 조회
        subgraph = self.graph.get_subgraph(entity_ids, depth=2)

        # 2. 시맨틱 유사도 기반 관련 청크 검색
        similar_chunks = self.vector.search(query, top_k=10)

        # 3. 토큰 예산 내에서 우선순위 결합
        context = self._merge_with_budget(subgraph, similar_chunks, token_budget)
        return context

    def _merge_with_budget(self, graph_ctx, vector_ctx, budget):
        scored = []
        for chunk in graph_ctx + vector_ctx:
            score = chunk.relevance_score * chunk.recency_weight
            scored.append((score, chunk))

        scored.sort(reverse=True)
        result, used = [], 0
        for score, chunk in scored:
            if used + chunk.token_count <= budget:
                result.append(chunk.text)
                used += chunk.token_count
        return "\n\n".join(result)

이 예시는 지식 그래프에서 depth=2 범위의 서브그래프를 가져오고, 벡터 저장소에서는 top_k=10으로 유사 청크를 검색한다. 이후 관련도와 최신성 가중치를 조합해 점수를 매기고, 토큰 예산 안에 들어오는 청크만 결과에 포함한다.

검색 계층에서는 벡터 유사성을 사용하는 Dense retrieval과 BM25 키워드 기반 Sparse retrieval을 결합할 수 있다. 두 결과는 RRF(Reciprocal Rank Fusion)로 통합하고, HyDE(Hypothetical Document Embeddings)를 이용한 쿼리 확장도 적용한다. 청크는 고정 길이만으로 자르기보다 헤더·섹션·단락 경계를 인식해 분할하며, 요약 레이어와 상세 레이어를 둔 계층적 인덱싱과 슬라이딩 윈도우 오버랩으로 경계에서 정보가 손실되는 문제를 줄인다. 검색 결과가 토큰 예산을 넘으면 LLMLingua·RECOMP로 4~6배 압축하거나 질문과 관련된 핵심 문장을 추출하고, 그래도 예산을 넘는 경우 중요도가 낮은 컨텍스트부터 점진적으로 제거한다.

메모리는 보존 대상과 수명에 따라 단기·장기·에피소딕·절차 메모리로 구분한다. 단기 메모리는 현재 대화 턴, 직전 도구 실행 결과와 임시 계산값을 담고 컨텍스트 창 전체의 15~20%를 고정 영역으로 배정해 슬라이딩 윈도우로 최신 N턴을 유지한다. 장기 메모리는 사용자 프로파일, 선호도와 작업 패턴을 영구 저장하며 벡터 임베딩으로 관련 기억을 찾는다. 에피소딕 메모리는 과거 작업의 성공과 실패를 구조화해 저장하고, 비슷한 상황이 감지되면 관련 에피소드를 주입하며 반성(Reflection) 메커니즘으로 기억의 품질을 평가하고 정제한다. 절차 메모리는 반복되는 작업 순서와 도구 조합을 스킬로 관리해 새 작업에 맞는 스킬을 자동으로 불러오고 성공 패턴을 학습해 라이브러리를 확장한다.

프롬프트와 RAG는 사라지지 않는다

프롬프트 엔지니어링, RAG와 컨텍스트 엔지니어링은 대체 관계로만 볼 수 없다. 각 접근법이 다루는 범위가 다르다.

항목 프롬프트 엔지니어링 RAG 아키텍처 컨텍스트 엔지니어링
핵심 목표 모델 응답 품질 향상 외부 지식 주입 전체 정보 환경 최적화
동적 정보 통합 불가 부분적 (검색 결과) 완전 (멀티소스 동적 통합)
상태 관리 없음 없음 에이전트 메모리·세션 상태
멀티에이전트 지원 불가 제한적 설계 핵심
토큰 최적화 수동 청크 크기 조절 자동화된 예산 제어
구현 복잡도 낮음 중간 높음
프로덕션 확장성 낮음 중간 높음
비용 효율성 중간 중간 최적화 시 최고
적합한 사용 사례 단순 작업·PoC 지식 검색 Q&A 복잡한 에이전트 시스템

실제 프로덕션 환경에서 조직은 대체로 프롬프트 엔지니어링에서 RAG를 거쳐 컨텍스트 엔지니어링으로 성숙도를 높인다. 이 진화 경로는 선형적이며, 앞 단계의 운영 경험이 다음 아키텍처를 설계하는 기반이 된다.

컨텍스트 엔지니어링은 프롬프트 엔지니어링과 RAG를 폐기하지 않는다. 최적화된 시스템 프롬프트와 벡터 검색 파이프라인을 하위 구성 요소로 포함하면서, 메모리·도구·상태와 토큰 예산까지 관리 범위를 넓힌 상위 아키텍처다. 여러 내부 문서와 시스템을 조회하는 엔터프라이즈 AI 어시스턴트, 에이전트끼리 상태와 컨텍스트를 공유해야 하는 멀티에이전트 환경, 수주~수개월의 맥락을 유지해야 하는 프로젝트, 주가·기상·재고 등 실시간 정보를 사용하는 서비스, 사용자별 선호와 이력을 반영하는 개인화 AI에서 이 경계가 특히 중요해진다.

컨텍스트 설계가 맞닿는 정보공학 영역

컨텍스트 엔지니어링의 레이어드 아키텍처는 계층형 시스템 설계 원칙과 연결된다. Context Precision·Recall·Faithfulness 같은 지표는 데이터 품질 관리 프레임워크로 다룰 수 있고, MCP는 AI 시스템 통합을 위한 표준 인터페이스에 해당한다. 토큰 예산과 캐싱 및 병렬 처리는 성능 최적화 문제이며, OAuth·OIDC 인증과 메모리 프라이버시는 보안 아키텍처의 대상이다. 프롬프트 중심 구조에서 컨텍스트 중심 구조로 옮기는 과정은 IT 시스템 전환과 마이그레이션 방법론으로 해석할 수 있다.

이 연결을 분리해 보면 RAG와 에이전트 메모리는 AI 시스템의 외부 기억 장치 아키텍처로 다룰 수 있고, MCP는 AI 시스템 통합 표준 인터페이스로서 ISO/IEC 표준 체계와 연결할 수 있다. RAGAS를 포함한 품질 지표 체계는 AI 시스템 품질 보증 프레임워크와 연계할 수 있다.

운영 기준은 관련성과 신선도에서 출발한다

컨텍스트를 선별할 때는 4가지 원칙을 적용할 수 있다.

  1. 관련성(Relevance): 현재 작업과 직접 연결된 정보만 선택한다.
  2. 신선도(Freshness): 최신 상태를 반영한 정보를 우선한다.
  3. 압축성(Compressibility): 중복 제거와 요약으로 토큰을 효율화한다.
  4. 일관성(Coherence): 컨텍스트 안에서 정보가 서로 모순되지 않게 한다.

모델 응답만 평가하면 어떤 컨텍스트 공급원이 문제를 일으켰는지 찾기 어렵다. 검색 결과가 실제 답변에 쓰였는지, 필요한 정보가 빠지지 않았는지, 모델이 제공된 근거를 충실하게 따랐는지를 분리해 측정해야 한다.

지표 설명 목표값
Context Precision 공급된 컨텍스트 중 실제 사용된 비율 ≥ 70%
Context Recall 정답 생성에 필요한 정보가 컨텍스트에 포함된 비율 ≥ 85%
Context Relevance 컨텍스트의 쿼리 관련성 점수 ≥ 0.75
Faithfulness 모델 응답이 컨텍스트에 충실한 비율 ≥ 90%
Token Efficiency 토큰 당 정보 밀도 (유용 토큰/전체 토큰) ≥ 0.65
Latency P95 컨텍스트 조립 완료까지 95번째 백분위 지연 ≤ 800ms

RAGAS는 Context Precision·Recall·Faithfulness를 자동으로 측정하는 평가 프레임워크로 사용할 수 있다. 별도 평가 모델을 둔 LLM-as-Judge로 품질을 지속적으로 감시하고, 컨텍스트 전략을 바꿀 때는 A/B 테스팅으로 지표 차이를 비교한다. 시간 경과에 따른 컨텍스트 드리프트를 감지해 알림을 보내며, 사용자의 엄지 업·다운과 명시적인 수정 요청도 품질 신호로 반영한다.

멀티에이전트 환경에서는 에이전트별 컨텍스트 격리(Context Isolation)로 보안과 정확성을 지키고, 컨텍스트 전파(Context Propagation)를 통해 서브에이전트에 필요한 정보만 전달해야 한다. 병렬로 실행된 에이전트의 결과는 컨텍스트 수렴(Context Convergence) 전략에 따라 하나의 정보 환경으로 통합한다.

2026년의 주요 흐름은 이 선별과 우선순위 결정의 자동화다. 수동으로 작성하던 로직이 강화학습 기반 자동 최적화 시스템으로 대체되고 있으며, Meta의 MemGPT 후속 연구, Anthropic의 컨텍스트 캐싱 고도화와 OpenAI의 Responses API 확장이 같은 방향을 가리킨다.

LLM이 자신의 컨텍스트를 자동으로 압축·요약하는 Self-Compression 기법의 상용화, 텍스트·이미지·오디오·비디오를 함께 관리하는 멀티모달 컨텍스트, 조직 사이에서 프라이버시를 보존하며 정보를 공유하는 Federated Context, 검증된 도메인 컨텍스트 패키지를 거래하는 B2B 마켓플레이스도 등장할 전망이다. 강화학습으로 컨텍스트 전략을 스스로 개선하는 자율 최적화 시스템 역시 발전 방향으로 제시된다.

이 변화에 따라 컨텍스트 아키텍트는 기업 AI 시스템의 컨텍스트 구조를 설계하고, MCP 서버 개발자는 도메인별 서버 구축과 운영을 담당하며, AI 메모리 엔지니어는 에이전트 메모리 시스템의 설계와 구현을 맡는다. 컨텍스트 엔지니어링 관련 채용공고는 전년 대비 340% 증가했다. 프롬프트 엔지니어의 역할은 컨텍스트 엔지니어링으로 흡수되며 전환이 빨라질 전망이다.

MCP는 2026년 Linux Foundation 산하의 중립 표준으로 이관돼 벤더 중립성을 확보했다. 엔터프라이즈 채택도 빨라져 Fortune 500 기업의 68%가 MCP 서버를 프로덕션 컨텍스트 공급 인프라로 채택했다.

프로덕션 AI에서 프롬프트는 여전히 필요하지만 충분조건은 아니다. IT·데이터 리더 82%의 인식 변화가 보여주듯, 확장 가능한 서비스에는 MCP 기반 동적 공급 파이프라인, 에이전트 메모리와 지식 그래프, 토큰 예산 자동 최적화를 함께 다루는 컨텍스트 아키텍처가 필요하다. MCP 에코시스템의 표준화와 강화학습 기반 컨텍스트 자동 최적화가 2026년 이후의 방향을 결정할 것이다.

Sources

컨텍스트 엔지니어링MCPRAGAI 에이전트지식 그래프