에이전트의 컨텍스트가 부족해지는 것이 아니라, 79%에서 성능이 저하됩니다

나의 긴 에이전트 (agent) 세션 중 하나가 처음으로 잘못되었을 때, 나는 엉뚱한 것을 찾고 있었다. 나는 context window exceeded (컨텍스트 창 초과)라는 문구를 검색했다. 스택 트레이스 (stack trace)를 찾으려 했고, API로부터의 400 에러를 찾으려 했다. 하지만 아무것도 없었다. 실행은 완료되었다. 다만 시작할 때보다 더 나쁜 상태로 끝났을 뿐이다 — 더 허술해진 도구 호출 (tool calls), 이미 파악했던 내용을 다시 도출하는 단계, 20단계 전에 명시된 제약 조건을 무시하는 답변 같은 것들 말이다.

충돌도 없었고, 에러도 없었다. 에이전트는 컨텍스트 (context)가 부족해진 것이 아니었다. 그 과정에서 점점 더 멍청해진 것이었다.

내가 받아들이는 데 너무 오랜 시간이 걸렸던 부분은 이것이다: 손상은 컨텍스트 창이 가득 차기 훨씬 전부터 시작된다. 단계별 성공률 대 컨텍스트 창 점유율을 나타낸 합성 모델 (synthetic model)에 따르면, 신뢰도 하한선은 100% 초과 시점이 아니라 79% 점유율에서 무너진다. exceeded (초과)라는 문구를 볼 때쯤이면, 에이전트는 이미 세션의 상당 부분을 조용히 더 약한 단계들을 수행하며 허비한 상태다.

요약 버전

만약 여러 단계를 실행하는 에이전트를 구축한다면, 단순히 초과 여부만 보지 말고 사용 중인 컨텍스트 창의 비율을 주시하라. 단계의 품질은 창이 채워지는 동안 평탄하게 유지되다가, 70~80% 부근의 변곡점(knee)을 지나며 아래로 꺾인다. 그 변곡점 _이전_의 임계값에서 결정론적 핸드오프 (deterministic handoff; 요약, 체크포인트, 점유율 압축 등)를 수행하면 전체 세션을 상한선 위로 유지할 수 있다. 아래 모델에서는 2번의 압축 (compaction)을 통해 50단계 중 31개의 양호한 단계를 50개 중 50개 모두 양호한 단계로 바꾼다.

이것이 핵심 아이디어다. 나머지는 결과물(artifact)과 이것이 무엇을 증명하고 무엇을 증명하지 못하는지에 대한 정직한 설명이다.

먼저 결과물부터

내가 이야기하려는 출력 결과다. 하나의 합성 세션, 두 번의 실행. 처음에는 단순하게(Naive), 그다음에는 핸드오프 게이트(handoff gate)를 적용하여:

=== 단순한 긴 세션 (핸드오프 없음, '그냥 들어가길 기도함') ===
하한선 위를 유지한 단계: 31/50
하한선 아래로 떨어진 첫 단계의 점유율: 81%
...

하단 블록을 아래에서 위로 읽어보세요. 윈도우(window)의 절반 지점에서는 단계(step)가 97%의 확률로 성공합니다. 70%에서는 여전히 90%입니다. 85%에서는 72%로 떨어지며, 95%에서는 동전 던지기보다 조금 나은 수준인 0.61까지 떨어집니다. 곡선은 절벽처럼 뚝 떨어지지 않습니다. 휘어집니다. 그 휘어지는 지점이 바로 아무도 로그에 기록하지 않는 부분입니다.

실제 운영 환경(production)에서 단계의 성공을 신뢰할 수 있는 기준선인 바닥(floor)은 점유율 **78.6%**에서 교차됩니다. 단순한 세션(naive session)의 _첫 번째 실패한 단계_는 81%에서 나타나는데, 이는 단계들이 이산적인 점유율 그리드(discrete occupancy grid) 상에 떨어지며, 기준선을 넘어선 첫 번째 단계가 정확히 78.6%가 아닌 81%에 위치했기 때문입니다. 같은 이야기입니다. 하나는 곡선이고, 다른 하나는 실제 단계가 우연히 떨어진 지점입니다.

모델 전체 코드

이것이 전체 스크립트입니다. stdlib만 사용하며, 네트워크, 무작위성(randomness), 시계(clock)가 없습니다. python3 -I occupancy_handoff.py를 실행하면 매번 위의 바이트 데이터가 출력됩니다.

#!/usr/bin/env python3
"""긴 에이전트 세션을 위한 점유율(Occupancy) -> 단계 성공(step-success) 모델.

...

중요한 메커니즘은 run_session에 있습니다. 단순한 실행(naive run)은 계속해서 추가하기만 합니다: 50단계 × 2,600 토큰 = 100k 윈도우 대비 130k이므로 오버플로(overflow)가 발생하며, 그중 19개의 단계가 바닥을 지난 성능 저하 구역에 떨어집니다. 핸드오프 실행(handoff run)은 각 단계가 수행되기 _전_에 점유율을 확인합니다. 점유율이 70%에 도달하면 30%로 다시 압축합니다(요약과 체크포인트를 포함하여, 긴 작업을 짧은 작업으로 다시 접는 방식). 그런 다음 절반이 비어 있는 윈도우에서 단계를 수행합니다. 50단계 동안 두 번의 압축이 이루어집니다. 모든 단계가 기준선 위를 유지합니다.

임계값(threshold)은 의도적으로 굴곡(knee) 지점 _아래_에 설정되었습니다. 70%는 여유(margin)를 제공합니다. 단계의 성공률을 잃기 시작할 때쯤이면 이미 리셋을 완료한 상태가 됩니다.

내가 이 형태를 신뢰하는 이유 (그리고 주장하지 않는 것)

이 스크립트가 무엇인지 솔직하게 말씀드리겠습니다. 이것은 합성된 고정 장치(synthetic fixture)입니다. 저는 메커니즘을 명확하게 보여주기 위해(평탄함, 굴곡, 하락) 곡선과 바닥을 선택한 것이지, GPT나 Claude 또는 그 누구의 모델을 측정하기 위함이 아닙니다. 벤더 벤치마크(vendor benchmark)를 원하신다면 이것은 그것이 아니며, 이를 벤치마크인 것처럼 꾸민다면 그것은 거짓말일 것입니다.

실제로 중요한 것은 그 형태(shape)와 그것이 어디에서 왔는가입니다. 저희 Apify actor에서 수행된 2,190회의 프로덕션 실행(production runs) 중, 프로덕션 환경에서 혹사당한 단일 Trustpilot 스크레이퍼(scraper)에서 수행된 962회의 실행을 살펴보면, 제가 계속 목격한 패턴은 깔끔한 오버플로(overflow) 충돌이 아니었습니다. 그것은 벽에 부딪히기 전의 '품질(quality)' 저하였습니다. 즉, 모든 로그 라인은 정상(green)을 유지하고 있음에도 불구하고, 실행 시간이 길어질수록 더 약하고 일관성 없는 단계(steps)를 생성하는 것이었습니다. 예외도 없었고, 400 에러도 없었으며, grep으로 찾아낼 수 있는 것도 없었습니다. 그저 성능이 나빠질 뿐이었습니다.

그것으로부터 단 하나의 마법 같은 백분율을 제시하지는 않겠습니다. 왜냐하면 저에게는 그런 것이 없기 때문입니다. 작업과 모델에 따라 임계점(knee)은 변동되었으며, 작업에 따라 70~80% 대의 어딘가에 위치했습니다. 이 글의 첫 번째 버전에서 저는 실패 모드(failure mode)가 오버플로라고 가정했고, 완전히 잘못된 이벤트에 대해 계측(instrumented)을 수행했습니다. 저는 절벽(cliff)만을 지켜보았습니다. 하지만 피해는 이미 경사로(ramp)에서 발생하고 있었습니다.

여러분은 여기서 반박할 수 있으며, 그 반박은 옳을 것입니다: "손으로 그린 곡선을 사용한 50단계의 장난감 루프(toy loop)는 실제 모델에 대해 아무것도 증명하지 못한다." 동의합니다. 증명하지 못합니다. 이 스크립트가 얻어낸 것은 '상호작용(interaction)'에 대해 추론할 수 있는 저렴하고 정확한 방법입니다. 즉, 고정된 성공 곡선(success curve)에 채우기 비율(fill rate)과 게이트(gate)를 더하여, 단 하나의 토큰도 소비하지 않고 게이트가 결과를 어떻게 바꾸는지 관찰할 수 있는 것입니다. 이 형태(shape)가 바로 제가 프로덕션에서 가져온, 제가 지지하는 주장입니다. 스크립트는 게이트가 그 형태에 어떤 영향을 미치는지 보여주기 위해 제가 찾아낸 가장 깔끔한 방법일 뿐입니다.

실제 인용이 포함된 부분

이것은 단순히 저의 패턴 매칭(pattern-matching) 결과가 아닙니다. 2025년 10월, Du, Tian, Ronanki 및 7명의 공동 저자는 Context Length Alone Hurts LLM Performance Despite Perfect Retrieval (arXiv:2510.05381)를 발표했습니다. 그들의 연구 결과는 로그가 저에게 말해주던 것의 학술적 버전입니다: 입력 길이가 길어짐에 따라, 모델이 모든 관련 사실을 완벽하게 검색(retrieve)할 수 있음에도 불구하고 성능이 13.9%에서 85%까지 하락합니다. 따라서 이것은 "올바른 정보가 유실된 것"이 아닙니다. 점유된 공간 그 자체가 피해를 입히는 것입니다.

그리고 그들의 해결책은 'handoff(인계)'와 운이 맞닿아 있습니다. 그들의 완화 방법은 모델이 "문제를 해결하려고 시도하기 전에 검색된 증거를 암송(recite)하게 만드는 것"입니다. 그들은 이것이 "긴 컨텍스트(long-context) 작업을 짧은 컨텍스트(short-context) 작업으로 변환한다"고 언급합니다. 이는 결국 다른 이름의 압축(compaction)일 뿐입니다. 그들은 길이 그 자체만으로도 해가 된다는 것을 증명했습니다. 위에서 언급한 게이트(gate)는 오버플로(overflow)가 발생한 후가 아니라, 실행 중인 에이전트(agent)가 그 대가를 치르기 전에 이를 막는 한 가지 방법입니다.

이것이 컨텍스트 세금(context tax)과 다른 점

제가 이전에 작성한 컨텍스트 세금(context tax)에 관한 글을 읽어보셨다면, 이 내용이 그와 유사해 보일 수 있지만, 이것이 어떻게 다른지 말할 가치가 있습니다. 이전 글은 **비용(cost)**에 관한 것이었습니다. 즉, 긴 세션에서 동일한 페이지를 다시 읽는 것이 토큰 비용을 부풀린다는 내용이었습니다. 이번 내용은 **품질(quality)**에 관한 것입니다. 동일한 점유 공간이 올바른 단계를 수행할 확률을 낮추며, 이는 예산을 망가뜨리기 전 더 이른 시점에 발생합니다. 하나는 지갑을 털어가고, 다른 하나는 조용히 정확도를 갉아먹으며, 당신은 나중에야 그 사실을 알게 됩니다.

따라서 당신에게는 압축해야 할 이유가 하나가 아니라 실제로 두 가지가 있습니다. 비용은 요란한 이유이고, 79%는 조용한 이유입니다.

내가 월요일에 할 일

긴 세션에서 점유율(occupancy)을 일급 객체 메트릭(first-class metric)으로 추적하십시오. 성능이 급격히 떨어지는 지점(knee)보다 낮은 handoff 임계값을 선택하십시오. 저는 70%에서 시작하여 조정할 것입니다. 임계값에 도달하면 결정론적(deterministically)으로 압축하십시오. 상태를 요약하고, 중요한 것을 체크포인트(checkpoint)로 저장하며, 점유율을 낮춘 뒤 계속 진행하십시오. exceeded(초과)될 때까지 기다리지 마십시오. 그때가 되면 당신은 이미 로그에 아무런 흔적도 남기지 못한 채 성능이 저하된 수많은 단계들을 이미 실행해 버린 상태일 것입니다.

여기에 제가 여전히 모르고 있는 부분, 그리고 여러분의 의견을 듣고 싶은 부분이 있습니다. 여러분의 작업에서, 여러분의 에이전트는 어느 정도의 점유율에서 멍청해지기 시작합니까? 그리고 그 지점을 찾았을 때, 임계값에 따라 압축을 수행하나요, 아니면 여전히 (컨텍스트가) 다 들어갈 수 있기를 바라나요?

저는 실제 운영 환경의 수치들을 기록하며, 불편한 진실들도 포함합니다. 다음 글을 팔로우해 주시고, 여러분의 에이전트가 어디서부터 미끄러지기 시작하는지 댓글로 알려주세요. 실제로 실행하는 작업에서 단계 품질이 떨어지는 점유율 수치를 알려주세요.

AI의 도움을 받아 작성되었으며, 사람이 편집 및 사실 확인을 수행했습니다. Python 데모는 특정 모델을 벤치마크하기 위한 것이 아니라 메커니즘(점유율(occupancy) -> 단계 성공(step success))을 테스트하기 위해 선택된 합성 고정 장치(synthetic fixture)입니다. 이는 표준 라이브러리(stdlib)만 사용하며, 네트워크나 무작위성(randomness)이 없고, 실행할 때마다 동일한 출력을 출력합니다. 2,190회 실행 수치는 당사의 실제 운영 사용량(production usage)입니다.