Codex Computer History, 끊긴 작업을 다시 찾는 법 | DAKER 커뮤니티
Codex Computer History의 핵심은 멈춘 작업을 다시 찾는 속도와 기록 통제권을 함께 설계하는 것입니다. Codex Computer History란, 허용한 앱과 웹사이트의 최근 활동을 기억과 타임라인으로 바꿔 ChatGPT와 Codex가 참고하게 하는 기능입니다. 아침에 다시 앉았을 때 열린 탭은 사라졌고, 어제 보던 문서 이름도 흐릿할 수 있습니다. 이 기능은 그때 “어디서 멈췄는지”를 찾는 출발점이 됩니다.
문제 상황: 왜 어제의 작업은 오늘 다시 흩어질까요?
작업은 보통 한 파일에서 끝나지 않습니다. 문서, 이슈, 브라우저 탭, 터미널 로그가 함께 움직입니다. 중간에 회의나 장애 대응이 끼어들면 다음 실행에서 Codex에게 무엇을 이어 달라고 해야 할지부터 막힙니다.
핵심 개념: Codex Computer History는 무엇을 기억하나요?
Codex Computer History의 핵심은 멈춘 작업을 다시 찾는 속도와 기록 통제권을 함께 설계하는 것입니다. 작성 기준일 공식 문서는 이 기능이 macOS용 ChatGPT 데스크톱 앱에서 기본 꺼짐 상태이며, Pro 사용자는 직접 켤 수 있고 Business와 Enterprise는 관리자가 먼저 접근을 허용해야 한다고 안내합니다. 공개 본문에는 DAKER 정책에 맞춰 DAKER 내부 링크만 남기고, 외부 공식 문서 주소는 비공개 검증 노트에만 기록했습니다.
한 줄 요약은 이렇습니다. 작업을 되찾는 기능을 켜기 전에, 어떤 앱이 기록에 들어가도 되는지부터 좁혀야 합니다. 기억은 편의 기능이고, 통제는 운영 기준입니다.
단계별 사용법: 켜기 전 어떤 순서로 점검해야 할까요?
처음부터 모든 활동을 맡기지 말고, 멈춘 작업을 찾는 최소 흐름부터 시작하세요. 아래 순서는 개인 개발자와 관리형 팀 모두에게 필요한 기본 점검입니다.
- 먼저 이 기능을 켜야 하는 이유를 한 문장으로 정합니다. 예를 들어 멈춘 개발 작업, 흩어진 문서, 반복 워크플로 중 하나만 고릅니다.
- 기록에 포함할 앱과 웹사이트를 최소 범위로 고릅니다. 민감한 메신저, 결제, 인사, 고객 데이터 화면은 처음부터 제외합니다.
- 기록을 잠시 멈추는 위치와 삭제 위치를 확인합니다. 팀에서는 이 절차를 온보딩 문서나 AGENTS 파일의 개인정보 섹션과 함께 둡니다.
- 첫 요청은 과거 일을 실행하게 하지 말고 찾게 만듭니다. 최근에 보던 문서와 남은 결정만 요약하라고 요청합니다.
- 반복되는 흐름이 보이면 바로 자동화하지 말고, 성공 기준과 제외 화면을 확인한 뒤 스킬이나 자동화 후보로 넘깁니다.
짧은 예시: 멈춘 리뷰 작업을 어떻게 다시 찾나요?
예를 들어 어제 PR 리뷰 중에 테스트 실패 로그와 설계 문서를 번갈아 보다가 멈췄다고 해봅시다. 다음 날 첫 요청은 “어제 보던 PR을 수정해 줘”가 아니라 “어제 확인하던 PR, 문서, 남은 결정 후보를 찾아 요약해 줘”가 안전합니다. 그다음 현재 파일과 테스트를 다시 읽게 해야 실제 수정으로 넘어갈 수 있습니다.
| 상황 | 기록 없이 다시 시작 | Computer History 사용 |
|---|---|---|
| 중단 뒤 복귀 | 열어 둔 탭과 파일을 사람이 다시 찾습니다 | 최근 활동 타임라인에서 출발점을 좁힙니다 |
| 반복 업무 | 매번 절차를 말로 다시 설명합니다 | 반복 패턴을 스킬이나 자동화 후보로 검토합니다 |
| 보안 통제 | 무엇이 남았는지 흐려질 수 있습니다 | 허용 앱, 일시 중지, 삭제 기준을 먼저 세웁니다 |
| 검증 | 기억에 의존하기 쉽습니다 | 현재 문서와 파일을 다시 읽어 최신성을 확인합니다 |
워크플로 이미지: 기록은 어디까지 열어야 할까요?
핵심은 넓게 켜는 것이 아니라 좁게 시작하는 것입니다. 기록 대상과 제외 대상을 먼저 나누면, 기억을 업무 속도로 쓰면서도 민감 화면이 섞이는 위험을 줄일 수 있습니다.
실수 방지 체크리스트: 기억보다 먼저 막아야 할 것은 무엇인가요?
Computer History는 다시 찾는 기능이지 모든 활동을 맡겨도 된다는 허가가 아닙니다. 아래 항목을 먼저 확인하고 켜야 팀 운영에서 설명 가능한 기준이 남습니다.
- 민감 화면이 포함될 수 있는 앱을 처음부터 기록 대상에서 제외했나요?
- 기록을 멈추고 삭제하는 방법을 팀원이 스스로 찾을 수 있나요?
- Computer History를 항상 켜는 규칙이 아니라 필요한 작업에만 쓰는 기준을 정했나요?
- 기억이 최신 파일 상태를 보증한다고 오해하지 않도록 검증 단계를 따로 뒀나요?
- 관리형 워크스페이스에서는 관리자 허용 여부와 지역 제공 여부를 먼저 확인했나요?
공식 출처와 함께 볼 DAKER 글은 무엇인가요?
기능 사실은 작성 기준일에 OpenAI 공식 공개 문서로 비공개 검증했습니다. 공개 본문에는 DAKER 정책에 맞춰 확인된 DAKER 내부 링크만 남깁니다.
FAQ: Codex Computer History에서 자주 묻는 질문은 무엇인가요?
Computer History를 켜면 화면 녹화가 저장되나요?
공식 설명 기준으로 화면 녹화나 마이크 입력을 저장하는 기능은 아닙니다. 다만 허용한 앱과 웹사이트의 활동 이벤트가 기억과 타임라인으로 바뀌므로 대상 범위를 좁혀야 합니다.
API 키로 로그인한 Codex에서도 쓸 수 있나요?
작성 기준일 공식 설명은 Computer History가 API key나 Amazon Bedrock 사용 환경에서는 제공되지 않는다고 안내합니다.
팀에서 바로 전체 허용해도 되나요?
권장하지 않습니다. Business와 Enterprise는 관리자 허용이 먼저 필요하고, 허용 뒤에도 팀별 민감 앱 제외와 삭제 절차를 먼저 정해야 합니다.
기억이 있으면 현재 파일을 다시 읽지 않아도 되나요?
아닙니다. Computer History는 출발점을 찾는 데 도움을 주지만, 현재 파일과 문서 상태는 작업 직전에 다시 확인해야 합니다.
처음 켤 때 가장 안전한 요청은 무엇인가요?
최근에 보던 문서와 남은 결정만 찾아 달라는 읽기 중심 요청이 좋습니다. 파일 수정이나 외부 전송은 기록 통제 기준을 확인한 뒤 맡기세요.
오늘 이 기능을 켠다면, 먼저 기록 대상 앱 세 개만 고르고 “찾기 전용” 요청으로 시작해 보세요. 작업을 되찾는 속도는 그 다음에 붙여도 늦지 않습니다.