Context Engineering in 2026 — Louis-François Bouchard, Omar Solano & Samridhi Vaid, Towards AI

한 줄 핵심

이 영상은 AI 튜터 사례를 통해 모델 자체보다 컨텍스트 설계가 품질·비용·지연시간을 좌우하며, 많은 경우 요약·압축보다 원문 유지와 캐시 활용이 더 나은 선택임을 실험으로 보여준다.

시간별 요약

1. 0:00
   문제는 모델이 아니라 컨텍스트다 에이전트가 기대와 다르게 동작하는 핵심 원인은 모델 성능 저하보다 컨텍스트가 점점 차서 품질이 무너지는 데 있다. 따라서 하네스나 모델을 바꾸기 전에 무엇이 컨텍스트를 망치고 있는지 먼저 봐야 한다.
2. 1:30
   AI 튜터와 다섯 가지 요구사항 AI 튜터는 강의 내용에 근거해 답하고, 여러 강의 중 현재 범위를 정확히 잡아야 하며, 긴 디버깅 세션도 버텨야 한다. 여기에 코드 처리와 낮은 지연시간까지 필요해 컨텍스트 엔지니어링이 핵심 과제가 된다.
3. 5:21
   두 가지 근본 문제: 제한된 창, 상태 없는 모델 컨텍스트 윈도우는 유한하고 모델은 상태를 기억하지 못하므로, 매번 무엇을 넣고 무엇을 버릴지 설계해야 한다. 이 작업은 세션 내부의 컨텍스트 관리와 세션 간 메모리로 나뉘며, 여기서는 전자에 집중한다.
4. 7:52
   컨텍스트 부패, 비용, 지연시간 오래된 tool outputs가 누적되면 품질이 떨어지는 context rot가 생기고, 같은 토큰을 다시 보내는 구조 때문에 비용도 반복해서 발생한다. 또한 응답 시작까지 걸리는 시간이 늘어나 사용자 경험이 나빠진다.
5. 9:13
   압축 도구상자, LLM 유무에 따라 압축은 꼭 LLM이 있어야 하는 일이 아니며, 긴 tool output을 자르거나 sliding window를 쓰는 것만으로도 효과가 있다. LLM을 쓰는 경우에는 선택적 유지, 점진적 요약, 전체 재시작형 요약 같은 방법이 가능하지만, 모든 경우에 요약이 최선은 아니다.
6. 12:58
   파일로 넘기기, LLM 위키, 점진적 공개 필요한 정보를 파일과 인덱스로 옮겨두면 손실 없이 나중에 다시 불러올 수 있어 시스템이 더 저렴하고 오래간다. 작은 인덱스에서 시작해 필요할수록 chunk와 원본 파일로 깊게 들어가는 방식이 복잡도에 맞춰 컨텍스트를 점진적으로 공개하는 핵심이다.
7. 16:47
   Prompt caching, 그리고 압축이 역효과가 나는 이유 캐시는 기존 토큰을 다시 계산하지 않게 해 비용과 지연시간을 크게 줄인다. 그런데 요약이나 변환을 하면 새 컨텍스트가 되어 캐시를 못 쓰므로, 압축 이득이 캐시 손실보다 훨씬 커야만 의미가 생긴다.
8. 19:20
   언제 지우고, 압축하고, 캐시 적중을 노릴지 주제가 바뀌면 세션을 비우고, 불필요한 tool outputs는 제거하며, 필요할 때만 압축해야 한다. 동시에 캐시 적중률, 이상 행동, 사용자 불만 같은 로그를 남겨야 실제로 어떤 전략이 유효한지 볼 수 있다.
9. 21:53
   튜터 아키텍처, 단일 ReAct 에이전트 AI 튜터는 단일 ReAct 에이전트와 LangChain middleware로 구성되며, in-memory saver로 현재 대화만 관리한다. 핵심 도구는 hybrid search 기반 retrieval과 knowledge base를 직접 탐색하는 browse 기능이며, FastAPI와 Next.js UI로 감싼다.
10. 25:49
    8백만 토큰 코퍼스 위의 하이브리드 검색 수업 자료와 여러 공개 문서가 합쳐진 8 million token 코퍼스는 한 번에 다 넣을 수 없으므로 검색이 필요하다. semantic search와 BM25를 합친 뒤 rerank해 상위 chunk만 반환하고, 100,000 tokens 한도로 잘라서 컨텍스트에 넣는다.
11. 28:28
    에이전트에게 지식베이스를 직접 탐색하게 하기 원본, 생성된 색인, wiki 형태의 요약 파일을 분리해 두고 에이전트는 읽기 전용 bash로만 탐색하게 한다. 다만 긴 실행 제한, 출력 길이 제한, 명령 수 제한과 sandbox를 둬야 안전하게 운용할 수 있다.
12. 31:01
    탐색 도구 측정 결과: 회수율은 같고, 속도는 50% 느림 knowledge base를 직접 탐색하게 해도 recall은 기존 retrieval과 크게 다르지 않았지만, tool call이 늘어 전체 속도는 약 50% 느려졌다. 즉, 추가 탐색은 흥미롭지만 실제 정확도 개선이 없으면 비용만 늘릴 수 있다.
13. 36:23
    실험 설계: 프리셋, 과제, 하네스 프리셋은 컨텍스트 전략 조합, 과제는 단일 턴과 멀티 턴 세션, run과 bundle은 실행 결과와 저장된 메트릭을 뜻한다. 평가 데이터는 실제 학생 질문을 정리한 뒤, retrieval 정확도와 답변 사실성을 자동 채점하도록 구성했다.
14. 42:55
    결과: 아무것도 하지 않는 것이 세 가지 모두에서 승리 Gemini 3.5 flash 기준으로는 컨텍스트를 건드리지 않고 full history를 유지하는 방식이 기억력, 비용, 지연시간 모두에서 가장 좋았다. 불필요한 요약과 삭제는 오히려 tool call을 늘려 더 느리고 더 비싸게 만들었다.
15. 48:13
    정말로 압축해야 할까? 장기 대화, 붙여넣은 문서, tool output은 서로 다른 컨텍스트라서 같은 처방을 쓰면 안 된다. 프론티어 모델에서 full history가 잘 작동하는데도 비용 때문에 압축을 습관적으로 넣는 것은 다시 생각해야 한다.
16. 49:32
    DeepSeek과 50배 캐시 할인 DeepSeek에서는 캐시 할인 덕분에 동일한 full history 전략이 훨씬 싸게 동작했고, 여전히 성능도 가장 좋았다. 요약은 새 토큰을 계속 만들어 캐시 이점을 잃게 하므로, 캐시가 큰 모델일수록 더 불리해질 수 있다.
17. 50:53
    메모리: 요약 후 32% vs 원문 유지 95% 대화 속 세부 정보를 맞히는 실험에서 원문을 유지하면 95% 수준의 정확도를 보였지만, 요약이나 압축을 하면 32%로 크게 떨어졌다. 세부 디버깅 정보처럼 작은 차이가 중요한 업무에서는 요약이 기억 손실로 이어진다.
18. 54:38
    대규모 비용과 로컬 전환 턴 수가 많아질수록 per-turn 비용은 누적되어, 학생 수가 많으면 월 비용이 매우 커진다. 그래서 local model도 검토했지만, 하드웨어 제약과 작은 context window 때문에 결국 압축이나 retrieval이 필요했다.
19. 57:09
    로컬 한계: 모델이 커져도 창은 그대로 모델 크기를 키워도 context window 자체는 늘어나지 않으므로, 긴 대화는 여전히 담을 수 없다. 반면 문서형 입력에서는 retrieval이 매우 잘 작동해 100% 정확도에 가까운 결과를 낼 수 있었다.
20. 58:25
    dense retrieval이 실패하는 지점과 BM25의 강점 dense retrieval은 긴 문서에서 중간에 묻힌 사실을 놓치기 시작했지만, BM25는 끝까지 100%에 가깝게 유지됐다. 그래서 실제 튜터는 semantic search만이 아니라 BM25를 섞은 hybrid search를 써야 한다.
21. 1:01:01
    최종 선택 최종적으로는 DeepSeek V4 flash, hybrid retrieval, 그리고 메모리는 기본적으로 유지하되 30k tokens 이후에만 compact하는 구조를 채택했다. 핵심 결론은 기본값으로 압축하지 말고, 비용·지연·정확도 중 무엇이 제약인지 먼저 명확히 한 뒤 전략을 고르는 것이다.

실무 인사이트

• 긴 대화에서 요약은 기본 해법이 아니라 최후 수단이며, 캐시가 잘 먹는 환경에서는 full history 유지가 더 싸고 정확할 수 있다.
• 문서 검색은 dense retrieval 단독보다 BM25를 섞은 hybrid search가 안정적이며, 특히 긴 코퍼스나 중간에 묻힌 사실에 강하다.
• 컨텍스트 전략은 한 번 정하면 끝이 아니라, 실제 질문 로그로 recall·latency·cache hit을 함께 측정하며 계속 조정해야 한다.