AI 에이전트를 위한 효과적인 컨텍스트 엔지니어링
TMThttps://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
컨텍스트는 AI 에이전트를 위한 중요하지만 유한한 자원입니다. 이 글에서는 이를 구동하는 컨텍스트를 효과적으로 선별·관리하는 전략을 탐구합니다.
몇 년간 적용형 AI에서 프롬프트 엔지니어링이 주목을 받아온 후, 새로운 용어가 부상했습니다: 컨텍스트 엔지니어링. 이제 언어 모델로 빌드하는 일은 프롬프트에 적절한 단어와 문구를 찾는 것에서 벗어나, “어떤 컨텍스트 구성(configuration)이 우리 모델의 원하는 행동을 가장 잘 생성하는가?”라는 더 넓은 질문에 답하는 쪽으로 이동하고 있습니다.
컨텍스트는 대규모 언어 모델(LLM)로 샘플링할 때 포함되는 토큰의 집합을 의미합니다. 여기에 있는 엔지니어링 문제는 원하는 결과를 지속적으로 달성하기 위해 LLM의 고유 제약에 맞서 그 토큰들의 효용을 최적화하는 것입니다. LLM을 효과적으로 다루려면 종종 맥락 속에서 사고(thinking in context)가 필요합니다—즉, 어느 순간 LLM이 이용 가능한 총체적 상태를 고려하고 그 상태가 어떤 잠재적 행동을 산출할 수 있는지 생각하는 것입니다.
이 글에서는 떠오르는 컨텍스트 엔지니어링의 기예를 살펴보고, 조종 가능하고 효과적인 에이전트를 빌드하기 위한 정제된 멘탈 모델을 제시합니다.
컨텍스트 엔지니어링 vs. 프롬프트 엔지니어링
Anthropic에서는 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 자연스러운 진화로 봅니다. 프롬프트 엔지니어링은 최적의 결과를 위한 LLM 지시문을 작성하고 구성하는 방법을 의미합니다(개요와 유용한 프롬프트 엔지니어링 전략은 문서 참조). 컨텍스트 엔지니어링은 프롬프트 외에 컨텍스트에 들어올 수 있는 모든 정보를 포함하여, LLM 추론 중 최적의 토큰(정보) 집합을 선별·유지하기 위한 전략들의 집합을 의미합니다.
LLM 엔지니어링의 초기에는, 일상적인 채팅 상호작용 외의 대부분의 사용 사례가 원샷 분류나 텍스트 생성 작업을 위해 최적화된 프롬프트를 필요로 했기 때문에 프롬프트가 AI 엔지니어링 작업의 가장 큰 구성 요소였습니다. 용어가 암시하듯 프롬프트 엔지니어링의 주요 초점은 특히 시스템 프롬프트를 어떻게 효과적으로 작성할지에 맞춰져 있습니다. 그러나 여러 번의 추론과 더 긴 시간 지평에서 작동하는 더 유능한 에이전트를 엔지니어링하는 방향으로 이동함에 따라, 전체 컨텍스트 상태(시스템 지시문, 도구, Model Context Protocol (MCP), 외부 데이터, 메시지 히스토리 등)를 관리하기 위한 전략이 필요합니다.
루프에서 실행되는 에이전트는 다음 추론 턴에 관련될 수 있는 더 많고 많은 데이터를 생성하며, 이 정보는 순환적으로 정제되어야 합니다. 컨텍스트 엔지니어링은 끊임없이 진화하는 잠재적 정보의 우주로부터 제한된 컨텍스트 윈도우에 무엇을 넣을지 선별하는 예술과 과학입니다.
프롬프트 작성이라는 이산적 작업과 달리, 컨텍스트 엔지니어링은 반복적이며 모델에 무엇을 전달할지 매번 결정할 때마다 선별 단계가 발생합니다.
왜 컨텍스트 엔지니어링이 유능한 에이전트 구축에 중요한가
속도가 빠르고 더 큰 데이터 볼륨을 다룰 수 있음에도 불구하고, 우리는 LLM이 인간과 마찬가지로 어느 지점에서 집중력을 잃거나 혼란을 겪는다는 것을 관찰했습니다. 바늘-짚더미__형 벤치마킹 연구는 컨텍스트 부패(context rot) 개념을 밝혀냈습니다: 컨텍스트 윈도우의 토큰 수가 증가할수록, 모델이 그 컨텍스트에서 정보를 정확히 회상하는 능력은 감소합니다.
일부 모델은 다른 모델보다 더 완만한 성능 저하를 보이지만, 이 특성은 모든 모델에서 나타납니다. 따라서 컨텍스트는 체감효용이 감소하는 유한한 자원으로 다뤄져야 합니다. 인간이 제한된 작업 기억 용량을 갖듯, LLM도 많은 양의 컨텍스트를 파싱할 때 끌어 쓰는 “주의 예산”이 있습니다. 도입되는 모든 새로운 토큰은 이 예산을 일정량 고갈시키며, LLM에게 제공할 토큰을 신중하게 선별해야 할 필요를 증가시킵니다.
이러한 주의력의 희소성은 LLM의 구조적 제약에서 비롯됩니다. LLM은 트랜스포머 아키텍처를 기반으로 하며, 이는 모든 토큰이 전체 컨텍스트에 걸쳐 다른 모든 토큰에 어텐션할 수 있게 합니다. 이는 n개의 토큰에 대해 n² 개의 쌍 관계를 초래합니다.
컨텍스트 길이가 증가함에 따라, 모델이 이러한 쌍 관계를 포착하는 능력은 얇게 늘어나며, 컨텍스트 크기와 주의 집중 사이에 자연스러운 긴장이 생깁니다. 또한 모델은 일반적으로 짧은 시퀀스가 긴 시퀀스보다 더 흔한 학습 데이터 분포에서 주의 패턴을 발달시킵니다. 이는 모델이 컨텍스트 전반의 의존성에 대해 덜 많은 경험과 더 적은 특화된 파라미터를 갖는다는 것을 의미합니다.
포지션 인코딩 보간(position encoding interpolation)과 같은 기법은 모델이 원래 더 작은 컨텍스트로 학습된 것을 더 긴 시퀀스에 맞게 적응시켜 처리하도록 하며, 토큰 위치 이해에서 약간의 저하가 있을 수 있습니다. 이러한 요인들은 급격한 성능 절벽이 아니라 성능 구배를 만듭니다: 모델은 더 긴 컨텍스트에서도 매우 유능하지만, 더 짧은 컨텍스트 대비 정보 검색과 장거리 추론의 정밀도가 낮아질 수 있습니다.
이러한 현실은 유능한 에이전트를 구축하기 위해 사려 깊은 컨텍스트 엔지니어링이 필수적임을 의미합니다.
효과적인 컨텍스트의 해부
LLM이 유한한 주의 예산에 제약받는다는 점을 고려할 때, 좋은 컨텍스트 엔지니어링은 원하는 결과의 가능성을 최대화하는 가능한 한 작은 고신호 토큰 집합을 찾는 것입니다. 이를 구현하는 실천은 말처럼 쉽지 않지만, 다음 섹션에서는 컨텍스트의 다양한 구성 요소에 걸쳐 이 지침 원칙이 실무에서 무엇을 의미하는지 설명합니다.
시스템 프롬프트는 매우 명확해야 하며, 에이전트에 대해 _적절한 고도_에서 아이디어를 제시하는 단순하고 직접적인 언어를 사용해야 합니다. 적절한 고도란 두 가지 일반적인 실패 모드 사이의 골디락스 존입니다. 한 극단에서는 엔지니어가 프롬프트에 복잡하고 취약한 로직을 하드코딩하여 정확한 에이전트 행동을 이끌어내려는 시도를 봅니다. 이 접근은 시간이 지남에 따라 취약성을 만들고 유지 관리 복잡성을 증가시킵니다. 다른 극단에서는 엔지니어가 LLM에게 원하는 출력에 대한 구체적인 신호를 주지 못하거나 공유된 컨텍스트를 잘못 가정하는 모호하고 상위 수준의 지침을 제공하기도 합니다. 최적의 고도는 균형을 이룹니다: 행동을 효과적으로 안내할 만큼 충분히 구체적이면서도, 모델에게 강한 휴리스틱을 제공해 행동을 유도할 수 있을 만큼 유연합니다.
한쪽 끝에는 취약한 if-else 하드코딩 프롬프트가 있고, 다른 쪽 끝에는 지나치게 일반적이거나 공유된 컨텍스트를 잘못 가정하는 프롬프트가 있습니다.
프롬프트를 <background_information>, <instructions>, ## Tool guidance, ## Output description 등과 같은 구분된 섹션으로 구성하고, 이러한 섹션을 구분하기 위해 XML 태깅이나 마크다운 헤더 같은 기법을 사용하는 것을 권장합니다. 다만 모델이 더 유능해짐에 따라 프롬프트의 정확한 서식은 점차 덜 중요해질 가능성이 있습니다.
시스템 프롬프트를 어떻게 구성하든, 기대하는 행동을 완전히 개괄하는 최소 정보 집합을 지향해야 합니다(최소가 반드시 짧음을 의미하지는 않습니다; 원하는 행동을 보장하기 위해 충분한 정보를 먼저 제공해야 합니다). 가장 좋은 방법은 최고의 모델로 최소 프롬프트를 테스트하며 작업에서 어떻게 성능을 내는지 확인하고, 초기 테스트에서 발견된 실패 모드에 기반해 명확한 지시와 예시를 추가하여 성능을 개선하는 것입니다.
도구는 에이전트가 환경에서 작동하고 작업하면서 새로운 추가 컨텍스트를 가져올 수 있게 합니다. 도구는 에이전트와 그 정보/행동 공간 사이의 계약을 정의하기 때문에, 도구가 토큰 효율적인 정보를 반환하고 효율적인 에이전트 행동을 장려하도록 하는 것이 매우 중요합니다.
Writing tools for AI agents – with AI agents에서는 LLM이 잘 이해할 수 있고 기능 중복이 최소화된 도구를 구축하는 방법을 논의했습니다. 잘 설계된 코드베이스의 함수와 유사하게, 도구는 자체 완결적이며, 오류에 강하고, 의도된 사용에 대해 매우 분명해야 합니다. 입력 매개변수 또한 서술적이고 모호하지 않으며, 모델의 고유한 강점을 살려야 합니다.
우리가 가장 흔히 보는 실패 모드 중 하나는 기능을 너무 많이 포괄하거나 어떤 도구를 사용할지에 대한 모호한 의사결정 지점을 초래하는 비대해진 도구 집합입니다. 인간 엔지니어가 특정 상황에서 어떤 도구를 사용해야 할지 단정적으로 말할 수 없다면, AI 에이전트가 더 잘할 것이라 기대할 수 없습니다. 이후에 논의하겠지만, 에이전트에게 최소 실행 가능한 도구 집합을 선별하는 것은 장시간 상호작용에서 컨텍스트 유지 관리와 가지치기를 더 신뢰성 있게 만드는 데도 도움이 됩니다.
예시 제공, 즉 퓨샷 프롬프트는 잘 알려진 모범 사례이며 계속해서 강력히 권장합니다. 그러나 팀은 종종 특정 작업에서 LLM이 따라야 할 모든 가능한 규칙을 설명하려고 프롬프트에 온갖 엣지 케이스 목록을 집어넣습니다. 우리는 이를 권장하지 않습니다. 대신, 에이전트의 기대 행동을 효과적으로 보여주는 다양한 정전(canonical) 예시 집합을 선별하는 데 힘쓰는 것을 권합니다. LLM에게 예시는 말 그대로 “천 마디 말보다 값진 그림”입니다.
컨텍스트의 다양한 구성 요소(시스템 프롬프트, 도구, 예시, 메시지 히스토리 등) 전반에 걸친 우리의 전체 가이던스는 사려 깊고, 컨텍스트를 정보성 있게 유지하되 타이트하게 유지하는 것입니다. 이제 런타임에서 동적으로 컨텍스트를 검색하는 방법을 살펴보겠습니다.
컨텍스트 검색과 에이전틱 서치
Building effective AI agents에서 우리는 LLM 기반 워크플로와 에이전트의 차이를 강조했습니다. 그 글 이후, 우리는 에이전트를 위한 간단한 정의에 점점 더 기울었습니다: 도구를 루프에서 자율적으로 사용하는 LLM.
고객과 함께 일하면서 우리는 현장이 이 간단한 패러다임으로 수렴하고 있음을 보았습니다. 기본 모델이 더 유능해짐에 따라 에이전트의 자율성 수준은 확장될 수 있습니다: 더 똑똑한 모델은 에이전트가 미묘한 문제 공간을 독립적으로 탐색하고 오류에서 회복하게 합니다.
이제 엔지니어들이 에이전트를 위한 컨텍스트 설계 방식을 바꾸는 것을 보고 있습니다. 오늘날 많은 AI-네이티브 애플리케이션은 에이전트가 추론할 중요한 컨텍스트를 표면화하기 위해 사전-추론 시간 임베딩 기반 검색을 어느 정도 채택합니다. 현장이 더 에이전틱한 접근으로 전환함에 따라, 우리는 점점 더 팀들이 이러한 검색 시스템을 “적시(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 위에 에이전트를 빌드하는 팀에게 계속해서 최선의 조언이 될 가능성이 큽니다.
장기 지평 작업을 위한 컨텍스트 엔지니어링
장기 지평 작업은 토큰 수가 LLM의 컨텍스트 윈도우를 초과하는 행동 시퀀스를 통해 일관성, 컨텍스트, 목표 지향적 행동을 유지해야 합니다. 대규모 코드베이스 마이그레이션이나 포괄적 연구 프로젝트처럼 수십 분에서 수 시간에 걸친 연속 작업에는, 컨텍스트 윈도우 크기 제한을 우회하기 위한 특화된 기법이 필요합니다.
더 큰 컨텍스트 윈도우를 기다리는 것이 명백한 전술로 보일 수 있습니다. 그러나 당분간은 모든 크기의 컨텍스트 윈도우가—최강의 에이전트 성능이 요구되는 상황에서는—컨텍스트 오염과 정보 관련성 문제의 영향을 받을 가능성이 큽니다. 확장된 시간 지평에 걸쳐 에이전트가 효과적으로 작동하도록 하기 위해, 우리는 이러한 컨텍스트 오염 제약을 직접 해결하는 몇 가지 기법을 개발했습니다: 압축(compaction), 구조화된 노트 테이킹, 다중 에이전트 아키텍처.
압축(compaction)
압축은 컨텍스트 윈도우 한계에 가까워진 대화를 요약해 그 내용을 담고, 요약으로 새로운 컨텍스트 윈도우를 재개하는 실천입니다. 압축은 일반적으로 더 나은 장기 일관성을 이끌어내기 위한 컨텍스트 엔지니어링의 첫 번째 레버 역할을 합니다. 그 핵심은 컨텍스트 윈도우의 내용을 높은 충실도로 증류하여, 에이전트가 최소의 성능 저하로 계속 진행할 수 있게 하는 것입니다.
예를 들어 Claude Code에서는 메시지 히스토리를 모델에 전달해 가장 중요한 세부사항을 요약·압축하도록 구현합니다. 모델은 아키텍처 결정, 미해결 버그, 구현 세부사항을 보존하면서, 중복된 도구 출력이나 메시지는 제거합니다. 그 후 에이전트는 이 압축된 컨텍스트와 가장 최근에 접근한 다섯 개 파일을 함께 사용해 계속 진행합니다. 사용자는 컨텍스트 윈도우 제한을 걱정하지 않고도 연속성을 얻습니다.
압축의 예술은 무엇을 유지하고 무엇을 버릴지의 선택에 있습니다. 지나치게 공격적인 압축은 나중에 중요성이 드러나는 미묘하지만 중요한 컨텍스트를 잃게 만들 수 있습니다. 압축 시스템을 구현하는 엔지니어에게는, 복잡한 에이전트 트레이스에 대해 프롬프트를 신중히 튜닝할 것을 권합니다. 먼저 리콜을 최대화하여 압축 프롬프트가 트레이스에서 모든 관련 정보를 포착하게 하고, 이후 잉여 내용을 제거해 정밀도를 개선하도록 반복하세요.
낮은 노력으로 제거 가능한 잉여 콘텐츠의 예는 도구 호출과 결과를 청소하는 것입니다—한 번 도구가 메시지 히스토리 깊은 곳에서 호출되었다면, 왜 에이전트가 그 원시 결과를 다시 볼 필요가 있겠습니까? 가장 안전하고 가벼운 형태의 압축 중 하나는 도구 결과 청소이며, 최근 Claude Developer Platform의 기능으로 출시되었습니다.
구조화된 노트 테이킹
구조화된 노트 테이킹, 또는 에이전틱 메모리는 에이전트가 컨텍스트 윈도우 밖에 지속되는 메모리에 정기적으로 노트를 작성하는 기법입니다. 이러한 노트는 이후 컨텍스트 윈도우로 다시 가져옵니다.
이 전략은 최소 오버헤드로 지속 메모리를 제공합니다. Claude Code가 할 일 목록을 만드는 것처럼, 또는 당신의 커스텀 에이전트가 NOTES.md 파일을 유지하는 것처럼, 이 단순한 패턴은 에이전트가 복잡한 작업 전반에서 진행 상황을 추적하도록 하며, 수십 개의 도구 호출에 걸쳐 그렇지 않으면 잃어버릴 중요한 컨텍스트와 의존성을 유지하게 합니다.
Claude playing Pokémon은 메모리가 비코딩 도메인에서 에이전트 능력을 어떻게 변모시키는지 보여줍니다. 에이전트는 수천 개 게임 단계에 걸쳐 정밀한 집계를 유지합니다—“지난 1,234 단계 동안 Route 1에서 내 포켓몬을 훈련해왔고, 피카츄는 목표 10 레벨을 향해 8 레벨을 올렸다” 같은 목표를 추적합니다. 메모리 구조에 대한 프롬프트 없이도, 탐색한 지역의 지도를 개발하고, 어떤 핵심 업적을 잠금 해제했는지 기억하며, 서로 다른 상대에게 어떤 공격이 가장 잘 통하는지를 학습하는 데 도움이 되는 전투 전략의 전략적 노트를 유지합니다.
컨텍스트가 재설정된 후에도, 에이전트는 자신의 노트를 읽고 수시간에 걸친 훈련 시퀀스나 던전 탐험을 계속합니다. 이러한 요약 단계 전반의 일관성은 LLM의 컨텍스트 윈도우만으로는 불가능한 장기 지평 전략을 가능하게 합니다.
Sonnet 4.5 출시의 일환으로, 우리는 Claude Developer Platform에서 컨텍스트 윈도우 밖의 정보를 파일 기반 시스템을 통해 더 쉽게 저장·조회할 수 있게 해주는 메모리 도구를 공개 베타로 출시했습니다. 이는 에이전트가 시간에 따라 지식 베이스를 구축하고, 세션 간에 프로젝트 상태를 유지하며, 모든 것을 컨텍스트에 유지하지 않고도 이전 작업을 참조할 수 있게 합니다.
서브-에이전트 아키텍처
서브-에이전트 아키텍처는 컨텍스트 제한을 우회하는 또 다른 방법을 제공합니다. 하나의 에이전트가 전체 프로젝트에 걸친 상태를 유지하려 애쓰는 대신, 특화된 서브-에이전트가 깨끗한 컨텍스트 윈도우로 집중된 작업을 처리합니다. 메인 에이전트는 상위 수준 계획으로 조정하고, 서브에이전트는 심층 기술 작업을 수행하거나 도구를 사용해 관련 정보를 찾습니다. 각 서브에이전트는 광범위하게 탐색할 수 있으며, 수만 토큰 이상을 사용할 수 있지만, 자신의 작업을 응축·증류한 요약(종종 1,000–2,000 토큰)을 반환합니다.
이 접근은 관심사의 분리를 명확히 달성합니다—세부 검색 컨텍스트는 서브-에이전트 내에 격리되고, 리드 에이전트는 결과의 종합과 분석에 집중합니다. How we built our multi-agent research system에서 논의된 이 패턴은 복잡한 연구 작업에서 단일 에이전트 시스템 대비 상당한 개선을 보였습니다.
이들 접근 사이의 선택은 작업 특성에 따라 달라집니다. 예를 들어:
- 압축은 광범위한 상호작용을 요구하는 작업에서 대화 흐름을 유지합니다;
- 노트 테이킹은 명확한 이정표가 있는 반복적 개발에서 탁월합니다;
- 다중 에이전트 아키텍처는 병렬 탐색이 수익을 내는 복잡한 연구와 분석을 처리합니다.
모델이 계속 개선되더라도, 확장된 상호작용 전반의 일관성을 유지하는 과제는 더 효과적인 에이전트를 구축하는 데 여전히 중심이 될 것입니다.
결론
컨텍스트 엔지니어링은 LLM으로 빌드하는 방식을 근본적으로 전환합니다. 모델이 더 유능해짐에 따라, 과제는 완벽한 프롬프트를 만드는 것만이 아닙니다—매 단계에서 모델의 제한된 주의 예산에 어떤 정보가 들어가는지를 사려 깊게 선별하는 것입니다. 장기 지평 작업을 위한 압축을 구현하든, 토큰 효율적인 도구를 설계하든, 에이전트가 환경을 적시에 탐색하도록 하든, 지침 원칙은 동일합니다: 원하는 결과의 가능성을 최대화하는 가장 작은 고신호 토큰 집합을 찾으세요.
우리가 개요한 기법들은 모델이 개선됨에 따라 계속 진화할 것입니다. 이미 더 똑똑한 모델은 덜 규정적인 엔지니어링을 요구하며, 에이전트가 더 많은 자율성으로 작동하게 합니다. 그러나 능력이 확장되더라도, 컨텍스트를 소중하고 유한한 자원으로 취급하는 것은 신뢰할 수 있고 효과적인 에이전트를 구축하는 데 여전히 중심에 남을 것입니다.
Claude Developer Platform에서 컨텍스트 엔지니어링을 시작하고, 우리의 memory and context management 요리책을 통해 유용한 팁과 모범 사례에 접근하세요.