Why Bigger Context Windows Won't Save Your Agent — Elizabeth Fuentes Leone, AWS

한 줄 핵심

대형 tool output 때문에 에이전트가 무너지는 이유를 설명하고, 컨텍스트를 더 키우는 대신 외부화·선별·압축·분리·포인터 활용으로 해결하는 방법을 정리한 영상이다.

시간별 요약

1. 0:00
   소개 컨텍스트 윈도우를 무한히 키우는 방식만으로는 에이전트 문제를 해결할 수 없으며, 실제로는 컨텍스트를 다루는 설계가 중요하다는 문제의식으로 시작한다.
2. 0:37
   큰 tool 출력에서 에이전트가 무너지는 이유 tool이 대량의 데이터를 반환하면 컨텍스트 윈도우가 넘치고 환각과 성능 저하가 발생하므로, 에이전트용 아키텍처는 입력을 더 잘 다루는 방향으로 설계되어야 한다.
3. 1:12
   로그를 감시하는 에이전트 예시 애플리케이션 로그를 계속 가져오는 에이전트는 매 세션마다 이전 대화와 로그가 누적되어 컨텍스트가 계속 커지며, 기억 구조가 곧 동작 비용과 품질을 좌우한다.
4. 1:57
   더 큰 윈도우가 해결책은 아니다 토큰만 늘리면 된다는 직관은 틀렸고, 컨텍스트가 커질수록 중요한 정보가 잘 전달되지 않는 다른 문제가 더 두드러진다.
5. 2:12
   가운데 정보가 사라지는 현상 긴 컨텍스트에서는 앞부분과 뒷부분만 잘 기억되고 중간 정보는 쉽게 잊히므로, 단순히 많은 데이터를 넣는 방식은 신뢰할 수 없다.
6. 2:42
   컨텍스트 엔지니어링의 의미 모델이 필요할 때 필요한 정보만 주는 것이 핵심이며, 불필요한 정보와 프롬프트 인젝션 위험을 줄이면서 토큰 소비와 결과 품질을 함께 최적화해야 한다.
7. 3:17
   외부화, 선택, 압축, 분리 큰 데이터를 영구 저장소로 외부화하고, 필요한 것만 선택해 가져오며, 요약으로 압축하고, 에이전트 간 문맥을 분리하는 네 가지 전략이 기본 축이다.
8. 4:07
   대화 관리자 Strands Agents의 대화 관리자는 최근 메시지만 유지하는 sliding window, 전체 대화를 요약하는 방식, 둘을 결합하는 방식으로 컨텍스트를 제어한다.
9. 5:07
   Strands Agents란 무엇인가 Strands는 한 줄 수준의 설정으로 에이전트 루프와 기본 구성 요소를 만들 수 있는 프레임워크이며, 다양한 모델과 연동할 수 있다.
10. 5:57
    대화 기록 요약 요약형 대화 관리자는 오래된 메시지를 압축하고 최근 메시지를 보존해 세션 컨텍스트를 유지하므로, 장기 대화에서도 기본 흐름을 잃지 않게 한다.
11. 6:42
    단기 기억, 장기 기억, 그래프 기억 최근 대화는 단기 기억으로, 세션을 넘어서는 정보는 벡터DB 기반 장기 기억으로, 관계와 연결 구조는 그래프 기억으로 다루는 구성이 효과적이다.
12. 8:12
    대형 tool 출력용 메모리 포인터 로그처럼 큰 tool 결과는 그대로 컨텍스트에 넣지 말고 저장소에 넣은 뒤 ID만 남기는 메모리 포인터 방식으로 관리해야 하며, 필요할 때만 다시 조회한다.
13. 9:47
    스웜에서 포인터 공유 여러 에이전트가 같은 큰 데이터를 공유할 때는 전체 문맥을 복제하기보다 invocation state와 메모리 포인터를 공유해야 중복과 혼선을 줄일 수 있다.
14. 10:42
    멈추지 않는 에이전트 에이전트가 같은 tool을 반복 호출하며 끝나지 않는 문제는 응답 조건을 명확히 하고, 루프를 멈출 수 있는 통제 장치를 두어야 해결된다.
15. 11:22
    tool 호출 제한 tool별 최대 호출 횟수를 정해 두면 불필요한 내부 루프를 막을 수 있고, 에이전트가 정해진 범위 안에서만 행동하도록 만들 수 있다.
16. 12:12
    느린 tool을 위한 비동기 핸들 외부 API나 MCP tool이 즉시 응답하지 않을 때는 동기 대기 대신 비동기 핸들을 써서 작업을 시작하고, 결과는 다음 호출에서 다시 가져오는 편이 안정적이다.
17. 13:41
    피해야 할 안티패턴 모든 정보를 한꺼번에 넣는 context stuffing, 과도한 native summarization, 불필요한 context pollution은 모델의 판단 품질을 떨어뜨리므로 피해야 한다.
18. 14:36
    치트 시트 큰 로그·DB·알림 데이터는 외부화와 메모리 포인터로 다루고, 여러 에이전트가 같은 큰 데이터를 쓰면 포인터를 공유하며, tool에는 명확한 응답과 호출 제한, 비동기 핸들을 적용하는 것이 핵심이다.

실무 인사이트

• 에이전트 성능 문제를 토큰 수로만 보지 말고, 어떤 정보를 외부화하고 어떤 것만 컨텍스트에 남길지 먼저 설계해야 한다.
• 장기 대화와 대형 tool 결과는 요약보다 메모리 포인터·검색·재조회 구조로 분리해야 정확도와 비용을 함께 잡을 수 있다.
• 도구 호출 루프와 느린 외부 API는 에이전트 품질 저하의 주요 원인이므로, 호출 횟수 제한과 비동기 처리로 안전장치를 두는 것이 효과적이다.