장기 실행 AI 에이전트를 위한 컨텍스트 엔지니어링

Arize의 분석, 컨텍스트 윈도우 오버플로에 관한 arXiv 논문, Redis의 프로덕션 해설, Atlan의 하네스 엔지니어링 비교를 종합하면 에이전트 설계의 실용적 변화가 보입니다. 장기 실행 에이전트는 모델의 컨텍스트 윈도우 크기보다 그 주변의 제어 계층으로 더 많이 평가되고 있습니다. Arize는 이 변화를 구체화합니다. Pi, OpenClaw, Claude Code, Letta를 포함해 실제 출시된 에이전트 도구와 메모리/하네스 시스템을 하네스 수준 컨텍스트 엔지니어링의 예로 들고, 200K-token 윈도우가 차오르는 모습을 보여주는 인터랙티브 시뮬레이터를 설명합니다.

인용된 출처에서 공개된 세부 정보의 밀도는 고르지 않습니다. Arize는 Pi, OpenClaw, Claude Code, Letta에 대해 구체적인 구현 수치를 제공합니다. AI 에이전트의 컨텍스트 윈도우 오버플로 해결에 관한 연구 논문은 어떤 실용적 윈도우도 초과할 수 있는 도구 출력을 처리하는 더 일반적인 메커니즘을 제시합니다. Redis의 컨텍스트 윈도우 오버플로 해설은 프로덕션에서 나타나는 증상을 요약합니다. 하드 API 오류, 조용한 품질 저하, 도구 출력 누적, prompt가 길어질수록 증가하는 지연 시간입니다. Atlan의 prompt, 컨텍스트, 하네스 엔지니어링 비교는 유용한 스택 비유를 제공합니다. prompt 엔지니어링은 메시지를 다듬고, 컨텍스트 엔지니어링은 모델이 보는 것을 다듬으며, 하네스 엔지니어링은 에이전트 환경 전체를 다듬습니다.

중요한 소식은 컨텍스트 윈도우가 너무 작다는 사실이 아닙니다. 빌더들은 이미 그 사실을 알고 있습니다. 더 유용한 지점은 인용된 에이전트 시스템들이 transcript가 더 이상 안전한 진실의 원천이 아니게 된 뒤에도 작업을 유지하는 네 가지 하네스 메커니즘으로 수렴하고 있다는 점입니다.

얕은 에이전트는 파일을 읽고, 도구를 호출하고, 결과를 덧붙인 다음 모델이 감당하기를 바랍니다. 하네스 우선 에이전트는 큰 입력이 모델에 도달하기 전에 차단하거나 재구성합니다.

첫 번째 제한 집합을 더 깔끔하게 읽으면 다음과 같습니다.

• Pi: 파일 읽기는 2,000줄 또는 50KB 중 먼저 도달하는 지점에서 멈춥니다. 반환된 콘텐츠에는 어떤 줄 범위가 표시되었고 offset 및 limit로 어떻게 계속할 수 있는지 모델에 알려주는 이어 읽기 힌트가 포함됩니다. OpenClaw는 이 동작을 계승한 뒤 별도의 상한을 추가합니다. 부트스트랩 파일은 파일당 12,000자, 전체 60,000자로 제한됩니다. 도구 결과에는 16,000자 또는 컨텍스트 윈도우의 30% 중 더 작은 값이라는 또 다른 예산이 적용됩니다.

Claude Code는 두 단계 게이트 설계를 사용합니다. Arize에 따르면 파일을 열기 전에 256KB 바이트 상한을 확인한 뒤, 읽은 결과를 25,000-token 예산에 맞춰 token 수로 다시 확인합니다. 상한보다 작은 파일이라도 기본적으로 처음부터 2,000줄을 반환하며, 2,000자를 넘는 줄은 잘라냅니다. 모델이 같은 파일 범위를 다시 읽고 파일이 변경되지 않았다면 Claude Code는 전체 콘텐츠를 반복하는 대신 stub를 반환할 수 있습니다.

이는 단순한 최적화가 아닙니다. 실패 모드를 바꿉니다. 하나의 큰 읽기가 작업을 밀어내도록 두는 대신, 하네스는 “전부 읽기”를 “제어된 조각 읽기”로 바꿉니다. 모델에 더 필요하면 요청할 수 있습니다. 에이전트 하네스를 처음부터 설계하는 빌더에게 이것이 1차 방어선입니다. 원시 외부 데이터가 기본적으로 transcript가 되지 않게 해야 합니다.

다음 패턴은 컨텍스트를 저장소가 아니라 viewport처럼 다루는 것입니다.

Pi와 Claude Code는 offset 및 limit를 통해 페이지네이션을 노출합니다. OpenClaw는 일부 위치에서 head/tail 절단을 추가해, 중간 부분의 중요도가 낮을 가능성이 있을 때 시작과 끝을 유지합니다. Arize에 따르면 OpenClaw는 너무 큰 부트스트랩 파일에 대해 75% head / 25% tail 분할을 사용하며, 오류, 닫는 JSON 중괄호, 요약처럼 보이는 키워드처럼 tail이 중요해 보일 때는 도구 결과에서도 head와 tail을 모두 유지할 수 있습니다.

Letta는 파일을 prompt 밖에 두는 방식으로 더 나아갑니다. 업로드된 파일은 파싱되고 chunk로 나뉘며 벡터 저장소에 임베딩되어, 에이전트가 직접 보기, 정확 검색, 의미 검색을 사용할 수 있게 합니다. 파일이 컨텍스트에서 열려 있을 때 Letta는 모델 컨텍스트에 따라 크기가 달라지는 관리형 뷰를 보여줍니다. 8K 컨텍스트에서는 5,000자, 32K에서는 15,000자, 128K에서는 25,000자, 200K+에서는 40,000자입니다. 동시에 열 수 있는 파일 수도 작은 모델의 3개에서 매우 큰 모델의 15개까지 확장되며, LRU 정책으로 가장 오래 접근하지 않은 파일을 제거합니다.

이는 프로덕션 RAG의 기반이 되는 설계 아이디어와 같습니다. 전체 코퍼스를 prompt에 밀어 넣지 말고, 중요한 부분을 검색해 가져오는 것입니다. 차이는 에이전트 하네스가 파일, 도구 출력, 메모리, 중간 계획 전반에서 이를 지속적으로 수행해야 한다는 데 있습니다. 같은 제약은 RAG 시스템에도 적용됩니다. 검색은 관련성만의 문제가 아니라, 실제 추론 단계에 충분한 컨텍스트 예산을 남겨두는 문제이기도 합니다.

Redis도 관련된 지점을 짚습니다. 더 큰 컨텍스트 윈도우가 컨텍스트 관리의 필요성을 없애지는 않습니다. 시스템 prompt, 검색된 문서, 대화 기록, 도구 출력은 모두 같은 공간을 두고 경쟁합니다. 하드 제한에 도달하기 전에도 관련 정보가 긴 입력 속에 묻히면 모델 품질이 저하될 수 있습니다.

오버플로는 눈에 잘 띄는 실패입니다. 목표 상실은 더 조용합니다. 에이전트에는 응답할 공간이 남아 있지만 원래 목적을 잊고, 제약을 놓치거나, 국소적인 하위 작업을 최적화하기 시작합니다.

이 지점에서 컴팩션이 중요해집니다. 잘못 수행된 요약은 지저분하지만 충실한 기록을 깔끔하지만 손실이 큰 이야기로 대체합니다. 잘 수행되면 작업 상태, 최근 작업, 대기 중인 항목, 도구 호출의 무결성을 보존합니다.

Arize에 따르면 Pi는 추정 컨텍스트 token이 컨텍스트 윈도우에서 예비 token을 뺀 값을 초과할 때 컴팩션을 트리거하며, 기본 예비 값은 16,384 token입니다. 가장 최근의 약 20,000 token을 유지하고, 더 오래된 콘텐츠를 유지된 tail 앞에 붙이는 합성 사용자 메시지로 요약합니다. 또한 도구 호출/도구 결과 쌍을 가로질러 자르는 일을 피합니다.

OpenClaw는 더 공격적인 기록 정책을 추가합니다. 기록이 컨텍스트 윈도우의 50%를 초과하면 메시지를 token 질량이 같은 chunk로 나누고, 가장 오래된 chunk를 삭제하며, 삭제된 콘텐츠를 단계적 다중 패스 요약으로 요약하고, 도구 호출/결과 쌍을 복구합니다. 또한 사전 컴팩션 flush를 수행합니다. 조용한 agentic turn을 통해 기록이 사라지기 전에 에이전트가 상태를 메모리 파일에 영속화할 기회를 줍니다. 별도로, 5분 캐시 TTL에서 soft-trim 및 hard-clear 동작으로 메모리의 도구 결과를 가지치기합니다.

Claude Code는 윈도우 끝부분에 가까워질 때 컴팩션합니다. Arize에 따르면 트리거는 유효 컨텍스트 윈도우에서 13,000-token 버퍼를 뺀 값이며, 200K 컨텍스트 모델에서는 약 167K token 지점에서 컴팩션이 일어납니다. 요약 prompt는 기본 요청, 기술 개념, 파일과 코드, 오류와 수정, 문제 해결, 사용자 메시지, 대기 중인 작업, 현재 작업, 다음 단계를 다루는 구조화된 섹션을 요청합니다. 컴팩션 후에는 token 예산 안에서 최근 읽은 파일을 최대 5개까지 다시 첨부할 수 있습니다.

패턴은 분명합니다. 컴팩션은 “채팅 요약”이 아닙니다. 체크포인팅입니다. 장기 실행 에이전트에는 저장 파일에 해당하는 것이 필요합니다. 목표, 제약, 결정, 열린 핸들, 최근 증거, 다음 행동입니다.

일부 출력은 애초에 컨텍스트 윈도우에 들어가서는 안 됩니다.

arXiv 논문은 이를 재료과학 워크플로로 구체화합니다. 한 도구가 분자의 전자 격자 구조를 생성합니다. 이는 128 × 128 × 128 크기의 3D 행렬로, 총 2,097,152개의 float32 요소로 구성됩니다. 이 출력은 널리 사용되는 LLM의 컨텍스트 윈도우를 훨씬 초과합니다. 하지만 다음 도구는 이 격자를 입력으로 필요로 합니다.

제안된 해결책은 큰 값을 모델 컨텍스트 밖에 저장하고 짧은 식별자, 즉 포인터를 반환하는 것입니다. 도구 wrapper는 입력이 원시 값인지 메모리 경로인지 검사합니다. 너무 큰 출력은 runtime memory의 경로 아래에 저장되고, 이후 도구는 포인터를 받아 내부적으로 해석할 수 있습니다. 모델은 참조를 조작하고, 하네스는 전체 데이터를 보존합니다. 논문에 따르면 두 방법이 모두 성공한 한 비교 실험에서 포인터 기반 접근 방식은 기존 워크플로보다 약 7배 적은 token을 사용했습니다.

이는 추론과 데이터 전송을 가장 깔끔하게 분리하는 방식입니다. 모델은 200만 개 요소의 행렬을 다른 도구에 넘기기 위해 그것을 “볼” 필요가 없습니다. 그 행렬이 존재한다는 것, 무엇을 나타내는지, 다음에 어떤 작업이 그것을 소비해야 하는지만 알면 됩니다.

같은 논리는 과학 배열을 넘어 적용됩니다. 큰 JSON 응답, PDF, 로그, embedding, 미디어 파일, 데이터베이스 export는 prompt가 아니라 저장소에 있어야 하는 경우가 많습니다. MCP 도구나 custom API connector를 중심으로 구축된 시스템에서는 포인터 전달이 첫 오버플로 이후의 임시 패치가 아니라 1급 설계 선택이어야 합니다.

200K-token 컨텍스트 윈도우는 에이전트가 행동을 시작하기 전까지는 커 보입니다. 시스템 prompt, 도구 정의, 몇 개의 검색된 문서, 파일 읽기, 로그, 오류 trace, 요약이 예상보다 빠르게 그것을 소모할 수 있습니다. 실용적인 기준은 윈도우가 문서상 얼마나 커 보이느냐가 아니라, runtime에서 에이전트가 그것을 얼마나 빨리 쓰느냐입니다. Redis의 에이전트 메모리 가이드는 호출을 넘어 살아남아야 하는 상태에는 외부의 durable memory를 사용하라는 방향을 제시하고, Atlan의 컨텍스트 엔지니어링 프레임은 더 나은 prompt와 더 나은 컨텍스트 조립을 구분합니다. 둘을 합치면 컨텍스트 윈도우는 창고라기보다 제약된 working set에 가깝게 다뤄집니다.

더 깊은 교훈은 컨텍스트 윈도우가 희소한 runtime 리소스라는 점입니다. 이를 “메모리”로 다루는 것은 유용하지만, 하네스가 운영체제처럼 동작할 때만 그렇습니다. 할당하고, 제거하고, 페이징하고, 컴팩션하고, 중복을 제거하고, 영속화해야 합니다. Atlan의 계층 구분은 여기서 유용합니다. prompt 엔지니어링은 다음 호출에 80,000개의 무관한 token을 쏟아붓는 파일 리더를 고칠 수 없습니다. 컨텍스트 엔지니어링은 working set을 개선할 수 있습니다. 하네스 엔지니어링은 그 working set이 애초에 보호되는지를 결정합니다.

이는 팀이 에이전트를 평가하는 방식도 바꿉니다. 데모 prompt만으로는 충분하지 않습니다. 장기 과업 평가는 증가하는 transcript, 반복되는 파일 읽기, 큰 도구 출력, 실패한 도구 호출, 컴팩션 이후 재개, 그리고 올바른 다음 단계가 초기 제약에 의존하는 작업을 포함해야 합니다. 에이전트를 위한 컨텍스트 엔지니어링 가이드는 이 문제의 모델 측면을 다룹니다. 하네스 계층은 그것이 운영 문제로 바뀌는 곳입니다.

첫째, 모든 컨텍스트 소스에 예산을 두세요. 파일, 도구 출력, 검색된 chunk, 메모리 insert, 대화 기록에는 각각 명시적 제한이 있어야 합니다. 단일 전역 최대 token 수만으로는 너무 둔합니다.

둘째, 절단을 실행 가능하게 만드세요. 하네스가 콘텐츠를 잘라냈다면, 모델은 어떤 범위를 보았고 어떻게 더 요청할 수 있는지 알아야 합니다. 조용한 절단은 누락된 데이터를 바탕으로 자신감 있는 작업을 만들어내기 때문에 거부보다 나쁩니다.

셋째, 산문이 아니라 상태를 중심으로 컴팩션하세요. 요약은 사용자의 목표, 제약, 결정, 대기 중인 작업, 건드린 파일, 중요한 도구 결과, 즉각적인 다음 단계를 보존해야 합니다. 도구 호출 쌍은 온전하게 유지되어야 합니다.

넷째, 큰 값을 prompt 밖으로 옮기세요. 저장하고, 이름을 붙이고, 도구 사이에 포인터를 전달하세요. 이는 API를 호출하거나, 문서를 처리하거나, 멀티 에이전트 시스템을 조율하는 에이전트에서 특히 중요합니다.

마지막으로, 목표 상실을 오버플로와 별도로 테스트하세요. 에이전트는 하드 윈도우 안에 머물면서도 표류할 수 있습니다. 올바른 질문은 “API가 prompt를 받아들였는가?”뿐만이 아닙니다. “다음 행동이 여전히 원래 작업에 기여하는가?”입니다.

아래 요약은 FAQ 전에 이러한 패턴을 빠른 체크리스트로 정리합니다.

• 장기 실행 에이전트는 컨텍스트 오버플로와 목표 상실을 모두 통해 실패하므로, 하네스는 prompt 길이 이상의 것을 관리해야 합니다.
• 프로덕션 에이전트 시스템은 원시 데이터가 모델에 도달하기 전에 파일, 도구 출력, 기록에 하드 예산을 적용합니다.
• 페이지네이션, 검색, 관리형 뷰는 컨텍스트를 영구 저장소가 아니라 제한된 viewport로 다룹니다.
• 컴팩션은 체크포인팅일 때 가장 잘 작동합니다. 목표, 제약, 결정, 대기 중인 작업, 도구 호출 무결성을 보존합니다.
• 큰 도구 출력은 prompt 안의 전체 값 대신 외부 저장소에 두고 짧은 포인터를 도구 사이에 전달하는 편이 더 적합한 경우가 많습니다.

이 섹션은 장기 실행 에이전트를 위한 컨텍스트 엔지니어링 뒤의 실용적 질문에 답합니다. 무엇이 오버플로되는지, 목표가 어떻게 상실되는지, 어떤 하네스 패턴이 작업을 궤도에 유지하는지입니다.

컨텍스트 오버플로는 에이전트에 누적된 prompt, 기록, 검색된 데이터, 파일, 도구 출력이 모델의 사용 가능한 컨텍스트 윈도우를 초과하거나, 하드 제한에 도달하기 전에 품질을 저하시킬 때 발생합니다.

목표 상실은 원래 작업이 transcript 어딘가에 여전히 존재하지만 더 이상 에이전트의 다음 행동을 이끌지 못할 때 발생합니다. 긴 기록이나 부실한 요약 이후에 자주 나타납니다.

소스별 예산을 설정하고, 파일 읽기를 페이지네이션하고, 관련 뷰만 검색하고, 상태를 중심으로 기록을 컴팩션하고, 반복 읽기를 중복 제거하며, 큰 출력을 prompt 밖에 저장합니다.

포인터는 모델이 행렬, 로그, PDF처럼 runtime memory에 저장된 큰 값을 참조하게 해주며, downstream 도구는 전체 데이터를 컨텍스트 윈도우에 넣지 않고도 해석할 수 있습니다.

아니요. 더 큰 윈도우는 도움이 되지만, 시스템 prompt, 도구 정의, 검색된 문서, 로그, 기록은 여전히 공간을 두고 경쟁하며, 하드 제한에 도달하기 전에도 관련 정보가 묻힐 수 있습니다.