예약 실행
이 장에서 배우는 것 예약 실행으로 무엇을 맡기고, 사람이 안 볼 때 무엇을 다르게 설계해야 하는지.
무엇을 맡기나
정해둔 시간에 업무를 시작하거나 명령을 실행합니다.
전형적인 것들입니다.
| 주기 | 예 |
|---|---|
| 매일 아침 | 어제 로그에서 오류 모아 요약 |
| 매일 밤 | 임시 파일 정리, 백업 |
| 매주 월요일 | 지난주 커밋 정리해서 주간 보고 초안 |
| 매월 1일 | 사용량 집계, 의존성 업데이트 확인 |
공통점은 사람이 기억하고 있어야 하는 일이라는 것입니다. 그걸 시간에 맡깁니다.
어디서 켜나
업무를 새로 만드는 화면에서 예약을 켜면 주기 선택이 나옵니다.
| 고를 수 있는 주기 | 예 |
|---|---|
| 분 단위 | 10분마다 |
| 시간 단위 | 3시간마다 |
| 매일 | 매일 오전 9시 (기본값) |
| 평일만 | 월~금 오전 9시 |
| 매주 | 월요일 오전 9시 |
| 매월 | 1일 오전 9시 |
목록에 없는 주기는 직접 입력으로 바꾸면 크론 식(0 9 * * * 형태)을 그대로
쓸 수 있습니다. 기본값은 0 9 * * * — 매일 오전 9시입니다.
예약으로 만든 업무는 회차마다 별도의 업무로 쌓입니다. 이름을 따로 안 주면 예약의 이름을 물려받으므로, 목록에서 구분하려면 예약에 이름을 주세요.
사람이 안 볼 때의 설계
이게 이 장의 핵심입니다. 예약 실행은 아무도 지켜보지 않을 때 돕니다. 그래서 평소 업무와 다르게 설계해야 합니다.
1. 실패했을 때를 적으세요
틀린 결과를 내는 것보다 안 하는 게 낫습니다. 아무도 안 보고 있으니 틀린 게 그대로 굳습니다.
2. 전제 조건을 확인하게 하세요
앞선 Phase 2 진단에서 데이터 갱신 주기를 확인하라고 한 것이 여기서 그대로 쓰입니다.
3. 자율성은 낮게 시작하세요
자율성 수준에서 "전부 자동"은 검증된 반복 작업에 쓰라고 했습니다. 예약 실행은 반복 작업이지만 처음에는 검증되지 않았습니다.
4. 결과를 어디로 보낼지 정하세요
아무도 안 보는 결과는 없는 것과 같습니다.
예약이 쌓일 때
예약이 늘어나면 관리가 필요해집니다.
| 확인 | 왜 |
|---|---|
| 이 예약이 마지막으로 성공한 게 언제인가 | 조용히 실패하고 있을 수 있음 |
| 아직 필요한 예약인가 | 목적이 사라진 예약이 계속 돎 |
| 비용을 얼마나 쓰나 | 매일 도는 것은 누적됨 |
두 번째가 흔합니다. 프로젝트가 끝났는데 그 프로젝트용 예약이 계속 돌고 있습니다.
비용 감각
예약 실행은 매일 돕니다. 한 번에 드는 비용이 작아도 누적됩니다.
큰 돈은 아니지만 예약이 열 개면 다릅니다. 모델 라우팅처럼 단순 반복에는 가벼운 모델을 쓰는 게 맞습니다.
자주 하는 실수
실패를 안 알립니다
가장 흔합니다. 조용히 실패하면 몇 주 뒤에 "그거 요즘 안 오네?"로 발견합니다. 실패도 알리게 하세요.
잘 도는지 확인을 안 합니다
만들어두고 잊습니다. 처음 1~2주는 매일 결과를 확인하세요. 그 뒤에 손을 떼도 됩니다.
시간대를 안 맞춥니다
컴퓨터가 꺼져 있으면 예약도 안 돕니다. 백그라운드 실행이나 시작 항목 등록이 되어 있어야 예약이 의미가 있습니다.
확인
1. 예약 실행에서 "실패했을 때"를 반드시 적어야 하는 이유는?
답
아무도 지켜보지 않기 때문입니다. 틀린 결과를 내면 그게 그대로 굳습니다. 틀린 결과를 내는 것보다 안 하고 실패를 알리는 게 낫습니다.
2. 예약 실행의 자율성을 처음부터 "전부 자동"으로 두면 안 되는 이유는?
답
반복 작업이긴 하지만 처음에는 검증되지 않았기 때문입니다. 계획만 → 파일 편집 자동 승인 → 전부 자동 순으로 며칠씩 확인하며 올립니다.
3. 예약이 쌓였을 때 가장 흔한 문제는?
답
목적이 사라진 예약이 계속 도는 것입니다. 프로젝트가 끝났는데 그 예약은 남아 매일 비용을 씁니다.
밖에서도 접속할 수 있게 만듭니다 → 어디서나 접속하기