한 예시적인 보고 에이전트가 월간 운영 검토(monthly operating review)를 준비합니다. 이 에이전트는 재무, CRM, 지원(support), 데이터 웨어하우스(data warehouse)를 쿼리하고, 이번 달을 이전 기간과 비교하며, 중요한 변화를 조사하고, 설명을 초안하고, 담당자의 의견을 수집하며, 며칠에 걸쳐 보고서를 수정합니다.

세 번째 수정 단계에 이르면, 에이전트의 컨텍스트(context)에는 가공되지 않은 쿼리 결과, 폐기된 가설, 반복된 지침, 오래된 담당자 의견, 그리고 현재의 초안이 포함되어 있습니다. 가장 중요한 수정 사항인 '재무 담당자가 원래의 수익 설명을 거부한 내용'은 이제 그 이전에 발생한 모든 정보와 경쟁하게 됩니다.

에이전트의 지능이 고갈된 것이 아닙니다. 에이전트는 **컨텍스트 부채 (context debt)**를 축적한 것입니다. 즉, 일시적인 실행 자료가 영구적인 추론 입력(reasoning input)이 되어버린 것입니다.

컨텍스트 윈도우 (Context window)는 작업 표면이지, 기록 시스템이 아니다

모든 중간 결과물을 모델 컨텍스트에 유지하는 것은 아무것도 잃어버리지 않는다는 점에서 안전하게 느껴질 수 있습니다. 하지만 실제로 실행 과정이 길어질수록 관련성(relevance)은 떨어집니다.

• 대규모 도구(tool) 응답이 토큰(token)을 소비합니다.
• 오래된 지침이 새로운 결정과 충돌합니다.
• 반복된 요약이 미세한 왜곡을 유발합니다.
• 거부된 가설이 수용된 결과물 근처에 남아 있습니다.
• 현재의 결과물을 이전 초안과 구별하기가 점점 더 어려워집니다.

더 큰 컨텍스트 윈도우는 이 문제를 지연시킬 뿐입니다. 컨텍스트 윈도우가 어떤 상태가 권위 있는지, 어떤 증거를 복구할 수 있는지, 또는 어떤 결정이 재시작 시 생존해야 하는지를 정의해주지는 않습니다.

장기 실행 워크플로(workflow)에는 최소 네 가지의 저장 역할이 필요합니다.

1. 작업 컨텍스트 (Working context)

현재의 목표, 즉각적인 제약 조건, 선택된 증거, 그리고 다음에 실행 가능한 단계가 여기에 속합니다. 이 세트는 모든 항목이 다음 결정에 영향을 미칠 수 있을 만큼 충분히 작아야 합니다.

2. 내구성이 있는 작업 상태 (Durable task state)

완료된 체크포인트(checkpoint), 담당자, 승인, 마감일, 미결 예외 사항, 허용된 다음 작업 등은 프롬프트(prompt) 외부에 존재해야 합니다. 이 상태는 모델 호출, 워커(worker) 재시작, 그리고 핸드오프(handoff) 상황에서도 유지되어야 합니다.

3. 증거 저장소 (Evidence storage)

가공되지 않은 원본 결과(Raw source results)는 안정적인 식별자(identifiers), 타임스탬프(timestamps), 그리고 액세스 제어(access controls)와 함께 유지되어야 합니다. 에이전트는 모든 기록을 모든 프롬프트(prompt)에 주입하지 않고도, 이후 단계에서 검사가 필요할 때 이를 다시 불러올 수 있습니다.

4. 산출물 상태 (Deliverable state)

현재의 보고서, 계획, 티켓 또는 기타 비즈니스 산출물(artifact)은 자체적인 버전 기록(version history)을 가져야 합니다. 검토자(Reviewer)의 변경 사항은 대화 전체 기록(conversation transcript)을 변경 사항의 유일한 기록으로 만들지 않으면서도 이 산출물을 업데이트할 수 있어야 합니다.

프롬프트(prompt)에서 내용을 이동시키는 것은 삭제를 의미하지 않습니다. 이는 런타임(runtime)이 의도적으로 정보를 검색할 수 있는 곳에 정보를 배치하는 것입니다.

압축(Compaction)은 단순히 텍스트를 줄이는 것이 아니라 의사결정을 보존해야 합니다

일반적인 대화 요약(conversation summary)은 주제는 유지할 수 있지만, 중요한 운영상의 사실(operational fact)을 놓칠 수 있습니다. 예를 들어, 누가 설명을 거부했는지, 어떤 소스(source)가 그것을 대체했는지, 그리고 수정 사항이 하나의 지표(metric)에만 적용되는지 아니면 보고서 전체에 적용되는지 등의 정보 말입니다.

유용한 체크포인트(checkpoint)는 구조화되어 있습니다. 예를 들어:

{
  "task_id": "monthly-review-2026-07",
  "objective": "승인된 운영 검토서 작성",
...

정확한 스키마(schema)는 달라질 수 있습니다. 중요한 부분은 의사결정(decisions)을 그것을 생성한 토큰(tokens)으로부터 분리하는 것입니다.

각 체크포인트는 다음 질문에 답할 수 있어야 합니다:

1. 모델 컨텍스트(model context)에 무엇이 남아 있는가?
2. 무엇이 영구적인 상태(durable state)로 이동하는가?
3. 나중에 복구할 수 있는 원본 증거(raw evidence)는 무엇인가?
4. 이 상태에서 유효한 작업(actions)은 무엇인가?

압축(Compaction), 하위 작업 격리(subtask isolation), 그리고 점진적으로 로드되는 지침(progressively loaded instructions)은 이러한 선택을 강제하기 위한 메커니즘입니다. 이것들은 상태 모델(state model)의 대체재가 아닙니다.

하위 작업은 격리와 공유된 계약(shared contract)이 필요합니다

보고 워크플로우(reporting workflow)는 재무 변동 분석, 영업 파이프라인 변경, 그리고 지원량 분석을 분리할 수 있습니다. 각 하위 작업(subtask)은 해당 작업과 관련된 시스템, 정의(definitions), 그리고 기간(period)만을 전달받습니다.

격리(Isolation)는 간섭을 줄여주지만, 통합 문제(integration problem)를 야기합니다. 조정 에이전트(coordinating agent)는 서로 다른 정의를 사용하는 세 개의 정제된 내러티브(narratives)를 안전하게 조정(reconcile)할 수 없습니다.

공유된 결과 계약(shared result contract)은 모든 하위 작업이 다음을 반환하도록 요구할 수 있습니다:

• 지표 식별자(metric identifier) 및 보고 기간;
• 현재 값 및 비교 값;
• 설명 및 신뢰도(confidence);
• 권위 있는 출처 참조(authoritative source references);
• 미해결 문제;
• 요청된 결정 또는 승인.

이 계약(contract)은 단순히 형식을 개선하는 것 이상의 역할을 합니다. 이는 코디네이터(coordinator)에게 검증(validation), 비교(comparison), 그리고 재시도(retry)를 위한 안정적인 경계를 제공합니다.

하나의 하위 작업(subtask)이 실패할 경우, 런타임(runtime)은 전체 워크플로우(workflow)를 다시 실행하지 않고도 해당 단위만 재실행할 수 있습니다. 만약 검토자(reviewer)가 지표 정의를 수정하면, 시스템은 해당 정의에 의존하는 결과물만을 무효화할 수 있습니다.

재개(Resuming)는 일급 시민 연산(first-class operation)입니다

장기 실행 에이전트(long-running agent)는 시작 지점뿐만 아니라 체크포인트(checkpoint)로부터도 테스트되어야 합니다.

재개 시점에 런타임은 다음 사항들을 재구성할 수 있어야 합니다:

• 현재 목표 및 승인된 결과물 버전;
• 완료된 단계 및 대기 중인 단계;
• 활성 소유자(active owners) 및 마감 기한;
• 최신 권위 있는 결정 사항;
• 다음 단계에 필요한 증거 참조(evidence references);
• 여전히 유효한 권한(permissions).

마지막 항목이 중요한 이유는 워크플로우가 일시 중지된 동안 권한(authority)이 변경될 수 있기 때문입니다. 어제 승인된 작업이라도 에이전트가 오늘 작업을 수행하기 전에는 새로운 확인이 필요할 수 있습니다.

따라서 재개 테스트(resume test)는 단순히 저장된 프롬프트(prompt)를 불러오는 것 이상을 의미합니다. 이는 워크플로우가 영구적인 상태(durable state)로부터 최소한의 신뢰할 수 있는 작업 세트(working set)를 재구축할 수 있는지 검증합니다.

컨텍스트 부채(Context debt)는 운영 비용을 발생시킵니다

외부 상태(external state)는 저장(storage), 보존(retention), 그리고 접근 제어(access-control) 결정을 수반합니다. 압축(compaction) 과정에서 나중에 중요해질 세부 사항이 누락될 수 있습니다. 하위 작업 격리(subtask isolation)는 오케스트레이션(orchestration) 복잡성을 증가시킵니다. 증거를 다시 불러오는 과정은 지연 시간(latency)을 추가할 수 있습니다.

이것들은 측정 가능한 트레이드오프(tradeoffs)입니다. 유용한 신호(signals)로는 다음이 포함됩니다:

• 워크플로우 단계별 컨텍스트 크기;
• 동일한 증거의 반복적인 검색(retrieval);
• 검토자에 의한 압축 수정 사항;
• 체크포인트 재개 실패;
• 재시작 후 사용된 오래된(stale) 결정 사항;
• 증거 재로드 지연 시간;
• 승인된 결과물당 비용.

일부 작업은 압축(compacting)하는 대신 일시 중지되어야 합니다. 만약 검토자(reviewer)가 목표를 근본적으로 변경한다면, 에이전트에게 길고 모순적인 이력을 재해석하도록 요구하는 것보다 명시적인 인수인계(handoff)와 함께 새로운 버전을 시작하는 것이 더 안전할 수 있습니다.

다른 실행(run)이 신뢰할 수 있는 기록으로 마무리하기

완료된 보고서는 보고 기간, 지표 정의(metric definitions), 검토자 결정 사항, 증거 참조(evidence references), 그리고 해결되지 않은 주의 사항(caveats)을 유지해야 합니다. 다음 달의 에이전트는 해당 결과물을 생성하는 데 발생했던 모든 실행 잔해(execution debris)를 상속받지 않고도, 승인된 산출물(artifact)을 비교 대상으로 사용할 수 있습니다.

컨텍스트 부채(Context debt)는 시스템이 기억(memory)을 축적(accumulation)과 혼동할 때 발생합니다. 장기 실행 에이전트에는 끝없이 성장하는 프롬프트가 아니라, 유지 관리되는 작업 세트(working set)와 내구성이 있는 운영 기록(durable operating record)이 필요합니다.

귀하의 장기 실행 에이전트에서는 작업 컨텍스트(working context)와 내구성이 있는 작업 상태(durable task state)를 어떻게 분리하고 계신가요?

이 기사는 Coryntas에서 처음 게시된 Long-Running Agents Accumulate Context Debt를 DEV 커뮤니티를 위해 각색한 것입니다.