LLM의 발전 속도는 따라잡기 어려울 정도로 빨라지고 있다. 최근 AI 전문가 앨리 밀러는 여러 작업에 활용하는 ‘추천 LLM 목록’을 공개하면서 “다음 주면 바뀔 것 같다”라고 언급했다. 한 모델이 더 빨라지거나 특정 영역에서 훈련이 강화되면 순위가 바뀔 수 있기 때문이다. 그러나 변하지 않는 것도 있다. 고가치 엔터프라이즈 데이터를 기반으로 해야 한다는 LLM의 본질적인 요구사항이다. 결국 중요한 과제는 LLM 자체의 발전을 쫓는 것이 아니라, AI가 활용할 ‘메모리’를 어떻게 설계하고 관리하느냐다.

LLM을 CPU에 비유한다면, 메모리는 하드드라이브이자 AI 에이전트가 유용하게 기능하기 위해 필요한 맥락과 축적된 지식에 가깝다. 에이전트에서 메모리를 제거하면 값비싼 난수 생성기 정도에 불과하다. 동시에 점점 더 자율성을 갖춘 에이전트형 시스템에 메모리를 주입하는 순간, 이전에는 없던 새로운 거대한 공격 표면이 생긴다는 점도 문제로 떠오르고 있다.

현재 많은 기업이 에이전트 메모리를 단순한 스크래치패드나 SDK 뒤에 있는 보조 기능 정도로 취급한다. 하지만 이제는 메모리를 데이터베이스로 다뤄야 한다. 기존 어느 시스템보다 위험할 수 있으면서도 강력한 데이터베이스로 관리해야 한다.

에이전틱 AI의 급소

필자는 불과 5달 전 일반적인 데이터베이스가 AI의 해마(hippocampus) 역할을 하며, 상태를 저장하지 않는(stateless) 모델에 장기 기억에 가까운 외부 메모리를 제공하기 시작했다고 설명한 바 있다. 이는 현재의 에이전트형 시스템이 본격적으로 확산하기 전의 이야기였다. 지금은 상황이 훨씬 더 복잡해졌다.

AI 에이전트를 연구하는 리치먼드 얼레이크는 지속적으로 진행 중인 ‘에이전트 메모리’ 연구를 통해 LLM 메모리와 에이전트 메모리의 차이를 강조해 왔다. LLM의 메모리는 사실상 파라미터 가중치와 짧은 컨텍스트 윈도우에 불과하며, 세션이 끝나면 모두 사라진다. 반면 에이전트 메모리는 다르다. 이는 지식을 지속적으로 축적하고, 맥락을 유지하며, 과거 상호작용을 기반으로 동작을 조정하는 ‘지속적 인지 아키텍처’에 가깝다.

얼레이크는 이를 ‘메모리 엔지니어링(memory engineering)’이라는 새로운 분야로 규정하며, 프롬프트 엔지니어링이나 컨텍스트 엔지니어링의 후속 단계로 봤다. 단순히 더 많은 토큰을 넣는 방식이 아니라, 원시 데이터를 의도적으로 구조화된 장기·단기·공유 메모리 등으로 변환해 저장하는 데이터-메모리 파이프라인을 구축하는 개념이다.

AI 전문 용어처럼 보이지만, 실제로는 전형적인 데이터베이스 문제다. 에이전트가 스스로 메모리에 데이터를 기록하기 시작하면 모든 상호작용이 미래 의사결정에 영향을 주는 상태 변화가 된다. 이 단계에 접어들면 인간의 역할은 프롬프트를 손보는 수준을 벗어난다. 에이전트가 ‘세계에 대해 믿는 것’을 실시간으로 업데이트하는 데이터베이스를 구축·운영하는 일이 핵심이 된다.

이 데이터베이스가 잘못되면 에이전트는 자신있게 틀린 판단을 내린다. 이 데이터베이스가 공격당하면, 에이전트는 일관되게 위험한 행동을 하게 된다. 위협은 크게 다음 3가지로 분류할 수 있다.

메모리 중독(memory poisoning). 공격자는 방화벽을 뚫지 않고도 정상적 상호작용을 통해 에이전트에 잘못된 정보를 ‘가르칠’ 수 있다. OWASP(Open Worldwide Application Security Project)는 메모리 중독을 저장된 데이터를 오염시켜 향후 잘못된 결정을 유도하는 공격으로 정의한다. 프롬프트푸(Promptfoo) 같은 도구는 이미 유효한 메모리를 악성 정보로 덮어쓰도록 속일 수 있는지 테스트하는 레드팀 플러그인을 제공한다. 메모리가 중독되면, 해당 정보를 참조하는 모든 후속 행동이 왜곡된다.

도구 오용(tool misuse). 에이전트는 SQL 엔드포인트, 셸 명령, CRM API, 배포 시스템 등 다양한 도구에 접근하는 경우가 늘고 있다. 공격자가 특정 상황에서 ‘잘못된’ 도구를 실행하도록 유도하면, 내부 사용자가 실수로 위험한 명령을 실행한 것과 구별하기 어려운 결과를 만든다. OWASP는 이를 도구 오용과 에이전트 하이재킹으로 분류한다. 권한을 탈출하는 것이 아니라, 부여된 권한을 공격자가 원하는 방식으로 쓰도록 유도하는 형태다.

권한 축적과 정보 노출(privilege creep and compromise). 시간이 지날수록 에이전트는 역할, 비밀값, 민감 데이터의 스냅샷을 점점 더 많이 축적한다. 하루는 CFO를 지원하고 다음 날은 신입 애널리스트를 지원하도록 설정하면, 에이전트는 이후 절대 공유해서는 안 되는 정보를 ‘기억’하게 될 수 있다. 에이전틱 AI 보안 분류 체계는 이런 권한 축적과 접근 범위 확대 문제를 주요 위험으로 지목한다. 특히 동적으로 역할이 바뀌거나 정책 검증이 느슨한 환경에서 위험은 더욱 커진다.

새로운 용어, 익숙한 문제

문제의 핵심은 이런 위협이 존재한다는 사실이 아니다. 모든 위협이 본질적으로 ‘데이터 문제’라는 점이다. AI라는 외피를 벗겨보면 그동안 데이터 거버넌스팀이 수년간 추적하던 문제와 정확히 일치한다.

최근 필자는 기업이 AI 플랫폼을 선택할 때 우선순위를 ‘빠른 구축’에서 ‘빠르게 거버넌스 체계로 연결’로 전환하고 있다고 언급했다. 에이전틱 시스템에서는 이 경향이 더 분명하게 드러난다. 에이전트는 인간 데이터를 활용하면서 기계 속도로 동작한다. 데이터가 잘못되었거나 오래되었거나 잘못 라벨링되어 있다면, 에이전트도 그만큼 잘못되고, 오래되고, 인간보다 훨씬 빠르게 오작동한다.

‘거버넌스 없는 빠름’은 고속의 부실 운영에 지나지 않는다.

문제는 대부분의 에이전트 프레임워크가 자체적인 작은 메모리 저장소를 함께 제공한다는 것이다. 이쪽에는 기본 벡터 데이터베이스, 저쪽에는 JSON 파일, 그리고 조용히 운영 환경으로 흘러가는 인메모리 캐시가 뒤섞여 있다. 데이터 거버넌스 관점에서 보면 모두 그림자 데이터베이스다. 스키마도 없고, 접근 제어 목록도 없고, 제대로 된 감사 로그도 없다.

사실상 에이전트만을 위한 ‘두 번째 데이터 스택’을 구축하면서, 동시에 보안팀이 왜 이 에이전트들을 중요한 시스템에 접근시키기를 꺼려하는지 의아해하고 있다. 하지만 이렇게 해서는 안 된다. 에이전트가 의사결정에 영향을 미치는 기억을 보관한다면, 그 기억은 고객 정보, HR 데이터, 재무 데이터를 관리하는 것과 동일한 거버넌스 데이터 인프라 안에 있어야 한다. 에이전트는 새롭다. 그러나 보안까지 새로운 필요는 없다.

기존 강자의 반격

업계는 ‘에이전트 메모리’라는 개념이 결국 ‘영속성(persistence)’을 다시 포장한 것이라는 사실을 깨닫기 시작했다. 자세히 들여다보면 주요 클라우드 서비스 업체가 하는 일은 이미 데이터베이스 설계에 가깝다. 예컨대 아마존 베드록(Bedrock) 에이전트코어(AgentCore)는 ‘메모리 리소스’를 논리적 컨테이너로 도입하면서 보존 기간, 보안 경계, 원시 상호작용을 지속 가능한 인사이트로 변환하는 방식을 명시적으로 정의한다. AI라는 이름을 붙였을 뿐, 사용되는 언어는 철저히 데이터베이스 개념이다.

벡터 임베딩을 기존 데이터베이스 바깥에서 별도로 취급하는 방식도 합리적이지 않다. 핵심 트랜잭션 엔진이 벡터 검색, JSON, 그래프 쿼리를 모두 네이티브로 처리할 수 있다면 굳이 분리할 이유가 없다. 메모리를 이미 고객 데이터를 보관하는 데이터베이스로 통합하면 수십 년간 축적된 보안 강화 효과를 그대로 누릴 수 있다. 웰스 파고의 수석 AI 아키텍트 브리지 판데이는 데이터베이스가 오랫동안 애플리케이션 아키텍처의 중심에 있었으며, 에이전틱 AI도 그 중력을 바꾸지 못한다고 지적했다. 오히려 그 중요성을 강화할 뿐이다.

그런데도 많은 개발자가 여전히 이 스택을 우회한다. 별도의 벡터 데이터베이스를 띄우거나 랭체인 같은 프레임워크가 제공하는 기본 저장소를 그대로 사용해 스키마도 감사 로그도 없는 비관리 임베딩 저장소를 만든다. 이는 앞서 언급한 ‘고속의 부실 운영’에 해당한다.

해결책은 명확하다. 에이전트 메모리를 정식 데이터베이스로 다루면 된다. 실무적으로는 다음과 같은 의미다.

생각에 대한 스키마를 정의하라. 많은 팀이 메모리를 비정형 텍스트처럼 취급하지만 이는 오해다. 에이전트 메모리는 구조화가 필요하다. 누가 말했는가? 언제인가? 신뢰도는 어떤가? 재무 데이터를 텍스트 파일에 던져 넣지 않듯, 에이전트의 기억도 아무 벡터 저장소에 던져 넣어서는 안 된다. 생각의 수명 주기를 관리할 메타데이터가 필요하다.

메모리 방화벽을 구축하라. 장기 메모리에 기록되는 모든 입력은 신뢰할 수 없는 데이터로 간주해야 한다. 스키마를 적용하고 제약을 검증하며 데이터 손실 방지 기능을 수행하는 ‘방화벽’ 로직이 필요하다. 디스크에 저장되기 전, 프롬프트 인젝션이나 메모리 중독 징후를 탐지하는 전용 보안 모델을 활용할 수도 있다.

접근 제어는 프롬프트가 아니라 데이터베이스에 넣어라. 이는 에이전트의 ‘뇌’에 행 단위 보안을 적용한다는 의미다. 예를 들어 1단계 권한(주니어 애널리스트)을 돕는 세션에서는, 에이전트가 2단계 권한(CFO)의 기억을 사실상 ‘제거한 상태’로 운영돼야 한다. 이를 강제하는 주체는 프롬프트가 아니라 데이터베이스다. 에이전트가 접근하면 안 되는 메모리를 조회하려 하면, 데이터베이스는 결과를 반환하지 않아야 한다.

생각의 사슬(chain of thought)을 감사하라. 전통적 보안에서는 누가 어떤 테이블에 접근했는지를 살핀다. 에이전트 보안에서는 ‘왜’ 접근했는지도 추적해야 한다. 에이전트의 실제 행동을 특정 메모리 기록과 연결해 계보 형태로 추적할 수 있어야 한다. 에이전트가 데이터를 유출했다면, 그 행동을 유발한 메모리를 찾아내 정확히 제거할 수 있어야 한다.

내재된 신뢰

우리는 종종 AI 신뢰 문제를 윤리, 정렬, 투명성 같은 추상적 개념으로 이야기한다. 물론 중요한 요소다. 그러나 실제 엔터프라이즈 환경에서 운영되는 에이전틱 시스템에서 신뢰는 추상이 아니라 구체적 문제다.

지금은 모든 기업이 ‘알아서 처리하는’ 에이전트를 구축하고 싶어하는 과열 단계다. 그 마음은 이해할 만하다. 에이전트는 과거에는 여러 팀이 나서야 했던 워크플로우와 애플리케이션을 자동화할 수 있다. 하지만 인상적인 데모 뒤에는 사실과 추론된 맥락, 중간 계획, 캐시된 도구 실행 결과 등으로 가득 찬 방대한 메모리 저장소가 자리 잡고 있다. 이 저장소를 정식 데이터베이스로 다루는지, 아니면 그렇지 않은지가 본질적 차이를 만든다.

데이터 계보, 접근 제어, 보존 정책, 감사 체계를 이미 갖춘 기업은 에이전트 시대에 구조적 우위를 가진다. 새롭게 거버넌스를 발명할 필요도 없다. 기존 체계를 새로운 유형의 워크로드에 확장하기만 하면 된다.

현재 에이전트 시스템을 설계하고 있다면 메모리 계층부터 시작해야 한다. 메모리가 무엇인지, 어디에 저장되는지, 어떤 구조로 관리되는지, 어떤 거버넌스가 적용되는지 먼저 결정하라. 그 모든 것이 갖춰진 뒤에야 비로소 에이전트를 운영 환경에 투입할 수 있다.
dl-itworldkorea@foundryco.com