출처 : Anthropic - Effective context engineering for AI agents (2025.09.29)

✼✼ disclaimer ✼✼ 본 글은 AI 번역 후 직접 검수하여 작성했습니다. 효율적인 정보 전달을 위해 AI 번역을 활용하되, 부자연스러운 표현은 수정했습니다. 번역 오류가 있을 수 있으니 정확한 내용은 원문을 확인하시기 바랍니다.

컨텍스트는 AI 에이전트에게 필수적이면서도 한정된 자원입니다. 이 글에서는 에이전트를 구동하는 컨텍스트를 효과적으로 선별하고 관리하는 전략들을 살펴봅니다.

AI 활용 분야에서 몇 년간 프롬프트 엔지니어링이 주목받았다면, 이제는 컨텍스트 엔지니어링이라는 새로운 개념이 떠오르고 있습니다. 언어 모델 작업의 핵심이 이제는 달라지고 있습니다. 프롬프트에 쓸 적절한 단어를 고르는 것보다, "어떤 식으로 컨텍스트를 구성해야 모델이 우리가 원하는 대로 움직일까?"라는 더 근본적인 물음에 답하는 것이 중요해졌습니다.

컨텍스트(Context)란 대규모 언어 모델(LLM)이 응답을 생성할 때 입력으로 들어가는 토큰들의 집합을 말합니다. 여기서 엔지니어가 해결해야 할 것은 LLM의 태생적 한계 속에서 이 토큰들을 최적으로 활용해 원하는 결과를 지속적으로 달성하는 일입니다. LLM을 효과적으로 다루려면 컨텍스트 중심으로 사고해야 합니다. 다시 말해, 특정 순간에 LLM이 활용할 수 있는 모든 정보 상태와 그것이 어떤 행동으로 이어질지를 전체적으로 바라봐야 한다는 뜻입니다.

이 글에서는 새롭게 부상하는 컨텍스트 엔지니어링의 기술을 탐구하고, 조종 가능하고 효과적인 에이전트를 구축하기 위한 체계적인 접근법을 제시합니다.

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

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

LLM 엔지니어링 초기에는 일상적인 채팅을 제외한 대부분의 사용 사례가 일회성 분류나 텍스트 생성 작업에 최적화된 프롬프트를 필요로 했기에, 프롬프팅이 AI 엔지니어링 작업의 가장 큰 부분을 차지했습니다. 이름에서 알 수 있듯이, 프롬프트 엔지니어링의 주된 초점은 효과적인 프롬프트, 특히 시스템 프롬프트를 작성하는 방법이었습니다. 그러나 이제는 여러 번의 추론을 반복하고 장시간 작동하는 고도의 에이전트를 만드는 쪽으로 발전하면서, 전체 컨텍스트 상태(시스템 지시사항, 도구, 모델 컨텍스트 프로토콜(MCP), 외부 데이터, 메시지 기록 등)를 관리할 전략이 필요해졌습니다.

반복 실행되는 에이전트는 다음 단계에 필요할 수 있는 데이터를 계속해서 만들어내고, 이 정보는 주기적으로 다듬어져야 합니다. 컨텍스트 엔지니어링은 계속 변화하는 방대한 정보 속에서 한정된 컨텍스트 창에 무엇을 담을지 골라내는 기술이자 학문입니다.

프롬프트 작성이 한 번 하고 끝나는 작업이라면, 컨텍스트 엔지니어링은 계속 반복되며 모델에 전달할 내용을 정할 때마다 선별 과정을 거칩니다.

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

빠른 속도와 방대한 데이터 처리 능력을 갖췄지만, LLM도 인간처럼 어느 순간부터는 집중력이 떨어지거나 헷갈리기 시작한다는 걸 확인했습니다. '건초더미 속 바늘 찾기' 형태의 벤치마크 연구에서 컨텍스트 부패(context rot)라는 개념이 나왔습니다. 컨텍스트 창에 토큰이 많아질수록 모델이 그 안에서 정보를 정확히 찾아내는 능력이 떨어진다는 것입니다.

어떤 모델은 다른 모델보다 성능 저하가 덜하긴 하지만, 이런 현상은 모든 모델에 공통적으로 나타납니다. 그래서 컨텍스트는 투입할수록 효율이 떨어지는 한정된 자원으로 봐야 합니다. 제한된 작업 기억 용량을 가진 인간처럼, LLM도 대량의 컨텍스트를 파싱할 때 활용하는 "주의력 예산"을 갖고 있습니다. 새로운 토큰이 도입될 때마다 이 예산이 일정량 소모되므로, LLM에 제공되는 토큰을 신중하게 선별해야 할 필요성이 커집니다.

이러한 주의력 부족은 LLM의 구조적 제약에서 비롯됩니다. LLM은 트랜스포머 아키텍처를 쓰는데, 이 구조에서는 모든 토큰이 전체 컨텍스트의 다른 모든 토큰에 주의를 기울입니다. 그 결과 n개의 토큰이 있으면 n² 개의 쌍 관계가 만들어집니다.

컨텍스트가 길어질수록 이런 쌍 관계를 포착하는 모델의 능력이 희석되면서, 컨텍스트 크기와 주의력 집중 사이에 자연스런 줄다리기가 생깁니다. 더군다나 모델은 훈련 데이터에서 주의력 패턴을 학습하는데, 훈련 데이터에는 긴 시퀀스보다 짧은 시퀀스가 훨씬 많습니다. 그러다 보니 모델은 컨텍스트 전체에 걸친 의존성에 대한 경험도 적고 특화된 파라미터도 부족합니다.

위치 인코딩 보간(position encoding interpolation) 같은 기법을 쓰면 원래 훈련된 작은 컨텍스트에 맞춰 조정해서 더 긴 시퀀스를 처리할 수 있지만, 토큰 위치 파악에서는 어느 정도 성능이 떨어집니다. 이런 요소들 때문에 성능이 급격히 추락하는 게 아니라 완만하게 내리막을 그립니다. 모델은 긴 컨텍스트에서도 여전히 훌륭하게 작동하지만, 짧은 컨텍스트와 비교하면 정보 검색이나 장거리 추론에서 정밀도가 조금 떨어질 수 있습니다.

이러한 현실은 유능한 에이전트를 구축하는 데 신중한 컨텍스트 엔지니어링이 필수적이라는 것을 의미합니다.

효과적인 컨텍스트의 구조

LLM의 주의력 예산이 한정되어 있다는 걸 고려하면, 좋은 컨텍스트 엔지니어링은 원하는 결과를 최대한 끌어낼 수 있는 가장 작은 핵심 토큰 세트를 찾는 것입니다. 말은 쉽지만 실천은 어렵습니다. 다음 섹션에서는 이 원칙이 컨텍스트의 각 구성 요소에서 실제로 어떻게 적용되는지 살펴봅니다.

시스템 프롬프트는 최대한 명확해야 하고, 에이전트에게 적절한 수준에서 개념을 전달하는 단순하고 직접적인 언어를 써야 합니다. 적절한 수준이란 두 가지 흔한 실패 사례 사이의 골디락스 존(적정 지점)입니다. 한쪽 극단에서는 엔지니어들이 원하는 에이전트 행동을 이끌어내기 위해 복잡하고 취약한 로직을 프롬프트에 하드코딩합니다. 이 방식은 취약성을 만들고 시간이 지날수록 유지보수 복잡성을 증가시킵니다. 반대쪽 극단에서는 모호하고 고수준의 지침만 제공해서 LLM에게 원하는 출력에 대한 구체적 신호를 주지 못하거나 공유된 컨텍스트를 잘못 가정하기도 합니다. 최적의 고도는 균형을 이룹니다. 행동을 효과적으로 안내할 만큼 구체적이면서도, 모델에게 행동을 이끌 강력한 휴리스틱을 제공할 만큼 유연해야 합니다.

스펙트럼의 한쪽 끝에는 취약한 if-else 하드코딩 프롬프트가 있고, 다른 쪽 끝에는 지나치게 일반적이거나 공유 컨텍스트를 잘못 가정하는 프롬프트가 있습니다.

프롬프트를 명확한 섹션들(예: <background_information>, <instructions>, ## 도구 가이드, ## 출력 설명 등)로 구성하고 XML 태그나 마크다운 헤더 같은 기법을 사용해 이러한 섹션들을 구분하는 것을 권장합니다. 다만 모델이 더 유능해질수록 프롬프트의 정확한 형식은 덜 중요해지고 있습니다.

시스템 프롬프트를 어떻게 구조화하든, 기대하는 행동을 완전히 담아내는 최소한의 정보만 넣으려고 노력해야 합니다. (최소한이라는 것이 반드시 짧다는 의미는 아닙니다. 에이전트가 원하는 행동을 준수하도록 초반에 충분한 정보를 제공해야 합니다.) 최상의 접근법은 사용 가능한 최고의 모델로 최소한의 프롬프트를 테스트해서 작업 성능을 확인한 다음, 초기 테스트에서 발견된 실패 모드를 바탕으로 명확한 지시사항과 예시를 추가해 성능을 개선하는 것입니다.

도구는 에이전트가 환경과 작동하고 작업하면서 새로운 추가 컨텍스트를 가져올 수 있게 합니다. 도구는 에이전트가 정보와 행동을 주고받는 방식을 정의하기 때문에, 토큰을 절약하는 정보를 제공하면서 동시에 에이전트가 효율적으로 작동하도록 이끄는 것이 핵심입니다.

'AI 에이전트를 위한 도구 작성 - AI 에이전트와 함께'에서는 LLM이 잘 이해하고 기능이 최소한으로 중복되는 도구를 구축하는 것에 대해 논의했습니다. 잘 설계된 코드베이스의 함수들처럼, 도구는 독립적이고 오류에 강하며 의도된 사용에 대해 극도로 명확해야 합니다. 입력 매개변수도 마찬가지로 서술적이고 모호하지 않으며 모델의 본질적인 강점을 활용해야 합니다.

자주 보는 실패 사례 중 하나는 도구 세트가 너무 많은 기능을 담고 있거나, 어떤 도구를 써야 할지 판단이 애매해지는 경우입니다. 인간 엔지니어가 특정 상황에서 어떤 도구를 사용해야 할지 명확하게 말할 수 없다면, AI 에이전트가 더 잘하리라 기대할 수 없습니다. 나중에 논의하겠지만, 에이전트에게 꼭 필요한 핵심 도구만 엄선해두면, 장시간에 걸친 작업에서도 컨텍스트를 더욱 체계적이고 안정적으로 유지하고 가다듬을 수 있습니다.

예시 제공, 즉 퓨샷 프롬프팅(few-shot prompting)은 우리가 계속해서 강력히 권장하는 잘 알려진 모범 사례입니다. 하지만 팀들은 종종 특정 작업에서 LLM이 따라야 할 모든 가능한 규칙을 설명하려는 시도로 프롬프트에 엣지 케이스들을 잔뜩 채워 넣습니다. 이는 권장하지 않습니다. 대신 에이전트의 기대 행동을 효과적으로 묘사하는 다양하고 대표적인 예시 세트를 선별하는 것을 권장합니다. LLM에게 예시는 천 마디 말의 가치를 지닌 "그림"입니다.

컨텍스트의 각 구성 요소 전반(시스템 프롬프트, 도구, 예시, 메시지 히스토리 등)에 대한 우리의 가이드는 신중하게 생각하면서 컨텍스트를 유익하면서도 간결하게 유지하라는 것입니다. 이제 런타임에서 컨텍스트를 동적으로 검색하는 것에 대해 깊이 들어가 보겠습니다.

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

'효과적인 AI 에이전트 구축'에서 LLM 기반 워크플로우와 에이전트의 차이점을 강조했습니다. 그 글을 쓴 이후, 우리는 에이전트를 간단하게 정의하게 됐습니다. LLM이 반복 실행 과정에서 스스로 도구를 활용하는 것, 그게 바로 에이전트입니다.

고객들과 함께 작업하면서, 이 간단한 패러다임으로 분야가 수렴하는 것을 목격했습니다. 기본 모델이 더 유능해질수록 에이전트의 자율성 수준도 확장될 수 있습니다. 더 똑똑한 모델일수록 에이전트가 복잡한 문제 공간을 스스로 헤쳐나가고 실수했을 때도 알아서 바로잡을 수 있습니다.

이제 엔지니어들이 에이전트용 컨텍스트를 설계하는 방식이 바뀌고 있습니다. 현재 많은 AI 기반 애플리케이션은 임베딩 기반 사전 검색을 활용해 에이전트가 추론할 때 필요한 중요 컨텍스트를 끌어옵니다. 하지만 에이전트가 더욱 자율적으로 작동하는 방향으로 발전하면서, 기존 검색 방식에 "필요한 순간에 즉시 가져오는(just in time)" 컨텍스트 전략을 결합하는 사례가 늘어나고 있습니다.

모든 관련 데이터를 미리 전처리하는 대신, "적시(just in time)" 접근법으로 구축된 에이전트는 가벼운 식별자(파일 경로, 저장된 쿼리, 웹 링크 등)만 갖고 있다가 이 참조를 활용해 실행 중에 도구로 데이터를 동적으로 컨텍스트에 불러옵니다. Anthropic의 에이전트 코딩 솔루션인 Claude Code는 이 접근법을 사용해 대규모 데이터베이스에서 복잡한 데이터 분석을 수행합니다. 모델은 타겟팅된 쿼리를 작성하고 결과를 저장하며, 전체 데이터 객체를 컨텍스트에 로드하지 않고도 head와 tail 같은 Bash 명령을 활용해 대량의 데이터를 분석할 수 있습니다. 이 접근법은 인간의 인지를 반영합니다. 우리는 일반적으로 전체 정보 말뭉치를 암기하지 않고, 대신 필요에 따라 관련 정보를 검색하기 위해 파일 시스템, 받은 편지함, 북마크 같은 외부 조직화 및 인덱싱 시스템을 도입합니다.

저장 공간 효율을 넘어, 이런 참조의 메타데이터는 명시적이든 직관적이든 행동을 효과적으로 다듬을 수 있는 수단이 됩니다. 파일 시스템에서 작동하는 에이전트에게는 tests 폴더 안의 test_utils.py 파일과 src/core_logic/에 있는 같은 이름의 파일이 전혀 다른 용도를 의미합니다. 폴더 구조, 이름 짓기 규칙, 시간 정보 모두 사람과 에이전트가 정보를 언제 어떻게 써야 할지 파악하는 데 중요한 단서가 됩니다.

에이전트가 스스로 데이터를 탐색하고 가져오도록 하면 점진적 공개도 가능해집니다. 다시 말해, 탐색 과정을 통해 관련 컨텍스트를 조금씩 발견할 수 있게 되는 것입니다. 상호작용 하나하나가 다음 결정에 필요한 컨텍스트를 만들어냅니다. 파일 크기는 복잡도를, 파일명 규칙은 용도를, 타임스탬프는 중요도를 짐작하게 해줍니다. 에이전트는 이렇게 이해를 단계별로 쌓아가면서 작업 메모리에는 꼭 필요한 것만 남기고, 더 오래 기억할 내용은 메모 전략을 활용합니다. 이런 자체 관리 컨텍스트 창 덕분에 에이전트는 방대하지만 쓸모없을 수 있는 정보에 파묻히지 않고 관련된 부분에만 집중할 수 있습니다.

물론 장단점이 있습니다. 실행 시점에 탐색하는 방식은 미리 가공해둔 데이터를 불러오는 것보다 속도가 느립니다. 더군다나 LLM이 정보 공간을 효과적으로 탐색할 수 있도록 적절한 도구와 판단 기준을 제공하려면 명확한 방향성을 가진 세심한 설계가 필요합니다. 제대로 된 가이드 없이는 에이전트가 도구를 잘못 쓰거나 막다른 길만 좇거나 핵심 정보를 못 찾아서 컨텍스트를 허비할 수 있습니다.

특정 상황에서 가장 효과적인 에이전트는 하이브리드 전략(절충안)을 사용할 수 있습니다. 속도를 위해 일부 데이터를 미리 검색하고, 재량에 따라 추가 자율 탐색을 추구하는 것입니다. 어느 정도의 자율성이 '적절한지'에 대한 판단 기준은 작업에 따라 달라집니다. Claude Code는 이러한 하이브리드 모델을 사용하는 에이전트입니다. CLAUDE.md 파일은 초기에 단순하게 컨텍스트에 포함시키고, glob와 grep 같은 기본 도구로 환경을 탐색하고 파일을 필요할 때 바로 가져올 수 있게 해서 오래된 인덱스나 복잡한 구문 트리(complex syntax tree) 문제를 효과적으로 피해갑니다.

하이브리드 전략은 법률이나 금융 업무처럼 변화가 적은 콘텐츠를 다루는 상황에 더 적합할 수 있습니다. 모델 성능이 향상되면서, 에이전트 설계는 사람의 개입을 점차 줄이고 똑똑한 모델이 스스로 똑똑하게 행동하도록 하는 방향으로 나아갈 것입니다. 이 분야의 빠른 발전 속도를 감안하면, Claude로 에이전트를 구축하는 팀들에게는 "작동하는 가장 단순한 방법을 쓰라"는 조언이 여전히 가장 현명한 선택일 것입니다.

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

장기 작업은 토큰 수가 LLM의 컨텍스트 창을 초과하는 일련의 행동에 걸쳐 에이전트가 일관성, 컨텍스트, 목표 지향적 행동을 유지하도록 요구합니다. 대규모 코드베이스 마이그레이션이나 포괄적인 연구 프로젝트처럼 수십 분에서 몇 시간의 지속적인 작업에 걸친 작업의 경우, 에이전트는 컨텍스트 창 크기 제한을 우회하기 위한 특수한 기법들이 필요합니다.

컨텍스트 창이 더 커지길 기다리는 게 당연한 방법처럼 보일 수 있습니다. 하지만 적어도 최고 성능의 에이전트가 필요한 상황에서는, 가까운 미래에도 어떤 크기의 컨텍스트 창이든 컨텍스트 오염과 정보 관련성 문제에서 자유롭지 못할 것입니다. 장시간에 걸쳐 에이전트가 효과적으로 작동하도록 하기 위해, 우리는 이러한 컨텍스트 오염 제약(context pollution constraints)을 직접적으로 해결하는 몇 가지 기법을 개발했습니다. 압축, 구조화된 메모 작성, 멀티 에이전트 아키텍처가 그것입니다.

압축(compaction)

압축은 컨텍스트 창 한계에 다다른 대화를 가져다가 내용을 요약하고, 그 요약본으로 새 컨텍스트 창을 다시 시작하는 방식입니다. 압축은 보통 장기적 일관성을 높이기 위한 컨텍스트 엔지니어링의 첫 번째 수단으로 활용됩니다. 핵심은 압축이 컨텍스트 창의 내용을 고품질로 압축해서 에이전트가 성능 저하를 최소화하며 작업을 이어갈 수 있게 한다는 점입니다.

예를 들어 Claude Code에서는 메시지 히스토리를 모델에 전달해 가장 중요한 세부 사항을 요약하고 압축하도록 구현합니다. 모델은 중복된 도구 출력이나 메시지를 버리면서 아키텍처 결정, 해결되지 않은 버그, 구현 세부사항을 보존합니다. 그런 다음 에이전트는 이 압축된 컨텍스트에 가장 최근에 접근한 다섯 개 파일을 더해 계속할 수 있습니다. 사용자는 컨텍스트 창 제한을 걱정하지 않고도 연속성을 얻습니다.

압축의 핵심은 무엇을 남기고 무엇을 버릴지 고르는 데 있습니다. 너무 과하게 압축하면 미묘하지만 중요한 맥락을 잃을 수 있고, 그 중요성은 나중에야 드러납니다. 압축 시스템을 만드는 엔지니어들에게는 복잡한 에이전트 추적 기록을 가지고 프롬프트를 세심하게 조율하라고 권합니다. 우선 회상을 최대화해서 압축 프롬프트가 추적 기록의 모든 관련 정보를 빠짐없이 담도록 한 다음, 불필요한 내용을 제거하며 정밀도를 높여가는 방식으로 개선합니다.

쉽게 제거할 수 있는 불필요한 콘텐츠의 예는 도구 호출과 결과를 정리하는 것입니다. 메시지 히스토리 깊숙이에서 도구가 호출되었다면, 에이전트가 원본 결과를 다시 볼 이유가 있을까요? 가장 안전하고 부담 없는 압축 방법 중 하나가 도구 결과 정리인데, 최근 Claude 개발자 플랫폼에 이 기능이 추가되었습니다.

구조화된 메모 작성(structured note-taking)

구조화된 메모 작성, 즉 에이전트 메모리(agentic memory)는 에이전트가 컨텍스트 창 외부의 메모리에 지속되는 메모를 정기적으로 작성하는 기법입니다. 이러한 메모는 나중에 컨텍스트 창으로 다시 가져옵니다.

이 전략은 부담을 최소화하면서 지속적인 메모리를 제공합니다. Claude Code가 할 일 목록을 만들거나 커스텀 에이전트가 NOTES.md 파일을 관리하는 것처럼, 이 간단한 패턴을 통해 에이전트는 복잡한 작업의 진행 상황을 추적하고, 수십 번의 도구 호출 과정에서 잃어버릴 수 있는 중요한 맥락과 의존 관계를 유지할 수 있습니다.

포켓몬을 플레이하는 Claude는 메모리가 비코딩 영역에서 에이전트 능력을 어떻게 변화시키는지 보여줍니다. 에이전트는 수천 게임 단계에 걸쳐 정확한 집계를 유지합니다. "지난 1,234 단계 동안 루트 1에서 내 포켓몬을 훈련했고, 피카츄는 목표인 10레벨을 향해 8레벨을 얻었다"와 같은 목표를 추적합니다. 메모리 구조에 대한 어떤 프롬프팅 없이도, 탐험한 지역의 지도를 개발하고 잠금 해제한 주요 업적을 기억하며 다양한 상대에게 어떤 공격이 가장 잘 작동하는지 학습하는 데 도움이 되는 전투 전략에 대한 전략적 메모를 유지합니다.

컨텍스트 재설정 후에도 에이전트는 자신의 메모를 읽고 몇 시간에 걸친 훈련 시퀀스나 던전 탐험을 계속합니다. 요약 단계에 걸친 이러한 일관성은 LLM의 컨텍스트 창만으로 모든 정보를 유지할 때는 불가능한 장기 전략을 가능하게 합니다.

Sonnet 4.5 출시의 일환으로, 우리는 Claude 개발자 플랫폼에서 공개 베타로 메모리 도구를 출시했습니다. 이는 파일 기반 시스템을 통해 컨텍스트 창 외부의 정보를 저장하고 참조하는 것을 더 쉽게 만듭니다. 이를 통해 에이전트는 시간이 지남에 따라 지식 베이스를 구축하고, 세션 간에 프로젝트 상태를 유지하며, 모든 것을 컨텍스트에 유지하지 않고도 이전 작업을 참조할 수 있습니다.

하위 에이전트 아키텍처(sub-agent architectures)

하위 에이전트 아키텍처는 컨텍스트 제한을 우회하는 또 다른 방법을 제공합니다. 하나의 에이전트가 전체 프로젝트에 걸쳐 상태를 유지하려 시도하는 대신, 전문화된 하위 에이전트들이 깨끗한 컨텍스트 창으로 집중된 작업을 처리할 수 있습니다. 메인 에이전트는 전체 계획을 조율하고, 하위 에이전트들은 깊이 있는 기술 작업을 수행하거나 도구를 써서 관련 정보를 찾습니다. 각 하위 에이전트는 수만 개 이상의 토큰을 사용해 광범위하게 탐색할 수 있지만, 최종적으로는 압축하고 정제한 요약본(보통 1,000~2,000 토큰)만 반환합니다.

이 접근법은 역할을 명확하게 분리합니다. 상세한 검색 컨텍스트는 하위 에이전트 내에 격리되고, 주도 에이전트는 결과 종합과 분석에 집중합니다. '멀티 에이전트 연구 시스템 구축 방법'에서 다룬 이 패턴은 복잡한 연구 작업에서 단일 에이전트 시스템보다 상당히 개선된 결과를 보여주었습니다.

이러한 접근법 간의 선택은 작업 특성에 따라 달라집니다. 예를 들어:

압축은 광범위한 주고받기가 필요한 작업에서 대화 흐름을 유지합니다
메모 작성은 명확한 이정표가 있는 반복적 개발에 탁월합니다
멀티 에이전트 아키텍처는 병렬 탐색이 배당금을 지불하는 복잡한 연구와 분석을 처리합니다

모델이 계속 발전하더라도, 긴 상호작용 과정에서 일관성을 유지하는 문제는 더 효과적인 에이전트를 구축하는 데 여전히 핵심적인 과제로 남을 것입니다.

결론

컨텍스트 엔지니어링은 LLM으로 구축하는 방식의 근본적 전환입니다. 모델이 더 유능해질수록, 중요한 건 완벽한 프롬프트를 만드는 것만이 아니라 각 단계에서 모델의 한정된 주의력 예산에 어떤 정보를 넣을지 세심하게 선별하는 것입니다. 장기 작업용 압축을 구현하든, 토큰 효율적 도구를 설계하든, 에이전트가 필요할 때 환경을 탐색하게 하든, 핵심 원칙은 동일합니다. 원하는 결과의 가능성을 최대화하는 최소한의 고신호(high-signal) 토큰 세트를 찾는 것입니다.

우리가 소개한 기법들은 모델 발전에 따라 계속 진화할 것입니다. 이미 더 똑똑한 모델은 덜 엄격한 엔지니어링을 필요로 하며 에이전트가 더 자율적으로 작동할 수 있게 한다는 걸 확인하고 있습니다. 하지만 능력이 확장되더라도, 컨텍스트를 귀중하고 한정된 자원으로 다루는 것은 신뢰할 수 있고 효과적인 에이전트를 만드는 데 여전히 핵심일 것입니다.

Claude 개발자 플랫폼에서 오늘 컨텍스트 엔지니어링을 시작하고, 메모리 및 컨텍스트 관리 쿡북에서 유용한 팁과 모범 사례를 확인하세요.

감사의 말

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의 지원에 특별한 감사를 드립니다.

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