2026년 컨텍스트 엔지니어링 — AI 에이전트의 기억과 추론 설계

URL: https://www.youtube.com/watch?v=WP3hjUXd918
날짜: 2026-08-18
채널: aiDotEngineer
발표: Louis-François Bouchard, Omar Solano, Samridhi Vaid (Towards AI)

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

==에이전트의 답변 품질·비용·속도를 동시에 좌우하는 것은 어떤 모델을 고르는가보다 매 호출 때 모델에게 어떤 컨텍스트를 보여주는가이며, 컨텍스트를 줄이는 것이 항상 정답은 아니다.==

• 모델의 컨텍스트 윈도(context window)는 유한하고, 모든 지시·문서·도구 결과·대화·사용자 코드가 같은 공간을 차지한다.
• 모델은 기본적으로 상태가 없으므로 세션 안에서는 컨텍스트 관리(context management), 세션 사이에서는 메모리(memory)를 별도로 설계해야 한다.
• 자동 요약·압축(compaction)은 토큰을 줄이지만 프롬프트 캐시(prompt cache)를 깨고, 이미 알고 있던 사실을 제거해 재검색을 유발할 수 있다.
• Towards AI의 실제 AI 튜터 실험에서는 Gemini와 DeepSeek 모두 컨텍스트를 그대로 유지하는 방식이 짧은 대화에서 기억 회수·비용·속도 모두 가장 좋았다.
• 로컬 모델처럼 컨텍스트 윈도 자체가 제약일 때만 검색과 압축을 적극적으로 사용하고, 클라우드 API에서는 캐시 적중률과 실제 측정 결과를 바탕으로 조건부 압축해야 한다.

컨텍스트 엔지니어링은 프롬프트 한 문장을 잘 쓰는 작업이 아니라, 매번 모델이 보게 될 정보의 선택·배치·보존·삭제·캐시·검색을 설계하는 운영 문제다. 핵심 원칙은 “일단 줄인다”가 아니라 “현재 제약을 이름 붙이고, 그 제약에 맞는 최소한의 변환만 실제 평가로 선택한다”는 것이다.

1. 문제의 출발점: 에이전트가 엉뚱한 일을 하는 이유

컨텍스트가 누적되면 모델을 바꾸는 것보다 먼저 현재 컨텍스트가 어떻게 변질됐는지 확인해야 한다.

1.1. 발표의 도입과 문제 제기

1. 가벼운 농담으로 시작한 워크숍

   1. 발표자는 “게임을 보지 않고 참석해줘서 고맙다”고 인사하고, 독일이 이기기를 기대하는 것보다 오늘의 내용이 조금 더 흥미롭고 적어도 뭔가를 배워 가는 시간이 되길 바란다고 농담한다.
   2. 주제는 2026년의 컨텍스트 엔지니어링(Context Engineering)이며, Towards AI의 AI 튜터를 실제 사례로 삼는다.

2. 에이전트가 사용자의 의도와 정반대로 움직이는 순간

   1. 에이전트에게 일을 시켰는데 원하지 않은 일을 정확히 해버리면 사용자는 화가 나서 “다시 해”라고 입력하며 모델이 그제야 학습하기를 기대하게 된다.
   2. 이때 문제는 반드시 모델이 멍청해졌거나 Claude, Codex 또는 사용 중인 하네스(harness)를 바꿔야 한다는 뜻이 아니다. 대화와 도구 결과가 컨텍스트를 채우면서 결과가 점점 나빠지는 컨텍스트 럿(context rot)일 수 있다.
   3. 발표자의 표현대로, 문제는 모델 자체보다 “컨텍스트가 차고 또 차면서” 모델이 무엇을 봐야 하는지 잃어버리는 데 있다.

1.2. 실제 사업에서의 실패 비용

1. AI 튜터의 사용 사례

   1. Towards AI는 AI 엔지니어를 위한 강의와 훈련을 만들며, 수강생의 질문에 강의 내용을 바탕으로 답하는 AI 튜터를 제공한다.
   2. 튜터가 질문을 엉뚱하게 처리하면 수강생은 서비스가 아니라 회사에 화를 내고 환불을 요청할 수 있다. 따라서 컨텍스트 엔지니어링은 품질 이론이 아니라 매출·신뢰와 연결된 제품 문제다.

2. 워크숍의 범위와 공개 자료

   1. 팀은 AI 튜터를 개선하고 실행 비용을 낮추기 위해 여러 실험을 진행했다.
   2. QR 코드는 실험을 직접 확인할 수 있는 Hugging Face Space로 연결되며, AI 튜터와 저장소도 오픈 소스다. Hugging Face에서 온라인 튜터와 실험을 확인하고 코드까지 살펴볼 수 있다.
   3. 약 80분 동안 먼저 Louis가 압축·메모리 검색 등 일반 기법을 설명하고, 이어 Omar가 튜터 아키텍처와 초기 평가를, Samridhi가 확장 평가와 최종 선택을 공유하는 순서로 진행한다.

2. 컨텍스트의 두 가지 근본 제약

2.1. 유한한 컨텍스트 윈도

1. 모든 것이 같은 공간에 들어간다

   1. 시스템 프롬프트, 강의 내용, 도구 정의, 도구 호출 및 결과, 대화 기록, 검색한 강의 조각, 사용자의 질문과 코드가 모델의 컨텍스트에 함께 들어간다.
   2. 컨텍스트 윈도는 유한하므로 더 많은 내용을 쌓을수록 토큰 비용이 증가하고, 긴 컨텍스트를 처리하는 동안 답변 품질도 악화된다.
   3. 사용자 질문 자체는 보통 가장 작은 부분이지만, 디버깅할 코드나 에러 로그가 붙으면 질문만으로도 큰 입력이 될 수 있다.

2. 가장 빠르게 커지는 부분은 오래된 도구 결과다

   1. 여러 턴에 걸쳐 호출한 모든 도구의 호출·결과 쌍, 검색으로 가져온 예전 강의 조각, 파일 검색 결과가 계속 남는다.
   2. 에이전트가 자체 메모리에서 수행한 검색 결과까지 누적되면 실제 질문과 무관한 정보가 컨텍스트의 상당 부분을 차지한다.
   3. LLM은 긴 컨텍스트 전체를 전역적으로 관리하도록 학습된 것이 아니라 많은 사실이 들어온 상황에서 패턴을 찾아 답하도록 학습됐다. 따라서 사실을 계속 주입한다고 전체 맥락을 더 잘 이해하는 것은 아니다.

2.2. 상태가 없는 모델과 세션 경계

1. 모델은 기본적으로 stateless다

   1. 수강생이 AI 튜터를 닫았다가 다시 열면, 별도 메모리 계층을 만들지 않는 한 모델은 무슨 일이 있었는지 전혀 모른다.
   2. 따라서 세션 내부의 컨텍스트 관리와 세션 간의 메모리 설계를 구분해야 한다.

2. 이번 워크숍의 초점

   1. 메모리는 텍스트를 파일이나 서버에 저장하고 나중에 검색하는 문제까지 포함하지만, 이번 실험에서는 먼저 한 세션이 이미 나빠지지 않도록 컨텍스트 관리에 집중한다.
   2. 한 세션의 품질이 좋지 않다면 여러 세션을 연결하는 메모리를 붙여도 도움이 되지 않으므로, 메모리는 향후 별도 워크숍 주제로 남긴다.

3. 컨텍스트를 관리하는 기본 도구 상자

컨텍스트를 줄이는 방법은 단순한 문자열 처리부터 작은 모델을 이용한 압축, 외부 저장소로의 오프로딩까지 단계가 있다.

3.1. 언어 모델 없이 하는 가장 싼 처리

1. 이상치 도구 결과 잘라내기

   1. 웹 검색이나 코드 실행처럼 보통 10줄 정도를 내야 하는 도구가 300줄을 내면, 결과의 머리(head)와 꼬리(tail)만 남기고 중간을 자른다.
   2. “중간 결과가 잘렸다(truncated)”고 표시하면 모델은 나중에 정보가 부족할 때 같은 도구를 다시 호출할 수 있다.

2. 슬라이딩 윈도(sliding window)와 트리밍

   1. 가장 최근의 사용자 턴 n개만 남기고 이전 턴을 버리는 방법이다.
   2. n의 값은 시스템과 사용자의 대화 패턴에 따라 정해야 하며, 모든 애플리케이션에 맞는 보편적 숫자는 없다.

3. 도구별 결과 지우기

   1. 특정 도구는 과거 결과가 다시 필요하지 않을 수 있으므로, 도구의 성격을 알고 있다면 결과 대부분을 항상 지우는 정책을 둘 수 있다.
   2. 이 단계는 언어 모델을 다시 호출하지 않으므로 토큰을 더 쓰지 않고 실행할 수 있다.

3.2. 언어 모델을 사용한 압축

1. 선택적 보존(selective retention)

   1. 작은 언어 모델이 대화가 어떤 방향으로 진행되는지 보고 무엇을 남기고 무엇을 버릴지 결정한다.
   2. 모든 도구 결과를 일률적으로 제거하는 것보다 현재 논점에 필요한 사실을 보존할 가능성이 있다.

2. 지속적 요약과 임계치 리셋

   1. 이전 턴을 계속 요약해 요약본과 최근 대화를 함께 유지하는 방식이다.
   2. Claude Code처럼 컨텍스트 한계에 도달하면 전체 대화를 요약하고, 그 요약으로 컨텍스트를 완전히 초기화할 수도 있다.
   3. 요약은 토큰을 소비해 더 많은 토큰을 절약하는 전략이므로, 요약 호출 비용과 정보 손실을 함께 측정해야 한다.

3. 델타 요약(delta summarization)

   1. 요약을 매번 처음부터 다시 만드는 대신, 기존 요약을 유지하면서 새로 생긴 정보에 대한 델타를 반영한다.
   2. 서브에이전트(sub-agent)를 여러 개 띄울 때 유용하다. 서브에이전트가 요약을 계속 갱신해 메인 에이전트에 넘길 수 있기 때문이다.
   3. Towards AI의 튜터는 단일 메인 에이전트만으로 잘 작동하므로, 현재는 서브에이전트와 델타 요약의 복잡성을 추가하지 않았다.

3.3. 외부로 오프로딩하기

1. 파일 메모리와 검색 증강 생성(RAG)

   1. 정보 전체를 컨텍스트에 계속 넣는 대신 문서·메모리 파일로 저장하고 필요할 때만 가져온다.
   2. RAG(Retrieval-Augmented Generation)는 오래된 기법이지만 여전히 강력한 선택지다.
   3. 파일로 옮긴 정보는 삭제하는 것이 아니라 저장하는 것이므로 완전히 가역적(reversible)이다. 같은 수강생이 훗날 관련 질문을 하면 다시 참조할 수 있고, 사람과 에이전트 모두 내용을 검사하기 쉽다.

2. LLM wiki 구조

   1. Karpathy가 제안한 LLM wiki 아이디어처럼, 정보를 작은 청크(chunk)로 나누고 청크끼리 포인터로 연결한다.
   2. 각 청크는 원본이 들어 있는 raw data 파일과 연결되고, 별도의 인덱스 하나가 모든 청크의 링크와 주제 설명을 매핑한다.
   3. 에이전트에게 처음부터 전체 문서를 주지 않고 약 450토큰 정도의 작은 인덱스만 보여준다.
   4. 질문이 단순하면 인덱스에서 필요한 청크까지만 읽고, 복잡하면 청크가 가리키는 원본 파일까지 내려가 더 많은 맥락을 가져온다. 작업 복잡도에 따라 가져오는 컨텍스트 양이 달라지는 구조다.

3. 그래프 RAG와 일반 RAG의 선택

   1. 팀은 Graph RAG도 비교했지만 실제 사용자 평가를 기준으로 한 이번 사례에서는 설치·구성 비용이 훨씬 높고 결과의 이점이 없었다.
   2. 데이터셋이 매우 크고 주제 사이의 관계가 촘촘하게 연결되어 있다면 Graph RAG가 가치 있을 수 있으므로, 모든 사례에서 배제하라는 뜻은 아니다.

4. 작고 정밀한 스킬과 점진적 공개(progressive disclosure)

   1. 고객 작업과 자체 구축 경험을 보면 2026년에는 더 많고 더 작은 스킬로 수렴하고 있다.
   2. 하나의 거대한 스킬보다 매우 정밀한 작은 스킬을 만들고 서로 참조하게 하면 컨텍스트를 절약할 수 있다.
   3. 스킬을 한 번에 전부 로드하지 않고 필요한 순간 하나씩 로드하면, 특정 스킬만 가진 서브에이전트를 띄우기도 쉬워진다.

4. 압축보다 먼저 봐야 할 프롬프트 캐싱

4.1. 반복 토큰의 비용 구조

1. 매 후속 질문마다 이전 토큰을 다시 계산하는 문제

   1. 대화가 이어지면 이전 토큰을 두 번, 세 번, 네 번씩 다시 보내고 다시 계산하게 된다.
   2. 제공업체는 이를 줄이기 위해 프롬프트 캐싱(prompt caching)을 제공한다. 이미 보낸 토큰의 임베딩과 KV 캐시를 보존해 다음 호출에서 재사용하는 방식이다.

2. 캐시 토큰은 매우 싸고 빠르다

   1. DeepSeek 같은 API에서는 재사용 토큰이 새 토큰보다 최대 50배 저렴할 수 있다. 일반적으로도 캐시를 사용하면 비용의 약 90%를 절감하는 경우가 있다.
   2. 새 사용자 질문 부분만 정상 가격으로 내고, 긴 과거 컨텍스트는 50분의 1 수준으로 처리할 수 있다.
   3. 캐시된 토큰은 이미 계산되어 있으므로 첫 토큰까지의 시간(TTFT, time to first token)도 줄어든다.

4.2. 압축이 캐시를 깨뜨리는 역설

1. 변환된 컨텍스트는 새 컨텍스트로 보인다

   1. 요약이나 압축은 기존 컨텍스트를 변환해 새로운 토큰을 만든다.
   2. 제공업체는 그것이 같은 주제의 변형이라는 사실을 지능적으로 이해하지 못하므로, 캐시를 재사용하지 못하고 새 요약 토큰 전체를 정상 가격으로 계산한다.

2. 손익분기점이 매우 높다

   1. 캐시를 죽이고 새 토큰을 만드는 압축이 이득이 되려면, 컨텍스트를 50배 이상 줄여야 할 수 있다.
   2. 그렇게 많이 줄이면서 품질을 잃지 않는 일은 어려우므로 요약은 잠재적인 함정이다.
   3. 진지한 코딩 하네스들은 캐시를 쓰면서도 다른 방식의 컨텍스트 관리와 조건부 압축을 함께 사용한다. 따라서 직접 하네스를 만드는 팀은 언제 캐시를 유지하고 언제 압축할지를 측정해야 한다.

4.3. 실무 운영 원칙

1. 사용자가 완전히 다른 주제로 넘어가면 세션을 새로 시작해 컨텍스트를 깨끗하게 만들 수 있다.
2. 파일과 스킬은 점진적 공개 방식으로 필요한 최소량만 보여준다.
3. 더 이상 유용하지 않은 오래된 도구 결과는 지운다.
4. 압축은 항상 하지 말고, 실험으로 이익이 확인되는 경우에만 실행한다.
5. 제공업체의 캐시 관리 기능은 계속 바뀌므로 현재 API가 제공하는 캐시 수명·경계·재사용 기능을 따라가야 한다.
6. 여러 작업에 모델 라우터(model router)를 사용하면 작업별 비용을 최적화할 수 있다.
7. 대부분의 팀이 놓치는 일이지만 모든 것을 로깅해야 한다. Claude 같은 코딩 에이전트에게 관측성(observability) 구현을 맡기면 어렵지 않다.
   1. 입력·출력 토큰 수와 캐시 적중률(cache hit rate)을 기록한다.
   2. 비용, TTFT, 전체 응답 시간, 도구 호출 수, 압축 발생 여부를 기록한다.
   3. 사용자가 “마음에 들지 않는다”고 표시한 횟수처럼 사용자 불만·좌절(frustration)을 기록한다.
   4. 비정상적으로 긴 출력이나 작은 모델이 감지할 수 있는 이상 행동도 기록한다.

5. Towards AI AI 튜터의 시스템 설계

Omar는 일반론을 실제 튜터에 적용해 어떤 구성과 평가를 사용했는지 설명한다.

5.1. 단일 ReAct 에이전트와 미들웨어

1. 단순한 에이전트 루프

   1. AI 튜터는 도구 호출과 사고 블록(thinking block)을 반복하는 단일 ReAct 계열 에이전트다.
   2. LangChain의 create_agent 메서드로 만들고, 현재 대화 기록만 저장하는 in-memory saver를 사용한다. 과거 세션 대화는 이 설정에 저장하지 않는다.

2. 런타임 미들웨어

   1. LangChain 미들웨어로 에이전트의 동작을 런타임에 바꿀 수 있다.
   2. 예시로 오래된 도구 결과를 지우거나 대화를 요약하는 기능을 미들웨어로 붙인다.
   3. 수강생이 답변에 사용할 소스, 즉 어느 강의·어느 과정을 사용할지 선택하는 기능도 미들웨어와 설정으로 처리한다.

5.2. 두 가지 지식 도구

1. retrieve_tutor_context: 하이브리드 검색

   1. 모든 과정의 강의와 LangChain, LlamaIndex, OpenAI, Codex, Claude Code 등의 공개 문서를 합쳐 800만 토큰이 넘는 대형 코퍼스를 만든다.
   2. 사용자는 질문 전에 사용할 소스를 선택할 수 있다. 검색 대상을 먼저 필터링하면 재현율(recall)과 정밀도를 높일 수 있다.
   3. 의미 기반 임베딩 검색과 키워드 기반 BM25 검색을 함께 사용한다.
   4. 두 검색에서 각각 얻은 결과를 합쳐 가장 관련성 높은 30개 청크를 모은 뒤, 재순위화(reranking)해 최종 5개 청크를 에이전트에 돌려준다.
   5. 반환 결과의 총량은 100,000토큰으로 제한한다. 이 한도를 넘으면 마지막 청크부터 제거한다.
   6. 임베딩 모델·BM25·상위 30개·최종 5개라는 값은 임의로 고른 것이 아니다. 가능한 설정을 반복 실험해 “정답 강의 페이지를 실제로 검색했는가”를 측정하고 최상의 재현율을 내는 조합을 선택했다.

2. run_knowledgebase_command: 파일 시스템 탐색

   1. 복잡한 질문에서 에이전트가 지식 베이스 전체를 직접 훑는 편이 더 나을지 확인하기 위해, 코딩 에이전트처럼 파일 시스템을 읽는 두 번째 도구를 추가했다.
   2. raw 폴더에는 모든 강의와 공개 문서의 마크다운 원본을 둔다.
   3. generated 폴더에는 원본 파일의 제목을 자동 생성해 에이전트가 후보를 찾기 쉽게 만든다.
   4. wiki 폴더에는 Claude Code가 raw 파일을 읽고 만든 간결한 주제·프레임워크 색인을 둔다. 예를 들어 fine-tuning 주제 파일은 관련 raw 파일들을 가리킨다.
   5. 배포 환경에서 에이전트는 지식 베이스를 읽기만 할 수 있고 파일을 수정할 수 없다. 허용한 Bash 명령은 읽기 전용이다.
   6. 한 명령이 8초를 넘기면 오류를 반환하거나 다른 명령을 선택하게 한다.
   7. 도구 출력은 40,000자로 제한한다. 강의가 더 길면 처음 40,000자를 읽은 뒤 후속 명령으로 마지막 부분을 읽을 수 있다.
   8. 한 턴에 최대 20개의 명령만 허용하며, 실제로 이 한도를 넘은 적은 없지만 무한 실행을 막는 안전장치다.
   9. 에이전트가 읽을 수 있는 경로도 지식 베이스 폴더 하나로 샌드박스한다.
   10. 폴더 구조와 wiki는 새 과정을 추가할 때 Claude Code로 한 번 생성하고 배포한다. 매 질의마다 wiki를 다시 만들지는 않는다.

3. 탐색 도구의 실험 결과

   1. 이 파일 시스템 도구는 거의 90%의 턴에서 사용됐다.
   2. 그러나 도구를 끈 경우에도 첫 번째 하이브리드 검색 도구와 같은 재현율을 얻었다.
   3. 파일 탐색 도구는 추가 호출 때문에 약 50% 느려졌다.
   4. 실제 수강생의 질문이 이미 충분히 복잡해서 파일 시스템 탐색의 이점을 받을 것이라고 예상했지만, 정답 문서를 찾는 정확도에는 이점이 없었다.
   5. 따라서 아이디어 자체는 흥미로웠지만, 이 튜터의 실제 데이터에서는 더 느리고 더 복잡한 도구일 뿐이었다.

6. 초기 운영 설정과 평가 하네스

6.1. 측정하지 않고 만든 초기 기본값

1. 처음에는 빨라 보이고 좋아 보여서 다음 세 가지를 측정 없이 설정했다.
   1. 도구 결과가 5,000토큰을 넘으면 오래된 결과를 지우되 최근 다섯 개는 남긴다.
   2. 전체 기록이 30,000토큰을 넘으면 대화 이력을 요약하되 최근 20개 메시지는 정확성을 위해 남긴다.
   3. 수강생이 답변에 사용할 소스를 선택할 수 있게 한다.
2. Hugging Face Space의 UI 왼쪽에서는 소스를 켜고 끌 수 있고, 질문을 보내면 Gemini 3.5 Flash가 추론과 도구 호출을 수행한다.
3. 시연 화면은 일시적인 인터넷 문제로 응답이 매끄럽지 않았지만, 모델의 활동·도구 호출·최종 답변을 확인할 수 있었다.
4. 예시 실행에서 모델은 네 번 사고하고 10개 소스를 사용한 뒤 최종 답변을 반환했다.
5. 코드는 공개되어 있으므로 각자의 코딩 에이전트로 코드베이스를 탐색하며 구현을 확인할 수 있다.

6.2. 매 턴 기록하는 운영 지표

1. 입력 토큰 수와 출력 토큰 수를 기록한다.
2. 그중 캐시된 토큰이 얼마나 되는지 기록한다.
3. 호출 비용, 첫 토큰까지 걸린 시간, 전체 처리 시간, 도구 호출 횟수를 기록한다.
4. 실제로 요약·압축이 일어났는지도 기록한다.
5. 이런 계측이 있어야 똑똑해 보이는 기법이 실제로 유용한지, 아니면 캐시와 재검색 때문에 해로운지 비교할 수 있다.

6.3. 평가 용어와 하네스

1. 프리셋(preset): 튜터 설정 하나다. 예를 들어 특정 토큰 수에서 요약하거나 슬라이딩 윈도를 쓰는 구성이다.
2. 태스크(task): 평가 유형이다. 초기 평가에서는 단일 턴과 멀티턴 세션 두 종류를 사용했다.
3. 런(run): 하나의 프리셋을 하나의 태스크에 실행한 결과다.
4. 번들(bundle): 실행하면서 저장한 모든 측정값을 담은 JSON 파일이다.
5. run_task와 run_battery 함수가 태스크를 실행하고, 코드 검사나 LLM 판정으로 채점하며, 트리거 검사를 통해 실제로 압축이 발생했는지 확인한다.
6. 마지막에는 지연 시간, TTFT, 토큰 수 등 측정 가능한 모든 지표를 포함한 보고서를 생성한다.

6.4. 실제 사용자 데이터 기반의 두 태스크

1. 단일 턴 질의응답

   1. 합성 질문이 아니라, 학생이 웹사이트에 질문하고 직원이 답한 기록을 Codex로 수집했다.
   2. 오래된 라이브러리 버전을 전제로 한 질문, 평가에 맞지 않는 질문, 중복 질문을 제거해 60개의 질문·답변 쌍을 남겼다.
   3. 코드로 올바른 강의 페이지를 검색했는지 확인하는 재현율을 측정했다.
   4. 답변이 올바른 사실과 적절한 응답 형태를 포함하는지는 LLM 판정으로 평가했다. API를 직접 사용하는 것보다 Codex 구독을 이용한 평가가 더 저렴하다고 판단했다.

2. 멀티턴 세션과 기억 회수

   1. 대화 시작에 가상의 학생 상태·사실을 넣는다. 예를 들어 학생이 “RAG 평가를 배우고 싶다”고 선언한다.
   2. 그 사실을 보존해야 하는 이유만 남기고, 중간에는 많은 필러 메시지를 넣어 대화를 길게 만든다.
   3. 이후 “오늘 무엇을 배우면 좋을까?”라고 다시 물어, 에이전트가 RAG 평가, 더 구체적으로 hit rate와 MRR 같은 주제를 회수하는지 본다.
   4. 요약 프리셋을 테스트할 때는 실제 요약 트리거가 발생했는지도 별도로 검사한다.

7. 초기 실험: Gemini에서 컨텍스트를 그대로 두는 선택

7.1. 비교한 프리셋과 비용

1. 전체 이력을 건드리지 않는 full history와 측정 전의 기본 설정인 production을 기준점으로 삼았다.
2. 슬라이딩 윈도, 프롬프트 압축(prompt compression), 선택적 보존(selective retention) 및 요약·도구 결과 정리 계열을 포함해 총 11개 프리셋을 비교했다.
3. 모델·프롬프트·도구·데이터셋은 고정하고 컨텍스트 처리 전략만 바꿨다.
4. 첫 평가 비용은 예상보다 커져 500달러를 넘었고, 이후 확장 평가에서는 약 600달러에 달했다. 비용을 낮추기 위해 더 싼 모델을 이용한 후속 평가를 설계했다.

7.2. 기억 회수 결과

1. 멀티턴에서 가장 뜻밖의 승자는 아무것도 하지 않는 full history였다.

   1. 컨텍스트를 그대로 둔 설정이 여러 메시지 뒤에 처음 심어 둔 사실을 가장 잘 회수했다.
   2. 측정 전에는 좋아 보였던 production 기본값은 최선이 아니었다.
   3. 1회 트라이얼과 2회 트라이얼을 각각 수행했기 때문에 절대 수치의 통계적 안정성은 제한적이지만, 기법의 순서는 유의미한 신호를 보였다.

2. 비용과 품질의 초기 비교는 다음과 같았다.

   1. production의 단일 턴 비용은 약 50센트였다.
   2. 멀티턴은 턴당 약 24센트였다.
   3. 단일 턴은 여러 압축 트리거가 발생할 만큼 길지 않아서 대부분의 기법이 높은 기억 회수율을 보였다.
   4. 멀티턴에서 production의 품질은 38%까지 떨어졌다.
   5. 반대로 full history는 더 싸고 더 빨랐으며 전체 기억 회수율도 더 높았다.

3. 왜 지우는 쪽이 더 비싸졌는가

   1. 오래된 도구 결과를 계속 지우면 에이전트가 이미 갖고 있던 정보를 다시 검색해야 한다.
   2. 추가 도구 호출이 생기면서 토큰 수와 지연 시간이 늘고, 오히려 기억 회수가 낮아졌다.
   3. 즉, 컨텍스트를 짧게 만드는 것이 에이전트의 작업량을 줄이는 것이 아니라 같은 정보를 재구성하는 일을 추가할 수 있다.

8. 확장 실험: DeepSeek·로컬 모델·긴 문서

Samridhi는 초기 결과를 더 싼 모델, 서로 다른 컨텍스트 유형, 긴 대화와 로컬 실행으로 확장했다.

8.1. 평가해야 했던 서로 다른 컨텍스트

1. 긴 채팅 기록: 학생이 설정, 오류, 이미 시도한 해결책을 여러 턴에 걸쳐 말해 중요한 세부사항이 중간에 묻힌다.
2. 붙여 넣은 문서: 학생이 긴 문서를 그대로 복사해 넣어 윈도에 큰 덩어리가 생긴다.
3. 도구 로그: 내부 도구가 만든 로그가 쌓이며, 도구 결과마다 다른 정리가 필요하다.
4. 비용 제약과 로컬 실행: 같은 평가를 싼 클라우드 모델과 로컬 모델에서 수행해 압축의 이점이 바뀌는지 확인했다.

8.2. DeepSeek V4 Flash의 캐시 실험

1. Gemini보다 비용이 낮은 DeepSeek V4 Flash를 사용했다.
2. DeepSeek의 캐시 할인은 Gemini 대비 50배 수준이어서 두 모델의 비용 차이가 매우 컸다.
3. 더 싼 모델에서도 모든 컨텍스트를 유지하는 방식이 가장 좋은 성능을 냈다.
4. 실제 수강생 대화에서 설정과 오류 등 특정 세부사항을 다시 묻는 방식으로 기억을 확인했다.
   1. 전체 컨텍스트를 유지하면 정확한 세부사항을 95%의 경우에 답했다.
   2. 먼저 요약하거나 압축하면 32%의 경우에만 정답을 돌려줬다.
   3. 요약이 필요한 세부사항을 제거해 모델이 답변에서 계속 누락했기 때문이다.
5. 전체 이력은 가장 많은 토큰을 보내는 설정이었지만 97%의 토큰이 캐시되어 가장 쌌다.
6. 36턴, 약 178만 토큰의 대화에서도 전체 이력 유지가 비용과 결과 모두에서 앞섰다.

8.3. 컨텍스트가 800,000토큰까지 길어졌을 때

1. 대화 길이를 크게 늘리고 하나의 특정 사실을 찾게 했다.
2. 구별이 쉬운(distinctive) 사실은 800,000토큰까지 거의 놓치지 않았다.
3. 모호한(ambiguous) 사실은 성능이 관찰된 수준의 절반까지 떨어졌지만, AI 튜터의 실제 사용 사례에는 여전히 충분히 좋은 결과였다.
4. 긴 대화에서 곧바로 컨텍스트를 압축하지 않아도 모델이 특정 사실을 상당히 안정적으로 찾을 수 있다는 결과였다.

8.4. 대규모 사용량의 비용과 로컬 모델의 한계

1. 하루 100,000~1,000,000턴의 질문을 가정하면 DeepSeek의 비용은 월 약 18,000~180,000달러가 된다.
2. 현재 Towards AI의 실제 규모는 이보다 작지만, 턴당 비용은 대규모 서비스에서 누적된다.
3. 그래서 토큰 비용이 없는 로컬 모델에서도 같은 캐싱·컨텍스트 전략이 작동하는지 확인했다.
4. 하드웨어 제약으로 MacBook에서 테스트했고 최대 컨텍스트 윈도는 32,000토큰이었다.
5. 강의 하나만으로도 32,000토큰을 넘는 경우가 있어, 대화가 윈도에 들어가지 않으면 캐시가 더 이상 도움이 되지 않았다.
6. 모델을 7B·8B에서 32B로 키워도 하드웨어가 허용하는 컨텍스트 윈도는 커지지 않는다. 모델 크기와 컨텍스트 윈도는 같은 문제를 해결하지 않는다.

8.5. 로컬 문서에서 검색과 컨텍스트 스터핑 비교

1. 긴 문서를 로컬에서 다뤄야 할 때는 검색이 매우 잘 작동했다.
   1. RAG로 필요한 결과를 검색하면 정확도 100%를 얻었다.
   2. 처리 시간은 약 25~65초였다.
2. 반대로 윈도보다 많은 대화를 억지로 넣으면 약 340초가 걸렸고, 결과는 단 한 토큰인 경우도 있었다.
3. 따라서 로컬 환경에서는 “더 많이 넣기”보다 문서를 검색해 필요한 부분만 넣는 선택이 중요하다.

8.6. Dense RAG와 BM25

1. Dense RAG는 텍스트의 의미를 임베딩해 비슷한 내용을 찾는 기본 전략이다.
2. 50,000~200,000토큰 범위에서는 dense 검색이 약 80%로 잘 작동했다.
3. 400,000토큰까지 늘리자 문서 중간에 묻힌 사실을 찾지 못해 재현율이 0%가 됐다.
4. 키워드 기반 BM25는 같은 조건에서 매번 100%를 얻었다.
5. 의미 검색 하나만으로는 충분하지 않기 때문에 AI 튜터가 dense 검색과 BM25를 섞은 하이브리드 검색을 사용하는 이유가 여기에 있다.

8.7. 클라우드와 로컬의 나란한 비교

1. 채팅 기억에서 클라우드는 전체 컨텍스트를 유지했을 때 약 92~95%의 점수를 냈다.
2. 로컬 모델은 컨텍스트 윈도 제약 때문에 약 33%에 머물렀다.
3. 로컬 실행은 이미 하드웨어를 보유했다면 토큰 비용이 없지만 처리량(throughput)이라는 제약이 있다.
4. 로컬에서도 검색을 적용하면 좋은 정확도를 얻을 수 있다.
5. 학생이 1,000명인 규모를 예로 들면 Gemini는 월 약 40,000달러, DeepSeek는 약 1,900달러 수준이었다. 로컬 실행은 토큰 비용을 더 줄일 수 있지만 하드웨어·처리량을 감당해야 한다.

9. 최종 설계 결정과 실용적 시사점

9.1. Towards AI가 선택한 튜터 구성

1. 모델: 하드웨어 제약과 현재 수강생 규모를 고려해 DeepSeek V4 Flash 클라우드를 선택했다.
2. 검색: 의미 기반 검색과 BM25를 결합한 하이브리드 검색을 사용한다.
3. 메모리·대화: 기본적으로 컨텍스트 전체를 유지한다.
4. 압축 예외: 30,000토큰을 기본 한도로 두고, 그 지점에 도달하기 전까지는 모든 세부사항을 보존하며 이후에만 압축한다.
5. 파일 탐색: 파일 시스템 위키 도구는 추가해 보았지만 50% 느리고 재현율 개선이 없어 핵심 경로에서 이득이 없었다.

9.2. 제약별 선택 규칙

1. 클라우드 모델에서 컨텍스트가 윈도 안에 들어가고 캐시가 잘 작동하면, 전체 이력을 유지하는 편이 품질·비용·속도 면에서 유리할 수 있다.
2. 컨텍스트가 실제 윈도를 넘으면 검색·슬라이딩 윈도·선택적 보존·요약 중 현재 데이터와 비용에 맞는 방법을 선택한다.
3. 긴 붙여 넣기 문서와 도구 로그는 일괄 요약하기보다 도구별로 자르거나 RAG로 필요한 구간만 꺼내는 편이 정확할 수 있다.
4. 의미 검색만 믿지 말고 희귀한 키워드와 문서 중간의 사실을 찾는 BM25를 함께 평가한다.
5. 무엇을 선택하든 실제 사용자 대화로 재현율, 정답 사실, 비용, 캐시 적중률, TTFT, 추가 도구 호출을 모두 측정한다.

9.3. 핵심 결론

1. 기본값은 “항상 압축”이 아니다: 압축 전에 해결하려는 제약이 비용인지, 윈도 초과인지, 품질 저하인지 명확히 이름 붙인다.
2. 캐시를 먼저 계산한다: 캐시된 반복 토큰은 매우 싸고 빠르므로, 압축이 캐시를 깨뜨리면서 얻는 절감량을 실제로 계산해야 한다.
3. 정보 손실의 재작업을 포함한다: 도구 결과를 지워서 짧아진 컨텍스트가 같은 정보를 다시 검색하게 만들면 전체 비용과 지연 시간이 더 커질 수 있다.
4. 작은 컨텍스트가 항상 더 똑똑한 컨텍스트는 아니다: 모델이 지금 필요한 세부사항을 보존한 채 캐시를 재사용하는지가 핵심이다.
5. Towards AI는 평가와 튜터 구축을 더 배우고 싶은 사람에게 academy.towardsai.net의 Full-Stack AI Engineering 과정을 안내한다.

주요 발언 모음

“컨텍스트 엔지니어링은 모델을 호출할 때마다 모델이 무엇을 보게 할지 결정하는 일이다.”

“압축은 기본값이 되어서는 안 된다. 자신이 가진 제약을 먼저 이름 붙이고 더 나은 대안을 찾아야 한다.”

“가장 많은 토큰을 보내는 실행이 캐시 때문에 가장 쌌다.”

“요약은 필요한 세부사항을 없애기 때문에 모델이 그 세부사항을 계속 놓치게 만든다.”

“모델의 크기를 계속 키워도 컨텍스트 윈도는 늘어나지 않는다. 그 부분은 선택을 통해 해결해야 한다.”

핵심 데이터 & 수치

• 80분: 압축·검색·메모리와 AI 튜터 평가를 다루도록 계획한 워크숍 길이.
• 8백만 토큰 이상: 강의·공개 라이브러리·OpenAI·Codex·Claude Code 문서를 합친 지식 코퍼스.
• 약 450토큰: 파일 기반 LLM wiki에서 에이전트가 먼저 읽는 작은 인덱스의 크기.
• 상위 30개 → 최종 5개: 하이브리드 검색 결과를 합친 뒤 재순위화하는 흐름.
• 100,000토큰: 검색 결과를 에이전트에 반환할 때의 상한.
• 8초 / 40,000자 / 20회: 파일 탐색 명령의 시간 제한, 출력 제한, 턴당 명령 제한.
• 5,000토큰 / 최근 5개: 초기 설정에서 오래된 도구 결과를 정리하던 기준.
• 30,000토큰 / 최근 20개 메시지: 초기 설정에서 대화를 요약하던 기준.
• 약 90%: 파일 탐색 도구가 사용된 턴의 비율. 재현율 개선은 없었고 약 50% 느려졌다.
• 60쌍: 실제 수강생 질문·직원 답변에서 정제한 단일 턴 평가 데이터.
• 약 50센트 / 약 24센트: 초기 Gemini 설정에서 단일 턴과 멀티턴 한 턴의 비용.
• 38%: 초기 production 설정의 멀티턴 기억 회수 성능.
• 95% 대 32%: DeepSeek에서 전체 컨텍스트 유지와 요약·압축의 특정 세부사항 회수율.
• 97%: 전체 이력 유지 설정에서 캐시된 토큰 비율.
• 36턴 / 178만 토큰: 전체 이력 유지가 더 쌌던 확장 대화의 규모.
• 800,000토큰: 구별이 쉬운 사실을 안정적으로 찾은 긴 컨텍스트 규모.
• 32,000토큰: MacBook 로컬 테스트의 최대 컨텍스트 윈도.
• 100% / 25~65초: 로컬 긴 문서에 RAG를 적용했을 때의 정확도와 처리 시간.
• 약 340초 / 한 토큰: 컨텍스트 윈도를 초과해 내용을 억지로 넣었을 때의 극단적 결과.
• 80% → 0% 대 100%: 50k~200k에서 400k로 커질 때 dense RAG의 재현율 변화와 BM25의 결과.
• 92~95% 대 33%: 전체 채팅 기억의 클라우드·로컬 성능 비교.
• 월 18,000~180,000달러: DeepSeek로 하루 10만~100만 턴을 처리한다고 가정한 비용.
• 월 40,000달러 대 1,900달러: 1,000명 규모에서 Gemini와 DeepSeek의 비교 예시.

결론 및 시사점

컨텍스트 엔지니어링의 최적화 목표는 짧은 프롬프트가 아니라 가장 적절한 정보 집합이다.

1. 현재 문제를 컨텍스트 윈도 초과, 캐시 비용, 검색 실패, 사용자 기억 상실 중 무엇인지 구분한다.
2. 캐시 재사용이 가능한지 먼저 확인하고, 캐시를 깨는 압축의 손익분기점을 계산한다.
3. 오래된 도구 결과는 무조건 삭제하지 말고, 재검색 비용과 품질 저하를 함께 측정한다.
4. 클라우드 모델의 윈도에 들어가는 동안에는 전체 이력 유지가 더 싸고 정확할 수 있다.
5. 윈도에 들어가지 않는 문서는 하이브리드 RAG로 검색하고, dense 검색과 BM25를 함께 평가한다.
6. 로컬 모델은 토큰 비용이 없지만 윈도와 처리량이 제한되므로 문서 검색과 압축이 필수적인 경우가 많다.
7. 작은 스킬과 점진적 공개로 필요한 정보만 단계적으로 로드한다.
8. 모든 실행에서 토큰·캐시·비용·TTFT·도구 호출·사용자 불만을 기록하고 실제 사용자 데이터로 프리셋을 비교한다.

핵심 요약 (20줄)

컨텍스트 엔지니어링은 매 호출마다 모델에게 보여줄 정보의 선택과 배치를 설계하는 작업이다. 모델의 컨텍스트 윈도는 유한하므로 지시문과 문서와 도구 결과와 대화가 서로 같은 공간을 놓고 경쟁한다. 모델은 기본적으로 상태가 없어서 세션 내부 컨텍스트 관리와 세션 간 메모리를 따로 설계해야 한다. 오래된 도구 결과가 쌓이면 관련 없는 정보가 실제 질문을 묻어버리고 품질과 속도와 비용이 함께 악화된다. 도구 출력은 이상치를 머리와 꼬리만 남겨 자르고 슬라이딩 윈도나 도구별 삭제 정책으로 정리할 수 있다. 선택적 보존과 지속적 요약과 델타 요약은 언어 모델을 사용해 컨텍스트를 압축하는 대표적인 방법이다. 파일 메모리와 RAG는 정보를 버리지 않고 외부로 옮겨 필요한 순간에만 다시 읽는 가역적인 방법이다. 작고 정밀한 스킬을 점진적으로 공개하면 거대한 스킬 하나를 매번 로드하는 비용을 피할 수 있다. 프롬프트 캐싱은 이미 보낸 토큰을 재사용해 비용을 크게 낮추고 첫 토큰까지의 시간도 줄인다. 요약과 압축은 기존 토큰을 새 토큰으로 바꾸기 때문에 캐시를 깨뜨릴 수 있다. 캐시를 잃고도 이득을 보려면 컨텍스트를 50배 이상 줄여야 하는 경우가 있어 요약은 기본값이 될 수 없다. Towards AI의 튜터는 LangChain 단일 ReAct 에이전트와 런타임 미들웨어로 동작한다. 8백만 토큰이 넘는 지식 코퍼스에는 의미 검색과 BM25를 결합하고 30개 결과를 5개로 재순위화한다. 파일 시스템 탐색 도구는 재현율을 높이지 못했고 추가 호출 때문에 약 50% 느려졌다. Gemini 초기 평가에서 전체 이력을 유지한 설정이 기억 회수와 비용과 속도에서 압축 설정을 앞섰다. DeepSeek V4 Flash에서도 전체 컨텍스트 유지가 특정 세부사항을 95% 회수했지만 요약·압축은 32%에 그쳤다. 전체 이력은 97%의 토큰이 캐시된 덕분에 가장 많은 토큰을 보내면서도 가장 저렴한 실행이 됐다. 긴 컨텍스트에서 구별이 쉬운 사실은 800,000토큰까지 안정적으로 찾았지만 모호한 사실은 더 약해졌다. 로컬 MacBook 환경은 32,000토큰 윈도에 막혔고, 긴 문서에서는 RAG가 100% 정확도로 작동했다. 최종 원칙은 제약을 먼저 이름 붙이고 캐시와 실제 평가를 확인한 뒤 필요한 경우에만 압축하는 것이다.