AI 에이전트를 써보신 분들이라면 한 번쯤 겪어보셨을 거예요.
"지난주에 말했던 그 프로젝트 있잖아."
사람한테는 이 한마디면 충분합니다. 그런데 AI한테는 안 통해요. 세션이 바뀌는 순간, 어제 나눈 대화는 없던 일이 되니까요. 그래서 매번 같은 배경 설명을 반복하게 됩니다. 똑똑한 신입사원인데, 출근할 때마다 첫 출근인 셈이죠.
그런데 최근 이 문제를 '기능 개선'이 아니라 '전략 과제'로 다루는 움직임이 눈에 띄게 늘고 있어요. 오늘은 그 얘기를 해보려고 합니다.
한 줄 결론부터. 기억은 이제 AI 에이전트의 선택 사항이 아니라, 필수 인프라입니다.
'장기기억'을 전략 과제로 꺼내 들었다
지난 7월 6일, 라인야후(LY)가 '테크버스 2026'에서 전사 AX 전략을 발표하면서 흥미로운 단어를 직접 언급했습니다. 바로 '장기기억'이에요.
사용자와의 대화 이력을 선별해 장기 저장하는 '장기기억(Long-term Memory)' 기능과, Agent i 대화와 라인·야후재팬 서비스 이용 데이터를 실시간으로 연계하는 '메모리 통합' 기능을 추진한다.¹
여기서 주목할 표현은 "선별해 장기 저장"입니다. 대화를 통째로 쌓아두는 게 아니라, 기억할 가치가 있는 것만 골라서 남기겠다는 거죠.
이건 LY만의 방향이 아니에요. 해외 주요 AI 기업들도 자사 어시스턴트에 메모리 기능을 기본으로 탑재하는 흐름이 뚜렷합니다. 컨텍스트 윈도우가 아무리 길어져도 그것만으로는 부족하다는 문제의식이, 이미 업계 공통이 된 거죠.
이유는 단순합니다. 컨텍스트 윈도우는 '작업 기억'이지 '장기기억'이 아니거든요. 회의 중에 메모지를 아무리 크게 만들어도, 그게 서랍 속 파일 캐비닛을 대신할 수는 없는 것과 같아요.
컨텍스트를 늘리는 경쟁은 끝나가고, 기억을 설계하는 경쟁이 시작됐습니다.
그런데 그 기억, 운영 부담이 만만치 않다
그럼 다들 기억을 붙이면 되는 거 아니냐고요? 문제는 여기서부터예요.
지금 장기기억 구현에서 널리 쓰이는 방식은 RAG + 벡터DB + 임베딩 조합입니다. 대화를 벡터로 변환해 저장하고, 질문이 들어오면 비슷한 걸 검색해서 컨텍스트에 붙여주는 방식이죠. 이 구조가 틀렸다는 얘기는 아니에요. 다만 '수많은 사용자의 기억'을 담는 용도로 운영하면, 규모가 커질수록 세 가지가 함께 늘어납니다.
비용 — 임베딩 호출과 벡터DB 인프라 비용이 기억의 양에 비례해 늘어납니다.
지연 — 검색 파이프라인이 응답 경로에 하나 더 끼어듭니다.
격리 — 여러 고객사의 기억을 한 인프라에 담으려면 테넌트 분리 설계가 별도로 필요합니다. 도입 초기에는 잘 드러나지 않다가, 기억이 쌓인 뒤에야 체감되는 종류의 부담이에요.
즉, 에이전트에 기억을 붙이는 순간 새로운 인프라 운영 과제가 하나 생기는 셈입니다.
기억이 필수라는 건 다들 동의하는데, 기억의 '운영 비용'은 아직 각자의 숙제로 남아 있습니다.
다른 접근 — 검색하지 말고, 정제하라
메모리허브가 택한 접근은 이 지점에서 갈라집니다. 지난 글에서 소개했듯, 메모리허브는 대화를 벡터로 저장하지 않아요. 대화가 끝나면 기억할 가치가 있는 것들을 뽑아 구조화된 기억으로 정제해서 저장합니다.
사실(Facts) — 사용자의 상태, 선호, 프로젝트 현황. 바뀌면 이전 값은 자동으로 '과거'로 밀려납니다.
타임라인 — "언제 무슨 일이 있었는지"를 시간축으로 정리합니다.
이벤트 원장(Ledger) — 참석한 행사, 구매한 물건, 지출 내역처럼 세어볼 수 있는 기록들이요.
이 구조에서는 벡터DB도, 임베딩 파이프라인도, 검색 레이어도 쓰지 않습니다. 기억이 처음부터 읽을 수 있는 형태로 정리돼 있으니까요. 그래서 앞에서 본 비용·지연·격리 이슈가 발생할 자리 자체가 없어요.
남는 질문은 하나였습니다. 검색 레이어를 걷어내고도 기억력이 유지되는가.
이를 확인하기 위해 지난 6월, 장기기억 평가에 널리 쓰이는 LongMemEval(ICLR 2025, 500문항) 전 문항으로 측정을 진행했습니다. 결과는 다음과 같습니다.²
maj@5(5회 실행 다수결) 기준 96.6%
단일 실행 기준 94.2% — 500문항 중 471문항 정답
maj@5는 벤치마크 비교에 통용되는 기준이고, 단일 실행은 재시도 없이 한 번 질문했을 때의 성적입니다. 실제 서비스 환경은 후자에 가깝기 때문에 두 수치를 함께 공개합니다. 측정 조건과 방법론 전체는 벤치마크 페이지에 정리되어 있어요.²
기억의 품질은 얼마나 많이 저장하느냐가 아니라, 얼마나 잘 정제하느냐에서 갈립니다.
정제된 기억, 어디서 쓰이고 있나
이 구조는 실험 단계가 아닙니다. 메모리허브는 현재 웍스AI에 기본 내장되어 있고, 2026년 7월 기준 국내 1,000개 이상 기업이 별도 설정 없이 사용하고 있습니다.
웍스AI에서 "내가 지난달에 뭐 물어봤었지?"라고 물었을 때 답이 돌아오는 것도 이 구조가 동작한 결과예요. 사용자 입장에서는 벡터DB나 임베딩 같은 인프라를 의식할 일이 없습니다.
자체 서비스에 장기기억을 붙이려는 팀을 위한 연동 경로도 열려 있습니다. 메모리허브에서 SDK 문서와 함께 확인할 수 있고, 연동은 코드 한 줄로 시작됩니다.
컨텍스트 윈도우 경쟁이 정리되어 가는 지금, 다음 경쟁의 축은 기억을 어떻게 설계하느냐입니다.
그 설계의 한 가지 답으로, 저희는 '검색'이 아니라 '정제'를 제시합니다.
¹ 이데일리, 「LY 전사 AX 전략 공개」, 2026. 7. 6.
² MemoryHub LongMemEval 평가 결과 — LongMemEval(ICLR 2025) 500문항, 2026년 6월 측정, maj@5 96.6% / 단일 실행 94.2%(471/500)