100만 토큰 컨텍스트 창이 메모리가 아닌 이유 (2026)

컨텍스트 창은 매 요청마다 처음부터 다시 구축됩니다

대부분의 사람들이 가진 멘탈 모델은 대화가 서버의 세션처럼 모델 내부에 누적된다는 것입니다. 하지만 그렇지 않습니다. 각 요청은 모델에 텍스트 블록(시스템 프롬프트, 이전 대화 차례, 첨부된 파일 등)을 전송하고, 모델은 이어지는 텍스트를 생성합니다. 그것으로 끝입니다. 모델 측에는 아무것도 남지 않습니다.

연속성이 있는 것처럼 착각하게 만드는 것은 클라이언트가 매번 대화 기록을 다시 보내기 때문입니다. 10분 전에 한 말은 "기억"하면서 어제 채팅에서 한 말은 전혀 모르는 이유가 바로 여기에 있습니다. 어제의 대화 기록은 현재 블록에 포함되어 있지 않기 때문입니다. 창이 커진다는 것은 블록이 더 커질 수 있다는 뜻일 뿐, 블록 간에 무언가가 유지된다는 뜻이 아닙니다.

이것이 바로 크기 수치가 메모리 지표로서 오해를 불러일으키는 이유이기도 합니다. 262,144 토큰은 대략 요청당 수십만 단어의 용량을 의미할 뿐, 아카이브가 아닙니다. 이를 가득 채우더라도 다음번에는 여전히 빈 상태로 시작하게 됩니다.

보존된 추론은 대화 내부의 연속성일 뿐, 대화 간의 연속성이 아닙니다

Qwen3.8의 생각 블록(thinking-block) 동작은 정말 유용한 기능이며 경계를 보여주는 완벽한 예시입니다. "대화 전반에 걸쳐 완전한 추론 추적"을 유지한다는 것은 모델이 이전 결론을 다시 도출하는 대신 어떻게 그 결론에 도달했는지 볼 수 있음을 의미합니다. 즉, 모순이 줄어들고, 장기적인 작업 수행 능력이 향상되며, 모델이 자신의 이전 추론을 잊어버려 발생하는 탈선 현상이 줄어듭니다.

범위를 주의 깊게 읽어보세요: 대화 전반에 걸쳐(across the conversation)입니다. 대화들 간(across conversations)이 아닙니다. 추론 추적은 다시 전송되는 대화 기록의 일부이므로, 대화 기록이 유지되는 동안만 생존합니다. 세션을 닫으면 추론도 함께 사라집니다. 하나의 긴 세션을 더 일관되게 만드는 기능이 내일의 세션에 정보를 제공하는 기능은 아닙니다.

100만 토큰은 선택해야 하는 설정이며, 공짜가 아닙니다

확장된 길이는 스케일링 기술이지 기본값이 아닙니다. Qwen의 카드에서는 모델 설정에서 rope_parameters 필드를 변경하는 YaRN의 사용을 설명하고 있으며, 특히 vLLM의 경우 VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 및 --max-model-len 1000000으로 서빙할 것을 안내합니다. 이는 사용자가 트레이드오프의 가치가 있다고 판단하여 모델이 위치를 처리하는 방식을 의도적으로 변경한 것입니다.

그리고 이것은 분명한 트레이드오프입니다. 긴 컨텍스트는 KV 캐시를 보유하는 장치의 메모리 비용과 토큰 생성 시마다의 시간 비용을 초래합니다. 로컬에서 100만 토큰 컨텍스트를 실행하는 것은 체크박스 하나로 해결되는 문제가 아니라 하드웨어 사양의 문제입니다. 반면, 여러분이 실제로 원했던 것—다음 주 화요일에 모델이 여러분의 프로젝트를 알고 있는 것—은 컨텍스트 문제가 전혀 아니기 때문에 VRAM 비용이 전혀 들지 않습니다.

누군가는 여전히 컨텍스트 창에 무엇을 넣을지 결정해야 합니다

이 부분이 간과되곤 합니다. 100만 토큰의 여유와 하드웨어가 있다고 가정해 봅시다. 거기에 무엇을 넣으실 건가요?

이에 답하려면 무엇이 존재하는지, 어떤 부분이 최신인지, 그리고 이 작업에 어떤 부분이 중요한지 알아야 합니다. 이는 검색 및 큐레이션(retrieval-and-curation)의 문제이며, 컨텍스트 창이 커진다고 해서 쉬워지지 않습니다. 오히려 더 어려워집니다. "그냥 전부 다 넣자"가 실현 가능해 보이는 순간, 그 "전부"에 번복된 결정, 두 번의 재작성으로 낡아버린 아키텍처 문서, 동일한 규칙에 대한 세 가지 모순된 버전이 포함되어 있다는 사실을 깨닫게 되기 때문입니다.

큰 컨텍스트 창은 로드할 수 있는 최대 한도를 늘려줄 뿐입니다. 무엇을 로드해야 하는지는 알려주지 않습니다. 그리고 창이 모순으로 가득 차면 모델의 출력은 더 나빠집니다. 모든 벤더가 항상 로드되는 지침 파일의 길이를 짧게 유지하라고 권장하는 이유도 바로 이 때문입니다.

롱 컨텍스트 벤치마크는 다른 능력을 측정합니다

컨텍스트 창 내 검색 평가는 모델이 사용자가 의도적으로 컨텍스트에 배치한 사실을 찾을 수 있는지를 묻습니다. 이는 실제 능력이며 모델들은 이 부분에서 극적으로 발전했습니다. 하지만 이 설정이 가정하는 바를 주목하십시오. 그 사실이 이미 컨텍스트 창 안에 존재한다는 것입니다. 누군가 그것을 거기에 넣어둔 것이죠.

사람들이 실제로 겪는 실패는 다릅니다. 아무도 그것을 거기에 넣지 않았습니다. 왜냐하면 그것은 3주 전에 끝난 대화에서 결정된 사항이고, 그것을 앞으로 전달할 프로세스가 없었기 때문입니다. 롱 컨텍스트 벤치마크의 어떤 점수도 이 문제를 해결하지 못합니다. 이는 모델의 능력 문제가 아니기 때문입니다.

매 세션마다 동일한 컨텍스트 붙여넣기. 가장 널리 쓰이는 임시방편입니다. 작동은 하지만 비용이 많이 듭니다. 매 요청마다 해당 토큰에 대한 비용을 지불해야 하고, 무엇을 붙여넣어야 할지 기억해야 하며, 다른 기기를 사용하거나 동료가 물어보는 순간 그 정보는 존재하지 않게 됩니다.

하나의 거대한 대화를 영원히 열어두기. 문제를 미룰 뿐입니다. 결국 스레드가 느려지거나, 요약되거나, 유실됩니다. 그리고 요약은 뼈아픈 방식으로 정보 손실을 유발합니다. 예를 들어 "순서 보장 문제로 인해 큐 기반 설계를 제외함"과 같은 구체적인 내용이 "아키텍처 논의함"으로 압축되어 버립니다.

더 큰 컨텍스트 창 구매하기. 한계를 높일 뿐, 경계를 바꾸지는 못합니다. 이것이 해결책으로 마케팅되는 업그레이드이며, 롱 컨텍스트 모델로 막 전환한 팀들이 세션 간에 개선된 것이 아무것도 없다는 사실에 가장 놀라는 이유이기도 합니다.

데이터를 로컬에 유지하기 위해 셀프 호스팅하기. 셀프 호스팅을 해야 하는 좋은 이유이긴 하지만, 메모리와는 무관합니다. 자체 GPU에서 실행되는 오픈 가중치 모델은 호스팅된 모델만큼이나 철저하게 당신을 잊어버립니다. 오히려 주변의 모든 레이어를 직접 책임져야 하므로 이 사실을 더 뼈저리게 느끼게 됩니다. 이 격차에 대해서는 셀프 호스팅 모델에 메모리 추가하기에서 다루고 있습니다.

문서를 벡터 저장소에 넣기. 정답에 더 가깝고, 소스 자료를 찾는 데 정말 유용합니다. 이는 작성된 문서의 청크를 검색합니다. 하지만 도달했으나 기록하지 않은 결론은 보관하지 못합니다. 이에 대한 차이점은 RAG가 메모리가 아닌 이유 및 AI 메모리 vs. 벡터 데이터베이스에서 설명합니다.

대화 기록을 폴더에 저장하기. 이제 아무도 읽지 않는 아카이브가 생겼을 뿐입니다. 저장소 역시 메모리가 아닙니다. 메모리는 사용 시점에 검색되어 활용되는 것을 전제로 합니다.

두 자원을 분리하고 나면 설계가 단순해집니다. 컨텍스트 창은 단일 요청에 대한 작업이 일어나는 곳입니다. 지속 가능한 레이어는 요청 간에 지식이 머무르는 곳이며, 그 역할은 크기 경쟁을 하는 것이 아니라 적절한 순간에 적절한 수천 개의 토큰을 컨텍스트 창에 넣어주는 것입니다.

그것이 바로 MemoryLake입니다. 실행 중인 모델이나 모델이 수용할 수 있는 컨텍스트 크기에 관계없이 어시스턴트가 읽을 수 있는 메모리 레이어입니다. 다음 달에 Qwen3.8을 다른 모델로 바꾸든, 로컬에서 실행하든 호스팅해서 실행하든, 32K 창을 쓰든 100만 창을 쓰든 메모리는 이동하지 않습니다. 메모리는 애초에 모델 내부에 있었던 적이 없기 때문입니다. 설정은 세 단계로 진행됩니다.

1단계: API 키 생성하기

MemoryLake에 로그인하고 API 키를 생성합니다. 이 키는 도구가 메모리를 읽고 쓰는 데 사용하는 자격 증명이며, 의도적으로 모델에 종속되지 않도록 설계되었습니다. 이 특성 덕분에 다음 업그레이드 시에도 메모리가 그대로 유지됩니다.

2단계: 첫 번째 메모리 업로드하기

그렇지 않았다면 매번 다시 붙여넣어야 했을 정보들을 입력하세요. 프로젝트 구조, 코드만으로는 명확하지 않은 제약 조건, 결정 사항과 그 배경이 되는 논리, 시도했다가 포기한 접근 방식 등입니다. 항목은 짧고 단일 목적으로 유지하세요. 좋은 항목이란 동료가 추가 질문 없이 바로 조치를 취할 수 있는 수준의 항목이며, 짧은 항목이 긴 항목보다 더 잘 검색됩니다.

3단계: AI 및 에이전트 연결하기

사용하는 도구들을 연결하세요. MemoryLake는 MCP 및 API를 통해 액세스할 수 있으므로, Claude Code, Codex, OpenClaw를 포함한 MCP 네이티브 에이전트들은 MCP 서버를 지정하여 연결하고, 그 외의 도구들은 API를 통해 동일한 메모리를 읽습니다. 실제 결과적으로 컨텍스트 창에는 필요할지도 모르는 모든 것을 거대하게 붙여넣는 대신, 작고 관련성 높은 최신의 조각만 들어가게 됩니다.

두 가지 솔직한 한계가 있습니다. 메모리 레이어는 모델의 롱 컨텍스트 검색 능력을 더 똑똑하게 만들어주지 않습니다. 그것은 모델 고유의 특성이며, 이 부분에 대한 Qwen의 연구 성과는 확실합니다. 또한 메모리 레이어는 사용자나 에이전트가 입력한 내용만 알 수 있습니다. 회의를 도청하거나 마음을 읽지 않습니다. 이는 반복적인 설명을 없애줄 뿐, 결정을 대신해 주지는 않습니다.

기능 저하 없이 토큰 소비가 감소합니다. 컨텍스트를 매번 다시 붙여넣는 것은 매 요청마다 동일한 수천 개의 토큰 비용을 지불함을 의미합니다. 관련성 높은 조각만 검색하면 비용이 훨씬 적게 들며, 모델은 현재 작업과 무관한 자료를 헤맬 필요가 없으므로 더 나은 성능을 발휘합니다. 이에 대한 계산법은 메모리가 토큰 비용을 줄이는 방법에서 다룹니다.

모델 업그레이드가 더 이상 마이그레이션 작업이 되지 않습니다. 지식이 모델 외부에 존재하면, 직접 호스팅하는 오픈 가중치 모델과 호스팅된 프론티어 모델 간의 전환은 단순한 설정 변경에 불과합니다. 지식이 오래 지속되는 대화 내부에 존재할 때는 전환할 때마다 매번 처음부터 다시 시작해야 합니다.

셀프 호스팅의 타당성을 입증하기가 더 쉬워집니다. 자체 모델을 실행할 때 흔히 제기되는 반론은 호스팅된 제품이 "나를 기억한다"는 점입니다. 레이어를 분리하면 이 장점은 사라집니다. 로컬 가중치와 지속적인 컨텍스트를 모두 가질 수 있으며, 이는 둘 중 하나만 가질 때보다 훨씬 강력한 이점입니다.

롱 컨텍스트가 본연의 장점에 맞게 사용됩니다. 큰 컨텍스트 창은 한 번에 많은 자료를 시야에 두어야 하는 작업에 탁월합니다. 예를 들어 대규모 코드베이스를 한 번에 읽거나, 여러 문서를 비교하거나, 장기적인 에이전트 실행 등이 있습니다. 이러한 작업들은 컨텍스트 창이 붙여넣은 배경 지식으로 절반쯤 차 있지 않을 때 훨씬 더 잘 수행됩니다.

창 크기를 메모리 사양이 아닌 용량 사양으로 취급하세요. 모델을 평가할 때 두 가지 개별적인 질문을 던져야 합니다. 한 번에 얼마나 담을 수 있는가, 그리고 세션 간에 무엇이 전달되는가. 두 번째 질문은 거의 모델 자체와 관련이 없습니다.

필요하지 않더라도 의도적으로 로드하세요. 100만 토큰을 넣을 수 있다고 해서 그것이 도움이 된다는 뜻은 아닙니다. 창 내부의 모순되고 낡은 자료는 출력을 저하시킵니다. 이것이 바로 "전부 붙여넣기"의 실제 비용입니다.

결과물뿐만 아니라 결론도 기록하세요. 문서는 존재하는 것을 설명합니다. 가치 있는 지식은 여러분이 무엇을 결정했고 왜 대안을 거부했는지에 대한 것입니다. 그리고 이 부분은 스스로 파일에 기록되지 않는 영역입니다.

헤드라인 수치에 의존하기 전에 확장 설정을 확인하세요. YaRN을 통한 컨텍스트 확장은 실제 하드웨어 비용이 수반되는 설정 변경이지 기본값이 아닙니다. 실제로 어떤 설정으로 서빙하고 있는지 확인하세요.

단 하나의 대화가 아카이브가 되도록 두지 마세요. 특정 스레드가 결정 사항이 존재하는 유일한 장소라면, 그 결정은 단일 장애점(SPOF)과 만료일을 갖게 됩니다.

항상 로드되는 지침은 짧게 유지하세요. 지속 가능한 레이어가 무엇이든, 매 요청마다 로드되는 자료는 작고 최신 상태여야 합니다. 항상 켜져 있는 긴 파일은 지침 준수율을 떨어뜨립니다. 이는 컨텍스트 창 크기와 관계없이 모든 벤더가 일관되게 권장하는 사항입니다.

Qwen3.8-27B는 정말 인상적인 릴리스입니다. Apache-2.0 라이선스의 오픈 가중치, 기본 262K 컨텍스트, 100만 토큰까지 확장 가능, 대화 전반에 걸쳐 보존되는 추론 추적까지. 이 모든 것은 실질적인 개선 사항이지만, 그 중 어느 것도 메모리는 아닙니다.

이것이 중요한 이유는 학문적인 꼼꼼함 때문이 아닙니다. "더 큰 컨텍스트 창을 기다리자"는 핑계가 지속 가능한 레이어 구축을 미루는 이유가 되었고, 그 기다림에는 끝이 없기 때문입니다. 기다리는 대상은 그 방향에서 오지 않습니다. 컨텍스트 창은 계속 커질 것입니다. 하지만 요청이 끝난 후에도 살아남는 것은 별개의 결정이며, 이는 여러분의 몫입니다. 메모리가 더 넓은 의미에서 무엇을 뜻하는지 고민 중이시라면 지속성 메모리의 실제 정의를 읽어보시는 것을 추천하며, Qwen의 호스팅 티어로 이동할 계획이시라면 컨텍스트 손실 없이 Qwen3.8-Max로 전환하기에서 해당 경로를 다루고 있습니다.