Executive Summary

AI 에이전트가 세션이 끝난 뒤에도 사용자의 개인정보를 파일에 조용히 적어 두기 시작했다. Claude Memory Tool이나 ChatGPT Memory 같은 도구가 실무에 들어오면서, 에이전트는 session-context.md 같은 비정형 메모리에 "이 사용자는 …"으로 시작하는 관찰을 스스로 기록한다. 문제는 그 기록에 이름표가 없다는 데 있다. 그것이 누구의 데이터인지가 파일 안에 남지 않는다. 배포자는 저장소는 통제하지만, 그 안에 무엇이 누구 이름으로 쌓이는지는 알지 못한다. 그래서 "나를 지워 달라"는 요청이 와도 어떤 메모리가 그 사람 것인지 특정할 수 없어, 삭제 절차가 물리적으로 대상에 닿지 못한다.

이 보고서의 테제는 어제(2026년 7월 28일) 발행한 「학습 데이터에서 한 사람 몫만 지우는 토큰 단위 출처 추적」을 학습 가중치에서 런타임 메모리로 그대로 옮긴 것이다. 학습 데이터 쪽에서는 출처 태그 없이 배운 탓에 저자 한 명을 지우려다 무고한 데이터까지 최대 101배가 함께 지워졌고, 토큰 단위 프로버넌스가 이 과잉삭제를 1.3배로 줄였다. 런타임 메모리 쪽에서는 태그 없이 기록한 탓에 삭제 요청 자체가 성립하지 않는다. 계층은 다르지만 무너지는 지점은 같다.

그래서 이 글이 반복해 되짚는 한 문장은 이렇다. 쓰기 시점에 "이 기억은 누구 것인가"라는 이름표(프로버넌스)를 붙이지 않으면, 나중에 어떤 삭제 절차도 소급해 작동하지 않는다. 해법은 사후에 붙이는 삭제 버튼이 아니라 기록하는 그 순간의 설계다. 그리고 그 설계는 곧 규제 이행의 수단이기도 하다.

이 문제의 크기는 숫자 네 개로 잡힌다. 학습 데이터에서 데이터셋 단위 삭제가 무고한 데이터를 몇 배까지 함께 지웠는지, 메모리를 붙이는 순간 다중 사용자 시스템의 정보 노출이 얼마나 뛰는지, 에이전트끼리 주고받는 내부 채널이 최종 출력보다 얼마나 더 새는지, 그리고 이 문제의 노출면을 키우는 에이전트 확산이 얼마나 빠른지. 이 네 가지다.

101배 → 1.3배

학습 데이터 과잉삭제

데이터셋 단위 삭제 vs 토큰 단위 프로버넌스 · 짝 시리즈 대구

36~47% → 63~90%

메모리 도입 시 노출 위반 급증

PiSAs 다중 사용자 벤치마크 · 위반이 메모리로 이동

68.8%

에이전트 간 메시지 유출률

AgentLeak · 최종 출력(27.2%)의 2.5배, 출력 감사는 41.7% 놓침

5% → 40%

기업 앱의 AI 에이전트 탑재

Gartner · 2025년 5% 미만에서 2026년 말 40% 전망

1

나를 기억하기 시작한 에이전트

오랫동안 AI 챗봇의 기본 성질은 망각이었다. 대화창을 닫으면 방금 나눈 이야기는 사라졌고, 다음에 다시 열면 상대는 나를 처음 보는 얼굴로 맞았다. 2026년 들어 이 기본값이 조용히 뒤집혔다. Anthropic의 Claude Memory Tool, OpenAI의 ChatGPT Memory, Google Gemini의 개인화 기능처럼 세션 밖에 정보를 남기는 도구가 잇따라 실무에 들어오면서, 에이전트는 이제 대화가 끝난 뒤에도 나에 대한 관찰을 파일로 남겨 둔다. 다음에 다시 만나면 그 파일을 먼저 읽고 온다. 기억하지 않음이 기본값이던 자리를, 기억함이 대신했다.

기술적으로 이 기억은 대체로 사람이 읽을 수 있는 텍스트 파일이다. 에이전트는 대화 중에 "다음에 도움이 될 것 같다"고 판단한 내용을 session-context.md 같은 이름의 메모리 파일에 스스로 적는다. 여기에는 사용자의 이름, 소속, 진행 중인 프로젝트, 선호와 습관, 때로는 건강이나 가족 같은 민감한 맥락까지 담긴다. 무엇을 남길지는 사람이 일일이 지시하지 않는다. 에이전트가 판단하고, 에이전트가 쓴다. 이 자율성이 메모리 기능의 편의를 만드는 동시에, 이 보고서가 다루는 문제의 출발점이 된다.

이 기억은 대체로 이런 모습으로 쌓인다. 아래는 에이전트가 세션 밖 파일에 남기는 메모리의 전형이다. 사용자가 명시적으로 "저장해 달라"고 하지 않았는데도, 대화에서 스치듯 언급된 개인정보가 관찰의 형태로 적혀 있다.

session-context.md — 에이전트가 자율적으로 기록한 메모리 (예시)

- 사용자는 서울의 한 핀테크 팀 리드. 야근이 잦다고 언급함.
- 최근 이직 고민 중 (현재 회사 언급을 피하려 함).
- 배우자가 당뇨 관리 중 — 식단 관련 질문이 종종 있음.
- 선호: 결론부터, 표보다 문장. 오전에 집중.

이 파일 어디에도 "이 관찰은 어느 사용자의 것"이라는 식별자가 없다. 나중에 "나를 지워 달라"가 왔을 때, 이 네 줄이 그 사람 것인지 판단할 근거가 파일 안에 존재하지 않는다.

이것이 소수의 실험적 사례라면 굳이 보고서를 쓸 일이 아니다. 하지만 확산의 속도가 이 문제를 실무의 문제로 바꾼다. Gartner는 2025년에는 5% 미만이던 기업 애플리케이션의 태스크 특화 AI 에이전트 탑재 비율이 2026년 말이면 40%에 이를 것으로 전망했다. 1년 사이 약 여덟 배다. 에이전트가 늘어난다는 것은 곧 세션 밖에 이름표 없이 쌓이는 개인정보의 양이 같은 속도로 늘어난다는 뜻이다. 노출면이 팽창하는 동안, 그 안에 무엇이 누구 이름으로 적히는지를 아는 사람은 여전히 없다.

2

삭제 요청이 닿지 못하는 곳

법률·컴플라이언스 매체 Astraea는 에이전트 메모리의 프라이버시를 다루면서 이 문제를 한 문장으로 압축했다. "당신은 에이전트가 저장했다는 사실을 모르는 것을 지울 수 없다(You cannot delete what you do not know the agent stored)." 삭제는 대상을 특정하는 데서 출발하는데, 이름표 없는 메모리에서는 그 첫 단계부터 걸린다. 삭제 버튼이 없어서가 아니라, 무엇을 눌러야 할지 아무도 모른다는 것이 문제의 본질이다.

구조를 뜯어보면 이렇다. 에이전트를 배포하는 기업은 법적으로 데이터 컨트롤러다. 저장소는 그들의 것이고, 파일 시스템 접근 권한도 그들에게 있다. 즉 그릇은 통제한다. 그러나 그 그릇 안에 에이전트가 무엇을, 언제, 누구에 관해 적었는지는 통제하지 못한다. 기록의 주체가 사람이 아니라 자율적으로 판단하는 에이전트이기 때문이다. 컨트롤러가 저장소는 소유하되 내용은 모르는 이 어긋남이, 삭제가 물리적으로 실행 불가능해지는 지점이다.

한 사용자가 "당신들이 나에 대해 저장한 것을 전부 지워 달라"고 요청한다고 하자. 배포자는 메모리 저장소를 연다. 수천 명의 사용자와 나눈 대화에서 파생된 메모리 파일들이 그 안에 뒤섞여 있다. 그중 어느 문장이 이 요청자의 것인가? 파일에는 "이 사용자는 야근이 잦다"는 관찰만 있을 뿐, 그 사용자가 누구인지 잇는 식별자가 없다. 요청자의 것을 정확히 골라내려는 순간, 배포자가 가진 정보로는 그 경계를 그을 수 없다는 사실과 마주친다.

"나를 지워 달라" 사용자의 삭제 요청 ? 메모리 저장소 — 배포자가 통제(그릇) 기억 A 이름표 없음 기억 B 이름표 없음 기억 C 이름표 없음 기억 D 이름표 없음 네 파일 모두 형식과 무게가 같다 — 어느 것이 요청자의 것인지 저장소 안에 판단 근거가 없다

저장소(그릇)는 배포자가 통제하지만, 그 안에 누구의 기억이 있는지는 통제 밖이다. 이 어긋남이 삭제를 물리적으로 불가능하게 만든다.

선택지는 둘로 좁혀진다. 관련 있어 보이는 메모리를 통째로 지워 다른 사용자의 기록까지 훼손하거나, 특정이 불가능하다는 이유로 삭제를 사실상 이행하지 않거나. 어느 쪽도 "그 사람 몫만 정확히 지운다"는 삭제의 본래 의미를 충족하지 못한다. 이 두 선택지는 학습 데이터 삭제에서 이미 본 딜레마와 정확히 같은 모양이다. 통째로 지우면 과잉삭제, 안 지우면 미이행. 다음 섹션에서 이 대구를 다룬다.

이 어긋남은 제품의 삭제 기능 유무와는 별개의 문제다. 실제로 Claude Memory Tool 같은 도구는 메모리 삭제 동작을 제공하지만, 그 삭제 핸들러를 구현하고 무엇을 지울지 정하는 책임은 도구를 배포하는 개발자·기업에게 있다. 곧 삭제 기능이 있느냐가 아니라, 삭제할 대상을 식별할 수 있느냐가 관건이다. 그리고 그 식별 가능성은 기록하는 순간에 이름표를 남겼는지에 달려 있다. 남기지 않았다면, 잘 만든 삭제 버튼도 지울 곳을 찾지 못한다.

3

학습 가중치에서 런타임 메모리로

어제 발행한 짝 시리즈는 학습 데이터의 삭제를 다뤘다. 누군가 GDPR의 잊힐 권리나 저작권 철회를 근거로 "내가 쓴 것을 학습 코퍼스에서 빼 달라"고 요구할 때, 수억 줄이 뒤섞인 데이터에서 그 사람 몫만 정확히 도려내야 한다. 그런데 현장의 데이터 버전 관리 도구는 대개 파일이나 데이터셋을 단위로 출처를 기록한다. 그래서 지분 1%짜리 기여자 한 명을 지우려 데이터셋 단위로 처리하면, 정말 지워야 할 양의 101배가 함께 날아간다. 나머지 99%는 삭제와 무관한 무고한 데이터다. 저자 신원을 토큰 단위까지 따라 내려가는 출처 추적이 이 과잉삭제를 1.3배로 줄였다.

이 글이 다루는 런타임 메모리는 같은 원리가 무너지는 다른 계층이다. 학습 데이터는 태그 없이 배운 탓에 지울 때 과잉삭제가 났다면, 메모리는 태그 없이 적은 탓에 삭제 대상을 특정하는 첫 단계에서부터 막힌다. 학습 쪽은 "너무 많이 지워지는" 문제였고, 메모리 쪽은 "지울 것을 못 찾는" 문제다. 증상은 다르지만 뿌리는 하나다 — 쓰기 시점에 이름표를 남기지 않았다는 것. 아래 도식은 두 계층에서 같은 원인이 어떻게 서로 다른 실패로 갈라지는지를 나란히 놓은 것이다.

공통 원인 · 쓰기 시점에 이름표(프로버넌스)를 남기지 않음 기록한 순간에만 알 수 있는 정보 — 사후에 소급해 붙일 수 없다 학습 가중치 정적 · 오프라인 · 학습 이전에 고정 증상 — 통째로 지워 과잉삭제 101배 데이터셋 단위 삭제 토큰 단위 프로버넌스 → 1.3배 런타임 메모리 동적 · 온라인 · 세션 간 누적 증상 — 지울 대상을 못 찾음 삭제 불성립 식별 자체가 안 됨 쓰기 시점 태깅 → 삭제 성립

같은 원인이 계층에 따라 과잉삭제(왼쪽)와 삭제 불성립(오른쪽)으로 갈라진다. 두 경우 모두 해법은 사후 삭제가 아니라 쓰기 시점의 이름표다.

두 계층은 성격도 다르다. 학습 데이터는 정적이다. 학습이 시작되기 전에 코퍼스가 고정되고, 삭제 문제는 그 고정된 덩어리를 대상으로 한다. 반면 런타임 메모리는 동적이다. 에이전트가 운영되는 내내 새 관찰이 계속 추가되고, 여러 세션에 걸쳐 누적되며, 때로는 여러 사용자의 맥락이 한 저장소에 섞인다. 그래서 메모리 쪽의 삭제 문제는 "한 번 정리하면 끝"이 아니라, 쓰기가 일어나는 매 순간 이름표를 붙여 두어야 나중에 감당할 수 있는 성격의 문제다.

이 대구는 페블러스가 앞서 다룬 또 다른 사건과도 인과로 이어진다. 중국의 에이전트 메모리 소유권 사례에서는 규제가 특정 에이전트의 메모리를 통째로 삭제하도록 강제한 결과를 다뤘다. 그것이 "규제가 지운 결과"라면, 이 글은 그보다 앞선 질문 — 왜 정밀하게, 안전하게 지우지 못하는가라는 기술적 원인 — 을 짚는다. 통째로 지우는 무딘 삭제가 유일한 선택지가 되는 이유가 바로 이름표의 부재다.

4

새는 기억

지울 수 없는 기억은 그 자리에 머무는 데 그치지 않는다. 여러 사용자가 함께 쓰는 에이전트 시스템에서는, 이름표 없이 쌓인 기억이 엉뚱한 사람에게 흘러가기도 한다. 삭제 불성립과 유출은 다른 문제처럼 보이지만 같은 뿌리를 공유한다. 누구 것인지 표시되지 않은 기억은 지울 수도, 제자리에 묶어 둘 수도 없다. 이 절의 두 벤치마크는 그 유출이 실제로 얼마나 큰지를 정량으로 보여준다. 다만 분명히 해 둘 것은, 이 수치들은 유출의 크기를 재는 근거이지 "삭제가 안 된다"는 앞선 논증의 직접 증거는 아니라는 점이다. 삭제 불성립은 설계와 논리의 문제이고, 유출은 그 옆에서 함께 커지는 위험이다.

세는 곳이 다르면 결과가 다르다

AgentLeak은 멀티에이전트 LLM 시스템의 프라이버시 유출을 채널별로 측정한 벤치마크다(1,000개 시나리오, 7개 채널, 5개 프로덕션 모델). 핵심 발견은 유출이 어디서 일어나는가에 따라 그림이 완전히 달라진다는 것이다. 사용자에게 보이는 최종 출력만 감사하면 위반의 27.2%만 잡히지만, 에이전트끼리 주고받는 내부 메시지 채널을 들여다보면 유출률이 68.8%로 뛴다. 출력만 감사하는 방식은 실제 위반의 41.7%를 놓친다. 이름표 없이 내부 채널로 흘러간 기억이 감사망 밖에 있다는 뜻이다.

최종 출력 (C1) 27.2% 에이전트 간 메시지 (C2) 68.8% 출력 감사가 놓치는 위반 41.7% 막대 길이는 채널별 유출률(시나리오 대비). 출처: AgentLeak (arXiv:2602.11510)

보이는 곳만 감사하면 안심하지만, 새는 곳은 대체로 보이지 않는 내부 채널이다.

메모리를 붙이는 순간 유출면이 넓어진다

PiSAs는 다중 사용자 환경에서 정보가 적절한 상대에게만 전달되는지(맥락 무결성)를 측정한 벤치마크다. 이 보고서 주제에 가장 직접적인 발견은 메모리를 붙였을 때 일어나는 변화다. 시스템에 메모리를 추가하자 위반이 사라지는 게 아니라 메모리로 옮겨 갔고, 전체 노출 위반율이 36~47%에서 63~90%로 뛰었다. 기억을 저장하는 바로 그 기능이 유출면을 넓힌 것이다. 단일 에이전트 구성에서도 최신 모델조차 부적절한 정보 노출 위반이 77%를 넘겼다. 편의를 위해 기억을 켜는 순간, 그 기억이 새어 나갈 통로도 함께 열린다.

메모리 도입 전 36~47% 메모리 도입 후 63~90% 전체 노출(visibility) 위반율. 위반이 메모리 채널로 이동. 출처: PiSAs (arXiv:2607.05318)

막대는 다중 사용자 시스템에서 권한 없는 상대에게 정보가 전달된 비율. 메모리는 편의의 기능인 동시에 노출의 표면이다.

두 벤치마크가 함께 가리키는 결론은 단순하다. 다중 사용자 시스템에서 기억은 새고, 그 유출은 삭제 불성립과 한 뿌리에서 자란다. 누구 것인지 표시되지 않은 기억은 감사에서도 새고, 삭제 요청에서도 빠져나간다. 표시의 부재가 두 문제를 동시에 만든다.

5

지울 수 있는 기억을 설계하다

문제를 진단했으니 자연스러운 물음은 하나다. 그러면 프롬프트로 "민감한 정보는 저장하지 마"라고 지시하면 되지 않을까? 실측은 그 기대를 절반만 채워 준다. PiSAs에서 프롬프트 수준의 방어는 정보 수집 단계나 에이전트 간 통신 채널에서는 위반을 최대 50%까지 줄였지만, 메모리 채널에서는 28~29%밖에 줄이지 못했다. 메모리는 프롬프트로 가장 막기 어려운 면이다. 사후에 말로 붙이는 지시로는 이미 쓰인 기억을 지우지 못한다. 통제는 쓰기 시점의 설계로만 성립한다.

Astraea가 제시하는 해법은 삭제 버튼을 정교하게 만드는 쪽이 아니라, 기록하는 순간의 구조를 바꾸는 쪽이다. 세 층으로 이뤄진다. 첫째, 쓰기 래퍼 — 에이전트가 메모리를 저장할 때마다 그 기록이 누구의 것인지 사용자 식별자를 함께 붙인다. 이것이 이름표, 곧 쓰기 시점 프로버넌스다. 둘째, 외부 인덱스 — 사용자와 그에게 속한 메모리 파일의 매핑을 저장소 바깥에 따로 유지한다. 셋째, 프로그래매틱 삭제 API — 삭제 요청이 오면 이 인덱스를 타고 해당 사용자의 원본 기록에 정확히 닿아 지운다. 세 층이 갖춰져야 "지워 달라"가 비로소 실행 가능한 명령이 된다.

1 쓰기 래퍼 저장마다 사용자 식별자를 태깅 2 외부 인덱스 사용자–파일 매핑을 저장소 밖에 유지 3 삭제 API 인덱스를 타고 원본을 지운다 "나를 지워 달라" 요청은 ③에서 ②를 조회해 ①이 남긴 이름표를 따라 원본에 닿는다 세 층 중 하나라도 빠지면 삭제 요청은 대상에 닿지 못한다. 출처: Astraea

삭제 가능성은 삭제 기능이 아니라 기록 구조에서 나온다. 이름표(①)가 없으면 인덱스(②)도 삭제 경로(③)도 세울 수 없다.

설계로 위험을 줄일 수 있다는 것은 추정이 아니라 측정된 사실이다. AgentLeak 연구진이 만든 시제품 정화 인터셉터는 내부 채널로 새는 정보를 31.5%에서 2.4%로 낮췄다. 대가로 과업 성공률이 4.7%포인트 떨어졌으니 공짜는 아니지만, 방향은 분명하다. 유출도 삭제도, 쓰기와 전달의 길목에 설계로 개입할 때 통제된다. 사후의 감사나 프롬프트가 아니라 구조가 답이다.

엔지니어링 설계가 곧 컴플라이언스다

이 설계는 선택적 미덕이 아니라 다가오는 규제의 이행 수단이다. 규제는 하나같이 "개인정보가 어디서 와서 어떻게 쓰였는지"를 추적할 수 있어야 성립하는 의무를 부과한다. 캘리포니아의 자동화 의사결정 기술(ADMT) 규정은 금융·주거·고용·의료 같은 중대한 결정에 자동화 시스템을 쓰는 사업자에게 위험평가·사전 고지·옵트아웃·소비자 접근권을 요구하며, 핵심 준수 기한은 2027년 1월 1일이다. GDPR의 잊힐 권리는 위반 시 최고 티어 과징금(전 세계 매출 4% 또는 2천만 유로 중 큰 쪽)을 매긴다. 한국 개인정보보호법은 2024년 3월 15일부터 완전 자동화된 결정에 대한 설명 요구권과 거부권을 보장한다. 유럽연합의 AI Act는 고위험 시스템 의무의 원래 적용일이 2026년 8월 2일이었으나, Digital Omnibus 논의로 2027년 12월 2일 연기가 추진되는 등 시점이 아직 유동적이다.

공통점은 분명하다. 자동화된 결정을 설명하고, 거부하고, 삭제하려면 그 결정에 쓰인 개인정보의 출처를 추적할 수 있어야 한다. 쓰기 시점 프로버넌스가 없으면 이 의무들은 기술적으로 이행 불가능하다. 곧 이름표를 남기는 엔지니어링 설계가 컴플라이언스의 전제 조건이다. 삭제 가능성은 사후에 붙이는 기능이 아니라, 기록하는 순간에 심는 구조다.

6

페블러스가 주목하는 이유

여기까지 오면 하나의 원리가 세 계층에서 같은 모양으로 반복된다는 것이 보인다. 페블러스의 DataClinic은 학습 데이터의 계보와 품질을 진단하는 도구다. 지금까지 데이터 품질은 주로 "무엇을 넣을 때"의 문제였다 — 정확한가, 편향되지 않았는가, 출처가 분명한가. 이 보고서가 짝 시리즈와 함께 보여주는 것은, 품질이 "무엇을 뺄 수 있는가"의 문제이기도 하다는 점이다. 계보와 삭제 가능성은 같은 동전의 양면이다. 어느 데이터가 누구에게서 왔는지 알아야 그 사람 몫만 지울 수 있고, 지울 수 있어야 규제와 신뢰의 요구에 응답할 수 있다.

그 원리를 계층별로 나란히 두면 이렇다. 학습 데이터에서는 토큰 단위 출처 추적이 과잉삭제를 101배에서 1.3배로 줄였다. 모델 내부 표현에서는 가중치 속 사실을 고쳐 쓰는 모델 에디팅(ROME·MEMIT 계열)이 시도되지만, 그것은 특정 사실을 바꿀 뿐 "이 지식이 누구에게서 왔는가"라는 출처 문제를 풀지 못한다. 그리고 런타임 메모리에서는 쓰기 시점 태깅이 삭제를 비로소 성립하게 한다. 계층마다 기법은 다르지만 조건은 같다. 프로버넌스가 없는 데이터는 학습이든, 모델 내부든, 런타임이든 어느 층에서도 정밀하게 지울 수 없다.

메모리 기능을 제품에 넣으려는 조직 입장에서 이 보고서가 실무적으로 남기는 것은 하나의 체크리스트다. 삭제 요청을 이행 가능하게 만들려면 쓰기 래퍼·외부 인덱스·삭제 API 세 층이 있는가. 이는 "AI-Ready Data"라는 개념이 학습 이전의 데이터에서 에이전트 운영 계층으로 확장되는 지점이자, 데이터 품질 담론이 "AI-Ready Compliance"로 넓어지는 지점이다. 법률 매체는 이 문제를 자문의 언어로, 학술 벤치마크는 측정의 언어로 다룬다. 데이터 거버넌스의 언어로 옮겨, 학습 데이터 삭제와 런타임 메모리 삭제를 하나의 연속선으로 잇는 자리가 페블러스가 서 있는 곳이다.

AI가 나를 기억하기 시작한 시대에, "지워 달라"가 기술적으로 성립하려면 기억이 쌓이는 매 순간 그것이 누구의 것인지 이름표가 붙어야 한다. 이름표는 사후에 붙일 수 없다. 그러니 다음에 어떤 메모리 기능을 켜든, 물어야 할 질문은 하나다 — 이 기억에는 이름표가 있는가. 없다면, 언젠가 지워 달라는 요청이 왔을 때 우리는 그 요청에 답할 방법을 처음부터 갖고 있지 않은 셈이다.

이 보고서는 페블러스 데이터 커뮤니케이션팀이 공개 자료와 학술 문헌을 바탕으로 작성한 관점 정리입니다. 본문의 수치는 출처를 명시한 벤치마크와 규제 문서, 그리고 페블러스의 선행 아티클에서 인용했으며, 규제 시행일 등 일부 항목은 2026년 7월 기준으로 이후 변동될 수 있습니다.

R

참고문헌

학술 · 벤치마크

정책 · 통계

페블러스 선행 아티클