The Missing Memory Hierarchy: Demand Paging for LLM Context Windows

이 논문은 LLM 의 컨텍스트 창을 메모리 계층 구조로 재해석하고, Pichay 라는 수요 기반 페이징 시스템을 통해 생산 환경에서 컨텍스트 소비를 최대 93% 까지 줄이는 동시에 상태 유지 문제를 해결하는 방법을 제시합니다.

핵심

이 논문은 인공지능 (LLM) 이 대화할 때 겪는 **'기억력 문제'**를 해결하기 위해, 1960 년대 컴퓨터 과학에서 개발된 '가상 메모리' 기술을 적용한 혁신적인 연구를 소개합니다.

간단히 말해, **"AI 가 대화할 때 필요한 정보를 마치 컴퓨터의 메모리처럼 관리하면, 비용은 줄이고 성능은 높일 수 있다"**는 내용입니다.

이 복잡한 내용을 일상적인 비유로 쉽게 설명해 드릴게요.

---

1. 문제: AI 의 '단기기억'은 너무 비싸고 좁다

지금까지 AI(예: Claude, ChatGPT) 는 대화할 때마다 처음부터 끝까지 모든 대화 내용을 다시 읽습니다.

• 비유: 친구와 1 년간 매일 대화했다고 상상해 보세요. 그런데 AI 는 오늘 대화할 때, 어제, 일주일 전, 1 년 전의 대화 내용까지 모두 다시 읽어야만 오늘 이야기를 이해할 수 있습니다.
• 현실: AI 는 대화할 때마다 "내 친구가 뭘 했지? 이 파일은 뭐였지?"라고 다시 확인하기 위해, 대화 기록 전체를 다시 읽습니다.
• 결과:
  1. 비용 폭탄: 불필요한 내용을 계속 읽으니 돈이 엄청나게 나갑니다.
  2. 혼란: 중요한 내용보다 쓸모없는 옛날 이야기 (예: 10 분 전에 읽은 파일, 이미 해결된 버그) 가 AI 의 '머리'를 차지해서 진짜 중요한 일에 집중하지 못합니다.
  3. 한계: 대화가 길어질수록 AI 는 기억할 공간이 부족해져서 "더 이상 기억할 수 없다"며 대화를 끊어버립니다.

논문은 이를 **"AI 가 L1 캐시 (매우 빠르지만 아주 작은 메모리) 만 가지고 있고, L2 나 하드디스크 같은 큰 저장공간이 없다"**고 지적합니다.

2. 해결책: '피차이 (Pichay)'라는 새로운 관리자

연구진은 **'피차이 (Pichay)'**라는 시스템을 만들었습니다. 이는 AI 와 사용자 사이에 끼어드는 '지능형 중개자' 역할을 합니다.

이 시스템은 컴퓨터의 '가상 메모리 (Demand Paging)' 기술을 차용했습니다.

🏠 비유: 책상 정리하기

• 기존 방식 (문제): 책상 (AI 의 기억 공간) 에 모든 서류를 다 펼쳐놓고 일합니다. 서류가 너무 많아지면 책상이 꽉 차서 일할 공간이 없어집니다.
• 피차이 방식 (해결):
  1. 필요한 것만 책상에: 지금 당장 필요한 문서만 책상 (L1) 에 올려둡니다.
  2. 안 쓰는 것은 서랍으로: 한참 전에 읽은 파일이나 해결된 버그 기록은 책상에서 치워 **서랍 (L2/L3)**에 넣습니다.
  3. 필요하면 다시 꺼내오기: 만약 AI 가 "아, 그 파일이 필요했어!"라고 말하면, 피차이는 서랍에서 그 파일을 다시 꺼내서 책상에 올려줍니다.

이때 중요한 점은, AI 가 서랍에 있는 걸 모른 척하고 다시 꺼내달라고 요청하면, 시스템이 알아서 그걸 '페이지 폴트 (Page Fault)'라고 인식하고 처리한다는 것입니다.

3. 피차이의 핵심 기능 3 가지

1. 쓰레기 청소 (Garbage Collection):
   • AI 가 한 번 읽고 다시는 안 쓸 '일시적인 명령 결과'는 아예 없애버립니다. (예: "디렉토리 목록을 보여줘"라는 명령의 결과물은 한 번만 보면 됩니다.)
2. 지능적인 정리 (Demand Paging):
   • 오래된 파일은 책상에서 치웁니다. 대신 책상에는 **"이 파일은 서랍에 있습니다. 필요하면 다시 읽어주세요"**라는 메모만 남겨둡니다.
   • AI 가 그 파일을 다시 읽으려 하면, 시스템이 알아서 서랍에서 가져옵니다.
   • 재미있는 사실: AI 는 이 메모를 보고 "아, 내가 이 파일을 다시 읽어야겠구나"라고 스스로 알아서 행동합니다.
3. 협업 (Cooperative Management):
   • 기존 컴퓨터는 프로그램이 "이거 필요 없어"라고 말하지 못했지만, AI 는 대화 중 **"이건 정리해도 돼"**라고 스스로 말할 수 있습니다. 피차이는 AI 의 이 말을 듣고 즉시 정리해 줍니다.

4. 실제 효과: 얼마나 좋을까요?

연구진은 실제 개발자들이 AI 를 사용하는 857 개의 세션을 분석했습니다.

• 낭비 발견: AI 가 읽는 정보 중 **약 22%**는 쓸모없는 '쓰레기'였습니다. (이미 읽은 파일, 중복된 설명, 해결된 버그 기록 등)
• 성능 향상: 피차이를 쓰니 대화 공간이 93% 까지 줄어든 사례도 나왔습니다. (예: 5MB 가 필요했던 대화가 339KB 만으로도 가능해짐)
• 비용 절감: 불필요한 읽기 작업을 줄여 비용을 크게 아끼고, 더 긴 대화를 가능하게 만들었습니다.

5. 결론: 왜 이 연구가 중요한가?

지금까지 AI 업계는 "메모리 공간이 부족하면 더 큰 메모리를 사자 (더 긴 컨텍스트 윈도우)"라고 생각했습니다. 하지만 이는 비싼 RAM 을 계속 늘리는 것과 같습니다.

이 논문은 **"메모리 크기를 키우는 게 아니라, 메모리를 잘 관리하는 시스템 (계층 구조) 을 만들어야 한다"**고 말합니다.

• 핵심 메시지: AI 의 기억 문제는 단순히 '공간 부족'이 아니라, **'잘못된 관리'**에서 옵니다.
• 미래: 이 기술을 적용하면 AI 는 더 길고 복잡한 일을 처리할 수 있고, 우리는 더 저렴하게 AI 를 쓸 수 있게 됩니다.

한 줄 요약:

"AI 가 대화할 때 책상 위를 계속 정리해주고, 필요할 때만 서랍에서 자료를 꺼내오게 하면, AI 는 더 똑똑해지고 우리는 더 돈을 아낄 수 있다."

기술 요약

1. 문제 정의: 컨텍스트 윈도우는 메모리가 아니다

• 현재의 한계: 현재 LLM 애플리케이션 (Claude Code, Cursor 등) 은 컨텍스트 윈도우를 '전체 메모리 시스템'으로 취급합니다. 모든 API 호출 시 시스템 프롬프트, 도구 정의, 전체 대화 기록을 다시 조립하여 전송합니다. 이는 1960 년대 이전의 '오버레이 (Overlay)' 방식과 유사하며, 운영체제가 개발한 가상 메모리 (가상 주소 공간, 페이징, 작업 집합 이론) 의 개념이 부재합니다.
• 구조적 낭비: 실제 프로덕션 환경 (857 세션, 44.5 억 토큰) 분석 결과, 입력 토큰의 **21.8%**가 구조적 낭비로 확인되었습니다.
  • 사용되지 않는 도구 스키마 (11.0%)
  • 중복된 콘텐츠 (2.2%)
  • 더 이상 참조되지 않는 오래된 도구 결과 (8.7%)
• 비용 증폭: 이러한 낭비된 토큰은 세션이 지속될수록 매번 재처리되며, 토큰당 평균 84.4 배의 증폭 효과 (Amplification Factor) 를 발생시킵니다. 이는 $O(n^2)$ 비용 폭발을 유발합니다.
• 오해: 업계는 컨텍스트 제한을 해결하기 위해 컨텍스트 윈도우 크기 (L1 캐시) 를 늘리는 데 집중하지만, 이는 물리적 RAM 을 늘리는 것과 같아 확장성이 떨어집니다. 진정한 해결책은 **계층화된 메모리 관리 (L1~L4)**입니다.

2. 방법론: Pichay 시스템 설계

Pichay는 클라이언트와 추론 API 사이에 투명하게 작동하는 HTTP 프록시입니다. 모델이나 클라이언트 코드 변경 없이 컨텍스트를 관리합니다.

2.1 메모리 계층 구조 (Memory Hierarchy)

• L1 (생성 윈도우): 현재 API 호출 시 모델이 주의를 기울이는 토큰. 작고 빠르며 비쌈.
• L2 (작업 집합, Working Set): 모델이 활발히 사용하지만 매번 L1 에 상주할 필요 없는 콘텐츠. **결함 기반 고정 (Fault-driven Pinning)**을 통해 관리됨.
• L3 (세션 히스토리): 완료된 대화나 도구 상호작용. 요약 (Compression) 을 통해 압축 저장.
• L4 (세션 간 영구 메모리): 세션이 종료된 후에도 유지되는 지식. 검색 및 인덱싱 가능.

2.2 핵심 메커니즘

1. 수거 (Garbage Collection) vs 페이징 (Paging):
   • 수거: 재요청이 불가능한 일시적 도구 결과 (Bash 출력 등) 는 즉시 제거.
   • 페이징: 파일 경로 등 식별 가능한 콘텐츠는 제거되지만, 필요 시 다시 불러올 수 있도록 '검색 핸들 (Retrieval Handle)'로 대체.
2. 페이지 폴트 감지 (Page Fault Detection):
   • 모델이 이전에 제거된 (Evicted) 콘텐츠를 다시 요청하면 이를 '페이지 폴트'로 간주합니다.
   • 프록시는 이를 감지하여 해당 콘텐츠를 다시 불러옵니다.
3. 결함 기반 고정 (Fault-Driven Pinning):
   • 제거된 콘텐츠가 한 번이라도 폴트 (재요청) 를 발생시켰다면, 해당 페이지는 세션 동안 **고정 (Pinned)**되어 다시 제거되지 않습니다. 이는 LRU 와 유사하지만, 실제 사용 패턴을 학습합니다.
4. 협력적 메모리 관리 (Cooperative Memory Management):
   • 기존 OS 와 달리 LLM 은 메모리 관리자와 협력할 수 있습니다.
   • 팬텀 도구 (Phantom Tools): 모델이 memory_release(불필요한 파일 제거 요청) 나 memory_fault(필요한 파일 복구 요청) 를 호출할 수 있도록 프록시가 가상의 도구를 제공합니다.
   • 정리 태그 (Cleanup Tags): 모델이 대화 기록을 요약하거나 특정 블록을 삭제하도록 프록시에 지시할 수 있습니다.
5. 점진적 압력 구역 (Graduated Pressure Zones):
   • 토큰 사용량에 따라 Normal → Advisory(모델에 경고) → Involuntary(자동 제거) → Aggressive(비상 제거) 단계로 전환됩니다.

3. 주요 결과 (Results)

3.1 오프라인 시뮬레이션 및 폴트율

• 140 만 건의 시뮬레이션된 제거 (Eviction) 중 **페이지 폴트율은 0.0254%**에 불과했습니다. 이는 4 사용자 턴 이상 지난 콘텐츠는 거의 재사용되지 않음을 의미하며, FIFO 기반의 단순 정책으로도 매우 안전함을 입증했습니다.

3.2 프로덕션 배포 효과

• 컨텍스트 효율성: 한 세션에서 컨텍스트 여유 공간이 **7% 에서 43%**로 증가했습니다.
• 압축률: 극단적인 681 턴 세션에서 컨텍스트 크기를 5,038KB 에서 339KB 로 93% 감소시켰습니다.
• 스래싱 (Thrashing) 현상: 작업 집합이 상주 집합을 초과하는 극단적인 상황에서는 폴트와 재로딩이 반복되는 스래싱이 발생했으나, 이는 운영체제 이론에서 예측된 바와 같습니다.

3.3 품질 평가 (Non-inferiority)

• 18 개의 세션에 대한 A/B 테스트에서, 제거된 도구 결과를 토막낸 (Tombstone) 환경에서도 모델의 출력 품질 (정확성, 완전성, 일관성) 은 베이스라인과 통계적으로 유의미한 차이가 없었습니다.
• 오히려 불필요한 노이즈가 제거되어 **주의 집중 (Attention Concentration)**이 개선된 세션도 관찰되었습니다.

4. 기여 및 의의

1. 실증적 데이터: 프로덕션 환경에서 LLM 컨텍스트의 21.8% 가 구조적 낭비임을 입증하고, 이를 도구 스키마, 중복, 노후 결과 등으로 분류했습니다.
2. 시스템 구현 (Pichay): LLM 을 위한 첫 번째 요구 기반 페이징 시스템을 구현하고, 프로덕션 환경에서 0.0254% 의 폴트율을 달성했습니다.
3. 새로운 메모리 관리 패러다임:
   • 결함 기반 고정: 폴트 이력을 학습하여 작업 집합을 동적으로 고정하는 정책 제안.
   • 협력적 관리: 하드웨어 메모리 계층에는 없던, 애플리케이션 (모델) 이 메모리 상태를 인지하고 직접 관리에 참여하는 메커니즘 (팬텀 도구, 정리 태그) 을 도입했습니다.
4. 비용 모델의 반전 (Inverted Cost Model):
   • 기존 VM 은 '폴트 (디스크 I/O) 를 최소화'하는 것이 목표였으나, LLM 은 '컨텍스트에 토큰을 유지하는 비용 (매 턴 계산 비용)'이 '폴트 비용'보다 훨씬 큽니다.
   • 따라서 **적극적인 제거 (Aggressive Eviction)**가 오히려 비용 효율적이며, 폴트 비용은 선형이 아닌 $O(n^2)$ (어텐션 비용) 이므로 컨텍스트 크기를 줄이는 것이 핵심임을 이론적으로 정립했습니다.
5. 인프라 경제적 영향: 토큰 처리 비용 절감뿐만 아니라, KV 캐시 메모리 사용량 감소로 인해 동시 사용자 수 (Throughput) 를 21.8% 증가시킬 수 있는 잠재력을 제시했습니다.

5. 결론

이 논문은 LLM 컨텍스트 관리가 단순한 프롬프트 최적화 문제가 아니라, 가상 메모리 계층 구조의 부재라는 시스템 공학적 문제임을 지적합니다. Pichay 는 L1~L4 로 이어지는 계층적 메모리 관리의 첫 단계를 실현하며, "더 큰 컨텍스트 윈도우"가 아닌 "지능적인 메모리 관리"가 LLM 시스템의 확장성과 경제성을 결정한다는 새로운 통찰을 제공합니다.