요약: 컨텍스트 엔지니어링은 프롬프트 엔지니어링의 자연스러운 발전으로, LLM의 제한된 주의 예산 내에서 최적의 결과를 얻기 위해 어떤 정보를 어떻게 제공할지 체계적으로 관리하는 기술입니다. LLM은 컨텍스트 길이가 길어질수록 정보 회수 능력이 저하되는 ‘컨텍스트 로트’ 현상을 겪으므로, 시스템 프롬프트, 도구, 예제, 메시지 기록 등 모든 컨텍스트 구성 요소를 신중하게 설계해야 합니다. 장기 작업을 위해서는 압축, 구조화된 메모 작성, 서브 에이전트 아키텍처와 같은 기법을 활용해 컨텍스트 창의 제약을 극복해야 합니다.
프롬프트 엔지니어링이 응용 AI 분야의 주목을 받던 몇 년 후, 새로운 용어가 부상했습니다: 컨텍스트 엔지니어링(context engineering). 언어 모델로 구축하는 것은 더 이상 프롬프트에 적합한 단어와 구문을 찾는 것이 아니라, “어떤 컨텍스트 구성이 모델의 원하는 행동을 생성할 가능성이 가장 높은가?”라는 더 넓은 질문에 답하는 것이 되어가고 있습니다. 컨텍스트는 대규모 언어 모델(LLM)에서 샘플링할 때 포함되는 토큰 세트를 의미합니다. 당면한 엔지니어링 문제는 일관된 결과를 달성하기 위해 LLM의 본질적인 제약에 대해 이러한 토큰들의 유용성을 최적화하는 것입니다. LLM을 효과적으로 다루려면 종종 컨텍스트 관점에서 생각해야 합니다 – 즉, 주어진 시점에 LLM이 사용할 수 있는 전체 상태와 그 상태가 어떤 잠재적 행동을 산출할 수 있는지 고려하는 것입니다. 이 게시물에서는 컨텍스트 엔지니어링이라는 싹트는 예술을 탐구하고 제어 가능하고 효과적인 에이전트를 구축하기 위한 정교한 멘탈 모델을 제공합니다.
컨텍스트 엔지니어링 대 프롬프트 엔지니어링
Anthropic에서는 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 자연스러운 진화로 봅니다. 프롬프트 엔지니어링은 최적의 결과를 위해 LLM 지시사항을 작성하고 구성하는 방법을 말합니다 (개요와 유용한 프롬프트 엔지니어링 전략은 우리의 문서를 참조하세요). 컨텍스트 엔지니어링은 프롬프트 외에도 포함될 수 있는 다른 모든 정보를 포함하여 LLM 추론 동안 최적의 토큰 세트(정보)를 큐레이션하고 유지하는 전략 세트를 말합니다.
LLM으로 엔지니어링하는 초기에는 프롬프팅이 AI 엔지니어링 작업의 가장 큰 구성 요소였습니다. 일상적인 채팅 상호작용 외의 대부든 사용 사례는 원샷 분류나 텍스트 생성 작업을 위해 최적화된 프롬프트가 필요했기 때문입니다. 용어가 암시하듯이, 프롬프트 엔지니어링의 주요 초점은 특히 시스템 프롬프트를 포함하여 효과적인 프롬프트를 작성하는 방법입니다.
하지만 여러 턴의 추론과 더 긴 시간 지평선에서 작동하는 더 유능한 에이전트를 엔지니어링해감에 따라, 전체 컨텍스트 상태(시스템 지시사항, 도구, Model Context Protocol (MCP), 외부 데이터, 메시지 기록 등)를 관리하는 전략이 필요합니다. 루프에서 실행되는 에이전트는 다음 추론 턴에 관련될 수 있는 점점 더 많은 데이터를 생성하며, 이 정보는 순환적으로 정제되어야 합니다. 컨텍스트 엔지니어링은 끊임없이 진화하는 가능한 정보의 우주에서 제한된 컨텍스트 창에 무엇이 들어갈지 큐레이션하는 예술이자 과학입니다.
프롬프트를 작성하는 이산적인 작업과 달리, 컨텍스트 엔지니어링은 반복적이며 큐레이션 단계는 모델에 무엇을 전달할지 결정할 때마다 발생합니다.
유능한 에이전트 구축에서 컨텍스트 엔지니어링의 중요성
속도와 점점 더 많은 양의 데이터를 관리하는 능력에도 불구하고, 우리는 LLM이 인간과 마찬가지로 특정 시점에서 초점을 잃거나 혼란을 겪는 것을 관찰했습니다. 건초 더미에서 바늘 찾기 스타일의 벤치마킹에 대한 연구는 컨텍스트 로트(context rot) 개념을 밝혀냈습니다: 컨텍스트 창의 토큰 수가 증가함에 따라 모델이 해당 컨텍스트에서 정보를 정확하게 회수하는 능력이 감소합니다. 어떤 모델은 다른 모델보다 더 완만한 저하를 보이지만, 이 특성은 모든 모델에서 나타납니다.
따라서 컨텍스트는 체감 한계가 있는 한정된 자원으로 취급되어야 합니다. 제한된 작업 메모리 용량을 가진 인간과 마찬가지로, LLM에는 대량의 컨텍스트를 구문 분석할 때 사용하는 “주의 예산(attention budget)”이 있습니다. 도입되는 모든 새로운 토큰은 어느 정도 이 예산을 소진하며, LLM에 제공되는 토큰을 신중하게 큐레이션해야 할 필요성을 증가시킵니다.
이러한 주의 희소성은 LLM의 아키텍처적 제약에서 비롯됩니다. LLM은 트랜스포머 아키텍처(transformer architecture) 를 기반으로 하며, 이를 통해 모든 토큰이 전체 컨텍스트에 걸쳐 다른 모든 토큰에 주의를 기울일 수 있습니다. 이것은 n개의 토큰에 대해 n² 쌍 관계를 생성합니다. 컨텍스트 길이가 증가함에 따라 모델이 이러한 쌍 관계를 포착하는 능력은 얇아지며, 컨텍스트 크기와 주의 초점 사이에 자연적인 긴장 관계가 형성됩니다.
또한 모델은 더 긴 시퀀스보다 더 짧은 시퀀스가 일반적으로 더 흔한 훈련 데이터 분포에서 주의 패턴을 개발합니다. 이것은 모델이 컨텍스트 전체 의존성에 대해 더 적은 경험을 가지고 더 적은 전문화된 매개변수를 가진다는 것을 의미합니다. 위치 인코딩 보간과 같은 기법을 통해 모델은 원래 훈련된 더 작은 컨텍스트에 맞춰 조정하여 더 긴 시퀀스를 처리할 수 있지만, 토큰 위치 이해에는 약간의 저하가 있습니다.
이러한 요인들은 성능 기울기를 생성하며 급격한 절벽은 아닙니다: 모델은 더 긴 컨텍스트에서도 고도로 유능하지만, 더 짧은 컨텍스트에서의 성능과 비교할 때 정보 회수 및 장거리 추론에 있어 감소된 정밀도를 보일 수 있습니다.
이러한 현실은 컨텍스트 엔지니어링이 유능한 에이전트를 구축하는 데 필수적임을 의미합니다.
효과적인 컨텍스트의 구조
LLM이 한정된 주의 예산으로 제약되어 있다는 점을 고려할 때, 좋은 컨텍스트 엔지니어링은 원하는 결과의 가능성을 극대화하는 가능한 가장 작은 고신호(high-signal) 토큰 세트를 찾는 것을 의미합니다. 이 실천을 구현하는 것은 말하는 것보다 훨씬 어렵지만, 다음 섹션에서는 이 안내 원칙이 컨텍스트의 다양한 구성 요소에서 실제로 무엇을 의미하는지 설명합니다.
시스템 프롬프트
시스템 프롬프트는 에이전트에게 적합한 높이에서 아이디어를 제시하는 명확하고 간단한 직접적인 언어를 사용해야 합니다. 올바른 높이는 두 가지 일반적인 실패 모드 사이의 골디락스 구역입니다.
한쪽 극단에서는 정확한 에이전트 행동을 유도하기 위해 엔지니어들이 프롬프트에 복잡하고 취약한 논리를 하드코딩하는 것을 볼 수 있습니다. 이 접근 방식은 취약성을 만들고 시간이 지남에 따라 유지 관리 복잡성을 증가시킵니다. 다른 극단에서는 엔지니어들이 때로는 모호하고 상위 수준의 지침을 제공하여 LLM이 원하는 출력에 대한 구체적인 신호를 제공하지 못하거나 공유 컨텍스트를 잘못 가정합니다.
최적의 높이는 균형을 맞춥니다: 행동을 효과적으로 안내할 만큼 구체적이면서도 모델이 행동을 안내하는 강력한 휴리스틱을 제공할 만큼 유연합니다.
한쪽 스펙트럼에서는 취약한 if-else 하드코딩된 프롬프트를 보고, 다른 쪽에서는 너무 일반적이거나 공유 컨텍스트를 잘못 가정하는 프롬프트를 봅니다. 우리는 프롬프트를 고유한 섹션(예:
시스템 프롬프트를 구조화하는 방식을 결정하든, 예상되는 행동을 완전히 개략적으로 설명하는 최소 정보 세트를 추구해야 합니다. (최소는 반드시 짧다는 것을 의미하지는 않습니다. 에이전트가 원하는 행동을 따르도록 하려면 여전히 충분한 정보를 미리 제공해야 합니다.)
가장 좋은 방법은 사용 가능한 최상의 모델로 최소 프롬프트를 테스트하여 작업에서 어떻게 수행하는지 확인한 다음, 초기 테스트 중에 발견된 실패 모드를 기반으로 성능을 개선하기 위해 명확한 지시사항과 예제를 추가하는 것입니다.
도구(Tools)
도구는 에이전트가 환경과 상호작용하고 작업하면서 새로운 추가 컨텍스트를 가져올 수 있게 합니다. 도구는 에이전트와 정보/작업 공간 간의 계약을 정의하므로, 토큰 효율적인 정보를 반환하고 효율적인 에이전트 행동을 장려함으로써 효율성을 촉진하는 것이 극히 중요합니다.
“Writing tools for AI agents – with AI agents”에서 우리는 LLM이 잘 이해하고 기능적 중복이 최소인 도구 구축에 대해 논의했습니다. 잘 설계된 코드베이스의 함수와 유사하게, 도구는 자체 포함적이고, 오류에 강건하며, 의도된 사용에 대해 극히 명확해야 합니다.
입력 매개변수도 마찬가지로 설명적이고, 모호하지 않으며, 모델의 고유한 강점을 활용해야 합니다. 우리가 보는 가장 일반적인 실패 모드 중 하나는 너무 많은 기능을 다루거나 사용할 도구에 대해 모호한 의사 결정 지점을 초래하는 비대한 도구 세트입니다. 인간 엔지니어가 주어진 상황에서 어떤 도구를 사용해야 하는지 명확하게 말할 수 없다면, AI 에이전트가 더 잘할 것이라고 기대할 수 없습니다.
나중에 논의하겠지만, 에이전트의 최소 실행 가능한 도구 세트를 큐레이션하는 것은 긴 상호작용에서 더 신뢰할 수 있는 유지 관리와 컨텍스트 정리로 이어질 수도 있습니다.
예제(Examples)
예제를 제공하는 것은 소샷 프롬프팅(few-shot prompting)으로도 알려져 있으며, 우리가 계속해서 강력하게 권장하는 잘 알려진 모범 사례입니다. 그러나 팀들은 종종 LLM이 특정 작업에서 따라야 하는 가능한 모든 규칙을 명확히 하려고 시도하며 에지 케이스의 일람표를 프롬프트에 채워 넣습니다. 우리는 이것을 권장하지 않습니다.
대신 우리는 에이전트의 예상되는 행동을 효과적으로 묘사하는 다양하고 전형적인 예제 세트를 큐레이션하는 것을 권장합니다. LLM의 경우 예제는 “천 마디 말의 가치가 있는 그림”입니다.
우리의 전반적인 가이드라인은 컨텍스트의 다양한 구성 요소(시스템 프롬프트, 도구, 예제, 메시지 기록 등) 전체에서 사려 깊고 컨텍스트를 유익하게 유지하면서도 단단하게 유지하는 것입니다. 이제 런타임에 컨텍스트를 동적으로 검색하는 방법을 살펴보겠습니다.
컨텍스트 검색 및 에이전트 서치
“Building effective AI agents”에서 우리는 LLM 기반 워크플로우와 에이전트의 차이점을 강조했습니다. 그 게시물을 작성한 이후, 우리는 에이전트에 대한 간단한 정의로 수렴했습니다: 루프에서 도구를 자율적으로 사용하는 LLM.
고객들과 함께 작업하면서 우리는 이 단순한 패러다임으로 분야가 수렴하는 것을 보았습니다. 기본 모델이 더 유능해짐에 따라 에이전트의 자율성 수준은 확장할 수 있습니다: 더 스마트한 모델은 에이전트가 미묘한 문제 공간을 독립적으로 탐색하고 오류에서 복구할 수 있게 합니다.
우리는 이제 엔지니어들이 에이전트를 위한 컨텍스트를 설계하는 방식에서의 변화를 보고 있습니다. 오늘날 많은 AI 네이티브 애플리케이션은 에이전트가 추론할 중요한 컨텍스트를 표면화하기 위해 임베딩 기반 추론 전 사전 검색의 어떤 형태를 사용합니다.
분야가 더 에이전트 중심적인 접근 방식으로 전환함에 따라, 우리는 점점 더 많은 팀들이 “적시(just in time)” 컨텍스트 전략으로 이러한 검색 시스템을 보강하는 것을 봅니다. 모든 관련 데이터를 미리 전처리하는 대신, “적시” 접근 방식으로 구축된 에이전트는 가벼운 식별자(파일 경로, 저장된 쿼리, 웹 링크 등)를 유지하고 이러한 참조를 사용하여 런타임에 도구를 통해 동적으로 데이터를 컨텍스트에 로드합니다.
Anthropic의 에이전트 코딩 솔루션인 Claude Code는 대규모 데이터베이스에서 복잡한 데이터 분석을 수행하기 위해 이 접근 방식을 사용합니다. 모델은 타겟팅된 쿼리를 작성하고 결과를 저장하며, 전체 데이터 객체를 컨텍스트에 로드하지 않고도 대량의 데이터를 분석하기 위해 head 및 tail과 같은 Bash 명령을 활용할 수 있습니다.
이 접근 방식은 인간 인지를 반영합니다: 우리는 일반적으로 정보의 전체 말뭉치를 암기하지 않고, 필요에 따라 관련 정보를 검색하기 위해 파일 시스템, 받은편지함, 북마크와 같은 외부 구성 및 인덱싱 시스템을 도입합니다.
저장 효율성을 넘어서, 이러한 참조의 메타데이터는 명시적으로 제공되거나 직관적이든 효율적으로 행동을 정제할 수 있는 메커니즘을 제공합니다. 파일 시스템에서 작동하는 에이전트에게 tests 폴더에 있는 test_utils.py 파일의 존재는 src/core_logic/에 있는 동일한 이름의 파일과 다른 목적을 암시합니다. 폴더 계층 구조, 명명 규칙, 타임스탬프는 모두 인간과 에이전트가 정보를 어떻게 그리고 언제 활용해야 하는지 이해하는 데 도움이 되는 중요한 신호를 제공합니다.
에이전트가 데이터를 자율적으로 탐색하고 검색하게 하는 것은 점진적 공개(progressive disclosure)도 가능하게 합니다 – 즉, 에이전트가 탐색을 통해 점진적으로 관련 컨텍스트를 발견하게 하는 것입니다. 각 상호작용은 다음 결정을 알리는 컨텍스트를 산출합니다: 파일 크기는 복잡성을 시사합니다. 명명 규칙은 목적을 암시합니다. 타임스탬프는 관련성의 대리일 수 있습니다.
에이전트는 레이어별로 이해를 조립하며, 작업 메모리에 필요한 것만 유지하고 추가 지속성을 위해 메모 작성 전략을 활용합니다. 이 자체 관리형 컨텍스트 창은 에이전트가 포괄적이지만 잠재적으로 관련 없는 정보에 빠지지 않고 관련 하위 세트에 집중하게 합니다.
물론 절충안이 있습니다: 런타임 탐색은 미리 계산된 데이터를 검색하는 것보다 느립니다. 그뿐만 아니라, LLM이 정보 환경을 효과적으로 탐색할 올바른 도구와 휴리스틱을 가지고 있는지 확인하기 위해 의견이 있고 사려 깊은 엔지니어링이 필요합니다.
적절한 지침이 없으면 에이전트는 도구를 오용하고, 막다른 길을 쫓거나, 핵심 정보를 식별하지 못하여 컨텍스트를 낭비할 수 있습니다. 특정 설정에서 가장 효과적인 에이전트는 속도를 위해 일부 데이터를 미리 검색하고, 그 재량에 따라 추가 자율적 탐색을 추구하는 하이브리드 전략을 사용할 수 있습니다.
“올바른” 자율성 수준에 대한 결정 경계는 작업에 따라 달라집니다. Claude Code는 이 하이브리드 모델을 사용하는 에이전트입니다: CLAUDE.md 파일은 미리 단순하게 컨텍스트에 드롭되는 반면, glob 및 grep과 같은 프리미티브는 환경을 탐색하고 적시에 파일을 검색할 수 있게 하여, 실질적으로 오래된 인덱싱 및 복잡한 구문 트리 문제를 우회합니다.
하이브리드 전략은 법률이나 금융과 같이 덜 동적인 콘텐츠가 있는 컨텍스트에 더 적합할 수 있습니다. 모델 기능이 향상됨에 따라 에이전트 설계는 지능형 모델이 지능적으로 행동하고 인간의 큐레이션을 점점 더 적게 하는 쪽으로 추세가 될 것입니다.
분야의 빠른 진전 속도를 고려할 때, Claude 위에서 에이전트를 구축하는 팀에게 “가장 단순한 것을 하라(do the simplest thing that works)”가 여전히 우리의 최고의 조언일 가능성이 높습니다.
장기 작업을 위한 컨텍스트 엔지니어링
장기 작업(long-horizon tasks)은 토큰 수가 LLM의 컨텍스트 창을 초과하는 작업 시퀀스에서 일관성, 컨텍스트, 목표 지향적 행동을 유지해야 하는 에이전트를 필요로 합니다. 대규모 코드베이스 마이그레이션이나 포괄적인 연구 프로젝트와 같이 수십 분에서 수 시간의 연속 작업에 걸치는 작업의 경우, 에이전트는 컨텍스트 창 크기 제약을 우회하기 위해 특수화된 기술이 필요합니다.
더 큰 컨텍스트 창을 기다리는 것이 분명한 전술처럼 보일 수 있습니다. 하지만 가까운 미래에는 모든 크기의 컨텍스트 창이 적어도 가장 강력한 에이전트 성능이 요구되는 상황에서는 컨텍스트 오염 및 정보 관련성 우려에 여전히 종속될 가능성이 높습니다.
에이전트가 확장된 시간 지평선에서 효과적으로 작동할 수 있도록 하기 위해, 우리는 이러한 컨텍스트 오염 제약을 직접적으로 해결하는 몇 가지 기술을 개발했습니다: 압축(compaction), 구조화된 메모 작성(structured note-taking), 서브 에이전트 아키텍처(multi-agent architectures).
압축(Compaction)
압축은 컨텍스트 창 제한에 가까워지는 대화를 가져와서 내용을 요약하고 요약으로 새로운 컨텍스트 창을 다시 시작하는 실천입니다. 압축은 일반적으로 더 나은 장기 일관성을 유도하기 위한 컨텍스트 엔지니어링의 첫 번째 레버로 작용합니다.
그 핵심에서 압축은 높은 충실도로 컨텍스트 창의 내용을 증류하여 에이전트가 최소의 성능 저하로 계속할 수 있게 합니다. 예를 들어 Claude Code에서는 메시지 기록을 모델에 전달하여 가장 중요한 세부 정보를 요약하고 압축함으로써 이를 구현합니다.
모델은 아키텍처 결정, 해결되지 않은 버그, 구현 세부 정보를 유지하면서 중복된 도구 출력이나 메시지를 삭제합니다. 그런 다음 에이전트는 이 압축된 컨텍스트와 최근에 액세스한 5개의 파일로 계속할 수 있습니다. 사용자는 컨텍스트 창 제한에 대해 걱정하지 않고 연속성을 얻습니다.
압축의 예술은 무엇을 유지할 것인지 무엇을 버릴 것인지 선택에 있으며, 과도하게 공격적인 압축은 나중에에야 중요성이 분명해지는 미묘하지만 중요한 컨텍스트가 손실될 수 있습니다.
압축 시스템을 구현하는 엔지니어를 위해 복잡한 에이전트 추적에서 프롬프트를 신중하게 튜닝하는 것을 권장합니다. 압축 프롬프트가 추적의 모든 관련 정보를 포착하도록 재현(recall)을 최대화하여 시작한 다음, 불필요한 콘텐츠를 제거하여 정밀도를 개선하기 위해 반복합니다.
가장 쉬운 불필요한 콘텐츠의 예는 도구 호출 및 결과 지우기입니다 – 도구가 메시지 기록 깊은 곳에서 호출되었다면, 에이전트가 왜 원시 결과를 다시 볼 필요가 있을까요? 가장 안전하고 가장 가벼운 형태의 압축 중 하나는 도구 결과 지우기로, Claude Developer Platform에서 기능으로 최근에 출시되었습니다.
구조화된 메모 작성(Structured note-taking)
구조화된 메모 작성 또는 에이전트 메모리(agentic memory)는 에이전트가 컨텍스트 창 외부의 메모리에 지속되는 메모를 정기적으로 작성하는 기술입니다. 이러한 메모는 나중에 컨텍스트 창으로 다시 가져옵니다. 이 전략은 최소한의 오버헤드로 지속적인 메모리를 제공합니다.
Claude Code가 할 일 목록을 만드는 것처럼, 또는 사용자 정의 에이전트가 NOTES.md 파일을 유지하는 것처럼, 이 간단한 패턴은 에이전트가 복잡한 작업에 걸친 진행 상황을 추적하고, 그렇지 않으면 수십 개의 도구 호출에 걸쳐 손실될 중요한 컨텍스트와 의존성을 유지할 수 있게 합니다.
포켓몬을 하는 Claude는 코딩이 아닌 도메인에서 메모리가 에이전트 능력을 어떻게 변형시키는지 보여줍니다. 에이전트는 수천 개의 게임 단계에 걸쳐 정확한 집계를 유지합니다 – 예를 들어 “마지막 1,234 단계 동안 Route 1에서 내 포켓몬을 훈련했고, 피카츄는 목표 10 레벨 중 8 레벨을 올렸습니다”와 같은 목표를 추적합니다.
메모리 구조에 대한 프롬프트 없이도, 탐험한 지역의 지도를 개발하고, 어떤 주요 성취를 해제했는지 기억하며, 다른 상대에게 어떤 공격이 가장 효과적인지 배우는 데 도움이 되는 전략적 메모를 유지합니다. 컨텍스트 재설정 후 에이전트는 자신의 메모를 읽고 수 시간의 훈련 시퀀스나 던전 탐험을 계속합니다.
이 요약 단계 간의 일관성은 모든 정보를 LLM의 컨텍스트 창에 유지하는 것만으로는 불가능했을 장기 전략을 가능하게 합니다.
Sonnet 4.5 출시의 일환으로 우리는 Claude Developer Platform에서 파일 기반 시스템을 통해 컨텍스트 창 외부의 정보를 더 쉽게 저장하고 조회할 수 있는 메모리 도구를 공개 베타로 출시했습니다. 이를 통해 에이전트는 시간이 지남에 따라 지식 베이스를 구축하고, 세션 간에 프로젝트 상태를 유지하며, 모든 것을 컨텍스트에 유지하지 않고도 이전 작업을 참조할 수 있습니다.
서브 에이전트 아키텍처(Sub-agent architectures)
서브 에이전트 아키텍처는 컨텍스트 제한을 우회하는 또 다른 방법을 제공합니다. 하나의 에이전트가 전체 프로젝트에 걸쳐 상태를 유지하려는 대신 전문화된 서브 에이전트가 깨끗한 컨텍스트 창으로 집중된 작업을 처리할 수 있습니다.
메인 에이전트는 상위 수준 계획으로 조율하는 반면 서브 에이전트는 심층적인 기술 작업을 수행하거나 도구를 사용하여 관련 정보를 찾습니다. 각 서브 에이전트는 광범위하게 탐색할 수 있으며 수만 개의 토큰 이상을 사용할 수 있지만 작업의 압축되고 증류된 요약(종종 1,000-2,000 토큰)만 반환합니다.
이 접근 방식은 명확한 관심사 분리를 달성합니다 – 상세한 검색 컨텍스트는 서브 에이전트 내에 격리되는 반면, 선도 에이전트는 결과를 종합하고 분석하는 데 집중합니다.
“How we built our multi-agent research system”에서 논의된 이 패턴은 복잡한 연구 작업에서 단일 에이전트 시스템보다 상당한 개선을 보여주었습니다.
이러한 접근 방식 간의 선택은 작업 특성에 따라 달라집니다. 예를 들어:
- 압축: 광범위한 대화가 필요한 작업을 위해 대화 흐름을 유지합니다.
- 메모 작성: 명확한 이정표가 있는 반복적 개발에 뛰어납니다.
- 다중 에이전트 아키텍처: 병렬 탐색이 보상이 되는 복잡한 연구 및 분석을 처리합니다.
모델이 계속 개선하더라도 확장된 상호작용에 걸쳐 일관성을 유지하는 도전은 더 효과적인 에이전트를 구축하는 데 여전히 중심으로 남을 것입니다.
결론(Conclusion)
컨텍스트 엔지니어링은 LLM으로 구축하는 방식에서 근본적인 변화를 나타냅니다. 모델이 더 유능해짐에 따라 도전은 완벽한 프롬프트를 작성하는 것이 아닙니다 – 각 단계에서 모델의 제한된 주의 예산에 어떤 정보가 들어갈지 사려 깊게 큐레이션하는 것입니다.
장기 작업을 위한 압축을 구현하든, 토큰 효율적인 도구를 설계하든, 에이전트가 환경을 적시에 탐색할 수 있도록 하든, 안내 원칙은 동일하게 유지됩니다: 원하는 결과의 가능성을 극대화하는 가능한 가장 작은 고신호 토큰 세트를 찾습니다.
우리가 개략한 기술들은 모델이 개선됨에 따라 계속 진화할 것입니다. 우리는 이미 더 스마트한 모델이 덜 처방적인 엔지니어링을 필요로 하여 에이전트가 더 많은 자율성으로 작동할 수 있게 하는 것을 보고 있습니다. 하지만 능력이 확장되더라도 컨텍스트를 소중하고 유한한 자원으로 취급하는 것은 신뢰할 수 있고 효과적인 에이전트를 구축하는 데 여전히 중심이 될 것입니다.
오늘 Claude Developer Platform에서 컨텍스트 엔지니어링을 시작하고, 메모리 및 컨텍스트 관리 쿡북을 통해 유용한 팁과 모범 사례에 액세스하세요.
감사의 말(Acknowledgements)
Anthropic의 Applied AI 팀인 Prithvi Rajasekaran, Ethan Dixon, Carly Ryan, Jeremy Hadfield가 작성했으며, 팀원인 Rafi Ayub, Hannah Moran, Cal Rueb, Connor Jennings의 기여가 있었습니다. 지원을 해주신 Molly Vorwerck, Stuart Ritchie, Maggie Vo에게 특별히 감사드립니다.
핵심 포인트
- 컨텍스트 엔지니어링은 프롬프트 엔지니어링의 자연스러운 발전으로, LLM의 제한된 주의 예산 내에서 최적의 결과를 얻기 위해 모든 컨텍스트 구성 요소(시스템 프롬프트, 도구, 예제, 메시지 기록 등)를 체계적으로 관리하는 기술이다.
- LLM은 컨텍스트 길이가 길어질수록 정보 회수 능력이 저하되는 ‘컨텍스트 로트’ 현상을 겪으므로, 가능한 가장 작은 고신호 토큰 세트를 찾는 것이 핵심 원칙이며, 이는 시스템 프롬프트, 도구, 예제 각각에 적용되는 고려사항이다.
- 장기 작업을 위해서는 압축(대화 요약 및 컨텍스트 창 재초기화), 구조화된 메모 작성(컨텍스트 외부 영구 저장), 서브 에이전트 아키텍처(전문화된 서브 에이전트에 작업 분할)와 같은 기법을 활용해 컨텍스트 창의 제약을 극복해야 한다.
