| Developed by | OpenAI |
|---|---|
| Type | Tool |
| Aliases | chronicle screen memory |
| Related | Codex (OpenAI), 컴퓨터 사용 (에이전트), 워크스페이스 에이전트 |
무엇인가
[[codex]]는 OpenAI가 만든 AI 도우미인데, Chronicle은 그 Codex에게 "사용자가 화면에서 방금 무엇을 하고 있었는지" 자동으로 기억해 주는 실험 기능이다. 친구와 대화할 때 "아까 보던 그거 있잖아"라고 하면 친구는 그게 뭔지 안다 — 같은 화면을 잠깐 같이 봤기 때문이다. Chronicle은 Codex에게 그런 짧은 공유 기억을 만들어 주려는 시도라고 보면 된다.
왜 만들었을까
Codex가 코딩 도구를 넘어 일상적인 컴퓨터 작업까지 도와주려면, 사용자가 매번 "지금 내 화면에는 이런 게 떠 있어"라고 설명해야 하는 번거로움이 있었다. 디자인 도구에서 작업하던 화면, 메일에서 읽던 문장, IDE에서 띄워둔 에러 메시지 — 이런 것을 일일이 스크린샷으로 붙여 넣지 않아도 되게 만든 것이 Chronicle이다.
어떻게 쓰나
Chronicle이 켜져 있으면 Codex는 화면을 주기적으로 "본다". 그리고 사용자가 "방금 그 화면에서 뭐가 잘못된 거야?"라고 물으면, 그 최근 장면을 함께 떠올려서 답한다. 사용자는 따로 캡처를 하지 않아도 된다.
다만 이 기능은 아직 실험 단계다. 어떤 화면이 얼마나 오래, 어디에 저장되는지를 OpenAI는 자세히 밝히지 않았다. 그래서 비밀번호 관리자나 개인정보가 떠 있는 시간에는 일단 꺼두는 것이 안전하다.
비슷한 흐름
[[computer-use]]나 [[workspace-agents]]처럼 AI가 사람의 작업 환경을 직접 보고 도와주는 큰 흐름의 일부로 이해하면 좋다. 차이가 있다면, Chronicle은 "화면을 직접 조작"하는 게 아니라 "화면을 옆에서 지켜보며 기억"하는 쪽에 초점이 있다는 점이다.
개요
Chronicle은 [[codex]]에 붙은 화면 컨텍스트 메모리 기능이다. 사용자가 명시적으로 스크린샷을 첨부하지 않아도, Codex가 최근 화면에서 관찰한 정보를 자동으로 답변에 활용한다. OpenAI는 이를 "screen memory"라는 이름으로도 지칭한다.
현재까지 알려진 동작
- 화면 캡처는 OS 권한이 필요하며, 사용자가 명시적으로 켜야 활성화된다.
- Codex 세션 안에서 "방금 화면에서 본 것"에 대한 자연어 질의를 받는다.
- 캡처 주기, 보관 기간, 서버 전송 여부, 인덱싱 방식은 공식 문서가 아직 없다.
마지막 항목이 핵심이다. 캡처 주기와 전송 경로가 불투명하면 기업 환경에서 그대로 켜기 어렵다.
사용 패턴
- 디자인·문서 작업: "이 부분을 Codex에게 설명"하는 단계에서 캡처 + 붙여넣기 절차를 생략한다.
- 코드 리뷰: IDE 화면을 그대로 둔 채 Codex에게 질의하면, 현재 보이는 파일·에러 메시지를 함께 본 상태로 답한다.
- 여러 앱 전환: 브라우저 → 터미널 → 디자인 툴을 오갈 때, 마지막 컨텍스트를 다시 설명할 필요가 줄어든다.
주의점
- 민감 정보 노출: API 키, 비밀번호 매니저, 환자 정보 같은 화면이 잠깐이라도 떠 있으면 그 프레임이 캡처 대상에 들어갈 수 있다. 작업 도메인에 따라 아예 꺼두는 것이 안전하다.
- 검증 가능성: Codex가 "방금 본 화면"을 근거로 답하는지, 아니면 학습 지식만으로 답하는지 사용자가 구별하기 어렵다. 핵심 결정은 별도 근거로 다시 확인해야 한다.
- 저장 위치: 로컬 캐시인지 OpenAI 서버로 전송되는지가 명시되지 않았다. 컴플라이언스가 필요한 환경에서는 채택 전에 공식 문서를 요구하는 것이 합리적이다.
관련 흐름
[[computer-use]]가 "AI가 화면을 조작"하는 축이라면 Chronicle은 "AI가 화면을 본다"는 보다 수동적인 축이다. [[workspace-agents]]와 결합되면, 같은 화면 컨텍스트를 여러 에이전트가 공유하는 구조로 발전할 수 있다.
개요
Chronicle은 [[codex]]가 사용자의 화면을 비전-언어 입력으로 받아 단기 메모리를 구성하는 실험 기능이다. 발표 시점에 OpenAI는 캡처 주기, 인덱싱, 보관 기간, 전송 경로 등 핵심 운영 파라미터를 공개하지 않았다. 따라서 아래 내용은 공개된 단서와 비교 가능한 기존 시스템에서 추론한 구현 가설이다.
구현 가설
1. 비전-언어 임베딩 + RAG
화면 프레임을 멀티모달 인코더로 임베딩하고, 사용자 질의 시점에 의미 유사도로 검색해 컨텍스트로 주입하는 구성. CLIP 계열 또는 GPT-4o의 비전 백본을 재사용할 수 있다. 자연어 질의에 강하다는 장점이 있는 반면, 텍스트가 빽빽한 화면(IDE·스프레드시트)에서는 OCR 품질이 임베딩 품질을 좌우한다.
2. 이벤트 트리거 캡처
활성 윈도우 변경, 키 입력, 클립보드 갱신처럼 의미 있는 사건이 발생할 때만 프레임을 저장. 고정 주기 캡처보다 저장량이 훨씬 작고, 사용자의 "지금 막 한 것"과 캡처 시점이 자연스럽게 정렬된다. [[computer-use]] 계열과 같은 OS 후크를 공유할 가능성이 크다.
3. 접근성 API 텍스트 스트림
화면 픽셀 대신 OS 접근성 트리(macOS AX, Windows UI Automation)에서 텍스트·위계 구조를 추출해 인덱싱. 픽셀 캡처보다 가볍고 정확하지만 게임·캔버스 앱·웹 캔버스에서는 정보가 비어 있다. 픽셀과 접근성 정보를 혼합해 사용하는 구성이 일반적이다.
실제 Chronicle은 위 세 축을 혼합한 형태일 가능성이 높다.
비교 가능한 기존 시스템
- Microsoft Recall: Windows 11에서 화면을 주기적으로 캡처해 로컬에 인덱싱한다. 출시 직후 평문 저장과 빈약한 보안 모델로 강한 비판을 받고 옵트인·암호화로 재설계됐다. Chronicle이 같은 함정을 피하려면 명시적 옵트인, 키 관리, 민감 영역 자동 마스킹이 필요하다.
- Rewind.ai: 로컬 우선 화면 메모리. 모든 데이터를 로컬 디스크에 보관하고 압축·OCR 인덱싱한다. 클라우드 전송이 없다는 점이 신뢰 모델의 핵심.
- Apple Intelligence "Onscreen Awareness": 현재 활성 화면 한 장만을 모델에 넘기는 보수적 설계로, 캡처를 누적하지 않는다.
한계와 미해결 문제
- 프라이버시 경계: 비밀번호 매니저·의료 기록 등이 우연히 프레임에 들어왔을 때 마스킹 정책이 자동으로 작동해야 한다. OCR 후 PII 분류기를 거치는 방식이 표준 후보이지만, 추가 모델 호출 비용과 지연이 발생한다.
- 답변 검증성: 답변 근거가 "방금 본 화면"인지 사전 학습 지식인지 명시되지 않으면 사용자가 사실성을 평가하기 어렵다. retrieval 결과를 답변에 명시적으로 인용하는 형태가 필요하다.
- 시간성: "방금 본 것"이 5초 전인가 5분 전인가에 따라 사용자가 의도한 컨텍스트가 달라진다. 시간 가중 검색 또는 명시적 시간 필터가 요구된다.
- 다중 디스플레이·가상 데스크톱: 사용자의 작업 단위와 OS 캡처 단위가 어긋날 때 컨텍스트가 섞일 수 있다.
- 에이전트 공유 모델: [[workspace-agents]]처럼 여러 에이전트가 같은 화면 메모리를 공유하는 시나리오에서 ACL과 감사 로그가 어떻게 정의되는지 미정이다.
OpenAI가 공식 백서를 내놓기 전까지 이 모든 항목은 가설로 남는다.