남의 기억이 내 답에 섞일 때, MemLeak이 묻는 것

MemLeak: Cross-User Semantic Leakage in Multi-Tenant AI Agent Memory는 arXiv에 공개된 연구로 arXiv 번호 2610.04195로 등록되어 있다. 원문 링크는 제목 아래에 걸어두었다.

이 연구가 내세우는 주장은 하나의 문장으로 정리된다. 기업용 멀티테넌트 환경에서 여러 사용자의 개인 에이전트가 장기 기억을 위한 하나의 벡터 저장소를 공유하면, 특별한 공격 없이도 평범한 유사도 검색만으로 다른 사용자의 기억이 내 답변에 섞여 들어올 수 있다는 것이다. 이 글에서는 그 진단에서 출발해 공유 기억의 구조와 우연한 누출, 의도적으로 다듬은 기억의 삽입, 답변 오염의 측정, 그리고 소유권 차단이 왜 유일하게 통했는지를 차례로 따라간다.

왜 남의 기억이 내 답에 끼어드는 걸까

제가 이 논문에서 가장 흥미롭게 본 부분은 문제의 출발점이 공격이 아니라는 점입니다. 누군가 시스템을 뚫거나 프롬프트를 속이는 장면이 먼저 나오지 않는데, 대신 평범한 업무용 에이전트의 평범한 하루가 먼저 그려지기 때문입니다. 아침에 출근해서 에이전트에게 어제 회의 내용을 정리해 달라고 묻고, 에이전트는 장기 기억에서 관련 내용을 꺼내 답을 만든다. 여기까지는 우리가 매일 상상하는 모습이죠. 그런데 이 평범한 흐름 안에 이미 누출의 씨앗이 들어 있습니다. 기억을 꺼내는 기준이 누구의 것인지가 아니라 얼마나 비슷한지이기 때문입니다.

생각해보면 사람도 비슷하게 기억합니다. 같은 팀에서 일하다 보면 누군가 했던 말을 내가 들은 것으로 착각할 때가 있죠. 회의실에서 오간 이야기가 누구 입에서 나왔는지 헷갈리는 것처럼요. 그런데 사람의 착각은 대개 그 자리에서 끝나는데, 에이전트의 착각은 저장소를 타고 계속 이어집니다. 한 번 섞인 기억이 다음 검색의 이웃이 되고, 그 이웃이 다시 다음 답변의 재료가 되기 때문입니다. 그렇다면 이 흐름은 어디에서 시작될까요. 저는 그 시작이 해커의 손이 아니라 설계자의 선택에 있다고 봅니다. 여러 사용자를 하나의 저장소에 모아두기로 한 바로 그 결정이죠.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 왜 굳이 기억을 함께 모아둘까요. 답은 운영의 편의에 있는데, 테넌트마다 저장소를 나누면 관리 비용이 늘고 검색 인프라도 조각나기 때문입니다. 하나의 큰 저장소에 모두 넣고 필요할 때 꺼내 쓰면 훨씬 효율적이죠. 그래서 많은 기업용 배포가 개인 에이전트라는 말을 쓰면서도 뒤에서는 기억을 함께 두는 구조를 택합니다. 앞에서는 내 비서처럼 보이고, 뒤에서는 모두가 같은 창고를 쓰는 셈입니다. 이 간격이 바로 논문이 파고든 지점인데, 말과 구조가 어긋나는 곳에서 누출이 시작되지 않을까요?

그래서 함께 쓰는 기억 창고는 어떻게 생겼을까

멀티테넌트 에이전트의 장기 기억은 대개 벡터 저장소 위에 서 있습니다. 사용자가 남긴 메모와 대화 요약, 문서 조각 같은 것들이 임베딩이라는 숫자 벡터로 바뀌어 저장되고, 새로운 질문이 들어오면 질문도 같은 공간의 벡터로 바뀐 뒤 코사인 유사도 같은 기준으로 가까운 이웃을 찾아옵니다. 가까운 것이 관련 있는 것이라는 가정인데, 검색 엔진으로서는 꽤 자연스러운 선택이죠. 문제는 이 가까움이라는 기준 안에 소유권이 들어 있지 않다는 점입니다. 누가 남긴 기억인지보다 무엇과 비슷한지가 먼저 묻기 때문입니다.

여기서 재미있는 질문이 생깁니다. 같은 팀 사람들끼리 비슷한 일을 하면 기억들은 공간 안에서 어디에 놓일까요. 당연히 서로 가까이 모이게 되는데, 영업팀의 회의 메모는 영업팀의 다른 메모 옆에, 개발팀의 장애 기록은 다른 장애 기록 옆에 눕게 되죠. 의미가 비슷할수록 거리가 가까워지는 것이 임베딩 공간의 성격이니까요. 그런데 바로 그 성질 때문에 내 질문은 내 기억만이 아니라 이웃 자리에 있는 동료의 기억까지 함께 끌어올리게 됩니다. 악의가 없어도 구조가 그렇게 이끄는 것이죠.

저는 이 대목을 읽으면서 도서관 비유가 떠올랐습니다. 여러 사람이 각자의 일기장을 한 서가에 꽂아두고, 사서에게 비슷한 내용의 일기장을 찾아달라고 부탁하는 모습인데요. 사서는 누가 쓴 것인지 묻지 않고 내용이 비슷한 순서대로 꺼내옵니다. 정직하게 일한 것뿐인데 결과는 someone else의 일기가 내 책상 위에 놓이는 것이죠. 연구진이 이 실패를 교차 사용자 허용 실패라고 부른 것도 그래서 이해가 됩니다. 들어오면 안 되는 기억이 검색 단계의 문턱을 아무 제지 없이 통과한다는 뜻이니까요. 그렇다면 이 문턱은 실제로 얼마나 자주 열릴까요. 다음 장면이 그 측정입니다.

비슷하다는 이유만으로 꺼내면 왜 위험할까

이 연구가 여섯 가지 실험과 추가 분석으로 펼쳐 보인 구도는 생각보다 단순합니다. 검색 방식을 두 갈래로 나누고, 누출이 일어나는 조건을 우연한 경우와 의도적인 경우로 나눈 뒤, 마지막에는 답변까지 오염되는지를 본 것인데요. 검색 방식부터 보면 한쪽은 TF-IDF라는 희소 검색이고 다른 한쪽은 MiniLM-L6-v2를 쓴 조밀한 dense 검색입니다. 전자는 단어가 겹치는지를 보고, 후자는 의미를 벡터로 읽어 실제 제품 환경에 가깝게 재현한 쪽이죠. 두 방식을 함께 본 것은 단어만 겹쳐서 생기는 일이 아니라 의미가 가까워서 생기는 일까지 보겠다는 뜻으로 읽힙니다.

표면적으로 보면 단순합니다. 실제로는 그렇지 않습니다. 검색이 비슷함을 기준으로 삼는 한, 소유권은 검색식 바깥에 남기 때문입니다. 검색식은 질문 벡터와 기억 벡터 사이의 거리만 재고, 그 기억이 누구 소유인지는 묻지 않죠. 그래서 같은 팀처럼 맥락이 겹치는 집단에서는 내 질문과 동료의 기억이 서로를 끌어당기게 됩니다. 어제 내가 쓴 주간 보고서 초안을 찾으려 했는데 옆자리 동료의 보고서 조각이 함께 딸려오는 것처럼요. 물리적으로는 한 저장소, 기하학적으로는 가까운 이웃, 제도적으로는 다른 사람 소유라는 세 가지 사실이 한 검색 결과 안에서 충돌하는 것이죠.

여기서는 조금 조심해서 읽을 필요가 있습니다. 유사도 검색 자체가 잘못됐다는 이야기가 아니기 때문입니다. 유사도 검색은 혼자 쓰는 기억에서는 아주 잘 동작하는데, 내 기억만 들어 있는 서가에서는 가까운 것이 곧 필요한 것이기 때문이죠. 그런데 사용자가 여럿이 되면 같은 식이 다른 뜻을 갖게 됩니다. 가까운 것이 남의 것일 수 있다는 가능성이 열리는 것이죠. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 검색식을 고치는 문제가 아니라 검색식 앞에 소유권이라는 조건을 어디에 둘지의 문제로 바뀌기 때문입니다. 그렇다면 우연한 겹침만으로도 얼마나 자주 열릴까요.

가만히 두었는데도 새어 나왔다면 무엇을 믿어야 할까

연구진이 먼저 본 것은 아무도 공격하지 않은 상태의 누출입니다. 같은 팀 안에서 저장소를 함께 쓰는 pooled same-team 조건에서는 우연한 누출이 70퍼센트에서 100퍼센트까지 치솟았는데요. 이 숫자는 공격자가 있다는 가정이 아니라 일상적인 질문만으로도 남의 기억이 검색 결과에 들어온다는 뜻입니다. 같은 프로젝트를 다루고 같은 용어를 쓰면 질문의 벡터가 동료의 기억 벡터 옆에 떨어지는 것은 거의 피할 수 없기 때문입니다. 제가 앞으로 보고 싶은 것은 바로 이 조건의 현실성인데, 기업 현장에서 같은 팀이 저장소를 나누는 일이 얼마나 흔한지를 생각하면 이 숫자는 실험실 너머의 이야기처럼 들립니다.

예를 들어 월요일 오전의 장면을 떠올려보자. 한 팀원이 에이전트에게 지난주 고객 미팅 요약을 찾아달라고 묻습니다. 질문에는 고객사 이름과 쟁점이 들어 있고, 저장소에는 같은 미팅에 대해 다른 팀원이 남긴 메모도 함께 들어 있죠. 표현이 조금씩 다를 뿐 다루는 내용은 같기 때문에 검색 결과에는 두 사람의 메모가 나란히 오릅니다. 그런데 에이전트는 둘을 가려내지 않고 함께 읽고, 답변에는 동료의 문장이 자연스럽게 녹아듭니다. 누구도 몰래 심어둔 것이 없는데 결과는 섞인 것이죠. (참고로 이 단계는 아직 답변이 오염됐다는 말이 아니라 검색 결과가 섞였다는 뜻인데요. 검색이 섞이면 답변이 섞일 준비가 끝났다는 점에서 절반쯤 온 셈입니다.)

문제는 그다음입니다. 희소 검색에서는 단어의 겹침이 누출을 설명하는 것처럼 보일 수 있는데, 조밀한 dense 검색에서도 누출이 이어졌다는 점이죠. 오히려 의미가 통하면 표현이 달라도 이웃이 되기 때문에 단어를 바꿔 쓴다고 피할 수 있는 일이 아닙니다. 같은 고객을 두고 한 사람은 이슈라고 쓰고 다른 사람은 리스크라고 써도 두 메모는 공간 안에서 이웃이 되니까요. 그래서 저는 이 우연한 누출이야말로 논문의 무게중심이라고 봅니다. 공격을 막는 문제가 아니라 평범한 사용이 평범하게 새는 문제이기 때문인데, 이런 종류의 문제는 경고 문구 하나로 덮을 수 있는 성격이 아니지 않을까요?

일부러 다듬은 기억은 얼마나 잘 위로 올라올까

우연한 누출 다음에 연구진이 본 것은 의도적으로 가공한 기억입니다. 공격자가 될 수 있는 쪽에서 검색의 성질을 이용해 자신의 기억을 남의 질문에 잘 걸리도록 다듬어 넣으면 어떻게 되느냐는 것인데요. 결과는 꽤 선명했습니다. 이렇게 다듬은 기억은 상위 검색 결과에 90퍼센트에서 100퍼센트까지 자리 잡았고, 단순히 키워드를 박아 넣은 약한 기준 공격보다 훨씬 높은 점수를 받았습니다. 조밀한 검색의 특정 설정에서는 점수 상승폭이 0.416에서 0.511까지 벌어졌는데, 이 차이는 우연히 걸린 수준이 아니라 검색 순위를 거의 장악한 수준으로 읽힙니다.

그렇다면 다듬는다는 것은 구체적으로 무엇을 뜻할까요. 단어 몇 개를 반복해 넣는 얕은 수를 넘어 질문의 의미와 이웃이 되도록 기억의 표현을 고르는 일이라고 보면 되는데, 같은 이야기를 검색이 좋아하는 모양으로 다시 쓰는 것에 가깝습니다. 생각해보면 시험에서 모범 답안의 말투를 따라 쓰는 것과 비슷한데요. 내용은 그대로 두면서 검색이 먼저 집어 들도록 포장을 바꾸는 것이죠. 그런데 이 포장이 통하는 이유는 검색이 애초에 의미의 가까움을 좋아하기 때문입니다. 검색의 미덕을 역이용하는 셈이라 막기가 더 까다롭습니다.

저는 여기서 조금 의심했습니다. 90퍼센트에서 100퍼센트라는 숫자가 너무 깔끔해 보였기 때문인데요. 조건을 뜯어보면 특정 설정 아래의 상위 결과라는 단서가 붙어 있습니다. 모든 저장소와 모든 질문에서 늘 그렇다는 뜻이 아니라, 공격자가 조건을 알고 다듬었을 때 순위가 그 정도로 기울 수 있다는 뜻이죠. 그럼에도 이 결과를 가볍게 볼 수 없는 이유는 방향이 분명하기 때문입니다. 얕은 키워드 공격보다 의미 단위로 다듬은 공격이 더 잘 통했다는 점, 그리고 그 상승폭이 소수점 이하의 오차가 아니라 0.4를 넘는 큰 폭이었다는 점이죠. 검색이 똑똑해질수록 이런 다듬기에 더 잘 반응한다면, 똑똑한 검색일수록 소유권의 문턱이 더 절실해지지 않을까요?

검색에서 그치지 않고 답을 오염시키는 과정은 어떨까

검색 결과가 섞이는 것과 답변이 오염되는 것은 다른 층위의 일입니다. 검색은 후보를 꺼내는 일이고 답변은 그 후보를 읽고 문장을 만드는 일이니까요. 연구진은 그래서 검색을 넘어 끝단까지 이어지는 오염을 따로 쟀는데, 제품 환경에 가까운 검색 경로에서는 오염 점수가 5점 만점에 5.00까지 올랐고 Claude Sonnet 4.5를 생성 모델로 쓴 경우에도 4.67까지 올랐습니다. 두 종류의 생성 모델에 걸쳐 비슷한 수준의 오염이 재현됐다는 점이 눈에 띄는데, 검색이 섞인 뒤에는 생성 모델이 그 섞임을 바로잡지 못했다는 뜻으로 읽힙니다.

이 과정은 실제 파이프라인을 따라가 보면 더 잘 이해됩니다. 먼저 사용자의 질문이 벡터로 바뀌고, 저장소에서 가까운 이웃들이 딸려옵니다. 그 안에는 내 기억과 남의 기억이 섞여 있는데 검색 결과에는 누구 것인지 적혀 있지 않거나 적혀 있어도 생성이 그 표식을 무시하죠. 이어서 생성 모델은 주어진 문맥을 성실하게 읽고 매끄러운 답을 만듭니다. 문제는 그 성실함이 오히려 오염을 완성한다는 점입니다. 남의 기억을 버리라는 지시가 없는 한 모델은 그것을 재료로 쓰는 것이 일을 잘하는 것이니까요. 그래서 오염된 답변은 어색하게 깨지지 않고 자연스럽게 완성됩니다.

저는 이 대목이 운영자의 언어로 읽힌다고 봅니다. 검색 정확도와 생성 유창성이 각자의 자리에서는 잘 동작하는데, 둘이 이어지는 지점에서 소유권이 빠져 있기 때문입니다. 각 부품은 열심히 일하는데 조립된 결과는 새는 것이죠. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 같은 태도로 보면 이 실험이 말하는 것은 점수 하나가 아니라 파이프라인의 이음새입니다. 검색과 생성 사이에 누구의 기억인지를 묻는 문이 없다는 사실이죠. 그렇다면 그 문이 없을 때 답변은 어떻게 보일까요. 겉보기에는 멀쩡해 보인다는 점이 다음 이야기의 시작입니다.

도움이 돼 보인다는 평가가 왜 더 무서울까

이 논문에서 개인적으로 인상 깊었던 점은 오염된 답변이 오히려 도움이 돼 보였다는 대목입니다. 오염된 답변은 사람의 판단과 견주어 봐도 깨끗한 답변만큼 도움이 되거나 때로는 더 도움이 되는 것처럼 평가받았는데요. 이유를 생각해보면 그리 이상하지 않습니다. 남의 기억이라도 같은 팀의 맥락에서는 관련 있는 정보일 때가 많기 때문입니다. 동료가 정리해둔 고객 배경이나 장애 대응 기록이 내 질문에도 들어맞으면 답변은 더 풍성해지죠. 출처가 섞였다는 사실만 빼면 내용으로는 더 좋아 보이는 역설이 생깁니다.

여기서 재미있는 질문이 생깁니다. 도움이 되면 괜찮은 것 아닐까요. 겉으로 보면 그렇게 물을 수 있는데, 소유권의 관점에서 보면 정반대로 읽힙니다. 도움이 된다는 느낌이 바로 누출을 감추는 연막이 되기 때문입니다. 사용자는 답변이 좋아서 만족하고, 만족했기 때문에 출처를 따지지 않으며, 따지지 않았기 때문에 누출은 다음에도 반복되죠. 보안 사고치고는 너무 조용한 셈인데, 깨지는 소리가 나지 않고 박수가 나오는 사고라서 더 오래 방치될 수 있습니다. 생각해보면 사람 조직에서도 비슷한 일이 있는데요. 옆 팀 문서를 몰래 보고 일을 잘 처리하면 당장은 칭찬받지만 조직의 경계는 이미 허물어진 것과 같습니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 그렇다면 품질 평가만으로는 이 문제를 잡을 수 없다는 뜻일까요. 저는 그렇다고 봅니다. 답변이 매끄럽고 도움이 된다는 신호는 오염 여부와 거의 무관하게 움직이기 때문입니다. 품질 점수가 높다고 소유권이 지켜졌다는 뜻이 아니죠. 그래서 평가는 두 갈래로 갈라져야 하는데, 하나는 답변이 쓸모 있는지를 묻고 다른 하나는 답변의 재료가 허용된 것인지를 묻는 것입니다. 쓸모 있음과 허용됨은 다른 질문인데, 그동안 우리는 앞의 것만 열심히 재지 않았을까요?

세 가지 처방 가운데 하나만 살아남은 까닭은 무엇일까

연구진은 세 가지 구조적 완화책을 시험했는데, 그 가운데 검색 뒤에 소유권을 단단히 가리는 hard post-retrieval ownership gating만이 두 종류의 생성 모델에서 모두 깨끗한 기준선인 5점 만점에 1.00을 회복했습니다. 다시 말해 오염이 거의 없는 상태로 돌아간 것이죠. 검색이 무엇을 가져오든 생성 단계로 넘어가기 전에 소유자가 다른 기억은 통과시키지 않는 문을 둔 것인데, 이 문은 단순하지만 확실했습니다. 쿼리당 1.4밀리초 정도의 지연만으로 오염을 기준선까지 낮췄다는 점도 함께 보고됐는데, 운영 비용으로 보면 꽤 가벼운 값으로 읽힙니다.

그렇다면 왜 하필 이 방식만 통했을까요. 이유는 문의 위치에 있다고 봅니다. 검색식을 손보는 방식은 순위를 조금 바꿀 수는 있어도 이웃 자체를 없앨 수는 없는데, 같은 팀의 기억들이 공간 안에서 이웃으로 모여 있는 한 다른 표현의 질문이 오면 다시 딸려오기 때문입니다. 반면 검색 뒤의 소유권 문은 순위와 무관하게 동작합니다. 몇 등에 올랐든 소유자가 다르면 생성 단계로 보내지 않죠. 순위 경쟁의 바깥에서 규칙을 거는 셈이라 공격자가 표현을 다듬어도 뚫기 어렵습니다. 저는 이 대비가 논문이 주는 운영상의 교훈이라고 봅니다. 똑똑한 순위 다툼 안에서는 답이 없고, 순위 바깥의 규칙에서만 답이 나왔다는 것이죠.

예를 들어 사내 문서함의 장면을 떠올려보자. 검색창에 물어보면 관련 문서가 쭉 뜨는데, 그 목록에는 내가 볼 권한이 없는 문서도 섞여 있다고 해보자. 검색 순서를 아무리 잘 다듬어도 권한 없는 문서가 목록에 뜨는 한 누군가는 그것을 열어볼 수 있습니다. 진짜로 필요한 조치는 순서를 다듬는 것이 아니라 권한 없는 문서를 목록에서 빼는 것이죠. 기억 저장소도 마찬가지인데, 검색이 잘 찾는 것과 보여줘도 되는 것은 다른 문제라서 두 번째 질문을 맡는 문이 따로 있어야 합니다. 이 차이는 생각보다 중요한데, 앞의 질문은 성능의 문제이고 뒤의 질문은 허용의 문제이기 때문입니다. 성능을 올리는 처방으로는 허용의 실패를 고칠 수 없죠. 그렇다면 이 문의 비용은 감당할 만할까요. 1.4밀리초라는 숫자는 긍정의 쪽에 가깝지만, 그 숫자를 곧바로 일반화하기 전에 조건을 봐야 합니다.

숫자를 그대로 믿기 전에 조건을 봐야 하는 대목은 어디일까

여기서는 조금 조심해서 읽을 필요가 있습니다. 70퍼센트에서 100퍼센트, 90퍼센트에서 100퍼센트, 5.00과 4.67 같은 숫자들이 강렬하지만, 각각의 숫자는 서로 다른 조건 위에서 잰 것이기 때문입니다. 우연한 누출은 pooled same-team이라는 함께 쓰는 조건 아래의 이야기이고, 의도적 삽입의 상승폭은 조밀한 검색의 특정 설정 아래의 이야기이며, 답변 오염은 제품 환경에 가까운 경로와 특정 생성 모델 조합 위의 이야기죠. 여섯 가지 실험과 추가 분석이 그런 조건들을 나누어 보여준 것은 잘한 일인데, 독자가 해야 할 일은 그 조건들을 하나로 뭉개지 않는 것입니다. 숫자를 합쳐서 모든 경우에 다 그렇다는 한 문장으로 만들면 논문이 말한 것보다 더 크게 말하는 셈이 되니까요.

좋은 건 알겠는데, 이걸 실제로 어떻게 재현할까요. 현장의 저장소는 논문의 실험보다 더 지저분한데, 사용자 수가 훨씬 많고 기억의 길이도 제각각이며 팀의 경계도 자주 바뀌기 때문입니다. 팀이 합쳐지거나 프로젝트가 끝나면 이웃 관계 자체가 바뀌죠. 이런 지저분함이 누출을 키울지 줄일지는 미리 단정하기 어렵습니다. 이웃이 많아지면 섞일 가능성도 커지지만, 동시에 관련 없는 기억이 완충재가 되어 순위를 희석할 수도 있기 때문입니다. 그래서 저는 이 숫자를 천장이나 바닥이 아니라 방향으로 읽는 편이 맞다고 봅니다. 조건이 갖춰지면 이 정도까지 새어날 수 있다는 가능성으로요. 가능성으로만 봐도 충분히 무겁지 않을까요?

또 하나 짚고 싶은 것은 측정의 성격입니다. 오염 점수 5.00이나 4.67은 사람이 보기에도 오염됐다는 뜻이지 기계가 자동으로 매긴 점수가 아니라는 점이 보고서에 엮여 있는데, 사람의 판단과 견준 검증이 함께 있었다는 대목은 숫자의 신뢰를 돕습니다. 다만 사람의 판단은 도움이 됨과 섞였음을 구분하기 어렵다는 앞에서 본 역설과 연결되는데, 오염됐지만 도움이 돼 보인다는 평가는 측정자를 헷갈리게 만들 수 있기 때문입니다. 그래서 다음 연구에서 보고 싶은 것은 오염의 종류를 더 나누는 일입니다. 사실 관계가 틀린 오염과 출처만 섞인 오염, 민감한 정보가 넘어간 오염은 서로 다른 위험이니까요. 지금 숫자는 그 셋을 한 바구니에 담은 것처럼 보이는데, 바구니를 나누면 처방의 순서도 달라지지 않을까요?

기억을 나누는 설계는 앞으로 무엇을 바꿔야 할까

앞에서 미뤄뒀던 질문으로 돌아올 차례입니다. 기억을 함께 두는 설계는 앞으로 어떻게 바뀌어야 할까요. 논문이 가리키는 답은 단순한데, 검색과 생성 사이에 소유권의 문을 두라는 것입니다. 검색이 끝난 뒤 생성으로 넘기기 전에 누구의 기억인지를 확인하고 남의 것은 빼라는 것이죠. 1.4밀리초라는 가벼운 비용으로 기준선을 회복했다는 결과는 이 문이 사치가 아니라 기본값이 되어야 한다는 쪽으로 기웁니다. 권한 확인을 검색 뒤에 두는 것이 어색하게 들릴 수도 있지만, 검색이 의미를 좋아하는 한 검색 안에서 소유권을 다 가려내기 어렵기 때문에 검색 뒤의 확인이 오히려 정직한 자리가 됩니다.

그렇다면 이 흐름은 어디에서 끊을 수 있을까요. 저는 세 군데를 함께 봐야 한다고 봅니다. 먼저 저장할 때 누구의 것인지를 지워지지 않게 적어두는 일, 다음에 꺼낼 때 그 표식을 순위와 무관하게 확인하는 일, 마지막으로 만들 때 재료의 출처를 답의 품질과 따로 감사하는 일인데요. 셋 가운데 논문이 직접 증명한 것은 가운데 것입니다. 저장할 때의 표식과 만들 때의 감사는 다음 연구와 현장의 몫으로 남죠. 특히 팀이 합쳐지고 사람이 이동하는 기업에서는 소유권이 고정된 값이 아니라 시간에 따라 바뀌는 값이라서, 어제의 동료가 오늘의 외부인이 될 수도 있습니다. 이런 변화를 문이 따라가지 못하면 문은 다시 유명무실해지니까요.

이 논문이 흥미로운 이유는 새로운 공격을 뽐내는 데 있지 않습니다. 평범한 설계가 평범하게 새는 장면을 숫자로 보여준 데 있는데, 멀티테넌트라는 말이 편리할수록 그 뒤의 저장소가 어떻게 생겼는지를 함께 물어야 한다는 점을 일깨우기 때문입니다. 앞으로 에이전트가 더 오래 기억하고 더 많은 일을 맡을수록, 개별 모델이 똑똑한지만 보는 것을 넘어 누구의 기억으로 답을 만들었는지까지 함께 살펴봐야 할 것 같습니다. 여러분의 에이전트가 어제 꺼내 쓴 그 기억은, 과연 누구의 것이었을까요.