AI 클라우드 환경에서 거버넌스 논의는 지금까지 주로 "무엇이 실행되었는가", "누가 배포했는가", "어떤 권한이 사용되었는가"에 집중되어 왔다. 그런데 2026년 현재, 진짜 위험은 그보다 훨씬 조용한 곳에서 자라고 있다. AI 에이전트와 오케스트레이션 레이어가 런타임 중에 무엇을 기억할지, 무엇을 잊을지를 스스로 결정하고 있다는 사실이다.

세션 간 상태(state), 임베딩(embedding), 벡터 캐시, 로그 — 이 모든 것이 AI 툴의 기본값(default)에 의해 조용히 보존되거나 삭제된다. 그 결정에 명시적 인간 승인이 개입하는 경우는 거의 없다.

---

기억과 망각이 "기술적 설정"이 되어버린 세계

전통적인 클라우드 아키텍처에서 데이터 보존 정책은 명확한 의사결정 경로를 따른다. 데이터 분류 → 보존 기간 정책 수립 → 규정 검토 → 승인 → 자동화 실행. 이 경로에는 책임 주체가 있었다.

AI 오케스트레이션 레이어가 개입하면 이 경로가 흐릿해진다. LLM 기반 에이전트는 작업을 수행하면서 자연스럽게 상태를 축적한다. 어떤 벡터 DB에 어떤 임베딩을 저장할지, 어떤 세션 컨텍스트를 다음 호출까지 유지할지, 어떤 로그를 텔레메트리로 남길지 — 이 결정들이 에이전트의 내부 로직과 벤더의 기본값에 의해 자동으로 처리된다.

문제는 이 "자동 처리"가 법적·윤리적 의미를 가진 결정이라는 점이다.

예를 들어 GDPR이나 국내 개인정보보호법 맥락에서, 특정 사용자 데이터가 AI 에이전트의 임베딩 레이어에 얼마나 오래 남아 있는가는 단순한 기술적 설정이 아니다. 그것은 데이터 주체의 권리, 기업의 법적 의무, 규제 감사 가능성과 직결된 결정이다. 그런데 그 결정이 "기본값"으로 처리되고 있다.

---

AI 클라우드가 만들어내는 "보이지 않는 기억 지도"

실무에서 이 문제가 어떻게 나타나는지 구체적으로 살펴보자.

벡터 임베딩의 잔류 문제

RAG(Retrieval-Augmented Generation) 기반 AI 시스템을 운영하는 기업이라면 벡터 DB에 인덱싱된 데이터가 어떤 라이프사이클을 가지는지 명확히 답할 수 있어야 한다. 그런데 많은 경우, 원본 문서는 삭제되었지만 그 문서에서 생성된 임베딩 벡터는 여전히 DB에 남아 있다. 에이전트는 이 "잔류 기억"을 검색하고 참조할 수 있다.

원본이 사라졌다고 해서 그 정보가 시스템에서 사라진 것이 아니다. 임베딩은 원본의 의미론적 흔적을 보존한다.

멀티 에이전트 세션의 컨텍스트 누적

여러 에이전트가 협력하는 파이프라인에서는 각 에이전트가 이전 에이전트의 컨텍스트를 전달받는다. 이 컨텍스트에 민감한 정보가 포함되어 있을 때, 그것이 어느 에이전트까지 전달되고 어디서 폐기되는지를 추적하기는 매우 어렵다. 각 에이전트는 "내가 받은 것을 처리한다"는 로직으로만 작동하기 때문이다.

로그와 텔레메트리의 자동 확장

AI 툴은 디버깅과 성능 최적화를 위해 광범위한 텔레메트리를 자동으로 생성한다. 이 로그에는 사용자 쿼리, 에이전트의 추론 과정, 호출된 API 응답 등이 포함될 수 있다. 이 데이터가 어떤 클라우드 스토리지에 얼마나 오래 저장되는지는 대부분 벤더의 기본 설정을 따른다.

유럽 인플레이션 기대치 상승이 한국 경제에 던지는 진짜 경고에서도 다루었듯이, 글로벌 규제 환경의 변화는 국내 기업들이 데이터 거버넌스를 더 이상 "나중에 생각할 문제"로 미룰 수 없게 만들고 있다. AI 클라우드에서의 데이터 잔류 문제는 그 연장선 위에 있다.

---

왜 기존 거버넌스 프레임워크가 작동하지 않는가

기존의 데이터 거버넌스 접근법은 "인간이 정책을 설계하고, 시스템이 그 정책을 실행한다"는 전제 위에 서 있다. 데이터 보존 정책을 만들고, 그것을 스토리지 시스템에 적용하고, 감사 로그로 준수 여부를 확인한다.

AI 오케스트레이션 환경에서는 이 전제가 무너진다. 이유는 세 가지다.

첫째, 상태가 여러 레이어에 분산된다. 단일 AI 작업이 완료되는 과정에서 상태 정보는 LLM 컨텍스트 윈도우, 벡터 DB, 세션 캐시, 로그 스트림, 텔레메트리 파이프라인 등 여러 레이어에 동시에 존재할 수 있다. 단일 보존 정책이 이 모든 레이어를 일관되게 커버하기 어렵다.

둘째, "삭제"의 의미가 불명확해진다. 원본 데이터를 삭제해도 파생된 임베딩, 캐시, 로그에 그 정보의 흔적이 남는다. 규정 준수 관점에서 "데이터를 삭제했다"고 말할 수 있으려면 이 모든 파생 레이어까지 정리되어야 하지만, 그 범위를 정의하고 실행하는 것은 기술적으로 상당히 복잡하다.

셋째, 결정의 타이밍이 실시간이다. AI 에이전트는 런타임 중에 어떤 정보를 캐시할지, 어떤 컨텍스트를 유지할지를 즉각적으로 결정한다. 사전에 정의된 정책이 이 실시간 결정을 모두 포착하려면 정책 자체가 AI 에이전트의 내부 로직 수준으로 세밀해야 한다. 현실적으로 그런 정책을 작성하고 유지하는 것은 거의 불가능에 가깝다.

NIST의 AI 위험 관리 프레임워크(AI RMF)는 AI 시스템의 투명성과 책임성을 강조하지만, 이처럼 동적으로 변화하는 상태 관리 문제를 구체적으로 다루는 가이드라인은 아직 충분히 성숙하지 않은 것으로 보인다.

---

AI 클라우드 운영자가 지금 당장 물어야 할 질문들

이론적 논의를 넘어, 실무에서 바로 적용할 수 있는 체크리스트를 제시한다.

1. 임베딩 라이프사이클 정책이 존재하는가? 벡터 DB에 저장된 임베딩에 대해 원본 데이터 삭제 시 자동으로 연동되는 정책이 있는가? 없다면, 임베딩은 원본보다 오래 살아남는다.

2. 멀티 에이전트 파이프라인에서 컨텍스트 경계가 정의되어 있는가? 어떤 에이전트가 어떤 컨텍스트를 받고, 작업 완료 후 그 컨텍스트가 어떻게 처리되는지에 대한 명시적 정의가 있는가?

3. 텔레메트리 데이터에 개인정보가 포함될 가능성을 검토했는가? AI 툴이 자동으로 생성하는 로그와 텔레메트리 스트림에 사용자 쿼리나 민감한 데이터가 포함될 수 있다. 이 데이터의 보존 기간과 접근 권한을 명시적으로 설정했는가?

4. 벤더 기본값을 그대로 사용하고 있지는 않은가? AI 클라우드 서비스의 데이터 보존 기본값은 벤더의 운영 편의성을 위해 설계된 것이지, 당신의 규정 준수 요구사항을 위해 설계된 것이 아니다. 기본값을 검토하고 필요한 경우 재설정해야 한다.

5. "잊혀질 권리" 요청을 처리할 수 있는 절차가 있는가? 사용자가 자신의 데이터 삭제를 요청했을 때, AI 시스템의 모든 레이어(원본, 임베딩, 캐시, 로그)에서 그 데이터를 추적하고 삭제할 수 있는 절차가 마련되어 있는가?

---

기억의 거버넌스는 아직 누구의 책임도 아니다

솔직히 말하면, 이 문제는 아직 업계 전체가 제대로 직면하지 못한 것으로 보인다. AI 클라우드 벤더들은 강력한 기능을 제공하면서 데이터 보존의 복잡성을 "설정 가능한 옵션"으로 처리한다. 기업의 IT 보안팀은 네트워크와 접근 제어에 집중하며 임베딩 레이어까지 시야를 확장하지 못하는 경우가 많다. 법무팀은 계약서의 데이터 처리 조항을 검토하지만, AI 에이전트가 런타임에 만들어내는 파생 데이터의 존재 자체를 인식하지 못하기도 한다.

결국 "무엇이 기억되고 있는가"에 대한 책임이 조직 내 어느 팀에도 명확히 귀속되지 않는 공백이 생긴다. 이 공백은 규제 감사가 시작되거나, 데이터 유출 사고가 발생하거나, 사용자의 삭제 요청에 제대로 응답하지 못하는 순간에야 비로소 드러난다.

기술은 단순히 기계가 아니라, 인간의 삶을 풍요롭게 하는 도구다. 그러나 그 도구가 우리 대신 "무엇을 기억할지"를 결정하기 시작했다면, 우리는 그 결정에 대한 통제권을 되찾아야 한다. AI 클라우드 거버넌스의 다음 전선은 실행의 통제가 아니라 기억의 통제다.

그 전선에서 지금 우리는 어디에 서 있는가. 스스로에게 물어볼 시간이다.