memU는 LLM 기억 비용을 90% 줄일까: Locomo 92%와 거짓 기억 점검

memU는 매번 전체 대화를 다시 보내는 비용을 줄일 수 있지만, “최대 90% 절감”과 “Locomo 92%”가 모든 에이전트에서 그대로 재현된다는 뜻은 아닙니다.

장기 기억의 핵심은 저장량보다 무엇을 사실로 남기고 언제 다시 꺼내느냐입니다. memU는 원본과 추출 기억, 주제 분류를 나누고 사람이 읽을 수 있는 형태로 관리합니다. 이 구조는 디버깅에 도움이 되지만, 추출을 맡은 모델이 틀리면 잘못된 기억도 오래 살아남을 수 있습니다.

세 층은 무엇을 분리하는가

memU의 구조는 Resource → Memory Item → Category 순서로 이해하면 쉽습니다.

계층	담는 것	확인할 문제
Resource	대화, 로그, 이미지 같은 원본	보존 기간과 접근 권한
Memory Item	원본에서 추출한 사실, 선호, 경험	출처와 신뢰도
Category	관련 기억을 묶은 주제	중복과 잘못된 분류

기억 사이의 교차 참조는 한 사실이 여러 주제와 연결될 때 유용합니다. 백그라운드 메모리 에이전트가 비동기로 정리하고, 덜 중요한 정보를 뒤로 미루는 우아한 망각도 지향합니다. 다만 비동기라는 말은 최신 대화가 즉시 검색된다는 보장이 아닙니다. 기록 완료 시점과 읽기 시점의 일관성을 별도로 시험해야 합니다.

벤치마크 숫자는 사용 조건과 함께 읽어야 한다

프로젝트는 기억 집약적 추론 벤치마크 Locomo에서 92% 정확도, 기존 클라우드 메모리 체인 대비 토큰 비용 최대 90% 절감을 제시합니다. 두 숫자는 가능성을 보여 주지만 서로 다른 질문에 답합니다.

• 92%는 특정 벤치마크와 평가 방식의 결과입니다.
• 최대 90%는 전체 이력을 보내는 비교 조건, 추출, 검색 호출 비용에 따라 달라집니다.
• 실제 비용에는 메모리 생성, 임베딩, 재정리, 저장소와 워커 운영도 포함됩니다.
• 업무 데이터에서는 질문 유형별 정확도와 누락률을 다시 측정해야 합니다.

대화 턴이 늘면 전체 이력의 크기는 대체로 함께 늘어납니다. 이를 매번 보내는 낭비는 분명하지만, 단순히 이력 자체가 “기하급수적으로 증가한다”고 볼 필요는 없습니다. 비교는 동일한 모델, 질문, 정답 세트에서 입력 토큰과 전체 호출 비용을 함께 재는 것이 맞습니다.

예시 코드는 개념 비교일 뿐이다

원문에 제시된 코드는 전체 이력 주입과 선택적 기억 검색의 차이를 보여 주는 의사 코드입니다.

# 전체 과거 대화를 매번 넣는 방식
past_history = db.get_all_past_conversations(user_id)
response = llm.chat(
    history=past_history,
    prompt="오늘 서버 배포할 건데, 저번에 실수했던 게 뭐였지?"
)

# 필요한 기억만 검색하는 방식
memory_context = memu.retrieve(user_id, intent="deployment_safety")
response = llm.chat(
    context=memory_context,
    prompt="오늘 서버 배포할 건데, 저번에 실수했던 게 뭐였지?"
)

이 조각은 실제 memU API 사용법을 완성한 실행 예제가 아닙니다. import, 클라이언트 초기화, 사용자 인증, 메모리 적재, 비동기 완료 확인, 오류 처리가 모두 빠져 있습니다. 또한 검색된 기억이 현재 질문의 근거가 되는지 검증하는 단계도 필요합니다. 설치나 연동은 프로젝트 페이지의 현재 설명과 저장소 버전을 기준으로 확인해야 합니다.

사람이 읽을 수 있어도 거짓 기억은 남는다

메모리를 마크다운으로 열람하고 memU-ui에서 수정할 수 있다는 점은 벡터만 저장하는 시스템보다 원인을 추적하기 쉽다는 장점이 있습니다. 하지만 사람이 읽을 수 있다는 사실만으로 기억이 사실이 되지는 않습니다.

운영 전에는 각 Memory Item에 원본 Resource, 생성 시각, 추출 모델, 신뢰 상태를 연결할 수 있는지 확인해야 합니다. 중요한 선호나 안전 규칙은 자동 확정하지 말고 승인 대기 상태로 두는 방식도 필요합니다. 기억 수정과 삭제가 검색 인덱스에 언제 반영되는지, 동시에 여러 워커가 같은 사용자의 기억을 갱신할 때 충돌하지 않는지도 시험해야 합니다.

Apache 2.0 기반 셀프호스팅과 1.0.0 이후의 사용자, 모델 간 격리 주장은 데이터 주권에 유리한 출발점입니다. 그러나 로컬 파일을 클라우드 LLM이 읽으면 내용은 외부로 전송될 수 있습니다. 저장 위치와 추론 경로를 함께 살펴야 “로컬”의 범위를 정확히 판단할 수 있습니다.

도입 여부는 기억 오류의 비용으로 결정한다

memU는 대화가 길고 반복되는 개인화 에이전트, 사람이 기억을 감사해야 하는 시스템에 잘 맞을 수 있습니다. 짧은 세션이나 소규모 서비스라면 서버, 워커, UI를 운영하는 부담이 절감 토큰보다 클 수 있습니다.

작게 시작하려면 대표 질문을 시간 간격을 두고 반복하고, 전체 이력 방식과 memU 방식의 정답률, 누락, 잘못된 기억, 총토큰을 비교합니다. 그다음 사용자 삭제 요청, 동시 쓰기, 모델 교체, 추출 실패를 시험합니다. 이 과정을 통과해야 memU가 “24시간 능동형 기억”이라는 인상보다 실제 시스템 요구에 맞는 선택인지 알 수 있습니다.

기억의 생명주기는 어떻게 설계할까

기억은 생성, 검색, 수정, 만료, 삭제의 다섯 단계를 가집니다. 대화가 들어왔다고 모든 문장을 Memory Item으로 만들면 중복과 민감 정보가 빠르게 쌓입니다. 장기적으로 유용한 선호와 일회성 요청을 구분하고, 자동 추출하지 않을 정보와 보관 기간을 먼저 정해야 합니다.

검색될 때는 어떤 Memory Item이 어느 Resource에서 왔는지 함께 반환하는 편이 좋습니다. 답변이 틀렸을 때 retrieval이 관련 없는 기억을 골랐는지, 기억 추출이 처음부터 틀렸는지, 생성 모델이 근거를 무시했는지를 구분할 수 있기 때문입니다. 기억을 수정하면 이전 embedding과 cache가 언제 무효화되는지도 확인해야 합니다.

삭제는 UI에서 항목 하나가 사라지는 것으로 끝나지 않습니다. 원본 Resource, 파생 Memory Item, Category 연결, vector index, backup과 observability log의 관계를 문서화해야 합니다. 사용자의 계정 삭제 요청을 test data로 실행해 검색 결과와 background worker에서 다시 나타나지 않는지 일정 시간 뒤 확인합니다.

동시성과 모델 변경에서 무엇이 깨질까

한 사용자가 여러 device에서 동시에 대화하면 background memory agent가 같은 Resource를 중복 처리할 수 있습니다. 두 worker가 서로 다른 Category로 분류하거나 오래된 항목으로 새 값을 덮어쓸 수도 있습니다. Event ID와 version을 두고 중복 write, 순서가 뒤바뀐 write, 부분 실패를 재현해야 합니다.

추출 모델을 바꾸면 같은 대화에서 다른 Memory Item이 나올 수 있습니다. 모든 과거 자료를 즉시 다시 처리하면 비용이 크고 사용자 선호가 갑자기 바뀔 수 있으므로, model version을 기록하고 일부 사용자, 일부 Category에서 비교하는 migration이 필요합니다. 새 추출과 기존 기억이 충돌할 때 어느 값을 우선할지도 정해야 합니다.

읽기 일관성도 업무마다 다릅니다. 방금 말한 주소를 바로 다시 묻는 assistant는 수 초 안에 반영돼야 하지만, 주간 요약 memory는 지연돼도 괜찮을 수 있습니다. 비동기 처리의 목표 시간을 Category별로 정하고 지연 중임을 application이 알 수 있어야 합니다.

전체 이력 방식과 어떻게 공정하게 비교할까

같은 model, 같은 질문, 같은 평가 시점으로 맞추고 입력 구성만 바꿉니다. 전체 이력, 최근 N개 대화, memU 검색의 세 기준을 두면 복잡한 기억 시스템이 단순한 최근 window보다 실제로 나은지 알 수 있습니다. 질문은 최근 사실, 오래된 선호, 수정된 정보, 서로 충돌하는 기억을 포함해야 합니다.

비용에는 최종 답변의 input token뿐 아니라 memory 추출, embedding, background 정리, 저장소와 재시도 호출을 포함합니다. 정답률도 평균만 보지 말고 “모른다”고 해야 하는 질문에서 잘못된 기억을 자신 있게 말하는 비율을 기록합니다. 기억 시스템에서는 누락과 함께 잘못된 회상이 중요한 실패입니다.

운영 지표는 사용자별 memory 수, 검색되지 않은 오래된 항목, 중복률, 수정, 삭제 반영 시간입니다. 이 값이 계속 늘면 우아한 망각이 실제로 작동하는지 점검해야 합니다. 비용 절감이 기억 품질 저하와 맞바뀌지 않는 범위에서만 검색 개수와 요약 강도를 조정합니다.

원문과 버전 확인

• 공식 GitHub 저장소

함께 읽으면 이해가 이어지는 글

• LingBot-World의 16 FPS는 실시간 월드 모델을 뜻할까: 1초 지연과 장기 기억 점검 — 16 FPS, 1초 미만 지연, 분 단위 기억 주장을 처리량, 입력 반응성, 물리 정확도로 나눠 검토합니다.
• MiroFish의 에이전트 사회는 예측 엔진일까: GraphRAG, OASIS와 비용 폭발 — GraphRAG 기억과 OASIS 환경에서 에이전트 사회를 돌리는 MiroFish의 구조를 살펴보고, 확률 보정, 상관된 환각, Context, JSON, 운영 비용 한계를 정리합니다.
• AIRI를 브라우저 AI 컴패니언으로 쓸까: WebGPU, WASM, 기억의 경계 — AIRI가 WebGPU, WASM, Live2D/VRM과 모듈식 음성, 기억 계층을 조합하는 방식, 브라우저 호환성, 자원, 개인정보, 업데이트 한계를 정리합니다.

자주 묻는 질문

memU를 쓰면 전체 대화를 보낼 필요가 없어지나요?

관련 기억만 검색해 입력을 줄일 수 있지만 현재 질문에 필요한 정보가 빠질 수 있습니다. 전체 이력 기준선과 같은 질문을 비교해 정답률, 누락, 전체 호출 비용을 함께 측정해야 합니다.

사용자가 대화를 삭제하면 추출된 기억도 자동으로 사라지나요?

Resource와 Memory Item, 검색 인덱스가 별도라면 삭제 전파 시점을 확인해야 합니다. 원본 삭제가 파생 기억과 backup까지 반영되는 절차를 실제 사용자 단위로 시험해야 합니다.

사람이 읽을 수 있는 기억이면 환각을 쉽게 막을 수 있나요?

검토와 수정은 쉬워지지만 잘못 추출된 기억을 자동으로 사실로 만들지는 않습니다. 중요한 항목은 원본 근거, 생성 시각, 신뢰 상태를 표시하고 확정 전에 승인하는 편이 안전합니다.