Codex 자동화 시작하기: 반복 작업 프롬프트와 예약 전 체크

요약: Codex 자동화는 실행 시간을 정하기 전에 입력, 결과, 실행 환경, 중복 방지 기준을 설계해야 합니다. 한 번의 수동 결과를 확인한 뒤 같은 일을 예약하고, 처음 몇 번의 결과와 다음 실행 시간을 확인하세요. 반복 점검에는 이전 비교 기준을 어디에 보관할지와 언제 끝낼지도 필요합니다.

1. 어떤 반복 업무부터 시작할까

“프로젝트를 관리해 줘”보다 “README와 docs에서 바뀐 실행 명령을 읽고, 잘못된 경로와 문서 간 차이를 근거와 함께 보고해 줘”가 자동화하기 쉽습니다. 입력이 고정되고 결과를 검토할 수 있기 때문입니다. 코드 수정까지 포함한다면 수정 대상과 검증 조건이 추가되어야 합니다. 처음에는 사람이 다음 행동을 결정할 수 있는 작은 보고 업무가 적당합니다.

OpenAI 공식 Scheduled tasks 문서에 따르면 예약 작업은 웹과 데스크톱 앱에서 만들고 관리하며, CLI·IDE에는 같은 예약 관리 화면이 없습니다. 로컬 파일을 사용하는 작업은 컴퓨터가 켜져 있고 앱이 실행 중이어야 합니다. 웹 작업은 업로드 자료나 연결 도구를 사용할 수 있지만 PC의 로컬 폴더에 직접 접근하는 방식과는 다릅니다.

이 글은 작성자가 구성한 가상 문서 점검 사례로 설정 방법을 설명합니다. 실제 예약을 등록하거나 특정 프로젝트를 실행한 후기는 아닙니다. 프롬프트의 경로와 비교 기준은 자신의 프로젝트에 맞게 바꾸고, 사용할 수 있는 기능은 현재 계정과 워크스페이스에서 확인하세요.

업무	자동화에 넣을 입력	검토 가능한 결과
문서 변경 점검	대상 문서, 비교 커밋, 검증 범위	변경 요약과 오류 후보의 근거 위치
최근 커밋 요약	저장소, 브랜치, 정확한 기간	주제별 변화와 관련 커밋
CI 상태 추적	대상 PR·실행 식별자, 접근 가능한 도구	새 실패·완료·사용자 조치 필요 상태
문서 수정안 작성	고칠 파일, 허용 변경, 완료 기준	변경 파일과 실제 검증 결과

빈 입력을 실행 중에 알아서 찾아 채우게 하면 다른 프로젝트를 읽거나 비교 범위를 바꾸는 결과가 생길 수 있습니다. 프로젝트, 기준, 보고 위치를 먼저 적어 두세요. 연결된 서비스가 필요한 일이라면 수동 실행에서 실제 접근할 수 있는지도 확인해야 합니다.

2. 먼저 한 번의 실행을 완성하기

수동 실행의 목적은 프롬프트가 예쁘게 작성되었는지보다, 필요한 자료를 읽고 유용한 결과를 만드는지 확인하는 것입니다. 아래 예시에서 비교 커밋은 실제 존재하는 값으로 넣으세요. 대괄호가 남아 있으면 예약하지 말고 먼저 입력을 완성하는 편이 좋습니다.

이 프로젝트의 문서 변경을 한 번 점검해 주세요.
프로젝트: [실제 프로젝트 경로]
비교: [실제 기준 커밋]부터 현재 HEAD까지
대상: README.md와 docs 폴더의 변경된 문서
확인: 실행 명령의 설명, 파일 경로, 문서끼리 다른 안내
출력: 비교 기준 / 변경 요약 / 문제 후보 / 근거 / 미확인 사항
명령을 실행하지 않고 읽어서 판단한 내용은 그렇게 표시해 주세요.
파일 수정과 외부 게시 없이 결과를 대화에 작성해 주세요.
변경이 없으면 확인한 비교 범위와 함께 변경 없음을 적어 주세요.

결과에서 기준 커밋과 현재 커밋이 실제로 확인되었는지 보세요. “링크가 정상”이라는 표현도 링크 문자열을 읽은 것인지, 실제 응답을 확인한 것인지 구분해야 합니다. 외부 링크 접속이 허용되지 않았다면 문서에 적힌 주소의 형식만 검토했을 수 있습니다. 필요한 검증 범위를 정하면 보고서가 과장되는 일을 줄일 수 있습니다.

첫 결과가 길고 모호하면 출력부터 줄여 보세요. 예를 들어 문제 후보를 최대 다섯 개로 제한하고 각 항목에 “파일 위치, 이유, 영향, 확인 방법”을 요구할 수 있습니다. 대상 문서가 너무 많다면 전체 프로젝트 대신 설치 안내와 실행 안내부터 시작하세요. 실행 주기를 늘리는 것으로 불명확한 입력을 해결할 수는 없습니다.

3. 프로젝트와 실행 환경 고르기

공식 Best practices는 데스크톱 앱의 Scheduled에서 프로젝트, 프롬프트, 주기, 실행 환경을 선택하는 흐름을 안내합니다. 먼저 등록된 프로젝트가 실제 작업 폴더를 가리키는지 확인하세요. 이름이 같은 프로젝트가 여러 개라면 경로와 저장소를 함께 확인하는 편이 좋습니다.

프로젝트 선택은 “무엇을 읽을지”, 실행 환경 선택은 “어디서 실행할지”입니다. 같은 저장소라도 작업 중인 로컬 폴더와 별도 체크아웃에는 준비된 의존성이나 로컬 자료가 다를 수 있습니다. 문서의 변경을 무엇과 비교할지도 프로젝트 이름만으로 정해지지 않으므로 프롬프트에 별도로 적어야 합니다.

선택	맞는 상황	예약 전에 확인할 것
로컬 프로젝트	현재 폴더의 자료와 설치된 도구가 필요함	작업 중인 파일과 예약 작업의 수정 범위
Git worktree	수정 결과를 별도 공간에서 검토하려 함	시작 기준, 필요한 의존성·설정 파일
웹에서 접근 가능한 자료	업로드 또는 연결 서비스 자료로 충분함	원본의 최신성, 연결 권한, 결과 보관 위치

공식 Worktrees 문서는 Git 프로젝트의 예약 작업을 별도 worktree에서 실행할 수 있고, Git을 사용하지 않는 프로젝트는 프로젝트 폴더에서 실행한다고 설명합니다. 문서 검토만 하더라도 비교 대상이 실제로 그 환경에 있는지 확인하세요. 기존 로컬 파일이 모두 자동으로 복사될 것이라고 가정하면 안 됩니다.

Local environments 문서의 setup script는 새 worktree의 의존성 등을 준비하는 데 사용할 수 있습니다. 문서 읽기만으로 끝나는 작업에 불필요한 설치를 넣을 필요는 없습니다. 명령 검증이 필요하다면 새 환경에서도 같은 명령이 준비되는지, 설치가 필요한 네트워크를 사용할 수 있는지 먼저 확인하세요.

4. 일정과 시간대를 구체적으로 적기

예약 요청에는 요일과 시각뿐 아니라 시간대를 적으세요. “월요일 아침” 대신 “매주 월요일 오전 9시, Asia/Seoul 기준”처럼 작성하면 의도가 분명해집니다. 해외 팀이라면 누구의 업무 시작 시간인지도 정해야 합니다. 아래 요청은 등록 예시이며 입력했다고 예약이 완료되는 것은 아닙니다.

방금 확인한 문서 점검을 반복 예약해 주세요.
작업 이름: [프로젝트명] 문서 변경 점검
일정: 매주 월요일 오전 9시, Asia/Seoul 기준
프로젝트: [현재 확인한 프로젝트와 경로]
실행 환경: [로컬 또는 Git worktree]
각 실행 결과는 독립된 검토 보고서로 남겨 주세요.
대상과 검증 범위는 확인한 프롬프트를 사용해 주세요.
새 문제, 해결, 접근 실패처럼 조치가 필요한 변화만 알려 주세요.
종료일: [예: 2026년 10월 30일 오후 6시, 한국 시간]
등록된 일정, 다음 실행 시각, 대상 프로젝트를 알려 주세요.

등록 후에는 표시된 다음 실행 시간을 요청한 시간대와 함께 확인하세요. 이 사례의 날짜를 사용한다면 첫 월요일은 2026년 10월 5일입니다. 시작일을 나중으로 정했거나 이미 지난 시간을 지정했다면 다음 실행일이 달라질 수 있습니다. 중요한 일정은 요청 문장과 실제 저장된 일정을 둘 다 확인하는 편이 좋습니다.

컴퓨터가 꺼져 있던 동안의 실행이 어떻게 처리되는지 확인하지 않았다면 자동으로 보충 실행된다고 가정하지 마세요. 로컬 점검은 정상 실행할 수 있는 시간대를 고르고, 실행 기록에서 빠진 구간이 있으면 다음 비교 범위에 포함할지 결정하세요. 놓친 기간과 변경 없음은 다른 상태입니다.

5. 같은 대화로 이어갈지, 독립 실행으로 만들지

공식 문서는 기존 대화의 맥락을 이어가는 예약과 저장된 프롬프트로 시작하는 독립 예약을 구분합니다. 진행 중인 CI를 완료될 때까지 추적하려면 같은 대화가 편하고, 주간 보고서를 따로 보관하려면 독립 실행이 편합니다. 사용할 방식과 결과 위치를 요청에 명시하세요.

독립 실행에서 이전 보고서나 비교 기준을 자동으로 기억할 것이라고 가정하면 안 됩니다. 이전 상태가 필요하다면 읽을 수 있는 기록을 지정해야 합니다. 같은 대화를 사용하더라도 비교 기준을 날짜나 커밋으로 남기면 “지난번 이후”의 의미를 확인하기 쉽습니다.

가상의 문서 점검에서는 매 실행의 시작 커밋과 끝 커밋을 보고서에 적고, 다음 실행은 마지막으로 성공한 끝 커밋 이후를 읽도록 설계할 수 있습니다. 상태 파일을 사용하는 방법은 작성자가 제안하는 운영 방식이며 Codex가 기본으로 만들어 주는 파일 기능을 뜻하지 않습니다.

상태 기록: [프로젝트 안의 .automation/docs-audit-state.json]
기록 항목: 마지막 성공 비교 커밋, 확인 시각, 기존 문제의 식별 정보
기록이 없으면 지정한 초기 기준부터 비교하고 초기 실행이라고 표시하세요.
기록의 커밋을 찾을 수 없으면 임의로 기준을 바꾸지 말고 알려 주세요.
문서 점검이 성공한 뒤에만 마지막 성공 기준을 갱신하세요.
실패한 실행에서는 기존 기준을 유지하세요.
쓰기 허용 대상은 지정한 상태 파일뿐이며 문서 본문은 수정하지 마세요.

이 방식에는 상태 파일 쓰기 권한이 필요합니다. 완전한 읽기 전용 보고가 목적이라면 접근 가능한 이전 보고서의 기준을 사용하거나, 매번 고정된 기간을 비교하도록 바꾸세요. 상태 파일을 만들기로 했다면 어떤 필드를 유지하고 누가 수정하는지도 정해 두는 편이 좋습니다.

6. 중복 보고와 중복 작업 줄이기

중복에는 같은 예약이 두 개 있는 경우와, 예약 하나가 같은 문제를 계속 새 문제처럼 보고하는 경우가 있습니다. 첫 번째는 작업 이름만 보지 말고 프로젝트·목적·주기를 비교해 찾으세요. 일정 변경은 기존 작업을 수정한다는 의도를 분명히 적고, 변경 후 활성 예약이 하나인지 확인합니다.

기존 [프로젝트명] 문서 변경 점검 예약을 수정해 주세요.
같은 목적의 새 예약을 추가하지 마세요.
요일은 유지하고 시간을 오전 9시에서 오전 10시로 바꿔 주세요.
시간대, 프로젝트, 실행 환경, 기존 프롬프트는 유지해 주세요.
수정 후 활성 작업과 다음 실행 시각을 확인해 주세요.

문제 중복은 “같은 파일 위치와 같은 원인”을 기준으로 관리할 수 있습니다. 파일명이 바뀌거나 줄 번호가 이동했다고 무조건 새 문제로 세면 반복 알림이 생깁니다. 이전 문제와 비교할 자료가 없다면 중복 판단을 했다고 보고하지 말고, 이번에 발견한 사실만 적도록 요구하세요.

“문서 수정해 줘”가 포함된 예약이라면 이미 수정안이 있는지 먼저 확인하고 같은 변경을 다시 만들지 않도록 해야 합니다. 서로 다른 예약이 같은 상태 파일을 고치면 기록이 충돌할 수 있으므로 하나의 기록에는 담당 작업 하나를 두는 편이 간단합니다. 프롬프트의 중복 금지 문장만으로 파일 잠금이나 동시에 실행되는 작업의 충돌 방지가 보장되지는 않습니다.

7. 실패·완료·종료 조건 정하기

상태	보고할 내용	비교 기준 처리
점검 성공, 변경 없음	확인 범위와 시각	성공 기준 기록
새 문제 또는 기존 문제 해결	근거, 이전 상태와 달라진 점	성공 기준과 문제 상태 기록
자료 접근 실패	실패 대상과 필요한 조치	이전 성공 기준 유지
비교 커밋 없음	기준을 찾지 못했다는 사실	사용자에게 새 기준 요청
종료일 또는 완료 조건 충족	최종 상태와 남은 문제	예약 종료 반영 확인

오랫동안 같은 상태를 추적하는 예약에는 종료 조건이 특히 유용합니다. CI 완료 확인은 성공·실패가 확정되었을 때 끝내고, 기간 한정 문서 점검은 종료일에 멈추도록 요청할 수 있습니다. 계속할 업무라면 종료일 대신 한 달 후 결과의 유용성과 실행 주기를 다시 검토하는 시점을 정하세요.

예약은 기본 샌드박스 설정을 사용하는 무인 실행이며 조직 정책이 적용됩니다. 공식 Sandbox 문서를 참고해 필요한 파일·네트워크 범위를 정하세요. 접근이 막혀 실패했다고 전체 접근을 일괄 해제하기보다 읽을 대상, 필요한 명령, 검증 범위를 다시 맞추는 편이 좋습니다.

종료 조건을 프롬프트에 넣었다면 실제 관리 화면에서 중지나 완료 상태가 반영되었는지도 확인하세요. 기록 보관과 예약 중지는 다른 작업입니다. 완료된 실행을 정리할 때는 다시 검토할 보고서와 필요한 변경 내용을 먼저 확인해 두세요.

8. 두 번의 가상 실행으로 결과를 검토하기

가상 프로젝트 “실험노트 웹”은 매주 월요일 오전 9시에 문서 변경을 점검한다고 가정합니다. 첫 실행에서 시작 커밋 A와 끝 커밋 B 사이의 변경 문서 세 개를 확인하고, 실행 안내에 잘못된 폴더 이름 하나를 발견했다고 해 봅시다. 보고서에는 해당 문장, 실제 확인한 경로, 명령을 실행했는지가 함께 남아야 합니다.

둘째 실행에서는 B 이후의 변경을 확인합니다. 같은 폴더 오류가 남아 있고 새 오류가 없다면 기존 문제 미해결로 표시합니다. 사용자가 폴더 이름을 고친 변경이 있다면 해결 근거를 적습니다. 앱이 실행되지 않아 점검이 빠졌다면 성공 기준을 앞당기지 않고 마지막 성공 지점부터 비교해야 누락을 줄일 수 있습니다.

처음 몇 번은 시간·프로젝트·기준·문제 상태가 맞는지 직접 읽어 보세요. 알림이 많으면 보고할 변화의 기준을 좁히고, 점검 시간이 길면 대상 문서를 줄이세요. 유용한 결과가 안정적으로 나오는지 확인한 뒤 수정 업무나 대상 프로젝트를 추가하면 자동화의 효과를 평가하기 쉽습니다.

공식 출처 및 확인일: Scheduled tasks, Best practices, Worktrees, Local environments, Sandbox. 2026년 10월 3일 확인. 사례·상태 파일·프롬프트는 작성자의 설명용 예시입니다.