AI 클라우드, 이제 "무엇을 실행하는가"보다 "무엇을 기억하는가"가 더 위험하다

AI 클라우드 환경에서 조용히 진행되고 있는 변화가 있다. 기업들이 AI 도구를 도입하면서 가장 먼저 묻는 질문은 "이 도구가 무엇을 할 수 있는가"였다. 그런데 2026년 현재, 진짜 위험한 질문은 따로 있다. "이 도구가 무엇을 기억하고 있는가."

단순 실행(execution)은 눈에 보인다. 로그가 찍히고, 비용이 발생하고, 결과가 나온다. 하지만 AI 도구가 컨텍스트를 유지하고, 이전 상태를 참조하고, 다음 결정을 위해 데이터를 보존하는 순간—이 모든 것은 어떤 승인 프로세스도 없이 클라우드 인프라 깊숙이 자리를 잡는다. 그리고 그 자리는 생각보다 훨씬 오래, 훨씬 넓게 유지된다.

AI 클라우드에서 "상태(State)"가 새로운 위험 요소가 된 이유

전통적인 클라우드 워크로드는 비교적 단순한 생애 주기를 가졌다. 요청이 들어오고, 처리되고, 결과가 반환되면 끝이었다. 물론 데이터베이스나 스토리지는 남지만, 그것은 명시적으로 설계된 영속성이었다. 누군가가 "이 데이터를 저장하겠다"는 결정을 내렸고, 그 결정에는 소유자가 있었다.

AI 에이전트와 LLM 기반 도구가 클라우드에 통합되면서 이 구도가 무너지기 시작했다. 현재 엔터프라이즈 환경에서 흔히 볼 수 있는 AI 워크플로우를 하나 떠올려보자.

직원 A가 AI 코파일럿에게 "지난 분기 영업 데이터를 분석해줘"라고 요청한다.
에이전트는 이 요청을 처리하기 위해 벡터 DB에서 관련 문서를 검색하고, 외부 API를 호출하고, 중간 추론 결과를 임시 스토리지에 저장한다.
직원 A는 답변을 받고 창을 닫는다.

여기서 문제가 시작된다. 3번 단계에서 직원 A의 세션은 종료됐지만, 2번 단계에서 생성된 컨텍스트 데이터—검색 인덱스, 임시 임베딩, 세션 메모리—는 여전히 클라우드 어딘가에 살아있다. 이것이 "기억하는 인프라(remembering infrastructure)" 문제다.

컨텍스트 윈도우가 스토리지 청구서로 변환되는 과정

많은 엔지니어링 팀이 간과하는 사실이 있다. LLM의 컨텍스트 윈도우는 처리 비용만 발생시키는 게 아니다. 에이전트가 장기 메모리(long-term memory)를 구현하는 방식—RAG(Retrieval-Augmented Generation), 벡터 스토어, 세션 캐시—은 모두 클라우드 스토리지와 연산 자원을 지속적으로 소비한다.

실제로 AWS, Azure, GCP 모두 AI 워크로드용 벡터 데이터베이스 서비스(Pinecone, Weaviate, pgvector 등과의 통합 포함)를 제공하고 있으며, 이 서비스들은 데이터가 쿼리되지 않는 동안에도 스토리지 비용이 청구된다. 에이전트가 "나중에 참고할 수도 있으니" 보존해둔 임베딩 데이터가 수개월째 과금되고 있어도, 이를 인지하는 팀은 드물다.

더 교묘한 문제는 컨텍스트의 연쇄(context chaining)다. 에이전트 A의 출력이 에이전트 B의 입력이 되고, B의 출력이 다시 C의 컨텍스트로 들어가는 멀티 에이전트 파이프라인에서는, 각 단계의 중간 상태가 모두 어딘가에 저장된다. 이 저장 위치를 명시적으로 설계한 사람이 없을 경우—그리고 대부분의 경우 없다—기본 설정(default configuration)이 결정을 대신한다. 기본 설정은 대개 "삭제하지 않는" 방향으로 설정되어 있다.

diagram

Photo by kenny cheng on Unsplash

"삭제 정책"이 없는 AI 클라우드 인프라의 실제 위험

이 지점에서 단순한 비용 문제를 넘어 보안과 컴플라이언스 문제로 진입한다.

2026년 현재 GDPR, 국내 개인정보보호법, 그리고 각종 산업별 규제는 "데이터 보존 기간"을 명시적으로 요구한다. 그런데 AI 에이전트가 자율적으로 생성한 임베딩 데이터, 세션 컨텍스트, 추론 중간 결과물에 대해 누가 보존 정책을 정의했는가? 대부분의 경우 아무도 정의하지 않았다.

법무팀은 공식 데이터베이스의 보존 정책을 알고 있다. IT 팀은 공식 스토리지 버킷의 라이프사이클 정책을 관리한다. 하지만 AI 코파일럿이 지난 6개월간 생성한 세션 메모리 데이터가 어느 클라우드 리전의 어느 벡터 스토어에 있는지 아는 사람은—솔직히 말하면—거의 없다.

이것은 단순한 기술적 부주의가 아니다. 거버넌스 설계 자체가 AI의 상태 관리를 전제하지 않고 만들어졌기 때문이다. 기존의 데이터 거버넌스 프레임워크는 "사람이 명시적으로 저장하는 데이터"를 기준으로 설계됐다. AI 에이전트가 추론 과정에서 암묵적으로 생성하고 보존하는 데이터는 그 어떤 분류 체계에도 깔끔하게 들어맞지 않는다.

AI 클라우드 거버넌스의 새로운 단위: "결정"이 아닌 "기억"

지금까지 AI 클라우드 거버넌스 논의는 주로 결정(decision)을 중심으로 이루어졌다. 에이전트가 어떤 API를 호출할 수 있는가, 어떤 데이터에 접근할 수 있는가, 어떤 액션을 자율적으로 취할 수 있는가. 이것은 중요한 질문이지만, 불완전한 질문이다.

진짜 거버넌스 공백은 기억(memory)에 있다. 에이전트가 무엇을 기억하도록 허용되는가, 그 기억은 얼마나 오래 유지되는가, 누가 그 기억을 감사(audit)할 수 있는가, 그리고 누가 그 기억을 삭제할 권한을 가지는가.

흥미롭게도, 이 문제는 AI와 무관한 영역에서도 유사한 패턴으로 등장한 적이 있다. AI 피부암 예측이 의료비 구조를 바꾼다: 600만 명 데이터가 증명한 것에서 다루었듯, AI가 대규모 데이터를 처리하고 판단을 내리는 과정에서 "누가 이 데이터의 책임자인가"라는 질문은 기술 영역을 넘어 제도적 설계의 문제가 된다. AI 클라우드 인프라에서의 상태 관리도 정확히 같은 구조적 질문에 직면해 있다.

실무에서 바로 적용할 수 있는 세 가지 접근

이 문제를 인식했다면, 다음 단계는 실제로 무엇을 할 수 있는가다. 완벽한 해법은 없지만, 지금 당장 시작할 수 있는 접근이 있다.

1. AI 워크로드 전용 "메모리 감사(Memory Audit)" 도입

기존 클라우드 비용 감사와 별개로, AI 에이전트가 생성하는 상태 데이터를 추적하는 별도 프로세스가 필요하다. 구체적으로는 다음을 포함해야 한다:

벡터 스토어 인벤토리: 현재 운영 중인 모든 벡터 데이터베이스와 임베딩 스토어 목록화
세션 컨텍스트 TTL(Time-To-Live) 정책: 에이전트 세션이 종료된 후 컨텍스트 데이터가 자동 삭제되는 기간 명시
소유자 태깅(Owner Tagging): 모든 AI 생성 데이터 리소스에 생성 에이전트, 담당 팀, 생성 목적을 태그로 부착

NIST의 AI 리스크 관리 프레임워크(AI RMF)는 AI 시스템의 투명성과 책임 추적 가능성을 핵심 원칙으로 제시하고 있다. 이 원칙을 "기억하는 인프라"에 적용하는 것이 바로 메모리 감사의 출발점이다.

2. 기본값(Default)을 "삭제"로 재설정

현재 대부분의 AI 클라우드 서비스는 기본값이 "보존"이다. 이것을 뒤집어야 한다. 명시적으로 "이 데이터는 X일간 보존한다"고 설정하지 않은 AI 생성 상태 데이터는 자동으로 삭제되도록 기본 정책을 변경하는 것이 실용적이다.

이는 기술적으로 어렵지 않다. AWS S3의 라이프사이클 정책, Azure Blob Storage의 보존 정책, GCP의 데이터 보존 규칙 모두 이를 지원한다. 문제는 기술이 아니라 "이 설정을 누가 담당하는가"에 대한 합의가 없다는 것이다. AI 도구를 도입한 팀이 담당하는가, IT 인프라 팀이 담당하는가, 아니면 데이터 거버넌스 팀이 담당하는가. 이 질문에 먼저 답해야 한다.

3. "에이전트 메모리 경계(Agent Memory Boundary)" 문서화

새로운 AI 에이전트를 클라우드에 배포할 때, 기능 명세서와 함께 메모리 경계 문서를 작성하는 것을 표준 프로세스로 만들어야 한다. 이 문서에는 다음이 포함되어야 한다:

에이전트가 생성하는 상태 데이터의 종류와 위치
각 데이터 유형의 최대 보존 기간
민감 데이터 포함 여부 및 암호화 정책
감사 및 삭제 권한을 가진 담당자

이것은 거창한 작업이 아니다. 처음에는 한 페이지짜리 체크리스트로 시작해도 충분하다. 핵심은 "이 에이전트는 무엇을 기억하는가"라는 질문을 배포 프로세스의 일부로 만드는 것이다.

"실행을 승인했다"는 것이 "기억을 승인했다"는 의미가 아니다

지금까지 AI 클라우드 거버넌스 논의에서 가장 많이 다루어진 주제는 에이전트의 행동(action)이었다. 무엇을 실행할 수 있는가, 어디에 접근할 수 있는가, 어떤 결정을 자율적으로 내릴 수 있는가. 이 질문들은 여전히 중요하다.

하지만 행동은 끝나도 기억은 남는다. 에이전트가 어떤 작업을 실행하도록 승인했다는 것이, 그 실행 과정에서 생성된 모든 상태 데이터를 무기한 보존하도록 승인했다는 의미는 아니다. 이 두 가지를 동일시하는 것이 현재 AI 클라우드 거버넌스의 가장 큰 맹점이다.

기억하는 인프라는 조용히 자란다. 어떤 알림도 없이, 어떤 승인 요청도 없이. 그리고 어느 날 보안 감사나 규제 점검이 시작될 때, 팀은 자신들이 얼마나 많은 것을 "기억하고 있었는지" 처음으로 알게 된다.

그때 가서 "우리는 그 도구가 이렇게 많은 것을 기억하는지 몰랐다"는 말은, 기술적 해명이 될 수 있을지 몰라도 법적·규제적 해명은 되지 않는다. AI 클라우드 시대의 거버넌스는 이제 실행의 통제에서 기억의 통제로 무게중심을 이동해야 한다.

이 글에서 다룬 AI 에이전트 메모리 관리 문제는 앞으로 엔터프라이즈 AI 거버넌스의 핵심 의제가 될 가능성이 높다. AI 클라우드 도입을 검토하거나 이미 운영 중인 팀이라면, 지금 당장 "우리 에이전트는 무엇을 기억하고 있는가"라는 질문을 인프라 점검 목록에 추가하기를 권한다.

다음 글에서는 이 문제를 규제 관점에서 더 깊이 다룰 예정이다. GDPR, 개인정보보호법, 그리고 AI 기본법이 "에이전트 메모리"를 어떻게 다루는지—혹은 아직 다루지 못하고 있는지—를 살펴볼 것이다.

독자들이 가장 많이 묻는 질문

Q. 우리 팀은 이미 AI 에이전트를 운영 중인데, 지금 당장 무엇부터 시작해야 하나?

가장 빠른 첫 번째 단계는 현재 운영 중인 AI 에이전트가 사용하는 클라우드 스토리지 버킷과 데이터베이스 목록을 만드는 것이다. 벡터 DB, 세션 캐시, 로그 저장소를 포함해서. 이 목록이 없다면, 지금 당신 팀은 무엇을 기억하고 있는지조차 모르는 상태다.

Q. 에이전트 메모리를 짧게 유지하면 성능이 떨어지지 않나?

맞다. 트레이드오프가 존재한다. 하지만 이 트레이드오프를 의식적으로 결정하는 것과 아무도 결정하지 않아서 기본값으로 무한정 보존하는 것 사이에는 거버넌스 관점에서 하늘과 땅 차이가 있다다음 글에서는 이 문제를 규제 관점에서 더 깊이 다룰 예정이다. GDPR, 국내 개인정보보호법, 그리고 AI 기본법이 "에이전트가 기억한 데이터"를 어떻게 다루는지—아직 명확한 답이 없는 그 공백을 들여다볼 것이다.

태그: AI 거버넌스, 클라우드 보안, AI 에이전트, 엔터프라이즈, 데이터 보존, FinOps, 컴플라이언스

독자 질문

이 글을 읽고 있는 당신의 조직은 지금 AI 에이전트가 생성하는 상태 데이터를 어디에, 얼마나 오래 보관하고 있는지 알고 있는가? 만약 그 질문에 즉시 답할 수 없다면, 그것이 바로 오늘 해결해야 할 첫 번째 문제다.

댓글로 여러분의 경험을 공유해 주시면 감사하겠다. 비슷한 문제를 겪고 있는 팀이 생각보다 훨씬 많을 것이다.

NOCODE TECH STACKER