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