2nd/00_Raw/Context Engineering.md

Context Engineering

📌 Brief Summary

Context Engineering(컨텍스트 엔지니어링)은 대규모 언어 모델(LLM) 기반 에이전트가 긴 작업을 수행할 때 컨텍스트 윈도우에 진입하는 정보를 능동적으로 큐레이션하고 구조화하는 시스템 설계 패러다임이다 [1-3]. 이는 단일 턴의 지시문을 최적화하는 프롬프트 엔지니어링(Prompt Engineering)을 넘어, 다중 턴에 걸쳐 어떠한 정보를 보존, 압축, 검색 및 주입할지를 결정하여 모델의 추론 환경을 관리한다 [1, 2]. 에이전트 하네스 엔지니어링(Agent Harness Engineering)의 핵심 하위 레이어인 컨텍스트 관리자(C-component)를 통해 구현되며, 에이전트의 신뢰성 향상과 토큰 비용 최적화, 그리고 보안 유지에 결정적인 역할을 한다 [4-6].

📖 Core Content

• 프롬프트 엔지니어링에서의 진화: AI 에이전트 시스템의 발전은 '무엇을 말할 것인가(Prompt Engineering)'에서 '어떤 정보를 보여줄 것인가(Context Engineering)'를 거쳐, '어떤 환경을 구축할 것인가(Harness Engineering)'로 진화했다 [1, 3, 7-10]. Context Engineering은 에이전트의 작업 기간이 길어지면서 발생하는 지시 사항의 표류(instruction drift)와 컨텍스트 부패(context rot)를 해결하기 위해 등장했다 [3, 9].
• 능동적 지식 필터로서의 역할: Context Engineering은 단순한 정보의 수동적 전달 경로가 아니라, 모델이 성취할 수 있는 바를 결정하는 능동적 인식 필터(active epistemic filter)로 작동한다 [11, 12]. 하네스는 잘림(Truncation), 요약(Summarization), 검색 증강(Retrieval-augmented), 지식 그래프(Knowledge graph), 행동으로서의 메모리(Memory-as-action) 등의 전략을 통해 컨텍스트를 스케줄링한다 [13-17].
• 초장문 컨텍스트 모델(Ultra-long-context models) 대응: 100만 토큰 이상의 윈도우를 가진 모델이 등장했음에도, 시퀀스 길이가 길어지면 초기나 중간에 위치한 정보에 대한 주의력이 떨어지는 '주의력 희석(attention dilution)' 현상이 발생한다 [18, 19]. 따라서 Context Engineering의 주요 과제는 단순히 '무엇을 남길 것인가(retention)'에서 '무엇을 돋보이게 할 것인가(salience)'로 이동했으며, 모델의 주의력이 가장 강한 위치에 중요 정보를 배치하는 구조적 닻(attention anchors)이나 계층적 정보 구성이 필요하다 [18, 19].
• 적응형 컨텍스트 압축(Adaptive Context Compaction): 토큰 예산이 고갈될 때 발생하는 시스템 충돌을 막기 위해, 컨텍스트 압력에 따라 5단계(70% 경고, 80% 관찰 마스킹, 85% 빠른 가지치기, 90% 공격적 마스킹, 99% 전체 요약)의 점진적인 압축 파이프라인을 운영한다 [20-22]. 대규모 도구 출력(예: 수천 줄의 코드나 로그)은 컨텍스트를 과도하게 점유하므로, 이를 파일 시스템이나 스크래치 파일로 오프로딩(offloading)하고 모델에는 짧은 요약과 파일 참조(reference)만 남긴다 [22-25].
• 이중 메모리 아키텍처(Dual-Memory Architecture): 전략적 사고를 위한 컨텍스트와 단기 실행을 위한 컨텍스트의 충돌을 피하기 위해, 전체 대화 이력을 요약한 일화적 메모리(Episodic memory)와 최근 몇 번의 상세 교환 기록을 그대로 유지하는 작업 메모리(Working memory)를 분리하여 함께 주입(Combined injection)한다 [26-28].
• 런타임 맥락 주입(Context-Injected Recovery & Reminders): 긴 세션에서 에이전트가 초기 지시를 잊는 것을 막기 위해, 도구 실행의 실패나 특정 이벤트 발생 시 적절한 시스템 알림(System Reminders) 및 오류 복구 지침을 컨텍스트에 즉시 주입하여 행동을 교정한다 [29-31].

⚖️ Trade-offs & Caveats

• 정보 보존과 보안의 상충 관계 (Retention-Security Coupling): 컨텍스트 윈도우를 길게 유지하면 에이전트의 작업 연속성과 성능은 향상되지만, 외부에서 주입된 악의적 페이로드(간접 프롬프트 주입)가 시스템 내에 더 오래 체류하게 되어 보안 위험이 크게 증가한다. 반면 보안을 위해 짧게 유지하면 작업 성능이 저하되는 딜레마가 있다 [32-34].
• 컨텍스트 부패 (Context Rot) 및 토큰 비용: 무분별하게 컨텍스트를 누적하면 모델의 정확도가 떨어질 뿐만 아니라 토큰 소비량이 작업 복잡도와 무관하게 초선형적(superlinear)으로 증가하여 경제적 비용이 기하급수적으로 커진다 [35-37].
• 검색 지연 (Retrieval Latency Injection): 모든 기록을 저장하고 필요할 때 검색하는 RAG 방식은 정보 손실을 피할 수 있지만, 긴 수평선의 작업에서는 각 단계마다 검색 쿼리를 실행해야 하므로 선형적으로 누적되는 심각한 지연 시간(Latency)을 초래한다 [38, 39].
• 압축 시 데이터 출처(Provenance) 상실: 컨텍스트의 요약 및 압축은 정보의 밀도를 높이지만, 해당 정보가 어디에서 왔는지에 대한 출처 데이터를 조용히 폐기할 위험이 있다 [40, 41]. 이를 보완하지 않으면 환각이나 오류 발생 시 디버깅이 불가능해진다 [42].
• 적대적 콘텐츠의 검색 게임화 (Retrieval gaming): 외부 콘텐츠를 검색해 컨텍스트를 구성할 때, 공격자가 예상되는 미래 쿼리와 의미적 유사성이 높도록 악의적 지시사항을 조작하면, 하네스가 이를 가장 관련성 높은 정보로 착각하여 우선적으로 컨텍스트에 주입할 위험이 있다 [43, 44].

🔗 Knowledge Connections

Related Concepts

[관계 유형 A: 아키텍처/기반 기술]

• Agent Harness (에이전트 하네스)

  • 연결 이유: Context Engineering이 실제로 작동하고 관리되는 상위 인프라 구조이기 때문이다 [8, 10, 45].
  • 이 개념을 통해 더 깊게 이해할 수 있는 부분: 컨텍스트 관리가 단순히 프롬프트를 다듬는 것을 넘어, 어떻게 실행 루프, 도구 레지스트리, 메모리 스토어와 결합하여 안전하고 통제된 자율 에이전트 환경을 구성하는지 이해할 수 있다 [4, 46].

• C-component (Context Manager)

  • 연결 이유: 에이전트 하네스 구조 내에서 Context Engineering 정책(압축, 검색, 우선순위 할당 등)을 전담하여 집행하는 핵심 거버넌스 모듈이다 [46, 47].
  • 이 개념을 통해 더 깊게 이해할 수 있는 부분: 매 턴마다 모델의 컨텍스트 윈도우에 어떤 정보가 어떻게 필터링되어 들어가는지 구체적인 메커니즘을 파악할 수 있다 [4, 47].

• Adaptive Context Compaction (적응형 컨텍스트 압축)

  • 연결 이유: Context Engineering이 토큰 예산 초과(OOM)를 방지하기 위해 채택하는 필수적인 세부 최적화 기법이다 [21, 22].
  • 이 개념을 통해 더 깊게 이해할 수 있는 부분: 70%부터 99%까지의 점진적 압력 한계치에 따라 관찰 내용 마스킹, 빠른 가지치기, 전체 요약 등이 어떻게 단계적으로 적용되는지 알 수 있다 [22, 48].

[관계 유형 B: 최적화 및 문제 현상]

• Context Rot (컨텍스트 부패)

  • 연결 이유: 효율적인 Context Engineering이 부재할 때 장기 실행 에이전트가 겪게 되는 핵심 실패 모드이기 때문이다 [35-37].
  • 이 개념을 통해 더 깊게 이해할 수 있는 부분: 하네스가 왜 적극적인 퇴거(eviction) 정책과 정보 압축을 스케줄링해야만 초선형적인 비용 증가와 모델의 지시 망각을 막을 수 있는지 근본적인 이유를 배울 수 있다 [36, 37, 49].

• Indirect Prompt Injection (간접 프롬프트 주입)

  • 연결 이유: 에이전트가 외부 문서를 검색해 컨텍스트에 포함시키는 과정에서 발생하는 치명적인 시스템 보안 취약점이다 [50, 51].
  • 이 개념을 통해 더 깊게 이해할 수 있는 부분: Context Engineering 설계 시 지시(instruction) 데이터와 정보(data) 데이터를 어떻게 분리하고 출처(provenance)를 추적해야 하는지에 대한 보안적 필요성을 이해할 수 있다 [50, 51].

Deeper Research Questions

• 100만 토큰 이상의 초장문 컨텍스트를 지원하는 모델에서 '주의력 희석(Attention Dilution)'을 최소화하기 위해 하네스 레벨에서 구조적 닻(Attention Anchors)을 어떻게 효율적으로 배치하고 스케줄링할 수 있는가?
• 컨텍스트 보존 기간이 길어질수록 성능이 향상되지만 동시에 악의적 프롬프트의 체류 시간이 증가하는 상충 관계(Retention-Security Coupling)를 수학적으로 모델링하고 공동 최적화(Joint Optimization)하는 프레임워크는 어떻게 구축할 수 있는가?
• 에이전트가 자체적으로 컨텍스트를 편집하고 압축하는 '행동으로서의 메모리(Memory-as-action)' 방식은 하네스가 중앙에서 강제하는 규칙 기반 요약(Rule-based Summarization) 방식과 비교하여 경제성 및 정확도 면에서 어떤 차이를 보이는가?
• 대규모 도구 실행 결과나 로그를 파일 시스템 등 외부 아티팩트 저장소로 오프로딩(offloading)할 때, 모델이 필요시 지연 없이 다시 해당 정보를 검색할 수 있도록 의미적 포인터(semantic pointer)를 어떻게 구성해야 하는가?
• 컨텍스트 압축(Compaction) 과정에서 불가피하게 발생하는 데이터 출처(Provenance)의 손실을 방지하고, 에이전트가 요약된 컨텍스트를 기반으로 추론할 때 발생할 수 있는 환각을 어떻게 교정할 수 있는가?

Practical Application Contexts

• Implementation: LangChain의 DeepAgents 프레임워크처럼 시스템 프롬프트를 단일 거대 파일로 제공하지 않고 미들웨어 아키텍처를 사용하여 조건별(우선순위, 모델 벤더별)로 모듈화하여 동적 주입 및 검증 루프를 구성한다 [52-54].
• System Design: 도구 출력 결과(예: 수천 줄의 코드 분석 결과)를 컨텍스트에 그대로 넣지 않고, 8,000자 이상의 출력은 스크래치 파일에 저장한 후 모델에는 메타데이터(예: "파일 읽기 완료, 142줄, 4,831자")와 참조 핸들만 제공하도록 도구 결과 최적화(Tool Result Optimization) 파이프라인을 설계한다 [23-25, 55].
• Operation / Maintenance: 모델 API가 보고하는 실제 프롬프트 토큰 사용량(prompt_tokens)을 기준으로, 현재 사용량이 80%에 도달하면 과거 도구 출력결과를 참조로 대체(마스킹)하고 99% 도달 시 LLM을 사용해 전체 대화 이력을 요약하는 모니터링 시스템을 운영한다 [20-22].
• Learning Path: 처음에는 단일 프롬프트 최적화(Prompt Engineering)부터 시작하여, 에이전트가 여러 세션을 넘나들며 작업할 때 어떤 기억을 남기고 버릴지 설계하는 Context Engineering을 익히고, 최종적으로 이를 인프라 레벨의 강제 규칙으로 승격시키는 Harness Engineering으로 학습을 확장한다 [1, 3, 7, 8, 56].
• My Project Relevance: 복잡한 소프트웨어 엔지니어링 문제를 해결하는 코딩 에이전트를 구축할 때, 토큰 한도 초과(OOM) 방지와 지속적인 목표 인지를 위해 에피소드 메모리(Episodic Memory) 요약과 작업 메모리(Working Memory) 유지를 분리 적용하는 데 직접적으로 활용할 수 있다 [26-28].

Adjacent Topics

• Prompt Engineering
  • 확장 방향: 단일 턴 상호작용에서 어떻게 지시를 전달할 것인가에 대한 모델 최적화 기법으로, 다중 턴에서 구조적 정보 배치를 다루는 Context Engineering 이전 단계의 기반 지식으로 확장할 수 있다 [1, 6, 7].
• Retrieval-Augmented Generation (RAG)
  • 확장 방향: 제한된 컨텍스트 예산 내에서 외부 지식을 언제, 어떻게 쿼리하고 주입할 것인지에 대한 구체적인 메커니즘을 탐구하는 방향으로 심화할 수 있다 [57, 58].

---

Last updated: 2026-05-01