r/AI_Agents•약 1개월 전•13•14

여러 에이전트가 기록, 권한, 정리 규칙을 공유할 때 에이전트 출력물은 어떻게 저장하시나요?

How are you storing agent outputs when multiple agents need history, permissions, and cleanup rules?

핵심 요약

에이전트 출력물의 버전 관리, 권한 제어, 데이터 만료 정책을 구현하기 위한 아키텍처와 감사 추적 방식을 논의합니다.

데이터 관리 — 메타데이터와 실제 아티팩트를 분리하여 저장함
정리 정책 — TTL 기반의 크론 작업으로 만료된 데이터 삭제함
감사 추적 — JSONL 저널이나 불변 아티팩트 ID를 활용함
권한 제어 — 읽기 시점에 권한을 확인하거나 스코프 기반 정책을 적용함

Git은 코드에 쓰고, 오브젝트 스토리지는 파일에 쓰고, 데이터베이스는 메타데이터에 쓰지만, 이 중 그 무엇도 누가 아티팩트를 읽을 수 있는지, 어떤 버전이 공식인지, 혹은 오래된 결과물을 언제 폐기해야 하는지에 대한 답을 주진 못해. 너희는 어떤 아키텍처를 쓰고 있고, 사람이 직접 검토할 수 있는 감사 추적(audit trail)은 어디에 보관하고 있냐?

원문

커뮤니티 목록

r/AI_Agents•약 1개월 전•13•14

여러 에이전트가 기록, 권한, 정리 규칙을 공유할 때 에이전트 출력물은 어떻게 저장하시나요?

How are you storing agent outputs when multiple agents need history, permissions, and cleanup rules?

핵심 요약

에이전트 출력물의 버전 관리, 권한 제어, 데이터 만료 정책을 구현하기 위한 아키텍처와 감사 추적 방식을 논의합니다.

데이터 관리 — 메타데이터와 실제 아티팩트를 분리하여 저장함
정리 정책 — TTL 기반의 크론 작업으로 만료된 데이터 삭제함
감사 추적 — JSONL 저널이나 불변 아티팩트 ID를 활용함
권한 제어 — 읽기 시점에 권한을 확인하거나 스코프 기반 정책을 적용함

주요 댓글

r/ai_agents

에이전트 출력물 관리를 위해 메타데이터와 아티팩트를 분리하고, 깃, DB, 객체 저장소를 조합하여 버전 관리와 권한 제어를 구현하는 실용적인 접근법들이 제시되었습니다.

내 생각에 정리 규칙이 가장 어려운 부분임. 버전 관리나 권한은 적절한 스키마로 덧붙일 수 있지만, 하위 에이전트가 만료되어야 할 출력물을 참조하고 있을 때 만료 정책이 꼬이게 됨. 저장소를 선택하기 전에 의존성 그래프를 먼저 정의하는 게 좋음.

그래프에 따라 다름.

아티팩트 저장을 위한 S3 버킷 정책

버전 관리 + RBAC 메타데이터를 위한 DB

만료된 출력물을 삭제하기 위한 자동화된 람다 크론 작업

우리는 잔머리 굴리는 대신 모든 에이전트 출력물에 agent_id, run_id, scope 필드가 포함된 행을 하나씩 부여함. 권한은 레코드가 아니라 스코프에 부여함. 정리는 참조된 곳이 없는 한 TTL이 지난 모든 것을 삭제하는 크론 작업으로 처리함. 지루한 방식이지만 시스템이 뻗지는 않음.

솔직히 말해서 하나의 기발한 시스템으로 이걸 해결하려는 건 포기했음. 내 설정(단열재 시공업체를 위한 B2B 도구를 만드는 소규모 에이전트 팀 운영 중)에서는 에이전트가 생성하는 모든 것이 워크스페이스 디렉토리에 일반 파일로 저장되고, 모든 쓰기 작업마다 JSONL 저널에 한 줄씩 추가됨(에이전트 이름, 작업 ID, 경로, 수행한 작업 한 문장). 그 저널이 감사 추적 역할을 하며, 뭔가 잘못됐을 때 실제로 열어보는 파일임. 권위 있는 버전은 그냥 깃에 올라간 것이고, 에이전트들은 깃에 커밋함...

모든 출력물에 불변 아티팩트 ID를 부여하고 읽기 시점에 권한을 확인하도록 하셈. 감사 추적은 해당 ID로 어떤 버전이 반환되었는지 기록해야 함. 그래야 의사결정 기록을 지우지 않고도 저장소에서 만료 처리를 할 수 있음.

YAML 레지스트리 방식을 씀. 거버넌스와 계획 수립을 위한 에이전트 하나와 빌더들과의 여러 병렬 세션을 사용함. 계획 수립 에이전트가 초기 릴레이를 만들고 YAML에 기록한 뒤 나를 위한 마크다운 버전을 생성함. YAML 레지스트리는 불변임. 빌더들은 계획 수립 에이전트가 제공한 타겟팅된 컨텍스트를 위해 레지스트리를 읽을 수 있음. 빌더들이 게이트를 닫으면 거버넌스 에이전트가 레지스트리를 업데이트함. 아주 잘 작동함.

작업 추적과 작업 아티팩트를 구분한 건 좋은 접근임. 물론 둘 사이에 겹치는 부분이 많긴 하지만.

내 생각에 전자는 에이전트와 함께 있어야 하고, 가장 간단한 답은 에이전트가 보관된 동일한 리포지토리의 깃 브랜치에 구조화된 파일을 두는 것임. 우리가 openroutines.dev에서 취한 방식이기도 함.

후자는 사용 사례에 따라 다르며, 일반적인 방식으로 해결하기보다는 아티팩트를 받는 시스템에서 처리하는 게 맞음. 예를 들어 시장 조사 에이전트...

매우 흥미로운 주제라 나도 고민 중이었음. 제안할 내용이 있다면 자유롭게 공유해주길 바람.

먼저 이걸 여러 문제와 그 해결책으로 나누고 싶음:

구조화된 메타데이터(누가 무엇을 언제 생성했는지 등) - Postgres/DynamoDB/메타데이터 카탈로그

아티팩트 저장소(출력 텍스트 파일, 보고서 등) - 객체 저장소(S3/GCS/ADLS)

버전 관리(어떤 출력물이 최신인지, 롤백 기능) - 코드는 깃, 데이터는 테이블

접근 제어 - IAM 정책, RBAC, 카탈로그...

길이 제한으로 뒷부분이 생략된 댓글입니다 · 원문에서 전체 보기 →

정리(cleanup) 문제는 가비지 컬렉션 문제와 같아서, 그쪽 용어를 차용하는 게 좋음. TTL은 시간 경과에 따라 만료되는데, 이건 잘못된 기준임. 3월에 생성된 아티팩트라도 현재 실행 중인 런(run) 3개가 참조하고 있다면 그건 가비지가 아님. 반대로 1시간 전에 생성된 파일이라도 아무것도 참조하지 않는다면 그건 가비지임. 활성 런의 루트 세트로부터의 도달 가능성(reachability)과 명시적으로 고정(pinned)된 항목들을 활용하면, 일일이 의존성을 기록할 필요 없이 정확한 결과를 얻을 수 있음.

그리고 감사 추적(audit trail)은 실제 데이터(bytes)와 분리해서 보관하셈. 추적 기록에는 아티팩트 해시와…

도달 가능성/GC 관점으로 접근하는 건 매우 일리 있음. 근데 '도달 가능하지만 오래된(reachable but stale)' 아티팩트는 어떻게 처리하는지 궁금함. 만약 현재 실행 중인 런이 이전 모델/도구/스키마로 생성된 출력을 여전히 참조하고 있다면, 도달 가능성 기준으로는 유지해야 하지만, 그렇다고 그게 여전히 사용 가능한 상태라는 보장은 없잖아. 아티팩트 자체뿐만 아니라 의존성 조건도 버전 관리를 하고 있음? 별개로, 데이터가 만료된 후에도 감사 ID나 해시를 남겨두는 건 유용한 구분 방식인 듯.

원문r/AI_Agents