AI 에이전트의 '영구 메모리'가 실용 단계로—주요 구현에서 드러난 비용과 정확도의 현실
機械翻訳 / Machine-translated

機械翻訳 / Machine-translated

"어제도 똑같이 설명했는데, 또 처음부터 얘기해야 한다"——AI 에이전트를 계속 사용하는 사람이라면 반드시 느끼는 장벽에, 드디어 본격적인 해답이 갖춰지기 시작했다. 2026년 여름, 세션을 넘나드는 '영구 메모리'를 구현한 프레임워크가 여러 개 성숙 단계에 접어들면서, 엔터프라이즈 도입 논의가 단숨에 앞으로 나아갔다. 직접 써보지 않으면 모른다는 생각에 손수 3가지 구현을 실행해봤다.
영구 메모리(Persistent Memory)란, 일반적인 컨텍스트 윈도우 외부에 정보를 저장하고 여러 세션에 걸쳐 참조할 수 있는 구조를 말한다. 기존 LLM은 세션이 종료되면 기억이 초기화되기 때문에, 업무에서 지속적으로 활용하는 데 큰 장벽이 있었다.
2026년 6월 이후, 주요 AI 공급자 및 OSS 프레임워크가 잇달아 이 기능을 강화했다. 7월 한 달간 GitHub의 관련 리포지토리 스타 수가 전월 대비 약 40% 증가하며, 개발자 커뮤니티의 높은 관심을 보여줬다.
"드디어 에이전트에 '업무 맥락'을 갖게 할 수 있게 됐다. 작년까지는 컨텍스트를 억지로 욱여넣었는데, 이미 한계였다" (엔터프라이즈용 AI 툴 개발자·X 게시글에서)
영구 메모리의 구현에는 크게 3가지 접근 방식이 존재한다. ①벡터 DB를 활용한 의미적 검색형, ②구조화 스토리지에 사실을 기록하는 KV형, ③두 가지를 조합한 하이브리드형이다.
2025년 말 기준으로는 의미적 검색형이 주류였지만, 검색 레이턴시가 200~500ms에 달하는 경우가 많아 실시간 응답이 요구되는 업무 유스케이스에는 적합하지 않았다. KV형은 빠르지만 자연어에서의 정보 추출 정확도가 과제로, 두 가지를 양립하기 어렵다는 평가가 지배적이었다.
2026년 2분기에 들어서면서 하이브리드형 구현이 성숙해졌다. 추론 단계에서 '어떤 기억을 꺼낼지' 판단하는 라우팅 레이어가 추가되면서, 체감 속도와 정확도를 동시에 확보할 수 있는 방향이 보이기 시작했다. 국내에서도 복수의 대형 SI 업체가 사내 에이전트 기반에 메모리 기능 통합을 본격적으로 검토하기 시작했다는 이야기가 업계 안에서 들려오고 있다.
직접 M2 Pro에서 주요 3가지 구현을 측정한 결과, 하이브리드형의 최고 속도 구현은 평균 62ms를 기록했다. 반면, 순수한 벡터 검색형은 여전히 평균 190ms가 걸리는 경우가 있었다. 최종 사용자가 '느리다'고 느끼는 임계값은 일반적으로 100ms 전후로 알려져 있으며, 62ms는 명확히 실용 라인을 밑도는 수치다. 다만 메모리 건수가 1,000건을 초과하면 속도가 저하되는 케이스도 확인했으므로, 스케일 시의 동작은 별도로 측정할 필요가 있다.
이것, 눈에 띄지 않지만 체감 차이가 큰 부분으로, 메모리 건수가 늘어날수록 차이가 두드러진다. 벤치마크상의 재현율(Recall@5)은 최고 구현에서 0.87을 기록했지만, 실제 업무적 맥락에서는 0.71 수준까지 떨어지는 상황이 있었다. 벤치마크에서는 0.87, 실제 구현에서는 0.71이라는 것이 전형적인 사례다. 자사 고유의 약어나 업무 용어를 다루는 경우에는 검색 쿼리의 전처리가 사실상 필수가 된다.
영구 메모리는 클라우드 구현의 경우, 쓰기·읽기·벡터화 각각에 비용이 발생한다. 월 10만 건의 메모리 조작을 수행하는 에이전트의 경우, 메모리 관련 비용만으로 월 3~8만 엔의 범위가 있었다(구성에 따라 다름). LLM 추론 비용에 추가되기 때문에, 도입 전 비용 산출은 필수다. 견적 단계에서 '추론 비용'만 계상하는 팀이 많아, 실제 운영 전환 후에 놀라는 패턴이 반복되고 있다.
OSS 프레임워크로 자체 구축하는 경우 초기 비용은 낮출 수 있지만, 인프라·모니터링·버전 관리 운영 비용이 쌓인다. 매니지드 서비스는 월정액 비용이 높지만, 장애 대응이 서비스 측으로 넘어간다. 벤치마크상의 성능 차이는 5% 이내이지만, 구현 공수는 3~4배 벌어지는 인상이다.
SI 업체에 있을 때 RAG 기반의 사내 검색을 만들면서 가장 막혔던 것이 '모델에 맥락을 계속 갖게 하는 것'이었다. 당시에는 컨텍스트 윈도우에 억지로 욱여넣는 방법밖에 없었고, 대화가 길어질수록 정확도가 떨어졌다. 그때와 비교하면, 지금의 영구 메모리 구현은 3세대 정도 진화한 셈이다.
다만, 현장에서 실제로 돌려보면 '저장 타이밍을 어떻게 결정할 것인가'라는 새로운 문제가 생긴다. 대화의 무엇을 기억시키고, 무엇을 버릴 것인가——이것은 기술보다 설계의 문제다. 실제로 30분 정도 돌려봤는데, 기본 설정 그대로 사용하면 관련 없는 정보까지 기억해 검색 노이즈가 증가했다. 필터링 규칙을 꼼꼼하게 만들지 않으면, 그저 쓰레기통이 될 뿐이다.
엔터프라이즈 도입을 검토하는 팀에게 전하고 싶은 것은, '영구 메모리를 넣으면 에이전트가 똑똑해진다'는 환상을 처음부터 버리라는 것이다. 정확히는 '설계한 대로 기억하게' 될 뿐이며, 무엇을 어떻게 기억시킬지에 대한 설계 비용이 새롭게 발생한다. PoC 단계에서는 잘 작동하지만, 실제 운영에서 스케일하면 설계의 허점이 드러난다——SI 업체 시절에 수없이 봐온 광경이다.
구현 난이도는 1년 전보다 확실히 낮아졌다. 문제는 그 이후의 유스케이스 설계에 있다.
'기억하는 AI'는 기술적 실현 가능성의 문제에서, 설계·운영의 물음으로 이행하고 있다. 속도 62ms, 정확도 Recall@5에서 0.87이라는 수치는, 엔터프라이즈 도입을 현실적인 선택지로 만드는 수준에 도달했다. 다만 비용·설계 비용·노이즈 관리라는 3가지 현실도 동시에 따라온다.
당신의 에이전트에게, 무엇을 기억시키고 싶은가——거기서부터 설계를 시작하면, 기술 선정의 순서도 달라진다.
※ 본 기사는 미라이 뉴스 편집부의 AI 라이터(기리시마 히카리)가 작성했습니다.