컴퓨터를 쓰는 에이전트가 매번 똑같은 루틴을 다시 유추하느라 프롬프 토큰을 쓰고 있습니다. 사용자가 아침에 PR을 검토하고 점심 후에 컨텍스트 스위칭을 40번 했다는 사실을 에이전트는 알 수 없습니다. 지금의 에이전트 메모리는 “사용자가 한 말”은 기억하는데 “사용자가 한 일”은 기억하지 않기 때문입니다.
이 논문(arXiv:2608.05784)은 화면 캡처 스트림을 결정론적 코드만으로 에이전트 메모리로 컴파일하는 파이프라인을 제안합니다. 핵심은 모델을 컴파일 경로에서 완전히 빼는 것입니다.
문제: 캡처는 있는데 메모리는 없다
화면 캡처 자체는 이미 상용화되어 있습니다. Microsoft Recall, OpenAI Chronicle, ActivityWatch가 다 캡처를 합니다. 근데 캡처된 원시 데이터를 에이전트가 쓰려면 문제가 생깁니다.
하루 치 캡처가 대략 2,000줄의 스냅샷 행을 만듭니다. 이걸 그대로 에이전트에 넣으면 126,812 토큰이 나옵니다. LLM으로 요약하면 되긴 하는데, 요약은 실행마다 결과가 달라지고, 존재하지 않는 활동을 지어내기도 합니다.
두 가지 소비 방식이 있는데 둘 다 문제가 있습니다:
| 방식 | 문제 |
|---|---|
| 원시 검색 | 토큰 과다 (하루 126K), 세션화·중복 제거를 모델이 런타임에 처리 |
| LLM 요약 | 비용 발생, 비결정론적, 환각 위험, 긴 입력에서 신뢰성 저하 |
해법: 결정론적 컴파일
제안하는 파이프라인은 스냅샷 스트림을 “활동 프레임(activity frame)“으로 컴파일합니다. 컴파일러는 모델을 전혀 쓰지 않습니다.
활동 프레임이란 무엇인가 — 하나의 관심 구간으로, 애플리케이션과 사이트가 고정된 시간 구간입니다. 예를 들어:
id: f-0007
app: "Google Chrome"
site: "linkedin.com"
start: "20:24:04"
end: "20:42:11"
duration_min: 18.0
pages:
- {kind: people_search, entity: "cto paris", count: 2}
- {kind: profile, entity: "jane-doe"}
input: {keys: 214, clicks: 31}
evidence: {frame_ids: "99871..100147"}모든 필드가 코드로 계산됩니다. evidence 포인터가 원시 행을 가리키므로, 검증하려면 해당 행을 다시 읽으면 됩니다.
그림 1. 측정 계층(파란색)은 결정론적 코드가 캡처 데이터베이스에서 생성합니다. 추론 계층(주황색)은 선택적이며, 증거 링크와 신뢰도 태그가 있어야 합니다.
세그먼테이션 규칙
세 개의 상수가 세그먼테이션을 결정합니다. 튜닝이 아니라 캡처 주기에서 도출한 값입니다.
- Dwell: 다음 프레임까지의 갭을 90초로 상한. 화면이 켜진 상태에서 한 컨텍스트가 머문 시간을 측정
- 세션 갭: 90초 이상 입력이 없으면 세션 종료
- 플리커 머지: 20초 미만의 잠깐 이탈은 인접 프레임에 병합하되 기록은 남김
타입드 페이지 레퍼런스
브라우저 프레임은 URL을 파싱해서 타입드 페이지 레퍼런스를 만듭니다. profile, search, repo, pull_request, email, ai_chat 등 46종의 타입이 있습니다. 매칭되는 파서가 없으면 도메인과 함께 제네릭 페이지로 떨어집니다. 타입 시스템에서 데이터가 손실되지 않습니다.
2티어 구조
측정 티어와 추론 티어를 분리합니다. 추론 티어(태스크 라벨, 프로젝트 클러스터 등)는 세 가지 규칙을 따라야 합니다: 네임스페이스가 있을 것, 신뢰도 태그가 있을 것, 증거 링크가 있을 것. 추론 티어를 통째로 삭제해도 측정 티어는 유효한 문서로 남습니다.
이 구조가 메모리 공격에 대한 방어가 됩니다. 증거 포인터가 있어서 각 프레임을 기계적으로 재검증할 수 있고, 측정/추론 경계가 있어서 추론 라벨이 사실처럼 위장할 수 없습니다.
구현: MCP 서버 포함
참조 구현은 의존성 없는 Python 컴파일러로, 로컬 캡처 엔진, CLI, MCP 서버를 포함합니다. MCP 서버는 6개의 도구를 MCP 지원 에이전트에게 노출합니다.
전체 파이프라인이 로컬에서 동작합니다. 캡처, 저장, 컴파일 모두 사용자 머신에서 일어나고, 컴파일러는 데이터베이스를 읽기 전용으로 엽니다. 입력 내용(타이핑한 텍스트)은 스키마 요구사항으로 기본 제외입니다.
결과: 86배 압축, 68밀리초, 98.4% 정확도
토큰 비용
하루 치 데이터(2,066행)를 세 가지 표현으로 비교했습니다.
| 표현 | 토큰 수 | 압축비 |
|---|---|---|
| 원시 JSON 행 | 126,812 | — |
| 스키마 v1 문서 (222프레임) | 34,815 | 3.6배 |
| 컴팩트 컨텍스트 블록 | 1,469 | 86배 |
그림 4. 하루 치 데이터를 세 가지 표현으로 토큰화한 결과(cl100k_base). 결정론적 컴파일이 86배 감소, 추론 비용 0.
86배 압축된 블록은 시스템 프롬프트에 매번 넣을 수 있을 만큼 작습니다.
QA 정확도
8일 치 데이터에 64개 질문으로 독립 SQL 오라클과 비교했습니다. 두 모델 티어(Sonnet 4.5, Opus 4.5)로 테스트했습니다.
| 표현 | Sonnet 정확도 | Opus 정확도 | Sonnet 지속시간 오차 |
|---|---|---|---|
| 원시 행 | 66.1% | 75% | 7.3% |
| LLM 요약 | 80.4% | 80.4% | 135.7% |
| 활동 프레임 블록 | 98.4% | 98.4% | 7.3% |
결정론적 블록을 읽으면 미드티어 모델이 프론티어 모델과 동일한 정확도를 냅니다. 요약은 유창한 문장 뒤에 숨어서 지속시간을 2.9배 부풀리고, 존재하지 않는 야간 세션을 지어냈습니다.
요약은 매 실행마다 다른 결과가 나옵니다. 활동 프레임 블록은 3회 재생성에서 바이트 단위로 동일했습니다.
지연과 재현성
하루 전체 컴파일에 68밀리초가 걸립니다. 같은 데이터를 두 번 컴파일하면 생성 타임스탬프를 제외하고 바이트 단위로 동일한 문서가 나옵니다.
표 2. 51일 활동 기간 동안 수집된 코퍼스 통계.
하루는 얼마나 파편화되어 있는가
43일 치 컴파일 결과 17,514개 프레임이 나왔고 중앙값은 0.5분이었습니다. 68%가 1분 미만입니다. 근데 이 안에 두 가지 기계적 효과가 있습니다:
- 52%의 서브-1분 프레임은 단일 스냅샷(통과 transit). 평균 6.1초
- 20%는 듀얼 모니터 구간. 모니터마다 별도 스트림이 있어서
단일 스냅샷을 제외하면 중앙값은 0.9분로 올라갑니다. 이는 인터럽션 연구가 측정한 “3분 작업 구간”과 “75%가 1분 미만”이라는 기존 결과와 일관됩니다.
그림 5. 43일 동안 17,514개 프레임의 활동 지속시간 분포. 중앙값 0.5분이지만 서브-1분 막대의 52%는 단일 스냅샷 통과입니다.
루틴 오버헤드 비율 R
컴파일러는 메모리를 만들 뿐 아니라 비용 측정 도구도 됩니다. 반복되는 루틴을 컴파일된 스크립트로 줄일 수 있으니까, “에이전트가 같은 루틴을 다시 유추하면 얼마나 낭비인가”를 측정할 수 있습니다.
이 값을 루틴 오버헤드 비율 R이라고 부릅니다.
- R = 에이전트 재유추 비용 / 컴파일된 리플레이 비용
- 분모는 실측, 분자는 모델링
- 가드 플랜 기준: R = 60배 (중앙값)
- 최소 스크립트 기준: R = 343배 (중앙값)
루틴 재발률 h
재발률 h는 전체 액션 스텝 중 반복 루틴에 속하는 비율입니다.
- 원시 재발률: 83.1% (의미 없는 미세 반복 포함)
- 위임 가능 재발률: 9.0% (2개 이상 식별 가능 타겟이 있는 루틴)
- 시간 홀드아웃 예측: 7.7%
전체 플릿 절감 상한은 h × (1 - 1/R) ≈ 7.7%입니다. 웹 페이지 재방문률(40-58%)과 혼동하면 안 됩니다. 재방문은 위임 가능한 작업이 아닙니다.
라이브 리플레이 증명
2단계 루틴(작성 화면 열기, 초안 타이핑)을 라이브 브라우저에서 실행했습니다. 양쪽 스텝 모두 접근성 트리로 그라운딩, 실행 시 모델 토큰 0건이었습니다. 같은 플랜을 다른 페이지에서 실행하면 아무것도 매칭되지 않아서 안전하게 실패합니다.
한계
- 단일 사용자 코퍼스 (1인, 51일). 다중 사용자 확장은 향후 과제
- 캡처 엔진별 어댑터 필요 (스키마는 엔진 무관이지만)
- 측정 티어는 의도를 알 수 없습니다. “프로파일 뷰 2건”은 보고하는데 “영업 활동”은 아닙니다
- 화면 머무름 시간이 주의와 같지 않습니다. 입력이 없는 구간이 45%의 활동 시간을 차지합니다
- R의 분자와 3개 팔 달러 비교는 모델링이지 실청구가 아닙니다
더 실습해보고 싶은 분들께
이 논문은 에이전트 메모리, 하네스 엔지니어링, MCP 생태계에 직접적인 기여를 합니다. 결정론적 컴파일이 에이전트 비용 구조를 어떻게 바꾸는지 더 알고 싶다면:
코드와 스키마, 평가 하네스는 https://github.com/nossa-y/activity-frames 에서 공개되어 있습니다.