현재 메모리 패러다임의 취약점

다들 한 번쯤 겪어보셨을 겁니다. 분명히 프롬프트에 소스 텍스트를 넣어줬는데, AI가 문서 앞부분을 까먹거나 갑자기 엉뚱한 소리를 하는 순간 말이죠. 이른바 '컨텍스트 천장'에 부딪힌 상황입니다. 그동안 업계는 이 문제를 해결하려고 컨텍스트 윈도우(모델이 한 번에 처리할 수 있는 텍스트 양)를 키우는 데 집중해 왔습니다. 데이터를 더 많이 담을 수 있게 그릇 자체를 키운 셈이죠.

하지만 이런 무식한 방식은 증상만 완화할 뿐, 구조적인 해결책이 되지 못합니다. 그릇이 커졌다고 해서 그 안에 담긴 방대한 데이터를 논리적으로 연결해 추론하는 능력이 자동으로 좋아지는 건 아니거든요. 그래서 많은 개발자가 RAG(검색 증강 생성)를 대안으로 선택합니다. 답변하기 전에 데이터베이스에서 관련 조각을 먼저 찾아오는 방식이죠.

문제는 RAG나 확장된 윈도우 모두 '깊은 추론' 앞에서는 무력하다는 점입니다. 새로운 지식을 넣기 위해 모델 전체를 다시 학습시키는 비용은 너무 비싸고, 정적인 학습 데이터와 동적인 대규모 메모리 사이에는 여전히 간극이 큽니다.

벡터 검색의 의미론적 한계

RAG의 가장 큰 약점은 정보를 저장하는 방식에 있습니다. 대부분의 시스템은 텍스트 뭉치를 숫자로 변환해 유사도를 찾는 벡터 데이터베이스를 사용하는데요. 이 과정에서 문서의 서로 다른 부분 사이에 존재하는 미묘한 연결 고리들이 사라지곤 합니다.

MIT의 아르만도 솔라-레자마(Armando Solar-Lezama) 교수는 벡터 데이터베이스가 텍스트 조각의 전체 의미를 단 하나의 벡터에 담아내기 어렵다는 점을 지적합니다. 특정 조각의 중요성이 다른 조각들과의 관계 속에서만 드러나는 경우, 단순한 벡터 매칭으로는 이를 잡아낼 수 없다는 거죠.

결국 '노이즈' 문제가 발생합니다. 키워드상으로는 관련 있어 보여서 가져왔는데, 정작 답변에 필요한 맥락은 빠져 있는 식입니다. 단순한 사실 하나를 찾는 것과, 흩어져 있는 여러 사실을 엮어 결론을 내는 추론 사이에는 근본적인 차이가 있습니다.

MeMo: 엔진과 도서관의 분리

이 문제를 풀기 위해 MIT 연구진은 추론 엔진과 지식 저장소를 완전히 분리한 모듈형 프레임워크, MeMo(메모)를 제안했습니다. 하나의 거대한 모델이 모든 걸 다 하게 만드는 대신, '집행 모델(Executive model)'과 '메모리 모델(Memory model)'로 역할을 나눈 겁니다.

작동 방식은 이렇습니다. 먼저 생성 모델이 원문 텍스트를 정제해 '리플렉션(Reflections)'이라 불리는 질의응답(QA) 쌍으로 만듭니다. 이 리플렉션들을 사용해 작고 전문적인 메모리 모델을 미세 조정(Fine-tuning)하죠. 실제 구성에서는 Qwen2.5(큐웬 2.5)가 생성 및 메모리 모델 역할을 하고, Gemini 3 Flash(제미나이 3 플래시)가 집행 모델 역할을 수행합니다.

사용자가 질문을 던지면 집행 모델은 데이터베이스를 검색하는 대신, 질문을 아주 작은 단위의 원자적 질문들로 쪼갭니다. 그러면 메모리 모델이 각 질문에 개별적으로 답하고, 마지막에 집행 모델이 이 답변들을 종합해 최종 응답을 내놓는 구조입니다.

재학습 없는 지식 업데이트

AI 도입의 가장 큰 걸림돌 중 하나는 지식을 업데이트하는 비용입니다. 보통 새로운 데이터를 넣으려면 전체 파라미터를 미세 조정해야 하는데, 비용이 엄청날 뿐 아니라 기존에 배웠던 능력을 잃어버리는 '치명적 망각' 현상이 일어날 위험이 큽니다.

MeMo는 이를 '태스크 벡터(Task Vectors)'로 해결했습니다. 새로운 데이터를 학습할 때 발생하는 변화량을 벡터 형태로 캡처해 기존 모델에 병합하는 방식입니다. 덕분에 추론 엔진 전체를 다시 학습시키지 않고도 지식 베이스만 빠르게 업데이트할 수 있습니다.

물론 트레이드오프는 있습니다. 전체 재학습과 비교하면 정확도가 약 11~19% 정도 떨어지는 것으로 나타났거든요. 하지만 매일 쏟아지는 데이터를 천문학적인 비용 없이 업데이트할 수 있다는 점에서, 대부분의 기업에는 충분히 납득 가능한 수준의 교환 조건일 겁니다.

RLM: 컨텍스트를 외부 환경으로 취급하기

MeMo가 저장 방식에 집중했다면, RLM(Recursive Language Model, 재귀적 언어 모델)은 긴 컨텍스트를 처리하는 관점 자체를 바꿨습니다. 핵심 철학은 간단합니다. "긴 프롬프트를 신경망에 직접 밀어 넣지 말고, 모델이 상호작용할 수 있는 외부 환경으로 취급하자"는 것이죠.

RLM은 REPL(Read-Eval-Print Loop) 환경에서 작동하며 데이터와 재귀적으로 상호작용합니다. 1,000만 토큰을 한 번에 활성 메모리에 올리려 애쓰는 대신, 컨텍스트를 관리 가능한 크기로 쪼개어 층별로 처리합니다.

이제 문제는 '용량'이 아니라 '상호작용'의 영역으로 넘어갑니다. 문서를 읽어야 할 프롬프트가 아니라 탐색해야 할 지도로 취급함으로써, RLM은 1,000만 토큰이 넘는 입력값도 거뜬히 처리합니다. GPT-5-mini(가칭)를 이용한 테스트 결과, 이 재귀적 전략은 기본 모델 대비 성능이 114%나 향상되었습니다.

도입 가이드: 우리 서비스엔 어떤 프레임워크가 맞을까?

두 아키텍처 중 무엇을 선택할지는 다루는 데이터의 성격과 원하는 결과물에 따라 다릅니다. 상황별로 가이드를 잡아봤습니다.

먼저 수백 페이지의 규제 문서나 거대한 코드베이스처럼, 멀리 떨어진 섹션 간의 복잡한 연결 고리를 찾아내야 한다면 MeMo 프레임워크가 정답입니다. 질문을 쪼개고 종합하는 능력이 탁월해, 긴 프롬프트에서 흔히 발생하는 디테일 손실을 막아주거든요.

반면 1,000만 토큰을 초과하는 초거대 문서 집합에서 특정 세부 정보를 정확히 추출해야 한다면 RLM 전략이 훨씬 유리합니다. 데이터를 외부 지도로 인식해 재귀적으로 탐색하며 정밀한 정보를 찾아내기 때문입니다.

만약 사내 정책이 매일 바뀌어 저비용으로 AI를 최신 상태로 유지해야 하는 환경이라면, MeMo의 모델 병합(Model Merging) 방식이 최적의 경로가 될 겁니다.

AI 지능의 새로운 설계도

이런 모듈형 전환의 효과는 벤치마크 수치로 명확히 드러납니다. NarrativeQA 데이터셋에서 MeMo(제미나이 3 플래시 조합)는 53.58%의 정확도를 기록했는데, 이는 HippoRAG2의 23.21%를 압도하는 수치입니다.

다양한 작업 전반에서 MeMo 도입 후 전체 성능이 26% 향상되었습니다. 결국 무한한 컨텍스트로 가는 길은 윈도우 크기를 무작정 키우는 것이 아니라, 더 정교한 아키텍처를 설계하는 데 있다는 뜻이죠.

방향은 명확합니다. AI 스케일링의 미래는 단순히 파라미터를 늘리는 무식한 방법에서 벗어나, 추론의 논리와 지식의 저장소를 분리하고 메모리를 모듈형 인터랙티브 컴포넌트로 다루는 방향으로 흐르고 있습니다.