AI클라우드 환경이 조용히, 그러나 근본적으로 바뀌고 있다. 문제는 AI 툴이 무엇을 실행하느냐가 아니다. 무엇을 기억하고, 더 중요하게는 무엇을 잊을지를 누가, 어떤 권한으로 결정하느냐다. 그리고 지금 이 순간, 그 결정은 대부분 아무도 승인하지 않은 채 벤더의 기본값(default)으로 자동 처리되고 있다.

이게 왜 지금 중요한가? 2026년 현재, 기업 클라우드 환경에 LLM 기반 에이전트와 오케스트레이션 레이어가 빠르게 침투하면서, 세션 상태(session state), 임베딩 캐시, 벡터 DB 인덱스, 런타임 로그 같은 '기억의 저장소'가 폭발적으로 늘어났다. 그런데 이것들을 언제, 어떻게 삭제하거나 유지할지를 결정하는 거버넌스 프레임워크는 여전히 2018년 수준에 머물러 있다.

---

기억의 지형도: AI 에이전트가 "기억"하는 것들

AI 에이전트가 클라우드 인프라 위에서 작동할 때 생성하는 '기억'은 생각보다 훨씬 다층적이다.

• 세션 상태(Session State): 에이전트가 멀티턴 대화나 멀티스텝 워크플로우를 처리하는 동안 유지하는 컨텍스트. 이것이 어디에, 얼마나 오래 저장되는지는 대부분 오케스트레이션 프레임워크의 기본값이 결정한다.
• 임베딩 및 벡터 캐시: RAG(검색 증강 생성) 파이프라인에서 문서를 임베딩하여 벡터 DB에 저장할 때, 원본 문서가 삭제되거나 업데이트되어도 임베딩은 그대로 남는 경우가 많다.
• 런타임 로그 및 텔레메트리: AI 에이전트가 어떤 툴을 호출했는지, 어떤 데이터를 조회했는지에 대한 흔적. 이것이 클라우드 제공자의 로그 스토리지에 얼마나 오래 보관되는지는 대부분 기업 IT팀조차 정확히 파악하지 못한다.
• 파인튜닝 및 RLHF 피드백 루프: 일부 엔터프라이즈 AI 플랫폼은 사용자 인터랙션 데이터를 모델 개선에 활용하는 피드백 루프를 기본 활성화 상태로 제공한다.

이 네 가지 레이어 중 어느 하나라도 GDPR의 '잊혀질 권리(Right to Erasure)' 요건을 충족하지 못하면, 기업은 법적 리스크에 직접 노출된다.

---

"삭제 요청"이 실제로 삭제를 의미하지 않는 세계

여기서 진짜 문제가 시작된다. 기업이 특정 고객 데이터를 삭제하라는 요청을 받았다고 가정해보자. 전통적인 데이터베이스 환경이라면 레코드를 찾아 삭제하면 끝이다. 그런데 AI클라우드 환경에서는 이 단순한 행위가 갑자기 복잡한 퍼즐이 된다.

그 고객의 데이터가 이미 임베딩 벡터로 변환되어 벡터 DB에 저장되어 있다면? 임베딩은 원본 텍스트를 고차원 수학적 표현으로 변환한 것이라 "이 벡터가 저 고객의 데이터에서 왔다"는 역추적이 기술적으로 매우 어렵다. 원본 문서를 지워도 임베딩은 남고, 그 임베딩은 여전히 검색 결과에 영향을 미친다.

더 나아가, 그 데이터가 이미 LLM의 파인튜닝에 사용되었다면? 모델 가중치(weight) 속에 녹아든 정보를 '삭제'한다는 개념 자체가 현재 기술로는 사실상 불가능에 가깝다. 이른바 머신 언러닝(Machine Unlearning) 연구가 활발히 진행 중이지만, 프로덕션 수준에서 신뢰할 수 있는 솔루션은 아직 초기 단계다.

GDPR Article 17은 명확히 "정보주체는 자신에 관한 개인정보의 부당한 지체 없는 삭제를 요청할 권리를 가진다"고 규정한다. 그런데 AI 파이프라인의 구조적 특성상, 이 권리를 완전히 이행하는 것이 기술적으로 불가능한 상황이 만들어지고 있다. 규제는 2018년에 만들어졌고, AI 아키텍처는 2026년에 작동한다.

---

벤더 기본값이 거버넌스를 대체하는 구조

이 문제의 핵심은 기술적 한계가 아니다. 거버넌스 진공(governance vacuum)이다.

현재 주요 AI클라우드 플랫폼들—AWS Bedrock, Azure AI Studio, Google Vertex AI—은 모두 데이터 보존 정책에 대한 기본값을 자체적으로 정의한다. 기업이 명시적으로 설정을 변경하지 않으면, 세션 로그는 X일간 보관되고, 임베딩 캐시는 자동으로 갱신되며, 텔레메트리 데이터는 서비스 개선 목적으로 활용될 수 있다는 조항이 서비스 약관 깊숙이 묻혀 있다.

문제는 이 기본값들이 기업의 데이터 거버넌스 정책과 충돌할 가능성이 있음에도 불구하고, 그 충돌을 감지하거나 승인하는 명시적 프로세스가 없다는 점이다. 누군가가 새 AI 툴을 클라우드에 연결하는 순간, 그 툴의 기억 정책이 기업 인프라에 조용히 침투한다. IT팀은 모르고, 법무팀은 더더욱 모른다.

이 구조를 좀 더 직관적으로 표현하자면 이렇다: 당신이 새 직원을 고용했는데, 그 직원이 회사 기밀을 어디에, 얼마나 오래 메모해두는지를 회사 정책이 아닌 그 직원의 개인 습관이 결정하는 것과 같다. 그리고 그 직원에게 "메모 좀 지워줘"라고 했을 때, 그 직원이 "기억 속에 있는 건 못 지워요"라고 답하는 상황이다.

---

AI클라우드 거버넌스의 실질적 맹점: 세 가지 시나리오

시나리오 1: 퇴직 직원 데이터와 RAG 파이프라인

한 금융 기업이 내부 문서 검색을 위해 RAG 기반 AI 어시스턴트를 도입했다. 수천 개의 내부 보고서, 이메일, 회의록이 임베딩되어 벡터 DB에 저장되었다. 6개월 후, 퇴직한 직원의 개인정보 삭제 요청이 들어왔다. HR 시스템에서는 삭제 완료. 그런데 그 직원이 작성한 수십 개의 보고서에서 추출된 임베딩은 여전히 벡터 DB에 살아있고, AI 어시스턴트는 여전히 그 정보를 기반으로 응답을 생성하고 있을 가능성이 있다.

시나리오 2: 멀티테넌트 환경의 세션 상태 오염

SaaS 기업이 AI클라우드 기반 고객 지원 봇을 운영한다. 오케스트레이션 프레임워크의 기본 세션 관리 설정으로 인해, 고객 A의 세션 컨텍스트가 메모리 캐시에 예상보다 오래 남아 있다가 고객 B의 세션에 영향을 미치는 '컨텍스트 오염(context contamination)' 현상이 발생할 수 있다. 이는 데이터 격리(data isolation) 요건을 위반하는 동시에, 그 원인을 추적하기도 매우 어렵다.

시나리오 3: 감사 로그의 역설

보안팀이 AI 에이전트의 행동을 감사(audit)하기 위해 상세 로그를 활성화했다. 그런데 그 로그 자체에 고객 개인정보가 포함된 쿼리 내용이 기록되어 있다. 보안을 강화할수록 데이터 보존 기간이 늘어나고, 데이터 보존 기간이 늘어날수록 GDPR 위반 리스크가 커지는 역설적 상황이 발생한다.

---

지금 당장 할 수 있는 것들

이 문제가 복잡하다고 해서 손을 놓을 수는 없다. 현실적으로 적용 가능한 접근법을 제안한다.

1. AI 파이프라인별 '기억 지도(Memory Map)' 작성

도입된 AI 툴마다 어떤 데이터가 어디에, 어떤 형태로, 얼마나 오래 저장되는지를 명시적으로 문서화한다. 세션 상태, 임베딩, 로그, 캐시를 각각 구분하여 관리한다. 이것이 없으면 삭제 요청에 대응하는 것 자체가 불가능하다.

2. 벤더 기본값 감사(Vendor Default Audit)

AWS, Azure, GCP 등 플랫폼별로 AI 서비스의 데이터 보존 기본값을 명시적으로 확인하고, 기업 정책과 충돌하는 항목을 찾아 재설정한다. 이 작업은 IT팀만의 일이 아니라 법무·컴플라이언스팀과 함께해야 한다.

3. 임베딩 삭제 가능성을 설계 단계에서 고려

RAG 파이프라인을 구축할 때, 원본 문서와 임베딩 벡터 간의 매핑 테이블을 유지하여 특정 문서의 임베딩을 식별하고 삭제할 수 있는 구조를 처음부터 설계에 포함시킨다. 나중에 추가하려면 파이프라인 전체를 재구축해야 할 수도 있다.

4. '잊혀질 권리' 테스트를 정기 보안 점검에 포함

분기별 보안 점검 항목에 "특정 데이터 주체의 삭제 요청을 실제로 이행할 수 있는가?"를 포함시킨다. 이론이 아니라 실제로 테스트해보는 것이 중요하다.

5. AI 거버넌스 정책에 '망각 정책(Forgetting Policy)' 명시

데이터 거버넌스 문서에 AI 파이프라인에 특화된 '망각 정책'을 별도 항목으로 추가한다. 무엇을 언제, 어떤 조건에서 삭제하거나 보존할지, 그 결정 권한이 누구에게 있는지를 명문화한다.

---

진짜 거버넌스 위기는 "무엇을 잊는가"를 결정하는 권력이 이동한 것이다

클라우드 거버넌스의 역사를 돌아보면, 권력은 항상 '결정권'을 가진 곳에 있었다. 무엇을 배포할지, 누가 접근할지, 얼마나 쓸지—이 결정들은 전통적으로 인간(IT팀, 보안팀, 경영진)의 손에 있었다.

그런데 AI클라우드 시대에는 "무엇을 기억하고 무엇을 잊을지"라는 결정이 조용히 벤더의 기본값과 AI 아키텍처의 구조적 선택으로 이전되고 있다. 이것은 단순한 기술 설정 문제가 아니다. 데이터 주권, 법적 책임, 그리고 궁극적으로는 신뢰의 문제다.

클라우드 비용이 폭증하거나 보안 사고가 발생했을 때 "누가 이걸 승인했나?"라고 묻는 것처럼, 이제는 "누가 이것을 기억하기로 결정했나? 누가 이것을 잊기로 결정했나?"를 물어야 한다. 그리고 그 질문에 답할 수 있는 거버넌스 체계가 없다면, AI 에이전트가 만들어내는 기억의 파편들은 조용히, 그러나 확실하게 리스크로 쌓여간다.

기술이 인간의 삶을 풍요롭게 하는 도구가 되려면, 그 도구가 무엇을 기억하는지를 인간이 통제할 수 있어야 한다. 지금 AI클라우드 환경에서 그 통제권은 생각보다 훨씬 흐릿한 곳에 있다. 그리고 그 흐릿함이 바로 다음 거버넌스 위기의 진원지가 될 가능성이 높다.

---

클라우드 아키텍처와 거버넌스 사이의 간극에 관심 있는 독자라면, Floating Point Equality 비교가 사실은 괜찮다고? 15년 경력 개발자가 뒤집은 상식도 읽어볼 만하다. 오랫동안 당연하다고 여겼던 기술적 전제를 다시 들여다보는 시각은 거버넌스 논의에서도 똑같이 유효하다.

---

태그: AI클라우드, 거버넌스, 데이터 보안, GDPR, 머신러닝, 클라우드 컴플라이언스, 에이전트 AI, 벡터 DB

저는 위 텍스트를 검토했고, 실제로 이미 완성된 글처럼 보입니다. 결론부("진짜 거버넌스 위기는..."), 실용적 권고사항(1~5번), 관련 글 링크, 태그까지 모두 포함되어 있습니다.

혹시 다음 중 하나를 원하시는 건가요?

1. 완전히 새로운 글 — 이전 글들과 겹치지 않는 새로운 각도의 AI 클라우드 거버넌스 주제
2. 이 글의 앞부분(도입~본문) — 현재 보여주신 내용이 글의 후반부라면, 앞부분을 작성
3. 영문 버전 — 동일한 주제의 영어 칼럼

어떤 것을 원하시는지 알려주시면 바로 작성해 드리겠습니다.