클로드 예약 작업 여러 개 운영하는 법, 공유 규칙 파일

3줄 요약

클로드 예약 작업은 실행마다 별개 세션으로 돌아가므로, 앞 작업이 만든 문맥을 뒷 작업이 이어받지 못합니다.
규칙을 프롬프트에만 적어 두면 사라집니다. 저는 8월 26일에 정한 규칙이 8월 27일 산출물에서 빠진 것을 뒤늦게 발견했습니다.
규칙은 여러 작업이 함께 읽는 문서 한 곳에 두고, 기계가 검사하게 만드시면 됩니다.

어제 저녁에 예약 작업 목록을 열어 봤습니다. 9월 1일부터 시작하도록 걸어 둔 것들이 줄줄이 대기 중이었습니다. 옵시디언 60일 학습, 영어 회화 교재 준비, 컨텍스트 엔지니어링 레슨, 그리고 매일 저녁의 야간 체크. 여기에 이미 돌고 있는 글쓰기 작업 세 개와 QA 역량 강화 하나를 더하면 여덟 개입니다. 화면을 보면서 든 생각은 뿌듯함이 아니라 불안이었습니다. 이게 정말 내일 아침에 순서대로 돌까.

불안의 정체는 곧 드러났습니다. 저는 이 여덟 개를 마치 아침에 순서대로 출근하는 팀원처럼 상상하고 있었는데, 실제로는 그렇지 않았습니다. 각자 자기 방에서 혼자 일하고 서로 얼굴을 본 적이 없는 여덟 명이었습니다. 이 차이를 몰랐던 3일 동안 저는 같은 실수를 세 번 반복했습니다.

이 글에는 그 세 가지를 적었습니다. 결론을 먼저 말하면, 예약 작업을 여러 개 굴릴 때 가장 중요한 설계 판단은 주기나 시각이 아니었습니다. 규칙과 상태를 어디에 두는가였습니다. 프롬프트 안에 둔 규칙은 조용히 사라졌고, 여러 작업이 함께 읽는 파일로 옮긴 뒤에야 살아남았습니다.

1. 예약 작업은 서로를 모릅니다

1-1. 공식 문서가 먼저 알려 준 한 줄

제가 설계를 세 번 뜯어고친 이유는 문서 한 줄을 늦게 읽었기 때문입니다. Anthropic 헬프센터의 예약 작업 안내 문서에는 이렇게 적혀 있습니다. 각 예약 작업은 자기만의 세션으로 실행된다고요. 문장 자체는 평범합니다. 그런데 이 한 줄이 나머지 설계를 전부 결정합니다.

세션이 별개라는 말은, 아침 여덟 시 작업이 무슨 결론을 냈는지 오후 다섯 시 작업이 알 방법이 없다는 뜻입니다. 사람이라면 "아침에 그거 했잖아요"가 통하지만 여기서는 통하지 않습니다. 오후 작업은 아침 작업이 존재한다는 사실조차 모른 채 깨어납니다.

저는 이걸 알기 전에 세 개의 글쓰기 작업을 하나의 사슬로 묶어 두었습니다. 여덟 시가 소재를 발굴하고, 열세 시가 그중 하나를 골라 쓰고, 열일곱 시가 나머지를 정리하는 구조였습니다. 종이에 그렸을 때는 우아했습니다.

1-2. 사슬은 첫 칸에서 끊어집니다

첫 칸이 실패한 날 전부 멈췄습니다. 그것도 조용히 멈췄습니다. 여덟 시 작업이 소재를 못 찾으면 열세 시 작업은 물려받을 것이 없는데, 그 사실을 "물려받을 것이 없다"고 인식하지 못했습니다. 애초에 앞 작업의 결과를 읽을 통로가 없었으니까요. 열세 시 작업은 빈손으로 깨어나 빈손인 이유를 모르고 그냥 자기 일을 시작했습니다.

QA 일을 오래 하면 이런 실패에 이름이 붙어 있는 걸 압니다. 테스트 스위트에서 앞선 케이스가 만든 상태에 뒤 케이스가 의존하면 딱 이런 식으로 깨집니다. 저는 그걸 20년 동안 다른 사람에게 지적해 왔는데, 제 개인 자동화에서는 똑같은 구조를 만들고 있었습니다. 웃겼습니다.

고친 방향은 단순합니다. 세 작업이 서로를 참조하지 않게 완전히 끊었습니다. 각자 자기 축의 리서치부터 발행까지 처음부터 끝까지 담당합니다. 대신 중복을 피하기 위한 최소한의 정보만 파일 하나에 남기게 했습니다.

구조	한 작업이 실패했을 때	상태를 어디에 두는가	디버깅
사슬형 (앞 작업 결과를 물려받음)	뒤 작업 전부 정지, 원인 추적 어려움	세션 문맥 — 세션이 끝나면 소멸	어느 칸에서 끊겼는지 로그로 역추적
독립형 (각자 완결)	그 작업만 실패, 나머지 정상	공유 파일 — 다음 실행이 읽을 수 있음	실패한 작업 하나만 열어 보면 끝

파일에 남기는 정보는 세 줄도 안 됩니다. 날짜, 슬롯, 다룬 소재 한 줄 요약, 그리고 발행 주소. 다음 실행은 이 파일의 최근 14일치를 읽고 같은 소재를 피합니다. 세션 문맥이 아니라 디스크에 있으니 세션이 끝나도 남습니다.

1-3. 지터라는 작은 발견

목록을 자세히 보다가 예상 못 한 걸 발견했습니다. 제가 지정한 시각은 정시인데 실제 실행 예정 시각에는 초 단위 오차가 붙어 있었습니다. 어떤 작업은 80초, 어떤 작업은 555초. 여러 작업이 같은 정시에 몰리지 않게 흩어 놓는 장치로 보입니다.

이건 제가 목록에서 관찰한 값이고 문서에서 확인한 동작은 아닙니다. 그래서 저는 이 값에 의존하는 설계를 하지 않기로 했습니다. 다만 하나는 배웠습니다. 정시에 두 작업이 같은 파일을 건드리게 설계하면 안 됩니다. 몇 초 차이로 서로의 쓰기를 덮을 수 있습니다. 그래서 세 작업의 시각을 여덟 시, 열세 시, 열일곱 시로 넉넉히 벌려 두었습니다.

2. 함정 하나 — 구두 규칙

2-1. 하루 만에 사라진 규칙

8월 26일에 규칙 하나를 정했습니다. 모든 글은 본문 맨 위에 세 줄 요약을 넣는다는 것이었습니다. 제목만 보고 들어온 사람이 그 세 줄로 판단을 마칠 수 있게 하려는 의도였습니다. 저는 이 규칙을 세 작업의 프롬프트에 말로 적어 넣었다고 생각했습니다.

8월 27일 산출물에는 없었습니다. 여덟 시와 열세 시 원고 두 편에서 세 줄 요약이 그냥 빠져 있었습니다. 실패 메시지도 없었습니다. 아무도 화내지 않았고 아무 로그도 남지 않았습니다. 규칙이 사라졌다는 사실을 저는 며칠 뒤 산출물을 다시 읽다가 알았습니다.

원인을 찾아보니 규칙이 실제로는 파일에 저장되지 않았습니다. 그날 저는 규칙을 정하고, 정했다고 믿고, 다른 일로 넘어갔습니다. 프롬프트 세 개를 각각 고쳐야 하는 구조에서 하나도 제대로 고치지 못한 것입니다. 이 함정에 구두 규칙이라는 이름을 붙였습니다. 정했다는 기억은 남고 실행되는 곳에는 없는 규칙입니다.

2-2. 체크리스트가 효과를 내는 지점

이 대목에서 오래된 연구 하나가 떠올랐습니다. Haynes와 Gawande 등이 New England Journal of Medicine 2009년 1월호(360권 5호, 491~499쪽)에 실은 수술 안전 체크리스트 연구입니다. 19개 항목짜리 체크리스트를 도입한 뒤 합병증 발생률이 11.0%에서 7.0%로, 병원 내 사망률이 1.5%에서 0.8%로 떨어졌다고 보고됐습니다.

제 해석으로는, 이 연구에서 효과를 낸 것은 항목의 내용이 아니었습니다. 어차피 수술팀은 그 19가지를 다 알고 있었습니다. 효과는 실행 직전에 소리 내어 확인하는 절차에서 나왔습니다. 알고 있는 것과 그 순간에 확인되는 것은 다릅니다.

제 규칙도 똑같았습니다. 저는 세 줄 요약이 필요하다는 걸 알고 있었습니다. 문제는 원고를 만드는 순간에 아무도 그걸 묻지 않았다는 점입니다.

2-3. 규칙을 옮긴 두 곳

그래서 규칙을 두 곳으로 옮겼습니다. 첫째, 세 작업이 모두 읽는 공유 문서 하나를 만들었습니다. 발행에 필요한 절차 전체를 여기에 모았고, 절차를 바꿀 때는 이 파일만 고칩니다. 프롬프트 세 개를 각각 고치는 구조를 없앤 것입니다.

둘째, 규칙을 기계가 검사하게 했습니다. 원고를 발행용 HTML로 바꾸는 전처리 단계에 검사를 심었습니다. 세 줄 요약 블록이 없거나 불릿이 세 개가 아니면 그 자리에서 멈춥니다.

# 서두 3줄 요약 검사 — 규칙을 사람 기억이 아니라 여기서 강제합니다
_b = body.lstrip()
if not _b.startswith("**3줄 요약**"):
    raise SystemExit("본문 서두에 '3줄 요약' 블록이 없습니다")

_bullets = []
for _ln in _b.split("\n")[1:]:
    _s = _ln.strip()
    if not _s:                      # 빈 줄을 만나면 블록 종료
        if _bullets:
            break
        continue
    if _s.startswith(("- ", "* ")):
        _bullets.append(_s)
    else:                           # 불릿이 아닌 줄이 나오면 블록 종료
        break

if len(_bullets) != 3:
    raise SystemExit(f"3줄 요약 불릿이 {len(_bullets)}개입니다 — 정확히 3개여야 합니다")

열 줄 남짓입니다. 그런데 이 열 줄이 붙은 뒤로 세 줄 요약이 빠진 적이 없습니다. 같은 자리에 검사를 몇 개 더 얹었습니다. 표가 네 개 미만이면 멈추고, 코드블록이 세 개 미만이면 멈추고, 검색 설명이 150자를 넘으면 멈춥니다. 제가 눈으로 세는 대신 스크립트가 셉니다.

한 가지는 분명히 해 두겠습니다. 기계 검사는 문자열 패턴만 봅니다. 제목의 주어와 방향이 뒤집혔는지 같은 판단은 여전히 사람이 해야 합니다. 실제로 저는 8월 25일에 의미가 뒤집힌 제목으로 발행해 놓고 나중에 정정한 적이 있습니다. 그래서 전처리 스크립트 마지막에는 "여기서부터는 사람이 읽으십시오"라는 안내를 출력하게 해 두었습니다.

규칙을 둔 곳	하루 뒤에도 살아 있었나	바꿀 때 손대는 파일 수	위반을 알아채는 시점
기억 속	아니오	0개	며칠 뒤 산출물을 다시 읽을 때
프롬프트 세 개에 각각	하나만 남음	3개	산출물 확인 시
공유 문서 한 개	예	1개	산출물 확인 시
공유 문서 + 기계 검사	예	1개 + 검사 코드	실행 도중 즉시

3. 함정 둘 — 질문 대기

3-1. 물어볼 사람이 없는 시간

두 번째 함정은 시간대에서 왔습니다. 예약 작업은 제가 자고 있거나 회의 중일 때 돌아갑니다. 문서에도 나옵니다. 원격으로 실행되기 때문에 컴퓨터가 잠들어 있어도 정해진 주기에 돈다고요. 편리한 성질이지만 대가가 있습니다. 막혔을 때 물어볼 사람이 없습니다.

처음 만든 프롬프트에는 "폴더를 찾을 수 없으면 사용자에게 확인하십시오"라고 적어 놓았습니다. 새벽 네 시에 돌아가는 작업에 이런 문장을 넣는 것은 아무 의미가 없습니다. 실행은 그 자리에서 서고, 저는 아침에 아무것도 없는 결과 화면을 봅니다.

고친 방식은 폴백 경로를 미리 다 적는 것입니다. 확인을 요청하는 대신, 첫 번째 방법이 막히면 두 번째, 두 번째가 막히면 세 번째로 내려가고, 전부 막히면 무엇을 포기하고 무엇을 보고할지까지 정해 두었습니다.

0단계: 아카이브 접근

경로 A  이미 연결된 폴더가 있으면 바로 읽는다            ← 가장 흔한 경우
경로 B  없으면 폴더 접근을 요청하는 도구를 호출한다
경로 C  그것도 없으면 원격 디바이스 도구로 우회한다
경로 D  전부 실패하면 재시도하지 않는다.
        중복 확인을 건너뛰고 진행한 뒤, 보고서에
        "아카이브 접근 불가로 중복 확인을 건너뛰었습니다"와
        막힌 지점을 한 줄로 적는다.

원칙: 어느 경로에서도 "사용자에게 확인"으로 끝나지 않는다.

경로 D가 핵심입니다. 실패를 성공으로 위장하지 않고, 대신 멈추지도 않습니다. 무엇을 못 했는지 적고 나머지를 진행합니다. 저는 아침에 그 한 줄을 읽고 손으로 고치면 됩니다.

3-2. 쓰기 동작은 명시적으로만

또 하나 정해 둔 것이 있습니다. 예약 작업을 만들 때 승인 모드를 고르게 되어 있는데, 사람이 없는 시간에 도는 작업에서 이 값은 신중할 필요가 있습니다.

저는 프롬프트에 이렇게 못 박았습니다. 보내기, 올리기, 만들기, 지우기 같은 동작은 작업 문서가 그 동작을 명시적으로 지시한 경우에만 수행합니다. 애매하면 하지 않고 보고서만 남깁니다. 발행 작업이니 발행은 지시된 동작이고, 그 외의 쓰기는 전부 금지입니다.

이 원칙 덕분에 잔재 정리 같은 애매한 상황에서 작업이 임의로 파일을 지우지 않았습니다. 지우려면 권한을 요청하고, 요청이 막히면 이름을 바꿔 저장한 뒤 보고합니다. 파일 하나 때문에 하루치 작업 전체를 중단하지 않는 것도 같은 프롬프트에 적어 두었습니다.

3-3. 실패를 성공처럼 보고하지 않기

가장 마지막에 넣은 문장이 이것입니다. "어느 단계에서 왜 실패했는지 쓰고, 성공한 것처럼 보고하지 마십시오."

이 문장이 필요했던 이유는 사람 팀에서와 똑같습니다. 자동화든 사람이든, 보고가 낙관적으로 기울면 다음 판단이 전부 틀어집니다. QA 리드로서 스프린트 회고에서 제일 곤란한 순간은 실패가 아니라, 실패가 늦게 드러날 때입니다. 예약 작업도 다르지 않았습니다.

4. 함정 셋 — 미래 진도

4-1. 시작하지 않은 커리큘럼의 n일차

세 번째 함정은 조금 더 미묘합니다. 저는 학습 커리큘럼 여러 개를 9월 1일 시작으로 걸어 두었습니다. 그리고 글쓰기 작업에는 "진행 중인 학습 기록을 쓰라"는 발굴 경로를 넣어 두었습니다.

8월에 이 두 개가 만나면 무슨 일이 생기는지 아시겠습니까. 아직 시작하지도 않은 커리큘럼의 "3일차 기록"이 나올 수 있습니다. 실제로 나오지는 않았지만, 구조상 나올 수 있었습니다. 이건 제 자동화가 저에게 거짓말을 하는 경로입니다.

그래서 프롬프트에 경고를 박았습니다. 커리큘럼 시작일이 미래일 수 있으니, 산출물 폴더에서 오늘까지의 실제 진도를 확인하라고요. 시작 전이라면 n일차 기록을 쓰지 말고, 준비 과정이나 설계 의도를 쓰는 것까지만 허용했습니다. 지금 이 글이 정확히 그 경우입니다.

4-2. 진도는 프롬프트가 아니라 산출물에서 읽습니다

여기서 원칙이 하나 더 나왔습니다. 진도 같은 값을 프롬프트에 숫자로 적어 두면 안 됩니다. 적는 순간 낡기 시작합니다. 대신 산출물 폴더를 세게 만들었습니다. 파일이 세 개 있으면 3일차입니다.

성격	작업 수	주기	상태 정보를 어디서 읽는가
글쓰기 발행	3	매일, 시각을 벌려 배치	공유 이력 파일의 최근 14일치
학습 커리큘럼	3	평일 오전	산출물 폴더의 파일 개수
학습 점검	1	평일 야간	그날 산출물 폴더
실무 역량	1	매일	자체 로그

합이 여덟입니다. 이 표를 그리고 나서 알았습니다. 여덟 개가 많아 보였던 건 개수 때문이 아니라, 상태를 어디서 읽는지가 정리되지 않았기 때문이었습니다. 정리한 뒤로는 여덟 개가 관리 가능한 숫자로 느껴집니다.

5. 도입 난이도, 유지 비용, 학습곡선

5-1. 세 가지로 나눠 본 평가

기술 도입을 검토할 때 저는 항상 세 축으로 봅니다. 예약 작업을 같은 틀에 넣어 봤습니다.

평가 항목	판단	근거
도입 난이도	낮음	이름, 프롬프트, 주기만 정하면 만들어집니다. 첫 작업은 10분 안에 돌았습니다
유지 비용	중간	작업 자체는 손이 안 갑니다. 비용은 프롬프트를 고칠 때 발생합니다. 작업이 여러 개면 공유 문서 없이는 급격히 올라갑니다
학습곡선	초반이 급함	"세션이 독립"과 "질문할 수 없음"이라는 두 사실을 이해하는 데 3일 걸렸습니다. 그 뒤는 완만합니다

유지 비용 칸을 특히 강조하고 싶습니다. 저는 이 비용을 처음에 0으로 잡았습니다. 한 번 만들면 알아서 돈다고 생각했으니까요. 실제 비용은 규칙이 바뀔 때 나옵니다. 작업이 하나면 프롬프트 하나를 고치면 되지만, 세 개면 세 곳을 같은 값으로 맞춰야 합니다. 8월 26일의 사고가 정확히 여기서 났습니다.

5-2. 로컬이냐 원격이냐

문서에서 짚어 둘 만한 대목이 하나 더 있습니다. 예약 작업은 기본적으로 원격에서 돌아 컴퓨터가 꺼져 있어도 실행됩니다. 그런데 같은 문서에 이런 주의도 있습니다. 로컬 파일이나 앱이 필요한 작업은 로컬에서만 실행된다고요.

구분	원격 실행	로컬 실행
컴퓨터가 꺼져 있을 때	실행됩니다	실행되지 않습니다
접근할 수 있는 자료	연결된 도구와 계정에 저장된 파일	지정한 로컬 폴더
제 글쓰기 작업	해당 안 됨	해당됨 — 아카이브가 로컬 폴더입니다

제 글쓰기 작업은 로컬 폴더의 이력 파일을 읽어야 하므로 로컬 쪽입니다. 이 말은 노트북이 꺼져 있으면 그날 글이 안 나온다는 뜻입니다. 대신 산출물이 제 손안에 남습니다. 저는 이 교환을 받아들였습니다. 다만 이 성질을 모르고 "왜 어제 글이 안 나왔지"를 한 번 겪었습니다.

6. 권할 만한 경우 / 권하지 않는 경우

6-1. 권할 만한 경우

같은 판단을 매일 같은 방식으로 반복하는 일에는 잘 맞습니다. 어제 무슨 소재를 다뤘는지 확인하고, 겹치지 않는 것을 고르고, 정해진 형식으로 정리하는 일. 판단 기준을 글로 쓸 수 있는 일이면 대체로 됩니다.

시작 시각이 자기 의지에 달려 있어서 자꾸 밀리는 일에도 맞습니다. 저는 학습 커리큘럼을 세 번 시작하고 세 번 흐지부지했습니다. 예약을 걸어 두면 시작 여부는 제 의지에서 빠집니다. 남는 것은 나온 결과를 읽을지 말지뿐입니다.

6-2. 권하지 않는 경우

판단 기준을 글로 쓸 수 없는 일에는 권하지 않습니다. 팀원과의 1:1 준비 같은 것은 그날의 표정과 맥락에 달려 있어서 프롬프트로 고정하면 오히려 해롭습니다. 저는 이런 일에 예약을 걸지 않았습니다.

되돌리기 어려운 쓰기 동작이 섞인 일도 권하지 않습니다. 메일 발송, 외부 공유, 삭제 같은 것은 사람이 없는 시간에 돌리지 않는 편이 안전합니다. 제 발행 작업은 발행이 목적이라 예외로 두었지만, 대신 검증 단계를 붙이고 실패 시 마커를 만들지 않게 했습니다.

작업이 하나뿐인 상태에서 공유 문서까지 만드는 것도 권하지 않습니다. 그건 아직 없는 문제를 해결하는 일입니다. 두 개째부터 만드시면 됩니다.

6-3. 오늘 저녁에 해볼 것

작업이 두 개 이상 있으시면 이 체크리스트로 한 번 훑어 보시면 됩니다. 다섯 항목이고 저는 15분쯤 걸렸습니다.

## 예약 작업 점검 5항목

- [ ] 1. 앞 작업의 결과를 뒷 작업이 물려받는 구조가 있는가
      → 있으면 끊는다. 필요한 정보는 파일 한 개로 주고받는다

- [ ] 2. 프롬프트에 "사용자에게 확인하십시오"가 있는가
      → 있으면 폴백 경로로 바꾼다. 마지막 경로는 "건너뛰고 보고"로 끝낸다

- [ ] 3. 두 개 이상의 프롬프트에 같은 규칙이 복사돼 있는가
      → 있으면 공유 문서 한 곳으로 옮긴다

- [ ] 4. 그 규칙을 기계가 검사하는가
      → 아니면 열 줄짜리 검사를 붙인다. 위반 시 그 자리에서 멈추게 한다

- [ ] 5. 프롬프트에 진도나 날짜가 숫자로 박혀 있는가
      → 있으면 산출물에서 세도록 바꾼다

3번과 4번을 같이 하시는 걸 권합니다. 저는 3번만 하고 며칠 지낸 적이 있는데, 공유 문서에 규칙이 있어도 아무도 확인하지 않으면 결과가 같았습니다. 문서에 적혀 있다는 사실이 지켜진다는 뜻은 아니었습니다.

여덟 개를 돌리며 배운 것을 한 줄로 줄이면 이렇습니다. 자동화의 어려움은 자동화되는 일에 있지 않고, 그 일을 어떤 규칙으로 할지 어디에 적어 두는가에 있었습니다. 내일 아침 여섯 시부터 커리큘럼 네 개가 처음 돌기 시작합니다. 이번에는 실패해도 어디서 실패했는지 알 수 있을 것 같습니다.

이렇게 자동으로 발행한 글이 검색에 잡히지 않을 때 확인한 순서는 서치콘솔 색인 생성 안 됨 원인을 찾은 글에 정리했습니다.

이 블로그 검색

하루 로그