이벤트 소싱은 AI 에이전트의 의사 결정에 대한 감사 추적을 어떻게 보존하나요?

이벤트 소싱은 변경 가능한 단일 현재 상태를 덮어쓰는 대신, 승인된 각 의사 결정과 상태 변경을 순서가 있는 이벤트로 기록하여 AI 에이전트의 감사 추적을 보존합니다.

홈 서버에서는 이를 통해 다단계 자동화를 재구성할 수 있습니다. 운영자는 워크플로가 완료된 후 제안, 승인, 도구 호출, 실패, 재시도, 보상 작업, 최종 상태를 추적할 수 있습니다.

이벤트 소싱은 상태 변경을 기본 기록으로 저장합니다

이벤트 소싱은 최신의 변경 가능한 행만을 유일한 진실의 원천으로 취급하는 대신, 승인된 각 상태 변경을 이벤트로 기록합니다. 현재 상태는 순서가 있는 이력에서 파생됩니다.

Martin Fowler는 이벤트 소싱을 애플리케이션 상태의 모든 변경 사항을 이벤트 시퀀스로 저장하는 방식으로 정의합니다. 이 이력은 시스템이 특정 상태에 도달한 과정을 보존합니다. Martin Fowler는 상태 변경을 이벤트 시퀀스로 저장하는 방식을 중심으로 이벤트 소싱을 설명하며, 이는 Martin Fowler의 이벤트 소싱 문서에서 사용된 기본 기록 개념을 보여 줍니다.

홈 AI 에이전트에서는 ProposalCreated, ApprovalGranted, ToolCallStarted, ToolCallFailed, CompensationCompleted를 하나의 상태 필드로 합치지 않고 별도의 사실로 유지할 수 있습니다.

각 에이전트 의사 결정은 시간순 사실이 됩니다

이벤트는 이미 발생한 일을 설명해야 하며, 나중에 해석할 수 있도록 워크플로 ID, 도구, 매개변수 해시, 정책 결과, 의사 결정 결과, 필요한 경우 타임스탬프 등 충분한 맥락을 포함해야 합니다.

Fowler는 이벤트 소싱을 사용하면 이벤트 저장소가 주요 진실의 원천이 되고 재생을 통해 상태를 다시 구축할 수 있다고 설명합니다. 이 순서가 있는 시퀀스는 인과관계가 드러나는 감사 경로를 만듭니다. Microsoft Azure는 이벤트가 애플리케이션 상태의 변경을 나타내는 추가 전용 이벤트 저장소를 설명하며, 이는 Azure 이벤트 소싱 패턴에서 설명하는 시간순 의사 결정 사실을 뒷받침합니다.

유용한 감사 객체는 관찰 가능한 의사 결정 기록이지 비공개 내부 추론이 아닙니다. 어떤 작업이 제안되었는지, 어떤 정책이 이를 평가했는지, 어떤 결과가 반환되었는지, 실제로 어떤 부작용이 발생했는지가 중요합니다.

프로젝션은 이벤트 로그를 현재 뷰로 변환합니다

모든 화면이나 에이전트 요청마다 전체 이력을 재생하는 것은 비효율적입니다.

이벤트 소싱 시스템은 현재 워크플로 상태, 대기 중인 승인, 최근 실패와 같은 프로젝션을 구축합니다.

이벤트 소싱은 기록된 이벤트에서 현재 애플리케이션 상태를 재구성할 수 있습니다. 따라서 로직이나 데이터베이스가 변경되더라도 프로젝션을 다시 구축할 수 있습니다. AWS 지침은 저장된 이벤트에서 현재 상태를 도출하는 방식을 설명하며, 기본 이력을 대체하지 않고 프로젝션으로 읽기 뷰를 구축하는 방법을 AWS 이벤트 소싱 지침에서 보여 줍니다.

소형 서버에서는 스냅샷을 사용해 재생 시간을 줄일 수 있지만 이벤트는 여전히 권위 있는 기록으로 남습니다. 스냅샷은 성능을 위한 지름길이고, 이벤트 시퀀스가 이력입니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

상관관계 ID는 다단계 작업을 하나의 의사 결정 이력으로 연결합니다

하나의 요청이 검색, 계획 수립, 승인, 여러 도구 호출, 재시도, 보상 작업을 연쇄적으로 실행할 수 있습니다.

상관관계 ID는 이러한 이벤트를 하나의 일관된 작업으로 묶습니다.

이는 단순히 로그를 다른 곳에 저장하는 것과 다릅니다. ZimaSpace의 외부 감사 로그 격리는 앱이 침해되어도 증거가 보존되는 방식을 설명합니다. 이벤트 소싱은 워크플로 상태 자체가 순서가 있는 이력이 되는 방식을 설명합니다. Kurrent는 순서가 있는 이벤트 스트림과 식별자를 강조하며, 이는 Kurrent 이벤트 소싱 개념에서 관련 단계를 하나의 추적 가능한 의사 결정 이력으로 연결하는 방식을 뒷받침합니다.

두 방식을 함께 사용할 수도 있습니다. 이벤트 기록은 운영 재생을 구동하고, 추가 지향 복사본은 더 강력한 증거 보존을 위해 별도의 로깅 경계로 내보낼 수 있습니다.

수정 사항은 이력을 다시 쓰는 대신 새 이벤트로 추가됩니다

에이전트의 의사 결정이 나중에 잘못된 것으로 밝혀지면 이벤트 소싱 설계에서는 원래 이벤트를 없애도록 편집하는 대신 보상 이벤트나 수정 이벤트를 기록합니다.

Fowler의 이중 시간성 논의는 나중에 얻은 지식이 이전의 가정을 수정하더라도 기록 이력을 추가 전용으로 유지할 수 있다는 더 넓은 개념을 보여 줍니다. Marten은 이벤트를 추가 전용 이력으로 유지하고 그로부터 집계 상태를 다시 구축합니다. 이는 Marten 이벤트 저장소 문서에서 설명하듯 수정 사항을 추가할 수 있으며 이전 사실을 조용히 다시 쓰지 않아도 되는 이유를 보여 줍니다.

이는 정책이나 프롬프트가 변경될 때 유용합니다. 운영자는 수리된 최종 상태만 보는 대신, 특정 정책 버전에서 작업이 승인되었고 나중에 되돌려졌다는 사실을 확인할 수 있습니다.

이벤트 소싱이 자동으로 증거를 변조 방지하는 것은 아닙니다

이벤트 이력의 신뢰성은 이벤트 생성, 저장, 접근, 시계, 삭제를 둘러싼 통제만큼만 높습니다.

저장소를 다시 쓸 수 있는 프로세스는 여전히 자신의 이력을 파괴할 수 있습니다.

Fowler는 이벤트 로그가 권위 있는 정보 저장소로 유지될 때 얻을 수 있는 감사 및 과거 쿼리의 장점을 강조합니다. 내구성과 추가 제어는 별도의 운영 문제로 남습니다. 최근 연구는 자율 에이전트 활동에 구조화된 추가 전용 이벤트 이력을 적용하지만, 애플리케이션의 추가 전용 로직이 변조 방지 저장소와 같지는 않다는 점도 분명히 합니다. 자세한 내용은 자율 에이전트를 위한 이벤트 소싱을 참조하세요.

ZimaSpace의 읽기 전용 우선 에이전트 설계는 위험한 작업이 실행되기 전에 이를 줄이고, 이벤트 소싱은 실제로 발생한 의사 결정과 작업을 보존합니다.