프로덕션 AI 에이전트는 다양한 곳에서 메모리를 축적합니다. 사용자 입력, API 응답, 시스템 로그, 이전 상호작용에서 도출된 추론 등이 그 예입니다. 대부분의 에이전트 구현은 이 모든 것을 동일한 풀에 저장하고 구분 없이 쿼리합니다.
데모에서는 잘 작동합니다. 하지만 프로덕션에서는 감지하기 어렵고 복구 비용이 큰 실패 유형을 만들어냅니다. 에이전트가 신뢰해서는 안 되는 메모리를 기반으로 행동하는 것입니다.
핵심 문제
메모리 소스는 동등하지 않습니다. 검증된 외부 API에서 가져온 사실은 사용자가 채팅 세션에서 에이전트에게 말한 사실과 같지 않습니다. 에이전트가 패턴에서 도출한 추론은 다운스트림 시스템의 구조화된 로그 항목과 같지 않습니다.
에이전트가 이 모든 것을 동등하게 취급하면, 신뢰할 수 있는 소스를 신뢰할 수 없는 소스보다 우선시할 메커니즘이 없습니다. 가장 신뢰할 수 있는 메모리가 아니라 가장 최근의, 가장 접근하기 쉬운, 또는 현재 쿼리와 구문적으로 가장 유사한 메모리를 사용하게 됩니다.
해결책은 더 많은 메모리가 아닙니다. 메모리 신뢰 수준입니다. 쓰기 시점에 적용되어 읽기 시점에 각 메모리가 영향을 미칠 수 있는 범위를 규정하는 분류 체계입니다.
대부분의 프로덕션 사례를 커버하는 네 가지 신뢰 수준
검증된 소스 메모리는 권위 있는 외부 시스템에서 옵니다. CRM 레코드, 서명된 API 응답, 알려진 타임스탬프가 있는 데이터베이스 읽기 등이 해당됩니다. 이 메모리는 아웃바운드 메시지 전송, 레코드 업데이트, 워크플로 트리거 등 결과에 영향을 미치는 행동을 주도할 수 있습니다.
추론된 메모리는 에이전트 자체가 생성합니다. 관찰된 패턴에서 도출된 결론, 비정형 입력에 적용된 분류, 이전 컨텍스트의 요약 등입니다. 이 메모리는 추론을 보조해야 하지만 독립적으로 행동을 승인해서는 안 됩니다. 출력을 주도하기 전에 더 높은 신뢰 수준의 뒷받침이 필요합니다.
사용자 주장 메모리는 시스템 검증 없이 사람이 에이전트에게 직접 말한 내용입니다. 유용한 컨텍스트이지만 절대적 사실이 아닙니다. 에이전트는 이를 검증된 소스 데이터보다 낮게 가중치를 두고, 충돌을 조용히 해결하는 대신 표시해야 합니다.
임시 메모리는 세션 범위의 컨텍스트로 지속되어서는 안 됩니다. 일시적인 선호도, 작업 중간 상태, 작업 가정 등이 해당됩니다. 이 메모리가 장기 저장소로 누출되면 오래되거나 컨텍스트에 맞지 않는 데이터로 미래 세션을 오염시킵니다.
각 수준은 서로 다른 권한 집합을 가집니다. 검증된 소스 메모리는 승인할 수 있습니다. 추론된 메모리는 제안할 수 있습니다. 사용자 주장 메모리는 컨텍스트를 제공할 수 있습니다. 임시 메모리는 만료되어야 합니다.
실패 시나리오
신뢰 수준이 없을 때 발생하는 문제입니다.
에이전트가 아웃바운드 잠재 고객 후속 조치를 처리합니다. CRM에서 가져온 검증된 소스 레코드가 있습니다. 잠재 고객의 회사 직원 수가 200명이며 3일 전에 업데이트된 정보입니다. 또한 이전 세션의 추론된 메모리도 있습니다. 에이전트가 대화 요약을 기반으로 해당 회사가 "최근 확장"되어 현재 약 500명에 가깝다고 결론 내린 것입니다.
추론된 메모리가 더 최신입니다. 에이전트는 검증된 소스 레코드를 우선시할 메커니즘이 없습니다. 아웃바운드 메시지에서 추론된 수치를 사용합니다. 실제보다 2.5배 잘못된 회사 규모를 인용하는 것입니다.
잠재 고객은 자신의 회사를 잘못 표현한 메시지를 받습니다. 거래는 진행되지 않습니다. 오류는 기록되지 않았습니다. 에이전트는 설계된 대로 정확히 작동했습니다.
이것은 환각 문제가 아닙니다. 에이전트는 데이터를 만들어내지 않았습니다. 시스템에서 어떤 소스를 신뢰해야 하는지 알려주지 않았기 때문에 자체 메모리 풀에서 잘못된 데이터를 선택한 것입니다.
실제로 신뢰 수준을 구현하는 방법
신뢰 수준은 별도의 저장 시스템이 아닌 메타데이터입니다. 각 메모리 항목은 쓰기 시점에 소스 식별자 및 타임스탬프와 함께 신뢰 레이블을 받습니다.
읽기 시점에 에이전트의 검색 로직은 관련성 순위를 매기기 전에 신뢰 필터를 적용합니다. 검증된 소스 메모리와 추론된 메모리가 동일한 사실에 대해 충돌하면, 에이전트는 조용히 해결하는 대신 충돌을 표시합니다. 사람이나 더 높은 권한의 시스템이 이를 해결합니다.
대부분의 구현에서 적용되는 몇 가지 운영 규칙입니다.
- 추론된 메모리가 검증된 소스 메모리를 덮어쓰지 않도록 하십시오. 공존할 수 있습니다. 대체할 수는 없습니다.
- 사용자 주장 메모리와 임시 메모리에 TTL을 설정하십시오. 오래된 사용자 주장은 메모리가 없는 것보다 나쁩니다. 잘못된 확신을 만들어냅니다.
- 모든 신뢰 수준 충돌을 기록하십시오. 이 로그는 메모리 풀이 현실에서 벗어나고 있다는 신호입니다.
- 아웃바운드 행동 전에 검증된 소스의 뒷받침을 요구하십시오. 에이전트가 행동을 지원할 검증된 소스 레코드를 찾을 수 없으면 일시 중지하고 에스컬레이션해야 합니다.
아웃바운드 AI 시스템에서 이것이 중요한 이유
위의 실패 모드는 가상이 아닙니다. 잠재 고객 리서치, 후속 시퀀싱, 계정 컨텍스트 등 아웃바운드 커뮤니케이션을 다루는 에이전트는 신뢰도 프로파일이 다른 여러 소스의 메모리를 기반으로 작동합니다.
DK1.AI의 AI Brand Presence와 아웃바운드 제품은 소스 수준 메모리 분류를 사후 고려가 아닌 기본 요구 사항으로 구축되었습니다. 에이전트가 귀하를 대신하여 메시지를 보낼 때, 해당 메시지를 주도하는 데이터는 감사할 수 있는 출처 체인이 필요합니다.
메모리 신뢰 수준은 에이전트 시스템에서 덜 눈에 띄는 설계 결정 중 하나입니다. 하지만 시스템이 대규모로 비감독 상태에서 안전하게 실행될 수 있는지를 결정하는 요소이기도 합니다.
아웃바운드 행동을 처리하는 에이전트 시스템을 구축하거나 평가하고 있다면, 어렵게 알게 되기 전에 현재 메모리 아키텍처가 소스 충돌을 어떻게 처리하는지 감사해볼 가치가 있습니다.