예약 작업

ChatGPT 계정으로 로그인한 Codex에서는 2026년 10월 14일 태평양 일광 절약 시간(PDT) 기준 정오(19:00 UTC)에 GPT-5.5 지원이 종료됩니다. Codex에서 GPT-5.5를 사용하는 예약 작업을 확인하고, 요금제와 워크스페이스에서 이용할 수 있다면 gpt-6.1-sol(GPT-6.1 Sol)을 선택하세요. OpenAI API와 API 키로 인증한 Codex 세션은 영향을 받지 않습니다. 요금제별 대체 모델은 GPT-5.5 지원 종료를 참고하세요.

ChatGPT 데스크톱 앱에서는 로컬 프로젝트의 작업을 예약하고 프로젝트 디렉터리나 별도의 작업 트리에서 실행할 수 있습니다. 예약 작업에 로컬 파일이 필요하다면 컴퓨터와 앱을 켜 두세요.

워크스페이스에서 예약 작업이 활성화되어 있다면 웹의 Chat 또는 ChatGPT Work에서 작업을 만들고 예약 작업에서 실행 내역을 관리하세요. 웹에서 실행하는 작업은 업로드한 컨텍스트와 연결된 도구를 사용할 수 있지만 컴퓨터의 폴더에서 직접 작업할 수는 없습니다.

Codex CLI에는 예약 작업 관리 화면이 없습니다. ChatGPT 웹이나 데스크톱 앱에서 예약 작업을 만들고 관리하세요. CLI에서 먼저 프롬프트, 스킬 또는 스크립트를 준비하고 테스트할 수 있습니다.

IDE 확장 프로그램에는 예약 작업 관리 화면이 없습니다. ChatGPT 웹이나 데스크톱 앱에서 예약 작업을 만들고 관리하세요. IDE 확장 프로그램에서 먼저 프롬프트, 스킬 또는 워크스페이스 변경 사항을 준비하고 테스트할 수 있습니다.

웹에서 예약 작업 관리하기

예약 작업을 열어 작업 상태와 최근 실행 내역을 확인하세요. 매번 저장된 프롬프트로 작업을 시작하려면 독립형 예약 작업을 사용하세요. ChatGPT가 같은 채팅으로 돌아와 기존 컨텍스트를 사용하도록 하려면 해당 채팅 안에서 작업을 예약하세요.

웹의 예약 작업은 업로드한 파일과 해당 채팅에서 사용할 수 있는 연결된 도구, 스킬, 플러그인을 활용할 수 있습니다. 실행이 끝나면 다음 실행을 위해 로컬 폴더나 작업 트리를 유지하지 않습니다. 매번 적용할 지침은 작업 프롬프트나 첨부한 스킬에 적고, 필요한 원본 자료는 접근 가능한 프로젝트, 업로드 파일 또는 연결된 서비스에 보관하세요.

작업을 예약하기 전에 일반 웹 채팅에서 프롬프트를 테스트하세요. 처음 몇 번의 실행 결과를 검토하고, 결과가 지나치게 포괄적이거나 컨텍스트가 더 필요하다면 프롬프트, 도구 또는 실행 주기를 조정하세요.

앱 이벤트가 발생할 때 작업 실행하기

이 기능을 지원하는 요금제에서는 Gmail, Slack 또는 GitHub에서 지원되는 이벤트가 발생하면 예약 작업을 실행할 수 있습니다. 이벤트 기반 작업은 ChatGPT 웹과 모바일에서 사용할 수 있습니다. ChatGPT 데스크톱 앱, Codex CLI, IDE 확장 프로그램에서는 지원하지 않습니다.

ChatGPT에 작업을 만들어 달라고 요청한 다음, 어떤 이벤트를 감지하고 이벤트가 발생하면 무엇을 해야 하는지 설명하세요. 트리거는 작업의 실행 시점을 결정하고, 저장된 프롬프트는 매번 실행할 내용을 정합니다. 한 작업에 여러 이벤트 트리거를 설정할 수 있지만 이벤트 트리거와 시간 기반 일정을 함께 사용할 수는 없습니다.

다음 이벤트를 트리거로 사용할 수 있습니다.

• Gmail: 새 메일을 수신하면 실행합니다. 보낸 사람이나 제목으로 필터링할 수 있습니다.
• Slack: 선택한 채널에 새 메시지가 올라오면 실행합니다. 작성자를 기준으로 필터링하고 스레드 답글을 포함할지도 정할 수 있습니다. 반응, 메시지 수정 및 삭제, 다이렉트 메시지는 지원하지 않습니다.
• GitHub: 리포지터리에서 pull request 관련 활동이 발생하면 실행합니다. 특정 pull request, 작성자, 제목 또는 레이블로 필터링하고, 리뷰, 댓글, 커밋 업데이트를 트리거로 사용할지 아니면 병합할 때만 실행할지 선택하세요.

작업을 만들기 전에 앱을 연결하고 필요한 권한을 부여하세요. Slack에서는 작업이 모니터링할 모든 채널에 @ChatGPT를 추가하세요. GitHub에서는 연결된 앱에 해당 리포지터리에 접근할 권한이 있어야 합니다.

조건에 맞는 이벤트가 짧은 시간에 여러 건 발생하면 ChatGPT가 한 번의 실행으로 묶어 처리할 수 있습니다. 예약 작업을 열어 대기 중인 이벤트를 확인하거나 지금 실행을 선택해 처리하세요.

이용 가능 여부는 요금제와 워크스페이스 설정에 따라 달라집니다. 관리형 워크스페이스에서는 관리자가 이벤트 기반 예약 작업 허용 권한으로 접근을 제어할 수 있습니다.

예를 들어 텔레메트리에 기록된 오류를 분석해 수정 사항을 제출하거나 최근 코드베이스 변경 사항을 보고서로 정리하는 작업을 예약할 수 있습니다. 같은 컨텍스트를 계속 사용해야 하는 작업이라면 기존 채팅 안에서 작업을 예약하세요.

프로젝트 단위로 작업을 예약했다면 컴퓨터와 ChatGPT 데스크톱 앱을 켜 두세요. 예약된 실행 시점에 디스크에서 선택한 프로젝트에 접근할 수 있어야 합니다.

Git 리포지터리에서는 예약 작업을 로컬 프로젝트에서 실행할지 새 작업 트리에서 실행할지 선택할 수 있습니다. 두 방식 모두 백그라운드에서 실행됩니다. 작업 트리를 사용하면 예약 작업의 변경 사항을 아직 끝내지 않은 로컬 작업과 분리할 수 있습니다. 로컬 프로젝트에서 실행하면 현재 편집 중인 파일이 바뀔 수 있습니다. 버전 관리 대상이 아닌 프로젝트에서는 예약 작업이 프로젝트 디렉터리에서 직접 실행됩니다.

모델과 추론 수준은 기본 설정을 그대로 사용해도 됩니다. 예약 작업의 실행 방식을 더 세밀하게 제어하려면 직접 선택하세요.

예약 작업이 지원 종료된 모델을 사용한다면 이용 가능한 대체 모델로 변경하세요. 모델 마이그레이션 안내를 참고하세요.

예약 작업은 기본 샌드박스 설정에 따라 사용자 개입 없이 실행됩니다. 작업을 완료하는 데 필요한 최소한의 권한으로 시작하고, 필요한 경우에만 네트워크 접근을 허용하거나 파일 접근 범위를 넓히세요. 자세한 내용은 샌드박스 알아보기를 참고하세요.

예약 작업 관리하기

ChatGPT 데스크톱 앱 사이드바의 예약 작업에서 모든 예약 작업과 실행 내역을 확인할 수 있습니다.

예약 작업 화면은 받은편지함 역할을 합니다. 보고할 내용이 있는 실행 결과가 이곳에 표시되며, 확인이 필요한 결과에는 읽지 않음 표시가 나타납니다.

독립형 예약 작업은 예약된 시각마다 새 채팅을 시작하고 예약 작업에 결과를 표시합니다. 각 실행이 독립적이어야 하거나 하나의 예약 작업을 하나 이상의 프로젝트에 적용하려면 이 방식을 사용하세요. 실행 주기를 직접 지정하려면 사용자 지정 일정 설정을 사용하세요. 더 복잡한 일정은 RFC 5545 반복 규칙(RRULE)을 편집해 설정할 수 있습니다. 예를 들어 매월 1일 오전 9시에 실행하는 규칙은 RRULE:FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=9;BYMINUTE=0입니다.

Git 리포지터리에서는 각 예약 작업을 로컬 프로젝트나 백그라운드 실행 전용 작업 트리에서 실행할 수 있습니다. 예약 작업의 변경 사항을 아직 끝내지 않은 로컬 작업과 분리하려면 작업 트리를 사용하세요. 기본 체크아웃에서 직접 작업하려면 로컬 모드를 사용하세요. 이 모드에서는 예약 작업이 현재 편집 중인 파일을 변경할 수 있습니다. 버전 관리 대상이 아닌 프로젝트에서는 예약 작업이 프로젝트 디렉터리에서 직접 실행됩니다. 같은 예약 작업을 여러 프로젝트에서 실행할 수도 있습니다.

웹의 ChatGPT Work에서 만든 예약 작업과 데스크톱 앱의 ChatGPT Work 또는 Codex에서 만든 예약 작업은 플러그인을 사용할 수 있습니다. 예약 작업에는 스킬도 사용할 수 있습니다. 예약 작업을 쉽게 관리하고 여러 팀에서 공유하려면 스킬에 수행할 동작을 정의하고 필요한 도구와 컨텍스트를 제공하세요. 워크플로우가 자동 도구 선택에 의존하지 않아야 한다면 작업 프롬프트에서 특정 스킬을 선택하거나 호출하세요.

ChatGPT에 예약 작업 생성 또는 업데이트 요청하기

ChatGPT 또는 Codex 채팅에서 예약 작업을 만들거나 업데이트할 수 있습니다. 어떤 작업을 언제 실행해야 하는지, 실행할 때마다 현재 채팅으로 돌아올지 새 채팅을 시작할지 설명하세요. ChatGPT는 프롬프트 초안을 작성하고 적절한 채팅을 선택하며, 작업 범위나 실행 주기가 달라지면 작업을 업데이트할 수 있습니다.

예를 들어 배포가 완료될 때까지 현재 채팅에서 후속 확인을 예약해 달라고 하거나, 프로젝트를 주기적으로 점검하는 독립형 예약 작업을 만들어 달라고 요청하세요.

스킬도 예약 작업을 만들거나 업데이트할 수 있습니다. 예를 들어 pull request를 지속적으로 관리하는 스킬은 GitHub 플러그인으로 PR 상태를 확인하고 새 리뷰 의견에 따라 코드를 수정하는 작업을 예약할 수 있습니다.

채팅 안에서 작업 예약하기

ChatGPT가 정해진 일정에 따라 기존 채팅으로 돌아오도록 하려면 해당 채팅 안에서 작업을 예약하세요. 이렇게 하면 매번 새 프롬프트로 시작하지 않고 채팅의 기존 컨텍스트를 사용합니다.

채팅 안에서 예약한 작업은 후속 확인이 자주 필요할 때 분 단위 간격으로 실행할 수 있습니다. 특정 시각에 점검하려면 매일 또는 매주 실행하도록 일정을 설정할 수 있습니다.

다음과 같은 경우에는 채팅 안에서 작업을 예약하세요.

• 오래 걸리는 작업이 끝날 때까지 진행 상황 확인하기
• 지원되는 앱 이벤트 하나에 대응하는 대신 주기적으로 현황을 파악해야 할 때 연결된 데이터 소스를 일정한 간격으로 확인하기
• ChatGPT에 정해진 주기로 검토를 이어가도록 알리기
• PR 상태를 확인하고 새 피드백을 반영하는 등 플러그인을 활용하는 스킬 기반 워크플로우 실행하기
• 조사나 이슈 분류를 진행 중인 채팅에서 기존 컨텍스트를 유지하며 작업 이어가기

각 실행이 독립적이어야 하거나 예약 작업에 결과를 실행별로 따로 표시하려면 독립형 예약 작업을 사용하세요.

채팅 안에서 작업을 예약할 때는 반복해서 사용할 수 있도록 프롬프트를 작성하세요. 매번 ChatGPT가 무엇을 해야 하는지, 보고할 만한 내용이 있는지 어떤 기준으로 판단할지, 언제 작업을 멈추거나 사용자에게 의견을 구할지 명시하세요.

예약 작업 테스트하기

작업을 예약하기 전에 일반 채팅에서 프롬프트를 직접 테스트하세요. 다음 사항을 확인할 수 있습니다.

• 프롬프트가 명확하고 작업 범위가 적절한지 확인합니다.
• 직접 선택했거나 기본값으로 설정된 모델, 추론 수준, 도구가 예상대로 작동하는지 확인합니다.
• 출력 결과를 검토할 수 있는지 확인합니다.

예약 실행을 시작한 뒤에는 처음 몇 번의 결과를 검토하고 필요에 따라 프롬프트나 실행 주기를 조정하세요.

ChatGPT 데스크톱 앱에서는 예약 작업 프롬프트에 $skill-name을 입력해 특정 스킬을 직접 호출할 수 있습니다.

예약 작업의 작업 트리 정리하기

Git 리포지터리에서 작업 트리를 사용하도록 설정하고 작업을 자주 실행하면 시간이 지나면서 작업 트리가 많이 쌓일 수 있습니다. 더 이상 필요 없는 실행 내역은 보관 처리하고, 작업 트리를 유지하려는 경우에만 실행 내역을 고정하세요.

권한 및 보안 모델

예약 작업은 기본 샌드박스 설정을 사용하며 사용자 개입 없이 실행됩니다.

샌드박스가 무엇을 제한하는지 쉽게 알아보려면 샌드박스 개요를 참고하세요. 파일 시스템 및 네트워크 규칙은 권한을 참고하세요.

• 샌드박스 모드가 읽기 전용이면 파일 수정, 네트워크 접근 또는 컴퓨터에 있는 앱 사용이 필요한 도구 호출은 실패합니다. 샌드박스 설정을 workspace-write로 변경하는 방안을 고려하세요.
• 샌드박스 모드가 workspace-write이면 워크스페이스 외부의 파일 수정, 네트워크 접근 또는 컴퓨터에 있는 앱 사용이 필요한 도구 호출은 실패합니다. 규칙을 사용하면 특정 명령어만 샌드박스 밖에서 실행하도록 허용할 수 있습니다.
• 샌드박스 모드가 전체 권한이면 ChatGPT가 사용자에게 묻지 않고 파일을 변경하거나 명령어를 실행하고 네트워크에 접근할 수 있으므로 백그라운드 예약 작업의 위험이 커집니다. 샌드박스 설정을 workspace-write로 변경하고 규칙으로 에이전트가 전체 권한으로 실행할 수 있는 명령어를 지정하는 방안을 고려하세요.

관리형 환경에서는 관리자가 요구 사항을 적용해 이러한 동작을 제한할 수 있습니다. 예를 들어 approval_policy = "never" 설정을 금지하거나 허용되는 샌드박스 모드를 제한할 수 있습니다. 관리자가 적용하는 요구 사항(requirements.toml)을 참고하세요.

예약 작업은 조직 정책에서 허용하는 경우 approval_policy = "never" 설정을 사용합니다. 관리자 요구 사항에서 approval_policy = "never" 설정을 허용하지 않으면 예약 작업은 선택한 권한 모드의 승인 방식을 따릅니다.

예시

새 스킬 자동으로 만들기

`~/.codex/sessions`에 있는 지난 하루치 파일을 모두 살펴보세요. 특정 스킬을 쓰는 데 어려움이 있었다면 그 스킬을 개선해 주세요. 개인 스킬만 대상으로 하고 리포지터리의 스킬은 제외해 주세요.

우리가 자주 하면서도 매번 애먹는 일이 있다면, 다음에는 더 빨리 처리할 수 있도록 스킬로 만들어 주세요.

꼭 스킬을 업데이트할 필요는 없어요. 그럴 만한 이유가 있을 때만 수정해 주세요.

스킬을 새로 만들었다면 알려 주세요.

프로젝트의 최신 변경 사항 파악하기

원격 브랜치 origin/master 또는 origin/main의 최신 상태를 확인하세요. 그런 다음 지난 24시간 동안 <DIRECTORY>에 변경을 가한 커밋을 바탕으로 경영진용 브리핑을 작성하세요.

형식과 구성:

- Markdown 서식을 활용하세요. 업무 영역별 섹션 제목은 H1으로, 부제는 이탤릭체로 표시하고 필요에 따라 가로 구분선을 넣으세요.
- 도입부는 “지난 24시간 동안 <directory>에서 달라진 내용입니다.”와 같이 시작해도 됩니다.
- 부제는 “업무 영역별 변경 사항과 담당자”로 쓰세요.
- 커밋을 하나씩 나열하지 말고 업무 영역별로 묶으세요. 각 업무 영역의 제목은 H1으로 쓰세요.
- 각 업무 영역에서 무엇이 달라졌는지 쉬운 말로 짧게 풀어 쓰세요.
- 읽기 쉬워진다면 글머리 기호와 굵은 글씨를 사용하세요.
- 사람별로 항목을 나눠도 됩니다. 이때 이름은 굵게 표시하세요.

내용 요건:

- “PR:”이라는 레이블 없이 본문에 PR 링크를 넣으세요(예: [#123](...)).
- 커밋 해시나 “주요 커밋” 섹션은 넣지 마세요.
- 한 업무 영역에 PR이 여러 개 있어도 됩니다. 다만 커밋마다 별도 항목을 만들지는 마세요.

범위:

- 현재 작업 디렉터리(또는 기본 체크아웃에서 이에 해당하는 디렉터리) 안의 변경 사항만 포함하세요.
- 지난 24시간 동안의 커밋만 포함하세요.
- 도움이 된다면 `gh`로 PR 제목과 설명을 가져오세요.
  PR 리뷰와 댓글도 가져와도 됩니다.

예약 작업과 스킬을 결합해 내 코드의 버그 수정하기

내 커밋에서 발생한 버그를 찾아 수정을 시도하는 $recent-code-bugfix 스킬을 새로 만들고 개인 스킬로 저장하세요.

---
name: recent-code-bugfix
description: Find and fix a bug introduced by the current author within the last week in the current working directory. Use when a user wants a proactive bugfix from their recent changes, when the prompt is empty, or when asked to triage/fix issues caused by their recent commits. Root cause must map directly to the author’s own changes.
---

# 최근 코드 변경으로 생긴 버그 수정하기

## 개요

현재 작성자가 지난 일주일 동안 변경한 코드에서 그 변경으로 생긴 버그를 찾아 수정하고, 가능하면 수정 결과를 검증하세요. 코드가 로컬에 있다고 가정하고 현재 작업 디렉터리에서 작업하세요. 버그의 근본 원인이 작성자 자신의 변경 사항과 직접 연결되는지 확인하세요.

## 워크플로우

### 1) 조사할 최근 변경 사항의 범위 정하기

Git으로 작성자와 지난 일주일 동안 해당 작성자가 변경한 파일을 파악하세요.

- `git config user.name`/`user.email`에서 작성자를 확인하세요. 확인할 수 없다면 환경에 설정된 현재 사용자 이름을 사용하거나 사용자에게 한 번 물어보세요.
- `git log --since=1.week --author=<author>`로 최근 커밋과 파일 목록을 확인하세요. 해당 커밋에서 변경한 파일을 중심으로 살펴보세요.
- 사용자 프롬프트가 비어 있으면 이 기본 범위로 바로 진행하세요.

### 2) 최근 변경으로 발생한 구체적인 오류 찾기

작성자가 수정한 코드에서 직접 비롯된 결함을 우선하세요.

- 로컬에서 로그나 CI 출력을 확인할 수 있다면 최근 테스트 실패, 린트 오류 또는 런타임 오류를 찾아보세요.
- 주어진 실패 사례가 없으면 수정된 파일을 확인할 수 있는 가장 작은 단위의 검증을 실행하세요. 테스트 하나를 실행하거나, 파일 단위로 린트를 실행하거나, 특정 문제를 재현해 보세요.
- 근본 원인이 관련 없는 기존 문제가 아니라 작성자의 변경 사항에 직접 있는지 확인하세요. 관련 없는 오류만 발견되면 작업을 멈추고 조건에 맞는 버그를 찾지 못했다고 보고하세요.

### 3) 버그 수정하기

프로젝트의 관례에 맞게 필요한 부분만 수정하세요.

- 문제를 해결하는 데 필요한 파일만 변경하세요.
- 불필요한 방어 로직을 추가하거나 관련 없는 코드를 리팩터링하지 마세요.
- 기존 코드 스타일과 테스트에 맞게 수정하세요.

### 4) 검증하기

가능하면 수정 결과를 검증하세요.

- 해당 문제를 확인할 수 있는 가장 작은 검증 단계를 우선하세요. 관련 테스트만 실행하거나, 린트 검사 범위를 좁히거나, 문제를 직접 재현하는 명령어를 실행하세요.
- 검증을 실행할 수 없다면 어떤 검증을 실행하려 했는지, 실행하지 못한 이유는 무엇인지 설명하세요.

### 5) 결과 보고하기

근본 원인과 수정 내용, 수행한 검증을 요약하세요. 근본 원인이 작성자의 최근 변경 사항과 어떻게 연결되는지 구체적으로 설명하세요.

그런 다음 새 예약 작업을 만드세요.

지난 24시간 동안의 내 커밋을 확인하고 $recent-code-bugfix 스킬로 버그 수정 사항을 제출해 주세요.