Codex Automations로 긴 작업 처리하기: 예약 트리거, heartbeat, 여러 날에 걸친 작업

Codex에게 반복 점검, PR 추적, 배포 후 확인, 여러 날에 걸친 triage를 맡길 때 먼저 물어봐야 할 것은 “자동화가 가능한가?”가 아닙니다. 어떤 작업을 어떻게 자동화해야 하느냐입니다. Automations는 Codex를 항상 켜진 백그라운드 에이전트로 바꾸지 않습니다. 대신 정확한 시점에, 정확한 경계 안으로 다시 불러와서 한 가지 명확한 일을 하게 만듭니다.

1. 먼저 이 작업이 자동화할 만한지 판단하기

1.1 standalone/project automation: 독립 백그라운드 작업

standalone automation과 project automation은 둘 다 독립 백그라운드 작업입니다. 차이는 범위입니다. standalone은 특정 프로젝트에 묶이지 않고, project automation은 특정 프로젝트 경로에 묶이기 때문에 고정된 저장소 주변의 반복 작업에 더 잘 맞습니다.

트리거가 울릴 때마다 새 실행이 시작됩니다. 끝나면 결과는 inbox나 triage로 들어가고, 새로 발견된 것이 없으면 자동 아카이브될 수 있습니다. 주된 사용 사례는 주간 dependency 점검, 일간 issue triage, 배포 후 정기 점검입니다.

핵심 제약은 로컬 환경입니다. Codex app이 실행 중인 머신은 켜져 있어야 하고, app은 계속 돌아가야 하며, 프로젝트 경로도 존재해야 합니다. 머신이 잠들거나 꺼지거나 app이 닫히면 계속되지 않습니다. 장기 무인 운영용 계층은 아닙니다.

1.2 thread automation (heartbeat): 같은 thread에서 주기적으로 깨우기

thread automation은 현재 대화 thread에 붙는 heartbeat형 주기 wakeup입니다. 핵심은 컨텍스트 유지입니다. 깨어날 때마다 새 독립 실행을 만드는 것이 아니라 같은 대화를 이어 갑니다.

배포 후 로그 확인, 여러 날에 걸친 follow-up, 지속 triage에 잘 맞습니다. 예를 들어 10분마다 배포 로그를 확인하고 오류나 성공 신호가 있을 때만 보고하고, 변화가 없으면 조용히 두는 식입니다. 이런 작업은 컨텍스트 연속성이 필요하므로 standalone automation보다 thread automation이 더 적합합니다.

heartbeat는 영구 daemon도 아니고 forever loop도 아닙니다. 깨어남 -> 확인 -> 보고 -> 대기라는 리듬입니다. app이 멈추거나 닫히면 heartbeat도 멈춥니다.

1.3 유형 비교표

관점	standalone/project automation	thread automation (heartbeat)
실행 위치	독립 백그라운드 thread	현재 대화 thread
컨텍스트 유지	매번 새 컨텍스트	현재 세션 컨텍스트 유지
적합한 경우	독립적인 반복 작업, issue triage, dependency 점검	장기 작업 후속, 지속 triage, 배포 로그 확인, 여러 날에 걸친 작업
의존 조건	로컬 app / 머신 / 프로젝트 경로가 있어야 함	현재 thread가 계속 연결돼 있어야 함
결과가 보이는 곳	inbox / triage, 아무것도 없으면 자동 아카이브	현재 대화 창
종료 방식	automation 상태 끄기	app을 일시정지하거나 닫기

판단은 단순합니다. 작업이 컨텍스트를 유지해야 하나요? 그렇다면 thread automation입니다. 특정 프로젝트에 묶여 있나요? 그렇다면 project automation, 아니면 standalone automation입니다.

2. 어떤 작업이 Automations에 맞나

모든 반복 작업이 Automations에 맞는 것은 아닙니다. 먼저 작업 형태를 봐야 합니다.

2.1 Automations에 맞는 작업의 특징

Automations에 맞는 작업은 보통 세 가지 특징을 가집니다. 반복성이 높고, 규칙이 명확하며, 결과를 검증할 수 있어야 합니다.

반복성이 높은 작업은 정해진 주기에 나타나고 매번 비슷한 결과를 목표로 합니다. 주간 dependency 점검, 일간 issue triage, 배포 후 고정 시점 점검이 좋은 예입니다. 점검 범위, 판단 기준, 출력 형식을 미리 정할 수 있습니다.

규칙이 명확한 작업은 prompt로 만들기 쉽습니다. 예를 들어 “package.json의 버전을 확인하고 새 버전이 있는 패키지를 나열한 뒤 업그레이드 우선순위를 추천하라”처럼 쓰면 됩니다. 판단 기준이 안정적이어서 매번 다시 설명할 필요가 없습니다.

검증 가능한 출력도 중요합니다. 좋은 automation 결과는 inbox / triage로 들어가고, 할 일이 없으면 자동 아카이브되며, 발견 사항이 있으면 다음 단계가 분명해야 합니다. 그래야 진짜로 시간을 아끼는지 알 수 있습니다.

2.2 Automations에 맞지 않는 작업의 특징

Automations에 맞지 않는 작업은 보통 네 가지 특징이 있습니다. 인간 판단이 자주 필요하고, 외부 상태가 빠르게 바뀌며, prompt가 아직 안정적이지 않거나, 장기 무인 운영이 필요합니다.

인간 판단이 자주 필요한 작업은 경계가 흐릿한 경우가 많습니다. 아키텍처 결정, 복잡한 bug 추적, 상황별 trade-off 판단은 모두 케이스에 따라 조정이 필요하므로 고정 automation에 잘 맞지 않습니다.

외부 상태가 빠르게 바뀌는 작업도 조심해야 합니다. 예를 들어 프로덕션 서비스의 실시간 상태 모니터링은 변화가 너무 빨라서 Automations보다 전문 관측 도구가 더 적합합니다.

검증되지 않은 prompt도 바로 자동화하면 안 됩니다. 먼저 수동으로 몇 번 돌려 규칙, 범위, 출력이 안정적인지 확인한 뒤 automation으로 옮기세요.

장기 무인 운영은 project-scoped automation이 맡아야 할 일이 아닙니다. 로컬 app, 머신, 프로젝트 경로에 의존하기 때문입니다. 머신이 사라지면 automation도 멈춥니다. 클라우드 호스팅 대용이 아닙니다.

2.3 작업 적합성 표

작업 유형	적합한가?	이유	권장 방식
주간 dependency 점검	예	반복적이고 규칙적이며 검증 가능	standalone automation 또는 project automation
일간 issue triage	예	inbox로 보낼 수 있고 자동 아카이브 가능, prompt도 안정적	standalone automation 또는 thread heartbeat
배포 후 로그 점검	예	같은 thread에서 이어가야 하므로 컨텍스트가 중요	thread automation
아키텍처 결정	아니오	자주 사람 판단이 필요하고 경계가 흐림	수동 대화
복잡한 bug 추적	아니오	상황별 조정이 필요	수동 대화
실시간 모니터링	아니오	외부 상태가 너무 빠르게 변함	전문 관측 도구
장기 무인 운영	아니오	project-scoped automation이 로컬 환경에 의존	CI 또는 cloud 방식
검증되지 않은 automation 흐름	아니오	prompt가 불안정하고 수동 실행도 들쭉날쭉	먼저 수동으로 안정화

판단 흐름은 간단합니다. 먼저 prompt가 안정적인지 확인하고, 그다음 컨텍스트를 유지해야 하는지 보고, 마지막으로 장기 클라우드 운영이 정말 필요한지 판단하면 됩니다.

3. 첫 standalone/project automation 만들기

3.1 생성 흐름

1. 먼저 작업을 명확히 적습니다. 범위, 입력, 출력, 성공 기준, 종료 조건을 정의하세요.
2. automation 유형을 고릅니다. 독립 반복 작업은 standalone, 고정 저장소 주변의 반복 작업은 project automation입니다.
3. 실행 위치를 고릅니다. Git 저장소라면 현재 작업 공간을 건드리지 않도록 worktree부터 쓰세요.
4. 주기를 정합니다. 분 단위 작업에는 명확한 종료 조건이 있어야 무한히 깨우지 않습니다.
5. 먼저 몇 번 시험 실행합니다. 출력이 안정되면 실제 주기로 올리세요.

3.2 worktree와 local project 고르는 법

실행 위치	격리 수준	적합한 작업	리스크
worktree	현재 작업 디렉터리와 분리	파일 수정, 코드 작성, PR 제안 작업	실수해도 대개 worktree 안에만 머물며 버리기 쉽습니다
local project	격리 없음; 현재 디렉터리에서 직접 실행	읽기 전용 점검, 보고서 생성, triage	지금 편집 중인 파일에 영향을 줄 수 있습니다

Git 저장소에서 수정 작업은 기본적으로 worktree를 쓰세요. local project는 명시적으로 읽기 전용, 점검 전용, 확인 전용일 때만 쓰는 편이 좋습니다.

4. thread automation(heartbeat) 만들기

4.1 생성 흐름

1. 현재 thread가 이미 장기 작업을 다루고 있는지 먼저 확인합니다.
2. 그 thread에 thread automation을 연결합니다.
3. 매 wakeup마다 무엇을 확인할지, 언제 보고할지, 언제 조용히 있을지를 정확히 적습니다.
4. 성공, 실패, timeout, 최대 라운드 수 같은 종료 조건을 정의합니다.
5. 먼저 낮은 빈도로 돌려서 스팸이 없는지 확인한 뒤 최종 주기로 올립니다.

4.2 heartbeat prompt 예시

10분마다 배포 로그를 확인하고, 아래 경우에만 보고하세요:

1. error, failed, exception을 포함한 오류 신호가 나타날 때
2. deployed, success, completed를 포함한 완료 신호가 나타날 때
3. 30분이 지나도 아직 끝나지 않았을 때

보고 형식:
- 상태: [진행 중 / 성공 / 실패]
- 핵심 로그 발췌: [최대 3줄]
- 다음 단계: [있으면]

변화가 없으면 조용히 있습니다.

이 prompt는 확인 범위, 출력 경계, 종료 조건을 분명히 합니다. 매 wakeup마다 “점검 완료”를 반복할 필요가 없고, 변화 없음 상태를 소음으로 바꾸지도 않습니다.

5. 보안 설정: sandbox, approval policy, 팀 운영

5.1 sandbox와 approval policy 설정

Automations는 기본적으로 sandbox 안에서 실행됩니다. sandbox는 어떤 파일을 만질 수 있는지, 경계를 넘을 수 있는지, 추가 승인이 필요한지를 결정합니다. 백그라운드 자동화라면 기본 경계가 작을수록 좋습니다.

sandbox 모드	권한 범위	적합한 경우	위험 수준
read-only	읽기 전용, 쓰기 없음	순수 점검과 분석 작업	낮음
workspace-write	workspace 안에서는 읽기/쓰기 가능, 외부 동작은 여전히 승인 필요	일상 automation, 파일 수정, PR 제안	중간
danger-full-access	시스템 접근 제한 없음	격리 환경이나 매우 신뢰할 수 있는 작업	높음

approval policy는 더 위험한 행동을 만났을 때 에이전트가 허가를 요청할지 정합니다.

approval policy	동작	사용 사례
on-request	필요할 때 더 높은 권한을 요청	어느 정도 자율성은 있지만 인간 검토가 필요한 경우
never	묻지 않고 전부 자동 실행	자동화 스크립트나 비대화형 환경

기본값은 workspace-write + rules/allowlist여야지 full access + unattended가 아닙니다. 후자는 문제가 생겼을 때 너무 넓습니다.

5.2 팀 운영 조언

팀은 requirements.toml로 sandbox와 approval을 고정해, 누구나 손쉽게 과도한 권한을 주지 않도록 할 수 있습니다.

[agent]
approval_policy = "never"
sandbox = "workspace-write"

목표는 전부 막는 것이 아닙니다. 기본 경계를 좁게 두고, 정말 필요한 경우에만 넓히는 것입니다.

6. 바로 쓸 수 있는 3가지 자동화 템플릿

6.1 주간 dependency 점검

• 트리거 주기: 주 1회
• 실행 위치: Git 저장소에서는 worktree 우선
• 성공 출력: 업그레이드 가능한 dependency와 우선순위 제안
• 종료 조건: 업그레이드할 것이 없으면 짧게 끝낼 것
• 권한 경계: 읽기 전용 또는 가벼운 보고서 작성

6.2 배포 후 heartbeat follow-up

• 트리거 주기: 10분마다, 최대 30분
• 실행 위치: thread automation
• 성공 출력: 성공, 실패, timeout 중 하나를 짧게 요약
• 종료 조건: 성공 신호, 실패 신호 또는 timeout
• 권한 경계: 로그만 읽고 프로덕션에는 손대지 않기

6.3 일간 issue / PR triage

• 트리거 주기: 하루 1회
• 실행 위치: standalone automation 또는 thread heartbeat
• 성공 출력: 사람이 봐야 할 항목을 inbox로 이동
• 종료 조건: 새 항목이 없으면 조용히 있을 것
• 권한 경계: 기본은 workspace-write, full access는 피하기

7. automation이 실패하면 먼저 이것부터 확인하세요

1. Codex app이 아직 실행 중이고 머신이 깨어 있나요?
2. 프로젝트 경로가 아직 존재하나요, 아니면 worktree가 이동/삭제됐나요?
3. sandbox가 쓰기나 네트워크를 막고 있나요?
4. thread automation이 정말 컨텍스트를 유지해야 하나요?
5. worktree가 너무 쌓여서 정리해야 하나요?
6. prompt에 언제 멈추고 언제 보고할지가 명확히 적혀 있나요?

8. FAQ 체크리스트

8.1 Automations는 예약 작업인가요, 항상 도는 에이전트인가요?

예약되거나 주기적으로 깨우는 백그라운드 작업에 더 가깝습니다. 매 wakeup마다 확인하고, 작업하고, 보고한 뒤 다시 기다립니다. forever loop는 아닙니다.

8.2 standalone/project와 thread automation의 차이는 뭔가요?

standalone/project automation은 매번 새로 시작하는 독립 백그라운드 실행이고, 결과는 inbox / triage로 갑니다. thread automation은 같은 thread의 heartbeat이며 현재 대화의 컨텍스트를 유지합니다.

8.3 어떤 작업이 Automations에 맞고, 어떤 작업은 아닌가요?

적합한 작업은 반복적이고 규칙적이며 검증 가능해야 합니다. 부적합한 작업은 인간 판단이 자주 필요하거나, 외부 상태가 빠르게 바뀌거나, prompt가 불안정한 경우입니다.

8.4 worktree와 local project는 어떻게 고르나요?

파일을 바꿀 수 있는 작업은 worktree를 우선하세요. local project는 순수 읽기와 보고서성 작업에만 쓰세요.

8.5 app을 닫거나 컴퓨터가 잠들면 계속되나요?

아닙니다. 프로젝트 범위 automation은 로컬 app, 머신, 프로젝트 경로에 의존하므로 app이 꺼지거나 머신이 잠들면 멈춥니다.

8.6 Computer Use는 언제 써야 하나요?

직접 GUI를 조작해야 하고 API나 웹 인터페이스가 없을 때만 쓰세요. 일반 코드로 해결되면 보통 쓸 이유가 없습니다.

8.7 비용과 주기는 어떻게 제어하나요?

필요한 만큼만 주기를 높이고, /status로 상태를 확인하고, 각 automation에 종료 조건을 넣고, 과도한 polling은 피하세요.

9. 요약

Computer Use, 내장 브라우저, Automations는 같은 문제의 다른 층을 해결합니다. Automations는 안정적이고 검증 가능하며 반복되는 일을 Codex에게 백그라운드로 맡기는 용도이고, thread automation은 여러 날에 걸친 장기 작업 후속에 적합하며, worktree와 sandbox는 위험을 통제하는 역할을 합니다.

가장 안전한 순서는 언제나 같습니다. 먼저 작업이 자동화할 만한지 판단하고, 그다음 실행 위치와 권한을 고르고, 마지막에 주기를 조정하세요. 먼저 사람이 하는 과정을 안정적으로 만들고, 그다음 Codex가 조금 더 오래 돌게 하세요.