컨텍스트 엔지니어링으로 설계하는 에이전틱 AI 아키텍처

에이전트의 실패는 상태에서 시작된다

프롬프트가 명확해도 에이전트는 이전 단계의 결과를 잊거나, 잘못된 도구를 고르거나, 서브태스크 사이에서 서로 다른 상태를 참조할 수 있다. 챗봇의 오류가 주로 명령 해석 문제였다면, 에이전트에서는 **상태 관리 실패(state management failure)**가 더 직접적인 원인이 된다.

프롬프트 엔지니어링(Prompt Engineering)은 LLM에 전달할 텍스트 명령을 다듬는 기술이다. "더 창의적으로 답하라", "단계별로 설명하라"처럼 모델과 어떻게 소통할지(how to communicate)를 최적화한다. 컨텍스트 엔지니어링(Context Engineering)은 범위가 다르다. 모델이 각 추론 호출(inference call)에서 무엇에 접근할 수 있는지(what the model has access to)를 아키텍처로 결정한다.

설계 대상에는 시스템 프롬프트와 사용자 입력만 들어가지 않는다. 검색된 문서, 대화 이력, 도구 정의, 작업 상태, 장기 메모리까지 모두 포함된다. 한 번의 입력을 잘 만드는 문제가 아니라 에이전트의 수명주기 전체에 걸쳐 정보 환경을 유지하는 문제다.

2026 State of Context Management Report에서는 IT 및 데이터 리더의 82%가 "프롬프트 엔지니어링만으로는 AI를 기업 수준으로 확장하기 충분하지 않다"고 답했다. 데이터 팀의 95%는 올해 컨텍스트 엔지니어링 교육에 투자할 계획이라고 밝혔다.

⤢✕

기억의 수명에 따라 저장소를 나눈다

에이전트 메모리는 보존 기간과 쓰임새에 따라 작업 메모리, 에피소딕 메모리, 장기 메모리로 구분할 수 있다.

**작업 메모리(Working Memory)**는 현재 태스크나 워크플로우에서 필요한 중간 결과를 보관한다. 멀티스텝 작업의 진행 상태와 서브태스크 결과를 다음 단계로 넘기며, 컨텍스트 윈도우 안에서 주로 구조화된 JSON 형태로 관리한다.

**에피소딕 메모리(Episodic Memory)**에는 대화 세션의 흐름이 남는다. 사용자가 확인한 내용, 실행한 액션과 그 결과를 기록하고, 세션이 끝난 뒤에도 요약본을 유지해 후속 세션에서 참조할 수 있게 한다.

**장기 메모리(Long-Term Memory)**는 세션 경계를 넘어 보존할 지식을 담당한다. 벡터 데이터베이스(Vector DB), 지식 그래프(Knowledge Graph), 구조화된 로그를 이용해 축적된 기관 지식(institutional knowledge)을 다시 불러온다. 2026년 초 기준 13개 이상의 에이전트 프레임워크가 그래프 메모리(Graph Memory) 통합을 지원한다. 시간 인식 엣지(time-aware edge)를 포함한 **시제적 지식 그래프(Temporal Knowledge Graph)**도 프로덕션에 도입되고 있다.

⤢✕

이 계층을 하나의 저장소로 합치면 현재 작업에 필요한 세부 상태와 장기간 보존할 지식이 뒤섞인다. 컨텍스트 어셈블러는 요청마다 각 계층을 조회하되, 모든 결과를 그대로 모델에 넣지 않고 현재 추론에 필요한 부분만 골라야 한다.

도구 목록을 런타임에 구성하는 MCP

도구(Tools) 통합에서는 MCP(Model Context Protocol)가 표준으로 수렴했다. Anthropic이 개발하고 OpenAI, Google, Microsoft, Amazon이 채택했으며, 2026년 3월 기준 Python과 TypeScript SDK의 월간 다운로드 합계는 9700만을 기록했다. 공개 MCP 서버도 1만 개를 넘어섰다.

MCP가 제공하는 핵심 기능은 **런타임 도구 탐색(runtime tool discovery)**이다. 사용할 도구를 애플리케이션 코드에 모두 하드코딩하는 대신, 에이전트가 연결된 MCP 서버를 탐색해 필요한 도구를 동적으로 고른다. 이 구조에서 사용 가능한 도구 레이어는 현재 연결된 MCP 서버가 제공하는 도구의 합집합이며, 프로토콜이 탐색과 스키마 전달, 호출을 처리한다.

역할 경계도 분명해진다. MCP 서버는 검색 기능이나 외부 시스템 접근을 리소스 또는 도구로 노출한다. 클라이언트는 필요한 시점에 이를 요청하고, 호스트는 어떤 서버를 어느 대화에 연결할지 오케스트레이션한다. 컨텍스트를 조립하는 계층과 애플리케이션 로직을 분리할 수 있는 이유다.

추론 직전에 필요한 정보만 조립한다

정적인 프롬프트 템플릿만으로는 요청마다 달라지는 메모리와 검색 결과, 도구 목록을 반영하기 어렵다. **동적 컨텍스트 어셈블리(Dynamic Context Assembly)**는 각 추론 호출 직전에 다음 작업을 수행한다.

입력 쿼리를 해석해 필요한 배경 지식을 판별한다.
작업 메모리와 에피소딕 메모리, 장기 메모리를 병렬로 조회한다.
MCP에서 관련 도구를 탐색해 사용할 수 있는 도구 정의를 포함한다.
토큰 예산(token budget)에 맞춰 정보의 우선순위를 정하고 압축한다.
응답과 액션이 끝나면 메모리 상태를 갱신한다.

핵심은 많은 정보를 넣는 데 있지 않다. 현재 요청에 필요한 정보, 신뢰할 수 있는 검색 결과, 호출 가능한 도구와 최신 상태를 제한된 컨텍스트 윈도우 안에 일관되게 배치하는 데 있다.

RAG는 검색 계층으로 남는다

RAG(Retrieval-Augmented Generation)는 사라지는 것이 아니라 더 큰 컨텍스트 아키텍처 안으로 들어간다. VentureBeat는 "컨텍스트 아키텍처가 에이전틱 AI의 기업 검색을 RAG만으로 처리할 수 없는 한계에 부딪히면서 RAG를 대체하고 있다"고 분석했다. IT 및 데이터 리더의 77%도 "RAG만으로는 프로덕션 AI에서 정확성과 신뢰성을 확보하기 충분하지 않다"고 답했다.

이 결과를 RAG의 무용론으로 해석할 필요는 없다. RAG는 컨텍스트 엔지니어링 안에서 필요한 근거를 찾는 지능형 검색 엔진 역할을 맡는다. 검색 이후에는 메모리와 도구 결과를 함께 평가하고, 우선순위를 조정해 모델에 전달하는 별도의 조립 계층이 필요하다.

기업 환경에서는 검색 인덱스에 들어갈 데이터의 품질·출처·신선도를 관리해야 한다. AI 즉시 활용 가능한 메타데이터(AI-ready metadata)는 기업의 62%가 최우선 인프라 투자로 분류했다. 메타데이터 필터링 외에도 자주 조회되는 컨텍스트를 보관하는 시맨틱 캐시(Semantic Cache), 텍스트와 이미지·표·코드·구조화 데이터를 아우르는 멀티모달 검색이 결합된다.

⤢✕

프롬프트와 컨텍스트, 파인튜닝의 경계

프롬프트 엔지니어링, 컨텍스트 엔지니어링, 파인튜닝(Fine-Tuning)은 하나를 선택하면 나머지를 버려야 하는 대안이 아니다. 서로 다른 계층에서 문제를 해결한다.

구분	프롬프트 엔지니어링	컨텍스트 엔지니어링	파인튜닝(Fine-Tuning)
초점	명령어 표현 최적화	정보 환경 아키텍처 설계	모델 가중치 업데이트
적용 범위	단일 추론 호출	에이전트 전체 수명주기	특정 도메인/태스크
변경 비용	즉시·무비용	중간(인프라 재설계)	높음(재훈련 필요)
토큰 비용	매 호출마다 발생	동적 최적화 가능	짧은 프롬프트로 절감
지식 최신성	실시간 반영 가능	실시간 반영 가능	훈련 시점에 고정
일관성	낮음(프롬프트 민감)	높음(아키텍처 수준)	매우 높음(가중치 내재화)
적합한 상황	빠른 프로토타이핑	에이전틱 프로덕션 시스템	특수 도메인, 고정 태스크

2026년 업계의 베스트 프랙티스는 **"행동은 가중치에, 지식은 컨텍스트에(behavior in weights, knowledge in context)"**라는 원칙으로 요약된다. 파인튜닝은 일관된 행동 패턴과 도메인 어투를 가중치에 내재화하고, 컨텍스트 엔지니어링은 실시간 지식과 현재 상태를 모델에 공급한다.

파인튜닝이 필요한 범위는 기업 내부의 특수 어휘와 개념이 많은 환경, 오류 비용이 매우 높은 고정밀 분류·추출 태스크, 모델 크기를 줄여 배포 비용을 절감해야 하는 경우로 좁혀진다. 반대로 파인튜닝이 먼저 필요하다고 판단한 팀 중 다수는 컨텍스트 엔지니어링 계층을 충분히 활용하지 않은 상태라는 것이 2026년 전문가들의 공통된 의견이다.

컨텍스트 윈도우를 운영 자원으로 다루기

에이전틱 시스템에서 컨텍스트 윈도우는 비용이 큰 자원 중 하나다. 모든 대화와 검색 결과를 계속 누적하기보다 정보의 중요도와 시간에 따라 해상도를 조절해야 한다.

**계층적 메모리 구조(Hierarchical Memory Structure)**는 최근 정보를 온전하게 남기고 오래된 정보는 점진적으로 압축한다. 단순 슬라이딩 윈도우(Sliding Window) 대신 요약본과 선택적으로 보존한 원본을 함께 사용하는 하이브리드 전략이 2026년 표준이 됐다.

**컨텍스트 컴팩션(Context Compaction)**은 대화가 컨텍스트 한계에 가까워지면 오래된 구간을 요약해 압축한다. Anthropic은 Claude Opus에서 서버 사이드 자동 컨텍스트 컴팩션 API를 프로덕션으로 출시했으며, 동일 세션 안에서 투명하게 처리된다.

**토큰 예산 관리(Token Budget Management)**는 컨텍스트 구성 요소마다 우선순위를 매긴 뒤 예산 안에서 공간을 동적으로 배정한다. 일반적으로 시스템 프롬프트, 현재 태스크 컨텍스트, 최근 대화 이력, 검색 결과, 장기 메모리 순으로 우선순위를 둔다.

오래 실행할수록 컨텍스트 품질을 감시해야 한다

장기 실행 에이전트에서는 **컨텍스트 로트(Context Rot)**가 발생할 수 있다. 대화가 길어질수록 컨텍스트의 품질이 낮아지는 현상이다. 초기 행동 패턴을 되풀이하거나 도구 선택 정확도가 떨어지고, 앞선 내용과 모순되는 응답이 늘어나는 식으로 나타난다.

**컨텍스트 격리(Context Quarantine)**는 새 정보를 곧바로 기존 컨텍스트에 합치지 않는다. 먼저 격리한 뒤 기존 정보와 충돌하는지 확인하고 통합한다.

**컨텍스트 프루닝(Context Pruning)**은 현재 태스크와 관계없는 대화 이력을 주기적으로 제거한다. 관련성 점수를 계산해 임계값보다 낮은 정보를 삭제하는 과정을 자동화할 수 있다.

**컨텍스트 오프로딩(Context Offloading)**은 당장 쓰지 않는 정보를 외부 스토리지로 옮긴다. 이후 필요할 때만 검색해 다시 로딩하며, 에피소딕 메모리 저장소와 벡터 DB가 이를 담당한다.

멀티에이전트(Multi-Agent) 환경에는 상태 동기화 문제가 더해진다. 각 에이전트가 워크플로우의 다른 단계를 처리한다면 모든 컨텍스트 윈도우에 최신 공유 상태가 일관되게 반영돼야 한다. **공유 상태 스토어(Shared State Store)**와 컨텍스트 브로드캐스트 메커니즘이 기업 에이전틱 인프라의 핵심 컴포넌트로 자리 잡은 배경이다.

⤢✕

컨텍스트 엔지니어링은 프롬프트 작성법의 새 이름이 아니다. 메모리의 수명, 검색 품질, 호출 가능한 도구, 토큰 예산과 세션 상태를 하나의 운영 구조로 묶는 아키텍처 작업이다. 데이터 팀의 95%가 올해 관련 역량 확보에 투자할 계획이라는 결과도 이 문제가 개별 프롬프트가 아니라 기업 인프라의 범위로 이동했음을 보여준다.