여러분의 회사가 실행하는 모든 AI 에이전트는 아무것도 모르는 상태로 깨어납니다.

에이전트는 지난 화요일 누군가가 디버깅했던 결제 관련 특이 사항을 기억하지 못합니다. 2주 전에 다른 에이전트가 알아낸 배포 레시피(deploy recipe)도 알지 못합니다. 에이전트는 매 세션마다, 영원히, 똑같은 사실을 다시 도출하고, 똑같은 실수를 저지르며, 똑같은 질문을 던집니다. 우리 모두는 이것이 정상이라고 생각하기로 했습니다.

하지만 이것은 정상이 아닙니다. 이것은 설계상의 선택이며, 저는 그것이 잘못된 선택이라고 생각합니다.

아무도 의문을 제기하지 않는 기본값

인기 있는 메모리 시스템들이 어떻게 구축되었는지 살펴보십시오. Mem0, Zep, Letta, Supermemory가 있습니다. 이들은 훌륭한 엔지니어링 결과물이며, 대부분 한 가지 사항에 동의합니다. 바로 메모리는 사용자(user), 세션(session), 또는 에이전트(agent)에 속한다는 것입니다. 여러분은 네임스페이스(namespace)를 할당받습니다. 그 안에 기록하고, 거기서 읽어옵니다. 메모리의 경계는 하나의 정체성(identity)의 경계입니다. Glen이 강력한 이유는 다른 방식으로 작동하기 때문이며, 이에 대해서는 나중에 다루겠습니다.

이러한 방식은 이 도구들이 원래 구축되었던 목적, 즉 소비자용 챗봇(consumer chatbot)에는 완전히 타당했습니다. 제가 제 어시스턴트와 대화할 때, 어시스턴트는 제가 채식주의자라는 사실과 제가 전화 통화를 싫어한다는 사실을 기억해야 합니다. 나의 메모리는 나의 것이고, 당신의 메모리는 당신의 것입니다. 사용자가 중요한 단위일 때는 사용자별 격리(Per-user isolation)가 정확히 맞습니다.

하지만 기업 내부에서는 그런 일이 일어나지 않습니다. 기업 내부에는 단 하나의 에이전트가 있는 것이 아닙니다. 당신은 하나의 함대(Fleet)를 보유하고 있습니다. 지원(Support) 에이전트, 영업(Sales) 에이전트, 운영(Ops) 에이전트, 누군가 지난달에 바이브 코딩(vibe-coded)한 세 가지의 서로 다른 내부 도구, 그리고 엔지니어링 팀에서 Cursor와 Claude Code가 수행하고 있는 모든 것들이 있습니다. 그리고 이들은 모두 동일한 비즈니스, 동일한 고객, 동일한 시스템, 그리고 동일한 몇 가지 반복되는 문제들을 다루고 있습니다.

그러한 환경에서 메모리 범위를 사용자별(per-user) 또는 에이전트별(per-agent)로 설정한다면, 당신은 조용히 이상한 결정을 내린 셈입니다. 지원 에이전트가 고객에 대해 배운 것을 영업 에이전트에게는 보이지 않아야 한다고 말한 것이며, 한 엔지니어의 에이전트가 찾아낸 배포 레시피(deploy recipe)가 그 엔지니어의 에이전트 안에만 갇혀 있어야 한다고 말한 것입니다. 당신은 공유 지식을 축적하는 기계인 기업에, 공유를 거부하는 메모리 계층(memory layer)을 건네준 것입니다.

왜 공유 메모리는 복리로 증가하고 격리된 메모리는 그렇지 않은가

여기서 실제로 중요한 부분이 나오는데, 이는 느낌(vibes)에 관한 논쟁이 아니라 수학적인 논증입니다.

단일 테넌트(Single-tenant) 설정에서는 각 에이전트가 자신이 직접 작성한 것들로부터만 이득을 얻습니다. N개의 에이전트가 있다면, N개의 분리된 메모리 더미가 존재합니다. 시스템의 가치는 에이전트의 수에 따라 선형적으로(linearly) 성장하며, 각 에이전트는 작업의 일부만을 보기 때문에 각 더미의 크기는 작습니다. 지식은 결합되지 않습니다. 그저 서로 결코 닿지 않는 N개의 버킷(buckets) 안에 놓여 있을 뿐입니다.

이제 N개의 모든 에이전트가 하나의 저장소(store)를 공유한다고 가정해 봅시다. 어떤 에이전트의 모든 쓰기(write) 작업은 다른 모든 에이전트에게 읽기(read) 작업이 됩니다. 한 에이전트가 오전 9시에 배운 내용은 9시 5분에 다른 에이전트가 사용할 수 있습니다. 새로운 사실들은 단순히 하나의 더미에 추가되는 것이 아니라, 전체 함대(fleet) 전체에서 재사용 가능해집니다. 유용한 양은 메모리의 개수가 아니라, 저장소에 접근할 수 있는 모든 에이전트에 걸친 '읽기 횟수 × 쓰기 횟수'이며, 이는 선형적인 성장보다 훨씬 더 빠르게 증가합니다.

이는 팀이 구성원 개개인의 합보다 더 큰 가치를 지니는 이유와 같으며, 공유 문서가 잘 갖춰진 코드베이스가 모두가 각자의 머릿속에만 메모를 남기는 코드베이스보다 나은 이유와도 같습니다. 지식은 공유될 때 복리로 쌓입니다(compounds). 반면 고립될 때(siloed)는 정체됩니다. 우리는 이미 인간에 대해 이 사실을 알고 있습니다. 단지 아직 에이전트를 그런 방식으로 설계하지 않았을 뿐입니다.

콜드 스타트(Cold-start) 문제는 이 사실을 구체적으로 보여줍니다. 단일 테넌트(Single-tenant) 환경에서 완전히 새로운 에이전트를 실행하면, 그 에이전트는 0에서 시작합니다. 정의상 과거 기록이 없기 때문에 모든 것을 처음부터 다시 배워야 합니다. 반면 공유 조직 저장소(shared org store)를 사용하는 새로운 에이전트를 실행하면, 조직의 현재 상태에서 시작합니다. 그 에이전트는 이미 결제 관련 특이 사항, 배포 레시피, 고객의 이상한 계약 조건 등을 알고 있습니다. 입사 첫 주차 채용 담당자의 에이전트가 시니어 채용 담당자의 에이전트처럼 채용 관리 시스템(ATS)을 운영할 수 있는 이유는, 시니어 채용 담당자의 에이전트가 1년 동안 채워온 것과 동일한 메모리를 읽고 있기 때문입니다. 이것이 Glen이 내세우는 핵심 가치이며, 올바른 방향입니다. 가치는 한 개인의 세션 내부가 아니라 조직 수준(org level)에 존재합니다.

회상은 기본일 뿐, 흥미로운 움직임은 증류(distillation)에 있다

여기서 제가 과소평가되고 있다고 생각하는 두 번째 요소가 있습니다.
대부분의 메모리 시스템은 회상(recall) 시스템입니다. 질문을 던지면 관련 청크(chunks)를 반환하고, 이를 컨텍스트(context)에 집어넣으면 모델이 그것들을 어떻게 처리할지 결정합니다. 이는 괜찮은 방식이지만, 가공되지 않은 회상은 합성(synthesis)에 필요한 모든 작업을 모델에게 떠넘깁니다. 그것도 컨텍스트 윈도우(context window)가 이미 차오르고 있는 최악의 타이밍인 대화 중간(mid-turn)에 말이죠.

더 흥미로운 설계는 메모리를 액션 레이어(action layer)로 취급하는 것입니다. 에이전트에게 온보딩(onboarding)에 관한 50개의 흩어진 관찰 결과(observations)를 건네주는 대신, 회상 시점에 관련 있는 것들을 클러스터링(cluster)하고 이를 에이전트가 실제로 실행할 수 있는 무언가로 증류(distill)하는 것입니다. 즉, 하나의 절차(procedure)나 기술(skill)로 만드는 것입니다. 에이전트는 온보딩이 대개 어떻게 진행되는지에 대한 사실의 더미를 받는 것이 아니라, 이미 조립되어 실행 준비가 된 '온보딩 플레이북'을 받게 됩니다.

그것이 바로 "배포에 대해 우리가 아는 모든 것"과 "배포하는 방법"의 차이입니다. 전자는 검색 결과(search result)이고, 후자는 전문 지식(expertise)입니다. Glen은 이 점을 강력하게 밀어붙이며, 관찰된 클러스터들을 실행 가능한 기술(runnable skills)로 정제하여 전달하는데, 저는 이것이 이 모든 기술이 나아가야 할 방향이라고 생각합니다. 단순히 기억만 하는 메모리는 데이터베이스(database)입니다. 조직이 알고 있는 것을 에이전트가 수행하는 것으로 전환하는 메모리는 전혀 다른 차원의 것입니다.

메모리가 공유될 때 피할 수 없는 난제들

이것이 공짜처럼 들리지 않기를 바랍니다. 왜냐하면 결코 공짜가 아니기 때문입니다. 여러 에이전트가 하나의 저장소(store)에 쓰기 작업을 허용하는 순간, 단일 테넌트(single-tenant) 시스템은 무시해도 되었던 일련의 문제들을 떠안게 되며, 시스템이 이를 어떻게 처리하느냐가 승패를 결정짓는 핵심이 됩니다.

첫째, 모순(contradictions)이 발생합니다. 두 에이전트가 동일한 고객에 대해 서로 충돌하는 사실을 기록할 수 있습니다. 작성자가 한 명뿐이라면 이런 일이 거의 일어나지 않는 척할 수 있지만, 에이전트 군단(fleet)을 운용한다면 이는 반드시 일어나는 일입니다. 따라서 단순히 마지막에 작성된 것이 승리하는 방식(last-write-wins)이 아니라, 실제적인 충돌 및 모순 해결(conflict and contradiction resolution) 메커니즘이 필요합니다.

둘째, 데이터의 노후화(staleness)가 발생합니다. 3월의 환불 정책은 6월에는 틀린 정보일 수 있습니다. 시간적 추론(temporal reasoning)이 없는 공유 메모리는 한때는 사실이었으나 더 이상은 아닌 사실을 아주 자신 있게 제공할 것입니다. 저장소는 단순히 어떤 사실이 말해졌다는 것뿐만 아니라, 그 사실이 언제 유효했는지를 이해해야 합니다.

셋째, 신뢰 문제(trust problem)가 발생합니다. 만약 에이전트가 두 팀에게 환불 정책에 대해 동일한 답변을 준다면 매우 좋겠지만, 이는 두 팀 모두가 그 답변을 설정한 결정(decision)까지 추적할 수 있을 때만 유효합니다. 메모리가 공유되는 상황에서 모든 사실에 대한 출처(provenance)를 확보하는 것은 있으면 좋은 기능(nice-to-have)이 아니라, 공유 저장소가 자신만만한 소문 생성기(rumor mill)로 변질되는 것을 막아주는 필수 요소입니다. 솔직히 말해서 몇몇 단일 테넌트 도구들은 이 지점에서 아직 절반 정도만 도달해 있습니다. 출처(provenance)와 시간적 추론(temporal reasoning)은 메모리가 한 명의 사용자에게 속해 있을 때는 건너뛰어도 되는 기능이지만, 수백 명에게 속해 있을 때는 결코 건너뛸 수 없는 기능입니다.

그리고 당연한 반론이 나올 것입니다: 어떤 것들은 공유되어서는 안 된다는 점입니다. 때로는 민감한 작업을 수행하고 있으며, 그것이 조직의 브레인(org brain)에 전혀 기록되지 않기를 원할 수도 있습니다. 이는 실질적인 제약 사항이며, 그 해답은 누군가 실수로 잘못된 내용을 붙여넣기를 기대하는 것이 아니라, 엄격한 조직 경계(org boundary)와 아무것도 기록하지 않는 프라이빗 모드(private mode)를 제공하는 것입니다. 한 조직이 다른 조직의 데이터를 절대 읽을 수 없도록 하는 행 레벨 격리(Row-level isolation), 그리고 필요할 때 쓰기 기능을 끌 수 있는 스위치 같은 것 말입니다.

이러한 점들이 공유 메모리(shared memory)가 나쁜 아이디어라는 근거는 아닙니다. 오히려 그것이 매우 어려운(hard) 아이디어라는 근거이며, 제대로 구현된 어려운 아이디어야말로 진정한 가치가 발생하는 지점입니다. 단일 테넌트(Single-tenant) 시스템이 더 단순해 보이는 이유는 대부분 흥미로운 문제들을 범위 밖(out of scope)으로 정의해 버렸기 때문입니다.

배관(Plumbing)은 사라져야 합니다

마지막으로 한 가지만 더 말씀드리겠습니다. 개발자들이 즉각적으로 체감하는 부분이기 때문입니다.
만약 여러분이 직접 RAG 메모리를 구축해 보았다면, 그 비용(tax)을 잘 알고 계실 것입니다. 벡터 스토어(vector store)를 선택하고, 청킹(chunking) 로직을 작성하고, 검색(retrieval)을 튜닝합니다. 쓰기 작업을 처리하고, 그 자체로 하나의 작은 제품인 인덱스(index)를 유지 관리합니다. 사용자가 인지할 수 있는 기능을 단 하나도 출시하기도 전에 메모리 인프라에만 일주일을 소비하게 됩니다.

제가 원하는 버전은 턴(turn)당 단 한 번의 호출로 끝나는 방식입니다. 관련 내용을 인라인(inline)으로 읽고, 동일한 턴에 쓰기 작업을 예약하면 끝납니다. 돌봐줘야 할 인덱스도 없고, 튜닝해야 할 검색 코드도 없으며, 매 턴마다 무엇을 저장할 가치가 있는지 수동으로 결정할 필요도 없습니다. 시스템이 무엇이 관련이 있고 무엇을 보관할 가치가 있는지 결정하며, 읽기와 쓰기를 한 번의 왕복(round trip)으로 처리하여 에이전트 루프(agent loop)를 단순하게 유지합니다. 이것이 Glen이 제공하는 모델이며, 여러분이 이를 사용하든 직접 구축하든 그것이 기준이 되어야 합니다. 메모리 레이어(memory layer)는 하나의 도구 호출(tool call)이어야지, 사이드 프로젝트가 되어서는 안 됩니다.

이것이 도달하는 지점

제가 여러분께 남기고 싶은 프레임워크(framing)는 간단합니다. 단일 테넌트 메모리(Single-tenant memory)가 틀린 것은 아닙니다. 다만 대부분의 에이전트가 실제로 존재하는 환경, 즉 다른 에이전트들로 가득 찬 조직(organization) 내부라는 맥락에 비추어 볼 때, 잘못된 단위(unit)로 범위(scope)가 지정되어 있을 뿐입니다. 사용자별 격리(Per-user isolation)는 소비자용 챗봇(consumer chatbot)에게는 올바른 기본값이었습니다. 하지만 에이전트 군단(fleet)에게는 조직별 공유(Per-org sharing)가 올바른 기본값입니다.

메모리가 공유되면 지식은 초기화되는 대신 복리로 쌓이며, 새로운 에이전트는 백지 상태가 아닌 똑똑한 상태로 시작합니다. 또한 가장 유능한 인재가 퇴사할 때 함께 사라지곤 하던 전문 지식이 조직 내에 그대로 남게 됩니다. 물론 이 과정에서 모순(contradictions), 데이터 노후화(staleness), 출처(provenance), 그리고 격리(isolation) 문제를 실제로 해결해야 하며, 이는 진입 비용(cost of admission)인 동시에 해자(moat)가 됩니다.

만약 동일한 비즈니스를 대상으로 두 개 이상의 에이전트를 운영하고 있다면, 왜 이들이 아직 하나의 두뇌를 공유하지 않는지 질문해 볼 가치가 있습니다. 저희가 Glen에서 구축한 답변의 한 버전을 직접 살펴보실 수 있습니다.