컨텍스트 윈도우(Context window) 관리는 모든 다단계 에이전트 파이프라인(multi-step agent pipeline)에 숨겨진 비용입니다.

저는 실제 운영 컨설팅 업무를 통해 이러한 패턴을 목격합니다. 테스트 단계에서는 10단계의 과정, 일관된 추론, 정확한 출력 등 깔끔하게 작동하던 에이전트가 배포 후 6주가 지나면 성능이 저하되기 시작합니다. 에러도 없고, 충돌도 없습니다. 그저 표류(drift)할 뿐입니다. 출력은 짧아집니다. 명확한 논리를 보여주던 추론 단계들은 모호한 요약처럼 읽히기 시작합니다. 사용자들은 에이전트가 "느려진 것 같다"고 느끼기 시작합니다.

근본 원인은 거의 항상 동일합니다. 단계가 거듭될수록 컨텍스트(Context)는 커지는데, 아무도 이를 측정하지 않았기 때문입니다.

컨텍스트가 축적되는 방식

다단계 에이전트는 기본적으로 전체 대화 기록을 축적합니다. 모든 도구 호출(tool call) 결과가 추가됩니다. 모든 중간 추론 단계가 저장됩니다. 각 모델 호출(model call)에 전달되는 대화 객체는 실행된 단계의 수에 따라 선형적으로 증가합니다.

10단계 파이프라인에서 8단계나 9단계에 이르면, 모델은 매 호출마다 컨텍스트 윈도우(context window)의 90%를 수신하게 됩니다. 기술적으로는 제한 범위 내에 있지만, 현재 단계에 더 이상 영향을 미치지 않는 수천 개의 이전 추론 토큰(tokens)에 주의력(attention)이 분산됩니다.

실제 파이프라인에서는 다음과 같은 모습으로 나타납니다. 연구 에이전트가 검색을 수행하고, 엔티티(entities)를 추출하며, 모호성을 해결하고, 문서를 검색하고, 순위를 매기고, 초안을 합성하고, 사실 확인(fact-check)을 한다고 가정해 봅시다. 이것은 7단계입니다. 각 단계에서 평균 800 토큰의 도구 출력(tool output)이 생성되고 모델이 각 단계의 전체 추론 흔적(reasoning trace)을 포함한다면 다음과 같습니다:

• 1단계 이후: 컨텍스트 내 약 1,200 토큰
• 3단계 이후: 약 4,800 토큰
• 5단계 이후: 약 9,600 토큰
• 7단계 이후: 약 15,600 토큰

16K 컨텍스트 모델의 경우, 마지막 단계는 실제 합성(synthesis) 작업을 위해 남은 것이 거의 없는 상태로 작동하게 됩니다. 128K 컨텍스트 모델의 경우 수치는 더 여유로워 보이지만, 매 호출마다 그 모든 컨텍스트에 대한 비용을 지불하고 있으며, 모델의 주의력(attention)이 3단계 전에는 관련성이 없어졌던 자료들에 희석되고 있다는 사실을 깨닫게 됩니다.

테스트가 이를 잡아내지 못하는 이유

단일 쿼리 테스트(Single-query testing)는 컨텍스트 포화(context saturation)를 결코 드러내지 않습니다. 개발자가 테스트 세트를 대상으로 파이프라인을 열 번 실행하여 올바른 출력을 확인하고 배포한다고 가정해 봅시다. 그들이 테스트한 것은 각각 0개의 토큰에서 시작하는 열 개의 새로운 대화 스레드(conversation threads)였습니다.

실제 운영 환경의 부하(Production load)는 이와 전혀 다릅니다. 사용자들은 순차적인 작업(sequential tasks)을 수행합니다. 세션 히스토리(session history)를 명시적으로 제한하지 않는다면, 동일한 세션에서 다섯 번의 요청을 실행하는 파이프라인은 다섯 번의 실행 모두로부터 컨텍스트를 축적합니다. 실패한 단계를 재시도하는 오케스트레이션 레이어(orchestration layer)는 실패 원인(failure reasoning)을 다시 컨텍스트로 전달합니다. 외부 API를 호출하고 결과를 기다리는 장기 실행 에이전트(Long-running agents)는 기다리는 동안 도구 로그(tool logs)를 축적합니다.

실제 쿼리 볼륨 하에서의 컨텍스트 성장은 일반적인 의미의 스케일링(scaling) 문제가 아닙니다. 그것은 상태 관리(state management) 문제입니다. 파이프라인은 어떤 과거 컨텍스트가 현재 단계에 여전히 유효한지에 대한 개념이 없습니다.

운영 환경에서 작동하는 세 가지 방법

대화당이 아닌, 단계(step)당 고정된 토큰 예산을 할당하세요.

만약 3단계에서 1단계의 출력이 필요하다면, 1단계의 전체 사고 과정(chain-of-thought)이 아니라 구조화된 결과(structured result)만을 전달하세요. 10개의 결과를 반환하는 검색 단계(search step)가 그 내부의 랭킹 근거(ranking rationale)를 합성 단계(synthesis step)까지 계속 들고 갈 필요는 없습니다. 합성 단계에 필요한 것은 순위가 매겨진 리스트입니다. 단계 경계(stage boundaries)에서 공격적으로 잘라내십시오(Truncate).

이를 위해서는 각 단계의 출력 계약(output contract)이 무엇인지에 대한 의도적인 설계 결정이 필요합니다. 출력이 비구조화된 텍스트(unstructured text)라면, 기본적으로 모든 것이 앞으로 전달됩니다. 출력이 타입화된 스키마(typed schema)라면, 스키마 필드만이 단계 사이를 이동합니다. 이 타입 경계(type boundary)가 토큰 예산을 강제하는 역할을 합니다.

파이프라인 단계 간의 핸드오프(handoff) 전에 요약하고 압축하세요.

검색(retrieval) 단계의 상세한 추론(reasoning) 과정이 합성(synthesis) 단계가 실행될 때까지 유지될 필요는 없습니다. 구조화된 요약(structured summary)은 필요합니다. 한 단계에서 다음 단계로 제어권을 넘기기 전에, 전체 출력을 받아 고정된 크기의 요약본(digest)을 생성하는 압축(compaction) 단계를 실행하세요. 이 요약본은 핵심 사실들을 전달합니다. 전체 추론 흔적(reasoning trace)은 디버깅을 위해 남겨두되, 실제 운영 호출 체인(production call chain)에는 포함시키지 마세요.

압축 단계 자체도 모델 호출이므로 비용이 발생합니다. 하지만 이는 거의 항상 그만한 가치가 있습니다. 3,000토큰의 추론 흔적을 400토큰의 구조화된 요약본으로 압축하면, 파이프라인의 이후 모든 단계에서 2,600토큰을 절약할 수 있습니다. 수천 개의 쿼리를 처리하는 10단계 파이프라인의 경우, 압축 비용은 절약되는 비용에 비해 무시할 수 있는 수준입니다.

단계별로 엄격한 컨텍스트 제한(hard context limit)을 설정하고, 이를 초과하면 명시적으로 실패(fail loudly)하게 하세요.

조용한 컨텍스트 오버플로(context overflow)는 사용자에게 도달하는 미묘하게 잘못된 출력을 생성합니다. 실제 작업을 위해 컨텍스트 윈도우(context window)의 2%만 사용할 수 있는 상태에서 작동하는 모델은 에러를 반환하지 않습니다. 대신 표면적인 품질 검사는 통과하지만 품질이 저하된, 그럴듯하게 들리는 답변을 반환할 것입니다. 단계별 컨텍스트 크기를 능동적으로 측정하지 않는 한, 이러한 실패 모드는 눈에 보이지 않습니다.

엄격한 제한을 추가하는 방법은 간단합니다. 각 모델 호출 전에 토큰 수를 측정하고, 임계값(threshold)을 초과하면 예외(exception)를 발생시키세요. 임계값은 모델의 최대치에 대한 비율이 아니라, 모델의 최대치보다 훨씬 낮은 수준으로 설정해야 합니다. 만약 단계별 예산이 2,000토큰인데 누적된 컨텍스트가 8,000토큰이라면, 해당 파이프라인은 "제한 내에 있는" 것이 아니라 이미 망가진 상태입니다.

명시적으로 실패(fail loudly)한다는 것은 엔지니어링 팀이 문제를 인지한다는 것을 의미합니다. 조용한 성능 저하(silent degradation)는 사용자가 문제를 가장 먼저 발견하게 된다는 것을 의미합니다.

실제로 필요한 계측(instrumentation)

다음 세 가지 지표는 컨텍스트 성장 문제가 사용자에게 영향을 미치기 전에 이를 포착합니다:

1. 단계별 입력 토큰 수 (Tokens-in per step): 파이프라인의 각 단계에서 모델이 받는 토큰의 수입니다. 대화 전체의 총합이 아니라, 각 단계별로 이를 기록(Log)해야 합니다.
2. 컨텍스트 활용률 (Context utilization rate): 입력 토큰 수를 모델의 컨텍스트 제한(context limit)으로 나눈 값입니다. 프로덕션 파이프라인의 어떤 단계에서든 이 수치가 70%를 초과하면 경고(Alert)를 발생시키세요.
3. 단계별 성장률 (Step-over-step growth rate): 연속된 단계 사이에서 컨텍스트가 얼마나 추가되는지를 나타냅니다. 한 단계에서 5,000개의 토큰이 추가된다면, 아마도 전체 추론 과정(reasoning trace)을 그대로 다음 단계로 전달하고 있을 가능성이 높습니다.

이러한 지표들을 수집하는 것은 어렵지 않습니다. 모델 호출(model call)을 감싸는 래퍼(wrapper)를 사용하면 전송 전 프롬프트 토큰 수를 캡처할 수 있습니다. 어려운 점은 대부분의 오케스트레이션 프레임워크(orchestration frameworks)가 이를 기본적으로 노출하지 않는다는 것입니다. 직접 계측(instrumentation)을 추가해야 합니다.

더 깊은 설계상의 문제

컨텍스트 성장이 팀들을 당혹스럽게 만드는 이유는 이것이 버그처럼 보이지 않기 때문입니다. 상태가 없는(stateless) 테스트 환경에서 작동했던 파이프라인 아키텍처는, 상태가 있는(stateful) 프로덕션 부하 환경에서 실패하는 바로 그 아키텍처이기도 합니다. 테스트와 프로덕션 사이에서 축적된 상태(accumulated state)를 제외하고는 바뀐 것이 아무것도 없습니다.

해결책은 메모리나 API 호출을 다루는 것과 동일하게, 컨텍스트를 예산(budget)이 있는 리소스로 취급하는 것입니다. 각 단계는 입력 예산(input budget)과 출력 예산(output budget)을 가집니다. 입력 예산은 해당 단계가 받을 수 있는 양을 제한하며, 출력 예산은 해당 단계가 다음으로 전달할 수 있는 양을 제한합니다. 파이프라인은 이 두 가지를 모두 강제해야 합니다.

명시적인 컨텍스트 예산이 없는 에이전트 파이프라인(agentic pipeline)은 핵심적인 운영 제약 조건 없이 실행되는 것과 같습니다. 이는 작동할 때까지는 잘 작동하겠지만, 결국 실패하게 될 것이며, 그 실패 신호는 대시보드가 감지하기 전에 사용자가 먼저 알아챌 정도로 미묘할 것입니다.

프로덕션 에이전트 시스템을 위한 컨텍스트 윈도우 관리 및 계측은 제가 hannune.ai에서 수행하는 컨설팅 업무의 일부입니다.