예약 실행

이 장에서 배우는 것 예약 실행으로 무엇을 맡기고, 사람이 안 볼 때 무엇을 다르게 설계해야 하는지.

무엇을 맡기나

정해둔 시간에 업무를 시작하거나 명령을 실행합니다.

전형적인 것들입니다.

공통점은 사람이 기억하고 있어야 하는 일이라는 것입니다. 그걸 시간에 맡깁니다.

업무를 새로 만드는 화면에서 예약을 켜면 주기 선택이 나옵니다.

목록에 없는 주기는 직접 입력으로 바꾸면 크론 식(0 9 * * * 형태)을 그대로 쓸 수 있습니다. 기본값은 0 9 * * * — 매일 오전 9시입니다.

예약으로 만든 업무는 회차마다 별도의 업무로 쌓입니다. 이름을 따로 안 주면 예약의 이름을 물려받으므로, 목록에서 구분하려면 예약에 이름을 주세요.

이게 이 장의 핵심입니다. 예약 실행은 아무도 지켜보지 않을 때 돕니다. 그래서 평소 업무와 다르게 설계해야 합니다.

틀린 결과를 내는 것보다 안 하는 게 낫습니다. 아무도 안 보고 있으니 틀린 게 그대로 굳습니다.

앞선 Phase 2 진단에서 데이터 갱신 주기를 확인하라고 한 것이 여기서 그대로 쓰입니다.

자율성 수준에서 "전부 자동"은 검증된 반복 작업에 쓰라고 했습니다. 예약 실행은 반복 작업이지만 처음에는 검증되지 않았습니다.

아무도 안 보는 결과는 없는 것과 같습니다.

예약이 늘어나면 관리가 필요해집니다.

두 번째가 흔합니다. 프로젝트가 끝났는데 그 프로젝트용 예약이 계속 돌고 있습니다.

예약 실행은 매일 돕니다. 한 번에 드는 비용이 작아도 누적됩니다.

큰 돈은 아니지만 예약이 열 개면 다릅니다. 모델 라우팅처럼 단순 반복에는 가벼운 모델을 쓰는 게 맞습니다.

가장 흔합니다. 조용히 실패하면 몇 주 뒤에 "그거 요즘 안 오네?"로 발견합니다. 실패도 알리게 하세요.

만들어두고 잊습니다. 처음 1~2주는 매일 결과를 확인하세요. 그 뒤에 손을 떼도 됩니다.

컴퓨터가 꺼져 있으면 예약도 안 돕니다. 백그라운드 실행이나 시작 항목 등록이 되어 있어야 예약이 의미가 있습니다.

1. 예약 실행에서 "실패했을 때"를 반드시 적어야 하는 이유는?

답

아무도 지켜보지 않기 때문입니다. 틀린 결과를 내면 그게 그대로 굳습니다. 틀린 결과를 내는 것보다 안 하고 실패를 알리는 게 낫습니다.

2. 예약 실행의 자율성을 처음부터 "전부 자동"으로 두면 안 되는 이유는?

답

반복 작업이긴 하지만 처음에는 검증되지 않았기 때문입니다. 계획만 → 파일 편집 자동 승인 → 전부 자동 순으로 며칠씩 확인하며 올립니다.

3. 예약이 쌓였을 때 가장 흔한 문제는?

답

목적이 사라진 예약이 계속 도는 것입니다. 프로젝트가 끝났는데 그 예약은 남아 매일 비용을 씁니다.

예약을 늘리기 전에 한도부터 봅니다 → 사용량 한도 다루기