Treating Data Jobs as State

이 글들은 데이터 작업을 어떻게 실행하고 복구할 것인지 고민하던 질문에서 시작한다. 처음에는 단순했다. 정해진 시간에 script를 실행하고, script가 외부 데이터를 가져온 뒤 후속 작업을 이어가면 되는 줄 알았다.

하지만 실행 시간이 길어지고, 같은 대상의 중복 실행을 막아야 하고, 취소와 복구를 생각하기 시작하니 단순한 script 실행만으로는 설명되지 않는 상태들이 보이기 시작했다.

읽는 순서는 그대로 따라가는 편이 좋다. 1부에서는 왜 단순한 실행 흐름이 부족해졌는지 출발점을 정리한다. 2부에서는 queue, lease, lock이 왜 함께 등장했는지 설명한다. 3부에서는 pipeline, cancel, recovery를 상태 전이로 다루는 과정을 본다. 마지막 4부에서는 이 모델이 데이터 엔지니어링에서 언제 유용하고 언제 과한지 정리한다.

구성

1. 왜 단순한 script 실행만으로는 부족했을까 문제 유형은 오래 걸리는 script 실행의 불투명성이고, 적용 패턴은 작업 상태 기록이며, 판단 기준은 “시스템이 지금 상태를 설명할 수 있는가”다.

2. queue, lease, lock은 왜 같이 등장했을까 문제 유형은 여러 worker의 동시 실행 충돌이고, 적용 패턴은 queue, lease, resource lock이며, 판단 기준은 “누가 작업을 맡았고 누가 대상을 건드릴 수 있는가”다.

3. pipeline과 cancel, recovery를 상태로 다루기 문제 유형은 단계 실행 중 실패와 취소의 애매함이고, 적용 패턴은 pipeline과 recovery rule이며, 판단 기준은 “다시 실행해도 되는 상태인가”다.

4. 이 상태 모델은 언제 쓸 만하고 언제 과할까 문제 유형은 상태 모델의 과잉 도입이고, 적용 패턴은 도입 기준 분리이며, 판단 기준은 “실패와 중복 실행을 명시적으로 다뤄야 하는가”다.