긴 컨텍스트가 답이 아니다: 에이전트는 무엇을 기억하고 무엇을 다시 가져와야 할까

• 카테고리: ai_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 에이전트가 오래 일할수록 왜 “컨텍스트를 더 크게”보다 “컨텍스트를 더 잘 관리”하는 설계가 중요해질까?
• 핵심 출처:
  • Effective Context Engineering for AI Agents - 2025-09-29 게시, 2026-06-08 확인
  • Compaction - 게시일 미표기, 2026-06-08 확인
  • Long context | Gemini Enterprise Agent Platform - 게시일 미표기, 2026-06-08 확인
  • Agents SDK | OpenAI API - 게시일 미표기, 2026-06-08 확인

1. 왜 지금 봐야 하나

요즘 AI 제품은 단발성 “질문-답변”에서 벗어나고 있다. 코드베이스를 여러 파일에 걸쳐 수정하고, 사내 문서를 훑고, 툴을 호출하고, 중간 결과를 저장한 뒤 다음 행동을 고르는 에이전트형 워크플로가 늘고 있다. 이때 가장 먼저 부딪히는 병목은 모델 지능보다 컨텍스트 관리다.

컨텍스트 창이 커졌으니 모든 것을 넣으면 된다고 생각하기 쉽다. Google Cloud의 Gemini long context 문서는 1백만 토큰급 컨텍스트와 Gemini 1.5 Pro의 2백만 토큰 컨텍스트가 RAG, 요약, 필터링 중심의 기존 설계를 바꿀 수 있다고 설명한다. 하지만 같은 문서도 여러 정보를 한 번에 찾아야 하는 경우 성능과 비용의 트레이드오프가 남는다고 경고한다.

Anthropic은 이를 더 직접적으로 “컨텍스트 엔지니어링”이라고 부른다. 프롬프트를 잘 쓰는 일을 넘어서, 시스템 프롬프트, 툴 정의, 툴 결과, 메시지 히스토리, 검색 문서, 메모리, 런타임 상태 중 무엇을 지금 모델 앞에 둘지 결정하는 기술이다. 에이전트가 오래 일할수록 컨텍스트는 자동으로 좋아지는 것이 아니라 오염되고, 길어지고, 비싸지고, 핵심 신호를 묻어버릴 수 있다.

2. 핵심 개념

컨텍스트를 단순히 “모델에 넣는 입력”이 아니라 “한정된 주의 예산”으로 보면 설계가 달라진다.

첫째, 긴 컨텍스트는 저장 공간이 아니다. 모델은 입력 전체를 볼 수 있지만, 모든 토큰을 같은 품질로 활용한다고 보장할 수 없다. Anthropic 글은 컨텍스트가 유한 자원이며, 추가 토큰이 늘어날수록 신호 대비 잡음이 커지고 주의가 분산될 수 있다고 설명한다. 긴 문서를 넣을 수 있다는 것과 그 안의 중요한 사실을 안정적으로 사용할 수 있다는 것은 다르다.

둘째, 메모리는 원문 보관소가 아니라 상태 압축 장치다. 장기 작업에서 중요한 것은 모든 로그를 기억하는 것이 아니라 목표, 제약, 이미 내린 결정, 아직 해결하지 못한 문제, 다음 행동 후보를 잃지 않는 것이다. 그래서 compaction, 구조화 노트, TODO, 작업 로그 같은 장치가 필요하다.

셋째, 검색은 한 번에 많이 넣는 기술이 아니라 “필요할 때 다시 가져오는” 기술이다. Anthropic은 just-in-time context 전략을 소개한다. 파일 전체, 데이터베이스 전체, 문서 전체를 미리 넣는 대신 파일 경로, 쿼리, 링크, 요약 인덱스 같은 가벼운 참조를 유지하다가 필요한 순간 툴로 가져오는 방식이다.

넷째, 오케스트레이션은 모델 호출보다 넓다. OpenAI Agents SDK 문서는 애플리케이션이 오케스트레이션, 툴 실행, 승인, 상태를 소유해야 할 때 SDK 경로가 적합하다고 설명한다. 즉 “큰 모델에 긴 프롬프트를 넣기”가 아니라, 어떤 상태를 저장하고 어떤 툴 결과를 다음 턴에 넘기며 어떤 작업을 별도 specialist에게 맡길지 정하는 런타임 설계가 핵심이다.

3. 최신 이슈와 연결

최근 문서들의 공통점은 “컨텍스트 창이 커졌으니 끝”이 아니라 “긴 작업을 어떻게 이어갈 것인가”로 논의가 이동했다는 점이다.

OpenAI의 Compaction 문서는 Responses API에서 컨텍스트가 임계값을 넘으면 server-side compaction을 실행하거나, 별도 compact endpoint로 긴 입력을 압축한 다음 다음 턴에 넘기는 흐름을 설명한다. 여기서 중요한 디테일은 compaction 결과가 단순 사람이 읽는 요약이 아니라 다음 실행에 필요한 상태를 적은 토큰으로 이어주는 항목이라는 점이다. 또한 이전 항목을 무작정 수동 삭제하지 말고, 최신 compaction item 이후만 유지하거나 previous_response_id 방식을 따르라는 운영 팁도 있다.

Anthropic의 글은 compaction 외에도 구조화 노트와 sub-agent architecture를 함께 제시한다. 긴 작업을 하나의 에이전트가 계속 끌고 가면 컨텍스트가 커지고 오염된다. 반대로 하위 에이전트가 특정 탐색을 수행하고 1,000~2,000토큰 수준의 압축 결과만 상위 에이전트에게 돌려주면, 상세 탐색 컨텍스트와 의사결정 컨텍스트를 분리할 수 있다.

Google Cloud long context 문서는 긴 컨텍스트가 RAG를 대체할 수 있는 구간도 있지만, 여러 needle을 찾아야 하거나 반복 질의가 많은 경우 비용과 정확도 트레이드오프가 남는다고 설명한다. 따라서 “전부 넣기”, “검색해서 넣기”, “압축해서 이어가기”는 경쟁 관계가 아니라 작업 형태에 따라 조합해야 하는 선택지다.

4. 개발자 관점 해석

실무에서 컨텍스트 관리는 네 가지 질문으로 바뀐다.

첫째, 지금 모델이 반드시 봐야 하는 원문은 무엇인가? 법적 문구, 코드 diff, 사용자 입력, API 응답처럼 정확한 문자열이 중요한 정보는 요약하면 위험하다. 이런 정보는 짧게 자르더라도 원문과 출처를 유지해야 한다.

둘째, 요약해도 되는 상태는 무엇인가? “이 파일은 이미 수정했다”, “테스트는 A 케이스에서 실패했다”, “사용자는 한국어 답변을 원한다” 같은 작업 상태는 구조화 메모로 충분한 경우가 많다. 원문 로그 전체를 넣는 것보다 상태 테이블이나 checklist가 더 낫다.

셋째, 다시 가져올 수 있는 정보는 무엇인가? 코드 파일, DB row, 문서 페이지, 이슈 링크처럼 안정적인 ID가 있는 정보는 컨텍스트에 붙잡아 둘 필요가 없다. 참조만 남기고 필요할 때 툴로 다시 읽는 편이 비용과 집중도 모두에 유리하다.

넷째, 분리해야 하는 작업은 무엇인가? 조사, 코드 검색, 로그 분석, 최종 판단을 한 에이전트가 모두 들고 있으면 컨텍스트가 쉽게 썩는다. 조사 에이전트는 넓게 읽고, 결정 에이전트는 압축된 근거만 받는 식으로 역할을 나누면 실패 모드가 줄어든다.

이 관점에서 긴 컨텍스트 모델은 “설계가 필요 없는 모델”이 아니라 “더 큰 설계 공간을 주는 모델”이다. 작은 작업은 전부 넣는 것이 빠르다. 긴 작업은 compaction이 필요하다. 반복 작업은 memory와 캐시가 필요하다. 검증이 중요한 작업은 원문 근거와 압축 상태를 분리해야 한다.

5. 내 프로젝트에 적용할 체크포인트

• 에이전트 요청마다 전체 대화, 전체 문서, 전체 툴 결과를 다시 넣고 있지는 않은가?
• “원문 유지”, “요약 가능”, “참조만 유지”, “폐기 가능” 네 등급으로 컨텍스트 항목을 나눴는가?
• 긴 작업에서 compaction이 발생하는 기준을 토큰 수, 턴 수, 툴 호출 수 중 하나로 정했는가?
• compaction 결과가 목표, 제약, 결정, 미해결 이슈, 다음 액션을 보존하는지 테스트했는가?
• 검색/RAG 결과를 그대로 누적하지 않고, 출처 ID와 필요한 인용만 남기는가?
• sub-agent나 background worker가 상세 조사 결과를 압축해 반환하도록 만들었는가?
• 실패했을 때 “모델이 바보였다”가 아니라 “필요한 정보가 빠졌는지, 너무 많은 잡음이 들어갔는지, 잘못 압축했는지”를 구분할 로그가 있는가?

6. 오늘 10분 액션

지금 만들고 있는 AI 기능 하나를 골라 컨텍스트 인벤토리를 작성해보자.

1. 최근 한 요청의 입력을 펼쳐서 항목별로 나눈다: system prompt, user message, history, retrieved docs, tool schema, tool outputs, memory.
2. 각 항목 옆에 등급을 붙인다: 원문 유지, 요약 가능, 참조만 유지, 폐기 가능.
3. 요약 가능 항목 3개를 골라 다음 형식의 compaction note로 바꿔본다.

목표:
이미 결정한 것:
중요 제약:
열린 문제:
다음 액션:
근거 링크/파일:

4. 다음 요청에서 원문 전체 대신 이 note만 넣는다고 가정하고, 어떤 실패가 생길지 적어본다.
5. 실패가 크면 원문 유지가 필요한 항목이다. 실패가 작으면 compaction 후보이다.

이 10분 실험의 목적은 토큰을 아끼는 것이 아니라, 내 에이전트가 무엇을 “기억”해야 하고 무엇을 “다시 읽으면” 되는지 구분하는 감각을 만드는 것이다.

7. 더 볼 자료

• Anthropic의 context engineering 글은 prompt, tool, memory, sub-agent를 한 프레임으로 묶어 보는 데 좋다.
• OpenAI Compaction 문서는 장기 대화나 장기 작업에서 상태를 이어가는 API 수준 패턴을 확인할 때 유용하다.
• Google Cloud long context 문서는 “전부 넣기”가 유리한 경우와 그래도 비용/정확도 트레이드오프가 남는 경우를 비교하는 데 좋다.
• OpenAI Agents SDK 문서는 상태, 승인, 툴 실행, 관측성을 애플리케이션이 소유해야 하는 시점을 판단할 때 참고할 만하다.

중복 회피 메모

이전 AI 글들은 prompt caching/KV cache, batch lane, VRAM 예산, eval harness, structured outputs, AI Gateway, prefill/decode 분리처럼 비용·평가·서빙·운영 제어를 다뤘다. 이번 글은 같은 “토큰 비용” 문제가 아니라 장기 에이전트가 작업 상태를 잃지 않도록 원문, 압축 메모, 참조, 하위 에이전트 결과를 어떻게 나눌지에 초점을 둔다.