컨텍스트 엔지니어링이 바꾸는 AI 시스템 설계

한 줄짜리 지시문 밖에서 품질이 결정된다

2025년 말 Andrej Karpathy가 제시한 컨텍스트 엔지니어링(Context Engineering)은 2026년 들어 AI 시스템 설계의 표준 담론으로 자리 잡고 있다. 모델에 전달할 문장을 다듬는 데 머물지 않고, RAG·메모리·툴 컨텍스트를 포함한 정보 생태계 전체를 설계 대상으로 삼는 접근이다. IT·데이터 리더 82%가 프롬프트 엔지니어링만으로 AI를 대규모 운영하기에는 부족하다고 인식한다는 조사 결과도 이러한 전환이 운영상의 요구와 맞닿아 있음을 보여준다.

Karpathy가 문제 삼은 지점은 용어의 범위였다. 실제 LLM 애플리케이션의 품질은 사용자가 적은 한 줄의 지시문보다 호출 시점의 컨텍스트 윈도우에 어떤 정보가 어떤 형식과 분량으로 들어가는지에 더 크게 좌우된다. 이 정보 구성을 의도적으로 설계하는 작업이 컨텍스트 엔지니어링이다.

기술의 무게중심도 이동했다. 2024년에는 프롬프트 작성이 핵심 역량으로 다뤄졌고, 2025년에는 RAG가 외부 지식에 접근하는 수단으로 부상했다. 이후 에이전트 워크플로우가 보편화하면서 문제가 달라졌다. 수십 차례의 모델 호출이 이어지는 멀티턴·멀티에이전트 환경에서는 컨텍스트를 어떻게 구성하고 압축하며, 어디까지 공유하거나 격리할지가 시스템 품질의 병목이 된다.

관리 대상은 크게 다음 정보 소스로 나뉜다.

지시 컨텍스트(Instructional): 시스템 프롬프트, 역할 정의, 출력 형식 규약
지식 컨텍스트(Knowledge): RAG 검색 결과, 문서 청크, 구조화 데이터
메모리 컨텍스트(Memory): 세션 히스토리, 장기 사용자 프로파일, 요약된 과거 상호작용
툴 컨텍스트(Tool): MCP를 통한 도구 정의, 함수 시그니처, 도구 실행 결과

이 정보들은 서로 독립된 부속물이 아니다. 하나의 토큰 예산 안에서 요청에 맞게 선택되고 결합되어야 한다.

⤢✕

호출 직전에 정보를 조립하는 JIT 방식

JIT(Just-In-Time) 컨텍스트 조합은 컨텍스트 엔지니어링을 구현하는 핵심 패턴이다. 소프트웨어의 JIT 컴파일 개념처럼 정보를 미리 고정하지 않고, 모델을 호출하기 직전에 해당 요청에 맞춰 동적으로 조립한다. 정적 시스템 프롬프트가 커지면서 생기는 확장성 문제와 불필요한 토큰 소비를 줄이기 위한 구조다.

조립 과정은 세 단계로 진행된다. 먼저 요청을 분석해 사실적·절차적·맥락적 정보 가운데 무엇이 필요한지 분류한다. 이어서 각 유형을 적절한 소스에 연결해 병렬로 가져온다. 사실 지식은 벡터 DB와 RDB, 절차 지식은 코드베이스와 문서, 맥락 지식은 메모리 스토어가 담당한다. 마지막으로 확보한 후보를 우선순위에 따라 선별하고 압축해 토큰 예산 안에 배치한다.

여기서 RAG와 MCP(Model Context Protocol)는 서로 다른 질문을 처리한다. RAG가 모델이 무엇을 알아야 하는지에 해당하는 정적 지식을 공급한다면, MCP는 모델이 무엇을 할 수 있는지를 나타내는 동적 도구 컨텍스트를 표준화된 인터페이스로 제공한다. 요청 라우터는 검색 경로와 도구 실행 경로 가운데 무엇이 필요한지 판단하고, 두 경로의 결과를 최종 컨텍스트로 합친다.

⤢✕

멀티에이전트 시스템에서는 정보를 공유하는 범위가 특히 민감하다. 모든 에이전트에 전체 컨텍스트를 전달하면 토큰이 급증하고, 현재 작업과 관계없는 정보가 추론을 오염시킬 수 있다. 반대로 완전한 격리는 에이전트 간 협업을 끊는다.

실무에서는 공유 메모리 버스(shared memory bus)에 핵심 사실과 목표만 두고, 개별 작업에 필요한 컨텍스트는 서브에이전트별로 격리하는 절충 구조를 사용할 수 있다. 협업에 필요한 정보는 남기면서 컨텍스트 오염(context poisoning)을 줄이는 방식이다.

토큰 예산이 설계를 제한한다

컨텍스트 윈도우가 커져도 모든 정보가 같은 비중으로 활용되는 것은 아니다. 윈도우의 중간에 놓인 정보를 놓치는 Lost in the Middle 현상이 나타날 수 있고, 처리 비용도 늘어난다. 어떤 정보를 넣을지뿐 아니라 무엇을 줄이고 외부로 내보낼지를 결정하는 토큰 예산 관리가 필요한 이유다.

기법	목적	핵심 동작	주요 리스크
JIT 조합	동적 컨텍스트 구성	호출 직전 요청별 조립	조립 지연(latency)
예산 절삭(Pruning)	토큰 한도 준수	우선순위 낮은 청크 제거	핵심 정보 손실
압축/요약(Compaction)	메모리 밀도 향상	과거 턴을 요약으로 치환	요약 왜곡
격리(Isolation)	컨텍스트 오염 방지	서브에이전트 분할	협업 단절
오프로딩(Offloading)	윈도우 외부 저장	외부 메모리에 상태 보관	검색 정합성
캐싱(Caching)	비용/지연 절감	정적 접두부 재사용	캐시 무효화

출력 정확도만으로는 이 구조의 문제를 충분히 찾기 어렵다. 컨텍스트 자체를 평가하려면 제공된 정보 가운데 실제 사용된 비율인 컨텍스트 정밀도(Context Precision), 필요한 정보가 빠짐없이 포함됐는지를 보는 컨텍스트 재현율(Context Recall), 유용한 정보의 밀도를 나타내는 토큰 효율, 출력이 제공된 컨텍스트에 근거하는 정도인 컨텍스트 충실도(Faithfulness)를 함께 다뤄야 한다. 이러한 지표는 RAGAS류 평가 프레임워크와 결합해 회귀 테스트의 일부로 자동화할 수 있다.

프롬프트 자산을 시스템으로 전환하기

기존 프롬프트 엔지니어의 중심 역량이 자연어 지시문 최적화였다면, 컨텍스트 엔지니어에게는 정보 검색 시스템 설계, 토큰 경제학, 평가 파이프라인 구축 역량까지 요구된다. 역할의 성격도 데이터 엔지니어링과 분산 시스템 설계에 가까워진다.

긴 작업을 하나의 컨텍스트에 계속 쌓는 방식도 바뀌어야 한다. 작업을 서브태스크로 나누고 각 단계에는 필요한 최소 컨텍스트만 제공한다. 단계 사이에는 전체 대화 기록 대신 구조화된 요약(structured handoff)을 전달하면 토큰 소비와 오류 전파를 억제할 수 있다.

조직 차원의 전환은 현재 보유한 프롬프트 자산을 확인하는 데서 시작해 컨텍스트 소스 표준화, RAG-MCP 파이프라인 구축, 평가 체계 도입, 직무 정의로 이어질 수 있다. 성숙도 평가에서 기준에 미달하면 소스 표준화 단계로 돌아가 구조를 다시 점검한다.

⤢✕

고객 지원 에이전트를 보면 차이가 선명하다. 정적 프롬프트 기반 챗봇은 모든 고객에게 같은 거대 시스템 프롬프트를 적용한다. 컨텍스트 엔지니어링을 적용한 시스템은 요청 시점에 고객의 계정 상태를 메모리에서 가져오고, 관련 정책 문서를 RAG로 검색하며, 환불 처리 도구를 MCP로 연결한다. 필요한 정보와 기능만 조합하므로 토큰 사용량은 줄고 응답 정확도는 향상된다.

정적 문장 최적화와 동적 시스템 설계의 차이

프롬프트 엔지니어링은 빠르게 시작할 수 있으며 단순한 태스크에 효율적이다. 그러나 도메인 지식이 늘어나고 멀티턴 상호작용이 길어지면 정적으로 작성한 텍스트만으로는 확장하기 어렵다. 컨텍스트 엔지니어링은 초기 인프라 구축과 역량 재교육이 필요하지만, 운영 규모가 커질수록 품질과 비용 효율에서 우위를 갖는다.

비교 축	프롬프트 엔지니어링	컨텍스트 엔지니어링
대상 단위	단일 입력 문장	정보 생태계 전체
시점	작성 시점 고정(정적)	호출 시점 조립(동적)
정보 소스	수작업 텍스트	RAG·메모리·툴 통합
확장성	도메인 증가 시 한계	자동화로 엔터프라이즈 확장
평가 방식	출력 품질 위주	컨텍스트 품질 지표 포함
필요 역량	자연어 최적화	시스템·데이터 엔지니어링

동일 모델과 동일 태스크에서도 무관한 정보를 줄이고 핵심 정보의 밀도를 높이면 환각 감소와 정확도 향상이 일관되게 관찰된다. 품질 개선을 모델 교체에만 의존할 수 없는 이유다. 모델에 어떤 컨텍스트를 제공했는지가 결과를 함께 결정한다.

기존 아키텍처 원칙으로 읽기

JIT 조합, RAG-MCP 파이프라인, 멀티에이전트 격리는 완전히 낯선 구조가 아니다. 소프트웨어 아키텍처 관점에서는 파이프-필터, 브로커, 메시지 버스의 응용으로 볼 수 있다. 요청 라우터와 컨텍스트 머저는 여러 정보 소스와 모델 호출 사이를 연결하는 미들웨어 계층에 해당한다.

컨텍스트 정밀도·재현율·충실도는 데이터 거버넌스의 정합성과 완전성 원칙에도 닿아 있다. AI 시스템의 컨텍스트 관리는 데이터 라이프사이클과 메타데이터 관리 체계를 모델 호출 영역까지 확장한 문제로 해석할 수 있다.

RAG·MCP·메모리 스토어를 단일 예산 안에서 통합하는 구조는 이기종 시스템 통합과 EAI/ESB 통합 아키텍처와도 동형성을 가진다. 조직의 재교육 과정 역시 정보화 전략 계획(ISP), 변화관리, IT 인적자원 관리와 연결된다. 컨텍스트 엔지니어링은 프롬프트 기법의 유행이라기보다 기존 아키텍처·거버넌스·통합 원칙이 생성형 AI 시스템으로 확장된 사례에 가깝다.

프롬프트는 더 큰 설계 안에 남는다

프롬프트 엔지니어링이 사라지는 것은 아니다. 시스템 프롬프트와 역할 정의, 출력 규약은 여전히 지시 컨텍스트를 구성한다. 다만 프롬프트는 전체 시스템을 대표하는 기술이 아니라 컨텍스트 엔지니어링 안의 한 요소가 된다.

2026년 AI 운영에서는 JIT 동적 조합, 토큰 예산 관리, RAG-MCP 하이브리드 조달, 멀티에이전트 컨텍스트 격리를 함께 설계해야 한다. 조직은 정적 프롬프트 자산을 동적 컨텍스트 시스템으로 옮기고, 컨텍스트 품질을 측정 가능한 지표로 관리하며, 인력 역량을 시스템 공학 방향으로 확장해야 한다. 더 좋은 모델을 기다리는 것과 별개로, 현재 모델에 더 나은 컨텍스트를 공급하는 구조를 만드는 일이 남는다.