[요약 번역] AI 에이전트를 위한 효과적 컨텍스트 엔지니어링

9월 29일에 Anthropic에서 Effective context engineering for AI agents를 발표했습니다. 그동안 바이브 코딩 하며, 다른 분들과 대화하며 경험적으로 느껴 교육에서 얘기하곤 했던 것들이 훌륭한 시각화 자료와 함께 정리되어있어 반갑네요. (참고글: AI가 내 맘을 몰라줄 때: 더 적은 토큰으로 더 좋은 결과를 내는 4가지 기법)

Effective context engineering for AI agents

Anthropic is an AI safety and research company that’s working to build reliable, interpretable, and steerable AI systems.

그런데 집중해서 읽기에는 또 조금 길어서, 제가 보기에 중요한 부분을 의역 & 요약하며 중간중간에 제 생각도 담아봤습니다. 잘못된 해석이 있을 수 있으니 지적 & 피드백 언제든지 환영합니다. (전문 번역은 최승준님의 페이스북 포스팅을 참고하세요)

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

• 프롬프트 엔지니어링은 싱글턴 쿼리를 더 잘 하자는 것이고
• (특히 에이전트를 위한) 컨텍스트 엔지니어링은 다양한 컨텍스트 중 정말 필요한 것만 큐레이션하자는 것이다.

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

• 인간과 유사하게, LLM도 컨텍스트에 많은 데이터가 차있으면 집중력을 잃어 원하는 정보를 인출하기 어려워한다. (Context Rot)
• 인간이 작업기억에 한계를 가지는 것처럼, 트랜스포머 아키텍처를 기반으로 하는 LLM도 '주의력 예산(Attention Budget)'을 가진다. 이는 모든 새 토큰은 모든 다른 토큰에 영향을 받는다는 뜻이며, 갈수록 각 토큰에 부여하는 주의력이 얇아진다는 뜻이다.
• 게다가 LLM의 학습 데이터에는 길이가 짧은 것이 긴 것보다 훨씬 많기 때문에, LLM은 대체로 짧은 컨텍스트에 더 잘 반응하도록 훈련되었다. 그래서 긴 컨텍스트에 더 약한 것이며, 위치 인코딩 보간(position encoding interpolation)같은 기술을 통해 이 한계를 뛰어넘게도 해주긴 하지만 여전히 성능 감소가 있다.

역자 주: 해설해보자면 이런 논리입니다.

• 현재 에이전트는 '더 오랫동안, 더 많은 툴을' 사용하도록 개발되고 있다.
• 그러면 컨텍스트가 길어질 수밖에 없는데, 위의 이유로 현재 LLM은 긴 컨텍스트에 취약하다.
• 그래서 컨텍스트를 효과적으로 제어하는 게 에이전트 개발에 아주 중요하다.

효과적 컨텍스트의 해부학

좋은 컨텍스트 엔지니어링은 원하는 결과의 가능성을 최대화하는 가능한 가장 작은 고신호 토큰 집합을 찾는 것을 의미한다. (Smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome)

역자 주: GPT-5-Codex 프롬프팅 가이드: Less is More과도 일맥상통합니다. "성능을 올리기 위해 AGENTS.md에 내용을 더하기보다는 빼는 걸 먼저 해봐라." 그리고 디버깅을 위한 최소 재현 조건을 찾는 것도 떠오르네요.

시스템 프롬프트

• 시스템 프롬프트는 굉장히 명확하고, 단순하고, 직접적인 언어를 딱 적절한 수준으로만 표현해야 한다. 너무 구체적이면 다양한 케이스에 대응할 수 없고 너무 추상적이면 LLM이 추정해야 하는 게 너무 많다.
• 기대 동작에 대한 최소한의 기술만으로 시작하고, 프론티어 모델이 실패하는 케이스에 대해서만 명확한 명령과 예제를 추가하는 식으로 개선해나가라.
• XML이나 마크다운과 유사한 기법으로 섹션을 구분하되, 너무 정확한 문법을 지키려고 할 필요는 없다.

Tools

• Tools는 에이전트와 외부 공간(정보 공간, 실행 공간)과의 교환을 효과적으로 도와야 한다. 즉 Tools는 토큰-효율적으로 정보를 반환하며, 동시에 에이전트가 토큰-효율적으로 동작하도록 유도해야 한다.
• AI 에이전트로 AI 에이전트를 위한 Tools 만들기 문서에서 다뤘듯, Tools는 LLM이 잘 이해할 수 있는 형태여야 하며, 서로간에 겹치는 기능이 최소화되어야 한다. 굉장히 잘 정의된 함수 인터페이스와 유사하다.
• Tools 개발에서 가장 흔한 실수는 하나의 툴이 너무 많은 기능을 커버하거나, LLM이 어떤 툴을 써야 할지 결정하기 어려운 상황이 되는 것이다. 인간 엔지니어가 언제 무엇을 써야 할지 결정하기 어렵다면 AI 에이전트에게도 어렵다.
• 예제를 쥐어주는 few-shot 프롬프팅은 언제나 강추한다. 그러나 너무 많은 엣지 케이스에 대해 넣어두는 것은 범용성을 낮춘다. 신중하게 결정된 기대 동작을 보여주는 예제를 다양하게 포함하라.

컨텍스트 인출과 에이전틱 검색

• 효과적으로 AI 에이전트 만들기 문서에서 우리는 LLM 기반 워크플로우와 에이전트의 차이에 대해 논했다. 에이전트란, 목표 달성을 위해 루프를 돌며 자율적으로 도구를 실행하는 존재다. 모델이 강력해질수록 더 많은 권한을(자율성을) 에이전트에게 부여할 수 있다.
• 에이전틱 어프로치가 발전하면서 점점 더 많이 보이는 게 JIT(Just in Time)으로 컨텍스트를 부여하는 전략이다. 클로드 코드가 이걸 아주 잘 사용한다. 프롬프트상의 파일 경로와 링크를 보고 그걸 그자리에서 가져오는 식이다. 이는 인간의 인지 과정과 닮아 있다. 인간은 모든 걸 기억하는 대신 외부 기억 장치와 키워드를 사용해서 인덱싱한다.
• 좋은 컨텍스트를 JIT으로 불러오려면 처음부터 좋은 구조로 정보를 저장해야 한다. 여기에는 인출에 도움이 되는 메타데이터를 어떻게 저장해둘 것인가에 대한 고민도 포함된다. 폴더 구조, 네이밍 컨벤션, 타임스탬프를 비롯해 사람에게 중요하고 유의미한 시그널이 에이전트에게도 정보 활용에 큰 도움을 준다.

오래 걸리는 작업(long-horizon tasks)을 위한 컨텍스트 엔지니어링

오래 걸리는 작업들은 대개 LLM의 컨텍스트 윈도우를 가볍게 넘긴다. 따라서 에이전트가 어떻게 좋은 컨텍스트를 유지하며 목표 달성을 향해 꾸준히 나아가게 만들 것인지가 아주 중요해진다.

물론 모델의 컨텍스트 크기는 계속 커지겠지만, 단순히 더 큰 컨텍스트를 기대하는 것으로는 부족하다. 앞서도 언급했듯 컨텍스트는 쉽게 오염되고, 가능하면 적을수록 높은 성능을 내기 때문이다. 그래서 이런 테크닉들을 사용한다.

압축

• 컨텍스트 윈도우 제한에 가까워지면 중요한 컨텐츠를 요약해서 새 윈도우에 넘기는 것. 클로드 코드에서는 메시지 히스토리를 넘겨 요약하게 한다. 아키텍처 의사결정, 해결 안 된 버그, 구현 디테일 등.
• 압축의 묘는 결국 뭘 남기고 뭘 버릴 것인가에 있다. 가장 쉽게 버릴 만한 건 툴 호출과 결과물이다. 메시지 히스토리에 이미 들어갔다면 그것들은 가지고 있을 필요가 거의 없다. Claude의 메모리 툴로 툴 호출과 결과물을 지우는 이런 Context Editing이 가능하다.

구조화된 노트테이킹

• 에이전틱 메모리라고도 부른다. 정기적으로 컨텍스트 윈도우 바깥(즉 파일 시스템)에 노트를 남겼다가 나중에 가져오는 기법이다.
• 이전에도 가능했지만 Sonnet 4.5부터 메모리 툴로 이걸 하기가 더 수월해졌다.

서브에이전트 아키텍처

• 메인 에이전트는 큰 그림에서 계획을 세워 조율하고, 서브에이전트들이 딥한 기술적 작업을 하거나 툴을 써서 관련된 정보를 찾는 기법이다. 서브에이전트가 탐색에 엄청난 양의 토큰을 쓰더라도 결국 필요한 정보를 압축된 정보로 전달하게 되므로 메인 에이전트의 컨텍스트는 잘 보존된다. 이 패턴은 우리가 멀티-에이전트 리서치 시스템을 어떻게 만들었는지 서술한 글에 잘 나와있다.

작업의 특성에 따라 이 3가지 기법 중 무엇을 택할지 달라진다. 예를 들어:

• 압축은 광범위한 양방향 소통이 필요한 작업에서 대화 흐름을 유지하는 데 좋다.
• 구조화된 노트테이킹은 명확한 이정표가 있는 작업을 이터레이션을 돌며 개발하기에 좋다.
• 서브에이전트 아키텍처는 병렬 탐색이 효과를 발휘하는 복잡한 연구 및 분석을 처리하기에 좋다.

결론

• 모델이 강력해짐에 따라 단지 프롬프트만 잘 만드는 걸 넘어, 각 단계에서 어떤 정보가 '주의력 예산' 안에 들어갈지 선별하는 것이 중요한 과제가 되었다.
• 장기 작업을 위한 압축을 구현하든, 토큰 효율적인 도구를 설계하든, 에이전트가 적시에 환경을 탐색할 수 있게 하든, 이러한 지침 원칙은 동일하게 유지된다: 원하는 결과의 가능성을 최대화하는 가장 작은 고신호 토큰 집합을 찾는 것이다.
• 이 글의 기법들은 모델 개선과 함께 꾸준히 진화하며, 에이전트는 더 자율적으로 움직이게 되겠지만, 여전히 '컨텍스트는 귀중하고 유한한 자원이다'라는 관점은 신뢰 가능하며 효과적인 에이전트 구축의 핵심이 될 것이다.
• 더 많은 내용은 메모리 및 컨텍스트 관리 쿡북을 참고하길 바란다.