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