[요약 번역] AI 에이전트를 위한 효과적 컨텍스트 엔지니어링
(stdy.blog)- 9월 29일에 Anthropic에서 올린 Effective context engineering for AI agents를 요약 번역했습니다. 블로그 글에는 원본 글에 있던 이미지와 링크를 최대한 살렸습니다.
프롬프트 엔지니어링 vs 컨텍스트 엔지니어링
- 프롬프트 엔지니어링은 싱글턴 쿼리를 더 잘 하자는 것이고
- (특히 에이전트를 위한) 컨텍스트 엔지니어링은 다양한 컨텍스트 중 정말 필요한 것만 큐레이션하자는 것이다.
에이전트 구축에 컨텍스트 엔지니어링이 중요한 이유
- 현재 에이전트는 '더 오랫동안, 더 많은 툴을' 사용하도록 개발되고 있다.
- 그러면 컨텍스트가 길어질 수밖에 없는데, LLM은 인간과 유사하게 컨텍스트에 많은 데이터가 차있으면 집중력을 잃어 원하는 정보를 인출하기 어려워진다.
- 그래서 컨텍스트를 효과적으로 제어하는 게 에이전트 개발에 아주 중요하다.
효과적 컨텍스트의 해부학
좋은 컨텍스트 엔지니어링은 원하는 결과의 가능성을 최대화하는 가능한 가장 작은 고신호 토큰 집합을 찾는 것을 의미한다.
Smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome
1) 시스템 프롬프트
- 시스템 프롬프트는 굉장히 명확하고, 단순하고, 직접적인 언어를 딱 적절한 수준으로만 표현해야 한다. 너무 구체적이면 다양한 케이스에 대응할 수 없고 너무 추상적이면 LLM이 추정해야 하는 게 너무 많다.
- 기대 동작에 대한 최소한의 기술만으로 시작하고, 프론티어 모델이 실패하는 케이스에 대해서만 명확한 명령과 예제를 추가하는 식으로 개선해나가라.
- XML이나 마크다운과 유사한 기법으로 섹션을 구분하되, 너무 정확한 문법을 지키려고 할 필요는 없다.
2) Tools
- Tools는 토큰-효율적으로 정보를 반환하며, 동시에 에이전트가 토큰-효율적으로 동작하도록 유도해야 한다. LLM이 잘 이해할 수 있는 형태여야 하며, 서로간에 겹치는 기능이 최소화되어야 한다.
- 가장 흔한 실수는 하나의 툴이 너무 많은 기능을 커버하거나, LLM이 어떤 툴을 써야 할지 결정하기 어려운 상황이 되는 것이다. 인간 엔지니어가 언제 무엇을 써야 할지 결정하기 어렵다면 AI 에이전트에게도 어렵다.
- 예제를 쥐어주는 few-shot 프롬프팅은 언제나 강추한다. 그러나 너무 많은 엣지 케이스에 대해 넣어두는 것은 범용성을 낮춘다. 신중하게 결정된 기대 동작을 보여주는 예제를 다양하게 포함하라.
컨텍스트 인출과 에이전틱 검색
- 에이전트란, 목표 달성을 위해 루프를 돌며 자율적으로 도구를 실행하는 존재다. 모델이 강력해질수록 더 많은 권한을(자율성을) 에이전트에게 부여할 수 있다.
- 에이전틱 어프로치가 발전하면서 점점 더 많이 보이는 게 JIT(Just in Time)으로 컨텍스트를 부여하는 전략이다. 클로드 코드가 이걸 아주 잘 사용한다. 프롬프트상의 파일 경로와 링크를 보고 그걸 그자리에서 가져오는 식이다.
- 좋은 컨텍스트를 JIT으로 불러오려면 처음부터 좋은 구조로 정보를 저장해야 한다. 여기에는 인출에 도움이 되는 메타데이터를 어떻게 저장해둘 것인가에 대한 고민도 포함된다. 폴더 구조, 네이밍 컨벤션, 타임스탬프를 비롯해 사람에게 중요하고 유의미한 시그널이 에이전트에게도 정보 활용에 큰 도움을 준다.
오래 걸리는 작업(long-horizon tasks)을 위한 컨텍스트 엔지니어링
오래 걸리는 작업들은 대개 LLM의 컨텍스트 윈도우를 가볍게 넘긴다. 따라서 에이전트가 어떻게 좋은 컨텍스트를 유지하며 목표 달성을 향해 꾸준히 나아가게 만들 것인지가 아주 중요해진다.
작업 특성에 따라 크게 3가지 기법을 사용할 수 있다.
- 압축은 광범위한 양방향 소통이 필요한 작업에서 대화 흐름을 유지하는 데 좋다.
- 구조화된 노트테이킹은 명확한 이정표가 있는 작업을 이터레이션을 돌며 개발하기에 좋다.
- 서브에이전트 아키텍처는 병렬 탐색이 효과를 발휘하는 복잡한 연구 및 분석을 처리하기에 좋다.
1) 압축
- 컨텍스트 윈도우 제한에 가까워지면 중요한 컨텐츠를 요약해서 새 윈도우에 넘기는 것. 클로드 코드에서는 메시지 히스토리를 넘겨 요약하게 한다. 아키텍처 의사결정, 해결 안 된 버그, 구현 디테일 등.
- 압축의 묘는 결국 뭘 남기고 뭘 버릴 것인가에 있다. 가장 쉽게 버릴 만한 건 툴 호출과 결과물이다. 메시지 히스토리에 이미 들어갔다면 그것들은 가지고 있을 필요가 거의 없다.
- 소넷 4.5부터 도입된 메모리 툴로 Context Editing이 가능하다: https://www.anthropic.com/news/context-management
2) 구조화된 노트테이킹
- 에이전틱 메모리라고도 부른다. 정기적으로 컨텍스트 윈도우 바깥(즉 파일 시스템)에 노트를 남겼다가 나중에 가져오는 기법이다.
- 마찬가지로 소넷 4.5부터 메모리 툴로 이 기법을 쓰기 더 쉬워졌다.
3) 서브에이전트 아키텍처
- 메인 에이전트는 큰 그림에서 계획을 세워 조율하고, 서브에이전트들이 딥한 기술적 작업을 하거나 툴을 써서 관련된 정보를 찾는 기법이다.
- 멀티-에이전트 리서치 시스템을 어떻게 만들었는지 서술한 글 참조.
결론
- 모델이 강력해짐에 따라 단지 프롬프트만 잘 만드는 걸 넘어, 각 단계에서 어떤 정보가 '주의력 예산' 안에 들어갈지 선별하는 것이 중요한 과제가 되었다.
- 장기 작업을 위한 압축을 구현하든, 토큰 효율적인 도구를 설계하든, 에이전트가 적시에 환경을 탐색할 수 있게 하든, 이러한 지침 원칙은 동일하게 유지된다: 원하는 결과의 가능성을 최대화하는 가장 작은 고신호 토큰 집합을 찾는 것이다.
- 이 글의 기법들은 모델 개선과 함께 꾸준히 진화하며 더 자율적으로 움직이겠지만, 여전히 '컨텍스트는 귀중하고 유한한 자원이다'라는 관점은 신뢰 가능하며 효과적인 에이전트 구축의 핵심이 될 것이다.
- 더 많은 내용은 메모리 및 컨텍스트 관리 쿡북을 참고하길 바란다.