AI 에이전트 성능을 좌우하는 컨텍스트 엔지니어링 설계

에이전트가 무엇을 보느냐가 성능을 바꾼다

Anthropic과 GitHub Blog의 컨텍스트 엔지니어링 가이드는 AI 에이전트 설계의 초점을 질문 문구에서 정보 구성으로 옮긴다. 2026년의 멀티스텝 워크플로우에서는 정교한 프롬프트 한 줄보다 추론 과정에 어떤 토큰을 넣고, 유지하고, 비울지 결정하는 파이프라인이 더 넓은 영향을 미친다.

Anthropic은 컨텍스트 엔지니어링을 **“LLM 추론 중 원하는 결과를 극대화하는 최소한의 고신호(high-signal) 토큰 집합을 찾아내는 기술”**로 표현한다. 시스템 프롬프트만 다듬는 작업이 아니다. 검색 문서, 메시지 이력, 툴 정의와 출력, 메모리처럼 컨텍스트 창에 들어오는 모든 정보를 선택하고 배치하는 일이다.

GitHub Blog의 설명도 같은 지점을 향한다. 제한된 어텐션 예산 안에서 에이전트가 올바른 정보에 계속 집중하도록 만드는 것이 핵심이다.

프롬프트 최적화에서 정보 파이프라인으로

프롬프트 엔지니어링이 “어떻게 요청할 것인가”를 다룬다면, 컨텍스트 엔지니어링은 “작업에 앞서 무엇을 알려줄 것인가”를 설계한다.

단계	시기	핵심 역량	한계
프롬프트 엔지니어링	2022~2024	질문 문구 최적화	단일 턴, 정적 정보
컨텍스트 엔지니어링	2025~2026	동적 정보 파이프라인 설계	멀티턴 복잡성
하네스 엔지니어링	2026~	자율 에이전트 시스템 조율	진화 중

싱글 턴 챗봇에서는 프롬프트 자체가 큰 비중을 차지한다. 여러 단계에 걸쳐 검색하고 툴을 실행하며 상태를 갱신하는 에이전트에서는 프롬프트도 더 큰 컨텍스트 파이프라인에 들어가는 입력 중 하나가 된다.

정보를 많이 넣는다고 반드시 유리한 것도 아니다. 트랜스포머는 토큰 간 n² 쌍별 관계를 계산한다. 컨텍스트가 길어질수록 각 정보에 돌아가는 어텐션이 희석되고, 필요한 내용을 정확히 상기하는 능력이 떨어질 수 있다. 이 현상을 **컨텍스트 로트(context rot)**라고 한다.

컨텍스트 창에 들어오는 입력

⤢✕

지침은 구체성과 유연성 사이에 둔다

시스템 프롬프트는 에이전트 행동의 바닥을 만든다. 지나치게 세밀한 하드코딩 로직은 예상하지 못한 상황에 대응하기 어렵고, 모호한 고수준 지침은 행동을 충분히 제어하지 못한다. Anthropic이 제시한 기준은 행동을 유도할 만큼 구체적이면서도 강한 휴리스틱을 적용할 여지를 남기는 것이다.

GitHub는 .instructions.md의 applyTo 문법으로 작업 맥락에 맞는 지침만 불러오는 모듈식 방식을 제안한다. 관련 없는 규칙을 항상 싣지 않으므로 컨텍스트 창을 더 선별적으로 사용할 수 있다.

검색 결과는 필요해진 시점에 불러온다

검색 레이어는 외부 지식을 컨텍스트로 들여오는 통로다. 여기서는 저스트-인-타임(Just-In-Time) 조회가 중심 패턴이 된다. 작업 시작과 동시에 가능한 데이터를 전부 적재하지 않고, 파일 경로·URL·저장된 쿼리 같은 경량 식별자를 유지하다가 필요한 순간에 원문을 불러온다.

프로덕션 환경에서는 50개 이상의 후보를 폭넓게 검색한 뒤 크로스 인코더로 재랭킹할 수 있다. 컨텍스트를 조립하기 전에는 엄격한 Top-K 제한을 적용하고, 관련성 임계값 아래의 청크나 길고 중복된 툴 출력물을 제거하거나 요약해 신호를 보존한다.

Sourcegraph의 코드 인텔리전스 사례에서는 SCIP 프로토콜 기반 구조적 검색이 전통적 벡터 검색과 비교해 파일 리콜을 0.127에서 0.277로 높였고, Precision@5는 0.140에서 0.478로 향상시켰다. 일부 작업은 2시간 이상 걸리던 상태에서 90초 이내로 완료됐다.

메모리는 현재 작업과 세션 밖 지식을 나눈다

단기 메모리(Short-term Memory)는 현재 대화와 툴 호출 결과를 담는다. 이 정보는 컨텍스트 창에 상주하므로 창이 차면 오래된 내용을 요약하고 압축하는 **컴팩션(compaction)**이 필요하다. 아키텍처 결정과 미해결 이슈는 남기고, 반복되거나 중복된 툴 출력은 덜어내는 방식이다.

장기 메모리(Long-term Memory)는 세션이 끝난 뒤에도 유지해야 할 사용자 선호, 프로젝트 관례, 이전 상호작용 요약을 맡는다. .memory.md 파일이나 mem0, Letta 같은 외부 메모리 프레임워크로 구현할 수 있다. GitHub는 이를 시간과 세션을 넘어 프로젝트 지식과 결정을 보존하는 제도적 지식으로 설명한다.

툴 선택의 모호함을 줄인다

기능이 겹치는 툴은 에이전트에 불필요한 선택지를 준다. 어느 툴을 호출할지 판단하느라 여러 턴을 소비하거나 서로 다른 결과 형식 때문에 후속 처리가 복잡해질 수 있다. Anthropic은 툴이 자기완결적이고, 기능 중복이 없으며, 서술적인 파라미터를 갖춰야 한다고 권고한다.

2026년 프로덕션 툴체인에는 다음 범주가 포함된다.

벡터 DB: Weaviate, Pinecone, Qdrant, pgvector
오케스트레이션: LangChain, LlamaIndex, DSPy
코드 인텔리전스: Sourcegraph MCP 서버(SCIP 기반)
표준 인터페이스: Model Context Protocol(MCP)

정적 프롬프트가 멀티스텝 작업에서 막히는 지점

정적 프롬프트는 단일 턴과 단일 작업에서는 효과적일 수 있다. 하지만 작업이 여러 단계로 이어지면 이전 단계의 결과나 달라진 환경을 반영하기 어렵다. 가능한 맥락을 처음부터 모두 넣으면 어텐션 예산을 낭비하고, 실행 중 새로 발견한 정보를 활용하기도 힘들어진다.

동적 컨텍스트는 이 문제를 작업 중 반복되는 조회와 조립 과정으로 바꾼다.

⤢✕

이 과정의 바탕에는 **점진적 발견(Progressive Disclosure)**이 있다. 파일 구조, 명명 규칙, 타임스탬프는 에이전트가 어떤 정보를 언제 찾아야 하는지 알려주는 신호가 된다. 전체 데이터를 미리 기억시키는 대신 수요가 생길 때 접근하게 만드는 방식이다.

긴 작업에서 기억을 이어가는 방법

구조적 노트테이킹은 진행 상황, 중요한 맥락, 의존관계를 컨텍스트 창 밖에 기록한다. GitHub의 .memory.md 패턴처럼 작업 중 남긴 지속적 메모리를 이후 단계가 다시 읽을 수 있게 만든다.

복잡한 작업은 계획·구현·테스트처럼 별도 세션으로 나눌 수도 있다. 세션 분할(Session Splitting)을 사용하면 각 단계가 신선한 컨텍스트에서 시작하고, 앞선 세션의 맥락은 압축된 요약으로 넘겨받는다.

서브에이전트 아키텍처는 전문화된 에이전트마다 깨끗한 컨텍스트를 제공한다. 각 에이전트는 맡은 작업에 집중한 뒤 압축된 결과를 조율 에이전트에 반환한다. 전체 이력을 모든 에이전트가 공유하지 않아도 작업 연속성을 유지할 수 있다.

토큰을 늘릴 때 생기는 품질과 비용의 손실

컨텍스트를 더 넣으면 품질이 계속 좋아진다는 가정은 멀티스텝 환경에서 성립하지 않는다. 한쪽에서는 어텐션 희석과 “Lost in the Middle” 현상이 발생한다. 30K 토큰 벽 안에 묻힌 관련 정보는 컨텍스트 경계에 놓인 정보보다 현저히 낮은 성능을 보인다.

다른 쪽에서는 불필요한 토큰 처리 비용과 긴 컨텍스트로 인한 지연 시간이 늘어난다. 목표는 가능한 한 많은 토큰이 아니라 원하는 결과를 극대화하는 최소한의 고신호 토큰 집합이다.

이를 운영하려면 작업당 토큰 사용량과 툴 호출 횟수를 추적하고, 예산을 설정한 뒤 체계적인 초과가 발생할 때 알림을 보내는 모니터링 체계가 필요하다.

Anthropic은 컨텍스트 수명주기를 관리한다

Anthropic의 “Effective Context Engineering for AI Agents”는 에이전트 라이프사이클 전체를 관리 대상으로 본다.

적정 고도(Right Altitude): 시스템 프롬프트를 지나치게 세밀하거나 추상적이지 않은 수준에 둔다.
컨텍스트 편집(Context Editing): 규칙 기반 프루닝으로 컨텍스트 창을 제어 가능한 범위에 유지한다.
컨텍스트 인식(Context Awareness): 에이전트가 남은 컨텍스트 용량을 실시간으로 알 수 있게 한다.
메모리 툴: 외부 저장소를 연결해 정보를 지속적으로 저장하고 다시 검색한다.
프로그래매틱 툴 호출: 에이전트가 코드 실행을 통해 여러 툴을 조율하도록 허용한다.

이 다섯 가지 원칙은 개별 프롬프트보다 정보의 수명주기와 에이전트의 자기조절 능력에 초점을 맞춘다.

GitHub는 에이전트 경계를 검증한다

GitHub Blog의 “Multi-agent workflows often fail” 시리즈는 멀티에이전트 실패를 모델 능력보다 구조의 부재에서 찾는다. 에이전트 간 교환 형식과 실행 가능 범위가 불명확하면 잘못된 상태가 다음 단계로 전파된다.

패턴	문제	해결책
타입드 스키마	비정형 자연어 교환으로 불일치 발생	에이전트 간 명시적 데이터 구조 정의
액션 스키마	모호한 지시로 발산적 행동 유발	결과 집합을 사전 정의된 액션으로 제약
MCP 검증	잘못된 상태가 파이프라인 전파	실행 전 모든 툴 입출력 검증

여기서 멀티에이전트는 채팅 흐름이 아니라 분산 시스템에 가깝다. 각 에이전트의 경계를 검증하고, 에이전트 수를 늘리기 전에 가능한 액션을 제약하며, 디버깅에 필요한 중간 상태를 기록해야 한다.

AI 시스템 설계에서 이어지는 쟁점

컨텍스트 엔지니어링은 정보관리기술사의 AI 시스템 설계 영역과도 맞닿아 있다. 연계되는 주제는 세 가지다.

RAG 아키텍처에서는 단순한 유사도 검색을 넘어 재랭킹, 청크 경계 최적화, 컨텍스트 창 안의 위치 전략을 함께 다뤄야 한다. 검색 결과를 가져오는 것만으로 끝나지 않고 어떤 순서와 밀도로 모델에 전달할지를 설계하는 문제다.

에이전트 메모리 아키텍처에서는 단기·장기 메모리의 분리와 통합, 세션 간 상태 지속성, 메모리 압축 알고리즘이 핵심이 된다. 제한된 컨텍스트 창 안에서 작업 연속성을 유지하는 메커니즘이 필요하다.

토큰 예산 관리는 LLM 시스템의 비용과 성능 사이의 관계를 정량적으로 다룬다. 입력 토큰 최적화, 출력 토큰 제어, 캐싱 전략을 하나의 경제적 시스템 설계로 묶어야 한다.

컨텍스트 조립 이후의 에이전트 설계

2026년을 기점으로 컨텍스트 엔지니어링은 하네스 엔지니어링으로 확장되고 있다. 에이전트 하네스(agent harness)가 컨텍스트 조립을 자동화하면 개발자는 개별 정보 조각보다 전체 오케스트레이션 아키텍처에 집중하게 된다. Anthropic의 에이전트 API, GitHub Agent HQ, Google의 Managed Agents가 이 방향을 선도한다.

Model Context Protocol이 에이전트 간 데이터 교환의 사실상 표준으로 자리 잡으면서 컨텍스트 검증과 상태 전파는 인프라 수준에서 처리된다. 구현 부담은 줄어들지만 무엇을 전달하고 어디에서 검증할지 정하는 설계 원칙은 더 중요해진다.

토큰 사용량, 컨텍스트 활용도, 작업당 비용을 추적하는 관찰 가능성(observability) 도구도 성숙하고 있다. 컨텍스트 구성에 관한 판단을 운영 데이터로 확인할 수 있는 기반이다.

프롬프트 작성은 여전히 필요하다. 다만 에이전트 시스템에서는 저스트-인-타임 조회, 메모리 압축, 서브에이전트 분리, RAG 재랭킹, MCP 검증을 포함하는 더 큰 설계의 일부다. 에이전트가 무엇을 알아야 하는지뿐 아니라 언제 불러오고 무엇을 잊게 할지까지 정해야 컨텍스트 파이프라인이 완성된다.