프롬프트를 넘어 RAG·MCP 기반 컨텍스트 엔지니어링 설계
RAG·MCP·메모리를 런타임에 조립하고 토큰 예산·압축·RAGAS 평가·거버넌스로 LLM 컨텍스트 품질을 운영하는 설계 기준을 정리한다.
2026-08-14 · 최초 발행 2026-05-24
LLM 품질을 가르는 것은 입력 문자열보다 정보 환경이다
RAG의 공동 창시자 Douwe Kiela는 컨텍스트 엔지니어링이 MCP와 RAG를 포괄하며 프롬프트 엔지니어링을 대체했다고 선언했다. 개발자의 65%가 AI 코드 품질이 떨어지는 원인으로 모델 성능보다 컨텍스트 누락을 지목했다는 점도 이런 변화를 뒷받침한다.
프롬프트 엔지니어링이 지시문의 표현을 다듬는 작업이었다면, 컨텍스트 엔지니어링은 LLM에 전달할 정보의 내용·형식·순서·양을 설계한다. 정적 프롬프트만 관리하는 것이 아니라 런타임 조립, RAG, MCP, 메모리와 도구 결과까지 하나의 입력 환경으로 다룬다.
동일한 모델에 같은 질문을 입력해도 어떤 정보를 어떤 순서로 제공하느냐에 따라 응답 품질은 수십 배까지 달라질 수 있다. 따라서 운영 시스템에서는 프롬프트 문구보다 요청 시점에 적합한 컨텍스트를 선별하고 조립하는 계층이 중요해진다.
요청마다 달라지는 컨텍스트를 조립하는 법
런타임 오케스트레이터는 사용자 요청을 해석한 뒤 필요한 정보원을 선택한다. RAG는 장기 지식을, MCP 도구는 실시간 데이터를, 대화 히스토리는 단기 기억을, 에이전트 작업 공간은 현재 상태를 제공한다. 이 결과를 한꺼번에 넣는 대신 관련성을 평가하고 토큰 예산에 맞춰 우선순위를 조정해야 한다.
정보원별 가중치는 태스크에 따라 달라진다. 코딩 작업에서는 코드베이스를 더 높게 평가하고, 사실 조회에서는 RAG 검색 결과를 우선한다. 현재 상태가 필요한 요청이라면 MCP 도구가 반환한 실시간 데이터의 비중을 높인다.
개별 청크의 우선순위는 쿼리와의 의미 유사도만으로 결정하지 않는다. 정보 신선도, 출처 신뢰도, 이전 사용 이력까지 함께 반영하는 다차원 점수 모델이 필요하다. 시스템 지시문·도구 정의·검색 결과·대화 기록·사용자 입력·출력 공간에는 토큰 슬롯을 미리 할당해 구성 요소끼리 예산을 잠식하지 않도록 한다.
검색 결과를 그대로 넣지 않고 다듬는 과정
관련 문서를 찾았다고 컨텍스트 조립이 끝나는 것은 아니다. 검색 범위를 빠르게 줄인 뒤 정밀하게 재평가하고, 응답에 기여하지 않는 부분을 덜어내야 한다.
밀집 패세지 검색(DPR)은 쿼리와 패세지를 각각 인코딩하는 양방향 인코더(Bi-encoder)를 사용한다. 수백만 개 후보에서 Top-K를 추리는 1단계 검색에 적합하다. 이후 교차 인코더는 후보 청크와 쿼리를 하나의 시퀀스로 연결해 양방향 어텐션을 적용하고 관련도를 다시 계산한다. 이것이 2단계 리랭킹이다.
압축 방식도 목적에 따라 나뉜다. LLMLingua는 작은 언어 모델(Small LM)로 응답에 기여하지 않는 토큰을 청크에서 제거하며, 평균 3~5배 압축비로 동일 품질을 유지한다. 긴 문서는 목적에 맞게 다시 요약해 포함할 수 있다. 이때 계층적 요약 구조를 사용하면 압축된 정보에서 세부 내용으로 내려가는 접근 경로를 보존할 수 있다.
토큰 예산은 양보다 배치가 먼저다
컨텍스트 윈도우가 길어도 모든 위치의 정보가 같은 비중으로 사용되지는 않는다. Lost in the Middle 특성을 고려하면 중요한 정보는 중간에 몰아넣기보다 컨텍스트 앞과 뒤에 배치하는 편이 적합하다.
가용 예산에 따라 지시문의 상세도를 바꾸는 동적 프롬프트 템플릿도 사용할 수 있다. 예산이 충분할 때는 상세 지시문을 선택하고, 제한된 상황에서는 핵심만 남긴 단축 버전을 적용한다. Claude·GPT-4o 등이 지원하는 프롬프트 캐싱을 이용하면 반복되는 시스템 프롬프트·도구 정의·문서 컨텍스트의 처리 비용을 최대 90% 절감할 수 있다.
대화 기록은 모두 누적하기보다 슬라이딩 윈도우로 관리한다. 최근 N턴은 그대로 유지하고 그보다 오래된 내용은 요약해 보관하는 방식이다. 현재 대화의 연속성을 지키면서도 과거 기록이 토큰 예산을 점유하는 문제를 줄일 수 있다.
컨텍스트 품질을 측정하고 다시 조립한다
프로덕션 환경에서는 컨텍스트를 한 번 조립한 뒤 바로 모델에 넘기는 것만으로 부족하다. 관련성·정보 밀도·충실도를 검사하고, 기준에 미달하면 정보원을 바꾸거나 압축 강도를 조절해 다시 구성하는 피드백 루프가 필요하다.
RAGAS는 Context Recall·Context Precision·Faithfulness·Answer Relevancy의 4가지 지표로 컨텍스트와 응답 품질을 정량화한다. 정보 밀도는 컨텍스트에 포함된 고유 정보 단위 수를 토큰 수로 나눠 측정하며, 중복이 많은 청크를 찾아내는 데 쓸 수 있다.
Faithfulness는 응답이 제공된 컨텍스트만을 근거로 생성됐는지 확인하는 지표다. 값이 낮다면 컨텍스트가 불완전하거나 모델이 학습 데이터에 의존해 답을 만드는 할루시네이션 위험 신호로 볼 수 있다.
운영 중에는 사용자의 좋아요·싫어요 평가와 클릭 패턴을 수집해 검색 모델 미세조정과 청크 우선순위 갱신에 반영한다. 이 온라인 피드백이 있어야 컨텍스트 전략을 실제 사용 결과에 맞춰 계속 조정할 수 있다.
중복과 청크 경계를 함께 관리한다
검색 품질은 임베딩 모델뿐 아니라 문서를 어떻게 나누고 중복을 제거했는지에도 좌우된다. 코사인 유사도가 임계값인 0.95 이상인 청크 쌍을 중복으로 판별하고 대표 청크만 보존하면 근사 중복을 줄일 수 있다. 대규모 청크셋에서는 MinHash·LSH 알고리즘으로 이 과정을 효율적으로 처리한다.
문서 하나를 전체 요약·섹션 요약·세부 단락의 3계층으로 인덱싱하면 쿼리 복잡도에 맞는 세부 수준을 선택할 수 있다. 청크 경계는 문서 유형에 따라 달라져야 한다. 코드 파일은 함수나 클래스, 법률 문서는 조항, 학술 논문은 섹션, 웹 페이지는 의미 단위로 자르는 방식이다.
Proposition Chunking은 문서를 원자적 사실 명제(Proposition)로 분해한다. 각 명제가 독립적으로 검증 가능한 단일 사실을 담기 때문에 정밀도가 높은 검색에 활용할 수 있다.
실제로 사용된 컨텍스트를 찾아내는 지표
입력에 포함됐다는 사실과 응답 생성에 기여했다는 사실은 다르다. 컨텍스트 위치별 어텐션 가중치를 히트맵으로 표시하면 모델이 거의 주목하지 않은 구간을 식별할 수 있다.
실효 컨텍스트 길이(Effective Context Length)는 전체 입력 토큰 가운데 응답에 실제로 기여한 토큰의 비율을 나타낸다. 이 값이 낮다면 불필요한 컨텍스트가 과도하게 포함됐다는 뜻이다. 각 청크를 하나씩 제거한 뒤 응답 품질 변화를 비교하는 어블레이션 테스트를 병행하면 필수 청크와 불필요 청크를 구분할 수 있다.
비용도 같은 평가 체계에서 다뤄야 한다. 응답 품질 점수를 컨텍스트 조립 비용인 API 호출 수와 토큰 수로 나눈 효율 지표를 사용하면 서로 다른 조립 전략의 비용 대비 효과를 비교할 수 있다.
정적 프롬프트에서 런타임 정보 환경으로
프롬프트 엔지니어링은 무엇을 어떻게 지시할지에 초점을 맞춘다. 컨텍스트 엔지니어링은 올바른 답을 만드는 데 필요한 정보 환경 전체를 설계한다.
| 구분 | 프롬프트 엔지니어링 | 컨텍스트 엔지니어링 |
|---|---|---|
| 초점 | 지시문 문구 최적화 | 정보 환경 전체 설계 |
| 범위 | 시스템 프롬프트·Few-shot | RAG·MCP·메모리·도구·히스토리 |
| 시점 | 설계 시점 고정 | 런타임 동적 조립 |
| 측정 | 주관적 품질 평가 | 정량적 품질 지표(RAGAS) |
| 전문성 | 언어·지시문 작성 | 시스템·검색·데이터 엔지니어링 |
사전에 작성한 프롬프트는 사용자 요청에 따라 달라지는 맥락을 반영하기 어렵고, 지식 컷오프 이후의 최신 정보를 담을 수 없다. 런타임 조립은 현재 질문, 이전 대화, 작업 상태, 실시간 외부 데이터를 매 요청에 맞춰 새로 구성한다.
이에 따라 프롬프트 엔지니어의 역할도 컨텍스트 설계자로 넓어진다. 지시문 작성뿐 아니라 검색 시스템, 데이터 파이프라인, 토큰 최적화를 다루는 엔지니어링 역량이 필요해진다.
MCP를 연결할 때 거버넌스가 빠질 수 없다
RAG가 정적 지식 베이스를 검색한다면 MCP는 외부 시스템과 실시간으로 상호작용해 현재 상태를 공급한다. 메모리와 에이전트 상태까지 함께 연결하면 컨텍스트 오케스트레이터가 여러 정보원을 하나의 LLM 입력으로 통합할 수 있다.
기업 환경에서는 어떤 정보원을 어떤 사용자·에이전트·용도에 제공할지 정책으로 정의해야 한다. ABAC(속성 기반 접근 제어) 모델을 적용하면 컨텍스트 접근 범위를 세밀하게 제어할 수 있다.
정보 민감도는 공개·내부·기밀·극비로 분류하고, 에이전트의 보안 등급에 따라 포함 가능한 범위를 자동으로 제한한다. 응답의 근거가 된 컨텍스트 청크도 함께 기록해야 한다. 그래야 어떤 정보 때문에 해당 답변이 생성됐는지 사후 감사할 수 있다.
신선도 관리 역시 접근 통제만큼 중요하다. 정보원마다 TTL(Time-to-Live)을 설정하고, 만료된 데이터가 컨텍스트에 들어가지 않도록 자동 갱신하는 캐시 관리 체계를 둔다.
프롬프트 엔지니어링은 하위 구성으로 남는다
컨텍스트 엔지니어링이 확장된다고 해서 지시문 설계가 사라지는 것은 아니다. 시스템 지시문, 사용자 지시문, 도구 결과, 검색 컨텍스트 사이에 명시적인 우선순위를 부여하는 Instruction Hierarchy는 충돌을 처리하는 규칙으로 계속 필요하다.
메타 프롬프팅은 모델이 현재 컨텍스트를 분석하고 적합한 응답 전략을 스스로 선택하도록 유도하는 고수준 지시 방식이다. 단순한 태스크 지시보다 일반화 능력이 높다. Few-shot 예시도 고정된 목록으로 제공하기보다 현재 쿼리와 가장 유사한 예시를 실시간으로 검색해 넣는 동적 선택 방식으로 바뀐다.
다운스트림 안정성을 위해서는 출력 형식도 함께 통제해야 한다. Structured Outputs나 JSON Schema 강제로 결과를 파싱 가능한 형태로 고정하는 기법은 컨텍스트 엔지니어링 파이프라인의 후속 처리를 안정화한다.
프롬프트는 여전히 입력 환경의 일부다. 다만 프로덕션 AI의 품질을 좌우하는 범위가 지시문 문구에서 RAG·MCP·메모리·토큰 예산·품질 측정·거버넌스를 포함하는 시스템 설계로 넓어졌다.
Sources
- https://contextengineering.substack.com/
- https://docs.ragas.io/
- https://arxiv.org/abs/2310.06201 (LLMLingua)
- https://arxiv.org/abs/2312.06648 (Proposition Chunking)
- https://arxiv.org/abs/2307.03172 (Lost in the Middle)