Claude Desktop과 뭐가 다를까: Claude Code Scheduled Tasks 실전 비교

Claude Code에서 /loop만 치면 프롬프트가 알아서 반복 실행된다는 거, 진짜일까요?

저도 처음엔 의심했습니다. 2026년 2월 25일에 Claude Desktop Cowork에 Scheduled Tasks가 나왔을 때도 “오, 이거 내가 매일 수동으로 돌리는 RALPH 루프 대체할 수 있겠다” 싶어서 흥분했는데, 막상 써보니 세션이 꺼지면 끝이더라고요. 그런데 이번엔 Claude Code에도 같은 이름의 기능이 따로 있다는 걸 알게 됐습니다. 같은 Scheduled Tasks인데 동작 방식이 전혀 달라요.

Claude Code Scheduled Tasks는 2026년 3월 기준 Anthropic 공식 문서에 등재된 세션 내 스케줄링 기능으로, /loop 명령과 CronCreate/CronList/CronDelete 도구를 사용해 프롬프트를 반복 실행하거나 일회성 리마인더를 설정할 수 있습니다. 핵심은 세션 스코프(session-scoped)라는 점으로, Claude Code 프로세스가 종료되면 모든 예약 작업이 사라집니다.

Claude Desktop과 뭐가 다를까: Claude Code Scheduled Tasks 실전 비교 — 그리고 랄프 루프는 이제 끝인가?

왜 반복 프롬프트가 생각보다 큰 마찰 비용인가

이거 경험해봐야 알아요.

저는 개인 지식 관리 시스템을 Obsidian + Claude 에이전트 조합으로 운영하고 있습니다. RALPH 루프라고 부르는 건데, Review → Align → Log → Prioritize → Harden을 매일/주간 단위로 돌립니다. 에이전트가 온톨로지 상태를 점검하고, 끊긴 링크를 찾고, 승격 후보를 추천하고, 규칙을 패치하는 사이클이에요.

문제는 이게 자동이 아니라는 겁니다.

매일 아침 터미널 열고 @ontology-ralph-loop daily 치고, 일요일마다 @ontology-ralph-loop weekly 치고, 월말에 @ontology-ralph-loop ralph 치고. 프롬프트 자체는 간단한데, “아, 오늘도 돌려야 하는데” 하는 그 마찰이 쌓이면 꽤 커요. 까먹는 날도 있고, 귀찮아서 건너뛰는 날도 있고.

그래서 Claude Code Scheduled Tasks 소식을 듣는 순간 바로 떠오른 생각이 이거였어요.

“이걸로 RALPH 루프를 자동화할 수 있나?”

Claude Code Scheduled Tasks 공식 문서 핵심

Anthropic 공식 문서 기준으로 정리합니다. 추측이 아니라 문서에 적혀 있는 것만 씁니다.

/loop — 가장 빠른 반복 실행

/loop 5m check if the deployment finished and tell me what happened

이게 전부예요. /loop 뒤에 간격과 프롬프트를 쓰면, Claude가 cron 표현식으로 변환해서 백그라운드에서 반복 실행합니다.

간격 문법은 유연합니다.

형태	예시	해석
앞에 붙이기	`/loop 30m check the build`	30분마다
every 절	`/loop check the build every 2h`	2시간마다
생략	`/loop check the build`	기본 10분

지원 단위는 s(초), m(분), h(시), d(일). 초 단위는 cron의 1분 단위로 올림 처리됩니다.

다른 명령을 /loop로 감싸는 것도 됩니다.

/loop 20m /review-pr 1234

20분마다 PR 리뷰 스킬을 자동으로 재실행하는 거죠.

일회성 리마인더

자연어로 한 번만 실행되는 작업도 설정할 수 있어요.

remind me at 3pm to push the release branch

in 45 minutes, check whether the integration tests passed

한 번 실행되고 자동 삭제됩니다.

내부 도구 구조

도구	역할
`CronCreate`	새 작업 등록. 5필드 cron 식 + 프롬프트 + 반복/일회 구분
`CronList`	등록된 작업 목록 + ID + 스케줄 + 프롬프트 확인
`CronDelete`	8자리 ID로 작업 삭제

세션당 최대 50개 작업 등록 가능.

실행 메커니즘 — 진짜 중요한 부분

여기가 핵심입니다.

스케줄러가 매초 체크합니다. 예약된 시간이 되면 대기열에 넣어요.
낮은 우선순위로 실행됩니다. 사용자가 Claude와 대화 중이면 대화가 끝날 때까지 기다렸다가 실행해요.
로컬 타임존 기준입니다. 0 9 * * *이면 내 컴퓨터 시간대 기준 아침 9시.
**지터(jitter)**가 있어요. 모든 세션이 동시에 API를 때리지 않게, 일회성은 최대 90초 일찍, 반복은 최대 15분 늦게 실행될 수 있습니다.

그리고 가장 중요한 제약:

3일 만료(Three-day expiry): 반복 작업은 생성 3일 후 자동 만료됩니다. 마지막으로 한 번 실행하고 자동 삭제.

잊어버린 루프가 영원히 도는 걸 방지하는 안전장치인데, 동시에 장기 자동화에는 치명적인 제약이에요.

Claude Desktop Cowork와 Claude Code: 같은 이름, 다른 물건

이름이 같아서 헷갈리는 게 당연합니다. 둘 다 “Scheduled Tasks”라고 부르거든요. 근데 실체는 완전히 다릅니다.

구분	Claude Code Scheduled Tasks	Claude Desktop Cowork Scheduled Tasks
실행 환경	터미널 CLI 세션 안	Claude Desktop 앱 안
설정 방식	`/loop` + 자연어 또는 cron 도구	GUI 사이드바 `/schedule` 버튼
지속성	세션 종료 시 소멸	앱이 열려 있는 동안 유지
3일 만료	있음 (반복 작업 자동 삭제)	없음 (앱이 열려 있으면 계속)
재시작 복원	불가	가능 (앱 재시작 시 복원)
MCP 연동	Claude Code MCP 설정	Gmail, Slack, Notion 등 GUI 연동
대상 사용자	개발자, CLI 사용자	모든 Claude 유료 사용자
최대 작업 수	50개/세션	명시 안 됨
출시일	2026년 3월 공식 문서 등재	2026년 2월 25일 발표

한 줄로 정리하면 이렇습니다.

Claude Code = 개발 세션 중 임시 폴링/모니터링용

Claude Desktop Cowork = 일상 업무 반복 자동화용

Claude Code의 Scheduled Tasks는 “빌드 끝났는지 5분마다 확인해줘”, “PR 머지되면 알려줘”, “45분 뒤에 release branch 푸시 리마인드해줘” 같은 개발 워크플로우 내 임시 자동화에 맞춰져 있어요. 세션이 끝나면 사라지는 게 당연한 맥락이죠.

반면 Claude Desktop Cowork은 “매일 아침 9시에 뉴스 브리핑 만들어줘”, “매주 금요일에 스프레드시트 정리해줘” 같은 지속형 반복 업무에 초점이 있어요. 앱을 열어둬야 하지만, 앱만 열어두면 계속 돌아갑니다.

그리고 여기서 하나 더. 2026년 3월 5일에 나온 Cursor Automations는 아예 다른 차원이에요. 이건 이벤트 트리거 기반이라 사람이 시간을 지정하는 게 아니라 GitHub 푸시, Slack 메시지 같은 이벤트가 발생하면 AI가 클라우드 샌드박스에서 자동 실행됩니다. 시간 기반 예약과 이벤트 기반 자동화는 근본적으로 다른 패러다임이고, 이건 이전 글에서 자세히 다뤘습니다.

RALPH 루프 — 나는 왜 이걸 수동으로 돌리고 있었나

잠깐 제 시스템을 설명할게요. 이 맥락을 알아야 “Scheduled Tasks로 대체할 수 있나?” 질문이 의미가 있거든요.

저는 Obsidian 볼트에 개인 온톨로지 시스템을 구축해서 쓰고 있습니다. 팔란티어의 Foundry Ontology에서 아이디어를 따온 건데, 개인 지식/행동/결정을 Object + Link + Action + AI Agent로 관리하는 구조예요.

이걸 운영하는 핵심 사이클이 RALPH 루프입니다.

단계	이름	하는 일
R	Review	온톨로지 상태 점검 (고아 노트, 끊긴 링크, 만료된 객체)
A	Align	현재 목표와 프로젝트 정렬 확인
L	Log	변경 사항 기록, 에이전트 실행 로그
P	Prioritize	다음 주 집중 대상 선정, 승격 후보 추천
H	Harden	규칙/템플릿 패치, 발견된 문제 구조적 해결

지금은 이렇게 돌리고 있어요.

매일 아침: @ontology-ralph-loop daily → 분산 복습 + confidence 업데이트
매주 일요일: @ontology-ralph-loop weekly → 품질 게이트 + 거버넌스 리뷰
월말: @ontology-ralph-loop ralph → 풀 루프 + 규칙 패치

문제? 전부 수동 트리거입니다. Cursor에서 에이전트를 호출하거나, Claude Code에서 프롬프트를 쳐야 해요. 자동으로 아침 9시에 돌아가는 게 아니라, 제가 아침에 일어나서 터미널을 열고 명령을 쳐야 합니다.

이게 “반복 프롬프트의 마찰 비용”이에요. 프롬프트 자체는 10초면 치는데, 그 10초를 위해 “아, 오늘도 돌려야 하는데” 하는 인지 부담이 매일 쌓입니다.

Scheduled Tasks로 RALPH 루프를 자동화할 수 있을까?

솔직하게 답하면: 반만 가능합니다.

Claude Code `/loop`로 시도하는 경우

/loop 24h @ontology-ralph-loop daily

이론적으로 이렇게 치면 24시간마다 daily 루프가 돌아가야 해요. 근데 현실적 제약이 셋 있습니다.

제약 1: 3일 만료. 반복 작업이 3일 뒤에 자동 삭제됩니다. RALPH는 최소 주 단위, 이상적으로는 월 단위로 계속 돌아야 하는데 3일마다 재등록해야 한다면 수동보다 번거로울 수 있어요.

제약 2: 세션 종료 시 소멸. 터미널을 닫으면 끝입니다. 맥북을 닫고 출근하면? 사라져요. tmux나 screen으로 세션을 유지하는 방법이 있긴 한데, 그러면 이미 “간편한 자동화”가 아니라 인프라 운영이에요.

제약 3: 컨텍스트 크기. RALPH daily만 해도 볼트 파일 여러 개를 읽고, Obsidian CLI를 호출하고, 결과를 종합해야 합니다. 24시간 동안 세션을 유지하면서 다른 작업도 하면 컨텍스트가 커져요. compaction이 있다고는 하지만, 장기 실행 세션에서의 안정성은 별도 검증이 필요합니다.

Claude Desktop Cowork으로 시도하는 경우

GUI에서 “매일 아침 9시에 RALPH daily 실행”을 설정하면? 이론적으로 더 낫습니다. 앱만 열어두면 계속 돌아가니까요. 3일 만료도 없고, 앱 재시작 시 복원도 됩니다.

근데 여기도 제약이 있어요. Cowork의 Scheduled Tasks가 내 Obsidian 볼트의 .claude/ 에이전트 구조를 인식할 수 있는지, MCP로 로컬 파일 시스템에 접근해서 Obsidian CLI를 실행할 수 있는지 — 이건 실제로 세팅해봐야 알 수 있는 부분이에요.

현실적 해법: GitHub Actions + cron

공식 문서에서도 “내구성 있는 스케줄링이 필요하면 GitHub Actions의 schedule 트리거나 Desktop Scheduled Tasks를 쓰라”고 안내하고 있어요. 즉 Anthropic도 Claude Code의 세션 스코프 한계를 알고 있고, 장기 자동화에는 다른 방법을 추천하는 거예요.

결국 RALPH 루프를 진짜 자동화하려면:

GitHub Actions cron: .github/workflows/ralph-daily.yml에 0 0 * * * (매일 자정) 설정, Claude Code를 --dangerously-skip-permissions로 비대화식 실행
Obsidian MCP 연동: Claude Desktop Cowork에서 로컬 볼트 접근 가능하게 MCP 설정
하이브리드: 일상 모니터링은 Claude Code /loop, 장기 반복은 GitHub Actions

어떤 방식이든 “프롬프트 한 줄로 끝”은 아닙니다.

그래서 RALPH 루프는 끝인가?

아니요. 전혀 끝이 아닙니다.

오히려 더 중요해졌어요.

Scheduled Tasks가 해결하는 건 “트리거”입니다. 언제 실행할지, 어떤 주기로 실행할지를 자동화하는 거예요. 근데 RALPH 루프의 본질은 트리거가 아니라 판단 구조입니다.

Review에서 “이 노트가 고아인가 아닌가”를 판단하고, Align에서 “현재 목표와 정렬되어 있는가”를 확인하고, Prioritize에서 “다음 주에 뭘 집중할지”를 결정하는 건 실행 시점과 무관한 지적 작업이에요.

비유하자면, Scheduled Tasks는 알람 시계고, RALPH 루프는 아침 루틴입니다. 알람이 아무리 정확해도 루틴의 내용이 부실하면 의미 없어요. 반대로 루틴이 아무리 좋아도 알람 없이 매일 아침 7시에 자발적으로 일어나는 건 어렵고요.

좋은 소식은, 이 둘을 결합하면 꽤 강력해진다는 겁니다.

Scheduled Tasks가 트리거를 담당하고
RALPH 루프가 판단 구조를 담당하면

“매일 아침 자동으로 RALPH daily가 돌고, 결과가 노트에 기록되어 있고, 승격 후보 목록이 정리되어 있는” 상태에서 하루를 시작할 수 있어요. 지금은 이 모든 걸 제가 직접 트리거하고 있거든요.

내가 느낀 점

솔직히 이번에 공식 문서를 처음부터 끝까지 읽으면서 느낀 건 기대보다 차분한 기능이라는 거였어요.

“Scheduled Tasks”라는 이름만 들으면 뭔가 거창한 자동화 플랫폼 같은데, 실제로는 세션 안에서 돌아가는 간이 cron이에요. 3일 만료, 세션 종료 시 소멸, 지터로 인한 비정확한 타이밍. 이건 프로덕션 자동화가 아니라 개발 중 편의 기능입니다.

근데 그게 나쁜 건 아니에요. 오히려 범위를 명확히 한 게 좋았습니다. “이 기능으로 할 수 있는 것”과 “이 기능으로 하면 안 되는 것”이 공식 문서에 솔직하게 적혀 있거든요. 장기 자동화 필요하면 GitHub Actions 쓰라고 직접 안내하는 벤더는 드물어요.

ChatGPT가 2025년 1월에 예약 작업을 먼저 선보였을 때는 “AI가 알아서 다 해준다” 같은 분위기였는데, Claude의 접근은 더 엔지니어링적이에요. cron 표현식을 그대로 노출하고, 세션 스코프라는 한계를 명시하고, 도구 이름(CronCreate, CronList, CronDelete)까지 투명하게 보여주는. 개발자로서 이런 투명성이 오히려 신뢰가 갑니다.

솔직한 마음

사실 조금 불안합니다.

제가 몇 달째 공들여서 만든 RALPH 루프, 에이전트 팀, 하네스 코드 — 이런 것들이 플랫폼 기능 하나로 대체되는 건 아닌지. Cursor Automations 글을 쓸 때도 느꼈는데, “내가 직접 짠 runtime_harness.py를 Cursor가 플랫폼 레벨에서 해버렸다”는 감각이 있었거든요.

근데 이번에 깊이 파보니까 확신이 생겼어요. 플랫폼은 트리거를 자동화하지, 판단을 자동화하지 않습니다.

Scheduled Tasks가 아무리 발전해도, “이번 주 온톨로지에서 가장 취약한 링크가 뭔지”를 판단하는 로직은 제가 만든 에이전트 안에 있어요. “이 글감의 우선순위를 올릴지 내릴지”를 결정하는 기준은 제 RALPH 루프 안에 있고요.

결국 자동화의 가치는 트리거가 아니라 트리거된 후의 판단에 있습니다. 알람 시계를 사는 게 아니라 아침 루틴을 설계하는 게 중요한 것처럼요.

그래서 오히려 이번 기회에 RALPH 루프를 더 단단하게 만들어야겠다는 생각이 들었습니다. 트리거는 Scheduled Tasks나 GitHub Actions에 맡기되, 판단 구조는 더 정교하게.

앞으로 할 것들

이번 주 실험 계획

Claude Code /loop로 간이 RALPH 테스트: 10분 간격으로 볼트 상태 점검하는 최소 버전을 돌려보고, 세션 안정성과 컨텍스트 소비량을 측정합니다.
GitHub Actions cron 파일럿: ralph-daily.yml을 만들어서 매일 아침 Claude Code를 비대화식으로 실행하는 워크플로우를 세팅합니다. --dangerously-skip-permissions 대신 allowlist 방식으로 보안 설정.
Claude Desktop Cowork 연동 테스트: 로컬 Obsidian 볼트에 MCP로 접근해서 RALPH daily를 Cowork Scheduled Tasks로 돌릴 수 있는지 확인합니다.

장기 방향

RALPH 루프의 판단 로직을 더 정교하게 만들기 (지금은 단순 점검 수준, 향후 패턴 인식과 선제적 추천으로 확장)
트리거 레이어와 판단 레이어를 명확히 분리해서, 어떤 트리거 메커니즘이든 갈아끼울 수 있는 구조로 리팩토링
실험 결과를 트레이딩 일지처럼 기록해서, 어떤 자동화 방식이 가장 안정적인지 데이터로 판단하기

FAQ

Q1. Claude Code Scheduled Tasks는 무료로 쓸 수 있나요? Claude Code 자체가 유료(Max $100/월 또는 API 과금)이므로, Scheduled Tasks도 유료 사용자만 이용 가능합니다. 별도 추가 비용은 없지만, 반복 실행되는 프롬프트마다 토큰이 소비됩니다.

Q2. /loop로 설정한 작업이 3일 뒤에 사라지면 어떻게 하나요? 만료 전에 취소하고 재생성하거나, Claude Desktop Cowork의 Scheduled Tasks를 사용하면 3일 만료 제한이 없습니다. 또는 GitHub Actions cron으로 장기 스케줄링이 가능합니다.

Q3. Claude Code 세션을 tmux로 유지하면 계속 돌아가나요? 네, 터미널 세션이 살아있으면 Scheduled Tasks도 유지됩니다. 다만 3일 만료 규칙은 여전히 적용되고, 장기 실행 세션의 컨텍스트 관리(compaction)와 토큰 소비량은 별도 모니터링이 필요합니다.

Q4. Claude Desktop Cowork과 Claude Code의 Scheduled Tasks를 동시에 쓸 수 있나요? 네, 서로 독립적인 시스템이라 동시 사용 가능합니다. Claude Code는 개발 세션 중 임시 모니터링, Cowork는 일상 반복 업무로 용도를 나누면 됩니다.

Q5. Cursor Automations와 Claude Scheduled Tasks는 경쟁 관계인가요? 관점에 따라 다릅니다. Cursor Automations는 이벤트 트리거 기반(GitHub 푸시, Slack 메시지 등)이고, Claude Scheduled Tasks는 시간 기반입니다. 이벤트가 “언제 발생할지 모르는” 작업은 Cursor, “정해진 시간에 반복”하는 작업은 Claude가 맞습니다. 상호 보완적이에요.

Q6. RALPH 루프 같은 개인 자동화 시스템을 만들려면 어디서 시작해야 하나요? Obsidian + Claude Code 조합이 가장 접근성이 좋습니다. 먼저 매일 반복하는 작업 하나를 골라서 프롬프트로 정리하고, 그걸 /loop로 세션 내 자동화해보는 것부터 시작하세요. 판단 로직은 사용하면서 점진적으로 추가하면 됩니다.

결론

Claude Code Scheduled Tasks는 개발 세션 중 임시 폴링과 모니터링을 위한 간이 cron입니다. Claude Desktop Cowork의 Scheduled Tasks와 이름은 같지만 지속성, 범위, 대상 사용자가 전혀 다릅니다.

RALPH 루프 같은 개인 자동화 시스템 관점에서 보면, Scheduled Tasks는 “실행 트리거”를 해결하지 “판단 구조”를 대체하지 않습니다. 알람 시계가 아침 루틴을 대신하지 않는 것처럼요.

진짜 자동화는 트리거와 판단을 분리하고, 각각에 맞는 도구를 쓰는 데서 시작됩니다. 트리거는 Scheduled Tasks든 GitHub Actions든 Cursor Automations든 골라 쓰면 되고, 판단은 직접 설계한 루프 안에서 계속 정교하게 만들어가야 합니다.

그러니 RALPH 루프는 끝이 아닙니다. 이제 시작이에요.