Attention Budget와 Context Rot

컨텍스트는 무한하지 않다

에이전틱 루프가 진행될수록 컨텍스트 창은 점점 두꺼워진다. 관찰(observation), 도구 호출 결과, 모델의 중간 응답이 이터레이션마다 차곡차곡 쌓인다. 128k 토큰, 심지어 200k 토큰을 초과하는 컨텍스트 창을 지원하는 모델이 등장하면서 “컨텍스트가 늘어나도 괜찮다”는 막연한 안도감이 생겼다. 그러나 이 안도감은 위험하다.

LLM의 핵심 메커니즘인 **셀프 어텐션(self-attention)**은 입력 토큰 수 n에 대해 O(n²) 의 계산 복잡도를 갖는다. 토큰 수가 두 배가 되면 어텐션 행렬 연산량은 네 배, 메모리 사용도 네 배에 달한다. 실제로 최신 모델들은 Flash Attention이나 희소 어텐션(sparse attention) 같은 기법으로 이를 상당 부분 완화하지만, 근본적인 이차 스케일링 특성은 변하지 않는다. 그리고 계산 비용보다 더 중요한 문제가 있다. 컨텍스트가 길어진다고 해서 모델이 그 안의 모든 정보를 똑같이 잘 활용하지는 않는다는 점이다.

주의 예산(Attention Budget)이란

**주의 예산(attention budget)**이란 모델이 한 번의 추론 패스에서 실질적으로 집중할 수 있는 정보의 총량을 가리킨다. 컨텍스트 창의 크기(capacity) 와 모델이 실제로 효과적으로 참조할 수 있는 정보의 범위(effective range) 는 다른 개념이다. 연구들은 일관되게 모델 어텐션이 창 전체에 균등하게 분산되지 않음을 보여준다. 가장 최근 토큰과 첫 번째 토큰 근방에 어텐션이 집중되고, 중간 구간은 상대적으로 소홀해지는 경향이 있다.

이 불균등한 집중도를 고려해 컨텍스트를 배치하는 것이 주의 예산 설계의 핵심이다. 중요한 지시나 핵심 사실을 컨텍스트 창 한가운데에 아무렇게나 놓으면, 모델이 그것을 제대로 참조하지 못할 위험이 생긴다.

┌──────────────────────────────────────────────────────────────┐
│                  컨텍스트 창과 실효 주의 분포                   │
├──────────────┬──────────────────────────┬────────────────────┤
│  창 위치     │  어텐션 강도              │  권장 내용          │
├──────────────┼──────────────────────────┼────────────────────┤
│  앞쪽 (↑)   │  ████████████  (높음)    │  시스템 프롬프트,   │
│             │                           │  목표 명세, 도구 정의│
├──────────────┼──────────────────────────┼────────────────────┤
│  중간 (→)   │  ███           (낮음)    │  오래된 도구 결과   │
│             │                           │  → compaction 대상  │
├──────────────┼──────────────────────────┼────────────────────┤
│  뒤쪽 (↓)   │  ███████████   (높음)   │  최신 관찰, 현재    │
│             │                           │  스텝 도구 결과     │
└──────────────┴──────────────────────────┴────────────────────┘

이 구조에서 루프 설계의 기본 원칙이 나온다. 시스템 프롬프트와 작업 목표는 앞쪽에 고정하고, 최신 도구 결과는 뒤쪽에 노출하며, 중간에 쌓인 오래된 내용은 주기적으로 압축한다.

맥락 부패(Context Rot): 루프의 고질병

**맥락 부패(context rot)**란 루프가 진행되면서 컨텍스트 창이 오래된 정보, 중복 내용, 이미 해결된 오류 메시지로 가득 차 모델의 유효 추론 능력이 점진적으로 저하되는 현상이다. 이는 소프트웨어 프로젝트에서 오래된 댓글과 죽은 코드가 쌓여 코드베이스를 이해하기 어렵게 만드는 것과 유사하다. 컨텍스트가 길어진다고 반드시 더 많은 유용한 정보를 활용하는 것이 아니다. 오히려 핵심 신호가 잡음 속에 묻힐 수 있다.

맥락 부패는 다음 경로로 누적된다.

첫째, 도구 결과의 무제한 적재. 파일 읽기, API 응답, 테스트 출력이 이터레이션마다 그대로 추가된다. 20번 읽은 파일이 20개의 동일한 도구 결과 블록으로 컨텍스트를 채운다.

둘째, 에러 메시지 반복. 같은 컴파일 오류나 테스트 실패가 여러 이터레이션에 걸쳐 중복 등장한다. 모델은 이미 한 번 처리한 오류를 다시 읽고 다시 처리하는 데 추론 용량을 낭비한다.

셋째, 초기 지시의 희석. 루프 시작 시점의 목표 설명이 수만 토큰 뒤로 밀려나면, 모델이 원래 임무를 잊고 국소적인 하위 문제에만 집중하는 **목표 표류(goal drift)**가 발생한다.

넷째, 메타 추론 과부하. “내가 지금까지 무엇을 했는가”를 파악하는 데 추론 용량의 상당 부분이 소비되어, 실제 작업에 쓸 용량이 줄어든다.

# 개념 이해용 의사 코드이며 실제 API와 다를 수 있습니다.

COMPACTION_THRESHOLD = 80_000  # 토큰 수 임계치 (예시 값)

def run_loop(task: str, tools: list, max_iters: int = 30):
    messages = [{"role": "user", "content": task}]

    for i in range(max_iters):
        token_count = estimate_tokens(messages)

        # 맥락 부패 방지: 임계치 도달 시 압축
        if token_count > COMPACTION_THRESHOLD:
            messages = compact(messages)

        response = model.generate(messages, tools=tools)

        if response.stop_reason == "end_turn":
            return response.content

        for call in response.tool_calls:
            result = run_tool(call)
            # 도구 결과 크기도 제한: 대용량 파일은 요약본만 추가
            messages.append({
                "role": "tool",
                "content": truncate_if_large(result, max_chars=4000)
            })

    raise RuntimeError("max_iters 초과: 루프 강제 종료")

컨텍스트를 정적·동적으로 나누기

Anthropic의 컨텍스트 엔지니어링 가이드는 컨텍스트를 정적(static) 부분과 동적(dynamic) 부분으로 분리해 설계할 것을 권장한다.

구분	내용	위치	변경 빈도
정적	시스템 프롬프트, 도구 정의, 작업 명세	앞쪽 고정	루프 내 불변
동적	관찰, 도구 결과, 모델 응답	뒤쪽 누적	매 이터레이션
압축 대상	오래된 동적 내용	중간 구간	임계치 도달 시

정적 부분은 **프롬프트 캐싱(prompt caching)**의 주요 대상이기도 하다. 변하지 않는 앞쪽 내용을 캐시하면 반복 호출 비용을 크게 줄일 수 있다(캐시 읽기는 기본 입력가의 약 10%).

Anthropic 멀티에이전트 리서치 시스템은 서브에이전트에게 별도의 컨텍스트를 부여해 오케스트레이터의 컨텍스트 창이 오염되지 않도록 격리하는 방식을 채택했다. 이는 주의 예산을 여러 에이전트에 분산하는 부가 효과도 낳는다.

루프 엔지니어에게 의미하는 것

컨텍스트 관리는 단순한 비용 최적화가 아니다. 루프가 수십 회 이상 반복되는 장기 에이전트에서 주의 예산 설계는 작업 완료 가능 여부를 결정짓는 근본 조건이다. 토큰 한도에 도달해 루프가 중단되거나, 맥락 부패로 모델이 초기 목표를 잃어버린 채 엉뚱한 방향으로 달려가는 상황은 루프 엔지니어라면 반드시 선제적으로 대비해야 한다.

이어지는 챕터들에서는 이 문제를 구체적인 전략으로 해소하는 방법을 살펴본다. 5-2에서는 중간 위치 정보가 왜 특히 취약한지 실증 연구로 확인하고, 5-3에서는 compaction 전략을, 5-4에서는 루프 메모리 계층을, 5-5에서는 JIT 검색을 통해 신선한 컨텍스트를 유지하는 방법을 다룬다.