Cron Job에 사람의 승인 단계 추가하기
요약
Cron Job 실행 시 부작용을 방지하기 위해 사람의 승인 단계를 추가하는 패턴을 소개합니다. Python 예제와 함께 작업 유형별 적절한 만료 시간 설정 및 승인/거절/만료 처리 방법을 다룹니다.
핵심 포인트
- 환경 플래그 대신 작업 제안 및 승인 패턴 권장
- 작업 유형(DB 퍼지, 배포 등)에 따른 적절한 만료 시간 설정 필요
- 승인 전 검토자가 내용을 수정할 수 있는 편집 기능 활용 가능
- 거절 및 만료 시 부작용 없이 안전하게 종료되는 구조 설계
스케줄은 실행되되 부작용(side effect)은 당신의 승인을 기다리도록 Cron Job에 사람의 승인 단계를 추가하는 방법 — 작동하는 Python 예제와 만료 시간(expiry window) 가이드를 포함합니다.
예약된 작업(Scheduled jobs)이 사각지대인 이유
본능적으로는 작업을 일시 중지하기 위해 환경 플래그(environment flag)나 설정 토글(config toggle)을 추가하려 합니다. 이는 작동하지만, 실행 창이 열리기 전에 플래그를 전환하는 것을 기억해야 합니다. 그리고 잊어버린 토글은 토글이 없는 것과 마찬가지입니다.
더 나은 패턴: 스케줄은 제시간에 실행되지만, 작업이 당신에게 실행을 '제안(proposes)'하고 당신이 승인할 때까지 진행할 수 없도록 하는 것입니다. Cron 스크립트는 준비 작업을 수행한 다음, 당신의 결정이 내려질 때까지 대기(blocks)하며, 그 후 실행하거나 깔끔하게 종료됩니다.
패턴의 작동 방식
cron fires
│
...
Crontab 항목은 변경되지 않습니다. 변경되는 것은 스크립트 자체가 사람의 결정이 돌아올 때까지 부작용(side effect)을 실행하지 않는다는 점입니다.
#!/usr/bin/env python3
import os
...
Crontab에 연결하세요:
적절한 만료 시간(Expiry window) 선택하기
expires_in은 반드시 승인해야 하는 시간 범위입니다. 이 시간이 지나면 작업은 승인될 수 없으며 스크립트는 깔끔하게 종료됩니다.
| 작업 유형 | 권장 expires_in | 이유 |
|---|---|---|
| 데이터베이스 퍼지 (Database purge) | 1–4시간 | 좁은 범위 — 놓치더라도 다음 실행 체크포인트를 기다림 |
| 배포 (Deployment) | 900s (15분) | 타이트한 범위가 주의를 강제함; 오래된 배포는 위험함 |
| 보고서 생성 (Report generation) | 86400s (24시간) | 보고서는 위험도가 낮으며 하루 정도는 기다릴 수 있음 |
기본값은 72시간입니다. 대부분의 예약된 작업의 경우, 더 짧은 시간이 안전합니다. 이는 데이터가 여전히 신선할 때 결정이 내려지도록 강제하며, 며칠 뒤에 오래된 작업이 실수로 승인되는 것을 방지합니다.
거절(Rejection)과 만료(Expiry)의 의미
status가 rejected 또는 expired인 경우, 스크립트는 부작용(side effect) 없이 종료됩니다. 아무것도 전송, 삭제 또는 배포되지 않습니다.
거절(Rejection)은 명시적입니다: 누군가가 초안(draft)을 검토하고 거절한 경우입니다. 만료(Expiry)는 암시적입니다: 정해진 시간 내에 아무도 응답하지 않은 경우입니다. 두 경우 모두 안전한 종료(safe exits)입니다. 에러 핸들링(error handling) 시 두 경우를 동일하게 취급하거나, 서로 다른 알림(alerting) 동작을 원한다면 구분하여 처리할 수 있습니다.
elif status == "rejected":
print("Rejected by reviewer. Exiting.")
elif status == "expired":
...
사람의 편집 처리하기 (Handling human edits)
editable: ["preview.body"]를 설정하면, 검토자(reviewer)가 승인하기 전에 초안을 수정할 수 있습니다. 이때 폴링(polling) 응답에는 다음 내용이 포함됩니다:
decision.final_preview.body— 사람이 승인한 버전 (원본 대신 이 버전을 사용하세요)decision.diff— 변경된 사항에 대한 통합 디프 (unified diff) (실제로 수정된 사항이 있는 경우에만 존재)
항상 final_preview.body로 실행하십시오. 이것이 원클릭 수정(one-click corrections)이 작동하는 방식입니다. 검토자가 수신함 카드(inbox card)에서 오타를 수정하거나 링크를 직접 업데이트한 후 승인하면, 수정된 버전이 자동으로 전송됩니다.
다음 단계
- Quickstart — API 키를 발급받고 5분 이내에 첫 번째 테스트 액션(test action)을 실행해 보세요
- Notifications — 이메일, Slack 또는 Telegram을 설정하여 크론 잡(cron job)이 액션을 실행하는 즉시 알림을 받으세요
- Audit log — 무엇이 실행되었고, 무엇이 승인되었으며, 무엇이 거절되었는지, 그리고 언제 발생했는지에 대한 이력을 검토하세요
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기