#컨텍스트 윈도우는 창고가 아니라 주의력 예산이다

← 전체 목차 · 이전: 첫 글자 지연은 왜 주로 Prefill을 보나 · 다음: 다중 턴 대화에서 왜 이력을 그냥 밀어 넣으면 안 되나

신입은 컨텍스트 윈도우에 아직 절반이 남은 것을 보면 사용자 이력 전체를 통째로 밀어 넣는다. 정보가 많을수록 안전하다고 여긴다. 그런데 프로덕션에서 안정적으로 도는 Agent를 만드는 사람들은 오히려 절반 이상을 지워버린다. 자리가 남았는데도 굳이 채우지 않는다. 이 대비 자체가 답이다.

윈도우에 자리가 있는 것 ≠ 모델에게 그만큼의 주의력이 있는 것. token을 하나 더 넣을 때마다 핵심 지시가 주의력을 조금씩 나눠준다.

#핵심 답변: 창고가 아니라 주의력 예산

• 수백만 자를 담는다고 표방해도 모델은 모든 내용을 똑같이 대할 수 없다.
• 집어넣는 모든 단락이 본래부터 부족한 주의력을 소비한다.
• 결론: 많이 넣을수록 많이 잃는다.

배치는 세 차원으로 한다: 정보 밀도, 관련성, 역할 책임.

컨텍스트 예산을 관리하는 것이 단순히 윈도우를 넓히는 것보다 훨씬 값지다.

#메커니즘 1: 주의력 가중치 희석, 노이즈 바닥 상승

Transformer의 주의력은 token 두 쌍 사이에서 계산된다.

token이 많아질수록
  → 각 token이 분배받는 주의력 가중치가 작아지고
  → 노이즈 바닥이 높아지며
  → 핵심 정보가 바닥으로 가라앉는다

#메커니즘 2: "중간에서 길을 잃다"(Lost in the Middle)

• 모델은 컨텍스트의 머리와 꼬리 정보를 가장 확실히 기억한다.
• 중간에 놓인 정보는 내용이 완전히 정확해도 자주 누락된다.
• 정확률이 크게 떨어진다.

이것은 모델이 똑똑하지 않아서가 아니라 롱컨텍스트의 물리 법칙이다. 꽉 채울수록 중간이 사라지기 쉽다.

#실제 사고 사례: 상담 Agent의 환불 지시가 묻히다

이것이 **주의력 희석(Attention Dilution)**의 전형적인 현장이다.

#간과되는 두 번째 대가: 비용과 지연

• 매 라운드 호출마다 이력 전체가 요청과 함께 다시 전송된다.
• token이 계속 불어나 요금과 첫 글자 지연이 함께 오른다.

"프롬프트 캐시를 쓰면 싸지지 않나"라는 반론에 대해:

캐시는 「안정적 접두사」에만 유효
  ├─ 캐시 쓰기 자체에 가산금이 붙고
  └─ 중간 token이 조금만 바뀌어도 → 캐시 즉시 무효 → 재과금

세 개의 예산: 윈도우가 공짜라 해도 주의력, 비용, 지연 세 가지 예산이 모두 존재한다. 이력을 많이 넣을수록 셋이 함께 터진다.

#해법: 3층 편성

#정렬 법칙: 세 개의 "~할수록 앞으로"

정보 밀도가 높을수록      → 앞으로
현재 작업과 관련될수록    → 앞으로
역할 책임이 핵심일수록    → 앞으로

#수위선과 관측

0. 정성
   「컨텍스트 윈도우는 주의력 예산이다.」
1. 평가
   먼저 신호 가치로 각 이력을 평가한다.
2. 계층화
   그다음 역할 책임으로 계층을 나눈다:
     - 시스템 프롬프트가 최고 우선
     - 현재 작업 지시는 머리에, 고우선순위 표기
     - 이력은 최근 몇 턴 + 요약만
3. 수위선
   컨텍스트에 수위선을 두고, 70%를 넘으면 절삭 또는 압축을 트리거한다.
4. 관측
   「지시 실행 지표」를 지속 관측해 핵심 지시가 희석되지 않았음을 확인한다.

#핵심 통찰

1. 용량과 가용성은 별개다 — 윈도우 크기는 모델이 "얼마나 받을 수 있는지"를 말하고, 주의력 예산은 모델이 "실제로 얼마나 돌볼 수 있는지"를 말한다. 엔지니어링에서 행동을 결정하는 것은 후자뿐이므로 "아직 절반 남았다"는 결코 집어넣을 이유가 되지 못한다.
2. 컨텍스트는 제로섬의 주의력 배분이지 공짜 저장이 아니다 — token 하나가 늘 때마다 나머지 모든 token의 가중치가 조금씩 얇아진다. 컨텍스트에 무언가를 더하는 것은 언제나 대가가 있다. 그 자체로는 무해한 잡담도 희석제다.
3. 위치는 일종의 우선순위 신호다 — "중간에서 길을 잃다"는 모델의 기억 강도가 위치에 따라 불균등하게 분포함을 말해준다. 머리와 꼬리는 고주의력 구역, 중간은 감쇠 구역이다. 따라서 "핵심 지시를 어디에 두는가"는 대화 순서에 따라 자연히 결정되는 결과가 아니라 능동적으로 설계할 수 있는 엔지니어링 변수가 된다.
4. 실패가 침묵한다는 점이 진짜 위험이다 — 사례에서 모델은 에러도 거부도 하지 않고 "네, 알겠습니다" 한마디를 했으며, 3일 후 사용자 신고로 드러났다. 주의력 희석이 만드는 것은 의미 층위의 실행 누락이므로 일반적인 에러 모니터링으로는 잡히지 않고, 지시 실행 지표로 능동 관측할 수밖에 없다.
5. 컨텍스트 예산은 최소 세 개의 장부다 — 주의력, 비용, 첫 글자 지연이 같은 방향으로 악화된다. "윈도우가 충분한가"만 논하는 답변은 프로덕션 시스템을 해보지 않았음을 정확히 드러낸다.
6. 캐시는 긴 이력의 면죄부가 아니다 — 프롬프트 캐시의 수익은 "접두사 안정"이라는 전제 위에 서 있는데, 다중 턴 대화야말로 접두사가 계속 다시 쓰이는 시나리오다. 중간 token이 하나 바뀌면 전량 재계산이다. 캐시로 돈을 아끼는 것과 이력을 꽉 채우는 것은 방향이 충돌한다.
7. 삭감은 손실 압축의 타협이 아니라 신호 대 잡음비를 올리는 수단이다 — 절반을 지우는 이유는 담을 수 없어서가 아니라, 지우고 나면 핵심 지시의 상대적 가중치가 올라가기 때문이다. **"적은 것이 곧 정확한 것"**은 롱컨텍스트에서 정량화 가능한 엔지니어링 결론이다.
8. 수위선을 두어 편성을 피드백 있는 제어 시스템으로 만들 것 — 임계값(70%)이 절삭·압축을 트리거하고 지표가 핵심 지시의 희석 여부를 상시 관측한다. 임계값과 피드백이 있어야 컨텍스트 관리가 일회성 프롬프트 설계에서 운영 가능하고 회귀 가능한 시스템 능력으로 바뀐다.

#엔지니어링 실전 Tips

• 핵심 지시는 "앞으로"만이 아니라 "격리"할 것: 환불 같은 지시는 독립된 고우선순위 자리를 가져야 한다. 이력 흐름 속에서 앞쪽에 있는 것과, 별도의 블록으로 앞쪽에 있는 것은 희석될 확률이 다르다.
• 요약은 계층적으로, 일률적으로 하지 말 것: 최근 몇 턴은 원문 보존, 더 이른 것은 요약, 잡담은 그냥 삭제. 세 등급의 처리가 세 등급의 정보 밀도에 대응한다.
• 첫 글자 지연을 따로 주시할 것: 매 턴 이력을 다시 보내면 입력 측이 팽창하고, 총 소요 시간보다 첫 글자 지연에 먼저 반영된다. 컨텍스트 팽창의 조기 지표로 쓸 것.
• 캐시를 쓰려면 접두사 안정을 지킬 것: 캐시가 안정적 접두사에만 유효하므로, 편성 시 시스템 프롬프트와 도구 정의 같은 불변 내용이 실제로 가장 앞에 머물며 다시 쓰이지 않게 하고 변동 부분은 되도록 뒤로 보낼 것.
• 실패 모드에 이름을 붙일 것: "주의력 희석", "중간에서 길을 잃다"처럼 통일된 명칭이 있어야 팀이 원인을 규명할 때 공통 언어를 가진다. 사례에서도 이 개념이 먼저 있었기에 로그를 뒤질 때 "지시가 작업으로 인식되었는지"를 확인할 생각을 할 수 있었다.
• 답변에 비용 시각을 담을 것: "비용과 지연도 컨텍스트 예산의 일부"라는 한마디가 빠지면 여전히 개념 층에 머문다. 이 한 줄이 개념 문제에서 엔지니어링 문제로 건너가는 분수령이다.