[Claude 활용 24회 — AI에게 일을 위임하는 법] 15/24화: AI 예약 작업 3단계 — 자는 동안 돌아가는 시스템 만들기

2026년 08월 15일 12 Min Read

새벽 3시, 알림 47통 — AI 예약 작업 첫 시도의 참사

지난달, 14회에서 다룬 커넥터 조합으로 꽤 쓸만한 시장 동향 리포트를 만들었다. 메일함의 뉴스레터 5개, RSS 피드 3개, 북마크한 리서치 페이퍼 목록을 교차 조회해서 매일 아침 한 장짜리 브리핑으로 뽑는 작업이었다. 손으로 돌리면 15분, Cowork에 시키면 2분. “이걸 매일 아침 6시에 자동으로 돌리면 되겠다”는 생각이 자연스러웠다.

/schedule을 처음 열고, 크론 표현식에 0 6 * * *을 넣었다. 매일 아침 6시. 완벽하다고 생각했다. 등록을 마치고 뿌듯한 마음으로 잠자리에 들었다.

새벽 3시, 폰이 울렸다. 슬랙 알림. “스케줄 실행 완료: 시장 동향 브리핑이 생성되었습니다.” 3시? 설마. 눈을 비비고 확인했다. Cowork의 스케줄러는 UTC 기준으로 돌아간다. UTC 06:00은 한국 시간 15:00(오후 3시)이고, 내가 원한 KST 06:00은 UTC로 21:00이었다. 그런데 그건 시작에 불과했다.

결과 파일을 열어보니 전날 리포트와 동일한 내용이었다. RSS 피드 커넥터가 캐시된 데이터를 반환한 것이다. 수동으로 돌릴 때는 브라우저 세션이 살아 있어서 최신 데이터를 가져왔지만, 무인 실행에서는 커넥터의 캐시 갱신 타이밍이 달랐다. 거기에 더해, 실패 알림을 설정하지 않았기 때문에 “성공”으로 분류된 채 쓸모없는 리포트가 매일 쌓이고 있었다.

사흘 뒤에야 알아챘다. 3일치 리포트가 전부 같은 내용이었다.

20년 동안 서버 크론잡을 운영하면서 시간대 실수, 무음 실패(silent failure), 의도하지 않은 외부 행동 — 이 세 가지가 예약 작업의 3대 지뢰라는 걸 몸으로 알고 있었다. 그런데 AI 예약 작업에서도 똑같은 함정을 밟았다. 도구가 바뀌어도 지뢰의 위치는 같다. 이번 회차는 그 지뢰를 하나씩 해체하는 이야기다.

예약 작업의 구조 — /schedule이 실제로 하는 일

Cowork의 /schedule은 단순한 타이머가 아니다. 이걸 이해하려면 예약 작업이 실행되는 전체 흐름을 한 번 펼쳐봐야 한다.

실행 흐름 5단계

등록(Registration) — 사용자가 /schedule로 작업 이름, 실행 주기, 지시문, 사용할 커넥터, 결과 전달 경로를 정의한다.
트리거(Trigger) — 지정된 시각이 되면 Cowork 클라우드 스케줄러가 작업을 깨운다. 2회에서 다뤘듯 Cowork는 클라우드에서 실행되므로, 내 노트북이 꺼져 있어도 트리거는 정상 작동한다.
실행(Execution) — 새로운 Cowork 세션이 열리고, 등록된 지시문이 프롬프트로 들어간다. 이때 커넥터 권한은 등록 시점에 부여한 범위 그대로 적용된다.
산출(Output) — 지시문에 정의된 형태로 결과물을 생성한다. 파일 저장, 아티팩트 갱신, 또는 특정 경로로 전달.
알림(Notification) — 성공이든 실패든 사용자에게 알린다. 이 단계가 빠지면 내 첫 시도처럼 무음 실패에 빠진다.

핵심은 3단계다. 예약 작업은 내가 없는 상태에서 새 세션이 열린다는 점. 내가 옆에서 지켜보며 “아, 그게 아니고…” 하고 끼어들 수 없다. 그래서 13회에서 강조한 ‘결과물 중심 지시’가 예약 작업에서는 선택이 아니라 생존 조건이 된다.

크론 표현식과 시간대 — 가장 흔한 첫 번째 실수

크론 표현식은 유닉스 세계에서 수십 년간 쓰여온 시간 표기법이다. 다섯 개 필드로 분·시·일·월·요일을 지정한다.

┌───────────── 분 (0-59)
│ ┌─────────── 시 (0-23)
│ │ ┌───────── 일 (1-31)
│ │ │ ┌─────── 월 (1-12)
│ │ │ │ ┌───── 요일 (0-6, 0=일요일)
│ │ │ │ │
* * * * *

Cowork의 스케줄러는 UTC(협정 세계시)를 기준으로 동작한다. 한국(KST)은 UTC+9이므로, 한국 시간 아침 6시에 돌리고 싶다면 UTC 21시(전날)를 지정해야 한다.

자주 쓰는 한국 시간 변환표를 정리해두면 매번 계산할 필요가 없다.

원하는 KST 시각	UTC 크론 표현식	설명
매일 아침 6:00	`0 21 * * *`	UTC 전날 21시
매일 아침 8:30	`30 23 * * *`	UTC 전날 23시 30분
매일 오후 2:00	`0 5 * * *`	UTC 당일 5시
평일 아침 7:00	`0 22 * * 0-4`	UTC 일~목 22시 = KST 월~금 7시
매주 월요일 9:00	`0 0 * * 1`	UTC 월요일 0시 = KST 월요일 9시

요일 변환 함정에 주목하라. “평일 아침 7시”를 단순히 0 22 * * 1-5로 적으면 UTC 기준 월~금 22시, 즉 KST 화~토 7시가 된다. 토요일 아침에 불필요한 리포트가 오고, 월요일 아침엔 리포트가 없다. 9시간 차이가 요일 경계를 넘기 때문이다. 이건 20년 경력 서버 엔지니어도 가끔 실수하는 부분이다.

Cowork의 /schedule에는 timezone 파라미터가 있다. timezone: Asia/Seoul을 명시하면 내부에서 자동 변환해준다. 이걸 쓰는 게 정답이다. 크론 표현식을 UTC로 직접 변환하는 건 일광절약시간(DST)이 적용되는 지역에서 추가 지뢰가 된다. 한국은 DST를 쓰지 않으니 고정 오프셋이지만, 미국 동부 시간대로 설정하는 작업이 있다면 3월과 11월에 1시간씩 어긋난다.

/schedule
  name: "morning-briefing"
  cron: "0 6 * * 1-5"
  timezone: "Asia/Seoul"
  ...

이렇게 하면 “한국 시간 평일 아침 6시”가 명확하다. 크론 표현식 자체는 사람이 읽기 쉬운 형태로 두고, 시간대 변환은 시스템에 맡겨라.

실습 — 매일 아침 6시 시장 동향 브리핑 자동화

이제 실제로 AI 예약 작업을 등록해보자. 14회에서 연결한 커넥터들을 재활용한다. 목표는 단순하다: 매일 아침 6시, 관심 키워드의 시장 동향을 수집하고, 요약하고, 파일로 저장한다.

Step 1 — 수동으로 먼저 성공시켜라

예약 작업의 철칙: 손으로 한 번도 성공하지 못한 작업을 자동화하지 마라. 이건 서버 크론잡이든 AI 스케줄이든 똑같다. 먼저 Cowork에서 수동으로 돌려서 원하는 결과가 나오는지 확인한다.

Cowork 지시문 (수동 테스트용):

아래 3개 소스에서 "생성형 AI 규제"와 "AI 에이전트" 키워드 관련
최근 24시간 동향을 수집해줘.

소스:
1. 메일함 — 구독 중인 뉴스레터 (The Batch, Import AI, AI News)
2. RSS — techcrunch.com/feed, news.ycombinator.com/rss
3. 북마크 폴더 — "AI 리서치" 폴더의 최근 업데이트

출력 형식:
- 마크다운 파일 1개
- 첫 섹션: 3줄 핵심 요약 (경영진 브리핑 톤)
- 둘째 섹션: 소스별 주요 기사/논문 제목 + 한 줄 요약 (최대 10건)
- 셋째 섹션: 내가 주목해야 할 변화 1가지와 그 이유

파일명: briefing-YYYY-MM-DD.md
저장 위치: Cowork Files > daily-briefings 폴더

이 지시문을 Cowork에 넣고 돌려본다. 결과물을 직접 읽어보고, 빠진 소스는 없는지, 요약 품질은 괜찮은지, 파일이 제대로 저장되는지 확인한다. 여기서 한 가지라도 불만족스러우면 지시문을 고친다. 지시문이 완벽해질 때까지 수동으로 반복한다. 13회에서 말했다 — 산출물 품질은 지시서 품질을 절대 넘지 않는다. 예약 작업은 그 지시서를 매일 반복 실행하는 것이므로, 지시서의 결함이 매일 복제된다.

수동 테스트에서 내가 발견한 것들:

RSS 피드가 가끔 24시간이 아니라 48시간 전 기사를 포함했다 → 지시문에 “오늘 날짜 기준 24시간 이내만”을 명시
“주목해야 할 변화”가 너무 뻔한 내용일 때가 있었다 → “이미 널리 알려진 사실은 제외하고, 아직 메인스트림 뉴스에 나오지 않은 움직임 위주로”를 추가
기사가 10건 미만일 때 억지로 채우려 했다 → “해당 키워드 관련 기사가 3건 미만이면 ‘오늘은 유의미한 동향 없음’으로 표기”를 추가

세 번 수동 실행해서 세 번 다 만족스러운 결과가 나왔다. 이제 자동화할 준비가 됐다.

Step 2 — /schedule로 등록

Cowork에서 /schedule을 입력하면 예약 작업 설정 패널이 열린다. 핵심 필드를 하나씩 채워보자.

/schedule create

name: "daily-market-briefing"
description: "AI 시장 동향 일일 브리핑"

# 실행 주기
cron: "0 6 * * 1-5"
timezone: "Asia/Seoul"

# 지시문 — 수동 테스트에서 검증 완료된 버전 그대로 붙여넣기
instruction: |
  아래 3개 소스에서 "생성형 AI 규제"와 "AI 에이전트" 키워드 관련
  최근 24시간 동향을 수집해줘.

  소스:
  1. 메일함 — 구독 중인 뉴스레터 (The Batch, Import AI, AI News)
  2. RSS — techcrunch.com/feed, news.ycombinator.com/rss
  3. 북마크 폴더 — "AI 리서치" 폴더의 최근 업데이트

  출력 형식:
  - 마크다운 파일 1개
  - 첫 섹션: 3줄 핵심 요약 (경영진 브리핑 톤)
  - 둘째 섹션: 소스별 주요 기사/논문 제목 + 한 줄 요약 (최대 10건)
  - 셋째 섹션: 내가 주목해야 할 변화 1가지와 그 이유
  - 해당 키워드 관련 기사가 3건 미만이면 "오늘은 유의미한 동향 없음"으로 표기

  파일명: briefing-YYYY-MM-DD.md (오늘 날짜 자동 치환)
  저장 위치: Cowork Files > daily-briefings 폴더

# 커넥터 권한 — 14회에서 연결한 것 중 필요한 것만
connectors:
  - gmail: read-only
  - rss-reader: read-only
  - bookmarks: read-only

# 결과 전달
output:
  - file: "daily-briefings/briefing-{date}.md"

# 실패 알림
on_failure:
  notify: slack
  channel: "#personal-alerts"
  message: "시장 동향 브리핑 실패: {error_summary}"

# 성공 알림 (선택)
on_success:
  notify: slack
  channel: "#personal-alerts"
  message: "오늘의 브리핑이 준비됐습니다 → {output_link}"

여기서 몇 가지 의도적인 선택이 있다.

커넥터 권한을 전부 read-only로 제한했다. 14회에서 강조한 최소 권한 원칙이다. 이 작업은 정보를 읽어서 요약하는 것이지, 메일을 보내거나 파일을 삭제하는 게 아니다. write 권한이 필요 없으면 주지 마라. 무인 실행에서 AI가 “이 정보를 관련자에게 메일로 보내드릴까요?”라고 판단해버리는 상황을 원천 차단한다.

on_failure를 반드시 설정했다. 내 첫 시도의 가장 큰 실수는 실패 알림이 없었던 것이다. 예약 작업이 조용히 실패하면 “잘 돌아가고 있겠지”라는 착각 속에 며칠이 지난다. 서버 운영에서 모니터링 없는 크론잡은 존재하지 않는 크론잡과 같다. AI 예약 작업도 마찬가지다.

on_success도 설정했다. 이건 선택이지만 나는 권장한다. 매일 아침 6시에 슬랙 알림이 오면, (1) 작업이 정상 실행됐음을 확인하고 (2) 바로 링크를 눌러 브리핑을 읽을 수 있다. 결과물을 찾으러 가는 수고가 0이 된다.

Step 3 — 첫 자동 실행 검증

등록을 마쳤다고 끝이 아니다. 첫 자동 실행을 반드시 눈으로 확인하라.

/schedule test "daily-market-briefing"

/schedule test는 크론 주기와 무관하게 즉시 한 번 실행하는 명령이다. 이걸로 세 가지를 확인한다.

커넥터 인증이 무인 환경에서도 유효한가? — 수동 실행 때는 내 브라우저 세션의 인증이 살아 있었을 수 있다. 예약 실행은 별도 세션이므로, OAuth 토큰이 만료됐거나 재인증이 필요한 상태면 여기서 잡힌다.
파일 저장 경로가 올바른가? — daily-briefings 폴더가 실제로 존재하는지, 쓰기 권한이 있는지.
알림이 도착하는가? — 슬랙 채널에 성공/실패 알림이 제대로 오는지.

테스트 실행 결과가 만족스럽다면, 이제 진짜로 다음 날 아침을 기다려본다. 그리고 첫 주 동안은 매일 결과물을 열어서 품질을 확인한다. 첫 주가 안정적이면 그 다음부터는 알림만 확인하면 된다.

# 등록된 예약 작업 목록 확인
/schedule list

# 특정 작업의 최근 실행 이력
/schedule history "daily-market-briefing"

# 실행 이력 예시 출력:
┌──────────────────┬────────┬───────────┬──────────┐
│ 실행 시각(KST)    │ 상태   │ 소요 시간  │ 산출물   │
├──────────────────┼────────┼───────────┼──────────┤
│ 2026-08-15 06:00 │ 성공   │ 1분 42초   │ 📄 링크  │
│ 2026-08-14 06:00 │ 성공   │ 1분 38초   │ 📄 링크  │
│ 2026-08-13 06:00 │ 실패   │ 0분 12초   │ ⚠️ 로그  │
│ 2026-08-12 06:00 │ 성공   │ 2분 05초   │ 📄 링크  │
└──────────────────┴────────┴───────────┴──────────┘

/schedule history에서 실패 로그를 누르면 어디서 멈췄는지 볼 수 있다. 위 예시에서 8월 13일 실패는 RSS 커넥터의 일시적 타임아웃이었다. 12초 만에 실패한 걸 보면 커넥터 연결 단계에서 막힌 것이다. 이런 일시적 실패는 재시도 정책으로 대응한다.

/schedule update "daily-market-briefing"
  retry:
    max_attempts: 2
    delay_minutes: 10

실패 시 10분 후 1회 재시도. 대부분의 일시적 장애(네트워크 타임아웃, API 일시 과부하)는 이것으로 해결된다. 재시도 횟수를 3회 이상으로 늘리고 싶은 유혹이 있지만, 무인 작업에서 과도한 재시도는 같은 실패를 반복하면서 커넥터 API 할당량을 소진하는 문제를 만든다. 2회면 충분하다.

실패 알림 설계 — 침묵이 가장 위험하다

예약 작업 운영에서 가장 과소평가되는 부분이 알림 설계다. 20년간 서버를 운영하면서 배운 게 하나 있다: 알림이 너무 많으면 모든 알림을 무시하게 되고, 알림이 없으면 장애를 모르게 된다. 둘 다 같은 결과 — 문제를 놓친다.

AI 예약 작업의 알림은 세 단계로 설계한다.

1단계: 즉시 알림 (실패 시)

작업이 실패하면 즉시 알린다. 슬랙, 이메일, 모바일 푸시 중 본인이 가장 빨리 보는 채널로. 알림 메시지에는 에러 요약이 포함되어야 한다. “작업 실패” 한 줄만으로는 뭘 해야 할지 모른다.

on_failure:
  notify: slack
  channel: "#personal-alerts"
  message: |
    ⚠️ daily-market-briefing 실패
    시각: {timestamp}
    원인: {error_summary}
    재시도: {retry_count}/{max_retries}
    로그: {log_link}

2단계: 일간 요약 (성공 시)

매번 성공 알림을 보내면 하루에 5~10개 예약 작업이 돌 때 알림 피로가 온다. 대신, 하루에 한 번 “오늘 N개 작업 정상 실행”이라는 요약 알림을 보내는 방식이 낫다. 다만 작업이 1~2개뿐이라면 개별 성공 알림도 괜찮다.

3단계: 주간 리뷰 (품질 점검)

알림이 아니라 나 자신에게 거는 리마인더다. 매주 금요일 오후, 이번 주 예약 작업 결과물을 5분간 훑어본다. 자동화의 맹점은 “돌아가고 있으니까 괜찮겠지”라는 관성이다. 결과물의 품질이 서서히 떨어지는 걸 알림은 잡아주지 못한다. 사람의 눈이 잡아야 한다.

결과 수신 경로를 하나로 통일하라

예약 작업이 3개, 5개, 10개로 늘어나면 결과물이 여기저기 흩어진다. 어떤 건 파일로, 어떤 건 슬랙으로, 어떤 건 이메일로. 그러면 “어제 그 리포트 어디 갔지?”를 찾는 데 시간을 쓰게 된다.

내 규칙은 간단하다: 산출물은 전부 Cowork Files의 정해진 폴더에 저장하고, 알림 채널은 슬랙 한 곳으로 통일한다. 알림에는 산출물 링크를 포함시킨다. 이렇게 하면 슬랙에서 링크만 누르면 바로 결과물에 도달한다.

Cowork Files 구조 예시:

📁 scheduled-outputs/
├── 📁 daily-briefings/
│   ├── briefing-2026-08-15.md
│   ├── briefing-2026-08-14.md
│   └── ...
├── 📁 weekly-reports/
│   ├── report-2026-W33.md
│   └── ...
└── 📁 competitor-watch/
    ├── watch-2026-08-15.md
    └── ...

날짜 기반 파일명은 필수다. 같은 이름으로 덮어쓰면 이전 결과를 비교할 수 없다. 나중에 “지난주 화요일 브리핑에서 뭐라고 했더라?”를 찾을 때 파일명만으로 바로 접근할 수 있어야 한다.

함정 — 무인 작업의 3가지 지뢰

예약 작업의 본질은 무인 실행이다. 내가 자고 있는 동안, 회의 중인 동안, 주말 여행 중인 동안 AI가 알아서 돈다. 이건 위임의 궁극적 형태이지만, 동시에 위험의 궁극적 형태이기도 하다.

지뢰 1: 승인 없는 외부 행동

이게 가장 위험하다. 무인 작업은 승인 없이 외부로 나가는 행동을 절대 못 하게 막아야 한다.

구체적으로 “외부로 나가는 행동”이란:

이메일 발송
슬랙/팀즈 메시지 전송 (알림용 웹훅 제외)
파일 공유 링크 생성
외부 API 호출 (POST/PUT/DELETE)
결제·구매·구독 행위
SNS 게시

수동 실행에서는 AI가 “이 결과를 팀에 공유할까요?”라고 물어보면 내가 판단해서 응답한다. 예약 실행에서는 그 질문에 답할 사람이 없다. AI가 스스로 “공유하는 게 도움이 될 것 같다”고 판단해서 실행해버리면? 새벽 3시에 팀 전체에 미완성 리포트가 날아간다.

6회에서 다룬 훅(Hook)의 교훈을 여기서 다시 써먹을 때다. “하지 마”라는 프롬프트는 통제가 아니다. 지시문에 “외부로 보내지 마”라고 적어도, 그건 요청이지 강제가 아니다. 강제는 시스템 레벨에서 해야 한다.

Cowork의 예약 작업에서 이 강제를 거는 방법:

/schedule update "daily-market-briefing"
  permissions:
    connectors:
      gmail: read-only          # 메일 읽기만, 발송 불가
      rss-reader: read-only
      bookmarks: read-only
    actions:
      send_email: deny           # 명시적 차단
      share_file: deny           # 외부 공유 차단
      post_message: deny         # 메시지 전송 차단 (알림 웹훅은 별도)
      external_api_write: deny   # 외부 API 쓰기 차단

모든 외부 행동을 deny로 잠근다. 예약 작업이 할 수 있는 건 오직 정보를 읽고, 내부 파일에 쓰고, 미리 설정된 알림 웹훅으로 상태를 보고하는 것뿐이다. 이게 최소 권한 원칙의 예약 작업 버전이다.

지뢰 2: 무음 실패와 품질 저하

앞에서 충분히 다뤘지만 한 가지 더. “성공했지만 쓸모없는” 결과가 가장 잡기 어렵다. 작업은 에러 없이 완료됐는데, 결과물이 엉망인 경우. RSS 소스가 URL을 바꿔서 빈 피드를 반환하거나, 뉴스레터가 형식을 바꿔서 파싱이 깨지거나.

이런 조용한 품질 저하를 잡는 방법은 지시문에 검증 조건을 넣는 것이다.

instruction에 추가:

검증:
- 수집된 기사가 0건이면 실패로 처리하고 에러 메시지 "소스 데이터 없음"을 반환할 것
- 요약 섹션의 글자 수가 100자 미만이면 실패로 처리할 것
- 3개 소스 중 2개 이상에서 데이터를 가져오지 못하면 실패로 처리할 것

4회에서 강조한 작업 지시서의 네 번째 요소 — 검증 방법 — 이 예약 작업에서 구원투수가 된다. 검증 조건을 지시문에 명시해두면, AI가 스스로 결과물의 최소 품질을 체크하고, 기준 미달이면 실패로 보고한다. 실패 알림이 와야 내가 개입할 수 있다.

지뢰 3: 비용 폭주

예약 작업은 매일(또는 매시간) 돈다. 한 번 실행에 드는 비용이 작아도, 누적되면 상당하다. Cowork는 구독 플랜 내 토큰 사용량으로 과금되므로, 예약 작업이 많아지면 월 한도를 예상보다 빨리 소진할 수 있다.

특히 위험한 패턴:

매시간 실행 — 정말 매시간 필요한가? 대부분의 정보 수집은 하루 1~2회면 충분하다.
거대한 입력 — 커넥터가 가져오는 데이터 양을 제한하지 않으면, 메일함 전체를 매번 스캔하게 된다.
재시도 폭발 — 실패 → 재시도 → 또 실패 → 또 재시도. 재시도 횟수와 간격에 상한을 두지 않으면 하루치 할당량을 한 작업이 잡아먹는다.

/schedule update "daily-market-briefing"
  limits:
    max_tokens_per_run: 50000     # 실행당 토큰 상한
    max_runtime_minutes: 5        # 실행 시간 상한
    retry:
      max_attempts: 2
      delay_minutes: 10

토큰 상한과 실행 시간 상한을 걸어둔다. 상한에 도달하면 작업이 중단되고 실패 알림이 온다. “왜 중단됐지?” 하고 들여다보면, 대개 커넥터가 예상보다 많은 데이터를 끌어온 것이다. 그때 지시문의 데이터 범위를 좁히면 된다.

조합 레시피 — 예약 작업 5가지 활용 패턴

시장 동향 브리핑은 하나의 예시일 뿐이다. AI 예약 작업으로 자동화하기 좋은 패턴 5가지를 정리한다. 전부 같은 원칙(수동 성공 → 자동화 → 알림 설계 → 권한 제한)을 따른다.

1. 경쟁사 모니터링

경쟁 제품의 변경 로그, 가격 페이지, 채용 공고를 매일 체크한다. 변화가 감지되면 알림. 변화가 없으면 무음. 이 “변화 있을 때만 알림” 패턴이 알림 피로를 줄인다.

instruction: |
  아래 URL들의 최근 24시간 변경 사항을 확인하고,
  유의미한 변화가 있을 때만 보고해줘.
  변화 없으면 "변경 없음"만 기록하고 알림은 보내지 마.

on_change:
  notify: slack
on_no_change:
  notify: none    # 침묵

2. 주간 지표 정리

매주 월요일 아침, 지난주의 핵심 지표(블로그 방문자 수, 뉴스레터 구독자 증감, 사이드 프로젝트 수익)를 한 장으로 정리한다. 16회에서 다룰 대시보드와 연결하면 시너지가 난다.

3. 뉴스레터 초안 생성

주 1회 발행하는 개인 뉴스레터의 초안을 수요일 저녁에 자동 생성한다. 목요일에 내가 검토하고 수정한 뒤 금요일에 발송. 0에서 쓰는 것보다 초안을 다듬는 게 훨씬 빠르다.

4. 계약·갱신 리마인더

도메인 갱신, SaaS 구독 만료, 프리랜서 계약 종료 등을 캘린더/스프레드시트에서 읽어서 D-30, D-7, D-1에 알림. 이건 단순 리마인더지만, “해당 서비스의 현재 가격과 대안을 조사해서 함께 보고”를 넣으면 AI 예약 작업다워진다.

5. 코드 저장소 주간 요약

개발자라면 — 팀의 GitHub 저장소에서 지난주 머지된 PR, 열린 이슈, 변경된 파일 통계를 요약한다. 월요일 스탠드업 전에 읽으면 “지난주 뭐 했더라”를 떠올리는 시간이 0이 된다.

이번 회차의 수익화 지점

예약 작업은 그 자체가 상품이 될 수 있는 자동화 단위다.

위에서 만든 “매일 아침 시장 동향 브리핑”을 생각해보자. 나는 “생성형 AI 규제”와 “AI 에이전트”를 키워드로 잡았지만, 같은 구조를 “친환경 에너지 정책”이나 “부동산 재개발”로 바꾸면 완전히 다른 분야의 사람에게 가치가 있다. 지시문 템플릿 + 커넥터 설정 가이드 + 알림 설계 문서를 묶으면, “매일 아침 나만의 AI 브리핑 받기” 자동화 패키지가 된다.

9회에서 만든 Skill, 14회에서 조합한 커넥터 레시피, 그리고 이번 회차의 예약 설정을 하나로 묶으면 “설치하면 바로 돌아가는” 패키지가 완성된다. 12회에서 다룬 플러그인 형태로 배포하면, 구매자는 본인 키워드만 바꿔 넣으면 된다. 템플릿 하나에 만 원이라도, 100명이 사면 월 소득이 된다. 기술이 아니라 시간을 파는 것이다 — 정확히는, “매일 아침 15분”이라는 반복 시간을 파는 것이다.

AI에게 일을 위임하는 시대에, 예약 작업은 “위임을 시스템화”하는 단계다. 한 번 설계하면 내가 자는 동안에도 돌아간다. 위임할 줄 아는 사람이 하나의 회사가 된다는 말이, 예약 작업에서 가장 물리적으로 느껴진다.

다음 회 예고 — 16화에서는 예약 작업의 결과물을 대시보드로 만든다. HTML 아티팩트로 개인 지표를 시각화하고, 매주 자동으로 갱신되는 살아 있는 문서를 만드는 법. 자는 동안 모은 데이터를, 깨자마자 한눈에 보는 시스템이다.

관련 회차 바로가기:

← 14화: 커넥터 연결 — 여러 소스를 엮는 조합의 기술
→ 16화: 대시보드 — 매주 자동 갱신되는 나만의 지표판 (다음 회)
6화: 권한·샌드박스·훅 — 사고 치기 전에 막는 3중 방어 (안전장치 원칙)
13화: Cowork 업무 자동화 — 결과물 중심 지시의 기초

📚 시리즈: Claude 활용 24회 — AI에게 일을 위임하는 법 (총 24화 중 15화)

자주 묻는 질문

AI 예약 작업에서 시간대(타임존) 설정을 잘못하면 어떤 문제가 생기나요?

스케줄러가 UTC 기준으로 동작하기 때문에, 한국 시간(KST)으로 아침 6시에 실행하려면 UTC 21시(전날)로 설정해야 합니다. 이를 모르고 크론 표현식에 6을 그대로 넣으면 의도와 전혀 다른 시각에 작업이 실행됩니다.

AI 예약 작업이 실패 없이 돌아가는 것 같은데 결과가 이상할 때는 어떻게 해야 하나요?

이른바 무음 실패(silent failure)로, 작업이 성공으로 분류되지만 실제로는 캐시된 이전 데이터를 반환하는 등 쓸모없는 결과가 쌓일 수 있습니다. 실패 알림 설정을 반드시 해두고, 결과물의 내용이 실제로 갱신되었는지 주기적으로 확인하는 것이 중요합니다.

AI 예약 작업을 등록할 때 가장 중요한 원칙은 무엇인가요?

예약 작업은 사용자가 없는 상태에서 새 세션이 열려 실행되므로, 중간에 개입해 수정할 수 없습니다. 따라서 결과물 중심의 명확한 지시문을 작성하는 것이 선택이 아니라 생존 조건이며, 실행 주기·커넥터 권한·알림 경로까지 등록 시점에 빠짐없이 정의해야 합니다.