AI 에이전트는 어떻게 긴 작업을 기억할까? Claude Code, Codex, Cursor의 컨텍스트 관리 전략

코딩 에이전트에게 제법 큰 작업을 맡기면, 한참 잘 돌아가다가 어느 순간 화면에 "Compacting conversation..." 같은 메시지가 뜹니다. 그리고 그 직후부터 에이전트가 조금 멍청해집니다. 앞에서 분명히 정한 규칙을 잊거나, 이미 고친 버그를 다시 건드리거나, 했던 말을 또 합니다.

원인은 단순합니다. 에이전트가 보고 판단하는 공간, 즉 컨텍스트 윈도우(context window)가 가득 찼기 때문입니다. 그래서 자연스럽게 떠오르는 해법이 "윈도우를 더 키우면 되지 않나?"입니다. 실제로 100만 토큰 윈도우는 이미 흔해졌고, Meta의 Llama 4 Scout는 1000만 토큰 입력 컨텍스트까지 내놨습니다.

그런데 정작 Claude Code, Codex, Cursor 같은 실전 에이전트들이 택한 방향은 정반대에 가깝습니다. 윈도우를 키우는 데 기대는 대신, 윈도우는 작게 유지하면서 필요한 정보만 그때그때 끌어오는 쪽입니다. 왜 이런 선택을 했는지, 그 방법이 무엇인지 하나씩 풀어보겠습니다. 결국은 "긴 작업을 잘 해내는 에이전트는 무엇이 다른가"라는 질문이기도 합니다.

왜 컨텍스트 윈도우를 키우는 것만으로는 부족할까?

윈도우를 키우는 게 직관적인 해법처럼 보이지만, 거기엔 세 가지 벽이 있습니다.

첫째, 길수록 비쌉니다. 에이전트는 매 스텝마다 이전 대화, 도구 호출, 파일 내용, 명령 출력을 계속 덧붙입니다. 챗봇과 달리 입력이 출력보다 압도적으로 많아서, Manus 팀은 그 비율이 평균 약 100:1에 달한다고 말합니다. 윈도우에 다 욱여넣을수록 매 호출의 비용과 응답 시간이 그대로 불어납니다.

둘째, 길수록 멍청해집니다. 흔히 '컨텍스트 로트(context rot)'라 부르는 현상으로, 토큰이 늘수록 모델이 정작 필요한 정보를 정확히 집어내는 능력이 떨어집니다. Chroma가 18개 LLM을 조사했더니, 단순하고 통제된 과제에서도 입력이 길어지면 성능이 불안정해지거나 저하됐습니다. 오래된 로그와 실패한 시도가 윈도우에 뒤섞일수록, 모델은 지금 필요한 신호보다 과거의 잡음에 끌려갑니다. 윈도우가 크다고 이 문제가 사라지지 않습니다.

셋째, 그냥 요약해 버리면 위험합니다. 윈도우가 차면 오래된 대화를 요약으로 접게 되는데, 요약은 본질적으로 무언가를 버리는 일입니다. 한 번 "버그를 고쳤다"라고만 접어 버리면, 나중에 그게 정확히 어디였는지 다시 필요해졌을 때 되찾을 길이 없습니다.

그래서 지금의 흐름은 "100만 토큰을 믿고 다 넣기"가 아닙니다. 윈도우가 아무리 커도 실제로 활성화된 부분은 작게 유지하고, 나머지는 밖에 두는 구조입니다. Claude Code 문서조차 1M 토큰 모델에서도 압축은 똑같이 작동한다고 설명합니다. 윈도우 크기는 그저 하나의 변수일 뿐, 진짜 승부는 다른 데서 갈립니다.

그래서 최신 에이전트는 컨텍스트를 '기억'이 아니라 '작업대'로 봅니다

이 분야의 핵심 발상은 한 문장으로 정리할 수 있습니다. 컨텍스트 윈도우를 에이전트의 '기억'으로 여기지 않는 것.

비유하자면 이렇습니다. 윈도우는 장기 기억이 아니라 매번 새로 차리는 작업대(workbench)입니다. 진짜 자료, 그러니까 전체 대화 로그, 파일, 깃 히스토리, 메모는 작업대 바깥 서랍과 창고에 둡니다. 모델을 호출할 때마다 시스템은 이 창고에서 "지금 이 판단에 필요한 것"만 골라 작업대에 올리고, 작업이 끝나면 새로 생긴 기록을 다시 창고로 넣습니다. 다음 호출 때 작업대는 또 깨끗하게 다시 차려집니다.

Google ADK는 이걸 두고, 컨텍스트란 고정된 텍스트 덩어리가 아니라 더 풍부한 상태 위에서 매번 새로 컴파일되는 뷰라고 표현합니다. 한번 이 그림이 머리에 들어오면, 뒤에 나오는 기법들이 전부 같은 목표의 변주라는 게 보입니다. 결국 목표는 하나입니다. 매번 짧고 밀도 높은 작업대를 차리는 것. 창고를 어떻게 두고 무엇을 꺼내 올릴지는 모두 그 목표를 위한 수단일 뿐입니다.

이미지 출처: Anthropic, Effective context engineering for AI agents

그렇다면 진짜 문제는 "무엇을, 얼마나 작업대에 올릴 것인가"입니다. 창고가 아무리 잘 정리돼 있어도 필요 이상으로 많이 올리면 작업대는 다시 지저분해지니까요. 접근은 크게 두 갈래입니다. 작업대에 올라온 내용을 잘 줄이는 법, 그리고 애초에 무거운 일은 남에게 맡겨 작업대에 안 올리는 법.

작업대를 어떻게 비울까? 줄이거나, 애초에 안 쌓거나

작업대를 짧게 유지하는 첫 번째 방법은, 쌓인 걸 잘 줄이는 것입니다. 여기서 가장 중요한 깨달음은 의외로 단순합니다. 요약은 하되, 원본을 버리지 마라.

같은 내용을 두 가지로 요약해 보겠습니다. 나쁜 요약은 이렇습니다.

"인증 버그를 고쳤고 테스트를 통과했다."

좋은 요약은 이렇습니다.

"인증 버그는 src/auth/session.ts:120-168에서 리프레시 토큰 검증을 수정해 해결. 테스트는 tests/auth/session.test.ts, 실패 로그는 logs/run-0626.txt. 남은 이슈는 OAuth fallback."

모델이 보는 길이는 둘 다 비슷하게 짧습니다. 하지만 후자는 파일 경로와 라인 번호라는 돌아갈 주소를 남겨 둡니다. 나중에 디테일이 필요하면 그 주소로 원본을 다시 펼치면 됩니다. 이것이 '그냥 요약'과 '복구 가능한 요약'의 차이이고, 좋은 에이전트가 압축할 때 지키는 핵심 원칙입니다. Claude Code가 한계에 가까워지면 자동으로 압축하고, Anthropic이 compaction에서 아키텍처 결정과 미해결 버그를 보존한다고 설명하는 이유, Manus가 웹페이지 본문은 버리되 URL은 보존하는 이유가 전부 여기에 있습니다.

두 번째 방법은 더 근본적입니다. 애초에 작업대에 안 쌓는 것. 거대한 파일이나 명령 출력을 윈도우에 통째로 붙이는 대신, 디스크에 두고 필요할 때만 꺼내 읽습니다. 도서관 전체를 책상에 쌓는 대신 청구기호만 들고 있다가, 필요할 때 그 책을 꺼내 오는 것과 같습니다.

Cursor는 이 발상을 실제 제품에 선명하게 녹여냈습니다. 긴 출력은 파일로 저장한 뒤 tail로 끝부분만 보고, 대화 기록도 검색 가능한 파일로 남겨 요약에서 빠진 디테일을 다시 찾고, 터미널 세션까지 파일로 동기화해 "방금 그 명령은 왜 실패했지?"라는 질문에 grep으로 답하게 합니다. 특히 MCP 도구 설명을 폴더에 동기화해 필요한 도구만 찾아보게 한 전략은, MCP 도구를 호출한 실행에서 전체 에이전트 토큰을 46.9% 줄였습니다. 철학을 한 줄로 요약하면 이렇습니다. "요약을 믿지 말고, 요약은 색인으로만 쓰고 원문은 검색 가능한 파일로 남긴다."

이미지 출처: Manus, Context Engineering for AI Agents

심지어 '도구 목록'도 작업대 위의 짐입니다

한 가지 덜 알려진 사실이 있습니다. 우리가 흔히 컨텍스트라고 하면 대화나 파일만 떠올리지만, 에이전트가 쓸 수 있는 도구의 설명서도 전부 작업대 공간을 잡아먹습니다. 도구가 수십 개씩 붙는 요즘은 이게 무시 못 할 자리를 차지합니다.

그래서 같은 원리를 도구와 스킬에도 적용합니다. 설명서 전체를 펴 두는 대신 목차만 두고, 실제로 쓸 때 펼치는 것이죠. Claude Code는 MCP 도구 정의를 기본적으로 지연 로딩하고, Codex Skills는 처음엔 스킬 이름·설명·파일 경로만 보여 준 뒤 선택된 스킬의 SKILL.md를 읽습니다. Cursor도 MCP 도구 설명을 폴더에 동기화해 필요한 설명만 찾게 합니다. 도구가 아무리 많아도 작업대는 가벼운 상태로 유지되는 겁니다.

이미지 출처: Cursor, Dynamic context discovery

서브에이전트는 똑똑해지려는 게 아니라, 깨끗해지려는 것

작업대를 비우는 두 번째 큰 방법은 귀찮은 일을 남에게 맡기는 것입니다. 바로 서브에이전트(sub-agent)입니다.

'여러 AI가 협업한다'고 하면 흔히 더 똑똑해지는 모습을 떠올립니다. 하지만 지금 실무에서 검증된 서브에이전트의 진짜 가치는 다른 데 있습니다. 메인 작업대를 더럽히지 않는 것입니다.

리서치를 시킨 인턴을 떠올려 보세요. 인턴은 산더미 같은 자료를 자기 책상에서 뒤지고, 나에게는 요약 한 장만 가져옵니다. 자료 더미는 내 책상에 올라오지 않습니다. Claude Code의 서브에이전트가 정확히 이렇게 움직입니다. 무거운 검색이나 대용량 파일 읽기를 별도 윈도우에서 처리하고, 메인에는 요약만 돌려보냅니다. 탐색 과정에서 생긴 수만 토큰의 어수선함은 서브에이전트 안에 고립됩니다.

이미지 출처: Anthropic, How we built our multi-agent research system

Cognition은 여기서 흥미로운 사실을 관찰했습니다. Windsurf와 Devin의 에이전트 궤적에서 첫 턴의 60% 이상이 컨텍스트 검색(context retrieval)에 쓰이는 경우가 많았다는 겁니다. 그래서 SWE-grep과 SWE-grep-mini라는 빠른 검색 특화 모델을 학습시켜 Fast Context 서브에이전트에 붙였습니다. 그런데 이 서브에이전트는 친절한 요약문을 돌려주지 않습니다. 대신 파일 이름과 라인 범위만 건넵니다. 메인 모델이 요약을 맹신하는 대신 직접 근거를 펼쳐 보고 판단하게 하려는 의도입니다.

그렇다면 차라리 모든 일을 여러 에이전트에게 동시에 시키면 어떨까요? Cognition은 정반대를 경고합니다. 문제는 단순한 merge conflict만이 아닙니다. 여러 에이전트가 충분히 컨텍스트를 공유하지 못한 채 암묵적인 스타일·아키텍처 결정을 각자 내려 버리면, 의사결정이 흩어지고 합치기 어려운 결과가 나오기 쉽습니다. 그래서 보수적인 기본값은 이렇습니다.

검색·리서치·리뷰처럼 읽기 중심의 일은 격리된 서브에이전트에게 맡기고, 병렬 쓰기는 격리·검증·조율 장치가 있을 때만 신중하게 쓴다.

그렇다면 '병렬 쓰기'는 영영 안 되는 걸까?

Claude Code의 dynamic workflows는 이 경계를 한 번 더 밀어붙였습니다. 사실 서브에이전트를 띄우는 것 자체는 새롭지 않습니다. 달라진 건 조율하는 방식입니다. 예전에는 서브에이전트를 어떻게 나누고 합칠지가 미리 짜인 틀 안에 있었다면, 이제는 Claude가 작업에 맞는 오케스트레이션 코드(자바스크립트)를 그때그때 직접 작성합니다. 어떤 에이전트에 어떤 모델을 붙일지, 각자를 별도 worktree에 격리할지, 결과를 어떻게 검증하고 언제까지 반복할지를 코드로 짜서 한 세션에 수십~수백 개를 돌립니다. 말하자면 에이전트가 자기 하네스를 스스로 짜는 셈입니다. 실제로 Bun 런타임을 Zig에서 Rust로 포팅할 때는 수백 개의 에이전트가 동시에 코드를 고쳤습니다.

모순처럼 보이지만, 비결은 검증을 함께 얹은 것입니다. 결과를 내는 에이전트마다 검증용 에이전트를 따로 붙여, 정해진 기준으로 그 결과를 반박하게 하고, 답이 수렴할 때까지 반복합니다. 병렬 쓰기를 금지하는 대신 "쓰되, 독립적으로 검증해 수렴시킨다"로 문제를 우회한 겁니다. 단일 스레드 원칙을 뒤집은 게 아니라, 격리와 검증을 끝까지 밀어붙여 그 한계선을 넓힌 사례입니다.

서브에이전트의 핵심은 "한 명보다 여럿이 똑똑하다"가 아니라, "곁가지를 격리해 메인을 깨끗하게 지킨다"입니다.

더 멀리: 접는 일 자체를 모델에게 가르친다

지금까지 본 방법은 대부분 사람이 바깥에서 짜 둔 규칙에 기댑니다. 압축 임계점을 어디로 잡을지, 무엇을 파일로 뺄지, 서브에이전트를 언제 부를지를 사람이 설계했죠. 방금 본 dynamic workflows가 그 조율 코드까지 모델이 직접 쓰게 한 사례라면, 연구 쪽은 여기서 한 발 더 나아가 컨텍스트를 다루는 방식 자체를 모델이 학습하게 만들려 합니다.

가장 급진적인 시도가 RLM(Recursive Language Models)입니다. 대용량 입력 데이터를 모델 컨텍스트에 통째로 넣지 않고 파이썬 REPL의 변수로 두는 발상입니다. 모델은 코드를 써서 그 변수를 들여다보고, 쪼개고, 필요한 조각만 자기 자신이나 깨끗한 컨텍스트를 가진 하위 LLM 인스턴스에 넘깁니다. 통째로 요약하지 않으니 요약으로 인한 정보 손실을 피할 수 있다는 게 차별점입니다. 대부분의 실험에서는 개선을 보였지만 일부 과제에서는 기존 방식보다 낮았고, "긴 컨텍스트를 어떻게 다룰지"를 사람이 정하는 대신 모델이 스스로 배우게 한다는 그 방향이 핵심입니다.

이미지 출처: Prime Intellect, Recursive Language Models: the paradigm of 2026

여기엔 냉정한 교훈이 하나 있습니다. 이 모든 장치는 결국 "모델이 아직 못 하는 것"을 메우려는 임시방편이고, 모델이 좋아지면 그 장치는 빠르게 군더더기가 됩니다. 한 세대에서 꼭 필요했던 기법이 다음 세대에선 걷어내야 할 짐이 되기도 합니다. 사람이 바깥에 두던 설계가 조금씩 모델 안으로 흡수되는 흐름이죠. 그러니 좋은 컨텍스트 설계란 한 번 만들어 굳히는 게 아니라, 모델이 자라는 만큼 덜어내며 더 어려운 문제로 옮겨가는 일입니다.

결국 좋은 에이전트란 무엇일까?

긴 이야기를 한 문장으로 정리하면 이렇습니다.

좋은 에이전트는 긴 컨텍스트를 많이 들고 있는 에이전트가 아니라, 바깥의 자료를 잘 다뤄서 매번 짧고 밀도 높은 작업대를 차리는 에이전트입니다.

이렇게 보면, 에이전트를 판단하는 기준도 달라집니다. 누가 더 긴 윈도우를 제공하느냐는 더 이상 핵심 질문이 아닙니다. 더 중요한 건 빠진 정보를 언제든 되찾을 수 있게 설계됐는지, 곁가지를 잘 격리하는지, 그래서 매 순간 군더더기 없는 작업대를 차리는지입니다. Claude Code, Codex, Cursor가, 나아가 코딩 에이전트도 아닌 Manus와 Cognition까지 비슷한 방향을 보인다는 건, 이게 한 제품의 취향만은 아니라는 뜻입니다. 코딩 에이전트를 고르거나 직접 만들 때 들여다봐야 할 지점도 결국 이쪽입니다.

처음의 질문, "에이전트는 어떻게 긴 작업을 기억할까"로 돌아가 봅니다. 답은 '더 큰 기억'이 아니었습니다. 기억을 바깥에 잘 두고, 매 순간 필요한 만큼만 꺼내 쓰는 설계. 사람도 모든 걸 머릿속에 담지 않고 메모와 파일과 검색에 기대지 않나요. 에이전트도 결국 같은 길을 가고 있는 셈입니다.

참고문헌

1. Anthropic (2025). Effective context engineering for AI agents. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
2. Claude Code Docs. Explore the context window. https://code.claude.com/docs/en/context-window
3. Cursor (2026). Dynamic context discovery. https://cursor.com/blog/dynamic-context-discovery
4. Manus (2025). Context Engineering for AI Agents: Lessons from Building Manus. https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus
5. Claude Code Docs. How Claude Code works. https://code.claude.com/docs/en/how-claude-code-works
6. OpenAI Developers. Agent Skills (Codex). https://developers.openai.com/codex/skills
7. Anthropic (2026). A harness for every task: dynamic workflows in Claude Code. https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code
8. Anthropic (2026). Introducing dynamic workflows in Claude Code. https://claude.com/blog/introducing-dynamic-workflows-in-claude-code
9. Anthropic (2025). How we built our multi-agent research system. https://www.anthropic.com/engineering/multi-agent-research-system
10. Cognition. Introducing SWE-grep and SWE-grep-mini: RL for Multi-Turn, Fast Context Retrieval. https://cognition.com/blog/swe-grep
11. Cognition. Don't Build Multi-Agents. https://cognition.com/blog/dont-build-multi-agents
12. Google Developers Blog. Architecting an efficient context-aware multi-agent framework for production. https://developers.googleblog.com/architecting-efficient-context-aware-multi-agent-framework-for-production/
13. Prime Intellect (2026). Recursive Language Models: the paradigm of 2026. https://www.primeintellect.ai/blog/rlm