큐가 주문 티켓 레일이라면, 잡은 그 레일 위의 티켓 한 장이에요.
딱 하나의 특정 작업이에요. 정의되고, 넘겨지고, 추적되고, 완료되죠. 전체 워크플로우도 아니고 시스템도 아니에요. 그냥 이것 하나, 지금 처리해야 할 것이에요.
소프트웨어 제품을 운영할 때 일상적으로 만나는 잡의 예를 들면 이렇습니다:
- 오후 3시 47분에 가입한 고객에게 환영 이메일 발송.
- 계정 #8812의 주간 요약 리포트 생성.
- 사용자가 방금 업로드한 프로필 사진 리사이즈.
- 어젯밤 세일에서 쌓인 주문 묶음 처리.
각각이 하나의 잡이에요. 서로 독립적이고, 시작과 끝이 있어요. 실행됐는지, 성공했는지, 실패했는지 확인할 수 있죠.
"잡"을 별도 개념으로 이해해야 하는 이유.
잡을 이해하고 나면 자신의 업무를 다르게 보기 시작해요.
비즈니스에서 하는 일 대부분은 잡으로 쪼갤 수 있어요. 진짜 질문은 이거예요: 지금 매번 직접 수동으로 실행하고 있는 잡이 무엇인가요? 그리고 어떤 것을 큐에 넣고 맡겨서 내가 지켜보지 않아도 처리되게 할 수 있을까요?
잡에는 몇 가지 유용한 특성이 있어요:
성공하거나 실패해요. 모호함이 없어요. 이 덕분에 잡은 추적 가능해요. 지난 일요일에 주간 리포트가 생성됐는지 모른다면, 그건 "잡이 실행됐는가?"라는 질문이에요.
재시도할 수 있어요. 실패한 잡이 계속 실패한 상태로 남을 필요는 없어요. 제대로 된 시스템은 실패를 감지하고 다시 시도해요. 반송된 환영 이메일은 재시도를 위해 큐에 다시 들어가죠. 이를 재시도 로직이라 하는데, 에이전트 워크플로우를 안정적으로 만드는 가장 빠른 방법 중 하나예요.
일정을 가질 수 있어요. 평일 오전 9시마다 실행되는 잡은 마법이 아니에요. 트리거가 붙은 잡이에요. 그 트리거 시스템에는 별도 이름이 있는데, 바로 cron이에요.
혼선을 줄이는 구분법.
"시스템이 정상 작동하는가"와 "이 특정 잡이 잘 실행됐는가"를 혼동하는 경우가 많아요. 시스템 전체는 멀쩡한데 특정 고객, 특정 날짜의 잡 하나가 조용히 실패할 수 있어요. 둘이 별개임을 알아야 둘 다 확인하게 되거든요.
시스템에 물어봐야 해요: 잡이 실행됐나요? 성공했나요? 시스템이 이 질문에 답할 수 있어야 해요. 답하지 못한다면, 고객이 왜 이메일이 안 왔냐고 묻기 전에 고치는 게 낫습니다.
잡은 자동화된 작업의 원자 단위예요. 작고, 추적 가능하고, 교체 가능해요. 그렇게 만들면 전체 시스템을 지켜보기가 훨씬 쉬워져요.