저장 눌렀는데 변경 이력이 안 남는 이유
작업 예약 시간을 확인한 뒤 아무것도 수정하지 않고 저장(Save) 버튼을 눌렀다고 하자. 작업이 다시 실행된 것도 아니고, 설정 값도 달라지지 않았다. 그런데 이런 행동을 새로운 설정 변경으로 남겨야 할까?
이 질문은 "저장 버튼을 눌렀다"와 "실제 설정이 바뀌었다"를 구분하는 데서 출발한다.
두 종류의 기록부터 구분하자
- 설정 변경 이력: 작업의 스케줄, 설정 등 구성 정보가 언제 어떻게 달라졌는지 보는 기록
- 작업 실행 이력: 정해진 작업이 실제로 언제 실행됐고 어떤 상태였는지 보는 기록
Databricks Lakeflow Jobs의 시스템 테이블 system.lakeflow.jobs와 system.lakeflow.job_tasks는 구성 변경 이력을 설명하기 위한 자료다. 별도의 작업 실행 관련 타임라인 테이블과 혼동하면, 실행 여부를 잘못 해석할 수 있다.
2026년 10월 제조사 업데이트
Databricks 공식 2026년 10월 릴리스는 10월 19일 업데이트에서 설정을 바꾸지 않은 작업을 저장하더라도 위 두 설정 이력 테이블에 새 행을 추가하지 않으며, change_time을 마지막 실제 설정 변경 시점 그대로 유지하도록 바뀌었다고 안내한다. UI, Jobs API, Declarative Automation Bundles의 저장 경로가 범위에 포함된다.
이는 모든 저장 이벤트가 취소된다거나, 작업이 실행되지 않는다거나, 업데이트 후 어느 워크스페이스에서나 즉시 같은 상태가 된다는 의미는 아니다. Databricks는 기능 적용을 단계적으로 진행할 수 있다고 명시한다.
가상 예시
| 순서 | 사용자가 한 일 | 확인할 내용 |
|---|---|---|
| 1 | 오전 9시, 예약 시간을 실제로 변경 | 실제 설정 변경으로 간주할 수 있는지 |
| 2 | 오전 10시, 값 변경 없이 Save 클릭 | 새 설정 변경 행이 없어야 한다는 업데이트 설명 |
| 3 | 오전 11시, 예약된 작업 실행 | 설정 변경 이력이 아닌 실행 이력 확인 |
위 시각과 행은 이해를 위한 합성 예시이며, 실제 Databricks 계정에서 재현한 결과가 아니다.
결론
"저장했는가?"보다 "설정 값이 실제로 달라졌는가?"를 먼저 확인하자. 그리고 실행 이력과 구성 변경 이력을 다른 표로 취급하면 불필요한 오류 추정을 줄일 수 있다.
1차 근거
검증 범위: 제조사 공식 문서를 해설한 교육용 자료입니다. 예시는 원리를 설명하기 위한 가상 상황이며, 실제 현장 장비·운영 데이터베이스·고객 워크스페이스에서 성능이나 복구 결과를 측정한 실험이 아닙니다. 운영 설정 변경은 담당자의 승인과 해당 제품의 최신 문서를 확인한 뒤 진행해야 합니다.