실행이 보장되는 Cron

Why

매일 쓰는 스케줄 작업이 있습니다.
일일 리포트, 주간 로그 정리, 월간 청소 작업…

예상대로 잘 동작하고, 별 문제 없습니다.
그런데 뭐죠? 이 찜찜함은?

이상하죠.
아마도 이것 때문 일 겁니다.

• 크론이 진짜 작동 했을까?
• 재부팅을 했는데 작업들은 어떻게 됐을지
• 중간에 에러가 나진 않았는지…

늘 찜찜 한데 뭔가 딥하게 살펴 보기에는 너무 귀찮습니다.
그러다가 바쁜 일상에 치여 한마디로 넘기죠.

“잘 됐을거야. 아님 다시 하지 뭐”

그렇습니다.
슬프지만 운에 맡기고 있죠.

우리가 쓰던 cron 은 “시도” 를 예약할 뿐, “실행” 을 보장하지 않습니다.

Cron 이 뭐예요?

서버에서 “이때 이 명령을 실행해”라고 시간과 주기를 적어두는 것.
모든 Linux 계열의 서버에 네이티브로 존재하는 전통적인 스크립트입니다.

그런데 cron 은 시간 이벤트 스케줄러일 뿐이고,
실패/재시도/중단 후 재개/감사 로그 같은 건 없습니다.
그냥 그 명령의 실행 출력을 기록한 파일 로그 뿐 입니다.

즉, 성공을 끝까지 보장하는 메커니즘이 없어요.

성공이든 실패든, 종료를 보장 받고 싶다면, cron 외에 뭔가 더 필요합니다.
오늘 그걸 알아볼거예요.

일단, 실행 보장이라는게 대체 뭔지를 알아봅시다.

실행 보장의 필수 요소

• Retry — 실패하면 다시 시도해야 합니다. (백오프 포함)
• Resume — 중간에 끊겨도 이어서 가야 합니다. (체크포인트)
• Idempotency — 재시도해도 부작용 없이 처음 실행과 같아야 합니다.
• Ordering — 여러 단계 작업을 순서대로 보장해야 합니다.
• Visibility — 누가, 언제, 무엇을, 성공/실패 왜 했는지 보여야 합니다.

필수를 나열하긴 했는데, 좀 복잡하죠?
다만 확실한건, 하나하나 일일히 구현 하자니 꽤 어렵다는 것입니다.

• 구현 난이도가 높은 데다,
• 만드는 사람마다 중구난방이니 결국 쭉 이어지지 못합니다.

누구는 Cron, 누구는 batch, 누구는 TS, 누구는 GO… 누구는 맥, 누구는 리눅스…
1회용이 되어 버리죠.

.
.

자, 그런데 이 문제를 해결할 아주 좋은게 있어요.

소개합니다.
바로 Temporal 입니다.

Temporal 이 뭔가요?

Temporal 은 실행을 인프라 레벨에서 보장하는 오픈소스 입니다.
https://temporal.io/

N8N 같은 노코드 워크플로 서비스가 유행인데, Temporal 은 코드 버전의 워크플로 서비스라고 생각하세요.

Temporal 을 간단히 말하면 “한번 실행하겠다고 기록하면, 적어도 성공이든 실패이든 끝까지 책임지는 시스템.” 이라고 할수 있습니다.

• 워크플로우(Workflow)라는 “절차”를 코드로 정의하면
• 작업(Activities)은 실제 일을 처리하는 함수로 실행되고
• 모든 상태/이벤트가 히스토리에 저장되며
• 실패하면 자동 재시도, 중단되면 마지막 성공 지점부터 재개 하는 매커니즘을 갖습니다.
• 수 시간~수주짜리 장기 배치도 문제없이 굴러갑니다.

그리고, 이런 류의 워크플로 서비스가 갖춰야할 완벽한 스케줄링도 됩니다.

Schedule 기능으로 Cron처럼 주기 실행을 걸어두는건 같지만,
위 실행/종료 보장의 모든 원칙이 적용되기 때문에

Temporal 은 성공이던 실패이던 그 실행 결과는 반드시 만들어냅니다.

Cron과는 완전히 다릅니다.

재밌게 표현하면,

• Cron: 실행은 해보는 거야. 우린 여기까지야.
• Temporal: 실행을 하고, 반드시 너에게 돌아올께. 약속해.

.
.

우리가 그동안 사용한 Cron은… 결과를 운에 맡겼던 겁니다.
Temporal 은 운에 맡기지 않죠. 책임을 집니다.

실행을 보장해서요.

보장된 실행 흐름

Temporal 의 작업 흐름을 한번 따라가 봅시다.

1. 스케줄 등록
   • “매일 00:10에 보고서 생성”을 Schedule로 만듭니다.
2. 트리거 발생 → 워크플로우 시작
   • 정해진 시간에 워크플로우가 시작됩니다.
   • 미리 워커들이 temporal 에 붙어있기만 하면 됩니다.
3. 액티비티 실행
   • 외부 API 호출 / DB 조회 / 파일 쓰기 등 실제 작업을 하는 코드를 액티비티로 만들어 두었을 겁니다.
   • 이걸 워크플로 안에서 호출하게 됩니다.
4. 오우 잘 가다가 3번째 액티비티에서 실패했네요.
   • 네트워크 타임아웃, 500에러, 임계 리소스 락… 뭐든 실패할 수 있습니다.
   • 매일 겪는 거죠.
5. 그렇다면? → 자동으로 재시도 합니다.
   • 여기서 Cron 과 차이가 있는데요. 크론은 거기서 끝납니다. 그리고 왜 끝난건지도 모르죠.
   • Temporal 은, 다르죠.
     • 워크플로에 정의한 정책대로 즉시/지수 백오프로 재시도합니다.
     • 이때, 멈춘 부분 부터 다시 합니다.
     • 물론 직전 까지의 인풋/아웃풋은 히스토리에 남아 있어서,
     • temporal 이 절묘하게 그 값을 공급해서 거기부터 이어서 합니다.
   • 이 설계가 워크플로/액티비티를 잘 구분해둔 Temporal 철학 에서 오는 핵심 입니다.
6. 앗, 근데 워커가 다운됐네요.
   • 아유 괜찮습니다. Cron이면 OMG 였겠지만... 우린 괜찮아요.
   • 히스토리가 다 있으니, 다른 워커를 실행하기만 하면 돼요.
   • 마지막 성공 지점부터 다시 이어갑니다.
7. 완료 & 가시성
   • 성공/실패/재시도 이력이 전부 남고, 성공이면 왜 성공인지, 실패이면 왜 실패인지는 보면 됩니다.
   • 이제 Temporal 웹 대시보드에서 바로 확인됩니다.

.
.
.

어때요? Cron 쓰기 싫어졌죠?

그렇습니다.
우리가 무언가를 제대로 했다고 말하려면 이정도는 되어야죠.

Cron vs Temporal 요약

• Cron
  • 서버 재부팅? → 작업도 사라짐
  • 실패? → 로그만 남음
  • 재시도/재개? → 사람 손
  • 상태/Audit? → 각 팀이 제각각
• Temporal
  • 서버 재부팅? → 이어 실행
  • 실패? → 자동 재시도w
  • 재개? → 마지막 체크포인트부터
  • 상태/Audit → 히스토리로 일관되게

Cron 은 “시도”를, Temporal 은 “완료”를 보장하죠.

어따 쓰냐고요?

Cron 을 쓰던 곳인데, 제대로 해야 하는 모든 곳 입니다.

• 매일 / 매주 / 매월 리포트, 정리, 클린업
• 실패율이 높은 외부 API 연계가 많은 작업(SMS, 이메일, 대량 배치, 크롤링…)
• 대규모 데이터 마이그레이션, 백필(Backfill)
• 장기 절차(결제 승인 → 준비 → 배송 → 정산처럼 며칠 걸리는 플로우)

Cron이 안되면 어쩌지? 라는 불안을 영원히 떨쳐버리세요.
이제 그냥 맡겨버리면 됩니다.

Temporal 적용이 어렵나요?

약간 할 일이 있습니다.
물론 Cron 보다야 복잡 합니다.

그런데 Cron 을 만들때도 Cron 에 맞춰서 개발 했을 겁니다.
CLI 형태로 만들고 등등.

그 정도의 노력이면 됩니다.
앞으로 새로 진행할 작업을 Temporal 로 만들어보세요.

Go, TS, JAVA, PHP 등 다양한 SDK를 제공 하며, Temporal 은 오픈소스 입니다.
Self-hosted 도 가능하고, 서버 유지에 자신이 없으면 Temporal Cloud 도 있습니다.

• 워크플로우 / 액티비티 코드는 기존 함수를 래핑한 일반 함수입니다.
• 함수 단위로 액티비티로 빼고, 이를 워크플로우로 명확히 시간 순으로 조립하면 되죠.
• 항상 멱등하게 설계하시면 만사 OK

마무리

매일 쓰지만, 항상 찜찜한 기술이 있죠.
cron 이 그랬습니다.

이제 그 짐을 좀 덜어내는게 어떨까요?
물론 Temporal 말고도 우수한 스케쥴러, Cron 대체 솔루션들이 있습니다.

대표적으로 Kubernetes 의 CronJob 같은게 있죠.
하지만 쿠버네티스 운영은 엔지니어에게 접근성이 매우 떨어지고,
비 엔지니어는 못 합니다.

Temporal 외에도 Windmill 등 Workflow Job 솔루션들이 있어요.
하지만 직관적이며, 멱등성을 지원하고, 설계가 단순한 것이 항상 옳습니다.

Temporal 은 딱 이 단일 목적으로 CLI, 웹대시보드, 워커오케이스트레이션, SDK만 초집중 하는 서비스에요.

목적에 맞고, 오버엔지니어링이 없으며,
완전한 실행 보장을 얻고, 우리는 평온을 찾아가 보아요.

다음에도 좋은 글로 찾아뵙겠습니다.

아임웹 CTO 매튜 드림.