더 큰 컨텍스트 윈도우가 에이전트를 구하지 못하는 이유

제목 원문: Why Bigger Context Windows Won't Save Your Agent — Elizabeth Fuentes Leone, AWS
URL: https://www.youtube.com/watch?v=DrfyORO8RqA
날짜: 2026-10-08
채널: aiDotEngineer
업로드일: 2026-10-08
재생 시간: 15분 54초

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==에이전트의 문제를 더 큰 컨텍스트 윈도우로 해결할 수 있다는 믿음은 틀렸으며, 필요한 정보를 필요한 순간에 공급하는 컨텍스트 엔지니어링이 정확도·비용·안정성을 좌우한다.==

• 도구가 대량의 로그·데이터베이스 결과·알림을 반환하면 컨텍스트 윈도우가 계속 커지고, 오버플로와 환각, 성능 저하가 발생한다.
• 컨텍스트가 너무 커지면 모델은 앞과 뒤를 상대적으로 잘 기억하고 중간 내용을 잊는 attention U-curve 현상을 보인다.
• 대용량 데이터를 저장소로 외부화하고, 필요한 부분만 선택·압축하며, 에이전트 간 컨텍스트를 격리하면 토큰 소비와 오작동을 줄일 수 있다.

컨텍스트 엔지니어링은 모델에 모든 자료를 밀어 넣는 일이 아니라 모델이 답을 만들 때 실제로 필요한 정보를 필요한 시점에 전달하는 아키텍처 설계다. Strands Agents의 대화 관리 기능, 단기·장기·관계형 메모리, 메모리 포인터, 에이전트 스웜의 상태 포인터 공유, 도구 호출 상한, 비동기 작업 핸들이 이 원칙을 구현한다.

1. 무한 컨텍스트 윈도우라는 신화

더 큰 창은 저장 가능한 토큰 수를 늘릴 뿐, 모델이 모든 토큰을 동일하게 활용하도록 만들지는 않는다.

1.1. 시작 인사와 가벼운 농담

1. 엘리자베스와 모건을 둘러싼 오프닝 농담

   1. 엘리자베스 푸엔테스 레온은 자신이 모건이 아니라고 먼저 정정한다.
   2. 아젠다를 맡은 사람은 아젠다를 절대 바꾸지 않는다는 농담을 덧붙이고, 두 사람이 머리 색깔만 다를 뿐 거의 같다고 말한다.
   3. 비슷한 진행이 이어질 것이라는 말로 분위기를 풀고, 마지막에도 “엘리자베스이지 모건이 아니다”라는 농담을 반복하며 웃음과 함께 마무리한다.

2. 무한 컨텍스트 윈도우의 허구

   1. 현재 에이전트 시스템은 도구가 많은 데이터를 반환할 때 깨진다.
   2. 컨텍스트 윈도우 오버플로는 에이전트의 환각과 성능 저하를 유발한다.
   3. 컨텍스트 엔지니어링은 이런 에이전트 애플리케이션에 더 나은 구조를 제공한다.

1.2. 로그를 계속 쌓는 감독 에이전트

1. 컨텍스트가 세션마다 커지는 구조

   1. 애플리케이션을 감독하는 에이전트가 애플리케이션 로그를 가져온다고 가정한다.
   2. 로그를 가져올 때마다 결과가 컨텍스트 윈도우에 추가된다.
   3. 새 세션이 이전 세션의 데이터를 다시 가져오면 에이전트가 모든 것을 기억하는 방식 때문에 창의 크기가 계속 증가한다.

2. “토큰을 더 넣으면 해결된다”는 과거의 접근

   1. 에이전트 시대가 본격화되기 전, 대략 1년 전까지는 작업 수와 토큰 수를 늘리면 문제를 해결할 수 있다고 여겼다.
   2. 더 큰 컨텍스트 윈도우가 모든 과거 정보를 보존해 줄 것이라는 기대가 있었다.
   3. 실제 운영 경험은 이 기대가 틀렸음을 보여 준다.

1.3. Attention U-curve와 중간 정보 망각

1. 대량 컨텍스트의 비균등한 활용

   1. 데이터가 아주 많아지면 모델은 컨텍스트의 중간 부분을 잊기 쉽다.
   2. 컨텍스트의 처음과 마지막에 놓인 내용은 상대적으로 잘 기억하지만, 중간에 들어간 중요한 사실은 놓칠 수 있다.
   3. 창의 최대 토큰 수가 늘어났다는 사실과 모델이 모든 위치의 정보를 같은 품질로 참조한다는 사실은 다르다.

2. 컨텍스트 엔지니어링의 정의

   1. 모델이 필요한 정보를 필요한 시점에 받도록 만드는 것이 컨텍스트 엔지니어링이다.
   2. 에이전트가 창 안의 모든 정보를 필요로 하는 것은 아니다.
   3. 불필요한 자료는 토큰을 낭비할 뿐 아니라 컨텍스트 안에 프롬프트 인젝션을 섞어 모델을 오염시킬 수도 있다.
   4. 목표는 최적의 결과와 적절한 토큰 소비를 동시에 달성하는 것이다.

2. 컨텍스트를 관리하는 네 가지 설계 원칙

대용량 정보를 그대로 유지하지 말고 외부화·선택·압축·격리의 조합으로 다룬다.

2.1. 외부화: 대용량 결과를 저장하고 포인터만 유지하기

1. 영구 저장소로 옮기기

   1. 로그처럼 큰 결과를 컨텍스트 윈도우에 매번 넣지 않고 영구 저장소로 이동한다.
   2. 저장된 데이터 자체가 아니라 그 데이터가 있는 위치를 가리키는 메모리 포인터를 만든다.
   3. 포인터는 작은 ID이므로 에이전트의 컨텍스트에 보존해도 대량 로그보다 훨씬 적은 토큰을 사용한다.

2. 자료를 모두 받아 적을 필요가 없는 이유

   1. 발표 자료는 마지막에 공유되므로 청중이 슬라이드의 모든 문장을 받아 적을 필요가 없다는 비유가 사용된다.
   2. 필요한 설명은 현장에서 제공되므로, 현재 답을 만드는 데 필요한 정보만 창에 남기는 편이 효율적이다.
   3. 같은 원칙으로 로그 원문은 저장소에 보존하고, 에이전트에는 상태·요약·ID를 먼저 전달한다.

2.2. 선택: 관련 있는 데이터만 검색하기

1. 검색 범위 좁히기

   1. 현재 질문과 관련된 로그 구간이나 데이터베이스 레코드만 검색한다.
   2. 전체 저장소를 한 번에 컨텍스트에 복사하지 않는다.
   3. 선택 단계는 모델이 처리할 입력의 품질과 비용을 함께 낮춘다.

2. 선택과 보안

   1. 불필요한 데이터가 줄면 prompt injection이 모델의 판단에 끼어들 기회도 줄어든다.
   2. 권한이 없는 에이전트에 민감한 원문을 전달하지 않는 격리 경계도 만들 수 있다.

2.3. 압축: 요약으로 토큰을 줄이기

1. 요약과 컴팩션
   1. 오래된 대화를 요약해 짧은 표현으로 바꾸면 토큰 소비가 줄어든다.
   2. 요약한 정보와 최근 메시지를 함께 유지하면 최근 작업의 세부성과 과거 맥락을 절충할 수 있다.
   3. 압축은 단순 삭제와 다르지만, 요약 과정에서 답에 필요한 정보가 사라질 위험을 반드시 확인해야 한다.

2.4. 격리: 에이전트별로 필요한 컨텍스트만 전달하기

1. 에이전트 간 컨텍스트 분리
   1. 멀티 에이전트 구조에서 모든 에이전트가 동일한 전체 창을 공유할 필요는 없다.
   2. 한 에이전트에만 필요한 자료를 다른 에이전트에 전달하면 쓸모없는 정보가 되어 상대 에이전트의 창을 오염시킨다.
   3. 필요한 상태나 포인터만 공유하면 역할별 컨텍스트를 작게 유지할 수 있다.

3. Strands Agents로 대화 컨텍스트 관리하기

Strands Agents는 한 줄의 에이전트 루프와 내장 대화 관리 전략으로 컨텍스트를 다루는 오픈 소스 프레임워크다.

3.1. 프레임워크의 성격과 세 가지 전략

1. Strands Agents의 기본 특성

   1. AWS가 유지 관리하는 완전한 오픈 소스·무료 프레임워크다.
   2. 특정 모델에 종속되지 않는 모델 중립적 구조를 지향한다.
   3. 한 줄의 코드로 에이전트 루프를 만들고, 노드와 그래프를 직접 구성하지 않아도 프레임워크가 내부 처리를 맡는다.
   4. 시스템 프롬프트와 도구를 지정하면 기본적으로 Amazon Bedrock과 연결해 간단하게 사용할 수 있다.
   5. Ollama, Gemini, Anthropic, OpenAI 계열 모델을 쓰고 싶으면 해당 라이브러리를 가져오고 모델 설정 한 줄을 추가하면 된다.

2. 슬라이딩 윈도우

   1. 가장 최근 메시지만 보존한다.
   2. 오래된 메시지를 창에서 밀어내므로 최근 작업의 응답성과 토큰 예산을 안정적으로 유지한다.
   3. 과거 세부사항을 다시 써야 하는 작업에는 별도 장기 메모리가 필요하다.

3. 요약 대화 관리자

   1. 이전 메시지들을 요약하고 최근 메시지를 보존한다.
   2. 전체 이력을 그대로 넣지 않으면서 이전 대화의 핵심 방향을 유지한다.
   3. 긴 세션에서 단순 슬라이딩 윈도우보다 더 많은 과거 맥락을 압축된 형태로 전달할 수 있다.

4. 요약과 최근 메시지의 결합

   1. 오래된 메시지는 요약으로 축약한다.
   2. 최신 메시지는 원문에 가깝게 남긴다.
   3. 과거의 큰 흐름과 현재 작업의 세부사항을 동시에 유지하는 절충안이다.

3.2. 50% 요약과 최근 네 메시지 보존

1. 대화 관리자 설정 예시

   1. 요약 비율을 50%로 설정한다.
   2. 마지막 네 개의 메시지는 그대로 보존한다.
   3. 에이전트가 해당 세션에서 실행될 때마다 이 정책에 따라 컨텍스트가 관리된다.

2. 장점과 한계

   1. 최근 네 메시지에는 현재 작업의 세부 명령과 도구 결과가 남아 즉각적인 응답이 쉬워진다.
   2. 오래된 절반은 요약되어 창의 성장 속도가 늦어진다.
   3. 모든 장기 기억이 창 안에 남는 것은 아니므로, 장기 메모리 계층이 필요하면 별도 저장소를 사용해야 한다.

4. 단기·장기·관계형 메모리

한 종류의 메모리로 모든 세션과 관계 정보를 처리하지 말고, 기억의 수명과 연결 구조에 따라 저장 방식을 나눈다.

4.1. 단기 메모리

1. 최근 세션의 대화 기록
   1. 단기 메모리는 현재 세션의 최근 대화를 저장한다.
   2. Strands의 슬라이딩 윈도우와 요약 대화 관리자는 이 단기 메모리를 컨텍스트 예산 안에서 관리한다.
   3. 세션이 진행되는 동안 즉시 필요한 지시와 도구 결과를 유지하는 역할을 한다.

4.2. 장기 메모리

1. 새 세션에서도 이어지는 기억
   1. 세션을 끝내고 새 세션을 시작하면 단기 메모리만으로 과거를 복원할 수 없다.
   2. 장기 메모리는 벡터 데이터베이스에 저장할 수 있다.
   3. 대화나 문서를 임베딩해 저장하고, 검색 프롬프트에 따라 필요한 과거 기억만 불러온다.
   4. 서로 다른 유형의 기억과 프롬프트를 사용해 어떤 과거 정보를 복원할지 제어할 수 있다.

4.3. 관계형 메모리

1. 엔터티 그래프로 연결 관계 보존

   1. 단순 유사도 검색만으로는 사람·서비스·사건 사이의 연결을 정확하게 표현하기 어려운 경우가 있다.
   2. 엔터티 그래프를 사용하면 무엇이 무엇과 연결되는지 관계를 보존할 수 있다.
   3. Neo4j 같은 그래프 데이터베이스와 그래프 순회(traversal)로 관련 노드와 경로를 찾을 수 있다.

2. 세 계층의 결합

   1. 단기 메모리는 현재 세션의 최근 흐름을 맡는다.
   2. 장기 메모리는 과거 세션과 문서에서 필요한 기억을 검색한다.
   3. 그래프 메모리는 별도 방식으로 보존해야 하는 엔터티와 관계를 관리한다.
   4. 세 가지를 함께 사용하면 최근 대화·과거 기억·관계 구조를 각자의 적절한 저장소에서 복원할 수 있다.

5. 로그를 메모리 포인터로 외부화하기

로그 원문을 에이전트의 창에 매번 넣는 대신, 원문을 보관하는 도구와 필요한 순간 원문을 회수하는 도구를 분리한다.

5.1. 저장 도구와 상태 포인터

1. 대량 로그의 처리 흐름

   1. 애플리케이션 로그를 가져오는 도구가 많은 로그를 반환한다.
   2. 두 번째 도구가 그 로그를 외부 저장소에 저장한다.
   3. 저장소는 로그에 대한 ID를 반환하고, 에이전트 상태(agent state)에 도구 관련 정보를 기록한다.
   4. 컨텍스트 윈도우에는 대량 원문 대신 메모리 포인터 ID를 보존한다.

2. 로그를 먼저 해석하지 않는 경로

   1. 로그를 저장·분류하는 도구가 “로그는 정상”처럼 작은 상태 응답을 에이전트에 보낼 수 있다.
   2. 에이전트는 정상 여부를 판단하기 위해 매번 원문 전체를 읽을 필요가 없다.
   3. 상세 근거가 필요해지는 순간 “이 ID의 로그를 가져와야 한다”고 요청하면 저장소에서 원문을 다시 가져온다.

5.2. Strands 도구 구현 예시

1. 두 도구의 역할

   1. fetch_application_logs는 애플리케이션 로그를 가져오는 도구다.
   2. 로그 저장 도구는 도구 컨텍스트의 agent_step_state를 활용해 저장 결과와 포인터 ID를 상태에 기록한다.
   3. 후속 도구는 포인터 ID로 저장된 로그를 회수하거나 로그의 상태를 짧게 전달한다.

2. 도구 데코레이터와 포인터 보존

   1. Strands에서는 도구 데코레이터로 두 도구를 만들 수 있다.
   2. 도구 컨텍스트에서 에이전트 단계 상태를 읽고, 외부 저장소 ID를 메모리 포인터로 생성한다.
   3. 컨텍스트에 저장되는 값은 거대한 로그가 아니라 이후 호출에 사용할 수 있는 작은 식별자다.

6. 멀티 에이전트 스웜에서 컨텍스트 격리하기

여러 에이전트를 묶을수록 전체 창을 공유하는 방식의 낭비가 커지므로 호출 상태 포인터만 공유한다.

6.1. 전체 컨텍스트 공유의 문제

1. 모든 에이전트가 모든 정보를 필요로 하지는 않는다
   1. 복잡한 애플리케이션에서는 도구만으로 부족해 멀티 에이전트 애플리케이션이나 에이전트 스웜을 사용할 수 있다.
   2. 모든 에이전트가 같은 컨텍스트 윈도우를 공유하면 한 에이전트의 대량 데이터가 다른 에이전트에게 불필요한 쓰레기가 된다.
   3. 불필요한 공유는 토큰 소비를 늘리고, 각 에이전트가 자기 역할과 무관한 자료를 해석하게 만든다.

6.2. 호출 상태 포인터 공유

1. 공유해야 하는 최소 정보

   1. 스웜에 참여하는 에이전트 사이에 ID를 만든다.
   2. 전체 원문 대신 invocation state에 저장된 포인터를 공유한다.
   3. 필요한 에이전트만 ID를 사용해 같은 외부 데이터를 회수한다.

2. Strands 스웜의 구조

   1. 에이전트 루프나 도구 핸들러 사이에서 호출 상태를 넘긴다.
   2. 각 에이전트는 자기 역할에 필요한 결과만 컨텍스트에 넣는다.
   3. 동일 대용량 데이터를 여러 에이전트가 써야 할 때도 원문 복제 대신 상태와 포인터 공유로 처리한다.

7. 무한 도구 호출 루프 차단하기

컨텍스트를 작게 유지해도 에이전트가 같은 도구를 계속 호출하면 실행이 끝나지 않으므로 호출 횟수와 응답 형식을 제한한다.

7.1. 명확한 도구 응답

1. 무한 루프의 원인

   1. 어떤 에이전트는 같은 도구를 반복 호출하면서 루프에 빠진다.
   2. 도구를 호출했는데 명확한 응답이 돌아오지 않으면 에이전트가 작업이 끝났는지 판단하기 어렵다.
   3. 불분명한 상태는 같은 검색이나 같은 외부 호출을 다시 시도하게 만든다.

2. 도구 계약의 명료화

   1. 도구는 성공·실패·진행 중 상태를 명확하게 반환해야 한다.
   2. 응답에 다음 행동에 필요한 값과 종료 조건을 포함해야 한다.
   3. 에이전트가 결과를 해석하기 위해 같은 도구를 재호출하는 일을 줄일 수 있다.

7.2. 도구별 최대 호출 횟수

1. 호출 상한 설정

   1. 도구마다 최대 호출 횟수를 설정한다.
   2. 예시로 search_flights 도구는 세 번만 호출할 수 있고, 다른 도구도 세 번으로 제한할 수 있다.
   3. 상한에 도달하면 내부 루프가 계속되지 않고 실패·대체 경로·최종 응답으로 넘어간다.

2. 호출 상한의 효과

   1. 에이전트가 스스로 멈추지 못하는 상황을 시스템이 강제로 종료할 수 있다.
   2. 불필요한 API 비용과 지연을 제한한다.
   3. 같은 도구가 반환하는 대량 결과가 컨텍스트에 반복해서 누적되는 것도 막는다.

8. 비동기 MCP와 외부 API 핸들

비동기 처리는 컨텍스트를 직접 줄이는 기법은 아니지만, 오래 걸리는 도구 호출이 에이전트 전체를 멈추게 하는 일을 막아 컨텍스트 운영을 안정화한다.

8.1. 동기 호출의 지연 문제

1. MCP와 외부 API의 응답 시간

   1. MCP 도구나 외부 API가 필요한 시점에 바로 답하지 않는 경우가 있다.
   2. AWS API Gateway처럼 응답을 기다릴 수 있는 최대 시간이 정해진 시스템도 있다.
   3. 동기 호출이 끝날 때까지 기다리면 지연 때문에 애플리케이션이 중단되거나 에이전트가 멈춘 것처럼 보일 수 있다.

2. 동기와 비동기의 차이

   1. 동기 핸들은 외부 작업이 끝날 때까지 에이전트가 계속 기다리게 한다.
   2. 비동기 핸들은 작업을 시작한 뒤 결과를 저장하고, 다음 호출이나 필요한 시점에 상태를 조회한다.
   3. 에이전트는 긴 작업의 원문 결과를 기다리는 대신 작업 ID와 현재 상태만 컨텍스트에 유지할 수 있다.

8.2. FastAPI 기반 MCP 예시

1. 두 단계 도구 설계

   1. FastAPI로 MCP를 만들 때 도구만 정의하면 된다.
   2. 첫 번째 도구는 장시간 작업을 시작하는 start_job 역할을 맡는다.
   3. 두 번째 도구는 작업 ID를 받아 check_job_status 역할로 진행 상태와 완료 결과를 반환한다.

2. 테스트에서 확인한 운영 차이

   1. 긴 작업을 동기적으로 기다리는 구현은 에이전트 응답을 멈추게 만들 수 있다.
   2. 한 실험에서는 세션을 닫는 데 6분이 걸릴 정도로 대기 상태가 길어졌다.
   3. 비동기 시작·상태 조회 구조는 작업을 저장해 두고 필요할 때 결과를 회수하므로 장시간 응답 대기를 분리한다.
   4. 적합한 핸들 방식은 구축하는 애플리케이션의 작업 시간과 외부 시스템 특성에 따라 선택한다.

9. 콘텐츠 스터핑을 피하는 최종 체크리스트

컨텍스트 창을 크게 만드는 대신 질문에 답하는 데 필요한 데이터의 경로와 수명을 설계한다.

9.1. 모든 정보를 넣지 않기

1. 콘텐츠 스터핑의 문제

   1. 컨텍스트 윈도우에 모든 로그·데이터베이스·알림·문서를 넣을 필요가 없다.
   2. 에이전트는 사용자 질문에 답하는 데 필요한 정보만 받으면 된다.
   3. 지나치게 많은 입력은 토큰 비용, 중간 정보 망각, prompt injection 노출, 응답 지연을 함께 키운다.

2. 네이티브 요약의 한계

   1. 프레임워크의 네이티브 요약 기능을 사용할 수 있다.
   2. 그러나 자동 요약은 에이전트가 답하기 위해 꼭 필요한 세부사항을 빠뜨릴 수 있다.
   3. 어떤 요약기를 쓰더라도 답 생성에 필요한 사실이 요약문에 남았는지 검증해야 한다.
   4. 요약만 믿지 말고 원문은 외부 저장소에 보존해 포인터로 다시 회수할 수 있게 만든다.

9.2. 실전 매핑

1. 도구가 대용량 데이터를 반환할 때

   1. 로그·데이터베이스·알림을 외부화한다.
   2. 필요한 부분을 선택한다.
   3. 메모리 포인터를 컨텍스트에 남긴다.

2. 여러 에이전트가 같은 대용량 데이터를 사용할 때

   1. 단계·에이전트 루프·도구 핸들러 사이에서 호출 상태를 공유한다.
   2. 모든 에이전트에 전체 원문을 복제하지 않는다.
   3. 각 에이전트가 필요한 순간 포인터로 데이터를 회수하게 한다.

3. 도구 실행이 불안정할 때

   1. 도구가 명확한 상태와 결과를 반환하게 한다.
   2. 도구별 호출 횟수 상한을 둔다.
   3. 오래 걸리는 외부 작업에는 비동기 시작·상태 조회 핸들을 사용한다.

주요 발언 모음

“Bigger context windows do not fix the problem.”

“Context engineering is giving the model the information it needs when it needs it.”

“Sometimes the context window is poison to the engine because you can have a prompt injection inside your context window.”

“You don't need to include everything in the context window.”

“Many agents need the same large data: share the invocation state and use a memory pointer.”

“Clear answer for the tool, limited counts, and an async handle.”

핵심 데이터 & 수치

• 15분 54초: 발표 분량이다.
• 약 1년 전: 더 많은 토큰과 더 큰 창이 문제를 해결할 것이라는 기대가 강했던 시점을 가리킨다.
• 50%: Strands 요약 대화 관리자 예시의 요약 비율이다.
• 최근 4개 메시지: 요약 관리자 예시에서 원문으로 보존하는 메시지 수다.
• 3회: search_flights 같은 도구에 설정한 예시 최대 호출 횟수다.
• 6분: 동기 대기 실험에서 세션 종료까지 걸릴 수 있다고 언급된 시간이다.
• 3가지 메모리: 현재 세션을 위한 단기 메모리, 벡터 검색 기반 장기 메모리, 엔터티 연결을 위한 관계형 그래프 메모리다.
• 1줄 코드: Strands가 에이전트 루프·노드·그래프 구성을 대신해 주는 사용성의 핵심 예시다.

결론 및 시사점

1. 더 큰 컨텍스트 윈도우를 만능 해결책으로 취급하지 말고 정보의 수명과 필요 시점을 설계해야 한다.
2. 대량 결과는 영구 저장소로 외부화하고 작은 메모리 포인터만 컨텍스트에 남겨야 한다.
3. 검색 단계에서 관련 데이터만 선택해 토큰 비용과 prompt injection 노출을 줄여야 한다.
4. 오래된 대화는 요약하되 답에 필요한 세부사항이 사라지지 않는지 검증해야 한다.
5. 단기·장기·관계형 메모리를 각각의 목적에 맞게 조합해야 한다.
6. 멀티 에이전트에는 전체 창 대신 호출 상태와 포인터만 공유해야 한다.
7. 도구는 명확한 상태와 종료 조건을 반환해야 한다.
8. 도구별 최대 호출 횟수를 설정해 무한 루프와 비용 폭증을 막아야 한다.
9. 장시간 MCP·외부 API 작업은 비동기 시작과 상태 조회로 분리해야 한다.
10. Strands Agents는 이러한 컨텍스트 관리 패턴을 간단한 에이전트 루프에 붙일 수 있는 오픈 소스 선택지다.

직접 서술형 핵심 요약 20줄

• 에이전트의 컨텍스트 윈도우가 커져도 대량 도구 결과에 따른 오버플로와 환각은 사라지지 않는다.
• 로그를 매 세션마다 다시 넣으면 에이전트의 컨텍스트가 계속 성장하고 토큰 비용도 증가한다.
• attention U-curve 때문에 지나치게 큰 입력에서는 모델이 중간 내용을 잊고 처음과 끝을 더 잘 기억한다.
• 컨텍스트 엔지니어링은 모델이 필요한 정보를 필요한 시점에 받게 하는 정보 공급 설계다.
• 불필요한 컨텍스트는 토큰을 낭비하고 prompt injection을 모델의 입력에 섞을 수 있다.
• 대용량 로그와 데이터베이스 결과는 영구 저장소로 외부화하고 메모리 포인터를 남겨야 한다.
• 관련 있는 데이터만 선택해서 가져오면 응답 품질과 비용을 함께 관리할 수 있다.
• 오래된 대화는 요약하고 최근 메시지는 보존하는 압축 전략이 유용하다.
• Strands Agents는 슬라이딩 윈도우와 요약 및 두 방식의 결합을 제공한다.
• Strands의 요약 관리자 예시는 과거 절반을 요약하고 최근 네 메시지를 유지한다.
• 단기 메모리는 현재 세션을 저장하고 장기 메모리는 벡터 데이터베이스에서 과거를 검색한다.
• 관계형 메모리는 Neo4j 같은 엔터티 그래프와 그래프 순회로 사물 사이 연결을 보존한다.
• 로그 저장 도구는 원문을 외부화하고 에이전트에는 저장소 ID와 짧은 상태를 반환할 수 있다.
• 상세 로그가 필요해지는 순간 에이전트가 메모리 포인터를 사용해 원문을 회수하면 된다.
• 멀티 에이전트 스웜은 전체 컨텍스트 대신 invocation state 포인터를 공유해야 한다.
• 명확한 도구 응답은 에이전트가 같은 도구를 반복 호출하는 무한 루프를 줄인다.
• 도구별 호출 횟수를 세 번처럼 제한하면 내부 루프와 비용 폭증을 차단할 수 있다.
• 오래 걸리는 MCP와 외부 API는 비동기 작업 시작과 상태 조회 도구로 분리해야 한다.
• 네이티브 요약을 쓰더라도 답에 필요한 사실이 누락되지 않았는지 확인해야 한다.
• 안정적인 에이전트 아키텍처는 큰 창보다 외부화·선택·압축·격리와 명확한 도구 계약에 달려 있다.

마무리

Strands Agents 부스에는 추가 학습을 위한 전문가와 기념품이 준비되어 있으며, 아마존 레고도 받을 수 있다는 안내가 이어진다. 엘리자베스 푸엔테스 레온은 자신이 모건이 아니라는 점을 다시 강조하고 웃음과 함께 인사를 마친다.