본문 (Claude Code Generated)
논문: FileGram: Grounding Agent Personalization in File-System Behavioral Traces
저자: Shuai Liu, Shulin Tian, Kairui Hu 외 (NTU S-Lab, Synvo AI)
날짜: 2026년 4월 6일
링크: arXiv:2604.04901 | Project Page | GitHub | Dataset
TL;DR
AI 에이전트가 사용자의 파일 시스템 작업 패턴(파일 읽기, 생성, 편집, 정리 등)을 기억하고 개인화에 활용하는 프레임워크. 기존 대화 요약 기반 메모리 시스템(Mem0, Zep 등)이 행동 구분 정보를 잃어버리는 문제를 지적하고, 원자적 행동 로그에서 직접 프로파일을 구축하는 bottom-up 메모리 아키텍처를 제안한다.
왜 이 연구가 필요한가?
OS-level AI 에이전트(Claude Code, Cursor, Devin 등)가 단순 명령 실행을 넘어 파일 시스템 코워커로 진화하고 있다. 그런데 사용자마다 작업 방식이 완전히 다르다.
•
어떤 사람은 파일을 순차적으로 정독하고, 어떤 사람은 키워드 검색부터 한다
•
어떤 사람은 3단계 이상 중첩 폴더를 만들고, 어떤 사람은 루트에 다 쌓는다
•
어떤 사람은 소규모 반복 편집을 하고, 어떤 사람은 파일 전체를 새로 쓴다
문제는 기존 메모리 시스템이 전부 대화(dialogue) 기반이라는 것이다. "사용자가 무슨 말을 했는지"는 기억하지만, "사용자가 파일을 어떻게 다루는지"는 모른다. 여기에 세 가지 병목이 존재한다.
병목 | 설명 |
데이터 | 프라이버시 문제로 실제 파일 시스템 행동 데이터를 대규모 수집할 수 없음 |
평가 | 기존 벤치마크는 대화 회상이나 GUI 성공률만 측정, 행동 개인화 평가 부재 |
방법론 | 메모리 시스템이 대화 요약(top-down)에 의존 → 파일 작업의 세밀한 패턴이 소실됨 |
FileGram의 세 기둥
FileGram은 위 세 병목을 각각 해결하는 세 구성요소로 이루어진다.
1. FileGramEngine — 행동 데이터 생성
실제 데이터 수집이 어려우니, 페르소나 기반 시뮬레이션으로 해결한다.
•
20개 사용자 프로파일 정의 (6개 행동 차원 × L/M/R 3단계)
•
32개 태스크 설계 (Understand, Create, Organize, Synthesize, Iterate, Maintain)
•
20 × 32 = 640개 행동 궤적 생성, 총 20,028개 원자적 행동 + 약 10K 멀티모달 파일
각 프로파일에는 5개 궤적에 의도적 **행동 변동(perturbation)**을 주입해서, 현실적인 노이즈와 드리프트 탐지 평가를 가능하게 한다.
2. FileGramBench — 진단 벤치마크
4개 Track, 9개 sub-task, 4.6K QA 쌍으로 구성된 평가 체계.
Track | 목표 | Sub-tasks |
T1: Understanding | 궤적에서 사용자 프로파일 복원 | Attribute Recognition, Behavioral Fingerprint, Profile Reconstruction |
T2: Reasoning | 패턴 추론 및 궤적 분리 | Behavioral Inference, Trace Disentanglement |
T3: Detection | 행동 드리프트 탐지 | Anomaly Detection, Shift Analysis |
T4: Multimodal | 비텍스트 입력에서 행동 추론 | File Grounding, Visual Grounding |
3. FileGramOS — Bottom-Up 메모리 아키텍처
이 논문의 핵심 기여. 기존 시스템과의 근본적 차이는 추상화 시점에 있다.
기존 (Mem0, Zep 등): 궤적 → [즉시 요약] → 내러티브 저장 → 쿼리 응답
↑ 여기서 행동 구분 정보 소실
FileGramOS: 궤적 → [구조화 보존] → 3채널 저장 → [쿼리 시점 추상화] → 응답
↑ 정보를 최대한 유지
Plain Text
복사
3단계 파이프라인:
Stage 1 — Per-Trajectory Encoding (Engram 생성)
각 궤적을 3개 병렬 스트림으로 처리:
•
Procedural: 행동 카운팅 → 메트릭 계산 → 17차원 fingerprint 벡터
•
Semantic: VLM으로 파일 스냅샷/편집 diff에서 스타일·포맷 기술자 추출
•
Episodic: 이벤트 타임라인을 경계 탐지로 논리적 에피소드로 분절
Stage 2 — Cross-Engram Consolidation (3채널 MemoryStore)
N개 Engram을 통합:
•
Procedural Channel: fingerprint의 교차 통계 (mean, std, min, max)
•
Semantic Channel: 콘텐츠 임베딩 + 교차 세션 스타일 요약
•
Episodic Channel: 궤적 클러스터링 + z-score 기반 이상 탐지 → LLM Judge로 "의도적 변동 vs 진짜 이상" 판별
Stage 3 — Query-Adaptive Retrieval
쿼리가 들어올 때 비로소 3채널에서 관련 clue를 추출해 답변 생성. 의미 추상화를 쿼리 시점까지 미루는 것이 핵심.
6개 행동 차원
FileGram이 사용자를 프로파일링하는 축:
차원 | 이름 | L (Left) | M (Middle) | R (Right) |
A | Consumption Pattern | 순차 정독 | 검색 후 읽기 | 훑어보기 |
B | Production Style | 상세 보고서 (다단 헤딩, 표, 부록) | 적당한 분량 | 간결 요약 (불릿 포인트) |
C | Organization | 3+ 레벨 중첩 폴더 | 1-2 레벨 적응형 | 루트에 플랫 |
D | Iteration Strategy | 소규모 반복 편집 + 백업 | 균형 잡힌 수정 | 전체 재작성 |
E | Curation | 적극 정리 (임시파일 삭제) | 적당히 정리 | 전부 보존 |
F | Cross-Modal | 차트/도표 중심 | 표 활용 | 텍스트 only |
실험 결과
Gemini 2.5-Flash를 공통 QA backbone으로 사용해 12개 baseline과 비교.
방법 | 유형 | 평균 정확도 |
No Context | - | 25.7% |
Full Context | Context | 48.0% |
Naive RAG | Context | 40.5% |
Mem0 | Text Memory | 33.2% |
Zep | Text Memory | 40.2% |
MemOS | Text Memory | 36.2% |
EverMemOS | Text Memory | 49.9% |
MemU | Multimodal Memory | 44.4% |
MMA | Multimodal Memory | 44.7% |
FileGramOS | Bottom-Up | 59.6% |
핵심 발견
1. 내러티브 요약의 함정
Mem0, Zep 같은 시스템은 궤적을 즉시 요약하면서 "structured", "methodical", "comprehensive" 같은 동일한 제네릭 서술자로 수렴해버린다. 실제로는 다른 행동 패턴을 가진 프로파일들이 구분 불가능해지는 systematic flattening 현상.
2. Full Context의 역설
단순히 원시 이벤트를 전부 이어붙인 Full Context가 대부분의 memory 시스템보다 나았다 (48.0%). 이는 기존 시스템의 요약 과정에서 정보 손실이 얼마나 심각한지를 방증한다. 다만 32개 궤적 간 교차 비교가 필요한 태스크에서는 구조화된 집계가 필수적이라 FileGramOS가 크게 앞섰다.
3. 멀티모달 메모리의 한계
MMA, MemU 등 멀티모달 메모리 시스템도 텍스트 기반 최강 baseline을 넘지 못했다. 렌더링된 페이지 이미지로는 파일 수, 출력 길이, 편집 빈도, 디렉토리 깊이 같은 operation-level 통계를 볼 수 없기 때문.
4. Track별 난이도 계층
•
T1/T2: 부분적으로 풀림 (행동 이해/추론)
•
T3: 탐지-설명 격차 — 이상 자체는 감지하지만, "어떤 차원이 어느 방향으로 변했는지"를 귀인하는 데 대부분 실패
•
T4: 가장 어려움 — 멀티모달 그라운딩에서 전 방법론이 고전
데이터셋 구조 (HuggingFace)
Choiszt/FileGram에 공개된 데이터셋의 구조:
필드 | 설명 | 예시 |
question_id | 고유 식별자 | s1_dimcls_p10_silent_auditor_A |
track | 평가 트랙 | T1, T2, T3, T4 |
sub_track | 세부 태스크 | Attribute Recognition, Trace Disentanglement |
profile_id | 사용자 프로파일 | p10_silent_auditor, p1_methodical |
input_trajectories | 입력 궤적 목록 | ["p10_silent_auditor_T-01", ...] |
question | 질문 텍스트 | "이 사용자의 Consumption Pattern은?" |
choices | 선택지 | {"A": "Targeted searcher...", "B": "Sequential..."} |
correct | 정답 | B |
metadata | 메타데이터 (차원, 궤적 수 등) | {"target_dimension": "A", "n_trajectories": 32} |
개인적 생각
이 연구가 흥미로운 이유는 **"에이전트의 메모리를 어디서 구축할 것인가"**라는 질문에 대한 새로운 답을 제시하기 때문이다.
지금까지 에이전트 메모리 = 대화 기록 요약이라는 공식이 당연했다. 하지만 파일 시스템에서 작업하는 코워커 에이전트에게는 사용자가 말한 것보다 사용자가 한 것이 훨씬 강한 개인화 신호다. mkdir -p reports/Q1/analysis를 실행하는 사람과 루트에 summary.txt만 만드는 사람은, 대화에서는 비슷한 말을 해도 완전히 다른 작업 스타일을 가진다.
또한 "추상화 시점을 늦추는 것이 정보 보존에 유리하다"는 원칙은 메모리 시스템 설계를 넘어 RAG 파이프라인 전반에 적용할 수 있는 인사이트다. 요약은 압축이고, 압축은 손실이다. 쿼리가 올 때까지 원시 구조를 유지하고, 그때 필요한 수준으로만 추상화하는 전략이 결국 더 나은 결과를 만든다.
다만 현재 한계도 명확하다. 시뮬레이션 기반 데이터이기 때문에 실제 사용자의 messy하고 비일관적인 행동을 얼마나 반영하는지는 미지수이고, 20개 프로파일 × 6차원이라는 설정이 실제 사용자 다양성의 극히 일부만 포착한다는 점도 고려해야 한다.
2026.04.12