제9장 — 주의력 예산 관리

LLM Primer IV: MCP로 설계하는 AI 인지를 챕터별로 따라가는 워크스루의 아홉 번째 글입니다. 백만 토큰 컨텍스트 윈도가 운영 지점이 아니라 천장 값임이 드러나고, 「모델이 더 나빠졌다」의 놀랄 만큼 큰 몫이 사실은 「모델이 묻혔다」임이 드러납니다.

이 장이 존재하는 이유

컨텍스트 윈도는 자유 공간처럼 보입니다. 그렇지 않습니다. 에이전트가 읽는 모든 토큰은 지연 시간, 돈, 그리고 — 덜 명백하지만 더 중요하게 — 품질에 비용을 듭니다. 백만 토큰 윈도가 「모든 것을 채워라」를 뜻한다는 환상은 현재 관행에서 가장 비싼 오독 중 하나이며, 모델 회귀로 진단되는 프로덕션 실패의 큰 몫을 설명합니다. 모델이 나빠진 것이 아닙니다. 묻힌 것입니다. 이 장은 컨텍스트를 자유 자원이 아니라 유한 예산으로 다루는 것입니다. 무엇이 예산을 먹는지, 예산이 잘못된 도구일 때 어떤 대안이 있는지, 그리고 에이전트가 정확히 필요한 것만 갖고 더 갖지 않는 생산적 지대에 어떻게 착지하는지.

9.1 컨텍스트 부패와 비선형 절벽

컨텍스트 길이와 품질의 관계는 선형적이지 않습니다. 프롬프트를 두 배로 늘려도 품질이 절반이 되지 않습니다. 어느 지점을 지나면 절반 이상으로 떨어집니다. 자리잡은 기술 용어 — 컨텍스트 부패 — 는 비공식적이지만 정확합니다. Liu와 동료들의 고전적 스탠퍼드 연구는 문서 목록에서 정보를 찾으라는 요청을 받은 모델이 관련 문서가 양 끝에 있을 때보다 가운데에 있을 때 극적으로 더 못한다는 점을 보였습니다. U자 곡선은 모델 군과 컨텍스트 길이에 걸쳐 재현되었습니다. 긴 프롬프트의 가운데는 의미 있는 의미에서 경계보다 어텐션상 더 싸다 — 아키텍처는 모든 위치를 동일하게 다루지만.

2023년과 2024년에 표준이 된 「건초더미 속의 바늘」 벤치마크는 처음에는 이 그림을 반박하는 듯했습니다 — 100K, 200K, 심지어 1M 토큰에서 거의 완벽한 검색. 더 신중한 후속 작업은 벤치마크가 너무 쉬웠음을 보였습니다. 균질한 건초더미 속의 두드러진 바늘은 스무 개의 주제적으로 관련된 방해물 사이에 묻힌 관련 사실을 찾는 것과는 다른 문제입니다. 2025년 후반에 출시된 MCP-Universe와 BIG-Bench-Long은 그 적대적 구조를 내장했고, 숫자는 우울합니다. 100K 토큰에서 프런티어 모델은 동일 작업의 8K 시점에 비해 10~20점을 잃고, 500K에서 격차는 40점에 달할 수 있습니다.

MCP 에이전트에 특정된 두 번째 부패 형태가 있습니다. 도구가 시스템 프롬프트에 쌓이면 모델이 알맞은 도구를 고르는 정확도가 저하됩니다. MCP-Universe는 도구 다섯 개에서 약 90%였던 도구 선택 정확도가 마흔 개에서 60% 아래로 떨어지는 것을 보였습니다. 실무자는 이를 이제 도구 로드아웃 부패라고 부르며, 「능력을 더한 뒤 에이전트가 멍청해졌다」의 단일 가장 흔한 원인입니다. 두 경우의 메커니즘은 같습니다. 어텐션은 유한하고, 프롬프트가 자랄수록 각 토큰이 받는 몫이 줄어듭니다.

9.2 같은 질문에 대한 세 가지 답: MCP, RAG, 파인튜닝

모델이 필요한 지식을 갖지 못할 때 세 가지 아키텍처적 답이 있으며, 하나를 다른 것으로 혼동하는 일이 잘못 배분된 노력의 놀랄 만큼 큰 몫의 원인입니다. MCP는 지식이 운영적일 때 들어맞습니다 — 현재 재고, 오늘의 캘린더, 빌드의 상태. 이것들은 권위 있는 출처를 가지고, 계속 바뀌며, 사전 적재된 컨텍스트로는 최신성을 유지할 수 없습니다. 승리는 단지 신선도뿐 아니라 책임감입니다. 모델이 「빌드가 그린입니다」라고 말할 때, 사용자는 「무엇에 따라」를 물을 수 있고, 답은 「이 타임스탬프에 쿼리된 빌드 서버에 따라」입니다.

RAG는 지식이 문서적일 때 들어맞습니다 — 윈도에는 너무 크지만 검색 인덱스가 실현 가능할 만큼 안정된 코퍼스. 내부 문서, 지원 기사, 계약서, 큰 코드베이스. 이 시리즈 제3권은 전적으로 RAG 엔지니어링에 관한 책이며 정전적 레퍼런스로 남습니다. 파인튜닝은 간격이 행동일 때 들어맞습니다 — 일관된 형식, 특정 목소리, 한 요청 부류의 신뢰할 만한 거부. 업계에서 반복되는 잘못 배분은 변하는 사실 지식을 주입하려고 파인튜닝을 쓰는 것이며, 이는 잠깐 인상적이다가 세상이 그 동결 스냅숏에서 표류함에 따라 점차 틀려가는 모델을 만듭니다.

셋은 배타적이지 않습니다. 성숙한 에이전트는 보통 그것들을 결합합니다. 행동에는 파인튜닝, 문서적 지식에는 RAG, 운영적 지식에는 MCP. 도움이 되는 프레이밍은 알맞은 신선도 요구에 알맞은 기질입니다. 행동은 모델 세대 척도에서 안정적입니다. 가중치에 구워 넣으십시오. 문서적 지식은 일 척도에서 바뀝니다. 인덱싱하십시오. 운영적 지식은 초 척도에서 바뀝니다. 도구를 통해 닿으십시오. 기질을 어긋나게 맞춘 아키텍처 — 빠르게 변하는 사실에 동결된 가중치, 라이브 상태에 검색 인덱스 — 는 정확성, 지연 시간, 또는 둘 다에서 비용을 지불합니다.

9.3 골디락스 지대: 충분한 컨텍스트, 너무 많지 않게

일상 질문은 매 호출에 얼마나 많은 컨텍스트를 전달할지입니다. 가운데의 지대는 대부분의 팀이 처음 가정하는 것보다 좁습니다. 가장 결과적인 레버는 시스템 프롬프트입니다. 좋은 것은 짧고, 구체적이고, 안정적입니다. 나쁜 것은 누적으로 자라는 방어적 프롬프트이며, 모델이 잘못 행동할 때마다 절이 더해져 결국 모델이 더 이상 신뢰성 있게 따를 수 없는 천 단어짜리 규칙 문서가 됩니다. 분기마다 명시적 제거를 목표로 감사하는 팀은 일 년 전보다 짧은 프롬프트로 끝나며 더 나은 행동을 만듭니다.

두 번째 레버는 도구 명단입니다. 도구 로드아웃 부패의 교정은 점진적 공개입니다. 소수의 고수준 도구를 등록하고 모델이 발견 도구를 통해 구체로 파고들게 두십시오. 좁은 도구 마흔 개는 내부 디스패치를 가진 넓은 도구 네 개가 되고, 도구 선택 정확도는 잃은 것 대부분을 회복합니다. 세 번째 레버는 대화 이력입니다 — 윈도 용량의 90%가 아니라 첫 턴부터 압축하십시오. 네 번째는 도구 결과입니다. 전체 행이 아니라 모델이 필요로 하는 필드를 반환하십시오. 규율은 의도적 포함입니다. 모든 요소에 대해 팀은 「이것이 없다면 무엇이 일어날까」에 답할 수 있어야 합니다. 답이 「에이전트는 같게 행동할 것」이라면 제거되어야 합니다.

제9장이 준비하는 것

이 장은 단일 추론 호출 안에서 컨텍스트를 유한 예산으로 프레임했습니다. 다루지 않은 것은 시간의 질문입니다. 30초 도는 에이전트는 단일 윈도에 맞는 예산 문제를 갖습니다. 30분, 3시간, 3일을 도는 에이전트는 어떤 실용적 크기의 윈도도 담을 수 없는 메모리 문제를 갖습니다. 그 일 척도를 위한 전략은 정도가 아니라 종류에서 다릅니다.

다음 → 제10장: 장기 호라이즌 작업 메모리. 슬라이딩 윈도와 ReAct 스크래치패드를 통한 단기 메커니즘, 일화적 벡터와 의미적 저장소를 통한 장기 메커니즘, 그리고 에이전트가 시간과 일을 가로질러 운영되게 하는 압축 기법.