사용자의 수백 건 대화 기록, 계속 쌓이는 업무 문서, 에이전트의 이전 행동을 다음 질문에 반영해야 할 때 팀은 보통 세 가지 중 하나를 고른다. 필요한 문서를 찾아 넣는 RAG, 이전 내용을 짧은 문장으로 정리하는 대화 요약, 또는 가능한 많은 원문을 모델의 긴 컨텍스트에 넣는 방식이다.
여기에 Memorilla는 다른 선택지를 제안한다. 문서 원문이나 요약문을 LLM에 전달하는 대신, 전체 문서 집합에서 질문에 필요한 정보를 고정된 수의 메모리 토큰으로 압축해 모델 입력에 넣는다. 핵심 가치는 RAG를 전면 교체하는 데 있지 않다. 반복적으로 참조하는 큰 정보 집합을 매 요청마다 짧은 학습 입력으로 바꾸고 싶을 때 쓸 수 있는 별도 메모리 계층이라는 점에 있다.
CTO와 개발 리드는 “무엇이 더 최신인가”보다 “우리 질문은 어떤 종류의 기억을 요구하는가”부터 정해야 한다.
네 방식은 무엇을 모델에 전달하는가
| 방식 | 모델에 들어가는 정보 | 강한 상황 | 먼저 확인할 한계 |
|---|---|---|---|
| 긴 컨텍스트 | 원문 전체 또는 큰 범위의 원문 | 원문 전체를 읽어야 하고, 누락 없이 문맥을 대조해야 하는 질문 | 입력 길이, 응답 지연, 긴 입력 중간 정보 활용의 안정성 |
| RAG | 검색된 원문 청크 | 답변 근거를 원문 문장으로 제시해야 하는 질의, 정확한 문구 확인 | 검색 단계가 필요한 정보를 놓칠 가능성 |
| 대화 요약 메모리 | 이전 대화를 문장으로 정리한 요약 | 사용자의 안정적인 선호, 현재 상태, 직전 작업 맥락 | 초기 요약에서 빠진 사실을 나중에 되살리기 어려움 |
| 잠재 의미 메모리 | 질의에 따라 생성되는 고정 길이 메모리 토큰 | 여러 문서 조각을 함께 연결해야 하고, 입력 예산을 일정하게 유지해야 하는 질의 | 원문 근거 제시, 학습 범위, 자체 데이터에서의 재현성 |
긴 컨텍스트는 설계가 가장 직관적이다. 문서를 덜 가공하고 많이 넣으면 되기 때문이다. 그러나 긴 입력이 있다고 해서 모델이 그 안의 모든 정보를 같은 수준으로 활용하는 것은 아니다. 긴 컨텍스트 모델에서도 관련 정보가 입력 중간에 있을 때 성능이 떨어질 수 있다는 연구 결과가 있다. 따라서 “컨텍스트 창이 충분히 크다”는 사실만으로 긴 문서 질의를 통과시키면 안 된다. 관련 정보의 위치를 바꿔도 답이 유지되는지 테스트해야 한다.
RAG는 원문을 유지한다는 장점이 분명하다. 계약 조항, 기술 규격, 정책 문구처럼 답변 뒤에 해당 문장을 다시 보여줘야 하는 서비스에는 특히 유리하다. 다만 질문과 표현이 닮지 않은 정보를 검색 단계가 놓치면, 생성 모델은 애초에 그 사실을 볼 수 없다. 사용자가 몇 달 전 언급한 건강 상태와 최근의 운동 계획처럼, 서로 떨어진 정보 둘을 결합해야 하는 개인화 질문이 여기에 해당할 수 있다.
대화 요약은 가장 운영하기 쉬운 출발점이다. 다만 요약은 과거를 한 번 해석해 문장으로 굳힌다. 당시 중요하지 않아 보였던 정보가 이후 질문에서 핵심이 되면, 짧은 요약만으로는 회복하기 어렵다. 요약을 계속 덧붙이는 방식은 오래된 사실이 희미해지거나 서로 충돌하는 상태를 만들 가능성도 검토해야 한다.
Memorilla형 메모리는 검색 결과가 아니라 학습된 입력이다
Memorilla는 문서나 대화를 한 번씩 임베딩으로 저장하고, 질문마다 학습된 메모리 모듈이 전체 저장소를 읽어 고정 개수의 메모리 토큰을 만든다. 공개된 실험에서는 동결된 LLM에 16개 메모리 토큰을 공급하는 구성을 사용했다. 문서 수가 늘어도 LLM이 받는 메모리 토큰 수는 유지하며, 새 문서를 추가할 때는 해당 문서를 인코더로 처리해 저장소에 넣는 방식이다.
이 구조는 다음 요구가 동시에 있을 때 검토할 만하다.
- 사용자별 과거 대화나 문서가 계속 늘어나지만, 매 요청의 입력 길이는 예측 가능하게 유지해야 한다.
- 답이 한 개의 문서 청크가 아니라 여러 시점의 정보를 연결해야 한다.
- 기반 LLM을 다시 학습시키지 않고도 축적된 정보를 활용하려 한다.
- 문서 집합은 자주 커지지만, 과거 문서 전체를 매번 다시 처리하는 방식은 피하고 싶다.
- 최종 답변에서 원문 인용보다 질의에 맞는 정보 결합과 짧은 입력이 더 중요한 업무다.
연구진은 개인화, 긴 문서, 지식 집약형 질의 등 8개 벤치마크 중 5개에서 비교 대상보다 높은 성능을 보고했다. FactKG에서는 전체 문맥을 넣은 방식보다 높은 정확도를 제시했고, 문서 표현에 쓰는 토큰은 훨씬 적었다. 다만 이 수치는 특정 실험 조건, 동결된 Qwen3-8B 계열 모델, 해당 벤치마크와 학습 절차에서 나온 결과다. 자체 문서 구조, 언어, 모델, 질의 유형에서도 같은 결과가 난다고 볼 수는 없다.
원문 증거가 필요한 업무에는 단독 도입이 맞지 않을 수 있다
잠재 의미 메모리는 LLM이 읽을 짧은 벡터 형태의 입력을 만든다. RAG처럼 선택된 원문 청크를 그대로 보여주는 구조와는 다르다. 그래서 사용자가 “이 답은 어느 문서의 어느 문장에 근거했는가”를 확인해야 하는 서비스라면, 잠재 의미 메모리만으로 답변 경로를 구성하기 어렵다.
예를 들어 법무 검토, 규제 문서 질의, 사내 정책 안내, 기술 매뉴얼 지원에서는 답변 정확도와 함께 근거 문장을 제시하는 일이 중요할 수 있다. 이 경우 RAG를 기본 경로로 두고, 잠재 의미 메모리는 후보 정보 결합이나 개인화 맥락 보강에 쓰는 하이브리드 설계가 더 적합할 수 있다.
반대로 에이전트가 이전 시도와 실패를 기억하면서 다음 행동을 정해야 하거나, 사용자 장기 이력을 바탕으로 매번 다른 조합의 추천을 만들어야 한다면 고정 길이 메모리의 장점이 커질 수 있다. Memorilla 연구는 TextWorld 환경에서 전체 행동 이력을 입력하는 방식보다 더 높은 평균 성공률을 보고했다. 그러나 게임 환경의 개선을 업무 에이전트의 신뢰성 향상으로 바로 옮겨 해석해서는 안 된다.
요구사항 단계에서 먼저 물어볼 질문
잠재 의미 메모리를 PoC 후보에 넣기 전에 제품, 데이터, 모델 담당자가 같은 질문에 답해보는 편이 좋다.
-
답변에는 원문 근거가 필수인가
근거 문장, 문서 링크, 조항 위치를 사용자에게 제공해야 한다면 RAG 또는 긴 컨텍스트 비교군을 남겨야 한다. 메모리 토큰만으로 답을 만들지 여부를 먼저 정한다. -
질문은 단일 문서 찾기인가, 분산된 사실 결합인가
“이 계약의 해지 조항은 무엇인가”는 검색된 원문이 적합할 수 있다. “이 사용자의 과거 제약, 최근 요청, 이전 실패를 함께 고려해 다음 조치를 정하라”는 잠재 의미 메모리를 시험할 이유가 생긴다. -
어떤 정보가 오래 남아야 하는가
대화 요약에 넣을 안정적 사용자 선호와, 문서 저장소에서 매번 다시 읽어야 할 세부 사실을 구분한다. 이 구분 없이 요약과 메모리 모듈을 함께 도입하면 무엇이 틀렸는지 추적하기 어려워진다. -
학습 모듈을 운영할 준비가 되었는가
Memorilla는 저장된 임베딩만 쓰는 검색 설정이 아니라 메모리 모듈을 학습하는 접근이다. 따라서 데이터 분리, 평가 질의, 모델 교체 시 재검증 범위를 요구사항에 포함해야 한다. “벡터 DB가 있으니 바로 붙일 수 있다”는 판단은 충분하지 않다. -
평가에서 무엇을 실패로 볼 것인가
정답률만 보지 말고, 오래된 정보 회상, 여러 문서의 결합, 최신 정보와 과거 정보의 충돌, 관련 정보가 문서 중간에 있는 경우를 별도로 시험한다. 원문 근거가 필요한 서비스라면 근거 제시의 적절성도 독립 항목으로 본다.
도입 판단은 네 방식의 대결이 아니라 경로 분리에서 시작한다
처음부터 모든 질의를 하나의 메모리 방식으로 처리할 필요는 없다. 요구사항 단계에서는 질의를 두 갈래로 나누는 편이 판단이 빠르다. 원문 확인과 근거 제시가 필요한 질의는 RAG 또는 긴 컨텍스트 경로에 남긴다. 반면 반복되는 대화, 누적된 작업 이력, 여러 문서에 흩어진 개인화 정보처럼 짧은 입력 안에서 재조합해야 하는 질의만 잠재 의미 메모리 후보로 잡는다.
그다음 동일한 평가 세트에 긴 컨텍스트, RAG, 요약 메모리, 잠재 의미 메모리를 나란히 적용해 본다. 비교 대상은 토큰 수나 지연 시간만이 아니다. 어떤 방식이 필요한 과거 사실을 놓치는지, 어떤 방식이 원문 근거를 제공하지 못하는지, 어떤 방식이 문서가 늘어난 뒤에도 같은 품질을 유지하는지를 함께 확인해야 한다.
Memorilla 같은 접근은 RAG의 실패를 자동으로 해결하는 만능 메모리가 아니다. 그러나 “찾아온 몇 개 문서”와 “길어진 전체 이력” 사이에서 계속 흔들리는 서비스라면, 학습된 고정 길이 메모리를 별도 계층으로 시험할 명확한 이유가 있다.
