컨텍스트 엔지니어링 (Context Engineering)

요약 (TL;DR)

에이전트 (Agents)가 작업을 수행하려면 컨텍스트 (Context)가 필요합니다. 컨텍스트 엔지니어링 (Context engineering)은 에이전트의 궤적 (Trajectory) 매 단계마다 컨텍스트 창 (Context window)을 딱 적절한 정보로 채우는 기술이자 과학입니다. 이 포스트에서는 다양한 인기 에이전트와 논문들을 검토하며 컨텍스트 엔지니어링을 위한 몇 가지 공통적인 전략인 **쓰기 (write), 선택 (select), 압축 (compress), 격리 (isolate)**를 분석합니다. 그런 다음 LangGraph가 이러한 전략들을 지원하도록 어떻게 설계되었는지 설명합니다!

또한, 컨텍스트 엔지니어링에 관한 저희의 영상을 [여기]에서 확인하세요.

컨텍스트 엔지니어링 (Context Engineering)

Andrej Karpathy가 언급했듯이, LLM (Large Language Models)은 새로운 종류의 운영체제 (Operating system)와 같습니다. LLM은 CPU와 같고, 그 컨텍스트 창은 모델의 작업 메모리 (Working memory) 역할을 하는 RAM과 같습니다. RAM과 마찬가지로, LLM 컨텍스트 창은 다양한 출처의 컨텍스트를 처리하는 데 한정된 용량을 가집니다. 그리고 운영체제가 CPU의 RAM에 들어갈 내용을 선별하듯, 우리는 "컨텍스트 엔지니어링"이 유사한 역할을 한다고 생각할 수 있습니다. Karpathy는 이를 다음과 같이 잘 요약했습니다:

[컨텍스트 엔지니어링은] "...다음 단계를 위해 딱 적절한 정보로 컨텍스트 창을 채우는 섬세한 기술이자 과학이다."

LLM 애플리케이션을 구축할 때 관리해야 하는 컨텍스트의 유형에는 무엇이 있을까요? 컨텍스트 엔지니어링은 몇 가지 서로 다른 컨텍스트 유형에 적용되는 포괄적인 개념입니다:

지침 (Instructions) – 프롬프트 (Prompts), 메모리 (Memories), 퓨샷 예시 (Few-shot examples), 도구 설명 (Tool descriptions) 등
지식 (Knowledge) – 사실 (Facts), 메모리 (Memories) 등
도구 (Tools) – 도구 호출 (Tool calls)로부터의 피드백

에이전트를 위한 컨텍스트 엔지니어링 (Context Engineering for Agents)

올해 LLM이 추론 (Reasoning)과 도구 호출 (Tool calling) 능력이 향상됨에 따라 에이전트에 대한 관심이 엄청나게 커졌습니다. 에이전트는 종종 장기 실행 작업 (Long-running tasks)을 위해 LLM 호출 (LLM invocations)과 도구 호출 (Tool calls)을 교차하여 수행합니다. 에이전트는 LLM 호출과 도구 호출을 교차하며, 도구 피드백 (Tool feedback)을 사용하여 다음 단계를 결정합니다.

하지만 장기 실행 작업(long-running tasks)과 도구 호출(tool calls)로부터 누적되는 피드백은 에이전트가 종종 방대한 양의 토큰을 사용하게 된다는 것을 의미합니다. 이는 다음과 같은 수많은 문제를 야기할 수 있습니다: 컨텍스트 윈도우(context window)의 크기를 초과하거나, 비용 및 지연 시간(latency)을 폭증시키거나, 에이전트의 성능을 저하시킬 수 있습니다. Drew Breunig은 긴 컨텍스트가 성능 문제를 일으킬 수 있는 몇 가지 구체적인 방식을 다음과 같이 잘 정리해 두었습니다:

• 컨텍스트 오염 (Context Poisoning): 환각 (hallucination)이 컨텍스트에 포함될 때
• 컨텍스트 주의 분산 (Context Distraction): 컨텍스트가 학습된 내용을 압도할 때
• 컨텍스트 혼란 (Context Confusion): 불필요한 컨텍스트가 응답에 영향을 미칠 때
• 컨텍스트 충돌 (Context Clash): 컨텍스트의 일부 내용이 서로 상충할 때

이를 염두에 두고, Cognition은 컨텍스트 엔지니어링 (context engineering)의 중요성을 강조했습니다:

“컨텍스트 엔지니어링” …은 사실상 AI 에이전트를 구축하는 엔지니어들의 제1의 과업입니다.

Anthropic 또한 이를 명확하게 제시했습니다:

에이전트는 종종 수백 번의 턴(turn)에 걸친 대화에 참여하므로, 세심한 컨텍스트 관리 전략이 필요합니다.

그렇다면 오늘날 사람들은 이 과제를 어떻게 해결하고 있을까요? 우리는 에이전트 컨텍스트 엔지니어링을 위한 일반적인 전략들을 **쓰기(write), 선택(select), 압축(compress), 격리(isolate)**의 네 가지 범주로 분류하고, 인기 있는 에이전트 제품 및 논문 검토를 통해 각 사례를 제시합니다. 그런 다음 LangGraph가 이러한 전략들을 지원하도록 어떻게 설계되었는지 설명하겠습니다!

컨텍스트 쓰기 (Write Context)

컨텍스트를 쓴다는 것은 에이전트가 작업을 수행하는 데 도움이 되도록 컨텍스트 윈도우 외부의 어딘가에 저장하는 것을 의미합니다.

스크래치패드 (Scratchpads)

인간이 작업을 해결할 때, 우리는 메모를 하고 향후 관련 작업을 위해 무언가를 기억합니다. 에이전트 또한 이러한 능력을 갖추고 있습니다! “스크래치패드”를 통한 메모 작성은 에이전트가 작업을 수행하는 동안 정보를 유지하기 위한 한 가지 접근 방식입니다. 핵심 아이디어는 정보를 컨텍스트 윈도우 외부에 저장하여 에이전트가 사용할 수 있도록 하는 것입니다. Anthropic의 멀티 에이전트(multi-agent) 연구원은 이에 대한 명확한 사례를 보여줍니다:

LeadResearcher는 먼저 접근 방식을 생각하고 그 계획을 Memory (메모리)에 저장하여 컨텍스트 (context)를 유지합니다. 컨텍스트 윈도우 (context window)가 200,000 토큰을 초과하면 내용이 잘리게 되므로, 계획을 유지하는 것이 중요하기 때문입니다.

Scratchpad (스크래치패드)는 몇 가지 다른 방식으로 구현될 수 있습니다. 단순히 파일에 기록하는 Tool call (도구 호출) 형태일 수도 있고, 세션 동안 유지되는 Runtime state (런타임 상태) 객체의 필드 형태일 수도 있습니다. 어떤 경우든, Scratchpad는 에이전트가 작업을 완수하는 데 도움이 되는 유용한 정보를 저장할 수 있게 해줍니다.

Memories (메모리)

Scratchpad는 에이전트가 주어진 세션(또는 스레드) 내에서 작업을 해결하도록 돕지만, 때로는 에이전트가 수많은 세션에 걸쳐 무언가를 기억할 때 이득을 얻기도 합니다! Reflexion은 각 에이전트 턴(turn) 이후에 성찰(reflection)을 수행하고, 이렇게 스스로 생성된 메모리를 재사용하는 개념을 도입했습니다. Generative Agents는 과거 에이전트 피드백의 집합으로부터 주기적으로 합성된 메모리를 생성했습니다.

이러한 개념들은 ChatGPT, Cursor, Windsurf와 같은 대중적인 제품들로 이어졌으며, 이 제품들은 모두 사용자-에이전트 상호작용을 기반으로 세션 간에 유지될 수 있는 장기 메모리 (long-term memories)를 자동 생성하는 메커니즘을 갖추고 있습니다.

Select Context (컨텍스트 선택)

컨텍스트를 선택한다는 것은 에이전트가 작업을 수행할 수 있도록 컨텍스트 윈도우 (context window)로 컨텍스트를 끌어오는 것을 의미합니다.

Scratchpad

Scratchpad에서 컨텍스트를 선택하는 메커니즘은 Scratchpad가 어떻게 구현되었는지에 따라 달라집니다. 만약 그것이 도구(tool)라면, 에이전트는 단순히 도구 호출 (tool call)을 통해 이를 읽을 수 있습니다. 만약 에이전트의 런타임 상태 (runtime state)의 일부라면, 개발자는 매 단계마다 상태의 어떤 부분을 에이전트에게 노출할지 선택할 수 있습니다. 이는 나중의 턴에서 LLM에 Scratchpad 컨텍스트를 노출할 때 세밀한 수준의 제어를 제공합니다.

Memories

Memories (기억)

에이전트(Agents)가 기억을 저장할 수 있는 능력을 갖추고 있다면, 수행 중인 작업과 관련된 기억을 선택하는 능력 또한 필요합니다. 이는 몇 가지 이유로 유용할 수 있습니다. 에이전트는 원하는 행동의 예시를 위한 퓨샷 예시(few-shot examples, 에피소드 기억 (episodic memories)), 행동을 유도하기 위한 지침(instructions, 절차적 기억 (procedural memories)), 또는 작업 관련 컨텍스트를 위한 사실(facts, 의미적 기억 (semantic memories))을 선택할 수 있습니다.

한 가지 도전 과제는 관련 있는 기억이 확실히 선택되도록 보장하는 것입니다. 일부 인기 있는 에이전트들은 컨텍스트에 항상 불러오는 좁은 범위의 파일 세트를 단순히 사용합니다. 예를 들어, 많은 코드 에이전트(code agent)들은 지침(

RAG (Retrieval-Augmented Generation)는 풍부한 주제이며, 컨텍스트 엔지니어링 (Context Engineering)의 핵심적인 과제가 될 수 있습니다. 코드 에이전트 (Code agents)는 대규모 프로덕션 환경에서 RAG가 적용되는 가장 좋은 사례 중 일부입니다. Windsurf의 Varun은 이러한 과제 중 일부를 다음과 같이 잘 포착했습니다:

코드 인덱싱 (Indexing code) ≠ 컨텍스트 검색 (context retrieval) … [우리는 인덱싱 및 임베딩 검색 (embedding search)을 수행하고 있으며 … AST (Abstract Syntax Tree) 파싱을 통해 코드를 분석하고 의미론적으로 유의미한 경계에 따라 청킹 (chunking)을 수행합니다 … 코드베이스의 규모가 커짐에 따라 임베딩 검색은 검색 휴리스틱 (retrieval heuristic)으로서 신뢰할 수 없게 됩니다 … 따라서 우리는 grep/파일 검색, 지식 그래프 (knowledge graph) 기반 검색, 그리고 [컨텍스트]를 관련성 순으로 순위를 매기는 리랭킹 (re-ranking) 단계와 같은 기술들의 조합에 의존해야 합니다.

컨텍스트 압축 (Compressing Context)

컨텍스트 압축은 작업을 수행하는 데 필요한 토큰 (tokens)만을 유지하는 것을 포함합니다.

컨텍스트 요약 (Context Summarization)

에이전트 상호작용은 수백 번의 턴 (turns)에 걸쳐 이어질 수 있으며, 토큰 소모가 많은 도구 호출 (tool calls)을 사용할 수 있습니다. 요약은 이러한 과제를 관리하는 흔한 방법 중 하나입니다. 만약 Claude Code를 사용해 보았다면, 이것이 실제로 작동하는 것을 본 적이 있을 것입니다. Claude Code는 컨텍스트 창 (context window)의 95%를 초과하면 "자동 압축 (auto-compact)"을 실행하며, 사용자-에이전트 상호작용의 전체 궤적 (trajectory)을 요약합니다. 에이전트 궤적 전반에 걸친 이러한 유형의 압축은 재귀적 (recursive) 또는 계층적 (hierarchical) 요약과 같은 다양한 전략을 사용할 수 있습니다.

에이전트 설계의 특정 시점에 요약을 추가하는 것도 유용할 수 있습니다. 예를 들어, 특정 도구 호출(예: 토큰 소모가 많은 검색 도구)을 후처리하는 데 사용할 수 있습니다. 두 번째 예로, Cognition은 지식 전달 (knowledge hand-off) 과정에서 토큰을 줄이기 위해 에이전트 간 경계 (agent-agent boundaries)에서 요약을 수행한다고 언급했습니다. 특정 이벤트나 결정 사항을 반드시 포착해야 하는 경우 요약은 어려움이 될 수 있습니다. Cognition은 이를 위해 미세 조정된 (fine-tuned) 모델을 사용하며, 이는 이 단계에 얼마나 많은 노력이 들어갈 수 있는지를 강조합니다.

컨텍스트 트리밍 (Context Trimming)

요약 (Summarization)이 일반적으로 LLM을 사용하여 가장 관련 있는 컨텍스트 조각들을 추출하는 방식을 사용하는 반면, 트리밍 (Trimming)은 종음 컨텍스트를 필터링하거나 Drew Breunig이 지적한 것처럼 컨텍스트를 "가지치기 (Prune)" 할 수 있습니다. 이는 목록에서 오래된 메시지를 제거하는 것과 같은 하드코딩된 휴리스틱 (Heuristics)을 사용할 수 있습니다. Drew는 또한 질의응답 (Question-Answering)을 위해 훈련된 컨텍스트 가지치기 도구인 Provence에 대해서도 언급했습니다.

컨텍스트 격리 (Isolating Context)

컨텍스트 격리는 에이전트가 작업을 수행하는 데 도움이 되도록 컨텍스트를 분할하는 것을 포함합니다.

멀티 에이전트 (Multi-agent)

컨텍스트를 격리하는 가장 인기 있는 방법 중 하나는 이를 서브 에이전트 (Sub-agents)들로 나누는 것입니다. OpenAI Swarm 라이브러리의 동기 중 하나는 관심사의 분리 (Separation of concerns)였으며, 이를 통해 에이전트 팀이 특정 하위 작업 (Sub-tasks)을 처리할 수 있습니다. 각 에이전트는 특정 도구 세트, 지침, 그리고 자체적인 컨텍스트 창 (Context window)을 가집니다.

Anthropic의 멀티 에이전트 연구원은 이에 대해 다음과 같이 주장합니다. 격리된 컨텍스트를 가진 많은 에이전트가 단일 에이전트보다 더 나은 성능을 보였는데, 이는 주로 각 서브 에이전트의 컨텍스트 창이 더 좁은 하위 작업에 할당될 수 있기 때문입니다. 블로그에서 언급했듯이:

[서브 에이전트는] 각자의 컨텍스트 창을 가지고 병렬로 작동하며, 질문의 서로 다른 측면을 동시에 탐색합니다.

물론 멀티 에이전트의 과제에는 토큰 사용량 (예: Anthropic이 보고한 바와 같이 채팅보다 최대 15배 더 많은 토큰 사용), 서브 에이전트의 작업을 계획하기 위한 세심한 프롬프트 엔지니어링 (Prompt engineering)의 필요성, 그리고 서브 에이전트 간의 조정 (Coordination) 문제가 포함됩니다.

환경을 통한 컨텍스트 격리 (Context Isolation with Environments)

HuggingFace의 deep researcher는 컨텍스트 격리의 또 다른 흥미로운 사례를 보여줍니다. 대부분의 에이전트는 도구 호출 (Tool calling) API를 사용하며, 이는 도구 (예: 검색 API)에 전달되어 도구 피드백 (예: 검색 결과)을 얻을 수 있는 JSON 객체 (도구 인자)를 반환합니다. HuggingFace는 원하는 도구 호출을 포함하는 출력을 생성하는 CodeAgent를 사용합니다. 그런 다음 해당 코드는 샌드박스 (Sandbox) 내에서 실행됩니다. 도구 호출로부터 선택된 컨텍스트 (예: 반환 값)가 다시 LLM으로 전달됩니다.

이를 통해 환경 내에서 LLM으로부터 컨텍스트를 격리할 수 있습니다. Hugging Face는 이것이 특히 토큰 소모가 많은 객체들을 격리하는 데 매우 좋은 방법이라고 언급했습니다:

[Code Agents (코드 에이전트)는] 상태(state)를 더 잘 처리할 수 있게 해줍니다. … 이 이미지/오디오/기타 데이터를 나중에 사용하기 위해 저장해야 하나요? 문제없습니다. 그냥 상태(state) 내의 변수로 할당하면 [나중에 사용할 수 있습니다].

상태 (State)

에이전트의 런타임 상태(runtime state) 객체 또한 컨텍스트를 격리하는 훌륭한 방법이 될 수 있다는 점을 강조할 가치가 있습니다. 이는 샌드박싱 (sandboxing)과 동일한 목적으로 사용될 수 있습니다. 상태 객체는 컨텍스트가 기록될 수 있는 필드들을 가진 스키마 (schema)로 설계될 수 있습니다. 스키마의 한 필드(예: messages)는 에이전트의 매 턴마다 LLM에 노출될 수 있지만, 스키마는 더 선택적인 사용을 위해 다른 필드의 정보들을 격리할 수 있습니다.

LangSmith / LangGraph를 활용한 컨텍스트 엔지니어링 (Context Engineering)

그렇다면 이러한 아이디어들을 어떻게 적용할 수 있을까요? 시작하기 전에 도움이 될 만한 두 가지 기초적인 요소가 있습니다. 첫째, 데이터를 살펴보고 에이전트 전반에 걸친 토큰 사용량 (token-usage)을 추적할 수 있는 방법을 확보하십시오. 이는 컨텍스트 엔지니어링 노력을 어디에 집중하는 것이 가장 좋을지 판단하는 데 도움이 됩니다. LangSmith는 에이전트 트레이싱 (tracing) / 관측성 (observability)에 매우 적합하며, 이를 수행할 수 있는 훌륭한 방법을 제공합니다. 둘째, 컨텍스트 엔지니어링이 에이전트의 성능을 저하시키는지 아니면 향상시키는지 테스트할 수 있는 간단한 방법을 반드시 마련하십시오. LangSmith는 모든 컨텍스트 엔지니어링 노력의 영향을 테스트하기 위한 에이전트 평가 (agent evaluation)를 가능하게 합니다.

컨텍스트 쓰기 (Write context)

LangGraph는 스레드 범위 (thread-scoped, 단기) 및 장기 메모리 (long-term memory)를 모두 고려하여 설계되었습니다. 단기 메모리는 체크포인팅 (checkpointing)을 사용하여 에이전트의 모든 단계에 걸쳐 에이전트 상태를 유지합니다. 이는