AI 에이전트를 위한 효과적인 컨텍스트 엔지니어링
Effective context engineering for AI agents
컨텍스트는 AI 에이전트에게 중요하지만 유한한 자원입니다. 이 글에서는 에이전트를 작동시키는 컨텍스트를 효과적으로 큐레이션하고 관리하기 위한 전략들을 살펴봅니다.
몇 년 동안 프롬프트 엔지니어링이 응용 AI 분야에서 주목받은 후, 새로운 용어가 부상했습니다: 바로 컨텍스트 엔지니어링입니다. 언어 모델을 활용한 개발은 프롬프트에 적합한 단어와 구문을 찾는 것에서 벗어나, "어떤 컨텍스트 구성이 모델이 원하는 동작을 생성할 가능성이 가장 높은가?"라는 더 광범위한 질문에 답하는 것으로 변화하고 있습니다.
컨텍스트는 대규모 언어 모델(LLM)에서 샘플링할 때 포함되는 토큰의 집합을 의미합니다. 당면한 엔지니어링 문제는 원하는 결과를 일관되게 달성하기 위해 LLM의 내재된 제약 조건에 맞서 해당 토큰들의 효용을 최적화하는 것입니다. LLM을 효과적으로 다루려면 컨텍스트 안에서 사고해야 하는 경우가 많습니다. 다시 말해, 주어진 시점에 LLM이 사용할 수 있는 전체적인 상태와 그 상태가 야기할 수 있는 잠재적 행동들을 고려해야 합니다.
이 글에서는 새롭게 부상하는 컨텍스트 엔지니어링의 기술을 탐구하고, 제어 가능하고 효과적인 에이전트를 구축하기 위한 정제된 멘탈 모델을 제시합니다.
컨텍스트 엔지니어링과 프롬프트 엔지니어링
Anthropic에서는 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 자연스러운 발전으로 봅니다. 프롬프트 엔지니어링은 최적의 결과를 위해 LLM 명령어를 작성하고 구성하는 방법을 의미합니다(개요 및 유용한 프롬프트 엔지니어링 전략은 문서 참조). 컨텍스트 엔지니어링은 LLM 추론 중에 최적의 토큰 집합(정보)을 큐레이션하고 유지하기 위한 전략들의 집합을 의미하며, 여기에는 프롬프트 외부에서 유입될 수 있는 모든 다른 정보도 포함됩니다.
LLM 엔지니어링 초기에는, 일상적인 채팅 상호작용 외의 대부분의 사용 사례가 원샷 분류 또는 텍스트 생성 작업에 최적화된 프롬프트를 필요로 했기 때문에, 프롬프팅이 AI 엔지니어링 작업에서 가장 큰 비중을 차지했습니다. 용어가 시사하듯이, 프롬프트 엔지니어링의 주요 초점은 효과적인 프롬프트, 특히 시스템 프롬프트를 작성하는 방법입니다. 그러나 여러 턴의 추론과 더 긴 시간 지평에 걸쳐 작동하는 더 유능한 에이전트를 엔지니어링하는 방향으로 나아감에 따라, 전체 컨텍스트 상태(시스템 명령어, 도구, 모델 컨텍스트 프로토콜(MCP), 외부 데이터, 메시지 히스토리 등)를 관리하기 위한 전략이 필요합니다.
루프에서 실행되는 에이전트는 다음 추론 턴에 관련될 수 있는 점점 더 많은 데이터를 생성하며, 이 정보는 주기적으로 정제되어야 합니다. 컨텍스트 엔지니어링은 끊임없이 진화하는 가능한 정보의 공간에서 제한된 컨텍스트 윈도우에 포함될 내용을 큐레이션하는 기술이자 과학입니다.
![프롬프트를 작성하는 개별적인 작업과 달리, 컨텍스트 엔지니어링은 반복적이며 모델에 전달할 내용을 결정할 때마다 큐레이션 단계가 발생합니다.]
프롬프트를 작성하는 개별적인 작업과 달리, 컨텍스트 엔지니어링은 반복적이며 모델에 전달할 내용을 결정할 때마다 큐레이션 단계가 발생합니다.
컨텍스트 엔지니어링이 유능한 에이전트를 구축하는 데 중요한 이유
점점 더 큰 규모의 데이터를 관리하는 속도와 능력에도 불구하고, LLM은 인간처럼 특정 지점에서 집중력을 잃거나 혼란을 겪는다는 것을 관찰했습니다. 건초 더미에서 바늘 찾기 스타일의 벤치마킹 연구는 컨텍스트 부패라는 개념을 밝혀냈습니다: 컨텍스트 윈도우의 토큰 수가 증가함에 따라, 해당 컨텍스트로부터 정보를 정확하게 회상하는 모델의 능력이 감소합니다.
일부 모델은 다른 모델보다 더 완만한 성능 저하를 보이지만, 이러한 특성은 모든 모델에서 나타납니다. 따라서 컨텍스트는 한계 수익 체감 법칙이 적용되는 유한한 자원으로 취급되어야 합니다. 작업 기억 용량이 제한된 인간처럼, LLM은 대량의 컨텍스트를 파싱할 때 사용하는 "어텐션 예산"을 가지고 있습니다. 도입되는 모든 새로운 토큰은 이 예산을 일정량 소진시키며, 이는 LLM에 제공되는 토큰을 신중하게 큐레이션해야 할 필요성을 증가시킵니다.
이러한 어텐션 희소성은 LLM의 아키텍처 제약으로부터 비롯됩니다. LLM은 트랜스포머 아키텍처를 기반으로 하며, 이는 모든 토큰이 전체 컨텍스트에 걸쳐 **다른 모든 토큰에 어텐션할** 수 있게 합니다. 이는 n개의 토큰에 대해 n² 개의 쌍별 관계를 생성합니다.
컨텍스트 길이가 증가함에 따라, 이러한 쌍방향 관계를 포착하는 모델의 능력은 희석되며, 컨텍스트 크기와 어텐션 집중도 사이에 자연스러운 긴장이 발생합니다. 또한 모델은 짧은 시퀀스가 긴 시퀀스보다 더 흔한 학습 데이터 분포에서 어텐션 패턴을 학습합니다. 이는 모델이 컨텍스트 전체에 걸친 의존성에 대한 경험이 더 적고, 이를 위한 특화된 파라미터도 더 적다는 것을 의미합니다.
위치 인코딩 보간과 같은 기법들은 모델이 원래 학습된 더 작은 컨텍스트에 맞게 조정함으로써 더 긴 시퀀스를 처리할 수 있게 하지만, 토큰 위치 이해에서 일부 성능 저하가 발생합니다. 이러한 요인들은 급격한 절벽이 아닌 성능 경사를 만듭니다: 모델은 더 긴 컨텍스트에서도 여전히 높은 능력을 유지하지만, 더 짧은 컨텍스트에서의 성능과 비교했을 때 정보 검색과 장거리 추론에서 정밀도가 감소할 수 있습니다.
이러한 현실들은 유능한 에이전트를 구축하기 위해 신중한 컨텍스트 엔지니어링이 필수적임을 의미합니다.
효과적인 컨텍스트의 구조
LLM이 유한한 어텐션 예산에 제약을 받는다는 점을 고려할 때, 좋은 컨텍스트 엔지니어링은 원하는 결과의 가능성을 최대화하는 가능한 한 가장 작은 고신호 토큰 집합을 찾는 것을 의미합니다. 이 실무를 구현하는 것은 말하기는 쉽지만 행하기는 어렵지만, 다음 섹션에서는 컨텍스트의 다양한 구성 요소들에 걸쳐 이 지도 원칙이 실제로 무엇을 의미하는지 개괄합니다.
시스템 프롬프트는 극도로 명확해야 하며, 에이전트에게 적절한 고도에서 아이디어를 제시하는 단순하고 직접적인 언어를 사용해야 합니다. 적절한 고도는 두 가지 일반적인 실패 모드 사이의 골디락스 영역입니다. 한 극단에서는, 엔지니어들이 정확한 에이전트 행동을 유도하기 위해 프롬프트에 복잡하고 취약한 로직을 하드코딩하는 것을 볼 수 있습니다. 이 접근 방식은 취약성을 만들어내고 시간이 지남에 따라 유지보수 복잡도를 증가시킵니다. 다른 극단에서는, 엔지니어들이 때때로 LLM에게 원하는 출력에 대한 구체적인 신호를 제공하지 못하거나 공유된 컨텍스트를 잘못 가정하는 모호하고 고수준의 지침을 제공합니다. 최적의 고도는 균형을 이룹니다: 행동을 효과적으로 안내할 만큼 구체적이면서도, 모델에게 행동을 안내하는 강력한 휴리스틱을 제공할 만큼 유연합니다.
스펙트럼의 한쪽 끝에는 취약한 if-else 하드코딩된 프롬프트가 표시되고, 다른 쪽 끝에서는 지나치게 일반적이거나 공유된 컨텍스트를 잘못 가정하는 프롬프트를 볼 수 있습니다.
프롬프트를 별개의 섹션들(예:
시스템 프롬프트를 어떻게 구조화하기로 결정하든, 예상되는 행동을 완전히 설명하는 최소한의 정보 집합을 추구해야 합니다. (최소한이 반드시 짧다는 것을 의미하지는 않습니다; 에이전트가 원하는 행동을 준수하도록 보장하기 위해 여전히 사전에 충분한 정보를 제공해야 합니다.) 가장 좋은 방법은 사용 가능한 최고의 모델로 최소한의 프롬프트를 테스트하여 작업에서 어떻게 수행되는지 확인한 다음, 초기 테스트 중에 발견된 실패 모드를 기반으로 성능을 개선하기 위해 명확한 지침과 예제를 추가하는 것입니다.
도구들은 에이전트가 환경과 상호작용하고 작업하면서 새로운 추가 컨텍스트를 가져올 수 있게 합니다. 도구들은 에이전트와 그들의 정보/행동 공간 사이의 계약을 정의하기 때문에, 도구들이 토큰 효율적인 정보를 반환하고 효율적인 에이전트 행동을 장려함으로써 효율성을 촉진하는 것이 극도로 중요합니다.
AI 에이전트를 위한 도구 작성 – AI 에이전트와 함께에서, LLM이 잘 이해하고 기능 중복이 최소화된 도구를 구축하는 것에 대해 논의했습니다. 잘 설계된 코드베이스의 함수들과 유사하게, 도구들은 자체 포함적이고, 오류에 강건하며, 의도된 사용에 대해 극도로 명확해야 합니다. 입력 파라미터들도 마찬가지로 설명적이고, 모호하지 않으며, 모델의 내재된 강점을 활용해야 합니다.
우리가 보는 가장 일반적인 실패 모드 중 하나는 너무 많은 기능을 커버하거나 어떤 도구를 사용해야 하는지에 대한 모호한 결정 지점으로 이어지는 비대한 도구 세트입니다. 인간 엔지니어가 주어진 상황에서 어떤 도구를 사용해야 하는지 명확하게 말할 수 없다면, AI 에이전트가 더 잘할 것으로 기대할 수 없습니다. 나중에 논의하겠지만, 에이전트를 위한 최소 실행 가능한 도구 집합을 큐레이션하는 것은 긴 상호작용에 걸쳐 컨텍스트를 더 안정적으로 유지보수하고 정리하는 것으로 이어질 수도 있습니다.
퓨샷 프롬프팅으로도 알려진 예제 제공은 우리가 계속해서 강력하게 권장하는 잘 알려진 모범 사례입니다. 그러나 팀들은 LLM이 특정 작업에 대해 따라야 할 가능한 모든 규칙을 명시하려는 시도로 엣지 케이스들의 긴 목록을 프롬프트에 채워 넣는 경우가 많습니다. 우리는 이것을 권장하지 않습니다. 대신, 에이전트의 예상되는 행동을 효과적으로 묘사하는 다양하고 표준적인 예제 집합을 큐레이션하는 작업을 권장합니다. LLM의 경우 천 마디 말보다 가치가 있는 "그림"이 예입니다.
컨텍스트의 다양한 구성 요소들(시스템 프롬프트, 도구, 예제, 메시지 히스토리 등)에 걸친 우리의 전반적인 가이드는 신중하게 접근하고 컨텍스트를 유익하면서도 간결하게 유지하라는 것입니다. 이제 런타임에 컨텍스트를 동적으로 검색하는 것에 대해 살펴보겠습니다.
컨텍스트 검색과 에이전트 검색
효과적인 AI 에이전트 구축에서 LLM 기반 워크플로와 에이전트의 차이를 설명했습니다. 그 글을 쓴 후, 우리는 에이전트에 대한 간단한 정의에 도달했습니다: 루프에서 도구를 자율적으로 사용하는 LLM입니다.
고객들과 함께 일하면서, 이 분야가 이 단순한 패러다임으로 수렴하는 것을 보았습니다. 기본 모델이 더 유능해질수록, 에이전트의 자율성 수준도 확장될 수 있습니다: 더 똑똑한 모델은 에이전트가 복잡한 문제 공간을 독립적으로 탐색하고 오류에서 회복할 수 있게 합니다.
이제 엔지니어들이 에이전트를 위한 컨텍스트 설계를 생각하는 방식이 변하고 있습니다. 오늘날 많은 AI 네이티브 애플리케이션은 에이전트가 추론할 중요한 컨텍스트를 찾기 위해 임베딩 기반의 사전 추론 시간 검색을 사용합니다. 이 분야가 더 에이전트적인 접근 방식으로 전환하면서, 팀들이 이러한 검색 시스템을 "적시(just in time)" 컨텍스트 전략으로 보강하는 것을 점점 더 많이 보게 됩니다.
모든 관련 데이터를 미리 처리하는 대신, "적시" 접근 방식으로 구축된 에이전트는 가벼운 식별자들(파일 경로, 저장된 쿼리, 웹 링크 등)을 유지하고, 이 참조들을 사용하여 런타임에 도구로 데이터를 컨텍스트에 동적으로 로드합니다. Anthropic의 에이전트 코딩 솔루션인 Claude Code는 이 접근 방식을 사용해 대규모 데이터베이스에 대한 복잡한 데이터 분석을 수행합니다. 모델은 타겟 쿼리를 작성하고, 결과를 저장하고, head와 tail 같은 Bash 명령을 활용해 전체 데이터 객체를 컨텍스트에 로드하지 않고도 대량의 데이터를 분석할 수 있습니다. 이 접근 방식은 인간의 인지를 반영합니다: 우리는 보통 전체 정보를 암기하지 않고, 파일 시스템, 받은편지함, 북마크 같은 외부 조직화 및 색인 시스템을 사용해 필요할 때 관련 정보를 검색합니다.
저장 효율성을 넘어, 이러한 참조들의 메타데이터는 명시적이든 직관적이든 행동을 효율적으로 개선하는 메커니즘을 제공합니다. 파일 시스템에서 작동하는 에이전트에게, tests 폴더에 있는 test_utils.py라는 파일은 src/core_logic/에 있는 같은 이름의 파일과 다른 목적을 암시합니다. 폴더 계층, 이름 규칙, 타임스탬프는 모두 사람과 에이전트 모두가 정보를 언제 어떻게 활용할지 이해하는 데 도움이 되는 중요한 신호를 제공합니다.
에이전트가 자율적으로 데이터를 탐색하고 검색하게 하면 점진적 공개도 가능합니다—다시 말해, 에이전트가 탐색을 통해 관련 컨텍스트를 점진적으로 발견할 수 있습니다. 각 상호작용은 다음 결정에 도움이 되는 컨텍스트를 생성합니다: 파일 크기는 복잡도를 암시하고, 이름 규칙은 목적을 암시하며, 타임스탬프는 관련성의 지표가 될 수 있습니다. 에이전트는 작업 메모리에 필요한 것만 유지하고 추가 지속성을 위해 메모 작성 전략을 활용하면서 계층별로 이해를 구축할 수 있습니다. 이 자체 관리 컨텍스트 윈도우는 에이전트가 방대하지만 관련 없을 수 있는 정보에 빠지지 않고 관련 부분에만 집중하게 합니다.
물론 트레이드오프가 있습니다: 런타임 탐색은 미리 계산된 데이터를 가져오는 것보다 느립니다. 뿐만 아니라, LLM이 정보 환경을 효과적으로 탐색하기 위한 올바른 도구와 휴리스틱을 갖도록 하려면 신중한 엔지니어링이 필요합니다. 적절한 가이드 없이는, 에이전트가 도구를 잘못 사용하거나, 막다른 골목을 쫓거나, 핵심 정보를 놓쳐서 컨텍스트를 낭비할 수 있습니다.
특정 상황에서는, 가장 효과적인 에이전트가 하이브리드 전략을 사용할 수 있습니다. 속도를 위해 일부 데이터는 미리 가져오고, 추가 자율 탐색은 재량에 따라 수행합니다. '적절한' 자율성 수준에 대한 결정 경계는 작업에 따라 다릅니다. Claude Code는 이 하이브리드 모델을 사용하는 에이전트입니다: CLAUDE.md 파일은 처음부터 컨텍스트에 단순히 추가되고, glob과 grep 같은 기본 명령들은 환경을 탐색하고 파일을 적시에 가져올 수 있게 해서, 오래된 인덱싱과 복잡한 구문 트리 문제를 효과적으로 우회합니다.
하이브리드 전략은 법률이나 금융 업무처럼 덜 동적인 콘텐츠를 다루는 상황에 더 적합할 수 있습니다. 모델 능력이 향상됨에 따라, 에이전트 설계는 지능형 모델이 지능적으로 행동하도록 하는 방향으로 나아갈 것이며, 인간의 큐레이션은 점진적으로 줄어들 것입니다. 이 분야의 빠른 발전 속도를 고려할 때, "작동하는 가장 간단한 것을 하라"는 것이 Claude 위에 에이전트를 구축하는 팀들에게 여전히 최고의 조언일 것입니다.
장기 작업을 위한 컨텍스트 엔지니어링
장기 작업은 에이전트가 토큰 수가 LLM의 컨텍스트 윈도우를 초과하는 일련의 행동에서 일관성, 컨텍스트, 목표 지향적 행동을 유지하도록 요구합니다. 대규모 코드베이스 마이그레이션이나 종합 연구 프로젝트처럼 수십 분에서 수 시간에 걸친 연속 작업의 경우, 에이전트는 컨텍스트 윈도우 크기 제한을 우회하기 위한 특수한 기법이 필요합니다.
더 큰 컨텍스트 윈도우를 기다리는 것이 명백한 전략처럼 보일 수 있습니다. 하지만 가까운 미래에는 모든 크기의 컨텍스트 윈도우가 컨텍스트 오염과 정보 관련성 문제에 노출될 가능성이 큽니다—적어도 가장 강력한 에이전트 성능이 요구되는 상황에서는 그렇습니다. 에이전트가 긴 시간 동안 효과적으로 작업할 수 있도록, 우리는 이러한 컨텍스트 오염 제약을 직접 해결하는 몇 가지 기법을 개발했습니다: 압축, 구조화된 메모 작성, 다중 에이전트 아키텍처.
압축
압축은 컨텍스트 윈도우 한계에 근접한 대화를 가져와 그 내용을 요약한 뒤, 요약과 함께 새로운 컨텍스트 윈도우를 다시 시작하는 방법입니다. 압축은 일반적으로 컨텍스트 엔지니어링에서 장기적으로 더 나은 일관성을 이끄는 첫 번째 수단 역할을 합니다. 핵심적으로 압축은 컨텍스트 윈도우의 내용을 높은 정확도로 추출하여 에이전트가 최소한의 성능 저하로 계속 작업할 수 있도록 합니다.
예를 들어 Claude Code에서는 메시지 히스토리를 모델에 전달하여 가장 중요한 세부 사항을 요약하고 압축함으로써 이를 구현합니다. 모델은 아키텍처 결정, 해결되지 않은 버그, 구현 세부사항을 보존하면서 중복된 도구 출력이나 메시지를 버립니다. 그 후 에이전트는 이 압축된 컨텍스트와 최근에 접근한 다섯 개의 파일로 계속 작업할 수 있습니다. 사용자는 컨텍스트 윈도우의 제한에 대해 걱정하지 않고도 연속성을 얻을 수 있습니다.
압축의 기술은 무엇을 남기고 무엇을 버릴지 선택하는 데 있습니다. 지나치게 공격적인 압축은 미묘하지만 중요한 컨텍스트를 잃게 만들 수 있으며, 그 중요성은 나중에야 드러납니다. 압축 시스템을 구현하는 엔지니어라면, 복잡한 에이전트 트레이스에 대해 프롬프트를 신중하게 조정할 것을 권장합니다. 압축 프롬프트가 트레이스에서 모든 관련 정보를 포착하도록 재현율을 극대화하는 것부터 시작하고, 불필요한 내용을 제거하여 정밀도를 향상시키기 위해 반복하세요.
쉽게 제거할 수 있는 불필요한 콘텐츠의 예로는 도구 호출과 결과를 지우는 것이 있습니다. 도구가 메시지 히스토리 깊숙이 호출된 후에는 왜 에이전트가 원본 결과를 다시 볼 필요가 있겠습니까? 가장 안전하고 가벼운 압축 방식 중 하나는 도구 결과 정리로, 최근 Claude 개발자 플랫폼에서 기능으로 출시되었습니다.
구조화된 메모 작성
구조화된 메모 작성, 또는 에이전트 메모리는 에이전트가 컨텍스트 윈도우 밖 메모리에 메모를 정기적으로 작성하여 저장하는 기법입니다. 이 메모들은 나중에 컨텍스트 윈도우로 다시 가져옵니다.
이 전략은 최소한의 오버헤드로 영구 메모리를 제공합니다. Claude Code가 할 일 목록을 만들거나, 맞춤형 에이전트가 NOTES.md 파일을 유지하는 것처럼, 이 간단한 패턴은 에이전트가 복잡한 작업의 진행 상황을 추적할 수 있게 하며, 수십 번의 도구 호출 과정에서 잃어버릴 수 있는 중요한 컨텍스트와 의존성을 유지할 수 있게 합니다.
Claude가 포켓몬을 플레이하는 모습은 메모리가 비코딩 영역에서 에이전트의 능력을 어떻게 변화시키는지 보여줍니다. 에이전트는 수천 개의 게임 단계에 걸쳐 정확한 집계를 유지하며, 예를 들어 "지난 1,234단계 동안 1번 도로에서 포켓몬을 훈련시켰는데, 피카츄가 목표 10레벨을 향해 8레벨 올랐다"와 같은 목표를 추적합니다. 메모리 구조에 대한 별도의 안내 없이도 탐험한 지역의 지도를 만들고, 잠금 해제한 주요 업적을 기억하며, 다양한 적에게 가장 효과적인 공격을 배우는 데 도움이 되는 전투 전략 메모를 유지합니다.
컨텍스트가 리셋된 후, 에이전트는 자신의 메모를 읽고 수 시간에 걸친 훈련 시퀀스나 던전 탐험을 계속합니다. 요약 단계 간의 이러한 일관성 덕분에 LLM의 컨텍스트 윈도우에만 모든 정보를 저장할 때는 불가능한 장기 전략이 가능해집니다.
Sonnet 4.5 출시와 함께, Claude 개발자 플랫폼에서 공개 베타로 메모리 도구를 출시했는데, 이는 파일 기반 시스템을 통해 컨텍스트 윈도우 밖에서 정보를 저장하고 조회하는 것을 더 쉽게 해줍니다. 이를 통해 에이전트는 시간이 지남에 따라 지식 베이스를 구축하고, 세션 간 프로젝트 상태를 유지하며, 모든 것을 컨텍스트에 두지 않고도 이전 작업을 참조할 수 있습니다.
서브 에이전트 아키텍처
서브 에이전트 아키텍처는 컨텍스트 제한을 극복하는 또 다른 방법을 제공합니다. 한 에이전트가 프로젝트 전체에 걸쳐 상태를 유지하려 애쓰는 대신, 특화된 서브 에이전트가 깨끗한 컨텍스트 윈도우로 집중된 작업을 처리할 수 있습니다. 메인 에이전트는 고수준 계획으로 조율하며, 서브 에이전트들은 심층 기술 작업을 수행하거나 도구를 사용해 관련 정보를 찾습니다. 각 서브 에이전트는 수만 개 이상의 토큰을 광범위하게 탐색할 수 있지만, 결과는 자신의 작업에 대한 압축되고 정제된 요약(보통 1,000-2,000개 토큰)만 반환합니다.
이 접근법은 관심사를 명확히 분리합니다. 상세한 검색 컨텍스트는 서브 에이전트 내에서 격리되고, 리드 에이전트는 결과를 종합하고 분석하는 데 집중합니다. 이 패턴은 '다중 에이전트 연구 시스템을 구축한 방법'에서 논의되었으며, 복잡한 연구 작업에서 단일 에이전트 시스템에 비해 상당한 개선을 보였습니다.
이 접근법들 중 선택은 작업 특성에 따라 달라집니다. 예를 들어:
압축은 광범위한 주고받기가 필요한 작업에서 대화 흐름을 유지합니다;
메모 작성은 명확한 이정표가 있는 반복적 개발에 탁월합니다;
다중 에이전트 아키텍처는 병렬 탐색이 큰 효과를 내는 복잡한 연구와 분석을 처리합니다.
모델이 계속 개선되더라도, 장기간 상호작용에서 일관성을 유지하는 과제는 더 효과적인 에이전트를 구축하는 데 여전히 핵심적으로 남을 것입니다.
결론
컨텍스트 엔지니어링은 LLM으로 구축하는 방식에 근본적인 변화를 나타냅니다. 모델이 더 유능해질수록, 과제는 단순히 완벽한 프롬프트를 만드는 것이 아니라 각 단계에서 모델의 제한된 어텐션 예산에 어떤 정보가 들어가는지 신중하게 선별하는 것입니다. 장기 작업을 위한 압축을 구현하든, 토큰 효율적인 도구를 설계하든, 에이전트가 환경을 적시에 탐색할 수 있도록 하든, 핵심 원칙은 동일합니다: 원하는 결과의 가능성을 최대화하는 가장 작은 고신호 토큰 집합을 찾는 것입니다.
우리가 설명한 기법들은 모델이 개선됨에 따라 계속 진화할 것입니다. 이미 더 똑똑한 모델이 덜 세세한 엔지니어링을 필요로 하여 에이전트가 더 많은 자율성으로 작동할 수 있게 되는 것을 보고 있습니다. 하지만 능력이 확장되더라도, 컨텍스트를 귀중하고 유한한 자원으로 다루는 것은 신뢰할 수 있고 효과적인 에이전트를 구축하는 데 여전히 핵심으로 남을 것입니다.
오늘 Claude 개발자 플랫폼에서 컨텍스트 엔지니어링을 시작하고, 메모리 및 컨텍스트 관리 쿡북을 통해 유용한 팁과 모범 사례를 확인하세요.
감사의 말
Anthropic의 응용 AI 팀인 프리트비 라자세카란, 이선 딕슨, 칼리 라이언, 제레미 해드필드가 작성했으며, 팀원인 라피 아유브, 한나 모란, 칼 루브, 코너 제닝스가 기여했습니다. 몰리 보르베르크, 스튜어트 리치, 매기 보에게 특별히 감사드립니다.
출처: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents