프롬프트 엔지니어링을 넘어, 에이전트가 원하는 행동을 하도록 매 단계에서 어떤 정보를 컨텍스트에 넣고 유지할지 설계·운영하는 컨텍스트 엔지니어링의 핵심 개념과 실전 기법을 정리한다.
URL: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
적용 AI에서 몇 년간 프롬프트 엔지니어링이 주목의 중심이었던 이후, 이제는 새로운 용어가 부상하고 있습니다. 바로 컨텍스트 엔지니어링(context engineering) 입니다. 언어 모델로 무언가를 만드는 일은 점점 “프롬프트에 어떤 단어와 문구를 써야 하지?”보다는, 더 넓은 질문인 “어떤 컨텍스트 구성이 모델이 우리가 원하는 행동을 생성하도록 할 가능성이 가장 높은가?”를 답하는 쪽으로 이동하고 있습니다.
컨텍스트(context) 는 대규모 언어 모델(LLM)에서 샘플링할 때 포함되는 토큰들의 집합을 의미합니다. 여기서 엔지니어링 문제란, 원하는 결과를 꾸준히 얻기 위해 LLM의 내재적 제약 속에서 토큰들의 효용을 최적화하는 것입니다. LLM을 효과적으로 다루려면 종종 컨텍스트 관점으로 사고하기(thinking in context) 가 필요합니다. 즉, 어떤 순간에 LLM이 사용할 수 있는 전체 상태를 총체적으로 고려하고, 그 상태가 어떤 잠재적 행동을 낳을 수 있는지 생각하는 것입니다.
이 글에서는 컨텍스트 엔지니어링이라는 새롭게 떠오르는 기술적/실무적 ‘예술’의 핵심을 살펴보고, 조향 가능(steerable)하고 효과적인 에이전트를 구축하기 위한 더 정교한 멘탈 모델을 제시합니다.
Anthropic에서는 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 자연스러운 발전으로 봅니다. 프롬프트 엔지니어링은 최적의 결과를 위해 LLM 지시문을 작성하고 조직하는 방법을 뜻합니다(개요와 유용한 전략은 문서 참고). 반면 컨텍스트 엔지니어링은 LLM 추론 시점에 (정보) 토큰의 최적 집합을 선별·유지하기 위한 전략들의 집합이며, 프롬프트 외에도 그 안으로 유입될 수 있는 모든 정보를 포함합니다.
LLM을 활용한 엔지니어링의 초기에는, 일상적 채팅을 제외한 대부분의 유스케이스가 원샷(one-shot) 분류나 텍스트 생성처럼 프롬프트 최적화가 핵심인 작업이었기에, 프롬프트 작성이 AI 엔지니어링 업무의 가장 큰 비중을 차지했습니다. 프롬프트 엔지니어링의 주된 관심사는 특히 시스템 프롬프트를 포함해 “효과적인 프롬프트를 어떻게 쓰는가”였습니다. 하지만 여러 턴에 걸쳐 추론을 반복하고 더 긴 시간 지평에서 동작하는 더 유능한 에이전트를 설계하는 방향으로 나아가면서, 우리는 전체 컨텍스트 상태(시스템 지시문, 도구, Model Context Protocol(MCP), 외부 데이터, 메시지 히스토리 등)를 관리하는 전략이 필요해졌습니다.
루프에서 실행되는 에이전트는 다음 턴의 추론에 관련될 수 있는 데이터들을 점점 더 많이 만들어냅니다. 이 정보는 주기적으로 정제되어야 합니다. 컨텍스트 엔지니어링은, 끊임없이 진화하는 가능한 정보의 우주로부터 제한된 컨텍스트 윈도우 안에 무엇을 넣을지를 선별하는 예술이자 과학입니다.
프롬프트를 쓰는 ‘이산적’ 작업과 달리, 컨텍스트 엔지니어링은 반복적이며, 모델에 무엇을 전달할지 결정하는 매번 선별 단계가 발생합니다.
LLM은 속도가 빠르고 점점 더 큰 데이터도 다룰 수 있게 되었지만, 관찰해보면 인간처럼 어느 지점에서는 집중력이 떨어지거나 혼란을 겪습니다. 바늘 찾기(needle-in-a-haystack) 유형의 벤치마킹 연구는 컨텍스트 부패(context rot)라는 개념을 밝혀냈습니다. 컨텍스트 윈도우에 포함된 토큰 수가 증가할수록, 모델이 해당 컨텍스트에서 정보를 정확히 회상하는 능력이 감소한다는 것입니다.
어떤 모델은 완만히 성능이 저하되기도 하지만, 이 특성은 모든 모델에서 나타납니다. 따라서 컨텍스트는 한계가 있는 자원이며, 한 토큰을 더 추가할 때 얻는 한계 효용은 점점 줄어드는 것으로 다뤄야 합니다. 작업 기억 용량이 제한된 인간처럼, LLM도 대량의 컨텍스트를 파싱할 때 소모하는 “어텐션 예산(attention budget)”이 있습니다. 새 토큰이 들어올 때마다 이 예산이 일정량 소진되므로, LLM이 사용할 수 있는 토큰을 신중하게 선별해야 할 필요가 커집니다.
이러한 어텐션 희소성은 LLM의 아키텍처 제약에서 비롯됩니다. LLM은 트랜스포머 아키텍처를 기반으로 하며, 이는 전체 컨텍스트에서 각 토큰이 다른 모든 토큰에 어텐션을 줄 수 있게 합니다. 그 결과, 토큰이 n개일 때 n²개의 쌍대 관계(pairwise relationships)가 발생합니다.
컨텍스트 길이가 늘어날수록 모델이 이런 쌍대 관계를 포착하는 능력은 얇게(희석되어) 퍼지게 되며, 컨텍스트 크기와 어텐션 집중 사이의 자연스러운 긴장이 생깁니다. 또한 모델은 학습 데이터 분포로부터 어텐션 패턴을 형성하는데, 일반적으로 긴 시퀀스보다 짧은 시퀀스가 더 흔합니다. 즉 모델은 긴 컨텍스트 전반에 걸친 의존성을 다루는 경험이 상대적으로 적고, 그에 특화된 파라미터도 적습니다.
Position encoding interpolation 같은 기법은, 원래 더 작은 컨텍스트로 학습된 모델이 더 긴 시퀀스를 처리하도록 적응시키지만 토큰 위치 이해에서 일부 저하가 발생할 수 있습니다. 이런 요인들은 ‘급격한 절벽’이라기보다 ‘성능 기울기(gradient)’를 만들어냅니다. 즉, 모델은 긴 컨텍스트에서도 여전히 매우 유능하지만, 짧은 컨텍스트에서의 성능과 비교하면 정보 검색이나 장거리 추론에서 정밀도가 떨어질 수 있습니다.
이러한 현실 때문에, 유능한 에이전트를 만들기 위해서는 사려 깊은 컨텍스트 엔지니어링이 필수입니다.
LLM이 유한한 어텐션 예산에 의해 제한된다면, 좋은 컨텍스트 엔지니어링이란 원하는 결과가 나올 가능성을 최대화하는 신호가 강한(high-signal) 토큰들의 집합을 가능한 한 작게 찾는 것을 뜻합니다. 이를 구현하기는 말처럼 쉽지 않지만, 이 섹션에서는 컨텍스트의 구성 요소별로 이 원칙이 실무에서 무엇을 의미하는지 정리합니다.
시스템 프롬프트는 매우 명확해야 하며, 에이전트에게 적절한 고도(altitude) 에서 아이디어를 제시하는 단순하고 직접적인 언어를 사용해야 합니다. 적절한 고도란 두 가지 흔한 실패 모드 사이의 ‘골디락스 존’입니다. 한쪽 극단에서는 엔지니어가 프롬프트에 복잡하고 취약한 로직을 하드코딩하여 정확한 에이전트 행동을 유도하려는 경우가 있습니다. 이는 취약성을 만들고 시간이 지날수록 유지보수 복잡도를 증가시킵니다. 다른 극단에서는 너무 모호하고 고수준의 가이드를 제공해 LLM이 원하는 출력에 대한 구체적 신호를 얻지 못하거나, 공유 컨텍스트가 있다고 잘못 가정하는 경우가 있습니다. 최적의 고도는 균형을 잡습니다. 행동을 효과적으로 안내할 만큼 구체적이되, 강한 휴리스틱을 제공하면서도 유연하게 작동할 만큼 일반적이어야 합니다.
스펙트럼 한쪽에는 if-else로 하드코딩된 취약한 프롬프트가 있고, 다른 한쪽에는 지나치게 일반적이거나 공유 컨텍스트를 잘못 가정하는 프롬프트가 있습니다.
프롬프트를 <background_information>, <instructions>, ## Tool guidance, ## Output description 같은 구획으로 나누고, XML 태그나 Markdown 헤더 같은 기법으로 경계를 표시하길 권장합니다. 다만 모델이 더 유능해지면서 프롬프트의 정확한 포맷 중요도는 점점 낮아지는 추세입니다.
시스템 프롬프트를 어떤 구조로 잡든, 기대 행동을 온전히 설명하는 데 필요한 정보의 최소 집합을 목표로 해야 합니다. (여기서 ‘최소’가 반드시 ‘짧음’을 뜻하진 않습니다. 원하는 행동을 따르도록 하기에 충분한 정보를 선제적으로 제공해야 합니다.) 가장 좋은 방법은 사용 가능한 최고 성능 모델로 최소 프롬프트를 먼저 테스트해 과제에서의 동작을 보고, 초기 테스트에서 발견한 실패 모드에 따라 명확한 지시와 예시를 추가하여 성능을 개선해 나가는 것입니다.
도구(tools) 는 에이전트가 환경과 상호작용하고 작업 중에 새롭고 추가적인 컨텍스트를 가져오게 해줍니다. 도구는 에이전트와 정보/행동 공간 사이의 계약을 정의하므로, 도구가 효율성을 촉진하는 것이 매우 중요합니다. 즉, (1) 반환하는 정보가 토큰 효율적이어야 하고, (2) 에이전트의 효율적 행동을 유도해야 합니다.
AI 에이전트를 위한 도구 작성 – AI 에이전트와 함께에서는 LLM이 잘 이해하고 기능 중복이 최소인 도구를 만드는 방법을 다뤘습니다. 잘 설계된 코드베이스의 함수처럼, 도구는 자기완결적이고 오류에 강하며, 의도된 사용 방식이 매우 명확해야 합니다. 입력 파라미터 역시 설명적이고 모호하지 않아야 하며, 모델의 고유한 강점을 살리는 방식이어야 합니다.
우리가 자주 보는 실패 모드 중 하나는, 기능 범위를 과도하게 포괄하거나 어떤 상황에서 어떤 도구를 써야 하는지 애매한 의사결정 지점을 만드는 비대해진 도구 세트입니다. 인간 엔지니어가 특정 상황에서 어떤 도구를 써야 하는지 단정할 수 없다면, AI 에이전트가 더 잘할 것이라 기대할 수 없습니다. 또한 뒤에서 설명하겠지만, 에이전트에 필요한 최소 기능 도구 세트를 선별하면 긴 상호작용 동안 컨텍스트 유지/가지치기도 더 안정적으로 할 수 있습니다.
예시 제공(일명 few-shot prompting)은 널리 알려진 모범 사례로, 우리는 여전히 강력히 권장합니다. 하지만 팀들이 어떤 작업에서 LLM이 따라야 할 가능한 모든 규칙을 말로 적어내려는 시도로, 프롬프트에 엣지 케이스 목록을 잔뜩 집어넣는 경우가 종종 있습니다. 우리는 이를 권장하지 않습니다. 대신, 에이전트가 기대하는 행동을 효과적으로 보여주는 다양하고 정형화된(canonical) 예시 세트를 선별하는 데 집중하길 권합니다. LLM에게 예시는 “천 마디 말보다 값진 그림”입니다.
컨텍스트의 여러 구성 요소(시스템 프롬프트, 도구, 예시, 메시지 히스토리 등)에 대한 전반적 가이드는 다음과 같습니다. 신중하게, 그리고 정보량은 유지하되 군더더기 없이(tight) 컨텍스트를 구성하세요. 이제 런타임에서 컨텍스트를 동적으로 가져오는 방법으로 들어가 보겠습니다.
효과적인 AI 에이전트 구축에서 우리는 LLM 기반 워크플로와 에이전트의 차이를 강조했습니다. 그 글을 쓴 이후, 우리는 에이전트에 대한 단순한 정의로 수렴해 왔습니다. 즉, LLM이 루프 안에서 자율적으로 도구를 사용하는 것입니다.
고객과 함께 일하며, 우리는 업계가 이 단순한 패러다임으로 수렴하는 것을 보았습니다. 기반 모델이 더 유능해질수록, 에이전트의 자율성 수준은 확장될 수 있습니다. 더 똑똑한 모델은 더 미묘한 문제 공간을 스스로 탐색하고 오류에서 회복할 수 있게 합니다.
또한 에이전트를 위한 컨텍스트를 설계하는 방식에서도 변화가 일어나고 있습니다. 오늘날 많은 AI 네이티브 애플리케이션은 추론 전(pre-inference) 임베딩 기반 검색을 통해 에이전트가 추론할 중요한 컨텍스트를 표면화합니다. 하지만 분야가 더 에이전트형 접근으로 전환되면서, 이런 검색 시스템에 “저스트 인 타임(just in time)” 컨텍스트 전략을 덧붙이는 팀이 늘고 있습니다.
관련 데이터를 모두 미리 전처리해 올리는 대신, “저스트 인 타임” 접근으로 구축된 에이전트는 가벼운 식별자(파일 경로, 저장된 쿼리, 웹 링크 등)를 유지하고, 도구를 사용해 런타임에 이 참조를 바탕으로 데이터를 동적으로 컨텍스트로 로드합니다. Anthropic의 에이전트형 코딩 솔루션 Claude Code는 이 접근으로 대규모 데이터베이스에서 복잡한 데이터 분석을 수행합니다. 모델은 목표 지향적인 쿼리를 작성하고 결과를 저장하며, Bash의 head/tail 같은 명령을 활용해 전체 데이터 객체를 컨텍스트에 로드하지 않고도 방대한 데이터를 분석할 수 있습니다. 이는 인간의 인지와 유사합니다. 우리는 일반적으로 정보 코퍼스 전체를 암기하지 않고, 파일 시스템/받은 편지함/북마크 같은 외부 조직·인덱싱 시스템을 도입해 필요할 때 관련 정보를 검색해 오기 때문입니다.
저장 효율성 외에도, 이러한 참조의 메타데이터는 행동을 효율적으로 정제하는 메커니즘을 제공합니다(명시적으로 제공되든 직관적으로 이해되든). 파일 시스템에서 동작하는 에이전트에게 tests 폴더에 있는 test_utils.py 파일은, 동일한 이름이라도 src/core_logic/ 폴더에 있는 파일과 다른 목적을 시사합니다. 폴더 계층, 네이밍 규칙, 타임스탬프는 모두 인간과 에이전트가 정보를 어떻게, 언제 활용해야 하는지 이해하는 데 중요한 신호를 제공합니다.
에이전트가 데이터를 자율적으로 탐색하고 가져오게 하면 점진적 공개(progressive disclosure)도 가능해집니다. 즉, 탐색을 통해 관련 컨텍스트를 점진적으로 발견하게 되는 것입니다. 각 상호작용은 다음 결정을 이끄는 컨텍스트를 만듭니다. 파일 크기는 복잡도를 암시하고, 네이밍 규칙은 용도를 힌트로 주며, 타임스탬프는 관련성의 대리 지표가 될 수 있습니다. 에이전트는 이해를 층층이 쌓아가며, 작업 기억(컨텍스트 윈도우)에는 필요한 것만 유지하고, 추가적인 지속성을 위해 노트 작성 전략을 활용할 수 있습니다. 이렇게 자기 관리되는 컨텍스트 윈도우는, 포괄적이지만 잠재적으로 무관한 정보에 잠기지 않도록 에이전트를 관련 부분집합에 집중시킵니다.
물론 트레이드오프도 있습니다. 런타임 탐색은 미리 계산된 데이터를 가져오는 것보다 느립니다. 게다가 LLM이 정보 지형을 효과적으로 탐색할 수 있도록 올바른 도구와 휴리스틱을 갖추게 하려면, 의도적이고 사려 깊은 엔지니어링이 필요합니다. 적절한 가이던스가 없으면 에이전트는 도구를 오용하거나, 막다른 길을 쫓거나, 핵심 정보를 식별하지 못해 컨텍스트를 낭비할 수 있습니다.
어떤 환경에서는 가장 효과적인 에이전트가 하이브리드 전략을 사용할 수 있습니다. 일부 데이터는 속도를 위해 선제적으로 가져오고, 추가 탐색은 필요에 따라 자율적으로 수행하는 방식입니다. ‘적절한’ 자율성 수준을 가르는 경계는 과제에 달려 있습니다. Claude Code는 이 하이브리드 모델을 사용합니다. CLAUDE.md 파일은 단순하게 선제적으로 컨텍스트에 넣고, glob/grep 같은 프리미티브를 통해 환경을 탐색하며 파일을 저스트 인 타임으로 가져와, 오래된 인덱싱이나 복잡한 구문 트리의 문제를 효과적으로 우회합니다.
하이브리드 전략은 법률·금융처럼 콘텐츠가 덜 동적인 컨텍스트에 더 적합할 수 있습니다. 모델 역량이 향상됨에 따라, 에이전트 설계는 지능적인 모델이 지능적으로 행동하도록 하고 인간의 선별을 점차 줄이는 방향으로 갈 것입니다. 이 분야의 발전 속도를 고려하면, Claude 위에서 에이전트를 구축하는 팀에게 “작동하는 가장 단순한 것을 하라(do the simplest thing that works)”는 조언이 아마도 계속 최선일 것입니다.
장기 지평 과제는, 토큰 수가 LLM의 컨텍스트 윈도우를 초과하는 일련의 행동 시퀀스에 걸쳐 에이전트가 일관성, 컨텍스트, 목표 지향적 행동을 유지하도록 요구합니다. 수십 분에서 여러 시간에 이르는 연속 작업(대규모 코드베이스 마이그레이션이나 포괄적 리서치 프로젝트 등)에서는, 컨텍스트 윈도우 크기 제한을 우회하기 위한 특수한 기법이 필요합니다.
컨텍스트 윈도우가 더 커지기를 기다리는 것은 쉬운 선택처럼 보일 수 있습니다. 하지만 가까운 미래에도, 모든 크기의 컨텍스트 윈도우는 컨텍스트 오염과 정보 관련성 문제의 영향을 받을 가능성이 큽니다(특히 최고의 에이전트 성능이 필요할 때). 따라서 우리는 장시간 지평에서 에이전트가 효과적으로 일하도록 하기 위해, 컨텍스트 오염 제약을 정면으로 다루는 몇 가지 기법을 개발해 왔습니다. 압축(compaction), 구조적 노트 작성, 멀티 에이전트 아키텍처입니다.
압축은 컨텍스트 윈도우 한계에 다가가는 대화를 요약하고, 그 요약을 바탕으로 새 컨텍스트 윈도우를 시작하는 관행입니다. 압축은 장기적 일관성을 높이기 위한 컨텍스트 엔지니어링의 첫 번째 레버로 작동하는 경우가 많습니다. 핵심은 컨텍스트 윈도우의 내용을 높은 충실도로 증류해, 최소한의 성능 저하로 에이전트가 계속 작업할 수 있게 하는 것입니다.
예를 들어 Claude Code에서는, 메시지 히스토리를 모델에 넘겨 핵심 디테일을 요약·압축하도록 구현합니다. 모델은 아키텍처 의사결정, 미해결 버그, 구현 세부사항을 보존하고, 중복된 도구 출력이나 메시지는 버립니다. 이후 에이전트는 이 압축된 컨텍스트에 더해 가장 최근에 접근한 파일 5개를 포함한 상태로 계속 진행할 수 있습니다. 사용자는 컨텍스트 윈도우 제한을 걱정하지 않으면서도 연속성을 얻습니다.
압축의 예술은 무엇을 남기고 무엇을 버릴지 선택하는 데 있습니다. 지나치게 공격적인 압축은 나중에야 중요성이 드러나는 미묘하지만 치명적인 컨텍스트를 잃게 만들 수 있습니다. 압축 시스템을 구현하는 엔지니어에게는, 복잡한 에이전트 트레이스에서 프롬프트를 신중히 튜닝하길 권합니다. 먼저 재현율(recall)을 최대화해 트레이스의 관련 정보를 빠짐없이 포착하도록 하고, 그 다음 불필요한 내용을 제거해 정밀도(precision)를 개선하는 방식으로 반복하세요.
불필요한 내용의 쉬운 예는 도구 호출과 결과를 지우는 것입니다. 메시지 히스토리 깊은 곳에서 이미 호출된 도구 결과를 왜 다시 원문 그대로 볼 필요가 있을까요? 가장 안전한 ‘가벼운 터치’ 압축 형태 중 하나가 도구 결과 정리이며, 최근 Claude Developer Platform의 기능으로 출시되었습니다.
구조적 노트 작성(에이전트형 메모리/agentic memory)은 에이전트가 정기적으로 노트를 작성해 컨텍스트 윈도우 밖의 메모리에 저장하고, 나중에 이를 다시 컨텍스트로 불러오는 기법입니다.
이 전략은 최소한의 오버헤드로 지속적 메모리를 제공합니다. Claude Code가 할 일 목록을 만들거나, 여러분의 커스텀 에이전트가 NOTES.md 파일을 유지하는 것처럼, 이 단순한 패턴만으로도 에이전트는 복잡한 작업에서 진행 상황을 추적하고, 수십 번의 도구 호출 사이에 사라질 수 있는 중요한 컨텍스트와 의존성을 유지할 수 있습니다.
Claude의 포켓몬 플레이는 메모리가 코딩이 아닌 영역에서 에이전트 역량을 어떻게 바꾸는지 보여줍니다. 에이전트는 수천 단계에 걸쳐 정밀한 카운트를 유지합니다. 예를 들어 “지난 1,234 스텝 동안 Route 1에서 포켓몬을 훈련했고, 피카츄는 목표 10레벨 중 8레벨을 올렸다” 같은 목표를 추적합니다. 메모리 구조에 대한 특별한 프롬프팅 없이도, 탐험한 지역의 지도를 만들고, 어떤 주요 성취를 해제했는지 기억하며, 다양한 상대에게 어떤 공격이 효과적인지 학습하도록 돕는 전투 전략 노트를 유지합니다.
컨텍스트 리셋 이후에도 에이전트는 자신의 노트를 읽고, 여러 시간에 걸친 훈련이나 던전 탐험을 이어갑니다. 이런 요약 단계 전반에 걸친 일관성 덕분에, 정보를 LLM 컨텍스트 윈도우 안에만 두는 것으로는 불가능한 장기 전략이 가능해집니다.
Sonnet 4.5 출시의 일환으로, 우리는 Claude Developer Platform에서 파일 기반 시스템을 통해 컨텍스트 윈도우 밖에 정보를 저장하고 조회하기 쉽게 해주는 메모리 도구를 퍼블릭 베타로 출시했습니다(뉴스). 이를 통해 에이전트는 시간이 지나며 지식 베이스를 구축하고, 세션 간 프로젝트 상태를 유지하며, 모든 것을 컨텍스트에 넣지 않고도 이전 작업을 참조할 수 있습니다.
서브 에이전트 아키텍처는 컨텍스트 한계를 우회하는 또 다른 방법입니다. 하나의 에이전트가 전체 프로젝트에 걸쳐 상태를 유지하려 하기보다, 전문화된 서브 에이전트가 깨끗한 컨텍스트 윈도우로 집중 과제를 처리합니다. 메인 에이전트는 상위 수준 계획으로 조율하고, 서브 에이전트는 깊은 기술 작업을 수행하거나 도구를 사용해 관련 정보를 찾습니다. 각 서브 에이전트는 수만 토큰 이상을 쓰며 폭넓게 탐색할 수 있지만, 결과로는 자신의 작업을 응축한 요약(대개 1,000~2,000 토큰)을 반환합니다.
이 접근은 관심사의 명확한 분리(separation of concerns)를 달성합니다. 상세한 탐색 컨텍스트는 서브 에이전트 내부에 격리되고, 리드 에이전트는 결과의 종합과 분석에 집중합니다. 이 패턴은 멀티 에이전트 리서치 시스템을 구축한 방법에서 논의되었고, 복잡한 리서치 과제에서 단일 에이전트 시스템 대비 큰 개선을 보였습니다.
어떤 접근을 택할지는 과제 특성에 달려 있습니다. 예를 들어:
모델이 계속 좋아지더라도, 장시간 상호작용에서 일관성을 유지하는 문제는 더 효과적인 에이전트를 만드는 데 계속 핵심 과제로 남을 것입니다.
컨텍스트 엔지니어링은 LLM을 활용해 무언가를 만드는 방식에 근본적 변화를 가져옵니다. 모델이 더 유능해질수록, 과제는 완벽한 프롬프트를 만드는 데만 있지 않습니다. 매 단계에서 모델의 제한된 어텐션 예산 안으로 어떤 정보가 들어가야 하는지 사려 깊게 선별하는 일이 중요해집니다. 장기 지평 과제에서의 압축을 구현하든, 토큰 효율적인 도구를 설계하든, 에이전트가 환경을 저스트 인 타임으로 탐색하도록 하든, 지침 원칙은 동일합니다. 원하는 결과가 나올 가능성을 최대화하는 신호가 강한 토큰의 최소 집합을 찾아라.
우리가 정리한 기법들은 모델이 개선됨에 따라 계속 진화할 것입니다. 이미 더 똑똑한 모델은 덜 규정적인 엔지니어링만으로도 동작하며, 에이전트가 더 큰 자율성을 가지고 운영될 수 있음을 보여주고 있습니다. 그러나 역량이 확장되더라도, 컨텍스트를 귀중하고 유한한 자원으로 다루는 일은 신뢰할 수 있고 효과적인 에이전트를 구축하는 데 계속 중심에 있을 것입니다.
오늘 Claude Developer Platform에서 컨텍스트 엔지니어링을 시작해 보세요. 또한 메모리 및 컨텍스트 관리 쿡북에서 유용한 팁과 모범 사례를 확인할 수 있습니다.
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의 지원에 특별히 감사드립니다.
