길리랩blog

컨텍스트 엔지니어링으로 설계하는 RAG·MCP·파인튜닝

컨텍스트 엔지니어링의 개념과 JIT 어셈블리, RAG·MCP·파인튜닝의 역할, 토큰 예산과 거버넌스 설계를 다룬다.

2026-08-14 · 최초 발행 2026-05-24

프롬프트만으로는 부족한 이유

AI 시스템의 출력은 모델 파라미터만으로 결정되지 않는다. 추론 시점에 어떤 정보를 선택하고, 어떤 순서와 형태로 공급했는지가 결과에 직접 영향을 준다. RAG 공동 창시자 Douwe Kiela가 주창하고 arXiv 2603.09619에서 정식 정의한 컨텍스트 엔지니어링(Context Engineering)은 이 정보 공급 과정 전체를 하나의 설계 대상으로 본다. 개발자 커뮤니티에서 Awesome-Context-Engineering 저장소가 빠르게 표준 레퍼런스로 자리 잡은 배경도 여기에 있다.

개발자 65%가 AI 코드 품질 저하의 원인을 모델보다 컨텍스트 누락에서 찾았다는 점은 이 변화가 단순한 용어 교체가 아님을 보여 준다.

2022~2023년의 프롬프트 엔지니어링은 정적인 텍스트를 조정해 LLM 출력을 제어하는 데 초점을 맞췄다. 하지만 프롬프트만으로는 학습 컷오프 이후의 이벤트나 데이터를 가져올 수 없다. 수작업으로 구성한 프롬프트에는 관련성이 낮은 정보가 섞여 토큰 예산이 낭비되기 쉽고, 같은 문구를 사용해도 실행 시점의 상태에 따라 결과가 달라져 운영 환경의 재현성도 떨어진다.

arXiv 2603.09619는 프롬프트를 정적 아티팩트로, 컨텍스트를 동적으로 조립되는 정보 공간으로 구분한다. Douwe Kiela의 논문은 컨텍스트 엔지니어링을 다음과 같이 정의한다.

"The discipline of designing, constructing, and optimizing the information space that is provided to a language model at inference time, encompassing retrieval, memory, tool use, and any mechanism that shapes what a model knows and can act upon."

이 범위에는 시스템 프롬프트와 Few-shot 예시뿐 아니라 검색, 메모리, 도구 호출, 파인튜닝까지 포함된다.

⤢✕컨텍스트 엔지니어링정적 컨텍스트동적 컨텍스트파라메트릭 컨텍스트시스템 프롬프트Few-shot 예시페르소나 정의RAG (검색 증강)MCP (도구 호출)인메모리 캐시에이전트 히스토리파인튜닝 (SFT)RLHF / DPOLoRA 어댑터런타임 컨텍스트 어셈블러모델 가중치최종 추론 엔진

RAG는 컨텍스트 공급 체계로 확장됐다

RAG(Retrieval-Augmented Generation)는 컨텍스트 엔지니어링이 가장 성숙하게 구현된 영역 중 하나다. 초기에는 벡터 검색으로 찾은 문서를 프롬프트에 덧붙이는 방식이 중심이었지만, 이후 검색과 평가, 조립 과정이 세분화됐다.

1세대 Naive RAG는 문서를 청크로 나눈 뒤 벡터 유사도 상위 K개를 가져왔다. 2세대 Advanced RAG에는 재순위화, BM25와 벡터를 결합한 하이브리드 검색, 쿼리 재작성이 추가됐다. 3세대 Modular RAG는 검색·평가·생성 모듈을 서로 독립적으로 교체할 수 있도록 구성했다.

컨텍스트 엔지니어링은 여기서 범위를 더 넓힌다. 검색 결과와 함께 MCP 도구 출력, 대화 히스토리, 사용자 메모리를 모아 추론 직전에 JIT(Just-In-Time) 방식으로 컨텍스트를 조립한다. RAG는 전체 정보 공간을 만드는 유일한 수단이 아니라 여러 공급원 중 하나가 된다.

추론 직전에 컨텍스트를 조립한다

동적 컨텍스트 어셈블리는 필요한 정보를 추론 시점에 선별하고, 주어진 예산 안에서 모델이 사용할 형태로 변환하는 작업이다.

⤢✕언어 모델컨텍스트 압축기토큰 예산 관리자관련성 점수화쿼리 분석기사용자 쿼리언어 모델컨텍스트 압축기토큰 예산 관리자관련성 점수화쿼리 분석기사용자 쿼리원본 쿼리 입력의도 분류 + 서브쿼리 분해멀티소스 병렬 검색 요청RAG 청크 점수 계산MCP 도구 결과 점수 계산캐시 히트 점수 계산관련성 순위 목록 전달토큰 예산 할당 (컨텍스트 타입별)예산 초과 청크 압축 요청추출적 요약 또는 청크 병합최적화된 컨텍스트 윈도우 조립최종 응답 생성

먼저 사용자의 질의를 의도별로 분류하고 복잡한 요청을 서브쿼리로 나눈다. 이렇게 분해된 검색 신호는 여러 컨텍스트 소스로 동시에 전달된다.

수집된 청크에는 의미적 유사도, 최신성, 출처 신뢰도, 이전 대화와의 연관성을 반영한 복합 점수를 매긴다. 이 순위는 무엇을 컨텍스트에 남기고 무엇을 압축하거나 제거할지 결정하는 기준이 된다.

토큰 예산 관리자는 시스템 프롬프트, RAG 청크, MCP 결과, 대화 히스토리, 출력 예비 토큰에 각각 공간을 할당한다. 예산을 넘으면 우선순위가 낮은 항목부터 압축하거나 제외한다.

청크를 줄이되 필요한 정보는 남긴다

컨텍스트 압축은 문장을 일정 길이로 잘라내는 작업과 다르다. 쿼리에 필요한 정보 밀도를 높이면서 의미 손실을 통제해야 한다.

추출적 압축(Extractive Compression)은 청크에서 쿼리와 관련된 문장만 선택하므로 원문 표현을 보존할 수 있다. LLMLingua와 Selective Context가 이 방식을 구현한다. 생성적 압축(Abstractive Compression)은 내용을 요약해 더 적은 토큰에 담지만 원문의 표현이 사라질 수 있다.

계층적 인덱싱(Hierarchical Indexing)은 문서를 서로 다른 세분화 수준으로 미리 인덱싱한다. 쿼리가 요구하는 상세도에 맞춰 적절한 크기의 청크를 가져오는 방식이다.

전체 컨텍스트 윈도우 예산을 T_total로 놓으면 각 영역은 다음과 같이 배분할 수 있다.

  • T_system = 시스템 프롬프트 (고정, 보통 5~15%)
  • T_rag = RAG 청크 (동적, 보통 30~50%)
  • T_mcp = MCP 도구 결과 (동적, 보통 10~20%)
  • T_history = 대화 히스토리 (슬라이딩 윈도우, 보통 15~25%)
  • T_output = 출력 예비 (고정, 보통 10~20%)

어느 버킷이 예산을 초과하면 관련성 점수가 낮은 항목부터 제거하거나 압축한다. 대화 히스토리는 오래된 턴부터 압축적 요약으로 대체하는 슬라이딩 압축 전략을 적용한다.

서로 다른 컨텍스트 소스를 한곳에서 융합한다

현대적인 컨텍스트 파이프라인은 단일 저장소에 의존하지 않는다. 조직 문서, 실시간 시스템, 세션 상태와 모델 가중치가 서로 다른 경로로 정보를 공급한다.

⤢✕문서 청크 + 점수실시간 도구 결과세션 캐시 히트파라메트릭 지식사용자 쿼리병렬 어댑터 레이어(1) RAG 파이프라인(2) MCP 도구 호출(3) 인메모리 캐시(4) 파인튜닝 모델신호 융합 엔진최신성 가중 재순위화컨텍스트 어셈블러최종 LLM 추론

RAG 파이프라인은 조직의 지식베이스, 문서 저장소와 코드베이스를 검색한다. 벡터 DB인 Pinecone, Weaviate, pgvector와 Elasticsearch·BM25 같은 키워드 인덱스를 조합한 하이브리드 검색이 표준이다.

MCP(Model Context Protocol)는 Anthropic이 표준화한 프로토콜이다. 데이터베이스, API, 파일 시스템 같은 외부 시스템에서 실시간 정보를 가져올 수 있어 정적 문서 검색을 보완한다.

인메모리 캐시는 세션에서 이미 얻은 쿼리 결과, 계산된 중간 값과 자주 참조하는 정보를 보관한다. Redis 또는 애플리케이션 레벨 캐시로 구현하며 반복 검색 비용을 줄이는 역할을 맡는다.

파인튜닝 모델에는 특정 도메인이나 작업 방식이 가중치 형태로 내재돼 있다. 이는 런타임 컨텍스트로 전달하기 어려운 암묵적 지식(tacit knowledge)을 담당한다.

최신성과 출처 충돌을 함께 다룬다

여러 소스에서 가져온 정보를 하나의 정보 공간으로 합치는 과정이 신호 융합(Signal Fusion)이다. 이때 검색 점수만 비교해서는 시간에 따라 가치가 달라지는 정보를 처리하기 어렵다.

최신성 가중(Recency Weighting)은 정보의 타임스탬프를 기준으로 최근 자료에 더 높은 비중을 준다. 지수 감쇠 함수 score = base_score × exp(-λ × age_in_days)를 적용하면 오래된 정보의 영향이 점차 줄어든다. λ는 도메인의 변화 속도에 맞춰 조정한다. 뉴스나 주가처럼 빠르게 달라지는 영역에서는 크게, 법률 조항이나 과학 원리처럼 안정적인 영역에서는 작게 설정한다.

RAG 문서와 MCP 결과가 서로 다른 내용을 반환할 수도 있다. 교차 소스 일관성 검사(Cross-Source Consistency Check)는 이런 충돌에서 어느 쪽을 우선할지 판단한다. 실시간 MCP 결과가 정적 RAG 문서보다 높은 신뢰도를 받는 경우가 일반적이지만, 실제 우선순위는 도메인과 쿼리 유형에 따라 달라진다.

기업 환경에서는 컨텍스트도 통제 대상이다

컨텍스트가 여러 시스템에서 동적으로 들어오면 접근 권한과 추적 가능성도 파이프라인에 포함해야 한다.

접근 제어 통합(Access Control Integration)은 사용자의 권한에 맞춰 사용할 수 있는 컨텍스트 소스를 제한한다. RAG 인덱스, MCP 도구와 캐시 데이터에 각각 RBAC(Role-Based Access Control)를 적용하면 같은 질의라도 사용자별로 허용된 정보 공간이 달라진다.

컨텍스트 감사 로그(Context Audit Log)는 어떤 정보가 특정 추론에 사용됐는지 기록한다. 규제가 엄격한 금융·의료 영역에서는 답변 생성에 사용된 컨텍스트의 출처를 추적하는 것이 필수 요건이 되고 있다.

컨텍스트 버전 관리(Context Versioning)는 RAG 인덱스, 시스템 프롬프트와 MCP 도구 설정의 변경 이력을 Git처럼 관리한다. 동일한 질의도 컨텍스트 구성이 바뀌면 다른 결과를 낼 수 있으므로, 재현성을 확보하려면 당시의 컨텍스트 스냅샷을 버전화해야 한다.

MCP는 통합 코드를 표준 인터페이스로 바꾼다

Anthropic이 2024년 11월 오픈소스로 공개한 MCP(Model Context Protocol)는 2026년 현재 9,700만 다운로드를 기록하며 컨텍스트 엔지니어링의 표준 통합 레이어로 자리 잡았다.

기존에는 데이터베이스, API, 파일 시스템과 외부 서비스마다 별도의 통합 코드를 작성해야 했다. MCP는 이 연결 방식을 서버-클라이언트 아키텍처로 표준화한다. MCP 서버를 한 번 구현하면 어떤 MCP 클라이언트에서도 같은 인터페이스로 접근할 수 있다. Linux Foundation의 거버넌스 합류에 따라 vendor-neutral한 생태계 발전이 기대된다.

파인튜닝은 런타임 컨텍스트와 역할이 다르다

컨텍스트 엔지니어링에서 파인튜닝은 모든 정보를 모델 내부에 집어넣는 수단이 아니다. 런타임에 전달하기 어려운 특정 역량과 지식을 가중치에 내재화하는 특수 목적 도구로 재배치된다.

응답 형식과 어조 같은 스타일, 특정 도메인의 전문 용어와 추론 패턴, 보안상 프롬프트에 노출하기 어려운 규칙은 파인튜닝에 적합하다. 최신 데이터, 사용자별 맥락과 계속 변하는 정보는 런타임 컨텍스트 파이프라인이 맡는 편이 더 효율적이다.

RAG, MCP와 파인튜닝은 같은 문제를 놓고 경쟁하는 기술이 아니다. 정적 문서, 실시간 데이터와 파라메트릭 지식이라는 서로 다른 정보 유형을 담당한다.

개발 도구도 컨텍스트를 먼저 찾기 시작했다

개발자 65%가 AI 코드 품질 저하를 컨텍스트 누락 탓으로 지목했다는 조사 결과는 코딩 도구 자체가 정보 수집과 선택을 지원해야 한다는 요구로 이어진다.

GitHub Copilot, Cursor, Windsurf는 코드베이스 전체를 인덱싱하고 관련 파일을 자동으로 컨텍스트에 포함하는 기능을 강화하고 있다. 의존성 그래프를 분석해 변경 영향 범위를 컨텍스트로 제공하는 방식도 표준화되고 있다.

Awesome-Context-Engineering 저장소가 GitHub 스타 수 기준으로 빠르게 성장한 현상도 같은 흐름을 보여 준다. 이 저장소는 컨텍스트 윈도우 관리, 청크 전략, 멀티에이전트 컨텍스트 공유와 컨텍스트 압축을 범주화한 실무 레퍼런스 허브로 기능한다.

컨텍스트 엔지니어링이 던지는 질문은 “좋은 프롬프트를 어떻게 쓸 것인가”에 머물지 않는다. 모델이 사용할 정보를 어떤 시점에, 어떤 형태로 제공할지를 시스템 차원에서 설계하는 문제다. 엔터프라이즈 AI가 성숙할수록 컨텍스트 거버넌스, 감사 가능성과 재현 가능성까지 포함한 설계 역량이 AI 엔지니어에게 요구될 것이다.

Sources

컨텍스트 엔지니어링RAGMCP파인튜닝생성형 AI