AI 에이전트를 위한 효과적인 컨텍스트 엔지니어링

응용 AI 분야에서 수년간 프롬프트 엔지니어링이 주목받아 온 가운데, 최근 새로운 개념이 부상하고 있습니다. 바로 컨텍스트 엔지니어링(context engineering)입니다. 언어 모델을 활용한 개발의 중심축이 프롬프트에 적합한 단어와 문구를 찾는 것에서 벗어나, "모델이 원하는 행동을 생성할 가능성을 극대화하는 컨텍스트 구성은 무엇인가?"라는 보다 근본적인 질문으로 옮겨가고 있습니다.

컨텍스트란 대규모 언어 모델(LLM)에서 샘플링할 때 포함되는 토큰의 집합을 의미합니다. 여기서 엔지니어링 과제는 LLM의 고유한 제약 조건 하에서 이 토큰들의 효용을 최적화하여 일관된 결과를 이끌어내는 것입니다. LLM을 효과적으로 다루려면 컨텍스트 관점에서 사고하는 능력이 필요합니다. 다시 말해, 특정 시점에 LLM이 접근할 수 있는 전체적인 상태와 그 상태가 유발할 수 있는 잠재적 행동을 종합적으로 고려해야 합니다.

이 글에서는 새롭게 떠오르는 컨텍스트 엔지니어링의 기법을 살펴보고, 제어 가능하고 효과적인 에이전트를 구축하기 위한 정교한 사고 프레임워크를 제시합니다.

컨텍스트 엔지니어링 vs. 프롬프트 엔지니어링

Anthropic은 컨텍스트 엔지니어링을 프롬프트 엔지니어링의 자연스러운 진화로 봅니다. 프롬프트 엔지니어링은 최적의 결과를 위해 LLM 지시문을 작성하고 구성하는 방법론입니다(개요와 유용한 전략은 관련 문서를 참고하세요). 컨텍스트 엔지니어링은 LLM 추론 과정에서 최적의 토큰(정보) 집합을 선별하고 유지하기 위한 전략 전반을 지칭하며, 프롬프트 외에도 컨텍스트 윈도우에 포함될 수 있는 모든 정보를 아우릅니다.

LLM 엔지니어링 초기에는 대부분의 활용 사례가 일상적인 채팅 외에 원샷 분류나 텍스트 생성 같은 작업에 최적화된 프롬프트를 요구했기 때문에, 프롬프팅이 AI 엔지니어링 작업의 핵심이었습니다. 용어가 시사하듯, 프롬프트 엔지니어링의 주된 관심사는 효과적인 프롬프트, 특히 시스템 프롬프트를 어떻게 작성하느냐에 있습니다. 그러나 여러 번의 추론 턴과 더 긴 시간 범위에 걸쳐 작동하는 고도화된 에이전트를 구축하는 방향으로 나아가면서, 이제는 전체 컨텍스트 상태(시스템 지시문, 도구, Model Context Protocol(MCP), 외부 데이터, 메시지 히스토리 등)를 관리하는 전략이 필요해졌습니다.

루프에서 실행되는 에이전트는 다음 추론 턴에 잠재적으로 관련될 수 있는 데이터를 점점 더 많이 생성하며, 이 정보는 주기적으로 정제되어야 합니다. 컨텍스트 엔지니어링은 끊임없이 변화하는 방대한 정보 풀에서 제한된 컨텍스트 윈도우에 무엇을 담을 것인지를 결정하는 기술이자 과학입니다.

컨텍스트 엔지니어링이 유능한 에이전트 구축에 중요한 이유

LLM은 처리 속도가 빠르고 점점 더 대용량의 데이터를 다룰 수 있지만, 인간과 마찬가지로 일정 시점을 넘어서면 집중력이 떨어지거나 혼동이 발생하는 현상이 관찰됩니다. needle-in-a-haystack 방식의 벤치마크 연구를 통해 컨텍스트 부패(context rot)라는 개념이 밝혀졌는데, 컨텍스트 윈도우의 토큰 수가 증가할수록 해당 컨텍스트에서 정보를 정확히 회수하는 모델의 능력이 저하된다는 것입니다.

모델에 따라 성능 저하의 정도에 차이가 있지만, 이 특성은 모든 모델에서 나타납니다. 따라서 컨텍스트는 한계 수익이 체감하는 유한한 자원으로 다뤄야 합니다. 제한된 작업 기억 용량을 지닌 인간처럼, LLM에도 대량의 컨텍스트를 파싱할 때 소모되는 "주의력 예산(attention budget)"이 있습니다. 새로운 토큰이 추가될 때마다 이 예산이 일정량 소모되므로, LLM에 제공하는 토큰을 신중하게 선별해야 할 필요성이 더욱 커집니다.

이러한 주의력 희소성은 LLM의 아키텍처적 제약에서 비롯됩니다. LLM은 트랜스포머 아키텍처를 기반으로 하며, 모든 토큰이 전체 컨텍스트에 걸쳐 다른 모든 토큰에 주의를 기울일(attend) 수 있습니다. 그 결과, n개의 토큰에 대해 n²개의 쌍별 관계가 생성됩니다.

컨텍스트 길이가 늘어나면 모델이 이 쌍별 관계를 포착하는 능력이 분산되어, 컨텍스트 크기와 주의력 집중 사이에 자연스러운 긴장이 발생합니다. 또한 모델은 짧은 시퀀스가 긴 시퀀스보다 훨씬 빈번하게 등장하는 학습 데이터 분포로부터 주의력 패턴을 형성합니다. 이는 모델이 컨텍스트 전체에 걸친 장거리 의존 관계에 대해 경험과 전문화된 파라미터가 상대적으로 부족하다는 것을 의미합니다.

위치 인코딩 보간(position encoding interpolation) 같은 기법을 사용하면 원래 학습된 짧은 컨텍스트에 맞춰 적응시켜 더 긴 시퀀스를 처리할 수 있지만, 토큰 위치 이해의 정밀도가 일부 저하됩니다. 이러한 요인들은 뚜렷한 성능 절벽이 아닌 점진적인 성능 기울기를 만들어냅니다. 모델은 긴 컨텍스트에서도 여전히 높은 능력을 발휘하지만, 짧은 컨텍스트 대비 정보 검색과 장거리 추론에서 정밀도가 다소 떨어질 수 있습니다.

이러한 현실을 감안할 때, 유능한 에이전트를 구축하려면 신중한 컨텍스트 엔지니어링이 필수적입니다.

효과적인 컨텍스트의 구조

LLM의 주의력 예산이 유한하다는 점을 고려하면, 우수한 컨텍스트 엔지니어링이란 원하는 결과의 가능성을 극대화하는 최소한의 고신호 토큰 집합을 찾는 것을 의미합니다. 이 원칙을 실제로 적용하는 것은 말처럼 쉽지 않지만, 다음 섹션에서는 컨텍스트의 각 구성 요소에 이 원칙이 어떻게 적용되는지 구체적으로 살펴보겠습니다.

시스템 프롬프트는 매우 명확해야 하며, 에이전트에 적절한 추상화 수준으로 간결하고 직접적인 언어를 사용해야 합니다. 적절한 추상화 수준이란 두 가지 대표적인 실패 패턴 사이의 균형점입니다. 한쪽 극단에서는 엔지니어가 정확한 에이전트 동작을 이끌어내기 위해 복잡하고 경직된 로직을 프롬프트에 하드코딩합니다. 이 접근법은 취약성을 높이고 시간이 지남에 따라 유지보수 복잡도를 증가시킵니다. 반대쪽 극단에서는 모호하고 고수준의 가이드만 제공하여 LLM이 원하는 출력에 대한 구체적인 신호를 받지 못하거나, 공유되지 않은 맥락을 전제로 삼는 경우입니다. 최적의 수준은 이 둘 사이의 균형입니다. 행동을 효과적으로 안내할 만큼 구체적이면서도, 모델에 행동 지침이 되는 강력한 휴리스틱을 제공할 만큼 유연한 지점이어야 합니다.

프롬프트를 구분된 섹션(<background_information>, <instructions>, ## Tool guidance, ## Output description 등)으로 나누고 XML 태그나 Markdown 헤더 같은 기법으로 섹션을 구분하는 것을 권장합니다. 다만 모델의 성능이 향상됨에 따라 프롬프트의 정확한 포맷팅 자체의 중요도는 점차 낮아지고 있습니다.

시스템 프롬프트를 어떤 구조로 작성하든, 기대하는 행동을 완전히 기술하는 최소한의 정보 집합을 목표로 해야 합니다. (최소한이라고 해서 반드시 짧다는 뜻은 아닙니다. 에이전트가 원하는 행동을 충실히 따르도록 충분한 정보를 사전에 제공해야 합니다.) 먼저 최소한의 프롬프트로 사용 가능한 최고 성능의 모델을 테스트해보고, 초기 테스트에서 발견된 실패 패턴을 기반으로 명확한 지시문과 예시를 추가하며 성능을 개선해 나가는 것이 가장 좋습니다.

도구(Tools)는 에이전트가 환경과 상호작용하며 작업 중에 새로운 컨텍스트를 가져올 수 있게 합니다. 도구는 에이전트와 정보/행동 공간 사이의 인터페이스를 정의하므로, 토큰 효율적인 정보를 반환하고 에이전트의 효율적 행동을 유도하는 등 효율성을 극대화하는 것이 매우 중요합니다.

AI 에이전트를 위한 도구 설계 – AI 에이전트와 함께에서 LLM이 잘 이해할 수 있고 기능 간 중복이 최소화된 도구를 만드는 방법을 다뤘습니다. 잘 설계된 코드베이스의 함수처럼, 도구는 자기 완결적이고, 오류에 강하며, 용도가 명확하게 드러나야 합니다. 입력 파라미터 역시 설명적이고 모호하지 않아야 하며, 모델의 고유한 강점에 맞게 설계되어야 합니다.

가장 흔히 관찰되는 실패 패턴 중 하나는 너무 많은 기능을 포괄하거나, 어떤 도구를 사용해야 하는지 모호한 판단 지점을 만드는 비대한 도구 세트입니다. 인간 엔지니어가 특정 상황에서 어떤 도구를 써야 하는지 확신할 수 없다면, AI 에이전트에게 더 나은 판단을 기대할 수는 없습니다. 뒤에서 다루겠지만, 에이전트에 필요한 최소한의 도구 세트를 선별하면 긴 상호작용에서 컨텍스트를 안정적으로 유지하고 정리하는 데도 도움이 됩니다.

Few-shot 프롬프팅으로도 알려진 예시 제공은 여전히 강력히 권장하는 모범 사례입니다. 다만, 많은 팀이 LLM이 따라야 할 모든 규칙을 빠짐없이 나열하려고 온갖 엣지 케이스를 프롬프트에 무분별하게 넣는 경우가 있는데, 이는 권장하지 않습니다. 대신, 에이전트의 기대 행동을 효과적으로 보여주는 다양하고 대표적인 예시 세트를 정성스럽게 선별하세요. LLM에게 예시는 "백문이 불여일견"과도 같습니다.

컨텍스트의 다양한 구성 요소(시스템 프롬프트, 도구, 예시, 메시지 히스토리 등)에 대한 전반적인 지침은, 정보성을 유지하되 간결하게 관리하라는 것입니다. 이제 런타임에 컨텍스트를 동적으로 검색하는 방법을 살펴보겠습니다.

컨텍스트 검색과 에이전틱 탐색

효과적인 AI 에이전트 구축하기에서 LLM 기반 워크플로와 에이전트의 차이를 조명한 바 있습니다. 해당 글을 작성한 이후, 우리는 에이전트에 대한 간결한 정의로 수렴했습니다. LLM이 자율적으로 도구를 루프 안에서 사용하는 것, 그것이 에이전트입니다.

고객들과 협업하면서, 업계가 이 단순한 패러다임으로 수렴하는 흐름을 목격하고 있습니다. 기반 모델의 성능이 향상될수록 에이전트의 자율성도 확장됩니다. 더 뛰어난 모델은 에이전트가 복잡한 문제 공간을 독립적으로 탐색하고 오류로부터 회복할 수 있게 해줍니다.

현재 에이전트를 위한 컨텍스트 설계 방식에 변화가 일어나고 있습니다. 오늘날 많은 AI 네이티브 애플리케이션은 에이전트가 추론할 중요한 컨텍스트를 사전에 확보하기 위해 임베딩 기반의 추론 전 검색(pre-inference time retrieval)을 어떤 형태로든 활용합니다. 에이전틱 접근 방식으로 전환이 가속화되면서, 이러한 검색 시스템에 "적시(just in time)" 컨텍스트 전략을 결합하는 팀이 점점 늘고 있습니다.

관련 데이터를 전부 사전 처리하는 대신, "적시" 접근 방식으로 구축된 에이전트는 경량 식별자(파일 경로, 저장된 쿼리, 웹 링크 등)를 유지하다가, 도구를 사용해 런타임에 이 참조들을 통해 데이터를 컨텍스트에 동적으로 로드합니다. Anthropic의 에이전틱 코딩 솔루션 Claude Code는 이 접근 방식을 활용하여 대규모 데이터베이스에 대한 복잡한 데이터 분석을 수행합니다. 모델은 타깃 쿼리를 작성하고, 결과를 저장한 뒤, head나 tail 같은 Bash 명령어를 활용하여 전체 데이터 객체를 컨텍스트에 로드하지 않고도 대용량 데이터를 분석합니다. 이 접근 방식은 인간의 인지 방식과 유사합니다. 우리도 방대한 정보를 통째로 암기하지 않고, 파일 시스템이나 받은편지함, 북마크 같은 외부 조직·색인 체계를 만들어 필요할 때 관련 정보를 검색합니다.

저장 효율성 외에도, 이러한 참조의 메타데이터는 명시적이든 암묵적이든 행동을 효율적으로 조정하는 메커니즘을 제공합니다. 파일 시스템에서 작동하는 에이전트에게 test_utils.py 파일이 tests 폴더에 있는 것과 src/core_logic/에 있는 것은 서로 다른 용도를 암시합니다. 폴더 계층 구조, 네이밍 컨벤션, 타임스탬프 등은 인간과 에이전트 모두가 정보를 어떻게, 언제 활용해야 하는지 판단하는 데 중요한 신호를 제공합니다.

에이전트가 자율적으로 데이터를 탐색하고 검색할 수 있게 하면 점진적 공개(progressive disclosure)가 가능해집니다. 즉, 에이전트가 탐색 과정을 통해 관련 컨텍스트를 점진적으로 발견할 수 있습니다. 각 상호작용은 다음 판단에 필요한 컨텍스트를 생성합니다. 파일 크기는 복잡도를 시사하고, 네이밍 컨벤션은 용도를 암시하며, 타임스탬프는 관련성의 지표가 됩니다. 에이전트는 이해를 단계적으로 쌓아가며, 작업 메모리에는 필요한 것만 유지하고 노트 테이킹 전략을 활용해 추가적인 지속성을 확보합니다. 이처럼 스스로 관리하는 컨텍스트 윈도우 덕분에 에이전트는 방대하지만 무관할 수 있는 정보에 매몰되지 않고 관련 있는 부분집합에 집중할 수 있습니다.

물론 트레이드오프도 있습니다. 런타임 탐색은 사전 계산된 데이터를 검색하는 것보다 느립니다. 그뿐만 아니라, LLM이 정보 환경을 효과적으로 탐색할 수 있도록 적절한 도구와 휴리스틱을 갖추게 하려면 주관이 확실하고 세심한 엔지니어링이 필요합니다. 적절한 안내가 없으면, 에이전트가 도구를 잘못 사용하거나 막다른 길을 쫓거나 핵심 정보를 놓치면서 컨텍스트를 낭비할 수 있습니다.

특정 환경에서는 하이브리드 전략이 가장 효과적일 수 있습니다. 일부 데이터는 속도를 위해 사전에 검색하고, 추가적인 자율 탐색은 에이전트의 판단에 맡기는 방식입니다. '적정' 자율성 수준의 판단 기준은 작업에 따라 달라집니다. Claude Code가 바로 이 하이브리드 모델을 사용하는 에이전트입니다. CLAUDE.md 파일은 단순하게 사전에 컨텍스트에 투입되고, glob이나 grep 같은 프리미티브를 통해 환경을 탐색하며 파일을 적시에 검색함으로써, 오래된 인덱싱이나 복잡한 구문 트리 문제를 효과적으로 우회합니다.

하이브리드 전략은 법률이나 금융처럼 동적 콘텐츠가 비교적 적은 분야에 더 적합할 수 있습니다. 모델의 역량이 향상될수록 에이전트 설계는 사람의 개입을 점차 줄이고, 지능적인 모델이 스스로 지능적으로 행동하도록 맡기는 방향으로 나아갈 것입니다. 이 분야의 발전 속도를 감안하면, "동작하는 가장 단순한 방법을 택하라"는 조언은 Claude 기반 에이전트를 구축하는 팀에게 앞으로도 가장 유효한 원칙으로 남을 것입니다.

장기 작업을 위한 컨텍스트 엔지니어링

장기(long-horizon) 작업에서는 토큰 수가 LLM의 컨텍스트 윈도우를 초과하는 긴 액션 시퀀스 전반에 걸쳐 에이전트가 일관성과 맥락, 목표 지향적 행동을 유지해야 합니다. 대규모 코드베이스 마이그레이션이나 포괄적인 리서치 프로젝트처럼 수십 분에서 수 시간에 이르는 연속 작업을 수행하려면, 컨텍스트 윈도우 크기 제한을 우회하는 별도의 기법이 필요합니다.

더 큰 컨텍스트 윈도우가 등장하기를 기다리는 것이 당연한 해법처럼 보일 수 있습니다. 하지만 가까운 미래까지, 어떤 크기의 컨텍스트 윈도우든 컨텍스트 오염(context pollution)과 정보 관련성 문제에서 자유롭지 못할 가능성이 높습니다—적어도 최고 수준의 에이전트 성능을 요구하는 상황에서는 그렇습니다. 확장된 시간 범위에서 에이전트가 효과적으로 작동하도록, 저희는 이러한 컨텍스트 오염 제약을 직접 해결하는 몇 가지 기법을 개발했습니다: 압축(compaction), 구조화된 노트 작성, 그리고 멀티 에이전트 아키텍처입니다.

압축(Compaction)

압축은 컨텍스트 윈도우 한계에 근접한 대화를 요약한 뒤, 그 요약으로 새로운 컨텍스트 윈도우를 다시 시작하는 기법입니다. 장기적 일관성을 높이기 위한 컨텍스트 엔지니어링의 첫 번째 수단으로 주로 활용됩니다. 핵심은 컨텍스트 윈도우의 내용을 높은 충실도로 압축해, 에이전트가 성능 저하를 최소화하면서 작업을 이어갈 수 있게 하는 것입니다.

예를 들어 Claude Code에서는 메시지 히스토리를 모델에 전달해 가장 중요한 세부 사항을 요약·압축하는 방식으로 구현합니다. 모델은 아키텍처 결정 사항, 미해결 버그, 구현 세부 사항 등은 보존하면서 중복된 도구 출력이나 메시지는 제거합니다. 이후 에이전트는 이 압축된 컨텍스트와 가장 최근 접근한 파일 5개를 기반으로 작업을 계속합니다. 사용자는 컨텍스트 윈도우 한계를 신경 쓰지 않고도 작업의 연속성을 유지할 수 있습니다.

압축의 핵심은 무엇을 유지하고 무엇을 버릴지 선택하는 데 있습니다. 지나치게 공격적으로 압축하면 나중에야 중요성이 드러나는 미묘하지만 핵심적인 맥락을 잃을 수 있기 때문입니다. 압축 시스템을 구현하는 엔지니어라면, 복잡한 에이전트 트레이스를 기반으로 프롬프트를 신중하게 튜닝하시길 권합니다. 먼저 재현율(recall)을 최대화해 압축 프롬프트가 트레이스에서 관련 정보를 빠짐없이 포착하도록 한 뒤, 불필요한 내용을 제거하는 방향으로 정밀도(precision)를 반복 개선해 나가세요.

쉽게 제거할 수 있는 불필요한 콘텐츠의 대표적인 예가 도구 호출과 그 결과를 정리하는 것입니다. 메시지 히스토리 깊숙한 곳에서 이미 호출된 도구의 원시 결과를 에이전트가 다시 볼 필요가 있을까요? 가장 안전하고 가벼운 형태의 압축이 바로 도구 결과 정리이며, 최근 Claude Developer Platform의 기능으로 출시되었습니다.

구조화된 노트 작성

구조화된 노트 작성, 즉 에이전틱 메모리(agentic memory)는 에이전트가 컨텍스트 윈도우 외부의 메모리에 정기적으로 노트를 기록하는 기법입니다. 이 노트는 이후 필요한 시점에 컨텍스트 윈도우로 다시 불러옵니다.

이 전략은 최소한의 오버헤드로 영속적인 메모리를 제공합니다. Claude Code가 할 일 목록을 만들거나, 커스텀 에이전트가 NOTES.md 파일을 관리하는 것처럼, 이 단순한 패턴만으로 에이전트는 복잡한 작업 전반의 진행 상황을 추적하고, 수십 번의 도구 호출 사이에서 사라질 수 있는 핵심 컨텍스트와 의존성을 유지할 수 있습니다.

Claude의 포켓몬 플레이는 코딩 이외의 영역에서 메모리가 에이전트의 역량을 어떻게 변화시키는지 잘 보여줍니다. 이 에이전트는 수천 단계의 게임 진행 과정에서 정확한 기록을 유지합니다. "지난 1,234 스텝 동안 1번 도로에서 포켓몬을 훈련시켰고, 피카츄가 목표 레벨 10 중 8레벨을 올렸다"와 같은 목표를 추적하는 식입니다. 메모리 구조에 대한 별도 프롬프트 없이도, 에이전트는 탐험한 지역의 지도를 직접 만들고, 달성한 주요 업적을 기억하며, 각 상대에게 어떤 공격이 가장 효과적인지 학습한 전투 전략 노트를 관리합니다.

컨텍스트가 초기화된 후에도 에이전트는 자신이 작성한 노트를 읽고, 수 시간에 걸친 훈련이나 던전 탐험을 이어갑니다. 이처럼 요약 단계를 넘나드는 일관성 덕분에, LLM의 컨텍스트 윈도우에만 모든 정보를 담아둘 때는 불가능했던 장기 전략이 가능해집니다.

Sonnet 4.5 출시와 함께, Claude Developer Platform에서 메모리 도구를 퍼블릭 베타로 공개했습니다. 파일 기반 시스템을 통해 컨텍스트 윈도우 외부에 정보를 저장하고 참조할 수 있어, 에이전트가 시간이 지남에 따라 지식 기반을 축적하고, 세션 간 프로젝트 상태를 유지하며, 모든 것을 컨텍스트에 담아두지 않고도 이전 작업을 참조할 수 있습니다.

서브 에이전트 아키텍처

서브 에이전트 아키텍처는 컨텍스트 제약을 우회하는 또 다른 방법입니다. 하나의 에이전트가 프로젝트 전체의 상태를 관리하는 대신, 특화된 서브 에이전트가 깨끗한 컨텍스트 윈도우로 집중된 작업을 수행합니다. 메인 에이전트는 상위 계획을 기반으로 조율하고, 서브 에이전트는 심층적인 기술 작업을 수행하거나 도구를 활용해 관련 정보를 탐색합니다. 각 서브 에이전트는 수만 토큰 이상을 광범위하게 탐색하더라도, 최종적으로는 압축·정제된 요약(보통 1,000~2,000 토큰)만 반환합니다.

이 접근 방식은 관심사의 분리를 명확히 달성합니다. 상세한 탐색 컨텍스트는 서브 에이전트 내부에 격리되고, 리드 에이전트는 결과의 종합과 분석에 집중합니다. 멀티 에이전트 리서치 시스템 구축기에서 소개한 이 패턴은 복잡한 리서치 작업에서 단일 에이전트 시스템 대비 상당한 성능 향상을 보여주었습니다.

이 기법들 중 어떤 것을 선택할지는 작업의 특성에 따라 달라집니다. 예를 들면:

• 압축은 빈번한 주고받기가 필요한 작업에서 대화 흐름을 유지하는 데 적합합니다.
• 노트 작성은 명확한 마일스톤이 있는 반복적 개발 작업에 강점을 발휘합니다.
• 멀티 에이전트 아키텍처는 병렬 탐색이 효과적인 복잡한 리서치 및 분석 작업에 적합합니다.

모델이 계속 발전하더라도, 장시간 상호작용 전반에 걸쳐 일관성을 유지하는 과제는 더 효과적인 에이전트를 구축하는 데 있어 핵심 과제로 남을 것입니다.

결론

컨텍스트 엔지니어링은 LLM 기반 개발 방식의 근본적인 전환을 의미합니다. 모델이 더 유능해질수록 중요한 것은 완벽한 프롬프트를 작성하는 일만이 아닙니다. 각 단계에서 모델의 제한된 주의(attention) 예산에 어떤 정보를 넣을지 신중하게 큐레이션하는 것이 핵심입니다. 장기 작업을 위한 압축을 구현하든, 토큰 효율적인 도구를 설계하든, 에이전트가 적시에 환경을 탐색하도록 하든, 핵심 원칙은 동일합니다: 원하는 결과의 가능성을 최대화하는 최소한의 고신호(high-signal) 토큰 집합을 찾는 것입니다.

이 글에서 소개한 기법들은 모델이 발전함에 따라 계속 진화할 것입니다. 이미 더 똑똑한 모델일수록 지시적인 엔지니어링이 덜 필요하며, 에이전트가 더 높은 자율성으로 동작할 수 있음을 확인하고 있습니다. 그러나 역량이 아무리 확장되더라도, 컨텍스트를 소중하고 유한한 자원으로 다루는 것은 신뢰할 수 있고 효과적인 에이전트를 구축하는 핵심으로 남을 것입니다.

지금 바로 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의 도움에 특별히 감사드립니다.