ChatGPT 예약 작업이 실행할 때마다 처음부터 다시 시작되는 문제 해결 방법 (2026)

독립형 실행은 의도적으로 새로운 채팅으로 시작됩니다

예약 작업의 기본 형태는 독립성입니다. 각 실행은 새로 시작되어 저장된 프롬프트에 설명된 작업을 수행하고, OpenAI가 수신함으로 설명하는 Scheduled에 보고합니다: "결과가 포함된 예약 작업 실행이 여기에 표시되며, 읽지 않음 표시를 통해 주의가 필요한 실행을 알려줍니다."

이는 주간 보고서, 야간 점검, 월간 요약과 같이 멱등성(idempotent)이 있는 작업에는 훌륭한 설계입니다. 하지만 이슈 분류 작업이 반복되는 이유이기도 합니다. 문서 어디에도 한 실행의 결론을 다음 실행을 위해 보관할 수 있는 공간에 대한 설명은 없습니다. 해당 수신함은 작업이 읽기 위한 것이 아니라 사용자가 읽기 위한 것이기 때문입니다.

여기서 명확히 짚고 넘어갈 필요가 있습니다. 많은 사람들이 이 부분에서 과도한 결론을 내리기 때문입니다. 문서에 명시된 것은 각 독립형 실행이 새로운 채팅을 시작한다는 점입니다. 이전 실행의 결과를 상속받는다는 내용은 전혀 없으며, 작업 자체의 작업 노트를 위한 실행 간 저장소도 문서에 언급되어 있지 않습니다. 연속성이 필요하다면 직접 구성해야 하며, 이것이 이 글의 나머지 부분에서 다룰 내용입니다.

두 가지 모드는 서로 다른 제품이며, 기본값은 기억하지 못하는 모드입니다

두 번째 모드가 있으며, 이는 누적 작업에 대한 직접적인 해결책입니다: "ChatGPT가 일정에 따라 해당 채팅으로 돌아가도록 하려면 기존 채팅 내부에서 작업을 예약하세요. 예약된 작업은 매번 새로운 프롬프트로 시작하는 대신 채팅의 기존 컨텍스트를 사용합니다."

문서에서는 언제 어떤 모드를 사용해야 하는지 명확히 설명합니다. 동일한 컨텍스트를 계속 사용해야 하는 진행 중인 작업의 경우 채팅 내부에서 예약하세요. "각 실행이 독립적이어야 하거나 결과가 Scheduled에 별도의 실행으로 표시되어야 할 때"는 독립형을 사용하세요. 채팅 내 예약의 유스케이스 목록에는 "장시간 실행되는 작업이 완료될 때까지 확인하기", "정해진 주기로 검토 루프를 계속하도록 ChatGPT에 알리기", "컨텍스트를 잃지 않고 진행 중인 조사 또는 분류 채팅 계속하기" 등이 포함됩니다.

대부분의 사람들은 프롬프트 바에서 작업을 생성하면 독립형 작업이 만들어지기 때문에 이러한 선택지가 있다는 사실조차 모릅니다.

이벤트 트리거는 경계를 더 모호하게 만드는 것이 아니라 더 명확하게 만듭니다

8월 25일에 추가된 기능을 통해 "지원되는 Gmail, Slack 또는 GitHub 이벤트가 발생할 때" 작업을 실행할 수 있게 되었습니다. 역할 분담은 명확합니다: "트리거는 작업이 실행되는 시점을 결정하고, 저장된 프롬프트는 각 실행이 수행할 작업을 결정합니다."

이 문장 어디에도 누적되는 요소는 없습니다. 트리거가 실행되면 저장된 프롬프트가 실행될 뿐입니다. 두 가지 제약 조건이 이를 뒷받침합니다: "하나의 작업은 여러 이벤트 트리거를 사용할 수 있지만, 이벤트 트리거와 시간 기반 일정을 결합할 수는 없습니다." 그리고 "여러 개의 일치하는 이벤트가 거의 동시에 도착하면 ChatGPT는 이를 하나의 실행으로 결합할 수 있습니다." 또한 이벤트 트리거 작업은 웹 및 모바일 전용입니다. "ChatGPT 데스크톱 앱, Codex CLI 또는 IDE 확장 프로그램에서는 사용할 수 없습니다."

따라서 가장 반응성이 뛰어난 버전의 예약 작업이 동시에 가장 상태가 없는(stateless) 버전이기도 합니다. 이는 결함이 아니라 트리거의 본질입니다.

실행이 일어나는 위치가 볼 수 있는 범위를 결정합니다

세 가지 환경, 세 가지 접근 범위가 있습니다. 웹의 경우, "웹 작업은 업로드된 컨텍스트와 연결된 도구를 사용할 수 있지만, 컴퓨터의 폴더에서 직접 작업할 수는 없습니다." 데스크톱 앱의 경우, 작업은 "로컬 프로젝트와 함께 작동하고 프로젝트 디렉터리 또는 격리된 작업 트리(worktree)에서 실행될 수 있습니다." 여기에는 두 가지 엄격한 조건이 따릅니다: "예약된 작업에 로컬 파일이 필요할 때는 컴퓨터를 켜두고 앱을 실행 상태로 유지해야 합니다." 그리고 "작업이 실행되도록 예약되었을 때 선택한 프로젝트가 디스크에 여전히 존재해야 합니다." CLI 및 IDE 확장 프로그램에는 예약 작업 관리 인터페이스가 아예 없습니다.

매일 아침 리포지토리를 읽는 작업과 매일 아침 수신함을 읽는 작업은 서로 다른 종류의 작업이며, 실패하는 방식도 다릅니다.

지난주 결과를 프롬프트에 붙여넣기. 일주일 동안은 작동합니다. 하지만 그 이후에는 프롬프트가 변경 로그가 되어 수정할 때마다 늘어나고, 어떤 줄이 지침이고 어떤 줄이 메모인지 아무도 구분할 수 없게 됩니다.

채팅 내부에서 예약하고 정리하지 않기. 올바른 모드이지만 유지 관리가 없는 경우입니다. 실행할 때마다 스레드가 누적되어, 결국 유용한 상태 정보가 스무 번의 일상적인 "보고할 내용 없음" 대화 아래에 묻혀버립니다.

실행 간격 단축하기. 채팅 내 작업은 "활발한 후속 조치 루프"를 위해 분 단위 간격을 지원하므로, 실행 빈도를 연속성의 대안으로 삼고 싶은 유혹에 빠지기 쉽습니다. 하지만 이는 대안이 될 수 없으며, 할 일이 없는 실행에 사용량만 낭비하게 됩니다.

프로젝트가 작업 상태를 유지한다고 가정하기. 프로젝트는 관련 채팅, 파일, 소스를 함께 보관합니다. 이는 정리 도구일 뿐 작업이 기록하는 공간이 아닙니다. 프로젝트가 공유하는 것과 공유하지 않는 것에 대한 내용은 ChatGPT 프로젝트가 메모리를 공유하지 않는 이유에서 다룹니다.

예약 작업은 누적 작업을 수행할 수 없다고 결론 내리기. 가능합니다. 해당 모드가 존재하고 문서에도 명시되어 있습니다. 누락된 것은 기능을 지원하지 않아서가 아니라, 읽어올 수 있는 지속 가능한 저장 공간입니다.

먼저 작업을 분류하는 것부터 시작하세요. 모드 선택은 매우 중요한 결정이며, 잘못된 선택이 문제의 대부분을 차지하기 때문입니다.

각 실행이 보고서, 점검, 요약처럼 완전히 독립적이라면 독립형으로 유지하고 Scheduled를 수신함으로 사용하세요. 만약 실행 시 지난번에 무슨 일이 있었는지 알아야 한다면 채팅 내부에서 예약하고, 프롬프트에 대한 OpenAI의 조언을 진지하게 따르세요: "프롬프트를 지속 가능하게 만드세요. ChatGPT가 각 예약된 실행에서 수행해야 할 작업, 보고할 중요한 내용이 있는지 판단하는 방법, 그리고 언제 중단하거나 입력을 요청해야 하는지를 설명해야 합니다." 마지막 조항은 사람들이 흔히 건너뛰는 부분이지만, 루프가 영원히 보고하는 것을 방지하는 핵심 요소입니다.

활용할 만한 두 번째 방법이 있습니다. 문서에서는 작업 자체를 패키징할 것을 권장합니다: "예약된 작업을 유지 관리하기 쉽고 팀 간에 공유할 수 있도록 하려면, 스킬(skills)을 사용하여 작업을 정의하고 도구와 컨텍스트를 제공하세요. 워크플로우가 자동 도구 선택에 의존해서는 안 될 때 작업 프롬프트에서 특정 스킬을 선택하거나 호출하세요." 스킬은 여러 실행에 걸쳐 절차를 안정적으로 유지합니다. 하지만 어제 이후로 무엇이 바뀌었는지는 보관하지 않습니다.

따라서 모드나 스킬 모두 다루지 못하는 부분, 즉 누적된 상태가 남게 됩니다. MemoryLake는 단일 도구의 외부에 존재하는 메모리 레이어로, 새로운 실행이 무엇이 새로운지 결정하기 전에 읽을 수 있는 정보를 제공합니다. 설정은 세 단계로 진행됩니다.

1단계: API 키 생성

로그인하고 API 키를 생성합니다. 연결하는 여러 도구에서 하나의 자격 증명으로 사용할 수 있습니다.

2단계: 첫 번째 메모리 업로드

각각 하나의 사실을 담은 짧은 항목들입니다. 반복 작업의 경우, "이것이 새로운 내용인가?"라는 질문에 답할 수 있게 해주는 항목들이 유용합니다:

이미 처리된 항목. 분류한 이슈, 무시한 경고와 그 이유, 이미 답변한 고객 질문 등입니다. 이 항목이 넷째 날의 반복을 방지합니다.

작업이 준수해야 하는 상시 결정 사항. 어떤 라벨을 무시해야 하는지, 어떤 리포지토리가 동결되었는지, 어떤 서비스를 누가 담당하는지 등의 정보입니다. 프롬프트를 수정할 때마다 매번 다시 붙여넣어야 했을 사실들입니다.

임계값 및 정의. 무엇을 긴급한 것으로 간주할지, 무엇을 노이즈로 간주할지 정의합니다. 사용자의 판단 기준이 어딘가에 기록되어 있지 않다면 실행 시 이를 적용할 수 없습니다.

외부 포인터. 대시보드, 런북, 트래커 등 작업이 수신함이나 폴더에서 찾을 수 없는 외부 리소스들입니다.

3단계: AI 및 에이전트 연결

사용 중인 도구를 연결하세요. MemoryLake는 MCP 및 API를 통해 접근할 수 있으며, ChatGPT는 연결된 도구를 지원하므로 예약된 작업이 실행될 때마다 동일한 메모리를 참조할 수 있습니다. Codex, Claude Code, Cursor, Cline도 동일한 메모리를 읽을 수 있으므로, 예약 작업이 사람이 다른 곳에서 마무리하는 프로세스의 한 단계일 때 매우 유용합니다.

세 가지 명확한 한계가 있습니다. 이 방법은 예약 작업의 실행 방식을 바꾸지 않습니다. 독립형 실행은 여전히 새로운 채팅을 열고, 이벤트 트리거는 여전히 이벤트별로 실행됩니다. 진정한 대화의 연속성이 필요한 채팅 내 모드를 대체하지는 않습니다. 마지막으로, 메모리는 컨텍스트일 뿐 강제 수단이 아닙니다. 매번 반드시 참이어야 하는 규칙은 에이전트가 따를 수도 있고 따르지 않을 수도 있는 메모가 아니라, 실패 시 차단되는 검증 단계에 두어야 합니다.

반복이 더 이상 기본 동작이 되지 않습니다. 실행 시 보고하기 전에 이미 처리된 항목을 확인할 수 있습니다.

프롬프트가 더 이상 연습장처럼 쓰이지 않습니다. 지침은 지침으로 유지되며, 상태 정보는 작업을 수정하지 않고도 업데이트할 수 있는 별도의 공간에 저장됩니다.

이벤트 트리거 작업을 실제 워크플로우에 사용할 수 있게 됩니다. 풀 리퀘스트 댓글마다 실행되는 트리거도 지난주에 팀이 결정한 사항을 파악할 수 있습니다.

목적에 맞게 모드를 선택할 수 있습니다. 독립적인 실행은 깔끔하게 유지되고, 누적되는 실행은 지속 가능한 프롬프트와 읽어올 수 있는 저장 공간을 갖게 됩니다.

프롬프트를 작성하기 전에 모드를 선택하세요. 독립적인 실행은 독립형으로, 누적되는 작업은 채팅 내 예약으로 설정합니다. 문서에서 각각을 명시하고 있으며, 기본값은 독립형입니다.

채팅 내 프롬프트를 지속 가능하게 만드세요. 각 실행에서 수행할 작업, 보고할 가치가 있는지 판단하는 방법, 그리고 중단하거나 질문할 시점을 모두 프롬프트에 포함하세요.

실행 빈도를 상태 유지의 대안으로 사용하지 마세요. 분 단위 간격은 활발한 후속 조치를 위한 것이지 연속성을 위한 것이 아닙니다.

이벤트 트리거의 일괄 처리(batching)를 고려하세요. 여러 개의 일치하는 이벤트가 동시에 도착하면 하나의 실행으로 결합될 수 있으므로, 단일 항목이 아닌 일괄 처리를 수행할 수 있도록 프롬프트를 작성하세요.

연결 체크리스트를 완료하세요. Slack의 경우, 작업이 감시하는 모든 채널에 @ChatGPT가 있어야 합니다. 리액션, 수정, 삭제 및 다이렉트 메시지는 지원되지 않습니다. GitHub의 경우, 연결된 앱에 리포지토리 접근 권한이 필요합니다.

디버깅 전에 관리자 권한을 확인하세요. 관리형 워크스페이스에서는 이벤트 트리거 예약 작업 허용(Allow event-triggered scheduled tasks) 권한에 의해 액세스가 제어됩니다. 작업이 전혀 실행되지 않는다면 버그가 아니라 정책 문제일 수 있습니다.

데스크톱 작업의 로컬 조건을 유의하세요. 컴퓨터가 켜져 있어야 하고, 앱이 실행 중이어야 하며, 프로젝트가 디스크에 여전히 존재해야 합니다. 작업 트리(worktree)를 사용하면 작업 변경 사항이 진행 중인 작업에 영향을 주지 않도록 격리할 수 있습니다.

절차는 스킬에, 상태는 메모리에 두세요. 이 둘은 서로 다릅니다. 자세한 차이점은 에이전트 스킬이 메모리가 아닌 이유에서 다룹니다.

반복 실행되는 것은 오작동이 아닙니다. 독립형 예약 작업은 "예약된 실행마다 새로운 채팅을 시작"하며, 이러한 독립성은 모든 실행이 독립적이어야 하는 작업을 위해 문서화된 기능입니다. 문제는 작업은 누적되어야 하는데 모드는 그렇지 않을 때 발생합니다.

OpenAI는 동일한 페이지에서 대안을 제시합니다. 기존 채팅 내부에서 작업을 예약하면 "예약된 작업은 매번 새로운 프롬프트로 시작하는 대신 채팅의 기존 컨텍스트를 사용"하며, 수행할 작업, 보고할 가치가 있는 항목을 판단하는 방법, 중단할 시점을 명시한 지속 가능한 프롬프트를 사용합니다. 절차를 스킬로 패키징하여 여러 실행에 걸쳐 안정적으로 유지되도록 하세요. 그리고 가장 최근에 도입되었으며 가장 상태가 없는 형태인 이벤트 트리거 작업의 경우, 트리거와 저장된 프롬프트의 조합이 메커니즘 자체에서 제공하는 연속성의 전부라는 점을 받아들여야 합니다.

남은 것은 상태 정보입니다. 이미 처리된 항목, 긴급한 항목의 기준, 팀이 이미 결정한 사항 등입니다. 이를 작업 프롬프트 외부의, 새로운 실행이 읽을 수 있는 레이어에 보관하면 넷째 날의 실행이 둘째 날의 내용을 반복하지 않게 됩니다. 구조적으로 실행 시 상태를 유지하지 않는 에이전트에 적용되는 이 논리의 일반적인 버전은 OpenClaw가 이전 실행을 잊어버리는 이유 및 상태가 없는 MCP 서버를 위한 메모리에서 확인할 수 있습니다.