컨텍스트 윈도우(Context Window)는 RAM이다 — 왜 에이전트의 SLI가 가득 찼음을 알려주는가

Azure SRE 에이전트를 구축한 Microsoft 팀은 지난 1월 제가 계속해서 다시 읽게 되는 글을 발표했습니다. 구축을 시작한 지 6개월 만에, 그들은 자신들이 SRE 에이전트를 만들고 있는 것이 아니라는 사실을 깨달았습니다. 그들은 우연히 사이트 신뢰성 공학 (Site Reliability Engineering, SRE)을 수행하는 컨텍스트 엔지니어링 (Context Engineering) 시스템을 구축하고 있었던 것입니다. 더 나은 모델은 기본 조건이었지만, 실제로 성과를 만들어낸 것은 그들이 제어할 수 있었던 것, 즉 절제된 컨텍스트 관리 (Context Management)였습니다. Kore.ai 이 프레임워크는 정확합니다. 그리고 여기에는 제가 지금까지 누구도 직접적으로 다루는 것을 보지 못한 신뢰성 관련 함의가 담겨 있습니다.

문제점
당신의 에이전트 컨텍스트 윈도우 (Context Window)는 휘발성 작업 메모리 (Working Memory)입니다. 빠르고, 비용이 많이 들며, 비지속적입니다. 이것은 저장 장치 (Storage)가 아니라 RAM입니다. 세션이 종료되면 사라집니다. 컨텍스트가 가득 차면 품질이 저하되는데, 이는 선형적으로 발생하는 것이 아니라 예측하기 어렵고 놓치기 쉬운 방식으로 발생합니다. 컨텍스트 윈도우를 채울수록 모델의 품질은 비선형적으로 떨어집니다. "중간에서 길을 잃음 (Lost in the middle)", "지시 사항 미준수", 그리고 긴 컨텍스트 저하 (Long-context degradation) 현상은 광고된 토큰 제한 (Token limits)에 도달하기 훨씬 전부터 나타납니다. 더 많은 토큰은 단순히 지연 시간 (Latency)만을 초래하는 것이 아니라, 조용히 정확도를 침식시킵니다. Kore.ai 이러한 조용한 침식이 바로 신뢰성 실패 모드 (Reliability failure mode)입니다. 이는 예외 (Exception)를 발생시키지 않습니다. 에러율 (Error rate)을 급증시키지도 않습니다. 당신의 에이전트는 계속 실행됩니다. 단지 컨텍스트가 채워짐에 따라 점점 더 나쁜 결정을 내릴 뿐입니다. 그리고 제가 구체적으로 말씀드리고 싶은 부분은 이것입니다: 당신은 이미 이를 포착할 수 있는 SLI (Service Level Indicators)를 가지고 있습니다. 단지 아직 그것들을 컨텍스트 상태 (Context state)와 연결하지 않았을 뿐입니다.

당신의 SLI에서 컨텍스트 오버플로 (Context Overflow)가 나타나는 방식
에이전트의 컨텍스트가 유효한 작업 범위를 넘어 가득 차게 되면, 다음 세 가지 일이 순차적으로 발생합니다: 첫째, DQR (Decision Quality Rate, 결정 품질률)이 먼저 떨어집니다. 에이전트의 결정이 나빠지는데, 이는 초기 지시 사항이 이제 수천 개의 토큰에 달하는 최근 도구 출력값 (Tool output)과 경쟁하게 되기 때문입니다. 3번째 턴 (Turn 3)의 지시 사항이 그 이후에 도착한 콘텐츠 아래에 묻히게 됩니다. 에이전트가 이를 무시하는 것이 아니라, 세션이 길어짐에 따라 최근 콘텐츠에 더 확실하게 주의를 기울이게 (Attending) 되는 것입니다. 이것은 모델의 버그가 아니라 수동적인 쇠퇴 과정 (Passive decay process)입니다.

다음으로 incident.io RTD (Reasoning Trace Depth, 추론 추적 깊이)가 상승합니다. 에이전트는 이전에 문제에 대해 이미 확립했던 초기 컨텍스트 (Context)가 부분적으로 쇠퇴하기 때문에 더 많이 재계획 (Re-plan)하게 됩니다. 이는 상황이 변해서 재계획하는 것이 아닙니다. 이미 파악했던 내용을 부분적으로 잊어버렸기 때문에 재계획하는 것입니다. 마지막으로 TIE (Tool Invocation Efficiency, 도구 호출 효율성)가 저하됩니다. 에이전트는 이미 가지고 있었던 컨텍스트를 재구성하기 위해 도구를 호출하기 시작합니다. 동일한 데이터 소스에 다시 쿼리(Query)를 보냅니다. 이미 읽었던 런북 (Runbook)을 다시 가져옵니다. 작업 품질은 계속 떨어지는 반면, 작업당 도구 호출 횟수는 기준치(Baseline) 이상으로 상승합니다. TIE가 눈에 띄게 높아질 때쯤이면, 이미 성능 저하 구간(Degradation window)에 깊숙이 진입한 상태입니다. DQR (Data Quality Ratio)이 더 앞선 신호였습니다. 외부 트리거 없이 장시간 세션에서 DQR이 떨어진다면, 그것이 바로 컨텍스트 오버플로 (Context overflow)의 징후입니다.

아키텍처 해결책 (The Architecture Fix)
Mem0의 2026년 벤치마크는 그 차이를 명확하게 수치로 보여줍니다: 전체 컨텍스트 기준선 (Full-context baseline, 모든 것을 윈도우에 채워 넣은 상태)은 쿼리당 26,000개의 토큰을 사용하여 17초의 p95 지연 시간 (Latency) 동안 72.9%의 정확도를 기록했습니다. 반면 2계층 메모리 아키텍처 (Two-layer memory architecture)는 7,000개 미만의 토큰을 사용하여 1.4초의 p95 지연 시간 동안 91.6%의 정확도를 기록했습니다. 이는 토큰 사용량을 4배 줄이고 지연 시간을 91% 단축하면서도 정확도를 18.7포인트 향상시킨 결과입니다. Yahoo Finance

2계층 아키텍처는 간단합니다:
작업 기억 (Working memory, 컨텍스트 윈도우): 현재의 의사결정에 필요한 것만 포함합니다. 활성 작업 상태 (Active task state), 최근 도구 결과, 현재 지침 (Instructions) 등이 해당됩니다. 세션이 길어짐에 따라 압축, 요약 또는 페이지 아웃 (Paged out)되는 방식으로 능동적으로 관리됩니다.
지속 기억 (Persistent memory, 외부 저장소): 의사결정 및 세션을 초월하여 유지되는 사실들입니다. 사용자 선호도, 확립된 시스템 상태, 이전 조사 결과, 런북 내용 등이 포함됩니다. 관련이 있을 때만 컨텍스트로 가져오며, 전체 시간 동안 상주시키지 않습니다.
핵심은 무엇이 각 계층에 속하는지 파악하고 그 경계를 능동적으로 관리하는 것입니다.

이를 귀하의 프로덕션 준비 체크리스트(Production Readiness Checklist)와 연결하기

장기 실행되는 에이전트(agent)가 프로덕션에 배포되기 전에 두 가지 질문에 대한 답이 필요합니다: 일반적인 세션에서 예상되는 컨텍스트 예산(context budget)은 얼마인가? 모델의 최대치가 아닙니다. 이 특정 에이전트가 이 특정 작업 클래스(task class)에서 DQR(데이터 품질/응답 품질)이 저하되기 시작하는 것으로 측정한 예산입니다. 그 수치가 광고된 토큰 제한이 아니라, 귀하의 운영 한계치(operational ceiling)입니다.

에이전트가 그 한계치에 도달하면 어떻게 됩니까? 압축(compress)합니까? 요약(summarize)하고 페이지 아웃(page out)합니까? 인간에게 에스컬레이션(escalate)합니까? 아니면 다운스트림(downstream)에서 무언가를 알아차릴 때까지 정확도가 저하된 상태로 조용히 계속 진행합니까? 두 번째 질문에 대한 답이 "계속 진행한다"라면, 그것이 바로 귀하의 신뢰성 격차(reliability gap)입니다. 컨텍스트 한계치는 비용 관련 포스트에서 다룬 토큰 예산 한계치와 마찬가지로 서킷 브레이커(circuit breaker) 사고방식이 필요합니다.

# agentsre/context_budget.py
from dataclasses import dataclass, field
from typing import Optional
import json
from datetime import datetime, timezone

@dataclass
class ContextBudgetTracker:
    """
    운영 DQR 한계치 대비 컨텍스트 사용량을 추적합니다.
    모델의 광고된 토큰 제한은 귀하의 운영 제한이 아닙니다.
    귀하의 운영 제한은 이 에이전트가 이 작업 클래스에서 DQR이 저하되기 시작하는 토큰 수입니다.
    섀도 모드(shadow mode)에서 해당 기준선(baseline)을 설정하십시오.
    그보다 낮은 수치로 한계치를 설정하십시오.

    Attributes:
        agent_id: 추적 중인 에이전트
        task_class: 작업 유형 (DQR 한계치는 작업 복잡도에 따라 달라짐)
        operational_ceiling_tokens: 이 에이전트/작업 조합에서 DQR이 저하되는 토큰 수. 모델의 최대치가 아님.
    """

warning_threshold_pct: 경고 임계치 비율 (Fraction of ceiling triggering warning)
current_tokens: 현재 토큰 수 (Current context utilization)
""" agent_id: str task_class: str operational_ceiling_tokens: int warning_threshold_pct: float = 0.75 current_tokens: int = 0 session_id: str = "" compression_events: int = 0 @property def utilization_pct(self) -> float: """ 현재 컨텍스트 활용률을 운영 최대치 대비 비율로 반환합니다.""" return self.current_tokens / self.operational_ceiling_tokens
@property def budget_status(self) -> str: """ 상태를 반환합니다. OK — 안전 작동 범위 내 WARNING — DQR 저하 임계치에 근접 CRITICAL — 운영 최대치에 도달했거나 초과, DQR 저하 중"""
u = self.utilization_pct
if u < self.warning_threshold_pct: return "OK"
elif u < 1.0: return "WARNING"
return "CRITICAL"
def update(self, current_tokens: int) -> dict: """ 현재 컨텍스트 활용률을 업데이트하고 상태 기록을 반환합니다. 각 도구 호출 또는 모델 응답 후에 이 함수를 호출해야 합니다. CloudWatch / Datadog에 로깅할 상태 기록을 반환합니다."""
self.current_tokens = current_tokens
record = {"agent_id": self.agent_id, "session_id": self.session_id, "task_class": self.task_class, "current_tokens": self.current_tokens, "operational_ceiling": self.operational_ceiling_tokens, "utilization_pct": round(self.utilization_pct, 3), "budget_status": self.budget_status, "compression_events": self.compression_events, "timestamp": datetime.now(timezone.utc).isoformat(), }
return record
def record_compression(self) -> None: """컨텍스트 압축 또는 요약이 발생했을 때 호출합니다."""
self.compression_events += 1
def should_compress(self) -> bool: """컨텍스트가 DQR 저하 임계치에 근접하면 True를 반환합니다."""
return self.utilization_pct >= self.warning_threshold_pct
def should_escalate(self) -> bool: """운영 최대치에 도달했거나 초과일 때 True를 반환합니다. 이 시점에서는 DQR이 활발하게 저하되고 있습니다. 사람에게 에스컬레이션하거나 세션을 깔끔하게 종료해야 합니다."""

return self.utilization_pct >= 1.0

실무적인 베이스라인 프로토콜 (Practical Baseline Protocol)
운영상의 컨텍스트 상한선 (context ceiling)을 설정하기 전에, 귀하의 특정 작업 클래스(task class)에서 특정 에이전트의 DQR이 실제로 저하되기 시작하는 지점을 알아야 합니다.

단계:

1. 대표적인 샘플 작업들에 대해 에이전트를 섀도 모드 (shadow mode)로 실행합니다.
2. 모델이 광고하는 컨텍스트 제한 (context limit)의 25%, 50%, 75%, 100% 지점에서 DQR을 기록합니다.
3. DQR이 떨어지기 시작하는 변곡점 (inflection point)을 찾습니다.
4. 해당 변곡점의 80% 지점에 운영 상한선을 설정합니다. 이것이 귀하의 경고 임계값 (warning threshold)입니다.
5. 상한선에 도달하면, 작업을 계속하는 것이 아니라 압축 (compression) 또는 에스컬레이션 (escalation)을 트리거합니다.

이는 HER 및 RTD와 동일한 베이스라인 프로토콜입니다. 30일 동안 섀도 모드를 실행하고, 지표를 측정하고, 임계값을 설정하십시오. 유일한 차이점은 컨텍스트 예산 저하 (context budget degradation)가 작업 범위 (task-scoped)가 아닌 세션 범위 (session-scoped)라는 점입니다.

이 포스트가 이 시리즈에 포함된 이유
포스트 4에서는 DQR을 출력 품질 SLI로 정의했습니다. 포스트 9에서는 토큰 예산 (token budget)을 비용 차단기 (cost circuit breaker)로 정의했습니다. 포스트 11에서는 RTD를 추론 관측성 계층 (reasoning observability layer)으로 소개했습니다. 이 포스트는 이 세 가지를 연결합니다. 컨텍스트 윈도우 (context window) 관리 부실은 DQR을 저하시키고, RTD를 높이며, 토큰 예산을 동시에 소진시키는 공통 원인입니다. 메모리 아키텍처를 수정하면 세 가지 SLI 모두에서 개선을 확인할 수 있습니다. 이는 우연이 아닙니다. 이들은 동일한 실패를 서로 다른 각도에서 측정하고 있는 것입니다.

코드는 GitHub의 agentsre/context_budget.py에 있습니다. MIT 라이선스이며, 외부 의존성이 없습니다.

Ajay Devineni | AWS Community Builder | Senior SRE/Platform Engineer
github.com/Ajay150313/agentsre