launchd, n8n, Codex 예약 작업을 나눠 쓰는 기준

반복 작업을 만들 때 처음 드는 생각은 "어디에 예약하지?"예요. n8n에 넣을 수도 있고, launchd에 넣을 수도 있고, Codex나 Claude의 예약 기능을 쓸 수도 있어요. 그런데 전부 한곳에 몰아넣으면 나중에 운영이 흐려집니다.

저는 로컬 AI 회사를 운영하면서 도구별 역할을 이렇게 나눠 보고 있어요.

launchd는 로컬 스크립트 실행에 좋아요

Mac mini에서 파일을 읽고 로컬 repo를 빌드하며, 로그를 남기는 작업은 launchd가 잘 맞아요. 터미널을 닫아도 돌고, 재부팅 후에도 다시 올릴 수 있어요.

대신 launchd는 환경이 얇아요. 터미널에서 되던 PATH가 launchd에서는 없을 수 있고, GUI 권한이나 Desktop 경로 권한 때문에 막힐 수도 있어요. 그래서 launchd 스크립트는 가능한 한 ~/ai-company, ~/n8n-marketing 같은 명확한 홈 경로 안에서 돌리는 게 좋아요.

저는 launchd를 이런 작업에 씁니다.

• 매시 work-cell 실행
• 매일 블로그 초안 생성
• 매일 블로그 발행 후보 처리
• watchdog과 healthcheck
• Notion sync 같은 로컬 주기 작업

n8n은 외부 서비스 연결에 좋아요

n8n은 webhook, Slack, Gmail, Google Sheets, API 연결이 많은 작업에 잘 맞아요. 흐름을 눈으로 보고, 실패한 execution을 열어볼 수 있다는 점도 좋아요.

반대로 n8n 안에 너무 많은 비즈니스 로직을 넣으면 디버깅이 어려워져요. 특히 Code node에 긴 JS가 쌓이면, 버전 관리와 테스트가 힘들어집니다. 저는 n8n을 "연결과 라우팅"에 두고, 복잡한 판단은 로컬 스크립트나 별도 모듈로 빼는 편이 낫다고 봅니다.

예를 들면 이런 식이에요.

• n8n: Slack slash command 받기
• n8n: webhook으로 이벤트 수신
• n8n: 실패 시 알림 보내기
• 로컬 스크립트: 실제 판정, 파일 생성, 검증

Codex와 Claude 예약은 판단이 필요한 반복에 좋아요

단순한 curl healthcheck는 굳이 LLM이 필요 없어요. 하지만 "오늘 로그를 보고 이상한 패턴을 요약해줘", "메일을 읽고 우선순위를 나눠줘", "지난 작업에서 교훈을 뽑아줘"처럼 해석이 필요한 반복 작업은 Codex나 Claude 예약이 어울립니다.

다만 이 예약은 세션 의존인지, 영구인지 꼭 확인해야 해요. 세션 안에서 만든 cron은 세션이 끝나면 사라질 수 있어요. 며칠 이상 안정적으로 돌아야 하는 작업은 launchd, GitHub Actions, Cloudflare Workers Cron, n8n처럼 독립 실행되는 곳에 두는 편이 맞습니다.

기준은 단순하게 잡는 게 좋아요

저는 이렇게 나눕니다.

작업 성격	추천 위치
로컬 파일, 빌드, repo 작업	launchd
Slack, Gmail, Sheets, webhook 연결	n8n
단순 healthcheck	launchd 또는 GitHub Actions
긴 해석과 요약이 필요한 작업	Codex/Claude 예약
외부 공개 발행	자동 준비 + 사람 승인

이 기준이 있으면 새 자동화를 만들 때 덜 흔들립니다. "이거 n8n에 넣을까?"가 아니라, 작업의 성격을 먼저 보고 위치를 정하게 되니까요.

반복 작업의 핵심은 소유권이에요

스케줄러를 여러 개 쓰면 또 다른 문제가 생겨요. 누가 실패를 책임지는지 애매해질 수 있습니다. 그래서 모든 반복 작업에는 최소한 세 가지를 붙여야 해요.

• 실행 주기
• 실패 알림 위치
• 결과물이 남는 경로

이 세 가지가 없으면 자동화가 조용히 사라집니다. 24시간 회사처럼 보이지만, 실제로는 아무도 결과를 확인하지 않는 상태가 될 수 있어요.

반복 작업은 많이 만드는 것보다, 실패했을 때 어디를 봐야 하는지 정해두는 게 먼저입니다. 혼자 운영할수록 더 그래요.