컨텍스트 엔지니어링이란 무엇인가요?

시스템 프롬프트는 정체성, 역량, 제약 조건, 행동 지침 등 에이전트의 기본 컨텍스트를 설정합니다. 상호 작용이 있을 때마다 변경되는 사용자 프롬프트와 달리, 시스템 프롬프트는 비교적 안정적으로 유지되며 일관된 '개성'과 규칙을 제공하는 역할을 합니다. 효과적인 시스템 프롬프트는 다음 세 가지 상충적인 요구 사항의 균형을 맞춥니다: 구체성(모호한 행동을 예방할 만큼 명확할 것), 유연성(다양한 시나리오를 처리할 수 있을 만큼 일반적일 것), 간결성(컨텍스트 윈도우 공간을 보존할 수 있을 만큼 간결할 것). 모범 사례는 다음과 같습니다.

• 에이전트의 역할을 명시적으로 정의("귀하는 금융 분석가 보조원입니다...")
• 추상적인 규칙 대신 바람직한 행동에 대한 구체적인 예시를 제공
• 구조화된 구분자(XML 태그, 마크다운 섹션)를 사용해 지침을 구성함으로써 모델이 보다 잘 이해하도록 함
• 모델이 위치 편향을 보이므로, 중요한 제약 조건(안전 규칙, 출력 형식 요구 사항)을 눈에 잘 띄는 위치에 배치

고급 기술에는 런타임 컨텍스트에 따라 활성화되는 조건부 지침(예: "사용자가 개인 정보에 대해 질문하면 개인정보 보호 정책으로 안내")과 에이전트의 추론 과정을 안내하는 메타 지침(예: "분석을 제공하기 전에 단계별로 사고")이 포함됩니다. 시스템 프롬프트는 특히 컨텍스트 윈도우 경쟁에 취약합니다. 대화 기록, 도구 출력, 검색된 데이터가 누적되면 잘못 설계된 시스템 프롬프트가 모델의 유효 주의 범위에서 밀려나, 에이전트가 점차 핵심 지침을 '잊어버리는' 행동 드리프트(behavioral drift)를 초래합니다.

장기 메모리는 AI가 여러 세션이나 대화에 걸쳐 정보를 유지할 수 있도록 합니다. 세션이 끝나면 사라지는 단기 메모리와는 달리, 장기 메모리는 AI가 사용자 선호도, 과거 상호 작용, 학습한 사실을 기억해 이후 참조할 수 있게 해 줍니다.

상태와 기록은 현재 세션에서 에이전트의 작업 메모리를 구성하며, 진행 중인 상호 작용에서 말한 내용, 수행한 행동, 학습한 정보를 기록합니다. 이 단기 메모리는 대화의 연속성을 지원합니다. 에이전트가 이전 대화를 참조할 수 있어 사용자는 컨텍스트를 반복할 필요가 없습니다. 하지만 대화 기록은 상호 작용이 길어짐에 따라 선형적으로 증가하며, 컨텍스트 윈도우를 빠르게 소모합니다.

효과적인 컨텍스트 엔지니어링은 능동적인 메모리 관리 전략을 필요로 합니다. 요약은 이전 대화 내용을 간결한 표현으로 압축하면서도 핵심 사실과 결정을 보존합니다. 윈도잉은 최근 문맥이 가장 중요하다는 가정 하에 가장 최근 N개의 메시지만 저장하고, 이전 기록은 제거합니다. 선택적 유지는 휴리스틱을 적용해 중요한 정보(사용자 선호도, 확립된 사실, 미해결 질문)를 식별하고 보존하며, 일상적인 대화의 불필요한 부분은 제거합니다.

보다 정교한 접근 방식에서는 에이전트가 중요한 상태를 외부 저장소에 기록하고 필요할 때 이를 검색하는 에피소드 메모리 구조를 사용합니다. 이는 인간이 전체 대화를 활성 작업 메모리에 전부 담아 두지 않고, 필요할 때 특정 세부 사항만 떠올리는 방식을 모방한 것입니다. 문제는 일관성을 유지관리하는 것입니다. 지나치게 공격적으로 가지치기하면 에이전트가 주요 맥락을 '잊고' 실수를 반복하게 되며, 압축이 부족하면 맥락이 넘쳐 성능이 저하됩니다.

Retrieval-Augmented Generation(RAG)은 AI가 내부 회사 문서나 공개 웹사이트와 같은 지식 기반에서 '필요한 순간에 바로' 데이터를 검색하는 것을 포함합니다. RAG를 통해 AI는 원래 학습되지 않은 정보를 사용해 질문에 답할 수 있으며, 최신 정보와 정확성을 갖춘 응답을 제공할 수 있습니다.

시맨틱 청킹은 정보를 논리적으로 구조화하여 검색을 개선합니다. 텍스트를 임의의 고정 크기 조각으로 나누는 대신, 시맨틱 청킹은 관련 개념을 함께 그룹화합니다(예: 단락, 함수 또는 논리적 섹션별로). 관련 청크가 검색되면 그 주변 내용도 함께 포함됩니다. 이렇게 하면 LLM에 보다 일관되고 완전한 컨텍스트를 제공하여 추론 능력을 향상시키고, 정보 단편화로 인한 문제를 완화할 수 있습니다.

단일 검색 방법에 의존하면 자주 실패하기 때문에, 하이브리드 검색은 컨텍스트 엔지니어링에서 매우 중요합니다. 벡터 검색은 개념적으로 유사한 정보를 찾는 데 뛰어나지만(예: '여름 옷'이 '따뜻한 날씨 의상'을 찾는 경우), 구체적이고 정확한 용어는 놓칠 수 있습니다. 키워드 검색(예: BM25)은 정확한 일치 항목(예: 'SKU-123AB')을 찾는 데 뛰어나지만, 동의어 처리에는 약합니다. 하이브리드 검색은 두 가지를 하나의 통합된 쿼리로 결합하여, LLM이 가능한 가장 정확하고 균형 잡힌 컨텍스트를 파악할 수 있도록 하고, 사용자의 개념적 의도와 중요한 키워드를 모두 포착할 수 있게 합니다.

순위 재지정은 대규모 검색에 내재된 '속도 vs. 정확도'의 트레이드오프 문제를 해결합니다. 초기 검색(예: 하이브리드 검색)은 잠재적으로 관련된 다량의 문서(예: 상위 100개)를 신속하게 검색하도록 최적화되어 있습니다. 그 후 일반적으로 계산 비용은 더 높지만 훨씬 정확한 순위 재지정 모델을 사용하여, 이 작은 하위 집합에 대해서만 다시 점수를 매깁니다. 컨텍스트 엔지니어링에서는 절대적으로 가장 관련성이 높은 스니펫을 컨텍스트 윈도우의 맨 위에 배치하는 것이 중요합니다. 이렇게 하면 '중간에 잃어버리는' 문제를 완화하고, LLM이 가장 높은 품질의 정보에 주의를 집중하도록 할 수 있습니다.

도구는 코드 실행, 데이터베이스 쿼리, API 호출, 파일 조작 등 외부 시스템과의 상호 작용을 가능하게 하여 에이전트의 기능을 텍스트 생성 이상으로 확장합니다. 컨텍스트 엔지니어링 관점에서, 도구는 독특한 도전 과제를 제시합니다. 각 도구에는 컨텍스트 윈도우 공간을 차지하는 설명(이름, 목적, 매개변수, 사용 예시)이 필요합니다. 도구 라이브러리가 확장됨에 따라, 이 '도구 컨텍스트 오버헤드'가 중요해집니다. 100개의 도구 에이전트는 사용자의 실제 작업이 시작되기 전에 사용 가능한 기능을 설명하는 데 컨텍스트 윈도우의 30%–40%를 사용할 수 있습니다.

효과적인 도구 엔지니어링은 여러 가지 원칙을 따릅니다:

• 도구 설명은 간결하되 명확하게 작성: 도구의 목적, 유형이 지정된 필수 매개변수, 대표 예시 하나를 포함합니다.
• 도구를 구성 가능하게 설계: 더 작고 집중된 도구(예: "search_documents," "summarize_text")는 여러 시나리오를 처리하는 모놀리식(monolithic) 도구보다 더 유연하게 결합할 수 있습니다.
• 선택적 로딩을 위해 도구 카테고리 또는 네임스페이스를 구현: 금융 분석을 수행하는 에이전트에는 이미지 처리 도구가 필요하지 않습니다.
• 도구 결과 필터링 사용: 에이전트에게는 필수 정보만 반환하고 원시 API 응답은 제공하지 않습니다. 예를 들어, 데이터베이스 쿼리 도구는 전체 SQL 결과 집합 대신 '총 4,532달러의 관련 거래 3건 발견'을 반환해야 합니다.

잘 설계된 도구는 설명에 오류 처리 기능을 포함하여, 에이전트가 워크플로우에서 오류가 연쇄적으로 발생하지 않도록 하고, 문제 발생 시 우아하게 복구하는 방법을 학습하도록 합니다.

에이전틱 검색

에이전틱 검색은 자체적으로 고립된 컨텍스트에서 복잡한 다단계 탐색을 수행하는 특수한 '하위 에이전트' 도구입니다. 예를 들어, 자연어 요청을 정확한 ESQL 쿼리로 변환하고, 데이터를 찾아 주요 에이전트에게 간결한 요약만 반환하여 작업 메모리를 깔끔하게 유지할 수 있습니다.

도메인 특화 워크플로우

도메인별 워크플로우는 위험도가 높고 예측 가능한 비즈니스 프로세스를 위해 설계된 사전 정의된 결정론적 도구 체인으로, 신뢰성과 일관성이 탐색적 유연성보다 중요합니다. 각 단계를 동적으로 추론하는 범용 에이전트와 달리, 이러한 워크플로우는 엄격하고 검증된 순서를 따릅니다. 예: '고객 신원 확인 → 신용 기록 확인 → 외부 규제 심사 → 위험 점수 계산 → 규정 준수 보고서 생성'. 각 단계에는 명확한 성공 기준, 오류 처리, 롤백 절차가 포함되어 있습니다.

이러한 경직성은 의도적입니다. LLM 기반 추론에 내재된 예측 불가능성이 금융 승인, 의료 진단 또는 규제 준수와 같은 미션 크리티컬한 운영에 영향을 미치는 것을 방지합니다. 컨텍스트 엔지니어링 관점에서 도메인 워크플로는 자유도를 줄여 에이전트의 작업을 간소화합니다. 에이전트에게는 가능한 모든 도구와 전략에 대한 컨텍스트가 필요하지 않으며 현재 워크플로우 단계에 필요한 특정 정보만 있으면 됩니다. 이 집중된 컨텍스트는 정확성과 효율성을 모두 향상시킵니다.

구현은 일반적으로 상태 기계 또는 방향성 비순환 그래프(DAG)를 포함하며, LLM은 변수 요소(사용자 입력 구문 분석, 데이터 소스 선택, 자연어 요약 생성)를 처리하고, 결정론적 논리는 전체 프로세스 흐름을 제어합니다. 대신 적응력이 감소합니다. 이러한 워크플로우는 알려진 시나리오에서는 뛰어나지만, 미리 정해진 경로를 벗어난 예외 상황에서는 어려움을 겪습니다.

동적 도구 탐색

동적 도구 탐색은 에이전트가 대규모 도구 라이브러리에 액세스할 때 발생하는 '프롬프트 비대화(prompt bloat)' 문제를 해결합니다. 수백 개의 도구 설명을 시스템 프롬프트에 나열하면 컨텍스트 윈도우 공간을 낭비하고 도구 선택의 정확성이 떨어지지만, 이 전략은 도구 메타데이터에 대한 시맨틱 검색을 통해 런타임 시 관련 기능만을 가져옵니다.

에이전트가 작업을 받으면 작업 설명을 입력으로 사용하여 도구 레지스트리를 쿼리하고, 해당 특정 컨텍스트와 의미적으로 가장 유사한 3~5개의 도구를 검색합니다. 이 접근 방식은 적시 데이터 검색과 유사합니다. 도구는 필요할 때까지 외부 저장 공간에 보관되며, 에이전트의 관심은 전체 카탈로그에 분산되지 않고 적용 가능한 기능에 집중할 수 있습니다. MCP(모델 컨텍스트 프로토콜)와 같은 프로토콜은 도구를 동적으로 검색, 이해, 호출할 수 있는 레지스트리를 제공하여 이러한 패턴을 표준화합니다. 하지만 동적 검색은 검색 작업 자체에서 지연 시간이 발생할 수 있으며, 도구 설명이 모호할 때 에이전트가 차선의 도구를 선택하거나 막다른 길로 빠지지 않도록 세심한 엔지니어링이 필요합니다.

사용자 프롬프트는 에이전트의 행동을 유발하고, 즉각적인 작업 컨텍스트를 정의하는 직접 입력입니다. 상대적으로 정적으로 유지되는 시스템 프롬프트와 달리, 사용자 프롬프트는 상호 작용마다 달라지며 대부분의 LLM 아키텍처에서 가장 높은 주의(attention) 가중치를 갖습니다. 이러한 위치 편향 때문에, 사용자 프롬프트는 컨텍스트 내 다른 정보와 상충되더라도 우선적으로 반영되는 경우가 많습니다.

효과적인 컨텍스트 엔지니어링은 사용자 프롬프트를 단순한 질문 이상으로 취급하며, 시스템 프롬프트를 비대하게 만들지 않으면서도 검색 및 도구 선택을 안내하는 명시적인 컨텍스트 힌트(타임스탬프, 사용자 기본 설정, 세션 상태)를 포함할 수 있습니다. 스테이트풀(stateful) 에이전트의 경우, 사용자 프롬프트는 세션별 정보가 주입되는 진입점이 됩니다. 예를 들어, '분기별 지표에 관한 대화를 고려할 때...'라는 프롬프트는 에이전트에게 최근에 검색된 금융 데이터를 우선 처리하라는 신호를 보냅니다. 그러나 사용자 프롬프트는 컨텍스트에서 가장 예측하기 어려운 요소이며 모호하거나 모순적이거나 적대적일 수 있습니다. 컨텍스트 엔지니어링은 불명확한 요청을 재구성하는 쿼리 이해 모델, 프롬프트 인젝션 시도를 감지하는 안전 필터, 입력만으로는 사용자 의도를 신뢰성 있게 추론할 수 없는 폴백(fallback) 전략을 통해 이러한 변동성을 고려해야 합니다.

구조화된 출력은 AI가 JSON, XML, 표 등 특정 형식으로 포맷해야 하는 정보를 의미합니다. 구조화된 출력을 정의하면 AI의 응답이 일관성을 유지하고 다른 프로그램이나 시스템에서 손쉽게 활용할 수 있습니다.

이 개념들에 대해 더 자세히 알아보려면, 블로그 게시물 컨텍스트 엔지니어링 개요 전문을 참고하세요.

컨텍스트 엔지니어링은 LLM을 지원하기 위해 구축된 체계적인 파이프라인의 설계로 이해하는 것이 가장 좋습니다. 이 파이프라인은 다양한 구성 요소를 임시로 결합하는 것이 아니라, 특정 작업에 맞게 조정되며 루프의 각 단계에서 모델과 주고받는 전체 정보 흐름을 관리하도록 설계되었습니다. 이 파이프라인은 일반적으로 세 가지 핵심 단계로 구성됩니다.

1. 컨텍스트 검색 및 생성: 이 단계에서는 벡터 데이터베이스에서 문서를 검색하거나, 구조화된 SQL 데이터베이스를 쿼리하거나, 외부 서비스에 API를 호출하는 등 다양한 잠재적 입력으로부터 원시 데이터를 적극적으로 수집하는 작업이 포함됩니다.
2. 컨텍스트 처리: 수집된 원시 데이터는 최적화됩니다. 청킹, 요약, 압축, 구조화와 같은 기술을 사용하여 신호 대 잡음비를 최대화하도록 데이터를 변환하는 작업을 포함합니다.
3. 컨텍스트 관리: 이 마지막 단계에서는 여러 상호 작용에서 정보가 저장, 업데이트, 활용되는 방식을 관리합니다. 스테이트풀(stateful) 애플리케이션을 구축하는 데 필수적이며, 단기(세션) 및 장기(영구) 메모리에 대한 전략을 포함합니다.

가장 강력한 전략은 정보를 컨텍스트 윈도우 밖에 두고, 에이전트가 필요할 때 '적시에' 정보를 가져오는 것입니다. 이는 사람이 일하는 방식과 유사합니다. 우리는 라이브러리 전체를 외우지 않고 검색 엔진과 파일링 시스템을 이용해 필요할 때 필요한 정보를 찾습니다.

AI 에이전트의 경우, 이는 외부 지식베이스를 쿼리하는 것을 의미합니다. 그러나 적절한 정보를 찾는 것은 매우 어려운 과제입니다. 데이터가 늘어나면 단순한 시맨틱 검색만으로는 신뢰할 수 없는 결과가 나올 수 있습니다. 효과적인 선택을 위해서는 키워드, 시맨틱, 그래프 기반 검색 등 다양한 검색 기법을 결합한 하이브리드 접근이 필요하며, 이를 통해 방대하고 복잡한 데이터 세트에서 정확한 컨텍스트를 찾아낼 수 있습니다.

이 전략은 에이전트가 '스크래치패드' 파일이나 전용 데이터베이스와 같은 외부 메모리에 정보를 기록하여 오프로드할 수 있는 장소를 제공합니다. 예를 들어, 에이전트는 다단계 계획을 파일에 저장하고 이를 다시 참조하여 복잡한 컨텍스트 윈도우에서 계획이 밀려나는 것을 방지할 수 있습니다. 이렇게 하면 에이전트가 작업 메모리를 어지럽히지 않으면서 장기 실행 작업의 상태를 유지 관리하고 진행 상황을 추적할 수 있습니다.

압축 기법은 컨텍스트 윈도우에서 토큰 수를 줄이면서 필수 정보를 보존합니다.

• 요약: LLM을 사용하여 긴 대화나 문서를 간결한 요약으로 정리합니다. 예를 들어, 토큰이 많은 도구의 전체 출력은 그 결과의 짧은 요약으로 대체할 수 있습니다.
• 트리밍: 대화에서 가장 오래된 메시지를 삭제하거나 더 이상 필요하지 않은 중복된 도구 출력을 지우는 등 하드코딩된 규칙을 사용하여 컨텍스트를 필터링합니다.

고도로 복잡한 작업의 경우, 단일 에이전트가 과부하될 수 있습니다. 격리는 문제를 세분화하고 각기 고유하고 깔끔하며 집중된 컨텍스트 윈도우를 가진 전문화된 '하위 에이전트'에 하위 작업을 할당하는 것을 포함합니다. 리드 에이전트가 이 팀을 조율하여 각 전문가로부터 정제된 최종 결과만 받습니다. 이 접근 방식은 각 에이전트의 컨텍스트를 관련성 있고 관리 가능한 상태로 유지하여 복잡한 연구 또는 분석 작업에서 전반적인 성능을 향상시킵니다.

이러한 원칙을 따르면, 컨텍스트 엔지니어링은 LLM이 성공적인 결과, 즉 관련성 높은 출력을 생성할 가능성을 극대화할 수 있도록 가능한 한 적은 수의 고신호 토큰을 제공하는 것을 목표로 합니다.

근본적으로 컨텍스트 엔지니어링은 LLM이 한정된 주의(attention) 예산을 가진다는 근본적인 제약에 의해 형성됩니다. 토큰 단위로 측정되는 컨텍스트 윈도우는 모델이 한 번에 처리할 수 있는 최대 정보량을 정의합니다. 현대 모델들은 점점 더 큰 컨텍스트 윈도우(10만 토큰, 100만 토큰, 심지어 200만 토큰)를 지원하지만, 단순히 이 공간을 채운다고 해서 더 나은 성능이 보장되지는 않습니다.

LLM은 모든 토큰이 다른 모든 토큰에 주의를 기울여야 하는 트랜스포머 아키텍처에서 작동합니다. 컨텍스트가 증가하면 연산 오버헤드를 초래하고 전문가들이 말하는 '컨텍스트 로트(context rot)' 현상이 발생합니다. 이는 정보 부하가 증가함에 따라 모델이 집중력을 유지하고 특정 세부 사항을 회상하는 능력이 떨어지는 것을 의미합니다. 이 현상은 사람의 인지 한계를 반영하는 것으로, 더 많은 정보가 항상 더 나은 결정을 의미하지는 않습니다.

단순히 윈도우를 확장하는 것만으로도 상당한 어려움이 따릅니다.

• 비용 및 지연 증가: 트랜스포머 아키텍처의 어텐션(attention) 메커니즘 연산 복잡도는 시퀀스 길이에 따라 제곱($O(n^2)$)으로 증가하므로, 컨텍스트가 커질수록 비용이 기하급수적으로 늘어나고 처리 속도는 느려집니다.
• 성능 저하('중간에 손실됨'): LLM은 긴 컨텍스트 윈도우에서 시작 부분이나 끝 부분의 정보는 잘 기억하지만, 중간 부분의 정보는 회상 성능이 크게 떨어집니다.
• 노이즈 및 방해 요소: 더 큰 컨텍스트 윈도우는 관련 없는 '노이즈' 정보를 포함할 가능성을 높여 모델의 주의를 분산시키고 출력 품질을 저하시킬 수 있습니다. 이를 흔히 '건초 더미 속 바늘 찾기' 문제라고 합니다.

이러한 역설은 단순한 무차별적인 방식이 아닌 지능적인 선별의 필요성을 강조하며, 컨텍스트 엔지니어링을 일종의 정교한 기술로 만듭니다.

컨텍스트 엔지니어링의 주요 동인은 에이전트가 작업을 성공적이고 신뢰성 있게 수행할 수 있도록 하는 것입니다. 정확하고 관련성 있는 컨텍스트와 올바른 도구가 없으면, 에이전트는 환각을 일으키거나 잘못된 도구를 선택하거나, 다단계 계획을 실행하지 못하는 등 실패하게 됩니다. 이것이 컨텍스트 엔지니어링이 해결하고자 하는 근본적인 문제입니다.

컨텍스트 엔지니어링 시스템에서 출력 품질은 에이전트의 응답이 사용자 의도, 사실적 정확성, 작업 요구 사항과 얼마나 잘 일치하는지를 나타내며, 이는 LLM이 자연스럽게 달성하는 단순한 유창성이나 일관성과는 구별됩니다. 고품질 출력은 고품질 입력 컨텍스트에 크게 의존합니다. '쓰레기가 들어가면 쓰레기가 나온다'는 원칙이 직접적으로 적용됩니다.

컨텍스트 엔지니어링은 여러 메커니즘을 통해 출력 품질을 향상시킵니다.

• 검색 품질: 에이전트가 환각을 일으키거나 오래된 교육 데이터에 의존하지 않고, 정확하고 관련성 있는 소스 자료에 접근할 수 있게 합니다.
• 컨텍스트 구조: 모델이 정보를 얼마나 효과적으로 추출하고 합성할 수 있는지에 영향을 줍니다.
• 잘 분할되고 의미적으로 일관된 컨텍스트: 단편적인 스니펫보다 더 정확한 추론을 가능하게 합니다.
• 신호 대 잡음비가 중요합니다: 관련성이 높은 5개의 문서만 포함하는 것이, 같은 5개의 문서에 관련성이 낮은 20개의 문서를 추가하는 것보다 더 효과적입니다. 관련 없는 정보는 모델의 주의를 분산시키기 때문입니다.

출력 품질은 시스템 프롬프트의 지시 사항 명확성과 명시적인 형식 요구(예: JSON과 같은 구조화된 출력이 파싱 오류를 줄임)에 따라 달라집니다. 품질을 측정하려면 작업별 평가가 필요합니다. RAG 시스템은 사실 정확성, 에이전트는 작업 완료율, 대화형 시스템은 사용자 만족도 점수로 평가합니다. 컨텍스트 엔지니어링은 입력과 출력 간의 관계를 관찰하고 조정할 수 있게 하여 체계적인 품질 개선을 가능하게 합니다. 어떤 컨텍스트 조합이 더 나은 출력을 만드는지 측정하고, 그에 따라 검색, 순위 지정, 필터링을 최적화할 수 있습니다.

컨텍스트 윈도우의 각 토큰에는 컴퓨팅 리소스, API 요금, 그리고 지연 시간이라는 비용이 발생합니다. 컨텍스트 엔지니어링은 이 세 가지 모두에 직접적인 영향을 미칩니다.

• 비용 최적화: 프롬프트에서 불필요한 토큰을 줄이면 대용량 애플리케이션의 API 비용을 수십 배까지 절감할 수 있습니다.
• 지연 시간 단축: 작고 집중된 컨텍스트는 추론 시간을 단축하고 애플리케이션의 응답성을 높입니다.
• 품질 개선: 타깃팅된 고신호 컨텍스트는 초점이 맞지 않는 대규모 정보 덤프보다 일관되게 우수한 성능을 발휘합니다.

프로덕션 AI 시스템은 회복력이 있어야 합니다. 부적절한 컨텍스트 엔지니어링은 여러 가지 실패 모드로 이어집니다.

• 컨텍스트 오염: 환각이나 오류가 컨텍스트에 내장되어 후속 상호 작용에서 누적되는 경우
• 목표 이탈: 관련 없는 정보를 축적하여 에이전트가 원래 목표를 잃어버리게 되는 현상
• 용량 초과: 컨텍스트 윈도우가 낮은 우선순위의 데이터로 가득 차면서 중요한 정보가 잘리는 경우

적절한 컨텍스트 엔지니어링은 유효성 검증, 가지치기, 구조화된 메모리 관리를 통해 이러한 문제를 방지합니다. 컨텍스트를 수동적으로 정보를 쌓는 대상으로 보기보다는, 신중하게 큐레이션된 리소스로 취급합니다.